Inleiding tot smart contracts

In dit artikel bespreken we wat smart contracts zijn, welke types er zijn, leren we verschillende smart contract platforms kennen, hun kenmerken, en bespreken we hoe ze werken en welke voordelen ze met zich mee kunnen brengen. Deze informatie is bijzonder nuttig voor lezers die nog niet helemaal bekend zijn met het onderwerp smart contracts, maar die een beter begrip willen krijgen.

Gewoon contract vs. smart contract

Voordat we in de details duiken, laten we het verschil bekijken tussen een gewoon contract, dat op papier staat, en een smart contract, dat digitaal is.

Hoe werkte het voordat smart contracts bestonden? Stel je een groep mensen voor die bepaalde regels en voorwaarden willen vaststellen voor de distributie van waarde, en een mechanismus willen creëren om ervoor te zorgen dat deze distributie volgens die regels en voorwaarden plaatsvindt. Ze kwamen dan samen, maakten een document waarin ze hun identificerende gegevens, voorwaarden, betrokken waarde, de datum en hun handtekeningen vastlegden. Dit contract werd ook geverifieerd door een vertrouwde derde partij, zoals een notaris. Vervolgens gingen deze mensen elk hun eigen weg met hun papieren exemplaar van het contract en begonnen ze handelingen te verrichten die mogelijk niet overeenkwamen met het contract zelf, wat betekent dat ze iets deden, terwijl op papier stond dat ze iets heel anders moesten doen. Hoe lost men deze situatie op? In feite moet een van de deelnemers aan de groep dit document pakken, bewijsstukken verzamelen, naar de rechtbank gaan en ervoor zorgen dat er overeenstemming is tussen het contract en de feitelijke handelingen. Het kan vrij moeilijk zijn om eerlijke uitvoering van dit contract te bereiken, wat kan leiden tot vervelende gevolgen.

Wat kunnen we zeggen over smart contracts? Ze combineren de mogelijkheid om de voorwaarden van het contract op te stellen met een mechanismus voor strikte uitvoering. Als de voorwaarden zijn vastgesteld en de bijbehorende transactie of verzoek is ondertekend, kan er na acceptatie van dit verzoek of deze transactie niks meer gewijzigd worden aan de voorwaarden of invloed worden uitgeoefend op hun uitvoering.

Er is één validator of een geheel netwerk aanwezig, evenals een database die alle smart contracts opslaat die in strikte chronologische volgorde zijn uitgevoerd. Het is ook belangrijk dat deze database alle voorwaarde-triggers voor de uitvoering van het smart contract bevat. Bovendien moet deze rekening houden met de waarde waarvan de distributie in het contract is beschreven. Als dit om een bepaalde digitale valuta gaat, moet deze database deze ook registreren.

Met andere woorden, de validators van smart contracts moeten toegang hebben tot alle gegevens waarmee het smart contract werkt. Bijvoorbeeld, één database moet worden gebruikt om tegelijkertijd digitale valuta, gebruikersbalansen, gebruikerstransacties en tijdstempels bij te houden. In het smart contract kan een voorwaarde bijvoorbeeld de balans van een gebruiker in een bepaalde valuta zijn, het verstrijken van een bepaalde tijd of het feit dat een transactie heeft plaatsgevonden, maar niet meer dan dat.

Definitie van een smart contract

De term werd voor het eerst geïntroduceerd door onderzoeker Nick Szabo in 1994 en werd gedocumenteerd in 1997 in een artikel dat het idee van smart contracts beschrijft.

Smart contracts impliceren dat er enige automatisering van waarde-distributie plaatsvindt, die alleen kan afhankelijk zijn van vooraf ingestelde voorwaarden. In de eenvoudigste variant lijkt dit op een contract met strikt gedefinieerde voorwaarden, dat door bepaalde partijen is ondertekend.

Smart contracts zijn bedoeld om het vertrouwen in derde partijen te minimaliseren. Soms wordt het besluitvormingscentrum volledig uitgesloten, waar alles van afhankelijk is. Bovendien is het voor dergelijke contracten gemakkelijker om audits uit te voeren. Dit is een gevolg van bepaalde ontwerpeisen van het systeem, maar meestal begrijpen we onder smart contracts een gedecentraliseerde omgeving en de aanwezigheid van functies die het voor iedereen mogelijk maken om de database te analyseren en een volledige audit van de uitvoering van de contracten uit te voeren. Op deze manier wordt bescherming tegen retroactieve wijzigingen in gegevens gegarandeerd, wat zou leiden tot wijzigingen in de uitvoering van het contract zelf. De digitalisering van de meeste processen bij het maken en implementeren van een smart contract vereenvoudigt vaak de technologie en de kosten van hun uitvoering.

Een eenvoudig voorbeeld - Escrow service

Laten we een heel eenvoudig voorbeeld bekijken. Dit zal helpen om de functionele mogelijkheden van smart contracts beter te begrijpen, evenals om beter te begrijpen in welke situaties ze moeten worden toegepast.

