Yn dit artikel sille wy sjen wat tûke kontrakten binne, wat se binne, wy sille yn 'e kunde komme mei ferskate tûke kontraktplatfoarms, har funksjes, en ek besprekke hoe't se wurkje en hokker foardielen se kinne bringe. Dit materiaal sil heul nuttich wêze foar lêzers dy't net goed bekend binne mei it ûnderwerp fan tûke kontrakten, mar wolle tichterby it begripen komme.
Regelmjittich kontrakt vs. smart kontrakt
Foardat wy yn 'e details ferdjipje, litte wy in foarbyld nimme fan' e ferskillen tusken in gewoan kontrakt, dat op papier oanjûn is, en in tûk kontrakt, dat digitaal fertsjintwurdige is.
Hoe wurke dit foar de komst fan tûke kontrakten? Stel jo in groep minsken foar dy't bepaalde regels en betingsten foar de ferdieling fan wearden fêststelle wolle, en ek in bepaald meganisme om de útfiering fan dizze ferdieling te garandearjen neffens de opjûne regels en betingsten. Dan soene se gearkomme, in papier opstelle wêrop se har identifikaasjedetails, de betingsten, de belutsen wearden opskreaunen, datearje en tekenje. Dit kontrakt waard ek sertifisearre troch in fertroude partij, lykas in notaris. Fierder gongen dizze minsken yn ferskate rjochtingen mei har papieren kopy fan sa'n kontrakt en begûnen guon aksjes út te fieren dy't miskien net oerienkomme mei it kontrakt sels, dat is, se diene ien ding, mar op papier waard sertifisearre dat se wat dwaan moatte folslein oars. En hoe te krijen út dizze situaasje? Eins moat ien fan 'e groepsleden dit papier nimme, wat bewiis nimme, it nei de rjochtbank nimme en konformiteit berikke tusken it kontrakt en de eigentlike aksjes. Hiel faak is it dreech om earlike útfiering fan dit kontrakt te berikken, wat liedt ta onaangename gefolgen.
Wat kin sein wurde oer tûke kontrakten? Se kombinearje sawol de mooglikheid om de betingsten fan it kontrakt te skriuwen en it meganisme foar har strikte ymplemintaasje. As de betingsten ynsteld binne en de korrespondearjende transaksje of fersyk is tekene, dan is it, as dat fersyk of transaksje is akseptearre, net mear mooglik om de betingsten te feroarjen of de útfiering dêrfan te beynfloedzjen.
D'r is ien validator as in folslein netwurk, lykas ek in database dy't alle tûke kontrakten opslacht dy't yn strikte gronologyske folchoarder binne yntsjinne foar útfiering. It is ek wichtich dat dizze databank alle triggerbetingsten moat befetsje foar it útfieren fan it tûke kontrakt. Dêrneist moat it rekken hâlden wurde mei de tige wearde wêrfan de ferdieling wurdt beskreaun yn it kontrakt. As dit jildt foar guon digitale faluta, dan moat dizze databank der rekken mei hâlde.
Mei oare wurden, tûk kontraktvalidators moatte tagong hawwe ta alle gegevens wêrop it tûke kontrakt wurket. Bygelyks, in inkele database moat brûkt wurde om tagelyk rekken te hâlden mei digitale faluta, brûkerssaldo, brûkerstransaksjes en tiidstempels. Dan, yn in tûk kontrakt, kin de betingst it lykwicht fan 'e brûker wêze yn in bepaalde munt, de komst fan in bepaalde tiid, of it feit dat in bepaalde transaksje is útfierd, mar neat mear.
Definysje fan in tûk kontrakt
Yn 't algemien waard de terminology sels betocht troch ûndersiker Nick Szabo en foar it earst brûkt yn 1994, en waard dokumintearre yn 1997 yn in artikel dat it heule idee fan tûke kontrakten beskriuwt.
Slimme kontrakten betsjutte dat guon automatisearring fan weardeferdieling wurdt útfierd, dy't allinich kin ôfhingje fan dy betingsten dy't foarôf bepaald binne. Yn syn ienfâldichste foarm liket it op in kontrakt mei strikt definieare betingsten, dat wurdt tekene troch bepaalde partijen.
Slimme kontrakten binne ûntworpen om fertrouwen yn tredden te minimalisearjen. Soms is it beslútfoarmingsintrum dêr't alles fan ôfhinget folslein útsletten. Derneist binne sokke kontrakten makliker te kontrolearjen. Dit is in gefolch fan guon ûntwerpfunksjes fan sa'n systeem, mar meastentiids begripe wy troch in tûk kontrakt in desintralisearre omjouwing en de oanwêzigens fan funksjes wêrmei elkenien de databank analysearje en in folsleine kontrôle fan 'e útfiering fan kontrakten útfiere. Dit soarget foar beskerming tsjin retroaktive gegevenswizigingen dy't feroaringen yn 'e útfiering fan' e kontrakt sels meibringe. Digitalisearring fan de measte prosessen by it meitsjen en lansearjen fan in tûk kontrakt makket faak de technology en kosten fan har ymplemintaasje ferienfâldigje.
In ienfâldich foarbyld - Escrow tsjinst
Litte wy nei in heul ienfâldich foarbyld sjen. It sil jo helpe om tichter by it begripen fan 'e funksjonaliteit fan tûke kontrakten te kommen, en ek better te begripen yn hokker gefallen se moatte wurde brûkt.
It kin ek ymplementearre wurde mei Bitcoin, hoewol op it stuit Bitcoin kin noch amper wurde neamd in folweardich platfoarm foar tûke kontrakten. Dat, wy hawwe wat keaper en wy hawwe in online winkel. In klant wol in monitor keapje fan dizze winkel. Yn it ienfâldichste gefal foltôget en stjoert de keaper in betelling, en de online winkel akseptearret it, befêstiget it en ferstjoert dan it guod. Yn dizze situaasje is d'r lykwols ferlet fan grut fertrouwen - de keaper moat de online winkel fertrouwe foar de folsleine kosten fan 'e monitor. Sûnt in online winkel kin hawwe in lege reputaasje yn 'e eagen fan' e keaper, der is in risiko dat foar guon reden, nei it akseptearjen fan de betelling, de winkel sil wegerje tsjinst en sil net stjoere it guod nei de keaper. Dêrom freget de keaper de fraach (en, sadwaande, stelt de online winkel dizze fraach) wat kin tapast wurde yn dit gefal om sokke risiko's te minimalisearjen en sokke transaksjes betrouberer te meitsjen.
Yn it gefal fan Bitcoin is it mooglik om de keaper en ferkeaper selsstannich in mediator te selektearjen. D'r binne in protte minsken dy't belutsen binne by it oplossen fan kontroversjele problemen. En ús dielnimmers kinne kieze út in algemiene list fan mediators dejinge dy't se sille fertrouwe. Tegearre meitsje se in 2 fan 3 multisignature-adres wêr't trije kaaien binne en twa hantekeningen mei elke twa kaaien binne ferplicht om munten fan dat adres te besteegjen. Ien kaai sil hearre ta de keaper, de twadde nei de online winkel, en de tredde oan de mediator. En nei sa'n multisignature adres sil de keaper it bedrach stjoere dat nedich is om te beteljen foar de monitor. No, as de ferkeaper sjocht dat jild foar in skoft blokkearre is op in multisignature-adres dat fan him hinget, kin hy de monitor feilich per post stjoere.
Dêrnei krijt de keaper it pakket, ynspektearret it guod en nimt in beslút oer de definitive oankeap. Hy kin hielendal iens mei de tsjinst oanbean en tekenje de transaksje mei syn kaai, dêr't er oerstappen munten út de multisignature adres oan de ferkeaper, of hy kin wêze ûntefreden mei wat. Yn it twadde gefal kontaktet er in bemiddeler om in alternative transaksje gear te setten dy't dy munten oars ferspriedt.
Litte wy sizze dat de monitor in bytsje bekrast kaam en de kit gjin kabel omfette foar ferbining mei de kompjûter, hoewol de webside fan 'e online winkel sei dat de kabel yn' e kit moat wurde opnommen. Dan sammelet de keaper it bewiis dat nedich is om de bemiddeler te bewizen dat hy yn dizze situaasje is ferrifelje: hy nimt skermôfbyldings fan 'e side, nimt in foto fan' e postûntfangst, nimt in foto fan 'e krassen op' e monitor en lit sjen dat it segel wie brutsen en de kabel waard útlutsen. De online winkel sammelet op syn beurt syn bewiis en bringt it oer oan de mediator.
De mediator is ynteressearre yn it tagelyk befredigjen fan sawol de argewaasje fan 'e keaper as de belangen fan' e online winkel (it sil letter dúdlik wurde wêrom). It is in transaksje wêryn munten fan in multisignature-adres yn guon ferhâlding sille wurde bestege tusken de keaper, de online winkel en de mediator, om't hy in diel foar himsels nimt as beleanning foar syn wurk. Litte wy sizze dat 90% fan it totale bedrach nei de ferkeaper giet, 5% nei de mediator en 5% kompensaasje foar de keaper. De mediator tekenet dizze transaksje mei syn kaai, mar it kin noch net tapast wurde, om't it twa hantekeningen fereasket, mar mar ien is it wurdich. It stjoert sa'n transaksje nei sawol de keaper as de ferkeaper. As op syn minst ien fan harren tefreden is mei dizze opsje foar werferdieling fan munten, dan sil de transaksje foarôf tekene wurde en ferspraat oan it netwurk. Om it te falidearjen is it genôch dat ien fan 'e partijen by de transaksje it iens is mei de opsje fan' e mediator.
It is wichtich om earst in mediator te kiezen sadat beide dielnimmers him fertrouwe. Yn dit gefal, hy sil hannelje ûnôfhinklik fan de belangen fan de iene of de oare en objektyf beoardielje de situaasje. As de mediator gjin opsje biedt foar it fersprieden fan munten dy't op syn minst ien dielnimmer befredigje, dan kinne, nei't se tegearre ôfpraat binne, sawol de keaper as de online winkel de munten stjoere nei in nij multisignature-adres troch har twa hantekeningen te setten. It nije multisignature-adres sil gearstald wurde mei in oare mediator, dy't miskien mear kompetinte is yn 'e saak en in bettere opsje biedt.
Foarbyld mei in sliepkeamer en in kuolkast
Litte wy nei in komplekser foarbyld sjen dat de mooglikheden fan in tûk kontrakt mear eksplisyt toant.
Litte wy sizze dat d'r trije jonges binne dy't koartlyn ferhuze nei deselde sliepkeamer. De trije binne ynteressearre yn it keapjen fan in kuolkast foar har keamer dy't se tegearre brûke kinne. Ien fan harren joech frijwilligers oan om it nedige bedrach te sammeljen om in kuolkast te keapjen en te ûnderhanneljen mei de ferkeaper. Se moete inoar lykwols pas koartlyn en der is net genôch fertrouwen tusken har. Fansels nimme twa fan harren in risiko troch jild te jaan oan de tredde. Derneist moatte se in oerienkomst berikke by it kiezen fan in ferkeaper.
Se kinne de escrow-tsjinst brûke, dat is, kieze in mediator dy't de útfiering fan 'e transaksje kontrolearje sil en kontroversjele problemen oplosse as der ien is. Dan, nei ôfpraat, meitsje se in tûk kontrakt en skriuwe dêr bepaalde betingsten foar.
De earste betingst is dat foar in bepaalde tiid, sizze binnen ien wike, it korrespondearjende tûke kontraktkonto trije betellingen fan bepaalde adressen foar in bepaald bedrach krije moat. As dit net bart, stopet de tûke kontrakt út te fieren en jout de munten werom nei alle dielnimmers. As de betingst foldien is, dan wurde de wearden fan 'e identifier fan' e ferkeaper en mediator ynsteld, en de betingst wurdt kontrolearre dat alle dielnimmers it iens binne mei de kar fan 'e ferkeaper en mediator. As alle betingsten foldien binne, dan wurde de fûnsen oerbrocht nei de opjûne adressen. Dizze oanpak kin dielnimmers beskermje fan fraude fan elke kant en elimineert algemien de needsaak om te fertrouwen.
Wy sjogge yn dit foarbyld it prinsipe dat dizze mooglikheid om stap foar stap parameters yn te stellen foar it ferfoljen fan elke betingst kinne jo systemen meitsje fan elke kompleksiteit en djipte fan nestele nivo's. Derneist kinne jo earst de earste betingst definiearje yn 'e tûke kontrakt, en allinich nei syn ferfolling kinne jo parameters ynstelle foar de folgjende betingst. Mei oare wurden, de betingst is formeel skreaun, en parameters foar it kinne wurde ynsteld al yn syn operaasje.
Klassifikaasje fan smart kontrakten
Foar klassifikaasje kinne jo ferskate groepen kritearia ynstelle. Lykwols, op it momint fan technology ûntwikkeling, fjouwer fan harren binne relevant.
Slimme kontrakten kinne wurde ûnderskieden troch har útfieringsomjouwing, dy't sintralisearre of desintralisearre kinne wêze. Yn it gefal fan desintralisaasje hawwe wy folle gruttere ûnôfhinklikens en skuldtolerânsje by it útfieren fan tûke kontrakten.
Se kinne ek ûnderskiede wurde troch it proses fan it ynstellen en ferfoljen fan betingsten: se kinne frij programmearre wurde, beheind of foarôf definieare, dus strikt typearre. As d'r mar 4 spesifike tûke kontrakten binne op it tûke kontraktplatfoarm, kinne de parameters foar har op elke manier ynsteld wurde. Dêrtroch is it ynstellen fan se folle ienfâldiger: wy selektearje in kontrakt út 'e list en passe de parameters troch.
Neffens de inisjatyfmetoade binne d'r automatisearre tûke kontrakten, dat is, as bepaalde betingsten foarkomme, binne se selsútfierend, en d'r binne kontrakten wêryn de betingsten binne spesifisearre, mar it platfoarm kontroleart har ferfolling net automatysk; moatte apart inisjearre wurde.
Derneist ferskille tûke kontrakten yn har nivo fan privacy. Se kinne folslein iepen, foar in part of folslein fertroulik wêze. Dat lêste betsjut dat waarnimmers fan tredden de betingsten fan tûke kontrakten net sjogge. It ûnderwerp fan privacy is lykwols heul breed en it is better om it apart te beskôgjen fan it hjoeddeistige artikel.
Hjirûnder sille wy de earste trije kritearia fan tichterby besjen om mear dúdlikens te bringen yn it begryp fan it aktuele ûnderwerp.
Smart kontrakten troch runtime
Op grûn fan de útfieringsomjouwing wurdt in ûnderskied makke tusken sintralisearre en desintralisearre smart contract platfoarms. Yn it gefal fan sintralisearre digitale kontrakten wurdt ien tsjinst brûkt, wêrby't mar ien validator is en der kin in reservekopy- en hersteltsjinst wêze, dy't ek sintraal beheard wurdt. D'r is ien databank dy't alle nedige ynformaasje opslacht om de betingsten fan it tûke kontrakt yn te stellen en de wearde te fersprieden dy't yn dizze tige tsjinstdatabase wurdt rekken holden. Sa'n sintralisearre tsjinst hat in klant dy't betingsten stelt mei bepaalde oanfragen en brûkt sokke kontrakten. Troch it sintralisearre karakter fan it platfoarm kinne autentikaasjemeganismen minder feilich wêze as yn cryptocurrencies.
As foarbyld kinne wy oanbieders fan mobile kommunikaasje nimme (ferskillende mobile operators). Litte wy sizze dat in bepaalde operator in sintralisearre rekord hâldt fan ferkear op har servers, dat kin wurde oerdroegen yn ferskate formaten, bygelyks: yn 'e foarm fan stimoproppen, SMS-oerdracht, mobyl ynternetferkear, en neffens ferskate noarmen, en hâldt ek records by. fan fûnsen op brûkerssaldo. Dêrtroch kin de provider fan mobile kommunikaasje kontrakten opstelle foar it rekkenjen fan de levere tsjinsten en har betellingen mei ferskate betingsten. Yn dit gefal is it maklik om betingsten yn te stellen lykas "ferstjoere in sms mei sa'n en sa'n koade nei sa'n en sa'n nûmer en jo krije sokke en sokke betingsten foar ferkearsdistribúsje."
Noch ien foarbyld kin wurde jûn: tradisjonele banken mei útwreide funksjonaliteit fan ynternetbankieren en heul ienfâldige kontrakten lykas reguliere betellingen, automatyske konverzje fan ynkommende betellingen, automatyske ôftrek fan rinte nei in spesifisearre akkount, ensfh.
As wy it hawwe oer tûke kontrakten mei in desintralisearre útfieringsomjouwing, dan hawwe wy in groep validators. Ideal kin elkenien in validator wurde. Troch it databanksyngronisaasjeprotokol en it berikken fan konsensus hawwe wy wat mienskiplike databank dy't no alle transaksjes mei strikt beskreaune kontrakten opslaan, en net guon betingsten fragen, wêrfan de formaten faak feroarje, en d'r is gjin iepen spesifikaasje. Hjir sille transaksjes ynstruksjes befetsje om it kontrakt út te fieren neffens in strikte spesifikaasje. Dizze spesifikaasje is iepen en dêrom kinne platfoarmbrûkers sels tûke kontrakten kontrolearje en validearje. Hjir sjogge wy dat desintralisearre platfoarms superieur binne oan sintralisearre yn termen fan ûnôfhinklikens en fouttolerânsje, mar har ûntwerp en ûnderhâld binne folle komplekser.
Smart kontrakten troch de metoade fan it ynstellen en ferfoljen fan betingsten
Litte wy no in tichterby besjen hoe't tûke kontrakten kinne ferskille yn 'e manier wêrop se betingsten ynstelle en foldogge. Hjir rjochtsje wy ús oandacht op tûke kontrakten dy't willekeurich programmearre binne en Turing kompleet. In Turing-folsleine tûke kontrakt lit jo hast alle algoritmen ynstelle as betingsten foar de útfiering fan it kontrakt: skriuwsyklusen, guon funksjes foar it berekkenjen fan kânsen, en sa - direkt nei jo eigen elektroanyske hantekeningalgoritmen. Yn dit gefal bedoele wy wier willekeurich skriuwen fan logika.
D'r binne ek willekeurige tûke kontrakten, mar net folsleine Turing. Dit omfettet Bitcoin en Litecoin mei har eigen skript. Dit betsjut dat jo allinich bepaalde operaasjes yn elke folchoarder brûke kinne, mar jo kinne gjin loops en jo eigen algoritmen mear skriuwe.
Derneist binne d'r tûke kontraktplatfoarms dy't foarôf definieare tûke kontrakten ymplementearje. Dizze omfetsje Bitshares en Steemit. Bitshares hat in ferskaat oan tûke kontrakten foar hannel, akkountbehear, behear fan it platfoarm sels en har parameters. Steemit is in ferlykber platfoarm, mar it is net mear rjochte op it útjaan fan tokens en hannel, lykas Bitshares, mar op bloggen, dat wol sizze, it bewarret en ferwurket ynhâld op in desintralisearre manier.
Willekeurige Turing-folsleine kontrakten omfetsje it Ethereum-platfoarm en RootStock, dy't noch yn ûntwikkeling is. Dêrom sille wy hjirûnder in bytsje mear detaillearje oer it Ethereum smart contract platfoarm.
Smart kontrakten troch inisjatyf metoade
Op grûn fan 'e metoade fan inisjatyf kinne tûke kontrakten ek wurde ferdield yn op syn minst twa groepen: automatisearre en hânmjittich (net automatisearre). Automatisearre wurde karakterisearre troch it feit dat, jûn alle bekende parameters en betingsten, it tûke kontrakt folslein automatysk wurdt útfierd, dat is, it fereasket gjin ferstjoeren fan ekstra transaksjes en útjaan in ekstra kommisje op elke folgjende útfiering. It platfoarm sels hat alle gegevens om te berekkenjen hoe't it tûke kontrakt sil foltôgje. De logika dêr is net willekeurich, mar foarbepaald en dit alles is foarsisber. Dat is, jo kinne fan tefoaren de kompleksiteit fan it útfieren fan in tûk kontrakt skatte, brûke dêrfoar in soarte fan konstante kommisje, en alle prosessen foar de útfiering dêrfan binne effisjinter.
Foar tûke kontrakten dy't frij programmearre binne, wurdt de útfiering net automatisearre. Om sa'n tûk kontrakt te begjinnen, moatte jo by praktysk elke stap in nije transaksje meitsje, dy't de folgjende útfieringsfaze as de folgjende tûke kontraktmetoade sil neame, de passende kommisje betelje en wachtsje oant de transaksje wurdt befêstige. Utfiering kin mei súkses foltôgje of net, om't de tûke kontraktkoade willekeurich is en guon ûnfoarspelbere mominten kinne ferskine, lykas in ivige loop, in tekoart oan guon parameters en arguminten, unbehannele útsûnderings, ensfh.
Ethereum Accounts
Ethereum Account Soarten
Litte wy sjen nei hokker soarten akkounts d'r kinne wêze op it Ethereum-platfoarm. D'r binne hjir mar twa soarten akkounts en d'r binne gjin oare opsjes. It earste type wurdt in brûkersaccount neamd, it twadde is in kontraktakkount. Litte wy útfine hoe't se ferskille.
It brûkersaccount wurdt allinich kontroleare troch de persoanlike kaai fan 'e elektroanyske hantekening. De accounteigner genereart syn eigen kaaipaar foar elektroanyske hantekening mei it ECDSA (Elliptic Curve Digital Signature Algorithm) algoritme. Allinich transaksjes ûndertekene mei dizze kaai kinne de steat fan dit akkount feroarje.
In aparte logika is foarsjoen foar de smart kontrakt account. It kin allinich kontrolearre wurde troch foarôf definieare softwarekoade dy't it gedrach fan 'e tûke kontrakt folslein bepaalt: hoe't it syn munten ûnder bepaalde omstannichheden beheare sil, op inisjatyf fan hokker brûker en ûnder hokker ekstra betingsten dizze munten wurde ferdield. As guon punten net foarsjoen binne troch de ûntwikkelders yn 'e programmakoade, kinne problemen ûntstean. Bygelyks, in tûk kontrakt kin in bepaalde steat krije wêryn it net akseptearret inisjatyf fan fierdere útfiering fan ien fan 'e brûkers. Yn dit gefal sille de munten eins beferzen wurde, om't it tûke kontrakt net foarsjocht foar it ferlitten fan dizze steat.
Hoe akkounts wurde makke op Ethereum
Yn it gefal fan in brûkersaccount genereart de eigner selsstannich in kaaipaar mei ECDSA. It is wichtich om te notearjen dat Ethereum krekt itselde algoritme en krekt deselde elliptyske kromme brûkt foar elektroanyske hantekeningen as Bitcoin, mar it adres wurdt op in wat oare manier berekkene. Hjir wurdt it resultaat fan dûbele hashing net mear brûkt, lykas yn Bitcoin, mar inkele hashing wurdt foarsjoen fan de Keccak-funksje op in lingte fan 256 bits. De minst signifikante bits wurde ôfsnien fan 'e resultearjende wearde, nammentlik de minste signifikante 160 bits fan' e útfier-hashwearde. As gefolch krije wy in adres yn Ethereum. Yn feite nimt it 20 bytes op.
Tink derom dat de akkount identifier yn Ethereum is kodearre yn hex sûnder it tapassen fan in kontrôlesum, yn tsjinstelling ta Bitcoin en in protte oare systemen, wêr't it adres is kodearre yn in basis 58 nûmersysteem mei tafoeging fan in kontrôlesum. Dit betsjut dat jo foarsichtich moatte wêze as jo wurkje mei akkountidentifiers yn Ethereum: sels ien flater yn 'e identifier is garandearre om te lieden ta it ferlies fan munten.
D'r is in wichtige funksje en it is dat in brûkersaccount op it algemiene databanknivo wurdt makke op it momint dat hy de earste ynkommende betelling akseptearret.
It meitsjen fan in tûk kontraktakkount nimt in folslein oare oanpak. Yn earste ynstânsje skriuwt ien fan 'e brûkers de boarnekoade fan' e tûke kontrakt, wêrnei't de koade wurdt trochjûn troch in kompiler spesjaal foar it Ethereum-platfoarm, it krijen fan bytekoade foar har eigen Ethereum-firtuele masine. De resultearjende bytekoade wurdt pleatst yn in spesjaal fjild fan 'e transaksje. It wurdt sertifisearre út namme fan de inisjatyfnimmer account. Dêrnei wurdt dizze transaksje troch it heule netwurk propagearre en pleatst de smart kontraktkoade. De kommisje foar de transaksje en, dus, foar de útfiering fan it kontrakt wurdt ynlutsen út it saldo fan de inisjatyfnimmer account.
Elk tûk kontrakt befettet needsaaklik in eigen konstruktor (fan dit kontrakt). It kin leech wêze of it kin ynhâld hawwe. Nei't de konstruktor is útfierd, wurdt in identifier foar tûk kontraktakkount makke, wêrmei jo munten kinne stjoere, bepaalde metoaden foar tûke kontrakten neame, ensfh.
Ethereum-transaksjestruktuer
Om it dúdliker te meitsjen, sille wy begjinne te sjen nei de struktuer fan in Ethereum-transaksje en in foarbyld fan smart kontraktkoade.
In Ethereum-transaksje bestiet út ferskate fjilden. De earste fan dizze, nonce, is in bepaald serialnûmer fan 'e transaksje relatyf oan it akkount sels dat it ferspriedt en de auteur is. Dit is nedich om dûbele transaksjes te ûnderskieden, dat is, om it gefal út te sluten as deselde transaksje twa kear akseptearre wurdt. Troch in identifier te brûken, hat elke transaksje in unike hashwearde.
Folgjende komt in fjild lykas gaspriis. Dit jout de priis oan wêryn't de Ethereum-basisfaluta wurdt omboud ta gas, dy't brûkt wurdt om te beteljen foar de útfiering fan it tûke kontrakt en de allocaasje fan 'e firtuele masine-boarne. Wat betsjut dat?
Yn Bitcoin wurde fergoedingen direkt betelle troch de basisfaluta - Bitcoin sels. Dit is mooglik troch in ienfâldich meganisme foar it berekkenjen fan har: wy betelje strikt foar it bedrach fan gegevens yn 'e transaksje. Yn Ethereum is de situaasje komplisearre, om't it heul lestich is om te fertrouwen op it folume fan transaksjegegevens. Hjir kin de transaksje ek programmakoade befetsje dy't útfierd wurde op 'e firtuele masine, en elke operaasje fan' e firtuele masine kin in oare kompleksiteit hawwe. D'r binne ek operaasjes dy't ûnthâld tawize foar fariabelen. Se sille har eigen kompleksiteit hawwe, wêrfan de betelling foar elke operaasje hinget.
De kosten fan elke operaasje yn gasekwivalent sille konstant wêze. It wurdt spesifyk yntrodusearre om de konstante kosten fan elke operaasje te bepalen. Ofhinklik fan 'e lading op it netwurk sil de gaspriis feroarje, dat is de koeffizient wêryn't de basisfaluta wurdt omboud yn dizze auxiliary unit om de kommisje te beteljen.
D'r is noch ien skaaimerk fan in transaksje yn Ethereum: de bytekoade dy't it befettet foar útfiering yn in firtuele masine sil wurde útfierd oant it foltôge is mei wat resultaat (súkses of mislearjen) of oant in bepaald oantal munten dy't tawiisd binne rint út om de kommisje te beteljen . It is om in situaasje te foarkommen wêrby't, yn it gefal fan wat flater, alle munten fan 'e akkount fan' e stjoerder waarden bestege oan kommisje (bygelyks in soarte fan ivige syklus begon yn in firtuele masine), it folgjende fjild bestiet - start gas (faak neamd gas limyt) - it bepaalt it maksimale bedrach fan munten dat de stjoerder is ree om te besteegjen te foltôgjen in bepaalde transaksje.
It folgjende fjild wurdt neamd bestimming adres. Dit omfettet it adres fan 'e ûntfanger fan' e munten of it adres fan in spesifyk tûk kontrakt waans metoaden wurde neamd. Nei it komt it fjild wearde, dêr't it bedrach fan munten dy't stjoerd wurde nei it bestimmingsadres ynfierd wurdt.
Folgjende is in nijsgjirrich fjild neamd data, dêr't de hiele struktuer past. Dit is net in apart fjild, mar in hiele struktuer wêryn de koade foar de firtuele masine is definiearre. Jo kinne hjir willekeurige gegevens pleatse - d'r binne aparte regels foar dit.
En it lêste fjild hjit hantekening. It befettet tagelyk sawol de elektroanyske hântekening fan de skriuwer fan dizze transaksje as de iepenbiere kaai wêrmei dizze hantekening wurdt ferifiearre. Fan 'e publike kaai kinne jo de akkountidentifikaasje fan' e stjoerder fan dizze transaksje krije, dat is, it akkount fan 'e stjoerder unyk identifisearje yn it systeem sels. Wy fûnen it wichtichste ding oer de struktuer fan 'e transaksje.
Foarbyld smart kontrakt koade foar Solidity
Litte wy no in tichterby besjen op it ienfâldichste tûke kontrakt mei in foarbyld.
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);
}
}Hjirboppe is in ferienfâldige boarnekoade dy't munten fan brûkers hâlde kin en se op oanfraach werombringe.
Dat, d'r is in Bank tûk kontrakt dat de folgjende funksjes útfiert: it sammelt munten op har saldo, dat is, as in transaksje wurdt befêstige en sa'n tûk kontrakt wurdt pleatst, wurdt in nij akkount makke dat munten kin befetsje op har saldo; it ûnthâldt brûkers en de ferdieling fan munten tusken harren; hat ferskate metoaden foar it behearen fan saldo's, dat is, it is mooglik om it lykwicht fan 'e brûker oan te foljen, werom te lûken en te kontrolearjen.
Litte wy troch elke rigel fan boarnekoade gean. Dit kontrakt hat konstante fjilden. Ien fan harren, mei type adres, hjit eigner. Hjir it kontrakt ûnthâldt it adres fan de brûker dy't makke dit tûke kontrakt. Fierder is d'r in dynamyske struktuer dy't korrespondinsje behâldt tusken brûkersadressen en saldo's.
Dit wurdt folge troch de Bank-metoade - it hat deselde namme as it kontrakt. Dêrtroch is dit syn konstruktor. Hjir wurdt de eignerfariabele it adres tawiisd fan de persoan dy't dit tûke kontrakt op it netwurk pleatst. Dit is it ienige ding dat bart yn dizze constructor. Dat is, msg yn dit gefal is krekt de gegevens dy't waarden oerbrocht nei de firtuele masine tegearre mei de transaksje mei de hiele koade fan dit kontrakt. Dêrtroch is msg.sender de skriuwer fan dizze transaksje dy't dizze koade host. Hy sil de eigner wêze fan it tûke kontrakt.
De boarch metoade lit jo in bepaald oantal munten oermeitsje nei it kontraktkonto troch transaksje. Yn dit gefal, it tûke kontrakt, ûntfangst fan dizze munten, lit se op syn lykwicht sheet, mar records yn 'e saldo struktuer dy't krekt wie de stjoerder fan dizze munten om te witten wa't se hearre.
De folgjende metoade hjit weromlûke en it nimt ien parameter - it bedrach fan munten dat immen wol weromlûke út dizze bank. Dit kontrolearret oft der genôch munten binne yn 'e balâns fan' e brûker dy't dizze metoade neamt om se te stjoeren. As d'r genôch binne, dan jout it tûke kontrakt sels dat oantal munten werom nei de beller.
Dêrnei komt de metoade foar it kontrolearjen fan it aktuele saldo fan de brûker. Wa't dizze metoade neamt, sil brûkt wurde om dit lykwicht werom te heljen yn it smart kontrakt. It is de muoite wurdich opskriuwen dat de modifier fan dizze metoade is werjefte. Dit betsjut dat de metoade sels de fariabelen fan syn klasse op gjin inkelde manier feroaret en it is eins allinich in lêsmetoade. Gjin aparte transaksje wurdt makke om dizze metoade te neamen, gjin fergoeding wurdt betelle, en alle berekkeningen wurde lokaal útfierd, wêrnei't de brûker it resultaat krijt.
De kill-metoade is nedich om de steat fan it tûke kontrakt te ferneatigjen. En hjir is in ekstra kontrôle oft de beller fan dizze metoade de eigner fan dit kontrakt is. As dat sa is, dan ferneatiget it kontrakt sels, en de ferneatigingsfunksje nimt ien parameter - de akkount-identifikaasje wêrnei't it kontrakt alle munten dy't op syn lykwicht bliuwe sil stjoere. Yn dit gefal sille de oerbleaune munten automatysk nei it adres fan 'e kontrakteigner gean.
Hoe wurket in folsleine knooppunt op it Ethereum-netwurk?
Litte wy skematysk sjen hoe't sokke tûke kontrakten wurde útfierd op it Ethereum-platfoarm en hoe't in folsleine netwurkknooppunt wurket.
In folsleine knooppunt op it Ethereum-netwurk moat op syn minst fjouwer modules hawwe.
De earste, lykas foar elk desintralisearre protokol, is de P2P-netwurkmodule - in module foar netwurkferbining en wurkje mei oare knopen, wêrby't blokken, transaksjes en ynformaasje oer oare knopen wurde útwiksele. Dit is in tradisjonele komponint foar alle desintralisearre cryptocurrencies.
Folgjende hawwe wy in module foar it opslaan fan blockchain-gegevens, ferwurkjen, kieze in prioriteitstak, taheakjen fan blokken, blokken losmeitsje, validearje fan dizze blokken, ensfh.
De tredde module wurdt neamd EVM (Ethereum firtuele masine) - dit is in firtuele masine dy't ûntfangt bytecode út Ethereum transaksjes. Dizze module nimt de aktuele steat fan in bepaald akkount en makket feroarings oan syn steat basearre op de ûntfongen bytekoade. De ferzje fan 'e firtuele masine op elke netwurkknooppunt moat itselde wêze. De berekkeningen dy't plakfine op elke Ethereum-knooppunt binne krekt itselde, mar se komme op in asynchrone manier: immen kontrolearret en akseptearret dizze transaksje earder, dat is, útfiert alle koade dy't deryn befettet, en immen letter. Dêrom, as in transaksje wurdt makke, wurdt it ferspraat oan it netwurk, de knooppunten akseptearje it, en op 'e tiid fan ferifikaasje, op deselde manier as Bitcoin Script wurdt útfierd yn Bitcoin, wurdt de bytekoade fan' e firtuele masine hjir útfierd.
In transaksje wurdt beskôge as ferifiearre as alle koade dêryn is útfierd, in nije steat fan in bepaald akkount is oanmakke en bewarre oant it dúdlik is oft dizze transaksje is tapast of net. As de transaksje wurdt tapast, dan wurdt dizze steat beskôge net allinnich foltôge, mar ek aktueel. D'r is in databank dy't de steat fan elke akkount opslacht foar elke netwurkknooppunt. Fanwege it feit dat alle berekkeningen op deselde manier foarkomme en de steat fan 'e blockchain itselde is, sil de databank mei de steaten fan alle akkounts ek itselde wêze foar elke knooppunt.
Myten en beheiningen fan smart kontrakten
Wat de beheiningen oanbelanget dy't besteane foar tûke kontraktplatfoarms fergelykber mei Ethereum, kinne it folgjende wurde oanhelle:
- koade útfiering;
- allocate ûnthâld;
- blockchain gegevens;
- ferstjoere betellingen;
- meitsje nij kontrakt;
- belje oare kontrakten.
Litte wy sjen nei de beheiningen dy't wurde oplein op in firtuele masine, en, sadwaande, ferdriuwe guon myten oer tûke kontrakten. Op in firtuele masine, dy't net allinich yn Ethereum kin wêze, mar ek yn ferlykbere platfoarms, kinne jo wirklik willekeurige logyske operaasjes útfiere, dat is, koade skriuwe en it sil dêr wurde útfierd, jo kinne ek ûnthâld tawize. Lykwols, de fergoeding wurdt betelle apart foar eltse operaasje en foar eltse ekstra ienheid ûnthâld tawiisd.
Dêrnei kin de firtuele masine gegevens lêze fan 'e blockchain-database om dizze gegevens te brûken as in trigger om ien of oare smart kontraktlogika út te fieren. De firtuele masine kin transaksjes oanmeitsje en ferstjoere, it kin nije kontrakten en opropmetoaden meitsje fan oare tûke kontrakten dy't al publisearre binne op it netwurk: besteande, beskikber, ensfh.
De meast foarkommende myte is dat Ethereum smart kontrakten ynformaasje kinne brûke fan elke ynternetboarne yn har betingsten. De wierheid is dat in firtuele masine gjin netwurkfersyk kin stjoere nei guon eksterne ynformaasjeboarnen op it ynternet, dat is, it is ûnmooglik om in tûk kontrakt te skriuwen dat wearde sil fersprieden tusken brûkers, ôfhinklik fan bygelyks wat it waar bûten is, of wa't wat kampioenskip wûn, of basearre op wat oare ynsidint barde yn 'e bûtenwrâld, om't ynformaasje oer dizze ynsidinten gewoan net yn' e database fan it platfoarm sels is. Dat is, d'r is neat op 'e blockchain oer dit. As it dêr net ferskynt, dan kin de firtuele masine dizze gegevens net brûke as triggers.
Neidielen fan Ethereum
Litte wy de wichtichste listje. It earste neidiel is dat d'r wat swierrichheden binne by it ûntwerpen, ûntwikkeljen en testen fan tûke kontrakten yn Ethereum (Ethereum brûkt de Solidity-taal om tûke kontrakten te skriuwen). Yndie, praktyk lit sjen dat in hiel grut persintaazje fan alle flaters heart by de minsklike faktor. Dit is eins wier foar al skreaune Ethereum smart kontrakten dy't gemiddelde of hegere kompleksiteit hawwe. As foar ienfâldige tûke kontrakten de kâns op in flater lyts is, dan binne yn komplekse tûke kontrakten heul faak flaters dy't liede ta stellerij fan fûnsen, har befriezen, ferneatiging fan tûke kontrakten op in ûnferwachte manier, ensfh. In protte sokke gefallen binne al bekend.
It twadde neidiel is dat de firtuele masine sels net perfekt is, om't it ek skreaun is troch minsken. It kin willekeurige kommando's útfiere, en dêryn leit de kwetsberens: in oantal kommando's kinne op in bepaalde manier konfigureare wurde dy't liede ta konsekwinsjes dy't fan tefoaren ûnfoarsjoen wiene. Dit is in heul kompleks gebiet, mar d'r binne al ferskate stúdzjes dy't sjen litte dat dizze kwetsberens besteane yn 'e hjoeddeistige ferzje fan it Ethereum-netwurk en se kinne liede ta it mislearjen fan in protte tûke kontrakten.
In oare grutte muoite, it kin beskôge wurde as in neidiel. It leit yn it feit dat jo praktysk of technysk kinne komme ta de konklúzje dat as jo kompilearje de bytekoade fan in kontrakt dat sil wurde útfierd op in firtuele masine, kinne jo bepale wat spesifike folchoarder fan operaasjes. As se tegearre wurde útfierd, sille dizze operaasjes de firtuele masine sterk laden en it ûnevenredich fertrage oan 'e fergoeding dy't waard betelle foar it útfieren fan dizze operaasjes.
Yn it ferline wie d'r al in perioade yn 'e ûntwikkeling fan Ethereum, doe't in protte jonges dy't yn detail de wurking fan in firtuele masine begrepen sokke kwetsberens fûnen. Yn feite, transaksjes betelle in hiel lytse fergoeding, mar praktysk fertrage it hiele netwurk. Dizze problemen binne heul lestich om op te lossen, om't it earst nedich is om se te bepalen, yn it twadde plak om de priis foar it útfieren fan dizze operaasjes oan te passen en, as tredde, in hurde gabel út te fieren, wat betsjut dat alle netwurkknooppunten aktualisearje nei in nije ferzje fan de software, en dan simultane aktivearring fan dizze feroarings.
Wat Ethereum oanbelanget, is in protte ûndersyk dien, in protte praktyske ûnderfining is opdien: sawol posityf as negatyf, mar dochs bliuwe der swierrichheden en kwetsberens dy't noch op ien of oare manier behannele wurde moatte.
Dat, it tematyske diel fan it artikel is foltôge, lit ús gean nei fragen dy't frij faak opkomme.
Faak stelde fragen
- As alle partijen by in besteande tûk kontrakt de betingsten wolle feroarje, kinne se dan dit tûke kontrakt annulearje mei multisig, en dan in nij tûk kontrakt oanmeitsje mei bywurke betingsten fan syn útfiering?
It antwurd hjir sil twafoldich wêze. Wêrom? Om't oan 'e iene kant, in tûk kontrakt wurdt definiearre ien kear en it ymplisearret gjin feroarings mear, en oan' e oare kant, it kin hawwe foarôfskreaune logika dy't soarget foar in folsleine of in part feroaring fan guon betingsten. Dat is, as jo wat wolle feroarje yn jo tûke kontrakt, dan moatte jo de betingsten foarskriuwe wêryn jo dizze betingsten kinne bywurkje. Dêrtroch kin de fernijing fan it kontrakt allinich op sa'n foarsichtige manier organisearre wurde. Mar ek hjir kinne jo yn de problemen komme: meitsje wat flater en krije in oerienkommende kwetsberens. Dêrom moatte sokke dingen tige detaillearre en soarchfâldich ûntwurpen en hifke wurde.
- Wat as de mediator in oerienkomst oangiet mei ien fan 'e dielnimmende partijen: escrow of smart kontrakt? Is in mediator ferplicht yn in tûk kontrakt?
In mediator is net fereaske yn in tûk kontrakt. It kin net bestean. As yn it gefal fan escrow de mediator yn in gearspanning komt mei ien fan 'e partijen, dan ja, dit skema ferliest dan skerp al syn wearde. Dêrom wurde mediators op sa'n manier selektearre dat alle partijen dy't belutsen binne by dit proses se tagelyk fertrouwe. Dêrom sille jo gewoan gjin munten oerdrage nei in multisignature-adres mei in mediator dy't jo net fertrouwe.
- Is it mooglik mei ien Ethereum-transaksje in protte ferskillende tokens oer te setten fan jo adres nei ferskate doeladressen, bygelyks útwikselingsadressen wêr't dizze tokens wurde ferhannele?
Dit is in goede fraach en it giet om it Ethereum-transaksjemodel en hoe't it ferskilt fan it Bitcoin-model. En it ferskil is radikaal. As jo yn it Ethereum-transaksjemodel gewoan munten oerdrage, dan wurde se allinich oerdroegen fan it iene adres nei it oare, gjin feroaring, allinich it spesifike bedrach dat jo opjûn hawwe. Mei oare wurden, dit is gjin model fan net bestege útgongen (UTXO), mar in model fan akkounts en oerienkommende saldo's. It is teoretysk mooglik om ferskate ferskillende tokens yn ien transaksje tagelyk te stjoeren as jo in slûchslimme tûk kontrakt skriuwe, mar jo moatte noch in protte transaksjes meitsje, in kontrakt oanmeitsje, dan tokens en munten dernei oermeitsje, en dan de passende metoade neame . Dit freget ynspanning en tiid, dus yn 'e praktyk wurket it net sa en alle betellingen yn Ethereum wurde makke yn aparte transaksjes.
- Ien fan 'e myten oer it Ethereum-platfoarm is dat it ûnmooglik is om betingsten te beskriuwen dy't ôfhinklik binne fan' e gegevens fan in eksterne ynternetboarne, dus wat dan te dwaan?
De oplossing is dat it tûke kontrakt sels ien of mear saneamde fertroude orakels leverje kin, dy't gegevens sammelje oer de stân fan saken yn 'e bûtenwrâld en troch spesjale metoaden trochjaan oan 'e tûke kontrakten. It kontrakt sels beskôget de gegevens dy't it krige fan fertroude partijen as wier. Foar gruttere betrouberens kieze gewoan in grutte groep orakels en minimalisearje it risiko fan har gearspanning. It kontrakt sels kin gjin rekken hâlde mei gegevens fan orakels dy't de mearderheid tsjinsprekke.
Ien fan 'e lêzingen fan' e online kursus oer Blockchain is wijd oan dit ûnderwerp - "".
Boarne: www.habr.com