En ĉi tiu artikolo, ni rigardos, kio estas inteligentaj kontraktoj, kio ili estas, ni konatiĝos kun malsamaj inteligentaj kontraktoplatformoj, iliaj funkcioj, kaj ankaŭ diskutos kiel ili funkcias kaj kiajn avantaĝojn ili povas alporti. Ĉi tiu materialo estos tre utila por legantoj, kiuj ne bone konas la temon de inteligentaj kontraktoj, sed volas proksimiĝi al kompreni ĝin.
Regula kontrakto vs. inteligenta kontrakto
Antaŭ ol ni enprofundiĝi en la detalojn, ni prenu ekzemplon de la diferencoj inter regula kontrakto, kiu estas specifita sur papero, kaj inteligenta kontrakto, kiu estas reprezentita ciferece.
Kiel ĉi tio funkciis antaŭ la alveno de inteligentaj kontraktoj? Imagu grupon de homoj, kiuj volas establi certajn regulojn kaj kondiĉojn por distribuado de valoroj, kaj ankaŭ certan mekanismon por garantii la efektivigon de ĉi tiu distribuo laŭ la donitaj reguloj kaj kondiĉoj. Poste ili kunvenis, ellaboris paperon, sur kiu ili notis siajn identigajn detalojn, la terminojn, la koncernajn valorojn, datis ilin kaj subskribis ilin. Ĉi tiu kontrakto ankaŭ estis atestita de fidinda partio, kiel ekzemple notario. Plue, ĉi tiuj homoj iris en malsamaj direktoj kun sia papera kopio de tia kontrakto kaj komencis fari iujn agojn, kiuj eble ne respondas al la kontrakto mem, tio estas, ili faris unu aferon, sed sur papero oni atestis, ke ili devas fari ion. tute malsama. Kaj kiel eliri el ĉi tiu situacio? Fakte, unu el la grupanoj devas preni ĉi tiun paperon, preni iujn pruvojn, preni ĝin al tribunalo kaj atingi plenumon inter la kontrakto kaj realaj agoj. Tre ofte, estas malfacile atingi justan efektivigon de ĉi tiu kontrakto, kiu kondukas al malagrablaj sekvoj.
Kion oni povas diri pri inteligentaj kontraktoj? Ili kombinas kaj la eblecon skribi la kondiĉojn de la kontrakto kaj la mekanismon por ilia strikta efektivigo. Se la kondiĉoj estas fiksitaj kaj la responda transakcio aŭ peto estis subskribita, tiam post kiam tiu peto aŭ transakcio estas akceptita, ne plu eblas ŝanĝi la kondiĉojn aŭ influi ilian efektivigon.
Estas unu validigilo aŭ tuta reto, same kiel datumbazo, kiu stokas ĉiujn inteligentajn kontraktojn, kiuj estis prezentitaj por ekzekuto en strikta kronologia ordo. Ankaŭ gravas, ke ĉi tiu datumbazo devas enhavi ĉiujn ellasilkondiĉojn por plenumi la inteligentan kontrakton. Krome, ĝi devas konsideri la valoron mem, kies distribuo estas priskribita en la kontrakto. Se ĉi tio validas por iu cifereca valuto, tiam ĉi tiu datumbazo devus konsideri ĝin.
Alivorte, inteligentaj kontraktovalidiloj devas havi aliron al ĉiuj datumoj, sur kiuj funkcias la inteligenta kontrakto. Ekzemple, ununura datumbazo devus esti uzata por samtempe kontentigi ciferecajn valutojn, uzantekvilibrojn, uzanttransakciojn kaj tempomarkojn. Tiam, en inteligenta kontrakto, la kondiĉo povas esti la ekvilibro de la uzanto en certa valuto, la alveno de certa tempo aŭ la fakto, ke certa transakcio estis farita, sed nenio pli.
Difino de inteligenta kontrakto
Ĝenerale, la terminologio mem estis kreita de esploristo Nick Szabo kaj unue uzita en 1994, kaj estis dokumentita en 1997 en artikolo, kiu priskribas la ideon mem de inteligentaj kontraktoj.
Inteligentaj kontraktoj implicas ke iu aŭtomatigo de valordistribuo estas farita, kiu povas nur dependi de tiuj kondiĉoj kiuj estas antaŭdeterminitaj. En ĝia plej simpla formo, ĝi aspektas kiel kontrakto kun strikte difinitaj kondiĉoj, kiu estas subskribita de iuj partioj.
Inteligentaj kontraktoj estas dizajnitaj por minimumigi fidon al triaj partioj. Kelkfoje la decidcentro, de kiu ĉio dependas, estas tute ekskludita. Krome, tiaj kontraktoj estas pli facile revizieblaj. Ĉi tio estas konsekvenco de iuj dezajnaj trajtoj de tia sistemo, sed plej ofte ni komprenas per inteligenta kontrakto malcentralizitan medion kaj la ĉeeston de funkcioj, kiuj permesas al iu ajn analizi la datumbazon kaj fari plenan revizion de la plenumo de kontraktoj. Ĉi tio certigas protekton kontraŭ retroaktivaj datumŝanĝoj, kiuj kunportus ŝanĝojn en la plenumo de la kontrakto mem. Ciferecigo de plej multaj procezoj dum kreado kaj lanĉo de inteligenta kontrakto ofte simpligas la teknologion kaj koston de ilia efektivigo.
Simpla ekzemplo - Escrow-servo
Ni rigardu tre simplan ekzemplon. Ĝi helpos vin pli proksimiĝi al kompreni la funkciecon de inteligentaj kontraktoj, kaj ankaŭ pli bone kompreni en kiuj kazoj ili devas esti uzataj.
Ĝi ankaŭ povas esti efektivigita uzante Bitcoin, kvankam nuntempe Bitcoin ankoraŭ apenaŭ povas esti nomita plentaŭga platformo por inteligentaj kontraktoj. Do, ni havas iun aĉetanton kaj ni havas interretan vendejon. Kliento volas aĉeti monitoron de ĉi tiu vendejo. En la plej simpla kazo, la aĉetanto kompletigas kaj sendas pagon, kaj la reta vendejo akceptas ĝin, konfirmas ĝin, kaj tiam sendas la varojn. Tamen, en ĉi tiu situacio estas bezono de granda fido - la aĉetanto devas fidi la interretan vendejon por la tuta kosto de la monitoro. Ĉar interreta vendejo povas havi malaltan reputacion en la okuloj de la aĉetanto, ekzistas risko, ke ial, post akcepti la pagon, la vendejo rifuzos servon kaj ne sendos la varojn al la aĉetanto. Sekve, la aĉetanto demandas (kaj, sekve, la reta vendejo demandas ĉi tiun demandon), kio povas esti aplikita en ĉi tiu kazo por minimumigi tiajn riskojn kaj fari tiajn transakciojn pli fidindaj.
En la kazo de Bitcoin, eblas permesi al la aĉetanto kaj vendisto sendepende elekti mediaciiston. Estas multaj homoj, kiuj okupiĝas pri solvado de polemikaj aferoj. Kaj niaj partoprenantoj povas elekti el ĝenerala listo de perantoj tiun, kiun ili fidos. Kune ili kreas 2 el 3 multisigna adreson kie ekzistas tri ŝlosiloj kaj du subskriboj kun iuj ajn du ŝlosiloj estas postulataj por elspezi monerojn de tiu adreso. Unu ŝlosilo apartenos al la aĉetanto, la dua al la reta butiko, kaj la tria al la mediaciisto. Kaj al tia multisigna adreso la aĉetanto sendos la necesan kvanton por pagi por la monitoro. Nun, kiam la vendisto vidas, ke mono estas blokita dum kelka tempo ĉe plursigna adreso, kiu dependas de li, li povas sekure sendi la monitoron per poŝto.
Poste, la aĉetanto ricevas la pakaĵon, inspektas la varojn kaj prenas decidon pri la fina aĉeto. Li povas tute konsenti kun la servo provizita kaj subskribi la transakcion per sia ŝlosilo, kie li transdonas monerojn de la multisigna adreso al la vendisto, aŭ li povas esti malkontenta pri io. En la dua kazo, li kontaktas mediaciiston por kunmeti alternativan transakcion, kiu disdonos tiujn monerojn malsame.
Ni diru, ke la monitoro alvenis iom gratita kaj la ilaro ne inkludis kablon por konekti al la komputilo, kvankam la retejo de la reta vendejo diris, ke la kablo estu inkluzivita en la ilaro. Tiam la aĉetanto kolektas la pruvojn necesajn por pruvi al la mediaciisto, ke li estis trompita en ĉi tiu situacio: li prenas ekrankopiojn de la retejo, prenas foton de la poŝta kvitanco, prenas foton de la grataĵoj sur la ekrano kaj montras, ke la sigelo estis. rompita kaj la kablo estis eltirita. La reta vendejo, siavice, kolektas siajn pruvojn kaj transdonas ĝin al la mediaciisto.
La mediaciisto interesiĝas samtempe kontentigi kaj la indignon de la aĉetanto kaj la interesojn de la reta vendejo (ekviĝos kial poste). Ĝi konsistigas transakcion en kiu moneroj de multisigna adreso estos elspezitaj en iu proporcio inter la aĉetanto, la reta vendejo kaj la mediaciisto, ĉar li prenas porcion por si kiel rekompencon por sia laboro. Ni diru 90% de la totala kvanto iras al la vendisto, 5% al la mediaciisto kaj 5% kompenso al la aĉetanto. La mediaciisto subskribas ĉi tiun transakcion per sia ŝlosilo, sed ĝi ankoraŭ ne povas esti aplikata, ĉar ĝi postulas du subskribojn, sed nur unu valoras ĝin. Ĝi sendas tian transakcion al kaj la aĉetanto kaj la vendisto. Se almenaŭ unu el ili estas kontenta pri ĉi tiu opcio por redistribuo de moneroj, tiam la transakcio estos antaŭsubskribita kaj distribuita al la reto. Por validigi ĝin, sufiĉas, ke unu el la partioj de la transakcio konsentas kun la opcio de la mediaciisto.
Gravas komence elekti mediaciiston por ke ambaŭ partoprenantoj fidu lin. En ĉi tiu kazo, li agos sendepende de la interesoj de unu aŭ la alia kaj objektive taksos la situacion. Se la mediaciisto ne donas eblon por disdoni monerojn, kiuj kontentigos almenaŭ unu partoprenanton, tiam, interkonsentinte, kaj la aĉetanto kaj la reta vendejo povas sendi la monerojn al nova multisigna adreso metante siajn du subskribojn. La nova multisigna adreso estos kompilita kun malsama peranto, kiu povas esti pli kompetenta en la afero kaj havigi pli bonan eblon.
Ekzemplo kun dormejo kaj fridujo
Ni rigardu pli kompleksan ekzemplon, kiu montras la kapablojn de inteligenta kontrakto pli eksplicite.
Ni diru, ke estas tri uloj kiuj lastatempe translokiĝis en la saman dormĉambron. La tri el ili interesiĝas aĉeti fridujon por sia ĉambro, kiun ili povas uzi kune. Unu el ili volontulis por kolekti la necesan sumon por aĉeti fridujon kaj intertrakti kun la vendisto. Tamen ili nur lastatempe renkontis unu la alian kaj ne estas sufiĉe da fido inter ili. Evidente, du el ili riskas donante monon al la tria. Krome, ili devas atingi interkonsenton pri elekto de vendisto.
Ili povas uzi la escrow-servon, tio estas, elekti mediaciiston, kiu kontrolos la ekzekuton de la transakcio kaj solvos polemikajn problemojn, se aperos. Tiam, konsentinte, ili ellaboras inteligentan kontrakton kaj preskribas en ĝi iujn kondiĉojn.
La unua kondiĉo estas, ke antaŭ certa tempo, ekzemple ene de unu semajno, la responda inteligenta kontrakto-konto devas ricevi tri pagojn de certaj adresoj por certa kvanto. Se ĉi tio ne okazas, la inteligenta kontrakto ĉesas ekzekuti kaj resendas la monerojn al ĉiuj partoprenantoj. Se la kondiĉo estas plenumita, tiam la valoroj de la vendisto kaj peranto-identigiloj estas fiksitaj, kaj la kondiĉo estas kontrolita, ke ĉiuj partoprenantoj konsentas kun la elekto de la vendisto kaj peranto. Kiam ĉiuj kondiĉoj estas plenumitaj, tiam la fundoj estos translokigitaj al la specifitaj adresoj. Ĉi tiu aliro povas protekti partoprenantojn kontraŭ fraŭdo de ajna flanko kaj ĝenerale forigas la bezonon fidi.
Ni vidas en ĉi tiu ekzemplo la principon mem, ke ĉi tiu kapablo laŭpaŝe agordi parametrojn por plenumi ĉiun kondiĉon ebligas al vi krei sistemojn de ajna komplekseco kaj profundo de nestitaj niveloj. Krome, vi povas unue difini la unuan kondiĉon en la inteligenta kontrakto, kaj nur post ĝia plenumo vi povas agordi parametrojn por la sekva kondiĉo. Alivorte, la kondiĉo estas formale skribita, kaj parametroj por ĝi povas esti agordita jam dum ĝia funkciado.
Klasifiko de inteligentaj kontraktoj
Por klasifiko, vi povas agordi malsamajn grupojn de kriterioj. Tamen, en la momento de teknologia evoluo, kvar el ili estas gravaj.
Inteligentaj kontraktoj povas esti distingitaj per sia ekzekutmedio, kiu povas esti aŭ centralizita aŭ malcentralizita. En la kazo de malcentralizo, ni havas multe pli grandan sendependecon kaj toleremon al misfunkciadoj dum plenumado de inteligentaj kontraktoj.
Ili ankaŭ povas esti distingitaj per la procezo de fiksado kaj plenumado de kondiĉoj: ili povas esti libere programeblaj, limigitaj aŭ antaŭdifinitaj, t.e. strikte tajpitaj. Kiam ekzistas nur 4 specifaj inteligentaj kontraktoj sur la inteligenta kontrakto-platformo, la parametroj por ili povas esti agordi iel ajn. Sekve, agordi ilin estas multe pli simpla: ni elektas kontrakton el la listo kaj pasas la parametrojn.
Laŭ la iniciata metodo, ekzistas aŭtomatigitaj inteligentaj kontraktoj, tio estas, kiam certaj kondiĉoj okazas, ili estas memplenumaj, kaj ekzistas kontraktoj en kiuj la kondiĉoj estas specifitaj, sed la platformo ne aŭtomate kontrolas ilian plenumon; por tio ili devas esti komencita aparte.
Krome, inteligentaj kontraktoj varias en sia nivelo de privateco. Ili povas esti aŭ tute malfermitaj, parte aŭ tute konfidencaj. Ĉi-lasta signifas, ke triaj observantoj ne vidas la kondiĉojn de inteligentaj kontraktoj. Tamen, la temo pri privateco estas tre larĝa kaj estas pli bone konsideri ĝin aparte de la nuna artikolo.
Malsupre ni rigardos pli detale la unuajn tri kriteriojn por alporti pli da klareco al la kompreno de la aktuala temo.
Inteligentaj kontraktoj laŭ rultempo
Surbaze de la ekzekuta medio, oni distingas inter centralizitaj kaj malcentralizitaj inteligentaj kontraktoplatformoj. En la kazo de centralizitaj ciferecaj kontraktoj, oni uzas ununuran servon, kie ekzistas nur unu validigilo kaj povas ekzisti rezerva kaj reakira servo, kiu ankaŭ estas centre administrita. Estas unu datumbazo, kiu stokas ĉiujn necesajn informojn por agordi la kondiĉojn de la inteligenta kontrakto kaj distribui la valoron, kiu estas konsiderata en ĉi tiu sama serva datumbazo. Tia centralizita servo havas klienton, kiu starigas kondiĉojn kun certaj petoj kaj uzas tiajn kontraktojn. Pro la centralizita naturo de la platformo, aŭtentikigmekanismoj povas esti malpli sekuraj ol en kriptaj moneroj.
Kiel ekzemplo, ni povas preni poŝtelefonajn provizantoj (malsamaj poŝtelefonaj telefonistoj). Ni diru, ke certa operatoro tenas centralizitan rekordon de trafiko sur siaj serviloj, kiu povas esti transdonita en malsamaj formatoj, ekzemple: en formo de voĉvokoj, SMS-transdono, movebla interreta trafiko, kaj laŭ malsamaj normoj, kaj ankaŭ konservas rekordojn. de financoj sur uzantsaloj. Sekve, la provizanto de poŝtelefonoj povas ellabori kontraktojn por kontado de la servoj provizitaj kaj ilia pago kun malsamaj kondiĉoj. En ĉi tiu kazo, estas facile agordi kondiĉojn kiel "sendu SMS kun tia kaj tia kodo al tia kaj tia nombro kaj vi ricevos tiajn kaj tiajn kondiĉojn por trafika distribuo."
Unu plia ekzemplo povas esti donita: tradiciaj bankoj kun vastigita funkcieco de Interreta bankado kaj tre simplaj kontraktoj kiel ekzemple regulaj pagoj, aŭtomata konvertiĝo de envenantaj pagoj, aŭtomata depreno de intereso al specifa konto, ktp.
Se ni parolas pri inteligentaj kontraktoj kun malcentralizita ekzekuta medio, tiam ni havas grupon de validigiloj. Ideale, iu ajn povas fariĝi validisto. Pro la datumbaza sinkroniga protokolo kaj atingi konsenton, ni havas iun komunan datumbazon, kiu nun stokos ĉiujn transakciojn kun strikte priskribitaj kontraktoj, kaj ne iujn kondiĉajn demandojn, kies formatoj ofte ŝanĝiĝas, kaj ne ekzistas malferma specifo. Ĉi tie, transakcioj enhavos instrukciojn por plenumi la kontrakton laŭ strikta specifo. Ĉi tiu specifo estas malfermita kaj, sekve, platformaj uzantoj mem povas kontroli kaj validigi inteligentajn kontraktojn. Ĉi tie ni vidas, ke malcentralizitaj platformoj estas pli bonaj ol centralizitaj rilate sendependecon kaj toleremo al misfunkciadoj, sed ilia dezajno kaj bontenado estas multe pli kompleksaj.
Inteligentaj kontraktoj per la metodo starigi kaj plenumi kondiĉojn
Nun ni rigardu pli detale kiel inteligentaj kontraktoj povas diferenci laŭ la maniero kiel ili starigas kaj plenumas kondiĉojn. Ĉi tie ni turnas nian atenton al inteligentaj kontraktoj, kiuj estas hazarde programeblaj kaj Turing kompleta. Turing-kompleta inteligenta kontrakto permesas vin agordi preskaŭ ajnajn algoritmojn kiel kondiĉojn por la plenumo de la kontrakto: skribu ciklojn, iujn funkciojn por kalkuli probablojn kaj similajn - ĝuste ĝis viaj propraj elektronikaj subskribaj algoritmoj. En ĉi tiu kazo, ni signifas vere arbitran skribon de logiko.
Ekzistas ankaŭ arbitraj inteligentaj kontraktoj, sed ne kompletaj Turing. Ĉi tio inkluzivas Bitcoin kaj Litecoin kun sia propra skripto. Ĉi tio signifas, ke vi povas uzi nur certajn operaciojn en ajna ordo, sed vi ne plu povas skribi buklojn kaj viajn proprajn algoritmojn.
Krome, ekzistas inteligentaj kontraktoplatformoj kiuj efektivigas antaŭdifinitajn inteligentajn kontraktojn. Ĉi tiuj inkluzivas Bitshares kaj Steemit. Bitshares havas gamon da inteligentaj kontraktoj por komerco, konta administrado, administrado de la platformo mem kaj ĝiaj parametroj. Steemit estas simila platformo, sed ĝi ne plu fokusiĝas al eldonado de ĵetonoj kaj komerco, kiel Bitshares, sed al blogado, t.e. ĝi stokas kaj prilaboras enhavon en malcentralizita maniero.
Arbitraj Turing-kompletaj kontraktoj inkluzivas la Ethereum-platformon kaj RootStock, kiu ankoraŭ estas disvolvita. Sekve, sube ni loĝos iom pli detale sur la platformo de inteligenta kontrakto Ethereum.
Inteligentaj kontraktoj per komenca metodo
Surbaze de la metodo de iniciato, inteligentaj kontraktoj ankaŭ povas esti dividitaj en almenaŭ du grupojn: aŭtomatigitaj kaj manaj (ne aŭtomatigitaj). Aŭtomatigitaj estas karakterizitaj per tio, ke, konsiderante ĉiujn konatajn parametrojn kaj kondiĉojn, la inteligenta kontrakto estas plene plenumita aŭtomate, tio estas, ĝi ne postulas sendi pliajn transakciojn kaj elspezi plian komisionon por ĉiu posta ekzekuto. La platformo mem havas ĉiujn datumojn por kalkuli kiel kompletiĝos la inteligenta kontrakto. La logiko tie ne estas arbitra, sed antaŭdeterminita kaj ĉio ĉi estas antaŭvidebla. Tio estas, vi povas antaŭkalkuli la kompleksecon de ekzekuto de inteligenta kontrakto, uzi ian konstantan komisionon por ĝi, kaj ĉiuj procezoj por ĝia efektivigo estas pli efikaj.
Por inteligentaj kontraktoj kiuj estas libere programitaj, ekzekuto ne estas aŭtomatigita. Por komenci tian inteligentan kontrakton, preskaŭ ĉiupaŝe vi devas krei novan transakcion, kiu nomos la sekvan ekzekuta stadion aŭ la sekvan inteligentan kontraktan metodon, pagu la taŭgan komisionon kaj atendu ke la transakcio estu konfirmita. Ekzekuto povas kompletigi sukcese aŭ ne, ĉar la inteligenta kontraktokodo estas arbitra kaj povas aperi iuj neantaŭvideblaj momentoj, kiel eterna buklo, manko de iuj parametroj kaj argumentoj, netraktitaj esceptoj ktp.
Ethereum-Kontoj
Ethereum-Kontaj Tipoj
Ni rigardu kiajn tipojn de kontoj povas esti sur la platformo Ethereum. Estas nur du specoj de kontoj ĉi tie kaj ne ekzistas aliaj ebloj. La unua tipo nomiĝas uzantkonto, la dua estas kontrakta konto. Ni eltrovu kiel ili diferencas.
La uzantkonto estas kontrolata nur per la persona ŝlosilo de la elektronika subskribo. La posedanto de la konto generas sian propran ŝlosilparon por elektronika subskribo uzante la algoritmon ECDSA (Elliptic Curve Digital Signature Algorithm). Nur transakcioj subskribitaj per ĉi tiu ŝlosilo povas ŝanĝi la staton de ĉi tiu konto.
Aparta logiko estas provizita por la inteligenta kontraktokonto. Ĝi povas esti kontrolita nur per antaŭdifinita programara kodo, kiu tute determinas la konduton de la inteligenta kontrakto: kiel ĝi administros siajn monerojn en certaj cirkonstancoj, laŭ la iniciato de kiu uzanto kaj sub kiaj aldonaj kondiĉoj ĉi tiuj moneroj estos distribuitaj. Se iuj punktoj ne estas provizitaj de la programistoj en la programkodo, problemoj povas aperi. Ekzemple, inteligenta kontrakto povas ricevi certan staton, en kiu ĝi ne akceptas komencon de plia ekzekuto de iu ajn el la uzantoj. En ĉi tiu kazo, la moneroj efektive estos frostigitaj, ĉar la inteligenta kontrakto ne provizas por eliri ĉi tiun staton.
Kiel kontoj estas kreitaj sur Ethereum
En la kazo de uzantkonto, la posedanto sendepende generas ŝlosilparon uzante ECDSA. Gravas noti, ke Ethereum uzas precize la saman algoritmon kaj ĝuste la saman elipsan kurbon por elektronikaj subskriboj kiel Bitcoin, sed la adreso estas kalkulita en iomete malsama maniero. Ĉi tie, la rezulto de duobla hashing ne plu estas uzata, kiel en Bitcoin, sed ununura hashing estas provizita per la funkcio Keccak je longo de 256 bitoj. La malplej signifaj bitoj estas fortranĉitaj de la rezulta valoro, nome la malplej signifaj 160 bitoj de la eliga hashvaloro. Kiel rezulto, ni ricevas adreson en Ethereum. Fakte, ĝi okupas 20 bajtojn.
Bonvolu noti, ke la kontidentigilo en Ethereum estas kodita en dekseso sen aplikado de ĉeksumo, male al Bitcoin kaj multaj aliaj sistemoj, kie la adreso estas ĉifrita en bazo 58 nombra sistemo kun aldono de ĉeksumo. Ĉi tio signifas, ke vi devas esti singarda kiam vi laboras kun kontaj identigiloj en Ethereum: eĉ unu eraro en la identigilo garantias konduki al la perdo de moneroj.
Estas grava trajto kaj ĝi estas, ke uzantkonto ĉe la ĝenerala datumbaza nivelo estas kreita en la momento, kiam li akceptas la unuan envenantan pagon.
Krei inteligentan kontraktokonton prenas tute alian aliron. Komence, unu el la uzantoj skribas la fontkodon de la inteligenta kontrakto, post kiu la kodo estas pasita tra kompililo speciala por la platformo Ethereum, akirante bajtokodon por sia propra virtuala maŝino Ethereum. La rezulta bajtkodo estas metita en specialan kampon de la transakcio. Ĝi estas atestita nome de la konto de la iniciatinto. Poste, ĉi tiu transakcio estas disvastigita tra la reto kaj metas la inteligentan kontraktokodon. La komisiono por la transakcio kaj, sekve, por la plenumo de la kontrakto estas retirita de la saldo de la konto de la iniciatinto.
Ĉiu inteligenta kontrakto nepre enhavas sian propran konstruiston (de ĉi tiu kontrakto). Ĝi povas esti malplena aŭ ĝi povas havi enhavon. Post kiam la konstrukciisto estas ekzekutita, estas kreita inteligenta kontrakta konto-identigilo, per kiu vi povas sendi monerojn, voki certajn inteligentajn kontraktajn metodojn ktp.
Ethereum Transakcia Strukturo
Por fari ĝin pli klara, ni komencos rigardi la strukturon de Ethereum-transakcio kaj ekzemplon de inteligenta kontraktokodo.
Ethereum-transakcio konsistas el pluraj kampoj. La unua el ĉi tiuj, nonce, estas certa seria numero de la transakcio rilate al la konto mem, kiu distribuas ĝin kaj estas ĝia aŭtoro. Ĉi tio estas necesa por distingi duoblajn transakciojn, tio estas, por ekskludi la kazon kiam la sama transakcio estas akceptita dufoje. Uzante identigilon, ĉiu transakcio havas unikan hashvaloron.
Poste venas kampo kiel benzina prezo. Ĉi tio indikas la prezon, je kiu la baza monero de Ethereum estas konvertita en gason, kiu estas uzata por pagi por la ekzekuto de la inteligenta kontrakto kaj la atribuo de la virtuala maŝina rimedo. Kion ĝi signifas?
En Bitcoin, kotizoj estas pagataj rekte per la baza valuto—Bitcoin mem. Ĉi tio eblas danke al simpla mekanismo por kalkuli ilin: ni pagas strikte por la kvanto de datumoj enhavita en la transakcio. En Ethereum la situacio estas pli komplika, ĉar estas tre malfacile fidi la volumon de transakciaj datumoj. Ĉi tie, la transakcio ankaŭ povas enhavi programkodon kiu estos efektivigita sur la virtuala maŝino, kaj ĉiu operacio de la virtuala maŝino povas havi malsaman kompleksecon. Ekzistas ankaŭ operacioj kiuj asignas memoron por variabloj. Ili havos sian propran kompleksecon, de kiu dependos la pago por ĉiu operacio.
La kosto de ĉiu operacio en gasekvivalento estos konstanta. Ĝi estas enkondukita specife por determini la konstantan koston de ĉiu operacio. Depende de la ŝarĝo en la reto, la prezo de gaso ŝanĝiĝos, tio estas, la koeficiento laŭ kiu la baza valuto estos konvertita en ĉi tiun helpan unuon por pagi la komisionon.
Estas unu plia trajto de transakcio en Ethereum: la bajtkodo, kiun ĝi enhavas por ekzekuto en virtuala maŝino, estos ekzekutita ĝis ĝi finiĝos kun iu rezulto (sukceso aŭ malsukceso) aŭ ĝis certa kvanto da moneroj asignitaj finiĝos por pagi la komisionon. . Estas por eviti situacion, kie, en kazo de iu eraro, ĉiuj moneroj de la konto de la sendinto estis elspezitaj komisiono (ekzemple, ia eterna ciklo komencita en virtuala maŝino), la sekva kampo ekzistas - ekgaso (ofte nomata gaslimo) - ĝi determinas la maksimuman kvanton da moneroj, kiujn la sendinto pretas elspezi por plenumi certan transakcion.
La sekva kampo estas nomita celloka adreso. Ĉi tio inkluzivas la adreson de la ricevanto de la moneroj aŭ la adreson de specifa inteligenta kontrakto, kies metodoj estos nomitaj. Post ĝi venas la kampo valoro, kie la kvanto de moneroj senditaj al la cela adreso estas enigita.
Poste estas interesa kampo nomata datumoj, kie la tuta strukturo taŭgas. Ĉi tio ne estas aparta kampo, sed tuta strukturo, en kiu la kodo por la virtuala maŝino estas difinita. Vi povas meti ĉi tie arbitrajn datumojn - estas apartaj reguloj por tio.
Kaj la lasta kampo estas nomita subskribon. Ĝi samtempe enhavas kaj la elektronikan subskribon de la aŭtoro de ĉi tiu transakcio kaj la publikan ŝlosilon per kiu ĉi tiu subskribo estos kontrolita. De la publika ŝlosilo vi povas akiri la konton-identigilon de la sendinto de ĉi tiu transakcio, tio estas, unike identigi la konton de la sendinto en la sistemo mem. Ni eksciis la ĉefan aferon pri la strukturo de la transakcio.
Ekzemplo de inteligenta kontraktokodo por Solidity
Ni nun rigardu pli detale la plej simplan inteligentan kontrakton uzante ekzemplon.
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);
}
}Supre estas simpligita fontkodo, kiu povas teni la monerojn de uzantoj kaj resendi ilin laŭpeto.
Do, ekzistas Banka inteligenta kontrakto, kiu plenumas la sekvajn funkciojn: ĝi amasigas monerojn sur sia saldo, tio estas, kiam transakcio estas konfirmita kaj tia inteligenta kontrakto estas metita, nova konto estas kreita, kiu povas enhavi monerojn sur sia saldo; ĝi memoras uzantojn kaj la distribuadon de moneroj inter ili; havas plurajn metodojn por administri ekvilibrojn, tio estas, ĝi eblas replenigi, retiriĝi kaj kontroli la ekvilibron de la uzanto.
Ni trairu ĉiun linion de fontkodo. Ĉi tiu kontrakto havas konstantajn kampojn. Unu el ili, kun tipadreso, nomiĝas posedanto. Ĉi tie la kontrakto memoras la adreson de la uzanto, kiu kreis ĉi tiun inteligentan kontrakton. Plue, ekzistas dinamika strukturo kiu konservas korespondadon inter uzanto-adresoj kaj ekvilibroj.
Ĉi tio estas sekvata de la Banka metodo - ĝi havas la saman nomon kiel la kontrakto. Sekve, ĉi tiu estas ĝia konstrukciisto. Ĉi tie la posedanto-variablo ricevas la adreson de la persono, kiu metis ĉi tiun inteligentan kontrakton en la reto. Ĉi tio estas la nura afero, kiu okazas en ĉi tiu konstrukciisto. Tio estas, msg en ĉi tiu kazo estas ĝuste la datumoj kiuj estis transdonitaj al la virtuala maŝino kune kun la transakcio enhavanta la tutan kodon de ĉi tiu kontrakto. Sekve, msg.sender estas la aŭtoro de ĉi tiu transakcio kiu gastigas ĉi tiun kodon. Li estos la posedanto de la inteligenta kontrakto.
La metodo de deponejo ebligas al vi translokigi certan nombron da moneroj al la kontrakta konto per transakcio. En ĉi tiu kazo, la inteligenta kontrakto, ricevante ĉi tiujn monerojn, lasas ilin en sia bilanco, sed registras en la bilanco-strukturo kiu ĝuste estis la sendinto de ĉi tiuj moneroj por scii al kiu ili apartenas.
La sekva metodo nomiĝas retiri kaj ĝi prenas unu parametron - la kvanton da moneroj, kiujn iu volas eltiri de ĉi tiu banko. Ĉi tio kontrolas ĉu estas sufiĉe da moneroj en la bilanco de la uzanto, kiu vokas ĉi tiun metodon por sendi ilin. Se estas sufiĉe da ili, tiam la inteligenta kontrakto mem resendas tiun nombron da moneroj al la alvokanto.
Poste venas la metodo por kontroli la nunan bilancon de la uzanto. Kiu nomas ĉi tiun metodon, estos uzata por retrovi ĉi tiun ekvilibron en la inteligenta kontrakto. Indas noti, ke la modifilo de ĉi tiu metodo estas vido. Ĉi tio signifas, ke la metodo mem neniel ŝanĝas la variablojn de sia klaso kaj ĝi fakte estas nur legata metodo. Neniu aparta transakcio estas kreita por nomi ĉi tiun metodon, neniu kotizo estas pagita, kaj ĉiuj kalkuloj estas faritaj loke, post kio la uzanto ricevas la rezulton.
La mortiga metodo estas necesa por detrui la staton de la inteligenta kontrakto. Kaj ĉi tie estas plia kontrolo, ĉu la alvokanto de ĉi tiu metodo estas la posedanto de ĉi tiu kontrakto. Se jes, tiam la kontrakto memdetruiĝas, kaj la detrua funkcio prenas unu parametron - la konto-identigilo al kiu la kontrakto sendos ĉiujn monerojn restantajn sur sia ekvilibro. En ĉi tiu kazo, la ceteraj moneroj aŭtomate iros al la adreso de la kontraktoposedanto.
Kiel funkcias plena nodo en la reto Ethereum?
Ni rigardu skeme kiel tiaj inteligentaj kontraktoj estas ekzekutitaj sur la platformo Ethereum kaj kiel funkcias plena reto-nodo.
Plena nodo en la reto Ethereum devas havi almenaŭ kvar modulojn.
La unua, kiel por iu ajn malcentralizita protokolo, estas la modulo pri reto P2P - modulo por retkonekto kaj laboro kun aliaj nodoj, kie blokoj, transakcioj kaj informoj pri aliaj nodoj estas interŝanĝitaj. Ĉi tio estas tradicia komponanto por ĉiuj malcentralizitaj kriptaj moneroj.
Poste, ni havas modulon por stoki blokĉenajn datumojn, prilabori, elekti prioritatan branĉon, almeti blokojn, malligi blokojn, validigi ĉi tiujn blokojn ktp.
La tria modulo nomiĝas EVM (Ethereum virtual machine) - ĉi tio estas virtuala maŝino, kiu ricevas bajtkodon de Ethereum-transakcioj. Ĉi tiu modulo prenas la nunan staton de aparta konto kaj faras ŝanĝojn al ĝia stato surbaze de la ricevita bajtokodo. La virtuala maŝinversio sur ĉiu retnodo devas esti la sama. La kalkuloj, kiuj okazas sur ĉiu Ethereum-nodo, estas ekzakte la samaj, sed ili okazas en nesinkrona maniero: iu kontrolas kaj akceptas ĉi tiun transakcion pli frue, tio estas, ekzekutas la tutan kodon enhavitan en ĝi, kaj iu poste. Sekve, kiam transakcio estas kreita, ĝi estas distribuita al la reto, la nodoj akceptas ĝin, kaj en la momento de konfirmo, same kiel Bitcoin Script estas ekzekutita en Bitcoin, la bajkodo de la virtuala maŝino estas ekzekutita ĉi tie.
Transakcio estas konsiderata kontrolita se la tuta kodo enhavita en ĝi estis efektivigita, nova stato de certa konto estis generita kaj konservita ĝis estas klare ĉu ĉi tiu transakcio estis aplikita aŭ ne. Se la transakcio estas aplikata, tiam ĉi tiu stato estas konsiderata ne nur finita, sed ankaŭ aktuala. Estas datumbazo, kiu konservas la staton de ĉiu konto por ĉiu retnodo. Pro la fakto, ke ĉiuj kalkuloj okazas en la sama maniero kaj la stato de la blokĉeno estas la sama, la datumbazo enhavanta la statojn de ĉiuj kontoj ankaŭ estos la sama por ĉiu nodo.
Mitoj kaj limigoj de inteligentaj kontraktoj
Koncerne al la limigoj, kiuj ekzistas por inteligentaj kontraktaj platformoj similaj al Ethereum, la jenaj povas esti cititaj:
- kodo ekzekuto;
- asigni memoron;
- blokĉenaj datumoj;
- sendi pagojn;
- krei novan kontrakton;
- voku aliajn kontraktojn.
Ni rigardu la limigojn, kiuj estas truditaj al virtuala maŝino, kaj, sekve, dispelu iujn mitojn pri inteligentaj kontraktoj. Sur virtuala maŝino, kiu povas esti ne nur en Ethereum, sed ankaŭ en similaj platformoj, vi povas fari vere arbitrajn logikajn operaciojn, tio estas, skribi kodon kaj ĝi estos ekzekutita tie, vi povas aldone asigni memoron. Tamen, la kotizo estas pagata aparte por ĉiu operacio kaj por ĉiu kroma memorunuo asignita.
Poste, la virtuala maŝino povas legi datumojn de la blokĉena datumbazo por uzi ĉi tiujn datumojn kiel ellasilon por ekzekuti unu aŭ alian inteligentan kontraktan logikon. La virtuala maŝino povas krei kaj sendi transakciojn, ĝi povas krei novajn kontraktojn kaj voki metodojn de aliaj inteligentaj kontraktoj, kiuj jam estas publikigitaj en la reto: ekzistantaj, disponeblaj, ktp.
La plej ofta mito estas, ke Ethereum-inteligentaj kontraktoj povas uzi informojn de iu ajn interreta rimedo laŭ siaj kondiĉoj. La vero estas, ke virtuala maŝino ne povas sendi retan peton al iu ekstera informrimedo en Interreto, tio estas, estas neeble verki inteligentan kontrakton, kiu distribuos valoron inter uzantoj depende de, ekzemple, kia estas la vetero ekstere, aŭ kiu gajnis iun ĉampionecon, aŭ surbaze de kia alia okazaĵo okazis en la ekstera mondo, ĉar informoj pri ĉi tiuj okazaĵoj simple ne estas en la datumbazo de la platformo mem. Tio estas, estas nenio en la blokĉeno pri ĉi tio. Se ĝi ne aperas tie, tiam la virtuala maŝino ne povas uzi ĉi tiujn datumojn kiel ellasilon.
Malavantaĝoj de Ethereum
Ni listigu la ĉefajn. La unua malavantaĝo estas, ke ekzistas iuj malfacilaĵoj por desegni, disvolvi kaj testi inteligentajn kontraktojn en Ethereum (Ethereum uzas la lingvon Solidity por skribi inteligentajn kontraktojn). Efektive, praktiko montras, ke tre granda procento de ĉiuj eraroj apartenas al la homa faktoro. Ĉi tio efektive validas por jam skribitaj Ethereum inteligentaj kontraktoj, kiuj havas mezan aŭ pli altan kompleksecon. Se por simplaj inteligentaj kontraktoj la probablo de eraro estas malgranda, tiam en kompleksaj inteligentaj kontraktoj tre ofte estas eraroj, kiuj kondukas al ŝtelo de monrimedoj, ilia frosto, neatendita detruo de inteligentaj kontraktoj ktp. Multaj tiaj kazoj jam estas. konata.
La dua malavantaĝo estas, ke la virtuala maŝino mem ne estas perfekta, ĉar ĝi ankaŭ estas skribita de homoj. Ĝi povas ekzekuti arbitrajn komandojn, kaj tie kuŝas la vundebleco: kelkaj ordonoj povas esti agorditaj en certa maniero, kiu kondukos al sekvoj, kiuj estis antaŭviditaj. Ĉi tio estas tre kompleksa areo, sed jam ekzistas pluraj studoj, kiuj montras, ke ĉi tiuj vundeblecoj ekzistas en la nuna versio de la reto Ethereum kaj ili povas konduki al fiasko de multaj inteligentaj kontraktoj.
Alia granda malfacilaĵo, ĝi povas esti konsiderata malavantaĝo. Ĝi kuŝas en tio, ke vi povas praktike aŭ teknike veni al la konkludo, ke se vi kompilas la bajtkodon de kontrakto, kiu estos efektivigita sur virtuala maŝino, vi povas determini iun specifan ordon de operacioj. Kiam ili fariĝas kune, ĉi tiuj operacioj multe ŝarĝos la virtualan maŝinon kaj malrapidigos ĝin misproporcie al la kotizo, kiu estis pagita por plenumi ĉi tiujn operaciojn.
En la pasinteco, jam estis periodo en la disvolviĝo de Ethereum, kiam multaj uloj, kiuj detale komprenis la funkciadon de virtuala maŝino, trovis tiajn vundeblecojn. Fakte, transakcioj pagis tre malgrandan kotizon, sed preskaŭ malrapidigis la tutan reton. Ĉi tiuj problemoj estas tre malfacile solveblaj, ĉar necesas unue determini ilin, due alĝustigi la prezon por plenumi ĉi tiujn operaciojn kaj, trie, efektivigi malmolan forkon, kio signifas ĝisdatigi ĉiujn retajn nodojn al nova versio. de la programaro, kaj tiam samtempa aktivigo de ĉi tiuj ŝanĝoj.
Koncerne Ethereum, multe da esploroj estis faritaj, multe da praktika sperto akiris: kaj pozitivaj kaj negativaj, sed tamen restas malfacilaĵoj kaj vundeblecoj, kiuj ankoraŭ devas esti iel traktitaj.
Do, la tema parto de la artikolo estas finita, ni transiru al demandoj, kiuj sufiĉe ofte aperas.
Oftaj demandoj
— Se ĉiuj partioj al ekzistanta inteligenta kontrakto volas ŝanĝi la kondiĉojn, ĉu ili povas nuligi ĉi tiun saĝan kontrakton per multisig, kaj poste krei novan inteligentan kontrakton kun ĝisdatigitaj kondiĉoj de ĝia ekzekuto?
La respondo ĉi tie estos duobla. Kial? Ĉar unuflanke, inteligenta kontrakto estas difinita unufoje kaj ĝi ne plu implicas ajnajn ŝanĝojn, kaj aliflanke, ĝi povas havi antaŭskribitan logikon kiu provizas por kompleta aŭ parta ŝanĝo de iuj kondiĉoj. Tio estas, se vi volas ŝanĝi ion en via inteligenta kontrakto, tiam vi devas preskribi la kondiĉojn, laŭ kiuj vi povas ĝisdatigi ĉi tiujn kondiĉojn. Sekve, nur tiel prudenta maniero povas esti organizita la renovigo de la kontrakto. Sed ankaŭ ĉi tie vi povas renkonti problemojn: fari iun eraron kaj akiri respondan vundeblecon. Tial tiaj aferoj devas esti tre detalaj kaj zorge desegnitaj kaj provitaj.
— Kio se la mediaciisto faras interkonsenton kun unu el la partoprenantaj partioj: escrow aŭ inteligenta kontrakto? Ĉu peranto postulas en inteligenta kontrakto?
Peranto ne estas postulata en inteligenta kontrakto. Ĝi eble ne ekzistas. Se, en la kazo de escrow, la mediaciisto eniras en konspiron kun unu el la partioj, tiam jes, ĉi tiu skemo tiam akre perdas sian tutan valoron. Tial, mediaciistoj estas elektitaj tiel, ke ili estas fidindaj de ĉiuj partioj implikitaj en ĉi tiu procezo samtempe. Sekve, vi simple ne transdonos monerojn al multisigna adreso kun peranto, kiun vi ne fidas.
— Ĉu eblas per unu Ethereum-transakcio translokigi multajn malsamajn ĵetonojn de via adreso al malsamaj celatadresoj, ekzemple, interŝanĝi adresojn kie ĉi tiuj ĵetonoj estas komercitaj?
Ĉi tio estas bona demando kaj ĝi koncernas la Ethereum-transakcian modelon kaj kiel ĝi diferencas de la Bitcoin-modelo. Kaj la diferenco estas radikala. Se en la transakcia modelo de Ethereum vi simple translokigas monerojn, tiam ili estas nur translokigitaj de unu adreso al alia, neniu ŝanĝo, nur la specifa kvanto, kiun vi specifis. Alivorte, ĉi tio ne estas modelo de neeluzitaj eligoj (UTXO), sed modelo de kontoj kaj respondaj saldoj. Teorie eblas sendi plurajn malsamajn ĵetonojn en unu transakcio samtempe, se vi skribas ruzan inteligentan kontrakton, sed vi ankoraŭ devos fari multajn transakciojn, krei kontrakton, poste transdoni ĵetonojn kaj monerojn al ĝi, kaj poste nomi la taŭgan metodon. . Ĉi tio postulas penon kaj tempon, do praktike ĝi ne funkcias tiel kaj ĉiuj pagoj en Ethereum estas faritaj en apartaj transakcioj.
— Unu el la mitoj pri la platformo Ethereum estas, ke estas neeble priskribi kondiĉojn, kiuj dependos de la datumoj de ekstera interreta rimedo, do kion fari tiam?
La solvo estas, ke la inteligenta kontrakto mem povas provizi unu aŭ plurajn tiel nomatajn fidindajn orakolojn, kiuj kolektas datumojn pri la stato de la aferoj en la ekstera mondo kaj transdonas ĝin al la inteligentaj kontraktoj per specialaj metodoj. La kontrakto mem konsideras la datumojn, kiujn ĝi ricevis de fidindaj partioj, veraj. Por pli granda fidindeco, simple elektu grandan grupon da orakoloj kaj minimumigu la riskon de ilia koluzio. La kontrakto mem eble ne enkalkulas datumojn de orakoloj, kiuj kontraŭdiras la plimulton.
Unu el la prelegoj de la reta kurso pri Blockchain estas dediĉita al ĉi tiu temo - "".
fonto: www.habr.com