Dit kan ook worden gerealiseerd met behulp van Bitcoin, hoewel Bitcoin op dit moment nog moeilijk als een volwaardige platform voor smart contracts kan worden beschouwd. Dus, we hebben een koper en een webwinkel. De koper wil een monitor kopen in deze winkel. In het eenvoudigste geval plaatst de koper een bestelling en verstuurt de betaling, en de webwinkel accepteert deze, bevestigt deze, waarna het product wordt verzonden. In deze situatie is er echter een grote mate van vertrouwen nodig - de koper moet de webwinkel volledig vertrouwen voor de prijs van de monitor. Aangezien de webwinkel mogelijk een lage reputatie heeft in de ogen van de koper, bestaat er het risico dat de winkel om een of andere reden weigert de service te bieden en het product niet naar de koper verzendt na de ontvangst van de betaling. Daarom vraagt de koper zich af (en de webwinkel vraag zich ook af) wat in dit geval kan worden toegepast om dergelijke risico's te minimaliseren en dergelijke transacties betrouwbaarder te maken.

In het geval van Bitcoin kan de koper en verkoper de mogelijkheid hebben om onafhankelijk van elkaar een mediator te kiezen. Er zijn veel mensen die zich bezighouden met het oplossen van geschillen. En onze deelnemers kunnen uit een algemene lijst van mediators degene kiezen die ze beiden vertrouwen. Samen creëren ze een multisignature adres 2 van 3, waar er drie sleutels zijn en twee handtekeningen van enige twee sleutels nodig zijn om munten van dit adres uit te geven. Eén sleutel zal toebehoren aan de koper, de tweede aan de webwinkel, en de derde aan de mediator. En op dit multisignature adres zal de koper het bedrag sturen dat nodig is voor de betaling van de monitor. Nu, wanneer de verkoper ziet dat het geld enige tijd is geblokkeerd op het multisignature adres, dat afhankelijk is van hem, kan hij met vertrouwen de monitor per post verzenden.

Vervolgens ontvangt de koper het pakket, inspecteert hij het product en neemt hij een beslissing over de uiteindelijke aankoop. Hij kan volledig tevreden zijn met de geboden service en de transactie met zijn sleutel ondertekenen, waarbij hij de munten van het multisignatureadres naar de verkoper overmaakt, of hij kan ergens ontevreden over zijn. In dat geval neemt hij contact op met de mediator om een alternatieve transactie op te stellen die deze munten anders zal verdelen.

Stel dat de monitor een beetje bekrast is aangekomen en er geen kabel bij zat om deze op de computer aan te sluiten, terwijl op de website van de webwinkel stond dat de kabel inbegrepen moest zijn. Dan verzamelt de koper bewijs dat nodig is om de mediator te tonen dat hij in deze situatie is bedrogen: hij maakt screenshots van de website, maakt een foto van de bon van de post, maakt een foto van de krassen op de monitor en laat zien dat het zegel is verbroken en de kabel is verwijderd. De webwinkel verzamelt op zijn beurt ook bewijs en stuurt dit door naar de mediator.

De mediator is geïnteresseerd in het tegelijkertijd tevredenstellen van de frustratie van de koper en de belangen van de webwinkel (later wordt het duidelijk waarom). Hij stelt een transactie op waarin de munten van het multisignatureadres in bepaalde proporties worden besteed tussen de koper, de webwinkel en de mediator, aangezien hij een deel voor zijn werk als beloning neemt. Stel 90% van het totale bedrag gaat naar de verkoper, 5% naar de mediator en 5% als compensatie voor de koper. Deze transactie ondertekent de mediator met zijn sleutel, maar kan nog niet worden toegepast omdat er twee handtekeningen voor nodig zijn en er nu slechts één is. Hij stuurt deze transactie naar zowel de koper als de verkoper. Als ten minste één van hen tevreden is met deze herverdeling van de munten, wordt de transactie getekend en verspreid in het netwerk. Voor de validatie is het voldoende dat één van de deelnemers aan de transactie akkoord gaat met het voorstel van de mediator.

Het is belangrijk om aanvankelijk een mediator te kiezen die door beide partijen vertrouwd wordt. In dat geval zal hij onafhankelijk handelen van de belangen van de één of de ander en de situatie objectief beoordelen. Als de mediator echter geen verdelingsoptie biedt die minstens één van de deelnemers tevredenstelt, kunnen de koper en de online winkel, in onderling overleg, de munten naar een nieuw multisignature adres overdragen, met beide handtekeningen. Het nieuwe multisignature adres zal worden aangemaakt met een andere mediator, die mogelijk competenter is in de kwestie en een betere optie aanbiedt.

voorbeeld met een studentenflat en een koelkast

Laten we een complexer voorbeeld bekijken dat de mogelijkheden van een smart contract duidelijker weergeeft.

Stel je voor dat er drie jongens zijn die onlangs in dezelfde kamer in een studentenflat zijn gaan wonen. Zij zijn alle drie geïnteresseerd in het kopen van een koelkast voor hun kamer, die ze samen zullen gebruiken. Eén van hen heeft zich aangemeld om het benodigde bedrag voor de aankoop van de koelkast bij elkaar te brengen en met de verkoper te onderhandelen. Ze kennen elkaar echter nog maar kort en er is niet genoeg vertrouwen tussen hen. Het is duidelijk dat twee van hen risico lopen door geld aan de derde te geven. Bovendien moeten ze tot een overeenstemming komen over de keuze van de verkoper.

Ze kunnen gebruikmaken van een escrow-service, dat wil zeggen een mediator kiezen die de uitvoering van de transactie controleert en eventuele geschillen oplost als die zich voordoen. Dan stellen ze, in onderling overleg, een smart contract op en leggen ze bepaalde voorwaarden vast.

