In dit artikel zullen we kijken naar wat slimme contracten zijn, wat ze zijn, we zullen kennis maken met verschillende slimme contractplatforms, hun kenmerken, en ook bespreken hoe ze werken en welke voordelen ze kunnen bieden. Dit materiaal zal zeer nuttig zijn voor lezers die niet goed bekend zijn met het onderwerp slimme contracten, maar er dichter bij willen komen.
Regulier contract vs. slim contract
Voordat we ingaan op de details, laten we een voorbeeld nemen van de verschillen tussen een regulier contract, dat op papier wordt gespecificeerd, en een slim contract, dat digitaal wordt weergegeven.
Hoe werkte dit vóór de komst van slimme contracten? Stel je een groep mensen voor die bepaalde regels en voorwaarden willen vaststellen voor de verdeling van waarden, evenals een bepaald mechanisme om de implementatie van deze verdeling volgens de gegeven regels en voorwaarden te garanderen. Vervolgens kwamen ze samen, stelden een papier op waarop ze hun identiteit, voorwaarden en betrokken waarden opschreven, dateerden en ondertekenden het. Ook dit contract is gecertificeerd door een vertrouwde partij, zoals een notaris. Verder gingen deze mensen verschillende kanten op met hun papieren exemplaar van een dergelijk contract en begonnen ze een aantal acties uit te voeren die misschien niet overeenkwamen met het contract zelf, dat wil zeggen: ze deden één ding, maar op papier werd verklaard dat ze iets moesten doen. totaal verschillend. En hoe kom je uit deze situatie? In feite moet een van de groepsleden dit document in ontvangst nemen, wat bewijs verzamelen, het voor de rechter brengen en naleving van het contract en de daadwerkelijke acties bewerkstelligen. Vaak is het moeilijk om een eerlijke uitvoering van dit contract te bereiken, wat tot onaangename gevolgen leidt.
Wat valt er te zeggen over slimme contracten? Ze combineren zowel de mogelijkheid om de voorwaarden van het contract te schrijven als het mechanisme voor de strikte implementatie ervan. Als de voorwaarden zijn gesteld en de bijbehorende transactie of aanvraag is ondertekend, is het na aanvaarding van die aanvraag of transactie niet meer mogelijk de voorwaarden te wijzigen of de uitvoering ervan te beïnvloeden.
Er is één validator of een heel netwerk, evenals een database waarin alle slimme contracten die ter uitvoering zijn ingediend, in strikt chronologische volgorde worden opgeslagen. Het is ook belangrijk dat deze database alle triggervoorwaarden voor het uitvoeren van het slimme contract moet bevatten. Bovendien moet het rekening houden met de waarde waarvan de verdeling in het contract wordt beschreven. Als dit van toepassing is op een bepaalde digitale valuta, moet deze database daar rekening mee houden.
Met andere woorden: slimme contractvalidators moeten toegang hebben tot alle gegevens waarop het slimme contract werkt. Er moet bijvoorbeeld één enkele database worden gebruikt om tegelijkertijd digitale valuta, gebruikerssaldi, gebruikerstransacties en tijdstempels te registreren. Vervolgens kan bij een slim contract de voorwaarde het saldo van de gebruiker in een bepaalde valuta zijn, het aanbreken van een bepaalde tijd of het feit dat een bepaalde transactie is uitgevoerd, maar meer niet.
Definitie van een slim contract
Over het algemeen werd de terminologie zelf bedacht door onderzoeker Nick Szabo en voor het eerst gebruikt in 1994, en in 1997 gedocumenteerd in een artikel dat het idee van slimme contracten beschrijft.
Slimme contracten impliceren dat er enige automatisering van de waardeverdeling plaatsvindt, die alleen kan afhangen van de vooraf bepaalde voorwaarden. In zijn eenvoudigste vorm lijkt het op een contract met strikt gedefinieerde voorwaarden, dat door bepaalde partijen wordt ondertekend.
Slimme contracten zijn ontworpen om het vertrouwen in derde partijen te minimaliseren. Soms wordt het beslissingscentrum waar alles van afhangt volledig uitgesloten. Bovendien zijn dergelijke contracten gemakkelijker te controleren. Dit is een gevolg van enkele ontwerpkenmerken van een dergelijk systeem, maar meestal verstaan we onder een slim contract een gedecentraliseerde omgeving en de aanwezigheid van functies waarmee iedereen de database kan analyseren en een volledige audit van de uitvoering van contracten kan uitvoeren. Dit garandeert bescherming tegen gegevenswijzigingen met terugwerkende kracht die wijzigingen in de uitvoering van het contract zelf met zich mee zouden brengen. Digitalisering van de meeste processen bij het creëren en lanceren van een slim contract vereenvoudigt vaak de technologie en de kosten van de implementatie ervan.
Een eenvoudig voorbeeld: Escrow-service
Laten we eens naar een heel eenvoudig voorbeeld kijken. Het zal u helpen de functionaliteit van slimme contracten beter te begrijpen en beter te begrijpen in welke gevallen ze moeten worden gebruikt.
Het kan ook met Bitcoin worden geïmplementeerd, al kan Bitcoin op dit moment nog nauwelijks een volwaardig platform voor slimme contracten worden genoemd. We hebben dus een koper en we hebben een online winkel. Een klant wil een monitor kopen in deze winkel. In het eenvoudigste geval voltooit en verzendt de koper een betaling, waarna de online winkel deze accepteert, bevestigt en vervolgens de goederen verzendt. In deze situatie is er echter behoefte aan groot vertrouwen: de koper moet de online winkel vertrouwen voor de volledige kosten van de monitor. Aangezien een online winkel in de ogen van de koper een slechte reputatie kan hebben, bestaat het risico dat de winkel om wat voor reden dan ook, na acceptatie van de betaling, service weigert en de goederen niet naar de koper stuurt. Daarom stelt de koper de vraag (en dienovereenkomstig stelt de online winkel deze vraag) wat in dit geval kan worden toegepast om dergelijke risico's te minimaliseren en dergelijke transacties betrouwbaarder te maken.
In het geval van Bitcoin is het mogelijk om de koper en verkoper onafhankelijk een bemiddelaar te laten selecteren. Er zijn veel mensen die betrokken zijn bij het oplossen van controversiële kwesties. En onze deelnemers kunnen uit een algemene lijst van bemiddelaars degene kiezen die zij vertrouwen. Samen creëren ze een 2 van 3 multisignature-adres waarbij er drie sleutels zijn en twee handtekeningen met twee willekeurige sleutels nodig zijn om munten vanaf dat adres uit te geven. Eén sleutel is van de koper, de tweede van de online winkel en de derde van de bemiddelaar. En naar zo'n adres met meerdere handtekeningen stuurt de koper het bedrag dat nodig is om voor de monitor te betalen. Als de verkoper nu ziet dat geld enige tijd geblokkeerd is op een adres met meerdere handtekeningen dat van hem afhankelijk is, kan hij de monitor veilig per post verzenden.
Vervolgens ontvangt de koper het pakket, inspecteert de goederen en neemt een beslissing over de definitieve aankoop. Het kan zijn dat hij het volledig eens is met de geleverde dienst en de transactie met zijn sleutel ondertekent, waarbij hij munten van het multisignature-adres naar de verkoper overmaakt, of dat hij ergens ontevreden over is. In het tweede geval neemt hij contact op met een bemiddelaar om een alternatieve transactie samen te stellen waardoor de munten op een andere manier worden verdeeld.
Laten we zeggen dat de monitor een beetje bekrast arriveerde en dat de set geen kabel bevatte om op de computer aan te sluiten, hoewel de website van de online winkel zei dat de kabel in de set moest worden meegeleverd. Vervolgens verzamelt de koper het bewijsmateriaal dat nodig is om aan de bemiddelaar te bewijzen dat hij in deze situatie is misleid: hij maakt screenshots van de site, maakt een foto van het ontvangstbewijs, maakt een foto van de krassen op de monitor en laat zien dat de verzegeling is gebroken en de kabel werd eruit getrokken. De online winkel verzamelt op zijn beurt het bewijsmateriaal en draagt dit over aan de bemiddelaar.
De bemiddelaar is geïnteresseerd in het tegelijkertijd bevredigen van zowel de verontwaardiging van de koper als de belangen van de online winkel (waarom zal later duidelijk worden). Het betreft een transactie waarbij munten van een adres met meerdere handtekeningen in een bepaalde verhouding worden uitgegeven tussen de koper, de online winkel en de bemiddelaar, aangezien hij een deel voor zichzelf neemt als beloning voor zijn werk. Laten we zeggen dat 90% van het totaalbedrag naar de verkoper gaat, 5% naar de bemiddelaar en 5% compensatie naar de koper. De bemiddelaar ondertekent deze transactie met zijn sleutel, maar deze kan nog niet worden toegepast, omdat er twee handtekeningen voor nodig zijn, maar er is er maar één de moeite waard. Het verzendt 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 munten, wordt de transactie vooraf ondertekend en naar het netwerk gedistribueerd. Om dit te valideren is het voldoende dat een van de partijen bij de transactie akkoord gaat met de optie van de bemiddelaar.
Het is belangrijk om in eerste instantie een mediator te kiezen, zodat beide deelnemers hem vertrouwen. In dit geval zal hij onafhankelijk van de belangen van de een of de ander handelen en de situatie objectief beoordelen. Als de bemiddelaar geen optie biedt voor het distribueren van munten die ten minste één deelnemer tevreden zullen stellen, kunnen zowel de koper als de online winkel, nadat ze dit samen hebben afgesproken, de munten naar een nieuw adres met meerdere handtekeningen sturen door hun twee handtekeningen te plaatsen. Het nieuwe adres met meerdere handtekeningen zal worden samengesteld met een andere bemiddelaar, die mogelijk competenter is in de zaak en een betere optie biedt.
Voorbeeld met een slaapzaal en een koelkast
Laten we eens kijken naar een complexer voorbeeld dat de mogelijkheden van een slim contract explicieter weergeeft.
Laten we zeggen dat er drie jongens zijn die onlangs naar dezelfde studentenkamer zijn verhuisd. Ze zijn alle drie geïnteresseerd in het kopen van een koelkast voor op hun kamer, die ze samen kunnen gebruiken. Een van hen bood zich vrijwillig aan om het benodigde bedrag op te halen om een koelkast te kopen en met de verkoper te onderhandelen. Ze hebben elkaar echter pas onlangs ontmoet en er is niet genoeg vertrouwen tussen hen. Het is duidelijk dat twee van hen een risico nemen door geld aan de derde te geven. Bovendien moeten ze tot overeenstemming komen bij de keuze van een verkoper.
Ze kunnen gebruik maken van de escrow-service, dat wil zeggen dat ze een bemiddelaar kunnen kiezen die toezicht houdt op de uitvoering van de transactie en eventuele controversiële problemen oplost. Vervolgens stellen ze, nadat ze het eens zijn geworden, een slim contract op en schrijven daarin bepaalde voorwaarden voor.
De eerste voorwaarde is dat het bijbehorende slimme contractaccount vóór een bepaald tijdstip, bijvoorbeeld binnen een week, drie betalingen moet ontvangen van bepaalde adressen voor een bepaald bedrag. Als dit niet gebeurt, stopt het slimme contract met de uitvoering en worden de munten teruggegeven aan alle deelnemers. Als aan de voorwaarde is voldaan, worden de waarden van de identificatiegegevens van de verkoper en de bemiddelaar ingesteld en wordt de voorwaarde gecontroleerd dat alle deelnemers het eens zijn met de keuze van de verkoper en de bemiddelaar. Wanneer aan alle voorwaarden is voldaan, wordt het geld overgemaakt naar de opgegeven adressen. Deze aanpak kan deelnemers van alle kanten tegen fraude beschermen en elimineert over het algemeen de noodzaak om te vertrouwen.
We zien in dit voorbeeld het principe dat deze mogelijkheid om stapsgewijs parameters in te stellen om aan elke voorwaarde te voldoen, je in staat stelt systemen te creëren van elke complexiteit en diepte van geneste niveaus. Bovendien kunt u eerst de eerste voorwaarde in het slimme contract definiëren, en pas nadat deze is vervuld, kunt u parameters instellen voor de volgende voorwaarde. Met andere woorden, de voorwaarde is formeel geschreven en de parameters ervoor kunnen al tijdens de werking ervan worden ingesteld.
Classificatie van slimme contracten
Voor classificatie kunt u verschillende groepen criteria instellen. Op het moment van de technologische ontwikkeling zijn er echter vier relevant.
Slimme contracten onderscheiden zich door hun uitvoeringsomgeving, die gecentraliseerd of gedecentraliseerd kan zijn. In het geval van decentralisatie hebben we een veel grotere onafhankelijkheid en fouttolerantie bij het uitvoeren van slimme contracten.
Ze kunnen ook worden onderscheiden door het proces van het stellen en vervullen van voorwaarden: ze kunnen vrij programmeerbaar, beperkt of vooraf gedefinieerd zijn, dat wil zeggen strikt getypeerd. Wanneer er slechts 4 specifieke slimme contracten op het slimme contractplatform staan, kunnen de parameters daarvoor op elke manier worden ingesteld. Dienovereenkomstig is het instellen ervan veel eenvoudiger: we selecteren een contract uit de lijst en geven de parameters door.
Volgens de initiatiemethode zijn er geautomatiseerde slimme contracten, dat wil zeggen dat wanneer bepaalde voorwaarden zich voordoen, ze zichzelf uitvoeren, en er zijn contracten waarin de voorwaarden zijn gespecificeerd, maar het platform controleert niet automatisch de vervulling ervan; hiervoor afzonderlijk moeten worden gestart.
Bovendien variëren slimme contracten in hun niveau van privacy. Ze kunnen volledig open, gedeeltelijk of volledig vertrouwelijk zijn. Dit laatste betekent dat externe waarnemers de voorwaarden van slimme contracten niet zien. Het onderwerp privacy is echter zeer breed en het is beter om dit los van het huidige artikel te beschouwen.
Hieronder zullen we de eerste drie criteria nader bekijken om meer duidelijkheid te scheppen in het begrip van het huidige onderwerp.
Slimme contracten op runtime
Op basis van de uitvoeringsomgeving wordt onderscheid gemaakt tussen gecentraliseerde en gedecentraliseerde slimme contractplatforms. Bij gecentraliseerde digitale contracten wordt gebruik gemaakt van één dienst, waarbij er slechts één validator is en eventueel sprake is van een backup- en hersteldienst, die eveneens centraal wordt beheerd. Er is één database die alle benodigde informatie opslaat om de voorwaarden van het slimme contract vast te stellen en de waarde te distribueren waarmee in deze servicedatabase rekening wordt gehouden. Zo’n gecentraliseerde dienst heeft een klant die voorwaarden stelt aan bepaalde verzoeken en gebruik maakt van dergelijke contracten. Vanwege het gecentraliseerde karakter van het platform zijn authenticatiemechanismen mogelijk minder veilig dan bij cryptocurrencies.
Als voorbeeld kunnen we mobiele-communicatieproviders nemen (verschillende mobiele operators). Laten we zeggen dat een bepaalde operator een gecentraliseerd register bijhoudt van het verkeer op zijn servers, dat in verschillende formaten kan worden verzonden, bijvoorbeeld: in de vorm van spraakoproepen, sms-transmissie, mobiel internetverkeer en volgens verschillende standaarden, en ook records bijhoudt van fondsen op gebruikerssaldi. Dienovereenkomstig kan de aanbieder van mobiele communicatie contracten opstellen voor de afrekening van de geleverde diensten en de betaling ervan, met verschillende voorwaarden. In dit geval kun je eenvoudig voorwaarden stellen als “stuur een sms met die en die code naar dat en dat nummer en je krijgt die en die voorwaarden voor de verkeersverdeling.”
Nog een voorbeeld kan worden gegeven: traditionele banken met uitgebreide functionaliteit van internetbankieren en zeer eenvoudige contracten zoals periodieke betalingen, automatische conversie van inkomende betalingen, automatische aftrek van rente op een bepaalde rekening, enz.
Als we het hebben over slimme contracten met een gedecentraliseerde uitvoeringsomgeving, dan hebben we een groep validators. Idealiter kan iedereen validator worden. Dankzij het databasesynchronisatieprotocol en het bereiken van consensus hebben we een gemeenschappelijke database die nu alle transacties met strikt beschreven contracten opslaat, en niet enkele voorwaardelijke zoekopdrachten, waarvan de formaten vaak veranderen, en er geen open specificatie is. Hier zullen de transacties instructies bevatten om het contract volgens een strikte specificatie uit te voeren. Deze specificatie is open en daarom kunnen platformgebruikers zelf slimme contracten auditen en valideren. Hier zien we dat gedecentraliseerde platforms superieur zijn aan gecentraliseerde platforms in termen van onafhankelijkheid en fouttolerantie, maar dat hun ontwerp en onderhoud veel complexer zijn.
Slimme contracten door de methode van het stellen en vervullen van voorwaarden
Laten we nu eens nader bekijken hoe slimme contracten kunnen verschillen in de manier waarop ze voorwaarden stellen en vervullen. Hier richten we onze aandacht op slimme contracten die willekeurig programmeerbaar en Turing compleet zijn. Met een Turing-compleet slim contract kunt u vrijwel alle algoritmen instellen als voorwaarden voor de uitvoering van het contract: schrijfcycli, enkele functies voor het berekenen van kansen en dergelijke - tot aan uw eigen algoritmen voor elektronische handtekeningen. In dit geval bedoelen we werkelijk willekeurig schrijven van logica.
Er zijn ook willekeurige slimme contracten, maar geen volledige Turing-contracten. Dit omvat Bitcoin en Litecoin met hun eigen script. Dit betekent dat je alleen bepaalde bewerkingen in willekeurige volgorde kunt gebruiken, maar dat je geen loops en je eigen algoritmen meer kunt schrijven.
Daarnaast zijn er slimme contractplatforms die vooraf gedefinieerde slimme contracten implementeren. Deze omvatten Bitshares en Steemit. Bitshares heeft een reeks slimme contracten voor handel, accountbeheer, beheer van het platform zelf en zijn parameters. Steemit is een soortgelijk platform, maar is niet langer gericht op het uitgeven van tokens en handel, zoals Bitshares, maar op bloggen, dat wil zeggen dat het inhoud op een gedecentraliseerde manier opslaat en verwerkt.
Willekeurige Turing-complete contracten omvatten het Ethereum-platform en RootStock, dat nog in ontwikkeling is. Daarom zullen we hieronder wat gedetailleerder ingaan op het Ethereum slimme contractplatform.
Slimme contracten via initiatiemethode
Op basis van de wijze van initiatie kunnen slimme contracten ook in minimaal twee groepen worden verdeeld: geautomatiseerd en handmatig (niet geautomatiseerd). Geautomatiseerde contracten worden gekenmerkt door het feit dat, gegeven alle bekende parameters en voorwaarden, het slimme contract volledig automatisch wordt uitgevoerd, dat wil zeggen dat het geen extra transacties vereist en geen extra commissie uitgeeft aan elke volgende uitvoering. Het platform zelf beschikt over alle gegevens om te berekenen hoe het slimme contract zal verlopen. De logica daar is niet willekeurig, maar vooraf bepaald en dit alles is voorspelbaar. Dat wil zeggen, u kunt van tevoren de complexiteit van het uitvoeren van een slim contract inschatten, er een soort constante commissie voor gebruiken en alle processen voor de implementatie ervan zijn efficiënter.
Voor slimme contracten die vrij geprogrammeerd zijn, is de uitvoering niet geautomatiseerd. Om zo'n slim contract te initiëren, moet je bij vrijwel elke stap een nieuwe transactie creëren, die de volgende uitvoeringsfase of de volgende slimme contractmethode zal aanroepen, de juiste commissie betalen en wachten tot de transactie wordt bevestigd. De uitvoering kan met succes worden voltooid of niet, omdat de slimme contractcode willekeurig is en er enkele onvoorspelbare momenten kunnen optreden, zoals een eeuwige lus, een gebrek aan bepaalde parameters en argumenten, onverwerkte uitzonderingen, enz.
Ethereum-accounts
Ethereum-accounttypen
Laten we eens kijken welke soorten accounts er op het Ethereum-platform kunnen zijn. Er zijn hier slechts twee soorten accounts en er zijn geen andere opties. Het eerste type wordt een gebruikersaccount genoemd, het tweede is een contractaccount. Laten we uitzoeken hoe ze verschillen.
Het gebruikersaccount wordt alleen beheerd door de persoonlijke sleutel van de elektronische handtekening. De accounteigenaar genereert zijn eigen sleutelpaar voor elektronische handtekeningen 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.
Er is een aparte logica voorzien voor het slimme contractaccount. Het kan alleen worden gecontroleerd door vooraf gedefinieerde softwarecode die het gedrag van het slimme contract volledig bepaalt: 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 sommige punten niet door de ontwikkelaars in de programmacode zijn voorzien, kunnen er problemen ontstaan. Een slim contract kan bijvoorbeeld een bepaalde status krijgen waarin het geen enkele verdere uitvoering van een van de gebruikers accepteert. In dit geval worden de munten daadwerkelijk bevroren, omdat het slimme contract niet voorziet in het verlaten van deze staat.
Hoe accounts worden aangemaakt op Ethereum
In het geval van een gebruikersaccount genereert de eigenaar zelfstandig een sleutelpaar met behulp van ECDSA. Het is belangrijk op te merken dat Ethereum exact hetzelfde algoritme en precies dezelfde elliptische curve voor elektronische handtekeningen gebruikt als Bitcoin, maar dat het adres op een iets andere manier wordt berekend. Hier wordt niet meer gebruik gemaakt van het resultaat van dubbele hashing, zoals bij Bitcoin, maar wordt enkelvoudige hashing voorzien van de Keccak-functie met een lengte van 256 bits. De minst significante bits worden afgesneden van de resulterende waarde, namelijk de minst significante 160 bits van de uitgaande hashwaarde. Als resultaat krijgen we een adres in Ethereum. In feite neemt het 20 bytes in beslag.
Houd er rekening mee dat de account-ID in Ethereum in hexadecimale code is gecodeerd zonder een controlesom toe te passen, in tegenstelling tot Bitcoin en veel andere systemen, waarbij het adres is gecodeerd in een basis 58-nummersysteem met de toevoeging van een controlesom. Dit betekent dat u 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.
Er is een belangrijk kenmerk en het is dat een gebruikersaccount op algemeen databaseniveau wordt aangemaakt op het moment dat hij de eerste inkomende betaling accepteert.
Het maken van een slim contractaccount vergt een heel andere aanpak. In eerste instantie schrijft een van de gebruikers de broncode van het slimme contract, waarna de code door een compiler speciaal voor het Ethereum-platform wordt gevoerd, waardoor bytecode wordt verkregen voor zijn eigen virtuele Ethereum-machine. De resulterende bytecode wordt in een speciaal veld van de transactie geplaatst. Het wordt gecertificeerd ten behoeve van de rekening van de initiatiefnemer. Vervolgens wordt deze transactie door het hele netwerk verspreid en wordt de slimme contractcode geplaatst. De commissie voor de transactie en daarmee voor de uitvoering van het contract wordt afgetrokken van het saldo van de rekening van de initiator.
Elk slim contract bevat noodzakelijkerwijs zijn eigen constructeur (van dit contract). Het kan leeg zijn of het kan inhoud bevatten. Nadat de constructor is uitgevoerd, wordt er een smart contract-account-ID aangemaakt, waarmee u munten kunt verzenden, bepaalde smart contract-methoden kunt aanroepen, enz.
Ethereum-transactiestructuur
Om het duidelijker te maken, zullen we beginnen te kijken naar de structuur van een Ethereum-transactie en een voorbeeld van een slimme contractcode.
Een Ethereum-transactie bestaat uit verschillende velden. De eerste hiervan, nonce, is een bepaald serienummer van de transactie ten opzichte van de rekening zelf die deze distribueert en de auteur ervan is. Dit is nodig om dubbele transacties te kunnen onderscheiden, dat wil zeggen om het geval uit te sluiten waarin dezelfde transactie tweemaal wordt geaccepteerd. Door een identificatie te gebruiken, heeft elke transactie een unieke hashwaarde.
Vervolgens komt een veld zoals gas prijs. Dit geeft de prijs aan waartegen de Ethereum-basisvaluta wordt omgezet in gas, dat wordt gebruikt om te betalen voor de uitvoering van het slimme contract en de toewijzing van de virtuele machinebron. Wat betekent het?
Bij Bitcoin worden de kosten rechtstreeks betaald door de basisvaluta: Bitcoin zelf. Dit is mogelijk dankzij een eenvoudig mechanisme om ze te berekenen: we betalen strikt voor de hoeveelheid gegevens in de transactie. In Ethereum is de situatie ingewikkelder, omdat het erg moeilijk is om te vertrouwen op de hoeveelheid transactiegegevens. Hier kan de transactie ook programmacode bevatten die op de virtuele machine wordt uitgevoerd, en elke bewerking van de virtuele machine kan een andere complexiteit hebben. Er zijn ook bewerkingen die geheugen toewijzen aan variabelen. Ze zullen hun eigen complexiteit hebben, waarvan de betaling voor elke operatie zal afhangen.
De kosten van elke operatie in gasequivalent zullen constant zijn. Het wordt specifiek 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 coëfficiënt volgens welke de basisvaluta zal worden omgezet in deze hulpeenheid om de commissie te betalen.
Er is nog een kenmerk van een transactie in Ethereum: de bytecode die deze bevat voor uitvoering in een virtuele machine, wordt uitgevoerd totdat deze wordt voltooid met een bepaald resultaat (succes of mislukking) of totdat een bepaald aantal toegewezen munten op is om de commissie te betalen. . Om een situatie te voorkomen waarin, in het geval van een fout, alle munten van de rekening van de afzender aan commissie zijn uitgegeven (bijvoorbeeld een soort eeuwige cyclus die in een virtuele machine is gestart), bestaat het volgende veld - gas beginnen (vaak gaslimiet genoemd) - het bepaalt het maximale aantal munten dat de afzender bereid is uit te geven om een bepaalde transactie te voltooien.
Het volgende veld wordt opgeroepen bestemmingsadres. Dit omvat het adres van de ontvanger van de munten of het adres van een specifiek slim contract waarvan de methoden zullen worden aangeroepen. Daarna komt het veld waarde, waar het aantal munten wordt ingevoerd dat naar het bestemmingsadres wordt verzonden.
Het volgende is een interessant veld genaamd gegevens, waar de hele structuur past. Dit is geen apart veld, maar een hele structuur waarin de code voor de virtuele machine is gedefinieerd. Hier kunt u willekeurige gegevens plaatsen, hiervoor gelden aparte regels.
En het laatste veld wordt opgeroepen handtekening. Het bevat tegelijkertijd zowel de elektronische handtekening van de auteur van deze transactie als de publieke sleutel waarmee deze handtekening zal worden geverifieerd. Uit de openbare sleutel kunt u de account-ID van de afzender van deze transactie halen, dat wil zeggen dat u de account van de afzender op unieke wijze in het systeem zelf kunt identificeren. We ontdekten het belangrijkste over de structuur van de transactie.
Voorbeeld van een slimme contractcode voor Solidity
Laten we nu het eenvoudigste slimme contract eens nader bekijken 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 bevatten en deze op verzoek kan retourneren.
Er is dus een slim contract van de bank dat de volgende functies vervult: het verzamelt munten op zijn saldo, dat wil zeggen dat wanneer een transactie wordt bevestigd en zo'n slim contract wordt geplaatst, er een nieuwe rekening wordt aangemaakt die munten op zijn saldo kan bevatten; het onthoudt gebruikers en de verdeling van munten tussen hen; heeft verschillende methoden voor het beheren van saldi, dat wil zeggen dat het mogelijk is om het saldo van de gebruiker aan te vullen, op te nemen en te controleren.
Laten we elke regel broncode doornemen. Dit contract heeft constante velden. Eén ervan, met typeadres, heet eigenaar. Hier onthoudt het contract het adres van de gebruiker die dit slimme contract heeft gemaakt. Verder is er een dynamische structuur die de correspondentie tussen gebruikersadressen en saldi onderhoudt.
Dit wordt gevolgd door de Bank-methode - deze heeft dezelfde naam als het contract. Dit is dus de constructor ervan. Hier krijgt de eigenaarvariabele het adres toegewezen van de persoon die dit slimme contract op het netwerk heeft geplaatst. Dit is het enige dat in deze constructor gebeurt. Dat wil zeggen dat msg in dit geval precies de gegevens zijn die naar de virtuele machine zijn overgebracht, samen met de transactie die de volledige code van dit contract bevat. Dienovereenkomstig is msg.sender de auteur van deze transactie die deze code host. Hij wordt de eigenaar van het slimme contract.
Met de stortingsmethode kunt u per transactie een bepaald aantal munten naar de contractrekening overboeken. In dit geval laat het slimme contract, dat deze munten ontvangt, ze op de balans staan, maar registreert in de balansstructuur wie precies de afzender van deze munten was om te weten van wie ze zijn.
De volgende methode heet opnemen en er is één parameter voor nodig: het aantal munten dat iemand van deze bank wil opnemen. Hiermee wordt gecontroleerd of er voldoende munten op het saldo staan van de gebruiker die deze methode aanroept om ze te verzenden. Als er genoeg zijn, geeft het slimme contract zelf dat aantal munten terug aan de beller.
Vervolgens komt de methode om het huidige saldo van de gebruiker te controleren. Wie deze methode aanroept, wordt gebruikt om dit saldo op te halen in het slimme contract. Het is vermeldenswaard dat de modifier van deze methode view is. Dit betekent dat de methode zelf de variabelen van zijn klasse op geen enkele manier verandert en dat het eigenlijk alleen maar een leesmethode is. Er wordt geen aparte transactie aangemaakt om deze methode aan te roepen, er wordt geen vergoeding betaald en alle berekeningen worden lokaal uitgevoerd, waarna de gebruiker het resultaat ontvangt.
De kill-methode is nodig om de staat van het slimme contract te vernietigen. En hier is er een extra controle of de beller van deze methode de eigenaar van dit contract is. Als dat zo is, vernietigt het contract zichzelf en neemt de vernietigingsfunctie één parameter aan: de account-ID waarnaar het contract alle resterende munten op zijn saldo zal sturen. In dit geval gaan de resterende munten automatisch naar het adres van de contracteigenaar.
Hoe werkt een full node op het Ethereum-netwerk?
Laten we schematisch bekijken hoe dergelijke slimme contracten worden uitgevoerd op het Ethereum-platform en hoe een volledig netwerkknooppunt werkt.
Een volledige node op het Ethereum-netwerk moet minimaal vier modules hebben.
De eerste is, zoals bij elk gedecentraliseerd protocol, 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 voor alle gedecentraliseerde cryptocurrencies.
Vervolgens hebben we een module voor het opslaan van blockchain-gegevens, het verwerken ervan, het kiezen van een prioriteitstak, het toevoegen van blokken, het ontkoppelen van blokken, het valideren van deze blokken, enz.
De derde module heet EVM (Ethereum virtual machine) - dit is een virtuele machine die bytecode ontvangt van Ethereum-transacties. Deze module neemt de huidige status van een bepaald account en brengt wijzigingen aan in de status op basis van de ontvangen bytecode. De versie van de virtuele machine op elk netwerkknooppunt moet hetzelfde zijn. De berekeningen die plaatsvinden op elk Ethereum-knooppunt zijn precies hetzelfde, maar ze vinden op asynchrone wijze plaats: iemand controleert en accepteert deze transactie eerder, dat wil zeggen, voert alle code uit die erin zit, en iemand later. Wanneer een transactie wordt aangemaakt, wordt deze dus naar het netwerk gedistribueerd, accepteren de knooppunten deze en op het moment van verificatie wordt hier, op dezelfde manier waarop Bitcoin Script in Bitcoin wordt uitgevoerd, de bytecode van de virtuele machine uitgevoerd.
Een transactie wordt als geverifieerd beschouwd als alle daarin opgenomen code 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 wordt toegepast, wordt deze status niet alleen als voltooid, maar ook als actueel beschouwd. Er is een database waarin de status van elk account voor elk netwerkknooppunt wordt opgeslagen. Doordat alle berekeningen op dezelfde manier plaatsvinden en de staat van de blockchain hetzelfde is, zal de database met de statussen van alle accounts ook voor elk knooppunt hetzelfde zijn.
Mythen en beperkingen van slimme contracten
Wat betreft de beperkingen die bestaan voor slimme contractplatforms vergelijkbaar met Ethereum, kan het volgende worden aangehaald:
- uitvoering van code;
- geheugen toewijzen;
- blockchain-gegevens;
- betalingen verzenden;
- nieuw contract aanmaken;
- Andere contracten bellen.
Laten we eens kijken naar de beperkingen die aan een virtuele machine worden opgelegd, en dienovereenkomstig enkele mythen over slimme contracten verdrijven. Op een virtuele machine, die zich niet alleen in Ethereum kan bevinden, maar ook op vergelijkbare platforms, kun je echt willekeurige logische bewerkingen uitvoeren, dat wil zeggen, code schrijven en die daar worden uitgevoerd, je kunt bovendien geheugen toewijzen. De vergoeding wordt echter afzonderlijk betaald voor elke bewerking en voor elke extra toegewezen geheugeneenheid.
Vervolgens kan de virtuele machine gegevens uit de blockchain-database lezen om deze gegevens te gebruiken als trigger om een of andere slimme contractlogica uit te voeren. De virtuele machine kan transacties aanmaken en verzenden, nieuwe contracten creëren en methoden aanroepen van andere slimme contracten die al op het netwerk zijn gepubliceerd: bestaand, beschikbaar, enz.
De meest voorkomende mythe is dat Ethereum slimme contracten in hun voorwaarden informatie van elke internetbron kunnen gebruiken. De waarheid is dat een virtuele machine geen netwerkverzoek naar een externe informatiebron op internet kan sturen, dat wil zeggen dat het onmogelijk is om een slim contract te schrijven dat waarde tussen gebruikers verdeelt, afhankelijk van bijvoorbeeld hoe het weer buiten is, of wie een kampioenschap heeft gewonnen, of op basis van welk ander incident er in de buitenwereld is gebeurd, omdat informatie over deze incidenten simpelweg niet in de database van het platform zelf staat. Dat wil zeggen: hierover staat niets op de blockchain. Als het daar niet verschijnt, kan de virtuele machine deze gegevens niet als triggers gebruiken.
Nadelen van Ethereum
Laten we de belangrijkste opsommen. Het eerste nadeel is dat er wat problemen zijn bij het ontwerpen, ontwikkelen en testen van slimme contracten in Ethereum (Ethereum gebruikt de Solidity-taal om slimme contracten te schrijven). De praktijk leert immers dat een zeer groot percentage van alle fouten te maken heeft met de menselijke factor. Dit geldt eigenlijk voor reeds geschreven slimme Ethereum-contracten die een gemiddelde of hogere complexiteit hebben. Als voor eenvoudige slimme contracten de kans op een fout klein is, dan zijn er bij complexe slimme contracten heel vaak fouten die leiden tot diefstal van geld, bevriezing ervan, vernietiging van slimme contracten op een onverwachte manier, enz. Veel van dergelijke gevallen zijn al bekend.
Het tweede nadeel is dat de virtuele machine zelf niet perfect is, aangezien deze ook door mensen is geschreven. Het kan willekeurige commando's uitvoeren, en daarin schuilt de kwetsbaarheid: een aantal commando's kan op een bepaalde manier worden geconfigureerd, wat leidt tot gevolgen die van tevoren niet te voorzien waren. Dit is een zeer complex gebied, maar er zijn al verschillende onderzoeken die aantonen dat deze kwetsbaarheden voorkomen in de huidige versie van het Ethereum-netwerk en dat ze kunnen leiden tot het mislukken van veel slimme contracten.
Nog een groot probleem, het kan als een nadeel worden beschouwd. Het ligt in het feit dat je praktisch of technisch tot de conclusie kunt komen dat als je de bytecode compileert van een contract dat op een virtuele machine wordt uitgevoerd, je een specifieke volgorde van bewerkingen kunt bepalen. Wanneer ze samen worden uitgevoerd, zullen deze bewerkingen de virtuele machine enorm belasten en onevenredig vertragen in vergelijking met de vergoeding die is betaald voor het uitvoeren van deze bewerkingen.
In het verleden was er al een periode in de ontwikkeling van Ethereum, waarin veel jongens die de werking van een virtuele machine tot in detail begrepen, dergelijke kwetsbaarheden ontdekten. In feite betaalden transacties een zeer kleine vergoeding, maar vertraagden ze praktisch het hele netwerk. Deze problemen zijn zeer moeilijk op te lossen, omdat het ten eerste nodig is om ze te bepalen, ten tweede om de prijs voor het uitvoeren van deze bewerkingen aan te passen en ten derde om een hard fork uit te voeren, wat betekent dat alle netwerkknooppunten moeten worden bijgewerkt naar een nieuwe versie. van de software, en vervolgens gelijktijdige activering van deze wijzigingen.
Wat Ethereum betreft, is er veel onderzoek gedaan en veel praktische ervaring opgedaan: zowel positief als negatief, maar toch blijven er moeilijkheden en kwetsbaarheden bestaan die op de een of andere manier nog moeten worden aangepakt.
Het thematische deel van het artikel is dus voltooid, laten we verder gaan met vragen die vrij vaak voorkomen.
Veel gestelde vragen
– Als alle partijen bij een bestaand slim contract de voorwaarden willen wijzigen, kunnen ze dit slimme contract dan opzeggen met behulp van multisig, en vervolgens een nieuw slim contract creëren met bijgewerkte uitvoeringsvoorwaarden?
Het antwoord hier zal tweeledig zijn. Waarom? Omdat aan de ene kant een slim contract één keer wordt gedefinieerd en het geen wijzigingen meer impliceert, en aan de andere kant vooraf geschreven logica kan hebben die voorziet in een volledige of gedeeltelijke wijziging van sommige voorwaarden. Dat wil zeggen: als u iets wilt wijzigen in uw slimme contract, dan moet u de voorwaarden voorschrijven waaronder u deze voorwaarden kunt bijwerken. Dienovereenkomstig kan de verlenging van het contract alleen op een dergelijke voorzichtige manier worden georganiseerd. Maar ook hier kun je in de problemen komen: maak een fout en krijg een overeenkomstige kwetsbaarheid. Daarom moeten dergelijke dingen zeer gedetailleerd en zorgvuldig worden ontworpen en getest.
— Wat als de mediator een overeenkomst sluit met een van de deelnemende partijen: escrow of smart contract? Is een bemiddelaar vereist bij een slim contract?
Bij een slim contract is een bemiddelaar niet vereist. Het bestaat misschien niet. Als de bemiddelaar in het geval van escrow een samenzwering aangaat met een van de partijen, ja, dan verliest dit plan scherp al zijn waarde. Daarom worden mediators zo geselecteerd dat ze tegelijkertijd vertrouwd worden door alle partijen die bij dit proces betrokken zijn. Dienovereenkomstig zult u eenvoudigweg geen munten overmaken naar een adres met meerdere handtekeningen bij een bemiddelaar die u niet vertrouwt.
— Is het mogelijk om met één Ethereum-transactie veel verschillende tokens van uw adres naar verschillende doeladressen over te dragen, bijvoorbeeld uitwisselingsadressen waar deze tokens worden verhandeld?
Dit is een goede vraag en gaat over het Ethereum-transactiemodel en hoe dit verschilt van het Bitcoin-model. En het verschil is radicaal. Als u in het Ethereum-transactiemodel eenvoudigweg munten overdraagt, worden ze alleen van het ene adres naar het andere overgedragen, zonder enige wijziging, alleen het specifieke bedrag dat u hebt opgegeven. Met andere woorden: dit is geen model van niet-bestede outputs (UTXO), maar een model van rekeningen en bijbehorende saldi. Het is theoretisch mogelijk om meerdere verschillende tokens in één transactie tegelijk te verzenden als je een slim slim contract schrijft, maar je zult nog steeds veel transacties moeten uitvoeren, een contract moeten maken, er vervolgens tokens en munten naartoe moeten overbrengen en vervolgens de juiste methode moeten aanroepen . Dit vergt inspanning en tijd, dus in de praktijk werkt het niet zo en worden alle betalingen in Ethereum in aparte transacties gedaan.
– Een van de mythes over het Ethereum-platform is dat het onmogelijk is omstandigheden te beschrijven die afhankelijk zijn van de gegevens van een externe internetbron, dus wat moet je dan doen?
De oplossing is dat het slimme contract zelf een of meer zogenaamde vertrouwde orakels kan bieden, die gegevens verzamelen over de stand van zaken in de buitenwereld en deze via speciale methoden doorgeven aan de slimme contracten. Het contract zelf beschouwt de gegevens die het van vertrouwde partijen heeft ontvangen als waar. Voor een grotere betrouwbaarheid kiest u eenvoudigweg een grote groep orakels en minimaliseert u het risico op samenzwering. Het contract zelf houdt mogelijk geen rekening met gegevens van orakels die de meerderheid tegenspreken.
Een van de lezingen van de online cursus over Blockchain is aan dit onderwerp gewijd: “'.
Bron: www.habr.com