In dit artikel bespreken we wat smart contracts zijn, welke soorten er zijn, maken we kennis met verschillende smart contracts-platformen, hun functies en bespreken we hoe ze zijn gestructureerd en welke voordelen ze kunnen bieden. Dit materiaal is zeer nuttig voor lezers die nog niet zo bekend zijn met het onderwerp smart contracts, maar er meer over willen weten.
Regulier contract versus slim contract
Voordat we in de details duiken, bekijken we een voorbeeld van het verschil tussen een gewoon contract, dat op papier is geschreven, en een slim contract, dat digitaal is vastgelegd.
Hoe werkte het vóór smart contracts? Stel je een groep mensen voor die regels en voorwaarden willen vaststellen voor de verdeling van waarden, en ook een bepaald mechanisme om ervoor te zorgen dat deze verdeling volgens de gegeven regels en voorwaarden plaatsvindt. Vervolgens komen ze bij elkaar, stellen een document op waarop ze hun identificatiegegevens, voorwaarden en de betrokken waarden noteren, de datum vermelden en ondertekenen. Dit contract wordt ook gecertificeerd door een betrouwbare partij, bijvoorbeeld een notaris. Vervolgens gaan deze mensen hun eigen weg met hun papieren exemplaar van zo'n contract en beginnen ze enkele handelingen te verrichten die mogelijk niet overeenkomen met het contract zelf. Dat wil zeggen, ze doen één ding, maar het document bevestigt dat ze iets heel anders moeten doen. En hoe kom je uit deze situatie? Sterker nog, een van de groepsleden moet dit document meenemen, wat bewijs verzamelen, het voor de rechter brengen en ervoor zorgen dat het contract en de daadwerkelijke handelingen worden nageleefd. Vaak is het moeilijk om een eerlijke uitvoering van dit contract te bereiken, wat tot onaangename gevolgen leidt.
Wat valt er te zeggen over smart contracts? Ze combineren de mogelijkheid om contractvoorwaarden te schrijven met het mechanisme voor de strikte implementatie ervan. Als de voorwaarden zijn vastgelegd en de bijbehorende transactie of aanvraag is ondertekend, is het na acceptatie van deze aanvraag of transactie niet meer mogelijk om de voorwaarden te wijzigen of de implementatie ervan te beïnvloeden.
Er is één validator of een heel netwerk, evenals een database die alle smart contracts die ter uitvoering zijn ingediend, in een strikt chronologische volgorde opslaat. Het is ook belangrijk dat deze database alle triggervoorwaarden voor de uitvoering van het smart contract bevat. Bovendien moet er rekening worden gehouden met de waarde waarvan de distributie in het contract wordt beschreven. Als het om een digitale valuta gaat, moet deze database hier rekening mee houden.
Met andere woorden, validators van smart contracts moeten toegang hebben tot alle gegevens waarop het smart contract draait. Zo moet één database worden gebruikt om gelijktijdig digitale valuta, gebruikerssaldi, gebruikerstransacties en tijdstempels te registreren. Een voorwaarde in een smart contract kan vervolgens het saldo van een gebruiker in een bepaalde valuta, het verschijnen van een bepaald tijdstip of het feit dat een bepaalde transactie heeft plaatsgevonden zijn, maar niets meer.
Definitie van een slim contract
De terminologie zelf werd in feite bedacht door onderzoeker Nick Szabo en voor het eerst gebruikt in 1994. In 1997 werd deze term vastgelegd in een artikel waarin het idee van slimme contracten werd beschreven.
Smart contracts impliceren dat er een zekere mate van automatisering van de waardeverdeling plaatsvindt, die mogelijk alleen afhankelijk is van vooraf vastgestelde voorwaarden. In de eenvoudigste vorm lijkt dit op een contract met strikt gedefinieerde voorwaarden, dat door bepaalde partijen wordt ondertekend.
Smart contracts zijn ontworpen om het vertrouwen in derden te minimaliseren. Soms wordt het besluitvormingscentrum waar alles van afhangt volledig uitgesloten. Bovendien is het gemakkelijker om dergelijke contracten te controleren. Dit is een gevolg van enkele ontwerpkenmerken van een dergelijk systeem, maar meestal beschouwen we een smart contract als een gedecentraliseerde omgeving en de aanwezigheid van functies waarmee iedereen de database kan analyseren en een volledige controle van de contractuitvoering kan uitvoeren. Dit garandeert bescherming tegen retroactieve gegevenswijzigingen die wijzigingen in de uitvoering van het contract zelf met zich meebrengen. Digitalisering van de meeste processen bij het opstellen en lanceren van een smart contract vereenvoudigt vaak de technologie en de kosten van de implementatie ervan.
Een eenvoudig voorbeeld is de Escrow-service
Laten we eens kijken naar een heel eenvoudig voorbeeld. Het helpt ons de functionaliteit van smart contracts beter te begrijpen en beter te begrijpen wanneer ze gebruikt moeten worden.
Het kan ook worden geïmplementeerd met Bitcoin, hoewel Bitcoin nog steeds moeilijk een volwaardig platform voor smart contracts te noemen is. We hebben dus een koper en een webwinkel. De koper wil een monitor in deze winkel kopen. In het eenvoudigste geval doet en verzendt de koper een betaling, waarna de webwinkel deze accepteert, bevestigt en de goederen verstuurt. In deze situatie is echter groot vertrouwen nodig: de koper moet de webwinkel de volledige kosten van de monitor kunnen toevertrouwen. Omdat de webwinkel een slechte reputatie kan hebben in de ogen van de koper, bestaat het risico dat de winkel om de een of andere reden na acceptatie van de betaling de service weigert en de goederen niet naar de koper verstuurt. Daarom vraagt de koper zich af (en de webwinkel stelt zich dienovereenkomstig deze vraag) wat er in dit geval kan worden gedaan om dergelijke risico's te minimaliseren en dergelijke transacties betrouwbaarder te maken.
In het geval van Bitcoin kunnen we de koper en verkoper de mogelijkheid bieden om onafhankelijk een bemiddelaar te kiezen. Er zijn veel mensen die geschillen behandelen. En onze deelnemers kunnen uit een gemeenschappelijke lijst van bemiddelaars degene kiezen die ze tegelijkertijd vertrouwen. Samen creëren ze een 2 van 3 multisignature-adres, met drie sleutels. Twee handtekeningen zijn vereist om munten van dit adres te kunnen uitgeven. Eén sleutel is van de koper, de tweede van de webwinkel en de derde van de bemiddelaar. En naar zo'n multisignature-adres stuurt de koper het bedrag dat nodig is om de monitor te betalen. Wanneer de verkoper nu ziet dat het geld enige tijd geblokkeerd is op het multisignature-adres dat van hem afhankelijk is, kan hij de monitor veilig per post versturen.
Vervolgens ontvangt de koper het pakket, inspecteert de goederen en neemt een definitieve beslissing over de aankoop. Hij kan volledig tevreden zijn met de geleverde service en de transactie ondertekenen met zijn sleutel, waarbij hij de munten van het multisignature-adres naar de verkoper overdraagt, of hij kan ergens ontevreden over zijn. In het tweede geval neemt hij contact op met de bemiddelaar om een alternatieve transactie op te stellen waarbij de munten anders worden verdeeld.
Stel dat de monitor licht bekrast is aangekomen en er geen kabel voor de verbinding met de computer in de set zit, terwijl op de website van de webwinkel staat dat die kabel wel meegeleverd zou moeten worden. Vervolgens verzamelt de koper het nodige bewijs om de bemiddelaar te bewijzen dat hij in deze situatie is opgelicht: hij maakt screenshots van de website, fotografeert de bon van het postkantoor, fotografeert de krassen op de monitor en toont aan dat de verzegeling is verbroken en de kabel is losgetrokken. De webwinkel verzamelt vervolgens het bewijs en geeft dit door aan de bemiddelaar.
De bemiddelaar is geïnteresseerd in het bevredigen van zowel de verontwaardiging van de klant als de belangen van de webwinkel (later zal duidelijk worden waarom). Hij creëert een transactie waarbij de munten van het multisignature-adres in een bepaalde verhouding worden uitgegeven tussen de klant, de webwinkel en de bemiddelaar, aangezien hij een deel ontvangt als beloning voor zijn werk. Stel dat 90% van het totale bedrag naar de verkoper gaat, 5% naar de bemiddelaar en 5% naar de koper. De bemiddelaar ondertekent deze transactie met zijn sleutel, maar deze kan nog niet worden toegepast, omdat er twee handtekeningen nodig zijn, en slechts één is de moeite waard. Hij stuurt een dergelijke transactie naar zowel de koper als de verkoper. Als ten minste één van hen tevreden is met deze optie voor het herverdelen van de munten, wordt de transactie opnieuw ondertekend en naar het netwerk gedistribueerd. Voor de validatie is het voldoende dat een van de deelnemers aan de transactie instemt met de optie van de bemiddelaar.
Het is belangrijk om in eerste instantie een bemiddelaar te selecteren, zodat beide partijen hem vertrouwen. In dat geval zal hij onafhankelijk van de belangen van de een of de ander handelen en de situatie objectief beoordelen. Als de bemiddelaar geen optie voor de distributie van munten biedt die ten minste één partij tevreden stelt, kunnen zowel de koper als de webwinkel, na overleg, de munten doorsturen naar een nieuw adres met meerdere handtekeningen, waarbij ze hun twee handtekeningen plaatsen. Het nieuwe adres met meerdere handtekeningen wordt aangemaakt door een andere bemiddelaar, die mogelijk competenter is en een betere optie kan bieden.
Voorbeeld met een slaapzaal en een koelkast
Laten we eens naar een complexer voorbeeld kijken dat de mogelijkheden van een slim contract duidelijker illustreert.
Stel je voor dat er drie mannen zijn die onlangs een studentenkamer hebben betrokken. Ze zijn alle drie geïnteresseerd in een koelkast voor hun kamer, die ze samen zullen gebruiken. Een van hen heeft zich aangeboden om het benodigde geld voor de koelkast bij elkaar te krijgen en met de verkoper te onderhandelen. Ze hebben elkaar echter pas kort ontmoet en er is onvoldoende vertrouwen tussen hen. Het is duidelijk dat twee van hen een risico nemen door geld aan de derde te geven. Bovendien moeten ze het eens worden over de verkoper.
Ze kunnen gebruikmaken van de escrowservice, dat wil zeggen een bemiddelaar kiezen die toezicht houdt op de uitvoering van de transactie en eventuele geschillen beslecht. Na overeenstemming stellen ze vervolgens een smart contract op en leggen ze er bepaalde voorwaarden in vast.
De eerste voorwaarde is dat er vóór een bepaalde tijd, bijvoorbeeld binnen een week, drie betalingen van bepaalde adressen voor een bepaald bedrag op de bijbehorende smart contract-rekening moeten zijn ontvangen. Als dit niet gebeurt, stopt het smart contract met de uitvoering en worden de munten teruggegeven aan alle deelnemers. Als aan de voorwaarde is voldaan, worden de waarden van de verkoper- en bemiddelaar-ID's ingesteld en wordt gecontroleerd of alle deelnemers akkoord gaan met de keuze van de verkoper en bemiddelaar. Wanneer aan alle voorwaarden is voldaan, wordt het geld overgemaakt naar de opgegeven adressen. Deze aanpak kan deelnemers beschermen tegen fraude van welke kant dan ook en elimineert over het algemeen de noodzaak van vertrouwen.
In dit voorbeeld zien we het principe zelf: een dergelijke mogelijkheid om stapsgewijs parameters in te stellen voor de vervulling van elke voorwaarde, maakt het mogelijk om systemen te creëren van elke complexiteit en diepte van geneste niveaus. Bovendien kan eerst de eerste voorwaarde in het smart contract worden gedefinieerd en pas nadat deze is vervuld, kunnen de parameters voor de volgende voorwaarde worden ingesteld. Met andere woorden, de voorwaarde is formeel voorgeschreven en de parameters hiervoor kunnen tijdens de uitvoering worden ingesteld.
Classificatie van slimme contracten
Voor classificatie kunnen verschillende groepen criteria worden vastgesteld. Op dit moment van technologische ontwikkeling zijn er echter vier relevant.
Smart contracts onderscheiden zich door hun uitvoeringsomgeving, die zowel gecentraliseerd als gedecentraliseerd kan zijn. In het geval van decentralisatie hebben we een veel grotere onafhankelijkheid en fouttolerantie bij de uitvoering van smart contracts.
Ze kunnen ook worden onderscheiden door het proces van het instellen en vervullen van voorwaarden: ze kunnen willekeurig programmeerbaar, beperkt of vooraf ingesteld zijn, d.w.z. strikt getypeerd. Wanneer er slechts vier specifieke smart contracts op het smart contractplatform staan, kunnen de parameters daarvoor willekeurig worden ingesteld. Het instellen ervan is dan ook veel eenvoudiger: we selecteren een contract uit de lijst en geven de parameters door.
Op basis van de initiatiemethode bestaan er geautomatiseerde smart contracts. Dat wil zeggen dat ze automatisch worden uitgevoerd als aan bepaalde voorwaarden is voldaan. Er zijn ook contracten waarbij de voorwaarden wel zijn vastgelegd, maar het platform de naleving ervan niet automatisch controleert. Hiervoor moeten ze afzonderlijk worden geïnitieerd.
Bovendien variëren smart contracts in hun mate van privacy. Ze kunnen volledig openbaar, gedeeltelijk of volledig vertrouwelijk zijn. Dit laatste betekent dat externe waarnemers de voorwaarden van smart contracts niet kunnen inzien. Het onderwerp privacy is echter zeer breed en kan het beste los worden bekeken van dit artikel.
Hieronder gaan we dieper in op de eerste drie criteria om het actuele onderwerp beter te begrijpen.
Slimme contracten per uitvoeringsomgeving
Afhankelijk van de uitvoeringsomgeving bestaan er gecentraliseerde en gedecentraliseerde smart contract-platformen. Bij gecentraliseerde digitale contracten wordt gebruikgemaakt van één service, met slechts één validator en mogelijk een back-up- en herstelservice, die eveneens centraal wordt beheerd. Er is één database die alle informatie opslaat die nodig is om de voorwaarden van het smart contract vast te stellen en de waarde te verdelen die in deze database in aanmerking wordt genomen. Zo'n gecentraliseerde service heeft een client die de voorwaarden voor bepaalde verzoeken vaststelt en dergelijke contracten gebruikt. Doordat het platform gecentraliseerd is, kunnen authenticatiemechanismen minder betrouwbaar zijn dan bij cryptovaluta.
Neem bijvoorbeeld mobiele-communicatieproviders (verschillende mobiele operators). Stel dat een bepaalde operator een gecentraliseerde registratie van het verkeer op zijn servers bijhoudt, die in verschillende formaten kan worden verzonden, bijvoorbeeld in de vorm van spraakoproepen, sms-berichten, mobiel internetverkeer en volgens verschillende standaarden. Ook houdt hij de saldi van gebruikers bij. Een mobiele-communicatieprovider kan dan contracten opstellen voor de boekhouding van geleverde diensten en de betaling daarvan, met verschillende voorwaarden. In zo'n geval zijn voorwaarden zoals "stuur een sms met die en die code naar dat en die nummer en je ontvangt die en die voorwaarden voor verkeersdistributie" eenvoudig in te stellen.
Een ander voorbeeld: traditionele banken met geavanceerde internetbankierfunctionaliteit en zeer eenvoudige contracten zoals periodieke betalingen, automatische omrekening van binnenkomende betalingen, automatische afschrijving van rente op een bepaalde rekening, etc.
Als we het hebben over smart contracts met een gedecentraliseerde uitvoeringsomgeving, dan hebben we een groep validators. In het ideale geval kan iedereen validator worden. Dankzij het databasesynchronisatieprotocol en de consensus hebben we een gemeenschappelijke database die nu alle transacties met strikt beschreven contracten opslaat, en niet enkele voorwaardelijke verzoeken, waarvan de formaten vaak veranderen, en er is geen open specificatie. Transacties bevatten instructies voor de uitvoering van het contract volgens een strikte specificatie. Deze specificatie is open en daarom kunnen de platformgebruikers zelf smart contracts controleren en valideren. Hier zien we dat gedecentraliseerde platformen superieur zijn aan gecentraliseerde platformen in onafhankelijkheid en fouttolerantie, maar hun ontwerp en onderhoud zijn veel complexer.
Slimme contracten door middel van het stellen en vervullen van voorwaarden
Laten we nu eens nader bekijken hoe smart contracts kunnen verschillen in de manier waarop voorwaarden worden ingesteld en uitgevoerd. We zullen hier aandacht besteden aan smart contracts die willekeurig geprogrammeerd en Turing-compleet zijn. Met een Turing-compleet smart contract kunt u vrijwel elk algoritme instellen als voorwaarden voor de uitvoering van een contract: het schrijven van cycli, sommige kansberekeningsfuncties en dergelijke - tot en met uw eigen algoritmen voor elektronische handtekeningen. In dit geval bedoelen we echt willekeurig geschreven logica.
Er bestaan ook willekeurige smart contracts, maar die zijn niet Turing-compleet. Denk bijvoorbeeld aan Bitcoin en Litecoin met hun eigen script. Dit betekent dat je alleen bepaalde bewerkingen in willekeurige volgorde kunt gebruiken, maar dat je geen cycli en je eigen algoritmes meer kunt schrijven.
Daarnaast zijn er smart contract-platformen die vooraf geïnstalleerde smart contracts implementeren. Voorbeelden hiervan zijn Bitshares en Steemit. Bitshares biedt een aantal smart contracts voor trading, accountbeheer en het beheer van het platform zelf en de parameters ervan. Steemit is een vergelijkbaar platform, maar richt zich niet langer op het uitgeven van tokens en trading zoals Bitshares, maar op bloggen, d.w.z. het slaat content decentraal op en verwerkt deze.
Arbitraire Turing-complete contracten omvatten het Ethereum-platform en RootStock, dat nog in ontwikkeling is. Daarom zullen we hieronder wat dieper ingaan op het Ethereum smart contract-platform.
Slimme contracten op basis van initiatiemethode
Qua initiatiemethode kunnen smart contracts ook worden onderverdeeld in ten minste twee groepen: geautomatiseerd en handmatig (niet-geautomatiseerd). Geautomatiseerde contracten kenmerken zich doordat het smart contract, met alle bekende parameters en voorwaarden, volledig automatisch wordt uitgevoerd. Dat wil zeggen dat er geen extra transacties hoeven te worden uitgevoerd en er geen extra commissie hoeft te worden betaald voor elke volgende uitvoering. Het platform zelf beschikt over alle gegevens om te berekenen hoe het smart contract zal worden voltooid. De logica is hier niet willekeurig, maar vooraf ingesteld en dit alles is voorspelbaar. Dat wil zeggen dat u de complexiteit van het smart contract vooraf kunt inschatten, er een constante commissie voor kunt gebruiken en alle implementatieprocessen efficiënter zijn.
Voor willekeurig geprogrammeerde smart contracts is de uitvoering niet geautomatiseerd. Om zo'n smart contract te initiëren, moet u bij elke stap een nieuwe transactie aanmaken, die de volgende uitvoeringsfase of de volgende methode van het smart contract aanroept, de bijbehorende commissie betalen en wachten op de transactiebevestiging. De uitvoering kan al dan niet succesvol worden voltooid, omdat de code van het smart contract willekeurig is en er onvoorspelbare momenten kunnen optreden, zoals een eeuwige lus, het ontbreken van bepaalde parameters en argumenten, onafgehandelde uitzonderlijke momenten, enz.
Ethereum-accounts
Ethereum-accounttypen
Laten we eens kijken welke accounts er mogelijk zijn op het Ethereum-platform. Er zijn hier slechts twee soorten accounts en geen andere opties. Het eerste type is een gebruikersaccount, het tweede is een contractaccount. Laten we eens kijken hoe ze verschillen.
Het gebruikersaccount wordt uitsluitend beheerd door de persoonlijke sleutel van de elektronische handtekening. De accounteigenaar genereert zijn eigen sleutelpaar voor de elektronische handtekening met behulp van het ECDSA-algoritme (Elliptic Curve Digital Signature Algorithm). Alleen transacties die met deze sleutel zijn ondertekend, kunnen de status van dit account wijzigen.
Een smart contract-account heeft zijn eigen logica. Het kan alleen worden beheerd met behulp van een vooraf gedefinieerde programmacode die het gedrag van het smart contract volledig definieert: hoe het zijn munten onder bepaalde omstandigheden zal beheren, op initiatief van welke gebruiker, en onder welke aanvullende voorwaarden deze munten zullen worden gedistribueerd. Als bepaalde punten niet door de ontwikkelaars in de programmacode worden aangegeven, kunnen er problemen ontstaan. Een smart contract kan bijvoorbeeld een bepaalde status krijgen waarin het geen verdere uitvoering van de munten door gebruikers accepteert. In dit geval worden de munten feitelijk bevroren, omdat het smart contract geen mogelijkheid biedt om deze status te verlaten.
Hoe Ethereum-accounts worden aangemaakt
In het geval van een gebruikersaccount genereert de eigenaar zelfstandig een sleutelpaar met behulp van ECDSA. Het is belangrijk om op te merken dat Ethereum exact hetzelfde algoritme en exact dezelfde elliptische curve gebruikt voor de elektronische handtekening als Bitcoin, maar dat het adres op een iets andere manier wordt berekend. Hierbij wordt niet langer het resultaat van dubbele hashing gebruikt, zoals bij Bitcoin, maar wordt een enkele hashing door de Keccak-functie geleverd over een lengte van 256 bits. De minst significante bits worden afgesneden van de resulterende waarde, namelijk 160 minst significante bits van de uitvoerwaarde van de hashfunctie. Dit resulteert in een adres in Ethereum. In feite neemt het 20 bytes in beslag.
Houd er rekening mee dat de account-ID in Ethereum gecodeerd is in hexadecimaal zonder controlesom, in tegenstelling tot Bitcoin en veel andere systemen, waar het adres gecodeerd is in basis 58 met een controlesom. Dit betekent dat je voorzichtig moet zijn bij het werken met account-ID's in Ethereum: zelfs één fout in de ID leidt gegarandeerd tot het verlies van munten.
Een belangrijk kenmerk is dat het gebruikersaccount op het niveau van de algemene database wordt aangemaakt op het moment dat hij de eerste binnenkomende betaling accepteert.
Een compleet andere aanpak wordt gebruikt voor het aanmaken van een smart contract-account. Eerst schrijft een van de gebruikers de broncode van het smart contract, waarna de code door een compiler speciaal voor het Ethereum-platform wordt gestuurd, waarmee bytecode voor de virtuele Ethereum-machine wordt verkregen. De resulterende bytecode wordt in een speciaal transactieveld geplaatst. Deze wordt gecertificeerd namens de account van de initiator. Vervolgens wordt deze transactie over het netwerk verspreid en wordt de smart contractcode geplaatst. De commissie voor de transactie en dus voor de uitvoering van het contract wordt afgetrokken van het saldo op de account van de initiator.
Elk smart contract bevat noodzakelijkerwijs zijn eigen constructor (van dit contract). Deze kan leeg zijn of inhoud bevatten. Nadat de constructor is uitgevoerd, wordt de account-ID van het smart contract aangemaakt, waarmee u munten kunt verzenden, bepaalde methoden van het smart contract kunt aanroepen, enz.
Ethereum-transactiestructuur
Om het duidelijker te maken, beginnen we met het bekijken van de structuur van een Ethereum-transactie en een voorbeeld van een smart contract-code.
Een Ethereum-transactie bestaat uit verschillende velden. Het eerste is nonce, een bepaald serienummer van de transactie gerelateerd aan de account zelf die de transactie distribueert en de auteur ervan is. Dit is nodig om dubbele transacties te onderscheiden, d.w.z. om uit te sluiten dat dezelfde transactie twee keer wordt geaccepteerd. Door gebruik te maken van een identificatiecode krijgt elke transactie een unieke hashwaarde.
Hierna komt een veld als dit: gas prijsDit is de prijs waartegen de basisvaluta Ethereum wordt omgezet in gas, dat wordt gebruikt om de uitvoering van het smart contract en de toewijzing van de virtuele machine-resource te betalen. Wat betekent dit?
Bij Bitcoin worden de kosten rechtstreeks betaald met de basisvaluta – Bitcoin zelf. Dit is mogelijk dankzij een eenvoudig mechanisme om ze te berekenen: we betalen strikt voor de hoeveelheid data die in de transactie is opgenomen. Bij Ethereum is de situatie ingewikkelder, omdat het erg moeilijk is om het transactievolume te baseren. Hier kan een transactie ook programmacode bevatten die op een virtuele machine wordt gestart, en elke bewerking op de virtuele machine kan een andere complexiteit hebben. Er zijn ook bewerkingen die geheugen toewijzen aan variabelen. Deze hebben hun eigen complexiteit, wat de betaling voor elke bewerking bepaalt.
De kosten van elke operatie in gasequivalent zullen constant zijn. Deze methode wordt specifiek ingevoerd om de constante kosten van elke operatie te bepalen. Afhankelijk van de netwerkbelasting verandert de gasprijs, d.w.z. de coëfficiënt waarmee de basisvaluta wordt omgezet in deze hulpeenheid om de commissie te betalen.
Er is nog een ander kenmerk van de transactie in Ethereum: de bytecode die deze bevat voor uitvoering in de virtuele machine wordt uitgevoerd totdat deze met een bepaald resultaat is voltooid (succes-mislukking) of totdat een bepaald aantal munten dat is toegewezen voor de betaling van de commissie is opgebruikt. Juist om te voorkomen dat alle munten van de rekening van de verzender worden uitgegeven aan de commissie in geval van een fout (bijvoorbeeld wanneer er een eeuwige cyclus in de virtuele machine is gestart), is het volgende veld beschikbaar: startgas (vaak aangeduid als gaslimiet) - Hiermee wordt het maximale aantal munten bepaald dat een verzender bereid is uit te geven om een bepaalde transactie te voltooien.
Het volgende veld heet bestemmingsadresHet adres van de ontvanger van de munten of het adres van een specifiek smart contract waarvan de methoden worden aangeroepen, wordt hier ingevoerd. Daarna komt het veld waarde, waar het bedrag aan munten wordt ingevoerd dat naar het bestemmingsadres wordt verzonden.
Vervolgens is er een interessant veld genaamd gegevens, waar de volledige structuur wordt ingevoerd. Dit is geen apart veld, maar een volledige structuur waarin de code voor de virtuele machine is gedefinieerd. Hier kunnen willekeurige gegevens worden geplaatst - hiervoor gelden aparte regels.
En het laatste veld heet handtekeningHet bevat tegelijkertijd zowel de elektronische handtekening van de auteur van deze transactie als de openbare sleutel die zal worden gebruikt om deze handtekening te verifiëren. Uit de openbare sleutel kunt u de account-ID van de verzender van deze transactie halen, dat wil zeggen, de unieke identificatie van de rekening van de verzender in het systeem zelf. We hebben de belangrijkste details over de transactiestructuur ontdekt.
Voorbeeld van smart contractcode in Solidity
Laten we nu eens nader naar het eenvoudigste smart contract kijken aan de hand van een voorbeeld.
contract Bank {
address owner;
mapping(address => uint) balances;
function Bank() {
owner = msg.sender;
}
function deposit() public payable {
balances[msg.sender] += msg.value;
}
function withdraw(uint amount) public {
if (balances[msg.sender] >= amount) {
balances[msg.sender] -= amount;
msg.sender.transfer(amount);
}
}
function getMyBalance() public view returns(uint) {
return balances[msg.sender];
}
function kill() public {
if (msg.sender == owner)
selfdestruct(owner);
}
}Hierboven ziet u een vereenvoudigde broncode die de munten van gebruikers kan bewaren en op verzoek kan teruggeven.
Er is dus een smart contractbank die de volgende functies vervult: het verzamelt munten op zijn saldo, dat wil zeggen, bij het bevestigen van een transactie en het plaatsen van een dergelijk smart contract wordt een nieuwe rekening aangemaakt, die munten op zijn saldo kan bevatten; het onthoudt gebruikers en de verdeling van munten tussen hen; het heeft verschillende methoden om saldi te beheren, dat wil zeggen, het is mogelijk om het saldo van de gebruiker aan te vullen, op te nemen en te controleren.
Laten we elke regel van de broncode doornemen. Dit contract heeft constante velden. Eén daarvan, met het adrestype, heet 'eigenaar'. Hier onthoudt het contract het adres van de gebruiker die dit smart contract heeft aangemaakt. Vervolgens is er een dynamische structuur die de correspondentie tussen gebruikersadressen en saldi opslaat.
Hierna volgt de Bank-methode – deze heeft dezelfde naam als het contract. Dit is dan ook de constructor. Hier krijgt de variabele-eigenaar het adres toegewezen van degene die dit smart contract op het netwerk heeft geplaatst. Dit is het enige wat er in deze constructor gebeurt. Dat wil zeggen dat msg in dit geval precies de data bevat die naar de virtuele machine is verzonden, samen met de transactie die de volledige code van dit contract bevat. Msg.sender is dus de auteur van deze transactie die deze code plaatst. Hij is de eigenaar van het smart contract.
Met de stortingsmethode kunt u een bepaald aantal munten via een transactie naar de contractrekening overmaken. In dit geval laat het smart contract deze munten na ontvangst op zijn saldo staan, maar registreert in de balansstructuur wie deze munten precies heeft verzonden, zodat het weet van wie ze zijn.
De volgende methode heet 'traw' en heeft één parameter nodig: het aantal munten dat iemand van deze bank wil opnemen. Hier wordt gecontroleerd of het saldo van de gebruiker die deze methode aanroept voldoende munten bevat om deze te versturen. Als er voldoende munten zijn, retourneert het smart contract dit aantal munten zelf aan de aanroeper.
Vervolgens komt de methode voor het controleren van het huidige saldo van de gebruiker. Degene die deze methode aanroept, wordt gebruikt om dit saldo in het smart contract op te vragen. Het is belangrijk om te weten dat de modifier van deze methode 'view' is. Dit betekent dat de methode zelf de variabelen van zijn klasse op geen enkele manier wijzigt en dat het in feite een 'read-only'-methode is. Er wordt geen aparte transactie aangemaakt om deze methode aan te roepen, er wordt geen commissie betaald en alle berekeningen worden lokaal uitgevoerd, waarna de gebruiker het resultaat ontvangt.
De kill-methode is nodig om de status van het smart contract te vernietigen. Hierbij wordt een extra controle uitgevoerd, namelijk of de aanroeper van deze methode de eigenaar van dit contract is. Zo ja, dan vernietigt het contract zichzelf en neemt de vernietigingsfunctie één parameter: de account-ID waarnaar het contract alle resterende munten op zijn saldo zal sturen. In dat geval gaan de resterende munten automatisch naar het adres van de contracteigenaar.
Hoe werkt een volledige Ethereum-node?
Laten we eens schematisch bekijken hoe dergelijke slimme contracten worden uitgevoerd op het Ethereum-platform en hoe een volledig netwerkknooppunt opereert.
Een volledige Ethereum-node moet minimaal vier modules hebben.
De eerste, zoals bij elk gedecentraliseerd protocol, is de P2P-netwerkmodule – een module voor netwerkverbinding en samenwerking met andere knooppunten, waar blokken, transacties en informatie over andere knooppunten worden uitgewisseld. Dit is een traditioneel onderdeel van alle gedecentraliseerde cryptovaluta.
Vervolgens hebben we een module voor het opslaan van blockchaingegevens, het verwerken ervan, het kiezen van een prioriteitstak, het toevoegen van blokken, het ontkoppelen van blokken, het controleren van deze blokken, enzovoort.
De derde module heet EVM (Ethereum Virtual Machine) - dit is virtuele machineDeze module ontvangt bytecode van een Ethereum-transactie. De module ontvangt de huidige status van een specifiek account en voert statuswijzigingen uit op basis van de ontvangen bytecode. De virtuele machineversie op elk netwerkknooppunt moet identiek zijn. De berekeningen die op elk Ethereum-knooppunt worden uitgevoerd, zijn identiek, maar ze vinden asynchroon plaats: sommige knooppunten verifiëren en accepteren de transactie eerst en voeren alle code daarin uit, terwijl andere dit later doen. Wanneer een transactie wordt aangemaakt, wordt deze dus naar het netwerk verspreid, accepteren de knooppunten deze en op het moment van verificatie wordt, net zoals Bitcoin Script in Bitcoin wordt uitgevoerd, de bytecode van de virtuele machine hier uitgevoerd.
Een transactie wordt als geverifieerd beschouwd als alle code die erin zit is uitgevoerd, een nieuwe status van een bepaalde rekening is gegenereerd en opgeslagen totdat duidelijk is of deze transactie al dan niet is toegepast. Als de transactie is toegepast, wordt deze status niet alleen als uitgevoerd beschouwd, maar ook als relevant. Er is een database die de status van elke rekening voor elk knooppunt in het netwerk opslaat. Omdat alle berekeningen op dezelfde manier worden uitgevoerd en de status van de blockchain hetzelfde is, zal de database met de statussen van alle rekeningen ook voor elk knooppunt hetzelfde zijn.
Mythen en beperkingen van slimme contracten
Wat betreft de beperkingen die bestaan voor Ethereum-achtige smart contractplatforms, kunnen de volgende worden genoemd:
- code-uitvoering;
- geheugen toewijzen;
- blockchain-gegevens;
- betalingen verzenden;
- nieuw contract aanmaken;
- andere contracten aanroepen.
Laten we eens kijken naar de beperkingen die aan de virtuele machine worden opgelegd en dienovereenkomstig enkele mythes over smart contracts ontkrachten. Op een virtuele machine, die niet alleen op Ethereum kan staan, maar ook op vergelijkbare platforms, kun je werkelijk willekeurige logische bewerkingen uitvoeren. Dat wil zeggen, code schrijven en deze wordt daar uitgevoerd. Je kunt bovendien geheugen toewijzen. De commissie wordt echter apart betaald voor elke bewerking en voor elke extra toegewezen geheugeneenheid.
Vervolgens kan de virtuele machine gegevens uit de blockchaindatabase lezen om deze te gebruiken als trigger voor de uitvoering van een smart contract. De virtuele machine kan transacties aanmaken en verzenden, nieuwe contracten creëren en methoden aanroepen van andere smart contracts die al op het netwerk zijn gepubliceerd: bestaand, beschikbaar, enz.
De meest voorkomende mythe is dat smart contracts voor Ethereum informatie van elke internetbron naar eigen inzicht kunnen gebruiken. De waarheid is dat een virtuele machine geen netwerkverzoek kan sturen naar een externe informatiebron op het internet. Dat wil zeggen dat het onmogelijk is om een smart contract te schrijven dat waarde verdeelt tussen gebruikers op basis van bijvoorbeeld het weer, wie een kampioenschap heeft gewonnen, of welk ander incident zich buiten heeft voorgedaan, omdat informatie over deze incidenten simpelweg niet bestaat in de database van het platform zelf. Dat wil zeggen, er staat niets over in de blockchain. Als het daar niet voorkomt, kan de virtuele machine deze gegevens niet als trigger gebruiken.
Nadelen van Ethereum
Laten we de belangrijkste op een rijtje zetten. Het eerste nadeel is dat er enkele moeilijkheden zijn bij het ontwerpen, ontwikkelen en testen van smart contracts in Ethereum (Ethereum gebruikt de programmeertaal Solidity om smart contracts te schrijven). De praktijk leert dat een zeer groot percentage van alle fouten te wijten is aan de menselijke factor. Dit geldt ook voor reeds geschreven smart contracts in Ethereum, die een gemiddelde of hogere complexiteit hebben. Terwijl de kans op een fout laag is bij eenvoudige smart contracts, komen er bij complexe smart contracts vaak fouten voor die leiden tot diefstal van geld, blokkering, onverwachte vernietiging van smart contracts, enzovoort. Veel van dergelijke gevallen zijn al bekend.
Het tweede nadeel is dat de virtuele machine zelf niet perfect is, omdat deze ook door mensen is geschreven. Hij kan willekeurige commando's uitvoeren, en daar schuilt de kwetsbaarheid: een reeks commando's kan op een bepaalde manier worden geconfigureerd, wat tot onvoorziene gevolgen leidt. Dit is een zeer complex gebied, maar er zijn al verschillende studies die aantonen dat deze kwetsbaarheden aanwezig zijn in de huidige versie van het Ethereum-netwerk en dat ze kunnen leiden tot het falen van veel smart contracts.
Een andere grote moeilijkheid, die als een nadeel kan worden beschouwd, is dat het praktisch of technisch mogelijk is om tot de conclusie te komen dat als je de bytecode van een contract compileert dat op een virtuele machine wordt uitgevoerd, je een specifieke volgorde van bewerkingen kunt definiëren. Wanneer deze bewerkingen samen worden uitgevoerd, zullen ze de virtuele machine zwaar belasten en onevenredig vertragen in verhouding tot de commissie die voor de uitvoering van deze bewerkingen werd betaald.
In het verleden was er al zo'n periode in de ontwikkeling van Ethereum, waarin veel mensen die de werking van de virtuele machine tot in detail begrepen, dergelijke kwetsbaarheden ontdekten. Transacties leverden weliswaar een zeer kleine commissie op, maar vertraagden praktisch de werking van het hele netwerk. Deze problemen zijn zeer moeilijk op te lossen, omdat ze ten eerste bepaald moeten worden, ten tweede de prijs voor deze bewerkingen moeten worden aangepast en ten derde een hard fork moeten worden uitgevoerd, wat betekent dat alle netwerkknooppunten moeten worden bijgewerkt naar een nieuwe versie van de software en deze wijzigingen vervolgens gelijktijdig moeten worden geactiveerd.
Wat Ethereum betreft, is er veel onderzoek gedaan en veel praktische ervaring opgedaan: zowel positief als negatief. Toch zijn er nog steeds moeilijkheden en kwetsbaarheden die op de een of andere manier moeten worden aangepakt.
Nu is het thematische gedeelte van het artikel afgerond. Laten we verdergaan met de vragen die vaak gesteld worden.
Veel gestelde vragen
— Als alle partijen bij een bestaand smart contract de voorwaarden willen wijzigen, kunnen ze dat smart contract dan annuleren met behulp van multi-signature en vervolgens een nieuw smart contract aanmaken met de bijgewerkte uitvoeringsvoorwaarden?
Het antwoord hierop is tweeledig. Waarom? Enerzijds omdat een smart contract één keer wordt gedefinieerd en geen wijzigingen impliceert, en anderzijds omdat het vooraf geschreven logica kan hebben die voorziet in een volledige of gedeeltelijke wijziging van bepaalde voorwaarden. Dat wil zeggen, als je iets in je smart contract wilt wijzigen, moet je vooraf de voorwaarden vastleggen waaronder je deze voorwaarden kunt bijwerken. Alleen op zo'n voorzichtige manier kun je een contractupdate organiseren. Maar ook hier kun je in de problemen komen: maak je een fout en krijg je een bijbehorende kwetsbaarheid. Daarom moeten dergelijke zaken zeer grondig en zorgvuldig worden ontworpen en getest.
— En wat als de bemiddelaar samenspant met een van de partijen: escrow of smart contract? Is een bemiddelaar vereist bij een smart contract?
Een bemiddelaar is niet vereist in een smart contract. Het kan zelfs zo zijn dat deze niet bestaat. Als de bemiddelaar in het geval van escrow samenspant met een van de partijen, verliest deze regeling plotseling al haar waarde. Daarom worden bemiddelaars zo gekozen dat ze door alle betrokken partijen tegelijkertijd worden vertrouwd. Je zult dus geen munten overmaken naar een multisignature-adres met een bemiddelaar die je niet vertrouwt.
— Is het mogelijk om in één Ethereum-transactie veel verschillende tokens van jouw adres naar verschillende doeladressen over te zetten, zoals beursadressen waar deze tokens worden verhandeld?
Dit is een goede vraag en het gaat over het Ethereum-transactiemodel en het verschil met het Bitcoin-model. En dat verschil is fundamenteel. Als je in het Ethereum-transactiemodel simpelweg munten overmaakt, worden ze alleen van het ene adres naar het andere overgemaakt, zonder wisselgeld, alleen een specifiek bedrag dat je hebt opgegeven. Met andere woorden, dit is geen model van onbesteedde outputs (UTXO), maar een model van rekeningen en bijbehorende saldi. Theoretisch is het mogelijk om meerdere tokens tegelijk in één transactie te versturen als je een slim smart contract schrijft, maar je zult nog steeds veel transacties moeten uitvoeren, een contract moeten aanmaken, vervolgens tokens en munten ernaar moeten overmaken en vervolgens de bijbehorende methode moeten aanroepen. Dit vereist inspanning en tijd, en in de praktijk werkt het daarom niet zo en worden alle betalingen in Ethereum in afzonderlijke transacties gedaan.
— Eén van de mythes over het Ethereum-platform is dat het onmogelijk is om dergelijke omstandigheden te beschrijven die afhankelijk zijn van gegevens van een externe internetbron. Wat moeten we dan doen?
De oplossing is dat het smart contract zelf kan voorzien in een of meer zogenaamde vertrouwde orakels, die gegevens verzamelen over de stand van zaken in de buitenwereld en deze via speciale methoden naar smart contracts verzenden. Het contract zelf beschouwt de gegevens die het van vertrouwde partijen heeft ontvangen als waar. Voor een grotere betrouwbaarheid wordt simpelweg een grote groep orakels geselecteerd en wordt het risico op collusie geminimaliseerd. Het contract zelf houdt mogelijk geen rekening met gegevens van orakels die de meerderheid tegenspreken.
Dit onderwerp is het onderwerp van een van de lezingen van de online cursus over Blockchain — “'.
Bron: www.habr.com