De eerste voorwaarde is dat voor een bepaalde tijd, laten we zeggen binnen een week, drie betalingen van bepaalde adressen voor een bepaald bedrag op de betreffende smart contract-account moeten worden ontvangen. Als dit niet gebeurt, stopt het smart contract met uitvoeren en worden de munten aan alle deelnemers teruggegeven. Als de voorwaarde echter wordt vervuld, worden de waarden voor de identificaties van de verkoper en de mediator ingesteld, en wordt gecontroleerd of alle deelnemers akkoord gaan met de keuze van de verkoper en de mediator. Wanneer aan alle voorwaarden is voldaan, zullen de fondsen verder worden overgemaakt naar de opgegeven adressen. Deze aanpak kan deelnemers beschermen tegen fraude van elke kant en sluit in principe de noodzaak van vertrouwen uit.

We zien aan dit voorbeeld het principe dat de mogelijkheid om stap voor stap parameters voor de uitvoering van elke voorwaarde in te stellen, het mogelijk maakt om systemen van elke complexiteit en diepte van geneste niveaus te creëren. Bovendien kan in het smart contract eerst de eerste voorwaarde worden gedefinieerd, en pas na de uitvoering ervan kunnen de parameters voor de volgende voorwaarde worden ingesteld. Met andere woorden, formeel wordt de voorwaarde vastgelegd, terwijl de parameters ervan al tijdens de uitvoering kunnen worden ingesteld.

Classificatie van smart contracts

Voor classificatie kunnen verschillende groepen criteria worden gedefinieerd. Op dit moment zijn er echter vier criteria die relevant zijn voor de ontwikkeling van technologieën.

Smart contracts kunnen worden onderscheiden op basis van de uitvoeringsomgeving, die centraal of gedecentraliseerd kan zijn. In het geval van decentralisatie hebben we veel meer onafhankelijkheid en fouttolerantie bij de uitvoering van smart contracts.

Ze kunnen ook worden onderscheiden op basis van het proces van instellen en uitvoeren van voorwaarden: ze kunnen willekeurig programmeerbaar, beperkt of vooraf ingesteld zijn, dat wil zeggen strikt getypeerd. Wanneer er op het platform van smart contracts slechts 4 bepaalde smart contracts bestaan, kunnen de parameters ervoor op willekeurige wijze worden ingesteld. Dienovereenkomstig is het veel eenvoudiger om ze in te stellen: we kiezen het contract uit de lijst en geven de parameters door.

Er zijn geautomatiseerde slimme contracten die zichzelf uitvoeren bij het verstrijken van bepaalde voorwaarden, en er zijn contracten waarbij de voorwaarden wel zijn vastgesteld, maar het platform deze niet automatisch controleert; in dat geval moeten ze afzonderlijk worden geïnitieerd.

Bovendien verschillen slimme contracten in hun privacy-niveau. Ze kunnen volledig openbaar zijn, gedeeltelijk of volledig vertrouwelijk. Het laatste betekent dat externe waarnemers de voorwaarden van de slimme contracten niet kunnen zien. Het onderwerp privacy is echter zeer uitgebreid en beter apart van dit artikel te bespreken.

Hieronder zullen we dieper ingaan op de eerste drie criteria om meer helderheid te geven over het huidige onderwerp.

Slimme contracten naar uitvoeringsomgeving

Wat betreft de uitvoeringsomgeving onderscheiden we gecentraliseerde en gedecentraliseerde slimme contractplatforms. Bij gecentraliseerde digitale contracten wordt één service gebruikt, waar slechts één validator bestaat en er kan een centrale back-up- en herstelservice zijn die ook gecentraliseerd wordt beheerd. Er is één database die alle benodigde informatie opslaat voor het vaststellen van de voorwaarden van het slimme contract en het toekennen van de waarde die in deze database van de service wordt vastgelegd. Een dergelijke gecentraliseerde service heeft een cliënt die door middel van bepaalde aanvragen de voorwaarden stelt en gebruikmaakt van dergelijke contracten. Aangezien het platform gecentraliseerd is, kunnen de authenticatiemechanismen minder betrouwbaar zijn dan in de cryptocurrency-wereld.

Als voorbeeld kunnen we mobiele aanbieders (verschillende mobiele operators) nemen. Stel dat een bepaalde operator het verkeer op zijn servers gecentraliseerd bijhoudt, dat in verschillende formaten kan worden verzonden, bijvoorbeeld: als spraakoproepen, SMS-verzending, mobiel internetverkeer, en volgens verschillende normen, en ook de middelen op de gebruikersbalans bijhoudt. Dienovereenkomstig kan de mobiele provider contracten opstellen voor het bijhouden van de geleverde diensten en hun betaling met verschillende voorwaarden. In dat geval kunnen voorwaarden eenvoudig worden ingesteld zoals “stuur een SMS met een bepaalde code naar een bepaald nummer en ontvang deze voorwaarden voor de verdeling van verkeer.”

Hier is nog een voorbeeld: traditionele banken met uitgebreide internetbankierfunctionaliteit en eenvoudige contracten zoals terugkerende betalingen, automatische conversie van binnenkomende betalingen, automatische renteaflossingen op de opgegeven rekening, enzovoort.

