In hierdie artikel gaan ons kyk na wat slim kontrakte is, wat dit is, kennis maak met verskillende slimkontrakplatforms, hul kenmerke, en ook bespreek hoe dit werk en watter voordele dit kan inhou. Hierdie materiaal sal baie nuttig wees vir lesers wat nie vertroud genoeg is met die onderwerp van slim kontrakte nie, maar nader daaraan wil kom om dit te verstaan.
Gereelde kontrak vs. slim kontrak
Voordat ons in die besonderhede ingaan, kom ons gebruik 'n voorbeeld om die verskil te verstaan tussen 'n gewone kontrak wat op papier geskryf is en 'n slim kontrak wat digitaal is.
Hoe het dit gewerk voor die koms van slim kontrakte? Stel jou 'n groep mense voor wat 'n paar reëls en voorwaardes vir die verspreiding van waardes wil daarstel, asook 'n sekere meganisme om te verseker dat hierdie verspreiding volgens die gegewe reëls en voorwaardes uitgevoer word. Toe het hulle bymekaargekom, 'n stuk papier opgestel waarop hulle hul identiteit, voorwaardes, waardes betrokke, gedateer en geteken neergeskryf het. Hierdie kontrak is ook gesertifiseer deur 'n betroubare party, soos 'n notaris. Verder het hierdie mense in verskillende rigtings versprei met hul papierkopie van so 'n kontrak en 'n paar aksies begin uitvoer wat dalk nie met die kontrak self ooreenstem nie, dit wil sê, hulle het een ding gedoen, maar op papier was dit verseker dat hulle iets moes doen heeltemal verskillend. En hoe om uit hierdie situasie te kom? Trouens, een van die groeplede moet hierdie vraestel neem, 'n paar bewyse neem, dit hof toe neem en voldoening tussen die kontrak en werklike optrede bereik. Dikwels is dit moeilik om 'n billike uitvoering van hierdie kontrak te bereik, wat tot onaangename gevolge lei.
Wat kan gesê word oor slim kontrakte? Hulle kombineer beide die vermoë om die bepalings van die kontrak te skryf, en die meganisme vir die streng implementering daarvan. As die voorwaardes gestel is en die ooreenstemmende transaksie of versoek onderteken is, is dit nie meer moontlik om die voorwaardes te verander of die implementering daarvan te beïnvloed na aanvaarding van hierdie versoek of transaksie nie.
Daar is een valideerder of 'n hele netwerk, sowel as 'n databasis wat alle slim kontrakte wat uitgevoer moes word in streng chronologiese volgorde stoor. Dit is ook belangrik dat hierdie databasis alle sneller voorwaardes vir die uitvoering van 'n slim kontrak moet bevat. Daarbenewens moet dit die einste waarde in ag neem, waarvan die verspreiding in die kontrak beskryf word. As dit oor 'n digitale geldeenheid gaan, moet hierdie databasis dit in ag neem.
Met ander woorde, slimkontrakvalideerders moet toegang hê tot al die data waarop die slimkontrak funksioneer. Byvoorbeeld, een databasis moet gebruik word om gelyktydig rekening te hou met digitale geldeenhede, gebruikerssaldo's, gebruikerstransaksies en tydstempels. Dan, in 'n slim kontrak, kan die toestand die gebruiker se balans in 'n sekere geldeenheid, die aanvang van 'n geruime tyd of die feit van 'n sekere transaksie wees, maar niks meer nie.
Definisie van 'n slim kontrak
Oor die algemeen is die terminologie self deur navorser Nick Szabo geskep en die eerste keer in 1994 toegepas, en is in 1997 gedokumenteer in 'n artikel wat die idee van slim kontrakte beskryf.
Slim kontrakte impliseer dat 'n mate van outomatisering van die verspreiding van waarde uitgevoer word, wat slegs kan afhang van daardie voorwaardes wat vooraf opgestel is. Op sy eenvoudigste lyk dit soos 'n kontrak met streng gedefinieerde voorwaardes, wat deur sekere partye onderteken word.
Slim kontrakte is ontwerp om vertroue in derde partye te verminder. Soms word die besluitnemingsentrum waarvan alles afhang, heeltemal uitgesluit. Daarbenewens is sulke kontrakte makliker om te oudit. Dit is 'n gevolg van sommige ontwerpkenmerke van so 'n stelsel, maar meestal verstaan ons 'n slim kontrak as 'n gedesentraliseerde omgewing en die teenwoordigheid van funksies wat enigiemand toelaat om die databasis te ontleed en 'n volledige oudit van die uitvoering van kontrakte uit te voer. Op hierdie manier word beskerming teen terugwerkende veranderinge aan die data, wat veranderinge in die uitvoering van die kontrak self sal meebring, gewaarborg. Digitalisering van die meeste prosesse tydens die skepping en bekendstelling van 'n slim kontrak vergemaklik dikwels die tegnologie en die koste van die implementering daarvan.
'N Eenvoudige voorbeeld - Escrow diens
Kom ons kyk na 'n baie eenvoudige voorbeeld. Dit sal jou help om nader te kom om die funksionaliteit van slim kontrakte te verstaan, asook om beter te verstaan wanneer dit gebruik moet word.
Dit kan ook met Bitcoin geïmplementeer word, hoewel Bitcoin tans kwalik 'n volwaardige platform vir slim kontrakte genoem kan word. So, ons het 'n koper en daar is 'n aanlyn winkel. 'n Kliënt wil 'n monitor by hierdie winkel koop. In die eenvoudigste geval stel die koper 'n betaling op en stuur dit, en die aanlynwinkel aanvaar dit, bevestig dit en stuur dan die goedere. In hierdie situasie is daar egter 'n behoefte aan groot vertroue - die koper moet die aanlyn winkel vertrou vir die hele koste van die monitor. Aangesien die aanlynwinkel 'n lae reputasie in die oë van die koper kan hê, is daar 'n risiko dat die winkel om een of ander rede, nadat die betaling aanvaar is, diens sal weier en nie die goedere aan die koper sal stuur nie. Daarom vra die koper (onderskeidelik, die aanlynwinkel vra hierdie vraag) wat in hierdie geval toegepas kan word om sulke risiko's te minimaliseer en sulke transaksies meer betroubaar te maak.
In die geval van Bitcoin kan die koper en verkoper die geleentheid gebied word om onafhanklik 'n bemiddelaar te kies. Daar is baie mense wat betrokke is by die oplossing van kontroversiële kwessies. En ons deelnemers kan uit die algemene lys bemiddelaars die een kies wat hulle terselfdertyd sal vertrou. Saam skep hulle 'n multihandtekeningadres 2 van 3 waar daar drie sleutels is en twee handtekeninge met enige twee sleutels nodig is om munte vanaf daardie adres te spandeer. Een sleutel sal aan die koper behoort, die tweede - aan die aanlynwinkel, en die derde - aan die bemiddelaar. En die koper sal die bedrag wat nodig is om vir die monitor te betaal na so 'n multisignature-adres stuur. Nou, wanneer die verkoper sien dat die geld vir 'n geruime tyd op die multisignature-adres geblokkeer is, wat van hom afhang, kan hy die monitor veilig per pos stuur.
Verder ontvang die koper die pakkie, inspekteer die goedere en neem 'n besluit oor die finale aankoop. Hy kan ten volle saamstem met die diens wat gelewer word en die transaksie met sy sleutel onderteken, waar hy die munte van die multisignature-adres na die verkoper oordra, of hy kan met iets ontevrede wees. In die tweede geval kontak hy die bemiddelaar om 'n alternatiewe transaksie saam te stel wat hierdie munte op 'n ander manier sal versprei.
Kom ons sê die monitor het 'n bietjie gekrap aangekom en die kabel om aan die rekenaar te koppel was nie by die stel ingesluit nie, alhoewel daar op die webwerf van die aanlynwinkel geskryf is dat die kabel by die stel ingesluit moet word. Dan samel die koper die bewyse in wat nodig is om aan die bemiddelaar te bewys dat hy in hierdie situasie mislei is: hy neem skermskote van die webwerf, neem 'n foto van die kwitansie uit die pos, neem 'n foto van skrape op die monitor en wys dat die seël was gebreek en die kabel is uitgetrek. Die aanlynwinkel samel op sy beurt sy bewyse in en gee dit aan die bemiddelaar deur.
Die bemiddelaar stel daarin belang om beide die verontwaardiging van die koper en die belange van die aanlynwinkel terselfdertyd te bevredig (dit sal later duidelik wees hoekom). Hy maak 'n transaksie waarin munte met 'n multisignature-adres in 'n mate tussen die koper, die aanlynwinkel en die bemiddelaar bestee sal word, aangesien hy 'n deel neem as 'n beloning vir sy werk. Kom ons sê 90% van die totale bedrag gaan na die verkoper, 5% aan die bemiddelaar en 5% van die vergoeding aan die koper. Die bemiddelaar teken hierdie transaksie met sy sleutel, maar dit kan nog nie toegepas word nie, want dit vereis twee handtekeninge, en slegs een koste. Hy stuur so 'n transaksie aan beide die koper en die verkoper. As ten minste een van hulle tevrede is met hierdie opsie om munte te herverdeel, sal die transaksie vooraf onderteken en na die netwerk versprei word. Vir die bekragtiging daarvan is dit genoeg dat een van die deelnemers aan die transaksie saamstem met die bemiddelaar se opsie.
Terselfdertyd is dit belangrik om aanvanklik ’n bemiddelaar te kies sodat beide deelnemers hom vertrou. In hierdie geval sal hy onafhanklik van die belange van die een of die ander optree en die situasie objektief beoordeel. As die bemiddelaar nie so 'n opsie bied vir die verspreiding van munte wat ten minste een deelnemer tevrede sal stel nie, kan beide die koper en die aanlynwinkel, nadat hulle saam ooreengekom het, die munte na 'n nuwe multihandtekeningadres stuur deur hul twee handtekeninge te plaas. 'n Nuwe multihandtekeningadres sal saam met 'n ander bemiddelaar opgestel word, wat dalk meer bevoeg is in die saak en 'n beter opsie bied.
Voorbeeld met 'n koshuis en 'n yskas
Kom ons kyk na 'n meer komplekse voorbeeld wat die vermoëns van 'n slim kontrak meer eksplisiet vertoon.
Kom ons sê daar is drie ouens wat onlangs in dieselfde koshuiskamer ingetrek het. Hulle drie stel belang om 'n yskas vir hul kamer te koop, wat hulle sal deel. Een van hulle het vrywillig aangebied om die nodige bedrag in te samel om 'n yskas te koop en met die verkoper te onderhandel. Hulle het mekaar egter relatief onlangs ontmoet en daar is nie voldoende vertroue tussen hulle nie. Dit is duidelik dat twee van hulle risiko's neem deur geld aan die derde te gee. Daarbenewens moet hulle 'n ooreenkoms bereik oor die keuse van die verkoper.
Hulle kan die borgdiens gebruik, dit wil sê, kies 'n bemiddelaar wat die uitvoering van die transaksie sal beheer en dispute sal besleg, indien enige. Dan, nadat hulle ooreengekom het, stel hulle 'n slim kontrak op en skryf sekere voorwaardes daarin voor.
Die eerste voorwaarde is dat voor 'n sekere tyd, kom ons sê binne een week, die ooreenstemmende slimkontrakrekening drie betalings van sekere adresse moet ontvang vir 'n sekere bedrag. As dit nie gebeur nie, stop die slim kontrak die uitvoering daarvan en gee die munte aan alle deelnemers terug. As aan die voorwaarde voldoen word, word die waardes van die identifiseerders van die verkoper en die bemiddelaar gestel, en die voorwaarde word nagegaan dat alle deelnemers saamstem met die keuse van die verkoper en die bemiddelaar. Wanneer aan alle voorwaardes voldoen word, sal die fondse na die gespesifiseerde adresse oorgeplaas word. So 'n benadering kan deelnemers van enige kant teen bedrog beskerm en skakel in die algemeen die behoefte aan vertroue uit.
In hierdie voorbeeld sien ons die beginsel dat so 'n geleentheid om parameters stap vir stap te stel vir die vervulling van elke voorwaarde, jou toelaat om stelsels van enige kompleksiteit en diepte van geneste vlakke te skep. Daarbenewens kan jy eers die eerste voorwaarde in die slim kontrak definieer, en eers nadat dit vervul is, die parameters vir die volgende voorwaarde stel. Met ander woorde, die toestand word formeel voorgeskryf, en die parameters daarvoor kan reeds tydens die werking daarvan ingestel word.
Klassifikasie van slim kontrakte
Vir klassifikasie kan jy verskillende groepe kriteria stel. Op die oomblik van tegnologie-ontwikkeling is vier van hulle egter relevant.
Slim kontrakte kan onderskei word deur hul uitvoeringsomgewing, wat óf gesentraliseerd óf gedesentraliseerd kan wees. In die geval van desentralisasie het ons baie groter onafhanklikheid en foutverdraagsaamheid wanneer ons slim kontrakte uitvoer.
Hulle kan ook onderskei word deur die proses om voorwaardes te stel en na te kom: hulle kan arbitrêr programmeerbaar, beperk of vooraf ingestel wees, dit wil sê, sterk getik. Wanneer daar slegs 4 gedefinieerde slimkontrakte op die slimkontrakplatform is, kan die parameters daarvoor arbitrêr gestel word. Gevolglik is dit baie makliker om dit op te stel: ons kies 'n kontrak uit die lys en slaag parameters.
Volgens die metode van inisiëring is daar outomatiese slim kontrakte, dit wil sê wanneer sekere toestande voorkom, is hulle selfuitvoerend, en daar is kontrakte waarin die voorwaardes gestel word, maar die platform kontroleer nie outomaties die uitvoering daarvan nie, hiervoor hulle moet afsonderlik geïnisieer word.
Boonop verskil slim kontrakte wat privaatheid betref. Hulle kan óf heeltemal oop, óf gedeeltelik, óf heeltemal vertroulik wees. Laasgenoemde beteken dat derdeparty-waarnemers nie die bepalings van slim kontrakte sien nie. Die onderwerp van privaatheid is egter baie wyd en word die beste apart van die huidige artikel hanteer.
Hieronder gaan ons in meer besonderhede stilstaan by die eerste drie kriteria om meer duidelikheid te bring in die verstaan van die huidige onderwerp.
Slim kontrakte volgens looptyd
Volgens die uitvoeringsomgewing word gesentraliseerde en gedesentraliseerde slimkontrakplatforms onderskei. In die geval van gesentraliseerde digitale kontrakte word 'n enkele diens gebruik waar daar net een valideerder is en daar kan 'n rugsteun- en hersteldiens wees wat ook sentraal bestuur word. Daar is een databasis wat al die nodige inligting stoor om die voorwaardes vir 'n slim kontrak te stel en die waarde te versprei wat in hierdie einste databasis van die diens in ag geneem word. So 'n gesentraliseerde diens het 'n kliënt wat op sekere versoeke die voorwaardes stel en sulke kontrakte gebruik. As gevolg van die feit dat die platform gesentraliseerd is, kan verifikasiemeganismes minder betroubaar wees as in kripto-geldeenhede.
As voorbeeld kan jy mobiele kommunikasieverskaffers (verskillende selfoonoperateurs) neem. Gestel 'n sekere operateur hou rekords van verkeer op sy bedieners op 'n gesentraliseerde wyse, wat in verskillende formate versend kan word, byvoorbeeld: in die vorm van stemoproepe, SMS-versending, mobiele internetverkeer, en volgens verskillende standaarde, en hou ook rekords van fondse op gebruikerssaldo's. Gevolglik kan die selfoonkommunikasieverskaffer kontrakte opstel vir die verantwoording van die dienste wat gelewer word en die betaling daarvan met verskillende voorwaardes. In hierdie geval word voorwaardes maklik gestel soos "stuur 'n SMS met so en so 'n kode na so en so 'n nommer en jy sal sulke en sulke voorwaardes vir verkeersverspreiding ontvang".
Nog 'n voorbeeld kan gegee word: tradisionele banke met gevorderde internetbankfunksies en baie eenvoudige kontrakte soos gereelde betalings, outomatiese omskakeling van inkomende betalings, outomatiese aftrekking van rente na 'n gespesifiseerde rekening, ens.
As ons praat van slim kontrakte met 'n gedesentraliseerde uitvoeringsomgewing, dan het ons 'n groep valideerders. Ideaal gesproke kan enigiemand 'n valideerder word. As gevolg van die databasissinchronisasieprotokol en die bereiking van konsensus, het ons 'n algemene databasis wat nou alle transaksies met streng beskryfde kontrakte sal stoor, en nie 'n paar voorwaardelike versoeke nie, waarvan die formate dikwels verander, en daar is geen oop spesifikasie nie. Hier sal die transaksies instruksies bevat vir die uitvoering van die kontrak volgens 'n streng spesifikasie. Hierdie spesifikasie is oop en daarom kan platformgebruikers self slim kontrakte oudit en valideer. Hier sien ons dat gedesentraliseerde platforms beter is as gesentraliseerde platforms in terme van onafhanklikheid en foutverdraagsaamheid, maar hul ontwerp en instandhouding is baie moeiliker.
Slim kontrakte deur voorwaardes te stel en na te kom
Kom ons kyk nou van nader na hoe slim kontrakte kan verskil in die manier waarop hulle voorwaardes stel en nakom. Hier gee ons aandag aan slim kontrakte wat arbitrêr programmeerbaar is en Turing voltooi is. 'n Turing-volledige slimkontrak stel jou in staat om byna enige algoritmes as voorwaardes vir die uitvoering van die kontrak te stel: skryf siklusse voor, sommige funksies vir die berekening van waarskynlikhede, en dies meer - tot by jou eie digitale handtekeningalgoritmes. In hierdie geval bedoel ons werklik arbitrêre skryf van logika.
Daar is ook arbitrêre slim kontrakte, maar nie volledige Turing nie. Dit sluit Bitcoin en Litecoin met hul eie skrif in. Dit beteken dat jy slegs sekere bewerkings in 'n arbitrêre volgorde kan gebruik, maar jy kan nie meer siklusse en jou eie algoritmes skryf nie.
Daarbenewens is daar slimkontrakplatforms wat voorafbepaalde slimkontrakte implementeer. Dit sluit Bitshares en Steemit in. Bitshares het 'n reeks slim kontrakte vir verhandeling, bestuur van rekeninge, bestuur van die platform self en sy parameters. Steemit is 'n soortgelyke platform, maar dit is nie meer gefokus op die uitreiking van tokens en handel, soos Bitshares nie, maar op blog, dit wil sê dit stoor en verwerk inhoud op 'n gedesentraliseerde manier.
Arbitrêre Turing-volledige kontrakte sluit die Ethereum-platform en RootStock in, wat nog in ontwikkeling is. Daarom sal ons verder stilstaan by die Ethereum-slimkontrakplatform in 'n bietjie meer besonderhede.
Slim kontrakte volgens inisiasiemetode
Volgens die metode van inisiëring kan slim kontrakte ook in ten minste twee groepe verdeel word: outomaties en handmatig (nie outomaties nie). Vir geoutomatiseerdes is dit tipies dat met al die bekende parameters en die voorwaardes wat gekom het, die slim kontrak outomaties ten volle uitgevoer word, dit wil sê dat dit nie nodig is om enige bykomende transaksies te stuur en 'n bykomende kommissie op elke volgende uitvoering te spandeer nie. Die platform self het al die data om te bereken hoe die slim kontrak sal eindig. Die logika daar is nie arbitrêr nie, maar voorafbepaald en dit alles is voorspelbaar. Dit wil sê, dit is moontlik om die kompleksiteit van die uitvoering van 'n slim kontrak vooraf te skat, 'n soort konstante kommissie daarvoor te gebruik, en alle prosesse vir die implementering daarvan word op 'n meer doeltreffende manier uitgevoer.
Vir slim kontrakte wat arbitrêr geprogrammeer is, word uitvoering nie geoutomatiseer nie. Om so 'n slim kontrak te inisieer, in werklikheid, by elke stap, moet jy 'n nuwe transaksie skep wat die volgende uitvoeringstadium of die volgende slimkontrakmetode sal oproep, die toepaslike fooi betaal en wag vir die transaksie om bevestig te word. Die uitvoering kan of mag nie slaag nie, want die slimkontrakkode is arbitrêr en sommige onvoorspelbare oomblikke kan voorkom, soos 'n ewige lus, gebrek aan sekere parameters en argumente, onverhandelde uitsonderlike oomblikke, ens.
Rekeninge in Ethereum
Tipes Ethereum-rekeninge
Oorweeg watter rekeninge op die Ethereum-platform kan wees. Daar is net twee tipes rekeninge en daar is geen ander opsies nie. Die eerste tipe word 'n gebruikersrekening genoem, die tweede is 'n kontrakrekening. Kom ons kyk hoe hulle verskil.
Die gebruikersrekening word slegs deur die persoonlike sleutel van die elektroniese handtekening bestuur. Die rekeningeienaar genereer sy/haar elektroniese handtekeningsleutelpaar deur die ECDSA (Elliptic Curve Digital Signature Algorithm) algoritme te gebruik. Slegs transaksies wat deur hierdie sleutel onderteken is, kan die toestand van hierdie rekening verander.
'n Aparte logika word voorsien vir die slimkontrakrekening. Dit kan slegs beheer word deur 'n voorafbepaalde programkode wat die gedrag van die slimkontrak heeltemal bepaal: hoe dit onder sekere omstandighede van sy munte ontslae raak, op inisiatief van watter gebruiker en onder watter bykomende voorwaardes hierdie munte versprei sal word. As sommige punte nie deur die ontwikkelaars in die programkode verskaf word nie, kan probleme ontstaan. Byvoorbeeld, 'n slim kontrak kan 'n spesifieke toestand ontvang waarin dit nie die aanvang van verdere uitvoering van enige van die gebruikers aanvaar nie. In hierdie geval sal die munte eintlik gevries word, want die slim kontrak maak nie voorsiening vir 'n uitgang uit hierdie staat nie.
Hoe Ethereum-rekeninge geskep word
In die geval van 'n gebruikersrekening, genereer die eienaar onafhanklik 'n sleutelpaar deur gebruik te maak van ECDSA. Dit is belangrik om daarop te let dat Ethereum presies dieselfde algoritme en presies dieselfde elliptiese kurwe vir elektroniese handtekening as Bitcoin gebruik, maar die adres word op 'n effens ander manier bereken. Hier word die resultaat van dubbele hashing nie meer toegepas nie, soos in Bitcoin, maar 'n enkele hashing deur die Keccak-funksie word voorsien vir 'n lengte van 256 bisse. Die minste betekenisvolle bisse word van die ontvangde waarde afgesny, naamlik die 160 minste betekenisvolle bisse van die uitsetwaarde van die hash-funksie. As gevolg hiervan kry ons 'n adres in Ethereum. Trouens, dit neem 20 grepe.
Let daarop dat die Ethereum-rekening-ID in hex geënkodeer word sonder 'n kontrolesom, anders as Bitcoin en baie ander stelsels, waar die adres in basis 58 geënkodeer is met die byvoeging van 'n kontrolesom. Dit beteken dat jy versigtig moet wees wanneer jy met Ethereum-rekeningidentifiseerders werk: selfs een fout in die identifiseerder is gewaarborg om tot die verlies van munte te lei.
Daar is 'n belangrike kenmerk en dit lê in die feit dat 'n gebruikersrekening op die vlak van die algemene databasis geskep word op die oomblik wanneer hy die eerste inkomende betaling aanvaar.
Met betrekking tot die skep van 'n slim kontrakrekening, word 'n heeltemal ander benadering gevolg. Aanvanklik skryf een van die gebruikers die bronkode van die slim kontrak, waarna die kode deur 'n samesteller spesiaal vir die Ethereum-platform gestuur word, wat die greepkode vir sy eie Ethereum virtuele masjien verkry. Die gevolglike greepkode word in 'n spesiale transaksieveld geplaas. Dit word namens die inisieerder se rekening gesertifiseer. Vervolgens versprei hierdie transaksie oor die netwerk en plaas die slimkontrakkode. Die kommissie vir die transaksie en gevolglik vir die uitvoering van die kontrak word uit die saldo van die inisieerder se rekening verwyder.
Elke slim kontrak moet sy eie konstruktor (van hierdie kontrak) bevat. Dit kan leeg wees of dit kan inhoud hê. Nadat die konstruktor uitgevoer is, word 'n slimkontrakrekening-ID geskep, waarmee u munte kan stuur, sekere slimkontrakmetodes kan noem, ens.
Ethereum transaksie struktuur
Om dit duideliker te maak, sal ons begin kyk na die struktuur van 'n Ethereum-transaksie en 'n voorbeeld van slimkontrakkode.
'N Ethereum-transaksie bestaan uit verskeie velde. Die eerste van hulle is 'n nonce - dit is 'n reeksnommer van die transaksie relatief tot die rekening self, wat dit versprei en die outeur daarvan is. Dit is nodig om tussen duplikaattransaksies te onderskei, dit wil sê om die geval uit te sluit wanneer dieselfde transaksie twee keer aanvaar word. Deur die gebruik van 'n identifiseerder het elke transaksie 'n unieke hash-waarde.
Dit word gevolg deur 'n veld soos gasprys. Dit is die prys waarteen die Ethereum-basisgeldeenheid in gas omgeskakel word, wat betaal vir die uitvoering van 'n slim kontrak en die toewysing van 'n virtuele masjienhulpbron. Wat beteken dit?
In Bitcoin word fooie direk deur die basisgeldeenheid, Bitcoin self, betaal. Dit is moontlik danksy 'n eenvoudige meganisme om dit te bereken: ons betaal streng vir die hoeveelheid data wat in die transaksie vervat is. In Ethereum is die situasie meer ingewikkeld, want dit is baie moeilik om op die volume transaksiedata te bou. Hier kan die transaksie steeds programkode bevat wat op die virtuele masjien sal loop, en elke operasie van die virtuele masjien kan verskillende kompleksiteit hê. Daar is ook bewerkings wat geheue vir veranderlikes toeken. Hulle sal hul eie kompleksiteit hê, waarvan die betaling vir elke operasie sal afhang.
Die koste van elke operasie in gasekwivalent sal konstant wees. Dit word spesifiek ingestel om die konstante koste van elke operasie te bepaal. Afhangende van die las op die netwerk, sal die gasprys verander, dit wil sê die koëffisiënt waarvolgens die basisgeldeenheid in hierdie hulpeenheid omgeskakel sal word om die kommissie te betaal.
Daar is nog een kenmerk van 'n transaksie in Ethereum: die greepkode wat dit bevat vir uitvoering in 'n virtuele masjien sal uitgevoer word totdat dit voltooi is met 'n resultaat (sukses-misluk) of totdat 'n sekere aantal munte toegeken is om 'n kommissie te betaal. Dit is om die situasie te vermy wanneer al die munte bestee is op 'n kommissie van die sender se rekening in die geval van een of ander fout (byvoorbeeld, 'n soort ewige siklus wat in 'n virtuele masjien begin is), is daar die volgende veld - begin gas (dikwels gaslimiet genoem) - dit bepaal die maksimum hoeveelheid munte wat die sender bereid is om te spandeer om 'n sekere transaksie te voltooi.
Die volgende veld word genoem bestemmingsadres. Dit sluit in die adres van die ontvanger van die munte of die adres van 'n spesifieke slim kontrak wie se metodes genoem sal word. Dit word gevolg deur 'n veld waarde, waar die hoeveelheid munte wat na die bestemmingsadres gestuur word, ingevoer word.
Volgende is 'n interessante veld genoem data, waar die hele struktuur pas. Dit is nie 'n aparte veld nie, maar 'n hele struktuur waarin die kode vir die virtuele masjien gedefinieer word. Jy kan arbitrêre data hier plaas - daar is aparte reëls hiervoor.
En die laaste veld word genoem handtekening. Dit bevat gelyktydig beide die elektroniese handtekening van die outeur van hierdie transaksie en die publieke sleutel wat gebruik sal word om hierdie handtekening te verifieer. Van die publieke sleutel kan jy die identifiseerder van die sender se rekening van hierdie transaksie kry, dit wil sê, die sender se rekening uniek in die stelsel self identifiseer. Deur die struktuur van die transaksie het ons die belangrikste ding uitgevind.
Solidity slim kontrak kode voorbeeld
Kom ons kyk nou van naderby na die eenvoudigste slim kontrak deur 'n voorbeeld te gebruik.
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);
}
}Hierbo is 'n vereenvoudigde bronkode wat gebruikers se munte kan hou en dit op aanvraag kan terugbesorg.
So, daar is 'n Bank slim kontrak wat die volgende funksies verrig: dit versamel munte op sy saldo, dit wil sê wanneer 'n transaksie bevestig word en so 'n slim kontrak geplaas word, word 'n nuwe rekening geskep wat munte op sy saldo kan bevat; dit onthou gebruikers en die verspreiding van munte tussen hulle; het verskeie metodes om saldo's te bestuur, dit wil sê, dit is moontlik om die gebruiker se balans aan te vul, te onttrek en na te gaan.
Kom ons gaan deur elke reël van die bronkode. Hierdie kontrak het konstante velde. Een van hulle, met tipe adres, word eienaar genoem. Hier onthou die kontrak die adres van die gebruiker wat hierdie slim kontrak geskep het. Vervolgens is daar 'n dinamiese struktuur wat die korrespondensie tussen gebruikersadresse en -balanse stoor.
Daarna volg die Bank-metode - dit word dieselfde as die kontrak genoem. Gevolglik is dit sy konstruktor. Hier word aan die eienaarveranderlike die adres toegeken van die persoon wat hierdie slimkontrak op die netwerk geplaas het. Dit is die enigste ding wat in hierdie konstruktor gebeur. Dit wil sê, boodskap in hierdie geval is presies die data wat na die virtuele masjien oorgedra is saam met die transaksie wat die hele kode van hierdie kontrak bevat. Gevolglik is msg.sender die outeur van hierdie transaksie, wat hierdie kode plaas. Hy sal die eienaar van die slim kontrak wees.
Die deposito-metode laat jou toe om 'n sekere aantal munte in 'n transaksie na 'n kontrakrekening oor te dra. In hierdie geval laat die slim kontrak, wanneer hierdie munte ontvang word, hulle op sy balans, maar teken in die saldostruktuur aan wie presies die sender van hierdie munte was om te weet aan wie hulle behoort.
Die volgende metode word onttrek genoem en dit neem een parameter - die hoeveelheid munte wat iemand by hierdie bank wil onttrek. Hier is 'n kontrole of daar genoeg munte op die balans van die gebruiker is wat hierdie metode aanroep om dit te stuur. As daar genoeg van hulle is, gee die slim kontrak self hierdie aantal munte aan die beller terug.
Vervolgens kom die metode om die gebruiker se huidige balans na te gaan. Wie hierdie metode noem, sal gebruik word om hierdie balans in die slim kontrak te kry. Dit is opmerklik dat die wysiger van hierdie metode siening is. Dit beteken dat die metode self nie die veranderlikes van sy klas op enige manier verander nie, en dit is in werklikheid slegs 'n leesmetode. 'n Afsonderlike transaksie word nie geskep om hierdie metode te noem nie, geen fooi word betaal nie, en alle berekeninge word plaaslik uitgevoer, waarna die gebruiker die resultaat ontvang.
Die doodmaakmetode is nodig om die toestand van die slim kontrak te vernietig. En hier word 'n bykomende tjek geskryf, of die oproeper van hierdie metode die eienaar van hierdie kontrak is. As dit so is, vernietig die kontrak self, en die vernietigingsfunksie neem een parameter - die rekening-ID waarheen die kontrak al die munte wat op sy balans oorbly, sal stuur. In hierdie geval sal die oorblywende munte outomaties na die adres van die kontrakeienaar gaan.
Hoe werk 'n volledige nodus van die Ethereum-netwerk?
Kom ons kyk skematies hoe sulke slim kontrakte op die Ethereum-platform uitgevoer word en hoe 'n volledige netwerknodus werk.
'n Volledige Ethereum-netwerknodus moet ten minste vier modules hê.
Die eerste, soos vir enige gedesentraliseerde protokol, is die P2P-netwerkmodule - 'n module vir netwerk en werk met ander nodusse, waar blokke, transaksies en inligting oor ander nodusse uitgeruil word. Dit is 'n tradisionele komponent vir alle gedesentraliseerde kripto-geldeenhede.
Vervolgens het ons 'n module vir die stoor van blokkettingdata, verwerking, kies van 'n prioriteitstak, voeg blokke by, onthaak blokke, kontroleer hierdie blokke, ens.
Die derde module word genoem EVM (Ethereum virtuele masjien) - dit is die virtuele masjien wat die greepkode van Ethereum-transaksies ontvang. Hierdie module neem die huidige toestand van 'n spesifieke rekening en voer veranderinge aan sy toestand uit op grond van die ontvang greepkode. Die weergawe van die virtuele masjien op elke gasheer moet dieselfde wees. Die berekeninge vind plaas op elk van die Ethereum nodusse is presies dieselfde, maar hulle vind plaas in 'n asynchrone volgorde: iemand kontroleer en aanvaar hierdie transaksie vroeër, dit wil sê, dit voer al die kode wat daarin vervat is, en iemand later. Gevolglik, wanneer 'n transaksie geskep word, word dit na die netwerk versprei, die nodusse aanvaar dit, en ten tyde van verifikasie, net soos Bitcoin Script in Bitcoin uitgevoer word, word die greepkode van die virtuele masjien hier uitgevoer.
'n Transaksie word as geverifieer beskou as al die kode wat daarin vervat is, uitgevoer is, 'n nuwe toestand van 'n sekere rekening gegenereer en gestoor is totdat dit duidelik is of hierdie transaksie toegepas is of nie. As die transaksie toegepas word, word hierdie toestand as nie net voltooi nie, maar reeds as relevant beskou. Daar is 'n databasis wat die toestand van elke rekening vir elke netwerknodus stoor. As gevolg van die feit dat alle berekeninge dieselfde is en die toestand van die blokketting dieselfde is, sal die databasis wat die toestande van alle rekeninge bevat, ook vir elke nodus dieselfde wees.
Mites en beperkings van slim kontrakte
Wat die beperkings betref wat vir Ethereum-agtige slimkontrakplatforms bestaan, kan die volgende aangehaal word:
- kode uitvoering;
- gee geheue toe;
- blokketting data;
- stuur betalings;
- skep nuwe kontrak;
- bel ander kontrakte.
Kom ons kyk na die beperkings wat op 'n virtuele masjien opgelê word en dienooreenkomstig sommige mites oor slim kontrakte uit die weg ruim. Op 'n virtuele masjien, wat nie net in Ethereum kan wees nie, maar ook in soortgelyke platforms, kan jy werklik arbitrêre logiese bewerkings uitvoer, dit wil sê, kode skryf en dit sal daar uitgevoer word, jy kan ook geheue toewys. Die fooi word egter afsonderlik betaal vir elke operasie en vir elke bykomende geheue-eenheid wat toegeken word.
Verder kan die virtuele masjien data van die blockchain-databasis lees om hierdie data te gebruik as 'n sneller vir die uitvoering van een of ander slim kontraklogika. Die virtuele masjien kan transaksies skep en stuur, dit kan nuwe kontrakte en oproepmetodes skep van ander slim kontrakte wat reeds op die netwerk gepubliseer is: bestaande, beskikbaar, ens.
Die mees algemene mite is dat Ethereum-slimkontrakte inligting van enige internethulpbron in hul eie terme kan gebruik. Die waarheid is dat 'n virtuele masjien nie 'n netwerkversoek na een of ander eksterne inligtingsbron op die internet kan stuur nie, dit wil sê, dit is onmoontlik om so 'n slim kontrak te skryf wat waarde tussen gebruikers sal versprei, afhangende van byvoorbeeld hoe die weer buite is , of wie in een of ander kampioenskap gewen het, of op grond van watter ander voorval in die buitewêreld gebeur het, want inligting oor hierdie voorvalle is eenvoudig nie in die databasis van die platform self nie. Dit wil sê, daar is niks in die blokketting hieroor nie. As dit nie daar verskyn nie, kan die virtuele masjien nie hierdie data as snellers gebruik nie.
Nadele van Ethereum
Kom ons lys die belangrikstes. Die eerste nadeel is dat daar 'n paar probleme is om slim kontrakte in Ethereum te ontwerp, te ontwikkel en te toets (Ethereum gebruik die Solidity-taal om slim kontrakte te skryf). Die praktyk toon inderdaad dat 'n baie groot persentasie van alle foute aan die menslike faktor behoort. Dit is eintlik waar vir reeds geskrewe Ethereum-slimkontrakte, wat van medium of hoër kompleksiteit is. As vir eenvoudige slim kontrakte die waarskynlikheid van 'n fout klein is, dan is daar in komplekse slim kontrakte baie dikwels foute wat lei tot diefstal van fondse, tot hul bevriesing, tot die vernietiging van slim kontrakte op 'n onverwagte manier, ens. Baie sulke gevalle reeds bekend is.
Die tweede nadeel is dat die virtuele masjien self nie perfek is nie, aangesien dit ook deur mense geskryf word. Dit kan arbitrêre opdragte uitvoer, en dit is waar die kwesbaarheid lê: 'n aantal opdragte kan op 'n sekere manier gekonfigureer word, wat vooraf tot onvoorsiene gevolge sal lei. Dit is 'n baie komplekse area, maar daar is reeds verskeie studies wat toon dat hierdie kwesbaarhede in die huidige weergawe van die Ethereum-netwerk bestaan en dit kan lei tot die mislukking van baie slim kontrakte.
Nog 'n groot probleem, dit kan as 'n nadeel beskou word. Dit lê in die feit dat jy prakties of tegnies tot die gevolgtrekking kan kom dat as jy die greepkode van 'n kontrak saamstel wat op 'n virtuele masjien uitgevoer sal word, jy 'n spesifieke volgorde van bewerkings kan definieer. Wanneer dit in kombinasie uitgevoer word, sal hierdie bewerkings die virtuele masjien swaar laai en dit buite verhouding tot die kommissie wat betaal is vir die uitvoering van hierdie bewerkings vertraag.
In die verlede was daar reeds so 'n tydperk in die ontwikkeling van Ethereum, toe baie ouens wat die werking van die virtuele masjien in detail verstaan het, sulke kwesbaarhede gevind het. Trouens, transaksies het 'n baie klein kommissie betaal, maar het feitlik die hele netwerk baie vertraag. Hierdie probleme is baie moeilik om op te los, aangesien dit eerstens bepaal moet word, tweedens moet die prys vir die uitvoering van hierdie operasies aangepas word, en derdens moet 'n harde vurk uitgevoer word, wat beteken dat alle netwerknodusse na 'n nuwe weergawe opgedateer moet word. van die sagteware, en dan gelyktydige aktivering van hierdie veranderinge.
Wat Ethereum betref, is baie navorsing gedoen, baie praktiese ervaring is opgedoen: beide positief en negatief, maar tog is daar probleme en kwesbaarhede wat nog op een of ander manier hanteer moet word.
Dus, die tematiese deel van die artikel is voltooi, kom ons gaan oor na vrae wat gereeld opduik.
Algemene vrae
- As alle partye by 'n bestaande slim kontrak die voorwaardes wil verander, kan hulle hierdie slim kontrak kanselleer deur multi-handtekening te gebruik, en dan 'n nuwe slim kontrak met opgedateerde voorwaardes vir die uitvoering daarvan skep?
Hier is die antwoord tweeledig. Hoekom? Want aan die een kant word 'n slim kontrak een keer opgestel en dit impliseer nie meer enige veranderinge nie, en aan die ander kant kan dit vooraf gedefinieerde logika hê wat voorsiening maak vir 'n volledige of gedeeltelike verandering in sommige toestande. Dit wil sê, as jy iets in jou slimkontrak wil verander, dan moet jy die voorwaardes voorskryf waaronder jy hierdie voorwaardes kan bywerk. Dienooreenkomstig kan die hernuwing van die kontrak slegs op so 'n verstandige wyse gereël word. Maar ook hier kan u probleme ondervind: maak 'n fout en kry die ooreenstemmende kwesbaarheid. Daarom moet sulke dinge baie gedetailleerd en noukeurig ontwerp en getoets word.
— En as die bemiddelaar met een van die deelnemende partye saamspan: borg of slim kontrak? Word 'n bemiddelaar in 'n slim kontrak vereis?
Die bemiddelaar word nie in 'n slim kontrak vereis nie. Dit bestaan dalk nie. Indien, in die geval van borgstelling, die bemiddelaar met een van die partye saamspan, dan ja, hierdie skema verloor dan skerp al sy waarde. Daarom word bemiddelaars op so 'n wyse gekies dat hulle gelyktydig deur alle partye wat by hierdie proses betrokke is, vertrou word. Gevolglik sal u eenvoudig nie munte na 'n multihandtekeningadres oordra met 'n bemiddelaar wat u nie vertrou nie.
— Is dit moontlik om baie verskillende tokens van u adres na verskillende teikenadresse oor te dra, byvoorbeeld ruiladresse waar hierdie tokens verhandel word, met een Ethereum-transaksie?
Dit is 'n goeie vraag en dit gaan oor die Ethereum-transaksiemodel en hoe dit van die Bitcoin-model verskil. En die verskil is kardinaal. As u in die Ethereum-transaksiemodel net munte oordra, word dit slegs van een adres na 'n ander oorgedra, sonder verandering, net 'n spesifieke bedrag wat u gespesifiseer het. Met ander woorde, dit is nie 'n model van onbestede uitsette (UTXO) nie, maar 'n model van rekeninge en ooreenstemmende saldo's. Dit is teoreties moontlik om verskeie verskillende tokens gelyktydig in een transaksie te stuur as jy 'n moeilike slim kontrak skryf, maar jy moet steeds baie transaksies maak, 'n kontrak skep, dan tokens en munte daarheen oordra en dan die toepaslike metode oproep. Dit verg onderskeidelik moeite en tyd, in die praktyk werk dit nie so nie en alle betalings in Ethereum word in afsonderlike transaksies gemaak.
- Een van die mites oor die Ethereum-platform is dat dit onmoontlik is om sulke toestande te beskryf wat sal afhang van die data van 'n eksterne internethulpbron, wat dan?
Die oplossing is dat die slimkontrak self voorsiening kan maak vir een of meer sogenaamde vertroude orakels wat data oor die stand van sake in die buitewêreld insamel en dit deur spesiale metodes na slim kontrakte oordra. Die kontrak self beskou die data wat dit van betroubare partye ontvang het as waar. Vir groter betroubaarheid kies hulle bloot 'n groot groep orakels en verminder die risiko van hul samespanning. Die kontrak self mag nie data van orakels wat die meerderheid weerspreek, in ag neem nie.
Een van die lesings van die aanlyn kursus oor Blockchain word aan hierdie onderwerp gewy - "".
Bron: will.com