In het geval van smart contracts met een gedecentraliseerde uitvoeringsomgeving hebben we een groep validators. Idealiter kan iedereen validator worden. Door het databasynchronisatieprotocol en het bereiken van consensus, hebben we een gezamenlijke database die nu alle transacties met strikt gedefinieerde contracten opslaat, in plaats van enige soort voorwaardelijke aanvragen waarvan de formaten vaak veranderen en voor welke er geen open specificatie bestaat. Hier bevatten transacties instructies voor de uitvoering van het contract volgens de strikte specificatie. Deze specificatie is open en, derhalve, kunnen de gebruikers van het platform de smart contracts auditen en valideren. Hier zien we dat gedecentraliseerde platforms superieur zijn aan gecentraliseerde platforms op het gebied van onafhankelijkheid en fouttolerantie, maar dat hun ontwerp en onderhoud veel complexer zijn.

Smart contracts op basis van hoe voorwaarden worden gesteld en uitgevoerd.

Laten we nu nader bekijken hoe smart contracts kunnen verschillen in de manier van het stellen en uitvoeren van voorwaarden. We richten ons hier op smart contracts die willekeurig programmeerbaar en Turing-compleet zijn. Een Turing-compleet smart contract maakt het mogelijk om vrijwel elke algoritme als voorwaarde voor de uitvoering van het contract te stellen: het definiëren van lussen, bepaalde probabiliteitsberekeningen en dergelijke — tot zelfs eigen algoritmen voor digitale handtekeningen. In dit geval wordt verwezen naar echte willekeurige logica.

Daarnaast zijn er ook willekeurige smart contracts, maar niet Turing-compleet. Hier vallen Bitcoin en Litecoin met hun script onder. Dit betekent dat je in willekeurige volgorde alleen bepaalde functies kunt gebruiken, maar dat je geen lussen of eigen algoritmen kunt schrijven.

Bovendien zijn er smart contract-platforms die vooraf geïnstalleerde smart contracts implementeren. Hiervoor behoren Bitshares en Steemit. Bitshares heeft een scala aan smart contracts voor handel, accountbeheer, en het beheer van het platform en zijn instellingen. Steemit is een vergelijkbaar platform, maar is gericht op bloggen, dat wil zeggen, het slaat content op en verwerkt deze op een gedecentraliseerde manier.

Volledige Turing-complete contracten omvatten het Ethereum-platform en RootStock, dat nog in ontwikkeling is. Daarom zullen we verder ingaan op het Ethereum smart contract-platform.

Smart contracts op basis van initiatie

Smart contracts kunnen ook minimaal in twee groepen worden onderverdeeld op basis van initiatie: geautomatiseerde en handmatige (niet-geautomatiseerde) contracten. Geautomatiseerde smart contracts vereisen geen extra transacties of kosten voor elke uitvoering, zolang aan alle bekende parameters en voorwaarden is voldaan. Het platform heeft alle gegevens om te berekenen hoe het smart contract zal eindigen. De logica is niet willekeurig, maar vooraf gedefinieerd, en alles is voorspelbaar. Dit betekent dat men de moeilijkheidsgraad van de uitvoering van het smart contract van tevoren kan inschatten, een constante commissie kan gebruiken, en alle processen van de uitvoering verliepen efficiënter.

Voor smart contracts die willekeurig kunnen worden geprogrammeerd, is de uitvoering niet geautomatiseerd. Voor het initiëren van een dergelijk smart contract moet bij elke stap een nieuwe transactie worden aangemaakt om de volgende fase van de uitvoering of de volgende methode van het smart contract aan te roepen, de bijbehorende kosten te betalen en te wachten op transactieconfirmatie. De uitvoering kan succesvol of niet succesvol zijn, omdat de code van het smart contract willekeurig is en er onvoorspelbare problemen kunnen optreden, zoals een oneindige lus, een tekort aan parameters en argumenten, onverwerkte uitzonderingen, enzovoort.

Accounts in Ethereum

Soorten Ethereum-accounts

Laten we eens bekijken welke soorten accounts er op het Ethereum-platform kunnen zijn. Er zijn slechts twee soorten accounts en verder geen opties. Het eerste type heet gebruikersaccount, het tweede is het contractaccount. Laten we de verschillen eens nader bekijken.

Een gebruikersaccount wordt uitsluitend beheerd met een persoonlijke elektronische handtekening sleutel. De eigenaar van het account genereert zijn eigen sleutelpaar voor elektronische handtekening volgens het ECDSA-algoritme (Elliptic Curve Digital Signature Algorithm). De toestand van dit account kan alleen worden gewijzigd door transacties die met deze sleutel zijn ondertekend.

Voor het smart contract-account is er een aparte logica. Het kan alleen worden beheerd met behulp van vooraf gedefinieerde programmatuur die het gedrag van het smart contract volledig bepaald: hoe het zijn munten zal beheren onder bepaalde omstandigheden, op initiatief van welke gebruiker en onder welke aanvullende voorwaarden deze munten zullen worden verspreid. Als bepaalde situaties niet door de ontwikkelaars in de programmatuur zijn voorzien, kunnen er problemen ontstaan. Bijvoorbeeld, het smart contract kan een bepaalde status bereiken waarin het geen verdere uitvoering van welke gebruiker dan ook accepteert. In dat geval kunnen de munten feitelijk bevroren raken, omdat het smart contract geen uitweg uit deze toestand biedt.

Hoe worden accounts in Ethereum aangemaakt

In het geval van een gebruikersaccount genereert de eigenaar zelf een sleutelpaar volgens ECDSA. Het is belangrijk op te merken dat Ethereum dezelfde algoritme voor elektronische handtekening en dezelfde elliptische kromme gebruikt als Bitcoin, maar het adres wordt anders berekend. Hier wordt het resultaat van dubbele hashing, zoals in Bitcoin, niet gebruikt, maar vindt er een enkele hashing plaats met de Keccak-functie op een lengte van 256 bits. Van de verkregen waarde worden de laagste bits afgeknipt, namelijk de 160 laagste bits van de uitvoer van de hashfunctie. Uiteindelijk krijgen we een adres in Ethereum. Het neemt feitelijk 20 bytes in beslag.

Laten we opmerken dat de accountidentificator in Ethereum in hex wordt gecodeerd zonder checksum, in tegenstelling tot Bitcoin en veel andere systemen, waar het adres in een 58 basis getalsysteem met toevoeging van een checksum wordt gecodeerd. Dit betekent dat je voorzichtig moet omgaan met accountidentificatoren in Ethereum: zelfs één fout in de identificatie zal gegarandeerd leiden tot het verlies van munten.

Er is een belangrijke eigenschap en dat is dat de gebruikersaccount op het niveau van de gezamenlijke database wordt aangemaakt op het moment dat hij de eerste inkomende betaling accepteert.

Voor het aanmaken van een smart contract-account wordt een totaal andere aanpak gehanteerd. Eerst schrijft een van de gebruikers de broncode voor het smart contract, waarna de code via een speciale compiler voor het Ethereum-platform wordt geleid, wat bytecode oplevert voor de eigen Ethereum Virtuele Machine. De verkregen bytecode wordt in een speciaal veld van de transactie geplaatst. Deze wordt ondertekend namens het initiatorsaccount. Vervolgens wordt deze transactie in het netwerk verspreid en plaatst de code van het smart contract. De kosten voor het uitvoeren van de transactie en, dienovereenkomstig, voor de uitvoering van het contract worden van het saldo van het initiatorsaccount afgetrokken.

Elk smart contract bevat noodzakelijkerwijs zijn eigen constructor (van dit contract). Deze kan leeg zijn of inhoud hebben. Nadat de constructor is uitgevoerd, wordt de accountidentificator van het smart contract aangemaakt, die gebruikt kan worden om munten te verzenden, bepaalde methoden van het smart contract aan te roepen, enz.

Structuur van een Ethereum-transactie

Om het begrijpelijker te maken, beginnen we met het onderzoeken van de structuur van een Ethereum-transactie en een voorbeeld van de code van een smart contract.

Een Ethereum-transactie bestaat uit verschillende velden. Het eerste is nonce - dit is een bepaalde volgnummer van de transactie met betrekking tot het account dat het verspreidt en de auteur ervan is. Dit is nodig om duplicaten van transacties te onderscheiden, om het geval uit te sluiten waar dezelfde transactie twee keer wordt geaccepteerd. Dankzij de toepassing van de identificatie heeft elke transactie een unieke hashwaarde.

Vervolgens volgt een veld zoals gasprijsHier wordt de prijs opgegeven waarop de basisvaluta Ethereum wordt geconverteerd in gas, dat wordt gebruikt voor het betalen van de uitvoering van smart contracts en het toewijzen van middelen van de virtuele machine. Wat betekent dit?

In Bitcoin worden de vergoedingen rechtstreeks betaald met de basisvaluta — de Bitcoin zelf. Dit is mogelijk dankzij een eenvoudig mechanisme voor hun berekening: we betalen strikt op basis van de hoeveelheid gegevens die in de transactie zit. In Ethereum is de situatie complexer, omdat het erg moeilijk is om op de hoeveelheid gegevens van de transactie te vertrouwen. Hier kan de transactie ook programmatuur bevatten die op de virtuele machine wordt uitgevoerd, en elke operatie van de virtuele machine kan een verschillende complexiteit hebben. Er zijn ook bewerkingen die geheugen toewijzen voor variabelen. Deze zullen hun eigen complexiteit hebben, waarvan de vergoeding voor elke operatie afhankelijk zal zijn.

De kosten van elke operatie in termen van gas zullen constant zijn. Dit is speciaal geïntroduceerd om de constante kosten van elke operatie te bepalen. Afhankelijk van de belasting van het netwerk zal de gasprijs veranderen, dat wil zeggen de coefficient, waarmee de basisvaluta wordt geconverteerd in deze hulpeenheid voor het betalen van vergoedingen.

Er is nog een bijzondere eigenschap van een transactie in Ethereum: de bytecode die het bevat voor uitvoering in de virtuele machine, zal worden uitgevoerd totdat het eindigt met een resultaat (succes of falen) of totdat een bepaald aantal munten dat bestemd is voor het betalen van de vergoeding op is. Dit wordt gedaan om te voorkomen dat wegens een fout alle munten op het account van de verzender aan de vergoeding worden uitgegeven (bijvoorbeeld wanneer er een oneindige lus in de virtuele machine is gestart), daarom bestaat er het volgende veld — start gas (dit wordt vaak gaslimiet genoemd) — het bepaalt het maximale bedrag aan munten dat de verzender bereid is uit te geven voor de uitvoering van een bepaalde transactie.

Het volgende veld wordt genoemd bestemmingsadres. Hier wordt het adres van de ontvanger van de munten of het adres van een specifiek smart contract ingevuld, waarvan de methoden zullen worden aangeroepen. Na dit volgt het veld value, waarin het bedrag aan munten wordt ingevuld dat naar het bestemmingsadres wordt gestuurd.

Daarna bevindt zich een interessant veld genaamd data, waar een hele structuur in past. Dit is geen apart veld, maar een hele structuur waarin de code voor de virtuele machine wordt gedefinieerd. Hier kunnen willekeurige gegevens worden geplaatst — hiervoor bestaan aparte regels.

En het laatste veld wordt genoemd handtekening. Het bevat zowel de elektronische handtekening van de auteur van deze transactie als de publieke sleutel die deze handtekening zal controleren. Vanuit de publieke sleutel kan de identificatie van het account van de verzender van deze transactie worden verkregen, dat wil zeggen het account van de verzender uniek identificeren in het systeem zelf. Wat de structuur van de transactie betreft, hebben we het belangrijkste vastgesteld.

Voorbeeld van de Smart Contract-code in Solidity

Laten we nu eens iets dieper ingaan op het eenvoudigste smart contract 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);
    }
}

Bovenstaand is een vereenvoudigde broncode die de munten van gebruikers kan vasthouden en deze op verzoek kan teruggeven.

Dus, er is een smart contract Bank dat de volgende functies uitvoert: het verzamelt munten op zijn balans, dat wil zeggen, bij bevestiging van de transactie en de plaatsing van een dergelijk smart contract wordt er een nieuw account aangemaakt dat munten op zijn balans kan bevatten; het onthoudt gebruikers en de verdeling van munten tussen hen; heeft verschillende methoden voor het beheren van saldi, dat wil zeggen, er zijn mogelijkheden voor het storten, opnemen en controleren van het saldo van de gebruiker.

Laten we elke regel van de broncode doornemen. In dit contract zijn er constante velden. Een daarvan, van het type adres, wordt owner genoemd. Hier onthoudt het contract het adres van de gebruiker die dit smart contract heeft gemaakt. Vervolgens is er een dynamische structuur die de overeenkomsten tussen de adressen van de gebruikers en de saldi opslaat.

Daarna volgt de methode Bank — deze heet dezelfde als het contract. Dit is dus de constructor. Hier wordt de variabele owner toegewezen aan het adres van degene die dit smart contract in het netwerk heeft geplaatst. Dit is het enige dat in deze constructor gebeurt. Dat wil zeggen, msg in dit geval zijn precies die gegevens die samen met de transactie, die de hele code van dit contract bevat, aan de virtuele machine zijn overgedragen. Dus, msg.sender is de auteur van deze transactie die deze code plaatst. Hij zal de eigenaar van het smart contract zijn.

De deposit-methode stelt je in staat om een bepaald aantal munten via een transactie naar het contractaccount over te dragen. In dit geval behoudt het slimme contract deze munten op zijn saldo, maar schrijft het in de structuur 'balances' wie precies de verzender van deze munten was, zodat het weet aan wie ze toebehoren.

De volgende methode heet withdraw en accepteert één parameter: het bedrag aan munten dat iemand uit deze bank wil opnemen. Hier wordt gecontroleerd of er voldoende munten op het saldo van de gebruiker die deze methode aanroept zijn om ze te verzenden. Als dat zo is, retourneert het slimme contract het opgevraagde aantal munten aan de aanroeper.

Vervolgens is er de methode om het huidige saldo van de gebruiker te controleren. Degene die deze methode aanroept, zal worden gebruikt om dit saldo in het slimme contract op te vragen. Het is belangrijk op te merken dat de modifier van deze methode 'view' is. Dit betekent dat de methode de variabelen van zijn klasse op geen enkele manier verandert en feitelijk alleen een leesmethode is. Voor het aanroepen van deze methode wordt geen aparte transactie aangemaakt, worden er geen kosten betaald en worden alle berekeningen lokaal uitgevoerd, waarna de gebruiker het resultaat ontvangt.

De kill-methode is bedoeld om de status van het slimme contract te vernietigen. Hier is een extra controle opgenomen om te zien of degene die deze methode aanroept de eigenaar is van dit contract. Als dat zo is, vernietigt het contract zichzelf en de vernietigingsfunctie accepteert één parameter: de account-id waaraan het contract alle munten op zijn saldo zal verzenden. In dit geval zullen de resterende munten automatisch naar het adres van de eigenaar van het contract gaan.

Hoe werkt een volwaardig Ethereum-netwerk-node?

Laten we schematisch bekijken hoe de uitvoering van dergelijke slimme contracten op het Ethereum-platform plaatsvindt en hoe een volwaardig netwerk-node werkt.

Een volwaardig Ethereum-netwerk-node moet minstens vier modules hebben.
De eerste, net als voor elk gedecentraliseerd protocol, is de P2P networking module — de module voor netwerkverbindingen en communicatie met andere nodes, waar blokken, transacties en informatie over andere nodes worden uitgewisseld. Dit is een traditionele component voor alle gedecentraliseerde cryptocurrencies.

Daarnaast hebben we een blockchain opslagmodule, verwerking, prioriteitsselectie van takken, het toevoegen van blokken, het loskoppelen van blokken, het controleren van deze blokken, enzovoort.

De derde module heet EVM (Ethereum Virtual Machine) - dit is het virtuele machine, dat bytecode uit Ethereum-transacties accepteert. Deze module neemt de huidige staat van een bepaald account en voert de wijzigingen in zijn staat uit op basis van de ontvangen bytecode. De versie van de virtuele machine op elk van de knooppunten van het netwerk moet identiek zijn. De berekeningen op elk van de Ethereum-knooppunten zijn volledig identiek, maar ze vinden asynchroon plaats: de ene knoop controleert en accepteert deze transactie eerder, dat wil zeggen dat hij de gehele code uitvoert die erin is opgenomen, en de andere later. Bij de creatie van een transactie wordt deze verspreid over het netwerk, de knooppunten accepteren het en op het moment van verificatie wordt hetzelfde als in Bitcoin gedaan, waar Bitcoin Script wordt uitgevoerd, hier wordt de bytecode van de virtuele machine uitgevoerd.

Een transactie wordt als geverifieerd beschouwd als de gehele code erin is uitgevoerd, een nieuwe staat van een bepaald account is gegenereerd en is opgeslagen totdat het duidelijk is of deze transactie is toegepast of niet. Als de transactie is toegepast, wordt die staat niet alleen als uitgevoerd beschouwd, maar ook als actueel. Er is een database die de staat van elk account voor elk knooppunt van het netwerk opslaat. Omdat alle berekeningen identiek plaatsvinden en de blockchain-toestand hetzelfde is, zal ook de database die de toestanden van alle accounts bevat hetzelfde zijn voor elk knooppunt.

Mythen en beperkingen van slimme contracten

Wat betreft de beperkingen die bestaan voor slimme contracten op platforms zoals Ethereum, kunnen de volgende genoemd worden:

• code-uitvoering;
• geheugen toewijzen;
• blockchain gegevens;
• betalingen verzenden;
• nieuwe contracten creëren;
• andere contracten aanroepen.

Laten we de beperkingen bekijken die aan een virtuele machine zijn verbonden, en daarmee enkele mythen over smart contracts ontkrachten. Op een virtuele machine, die zich niet alleen in Ethereum maar ook in soortgelijke platforms bevindt, kunnen werkelijk willekeurige logische bewerkingen worden uitgevoerd. Dit betekent dat je code kunt schrijven die daar wordt uitgevoerd en dat je extra geheugen kunt toewijzen. De kosten worden echter apart betaald voor elke bewerking en voor elke extra eenheid geheugen die wordt toegewezen.

Bovendien kan de virtuele machine gegevens uit de blockchain-database lezen om deze te gebruiken als triggers voor het uitvoeren van een bepaalde logica van smart contracts. De virtuele machine kan transacties aanmaken en verzenden, nieuwe contracten creëren en methodes van andere smart contracts aanroepen die al in het netwerk zijn gepubliceerd: ze bestaan, zijn toegankelijk, enzovoort.

De meest voorkomende mythe is dat Ethereum smart contracts informatie van eender welke internetbron in hun voorwaarden kunnen gebruiken. De waarheid is dat de virtuele machine geen netwerkverzoek kan verzenden naar een externe informatiebron op het internet. Dit betekent dat je geen smart contract kunt schrijven dat waarde tussen gebruikers verdeelt op basis van bijvoorbeeld het weer buiten, of wie een competitie heeft gewonnen, of op basis van andere gebeurtenissen in de buitenwereld, omdat deze informatie eenvoudigweg niet in de database van het platform zelf staat. Dit betekent dat er in de blockchain hierover niets te vinden is. Als het daar niet verschijnt, kan de virtuele machine deze gegevens ook niet gebruiken als triggers.

Nadelen van Ethereum

Laten we de belangrijkste opsommen. Het eerste nadeel is dat er sommige complicaties zijn bij het ontwerpen, ontwikkelen en testen van smart contracts in Ethereum (in Ethereum wordt de programmeertaal Solidity gebruikt voor het schrijven van smart contracts). In de praktijk blijkt dat een groot percentage van alle fouten toe te schrijven is aan de menselijke factor. Dit is feitelijk ook relevant voor reeds geschreven Ethereum smart contracts die van gemiddeld niveau of hoger zijn. Als de kans op fouten bij eenvoudige smart contracts klein is, komen er in complexe smart contracts vaak fouten voor die leiden tot diefstal van middelen, het bevriezen van middelen, onverwachte vernietiging van smart contracts, enzovoort. Er zijn al veel van zulke gevallen bekend.

Het tweede nadeel is dat de virtuele machine zelf niet perfect is, omdat deze ook door mensen is geschreven. Ze kan willekeurige opdrachten uitvoeren en hierin schuilt de kwetsbaarheid: verschillende opdrachten kunnen op een bepaalde manier worden geconfigureerd die leiden tot ongewenste gevolgen. Dit is een zeer complex gebied, maar er zijn al verschillende studies die aantonen dat deze kwetsbaarheden bestaan in de huidige versie van het Ethereum-netwerk en dat ze kunnen leiden tot falen in de werking van veel smart contracts.

Een andere grote complicatie, die als een nadeel kan worden beschouwd. Het houdt in dat je op praktische of technische wijze kunt vaststellen dat als je de bytecode van een contract compileert dat op de virtuele machine wordt uitgevoerd, je een specifieke volgorde van operaties kunt bepalen. Gecombineerd zullen deze operaties de virtuele machine aanzienlijk belasten en deze onevenredig vertragen ten opzichte van de vergoeding die is betaald voor het uitvoeren van deze operaties.

Eerder was er een periode van ontwikkeling van Ethereum waarin veel mensen die de werking van de virtuele machine goed begrepen, kwetsbaarheden ontdekten. In feite betaalden transacties een heel lage vergoeding, maar vertraagden ze praktisch de werking van het hele netwerk. Deze problemen zijn moeilijk op te lossen, omdat het in de eerste plaats nodig is om ze te determineren, in de tweede plaats de prijs voor het uitvoeren van deze operaties aan te passen, en in de derde plaats een hard fork uit te voeren, wat betekent dat alle knooppunten in het netwerk naar een nieuwe versie van de software moeten worden bijgewerkt en vervolgens deze wijzigingen gelijktijdig moeten worden geactiveerd.

Wat Ethereum betreft, zijn er veel onderzoeken uitgevoerd en is er veel praktische ervaring opgebouwd: zowel positieve als negatieve, maar toch blijven er problemen en kwetsbaarheden bestaan waarmee nog steeds moet worden omgegaan.

Dus het thematische gedeelte van het artikel is afgerond, laten we overgaan naar de vragen die vaak opkomen.

Veelgestelde vragen

— Als alle partijen van het actieve smart contract de voorwaarden willen wijzigen, kunnen ze dit smart contract dan annuleren met behulp van multiparty-handtekeningen en vervolgens een nieuw smart contract aanmaken met bijgewerkte voorwaarden voor de uitvoering ervan?

Het antwoord hierop is dubbelzinnig. Waarom? Omdat aan de ene kant het smart contract eenmalig wordt vastgesteld en al geen wijzigingen meer impliceert, terwijl aan de andere kant het de mogelijkheid kan hebben van vooraf gedefinieerde logica die volledige of gedeeltelijke wijziging van bepaalde voorwaarden voorziet. Dat wil zeggen, als je iets wilt veranderen in je smart contract, moet je van tevoren de voorwaarden vastleggen waaronder je deze voorwaarden kunt bijwerken. Alleen op die voorzorgsmaatregel kan de update van het contract worden georganiseerd. Maar ook hier kun je in de problemen komen: als je een fout maakt, kun je een bijbehorende kwetsbaarheid krijgen. Daarom moeten dergelijke zaken zeer zorgvuldig en gedetailleerd worden ontworpen en getest.

— En wat als de mediator een samenzwering aangaat met een van de deelnemende partijen: escrow of smart contract? Is een mediator verplicht in een smart contract?

Een mediator is niet verplicht in een smart contract. Deze kan afwezig zijn. Als in het geval van escrow de mediator in samenwerking met een van de partijen zou gaan, verliest dit systeem meteen zijn waarde. Daarom worden mediators op zo’n manier gekozen dat ze het vertrouwen genieten van alle betrokken partijen. Je zult dus simpelweg geen munten naar een multisignature adres sturen met die mediator aan wie je niet vertrouwt.

— Is het mogelijk om met één Ethereum-transactie verschillende tokens van je adres naar verschillende doeladressen te versturen, bijvoorbeeld beursadressen waar deze tokens verhandeld worden?

Dit is een goede vraag en betreft het transactie model van Ethereum en het verschil met het Bitcoin model. En dat verschil is fundamenteel. In het transactie model van Ethereum verstuur je simpelweg munten, die worden overgedragen van het ene adres naar het andere, zonder wisselgeld, alleen het specifieke bedrag dat je opgegeven hebt. Met andere woorden, dit is geen model van niet-uitgegeven uitgangen (UTXO), maar een model van accounts en bijbehorende saldi. In theorie is het mogelijk om met één transactie meerdere verschillende tokens te versturen, als je een slimme smart contract schreef, maar je zou nog steeds veel transacties moeten uitvoeren, een contract moeten creëren, dan tokens en munten aan hem overdragen, en dan de juiste methode aanroepen. Dit vereist inspanning en tijd, en in de praktijk werkt dit zo niet; alle betalingen in Ethereum worden gedaan via aparte transacties.

— Een van de mythen over het Ethereum-platform is dat het onmogelijk is om voorwaarden te beschrijven die afhankelijk zijn van gegevens van externe internetbronnen, wat te doen dan?

De oplossing is dat het smart contract een of meerdere zogenaamde vertrouwde oracle kan omvatten, die gegevens verzamelen over de stand van zaken in de buitenwereld en deze doorgeven aan smart contracts via speciale methoden. Het contract beschouwt als waar de gegevens die het van de vertrouwde partijen heeft ontvangen. Voor meer betrouwbaarheid kiest men gewoon een grotere groep orakels en minimaliseert het risico op samenspanning. Het contract kan geen rekening houden met gegevens van orakels die in tegenspraak zijn met de meerderheid.

Dit onderwerp wordt behandeld in een van de lezingen van de online cursus over Blockchain — “Inleiding tot smart contracts”.

Bron: habr.com