У гэтым артыкуле мы разгледзім, што такое смарт-кантракты, якія яны бываюць, пазнаёмімся з рознымі платформамі смарт-кантрактаў, іх асаблівасцямі, а таксама абмяркуем, як яны ўладкованыя і якія перавагі могуць у сабе несці. Дадзены матэрыял будзе вельмі карысны для чытачоў, якія недастаткова добра знаёмыя з тэмай смарт-кантрактаў, але жадаюць наблізіцца да яе разумення.
Звычайны кантракт vs. смарт-кантракт
Перад тым як мы паглыбімся ў дэталі, давайце разбяром на прыкладзе адрозненні паміж звычайным кантрактам, які задаецца на паперы, і смарт-кантрактам, які прадстаўлены ў лічбавым выглядзе.
Як гэта працавала да з'яўлення смарт-кантрактаў? Прадстаўце групу асоб, якая жадае ўсталяваць некаторыя правілы і ўмовы размеркавання каштоўнасцяў, а таксама вызначаным механізмам гарантаваць выкананне гэтага размеркавання па зададзеных правілах і ўмовах. Тады яны збіраліся разам, складалі паперу, на якой запісвалі свае ідэнтыфікацыйныя дадзеныя, умовы, уцягнутыя каштоўнасці, ставілі дату і падпісваліся. Гэты кантракт таксама запэўніваў давераны бок, напрыклад натарыус. Далей, гэтыя людзі разыходзіліся ў розныя бакі са сваёй папяровай копіяй такога кантракту і пачыналі выконваць нейкія дзеянні, якія маглі не адпавядаць самому кантракту, гэта значыць яны рабілі адно, а на паперы заверана, што павінны рабіць зусім іншае. І як выходзіць з гэтай сітуацыі? Фактычна трэба камусьці з удзельнікаў групы браць гэтую паперу, браць нейкія доказы, несці ў суд і дабівацца адпаведнасці паміж кантрактам і фактычнымі дзеяннямі. Даволі часта дамагчыся справядлівага выканання гэтага кантракту бывае складана, што прыводзіць да непрыемных наступстваў.
Што ж можна сказаць пра смарт-кантракты? Яны аб'ядноўваюць у сабе і магчымасць напісання ўмоў кантракта, і механізм строгага іх выканання. Калі ўмовы былі зададзены і была падпісана адпаведная транзакцыя або запыт, то пасля прыняцця гэтага запыту або транзакцыі ўжо немагчыма змяніць умовы або паўплываць на іх выкананне.
Прысутнічае адзін валідатар або цэлая сетка, а таксама база даных, якая захоўвае ўсе смарт-кантракты, якія паступалі на выкананне ў строгай храналагічнай паслядоўнасці. Яшчэ важна, што гэтая база дадзеных павінна змяшчаць усе ўмовы-трыгеры для выканання смарт-кантракту. Акрамя таго, яна павінна ўлічваць тую самую каштоўнасць, размеркаванне якой апісана ў кантракце. Калі гэта датычыцца некаторай лічбавай валюты, значыць гэтая база даных павінна ўлічваць яе.
Інакш кажучы, валідатары смарт-кантрактаў павінны мець доступ да ўсіх дадзеных, якімі аперуе смарт-кантракт. Напрыклад, адна база даных павінна выкарыстоўвацца для ўліку адначасова лічбавых валют, балансаў карыстальнікаў, транзакцый карыстальнікаў і часовых пазнак. Тады ў смарт-кантракце умовай можа быць баланс карыстальніка ў пэўнай валюце, наступ некаторага часу або факт ажыццяўлення некаторай транзакцыі, але не больш за тое.
Вызначэнне смарт-кантракта
Наогул, сама тэрміналогія была прыдумана даследчыкам Nick Szabo і ўпершыню прыменена ў 1994 годзе, а задакументавана была ў 1997 годзе ў артыкуле, які апісвае саму ідэю смарт-кантрактаў.
Смарт-кантракты маюць на ўвазе, што выконваецца некаторая аўтаматызацыя размеркавання каштоўнасці, якая можа залежаць толькі ад тых умоў, якія загадзя прадусталяваныя. У самым простым варыянце гэта выглядае, як кантракт са строга зададзенымі ўмовамі, які падпісаны пэўнымі бакамі.
Смарт-кантракты закліканы мінімізаваць давер трэцім бакам. Часам поўнасцю выключаецца цэнтр прыняцця рашэнняў, ад якога ўсё залежыць. Акрамя таго, для такіх кантрактаў прасцей праводзіць аўдыт. Гэта з'яўляецца следствам некаторых асаблівасцяў праектавання такой сістэмы, але часцей за ўсё мы разумеем пад смарт-кантрактам дэцэнтралізаванае асяроддзе і наяўнасць функцый, якія дазваляюць любому жадаючаму прааналізаваць базу дадзеных і правесці поўны аўдыт выканання кантрактаў. Такім чынам гарантуецца абарона ад змен дадзеных заднім лікам, якія пацягнуць за сабой змены ў выкананні самога кантракту. Аблічбоўка большасці працэсаў пры стварэнні і запуску смарт-кантракту часта спрашчае тэхналогію і кошт іх рэалізацыі.
Просты прыклад - Escrow сэрвіс
Давайце разгледзім вельмі просты прыклад. Ён дапаможа наблізіцца да разумення функцыянальных магчымасцяў смарт-кантрактаў, а таксама лепш арыентавацца, у якіх выпадках іх варта прымяняць.
Яго можна рэалізаваць таксама з выкарыстаннем Біткоіна, хоць зараз Біткоін яшчэ складана назваць паўнавартаснай платформай для смарт-кантрактаў. Такім чынам, у нас ёсць некаторы пакупнік і ёсць інтэрнэт-крама. Пакупнік хоча купіць манітор у гэтай краме. У самым простым выпадку пакупнік афармляе і адпраўляе плацёж, а інтэрнэт-крама прымае яго, пацвярджае, пасля чаго адпраўляе тавар. Аднак у гэтай сітуацыі прысутнічае неабходнасць вялікага даверу - пакупнік павінен на ўвесь кошт манітора давяраць інтэрнэт-краме. Паколькі інтэрнэт-крама можа мець нізкую рэпутацыю ў вачах пакупніка, то існуе рызыка, што па нейкіх чынніках пасля прыёму плацяжу крама адмовіць у абслугоўванні і не адправіць тавар пакупніку. Таму пакупнік задаецца пытаннем (адпаведна, і інтэрнэт-крама задаецца гэтым пытаннем), што можна ў гэтым выпадку прымяніць, каб мінімізаваць такія рызыкі і зрабіць больш надзейнымі падобныя здзелкі.
У выпадку з Біткоінам можна даць магчымасць пакупніку і прадаўцу незалежна адзін ад аднаго выбраць медыятара. Ёсць мноства людзей, якія займаюцца вырашэннем спрэчных пытанняў. І нашы ўдзельнікі могуць выбраць з агульнага спіса медыятараў таго, якому адначасова будуць давяраць. Разам яны ствараюць multisignature адрас 2 з 3, дзе ёсць тры ключы і неабходныя два подпісы любымі двума ключамі, каб выдаткаваць манеты з гэтага адрасу. Адзін ключ будзе належаць пакупніку, другі - інтэрнэт-краме, а трэці - медыятару. І на такі multisignature адрас пакупнік адправіць суму, неабходную для аплаты манітора. Цяпер, калі прадавец бачыць, што грошы на некаторы час заблакаваныя на multisignature адрасе, які залежыць ад яго, ён смела можа адпраўляць манітор поштай.
Далей, пакупнік атрымлівае пасылку, аглядае тавар і прымае рашэнне аб канчатковай пакупцы. Ён можа быць цалкам згодзен з прадастаўленым абслугоўваннем і падпісаць транзакцыю сваім ключом, дзе ён перадае манеты з multisignature адрасы прадаўцу, а можа быць нечым незадаволены. У другім выпадку ён звязваецца з медыятарам для складання альтэрнатыўнай транзакцыі, якая па-іншаму будзе размяркоўваць гэтыя манеты.
Дапушчальны, манітор прыехаў крыху падрапаны і ў камплекце не ляжаў кабель для падлучэння да кампутара, хоць на сайце інтэрнэт-крамы было напісана, што кабель павінен уваходзіць у камплект. Тады пакупнік збірае доказы, неабходныя для таго, каб даказаць медыятару, што яго падманулі ў гэтай сітуацыі: ён робіць скрыншоты сайта, робіць фатаграфію чэка з пошты, робіць фатаграфію драпін на маніторы і паказвае, што пломба была сарваная і кабель выцягнулі. Інтэрнэт-крама ў сваю чаргу збірае свае доказы і перадае іх медыятару.
Медыятар зацікаўлены ў тым, каб задаволіць адначасова і абурэнне пакупніка, і інтарэсы інтэрнет-магазіна (далей будзе зразумела, чаму). Ён складае такую транзакцыю, у якой манеты з multisignature адрасы будуць марнавацца ў некаторай прапорцыі паміж пакупніком, інтэрнэт-крамай і медыятарам, бо ён бярэ сабе частку ў якасці ўзнагароды за сваю працу. Дапусцім, 90% усёй сумы пойдзе прадаўцу, 5% медыятару і 5% кампенсацыі пакупніку. Гэтую транзакцыю медыятар падпісвае сваім ключом, але яна яшчэ не можа быць прыменена, таму што для гэтага патрэбны два подпісы, а стаіць толькі адзін. Такую транзакцыю ён адпраўляе і пакупніку, і прадаўцу. Калі хаця б адзін з іх будзе задаволены такім варыянтам пераразмеркавання манет, то транзакцыя будзе да-падпісана і распаўсюджана ў сетку. Для яе валідацыі дастаткова, каб адзін з удзельнікаў здзелкі пагадзіўся з варыянтам медыятара.
Пры гэтым важна першапачаткова выбраць медыятара так, каб абодва ўдзельнікі давяралі яму. У такім выпадку ён будзе дзейнічаць незалежна ад інтарэсаў аднаго ці іншага і аб'ектыўна ацэніць сітуацыю. Калі ж медыятар не дае такі варыянт размеркавання манет, які задаволіць хаця б аднаго ўдзельніка, тады, дамовіўшыся разам, і пакупнік, і інтэрнэт-крама могуць пераправіць манеты на новы multisignature адрас, паставіўшы свае два подпісы. Новы multisignature адрас будзе складзены ўжо з іншым медыятарам, які, магчыма, будзе больш кампетэнтным у пытанні і прадаставіць лепшы варыянт.
Прыклад з інтэрнатам і халадзільнікам
Давайце разгледзім больш складаны прыклад, які адлюстроўвае магчымасці смарт-кантракту больш відавочна.
Дапушчальны, ёсць трое рабят, якія нядаўна засяліліся ў адзін пакой у інтэрнаце. Яны ўтрох зацікаўлены ў тым, каб купіць у свой пакой халадзільнік, якім яны будуць сумесна карыстацца. Адзін з іх падахвоціўся сабраць неабходную суму для пакупкі халадзільніка і весці перамовы з прадаўцом. Аднак яны адносна нядаўна пазнаёміліся сябар з сябрам і дастатковага даверу паміж імі няма. Відавочна, што двое з іх рызыкуюць, аддаючы грошы трэцяму. Акрамя таго, ім трэба дасягнуць згоды ў выбары прадаўца.
Яны могуць скарыстацца escrow сэрвісам, гэта значыць абраць медыятара, які пракантралюе выкананне ўгоды і ўладзіць спрэчныя пытанні, калі такія ўзнікнуць. Тады, дамовіўшыся, яны складаюць смарт-кантракт і прапісваюць у ім пэўныя ўмовы.
Першая ўмова заключаецца ў тым, што да наступлення вызначанага часу, дапусцім на працягу аднаго тыдня, на адпаведны акаўнт смарт-кантракта павінны паступіць тры плацяжы з пэўных адрасоў на пэўную суму. Калі гэтага не адбываецца, смарт-кантракт спыняе сваё выкананне і вяртае манеты ўсім удзельнікам. Калі ж умова выконваецца, тады задаюцца значэнні ідэнтыфікатараў прадаўца і медыятара, а таксама правяраецца ўмова, што ўсе ўдзельнікі згодны з выбарам прадаўца і медыятара. Калі ўсе ўмовы будуць выкананы, то далей сродкі будуць пераведзены на ўказаныя адрасы. Падобны падыход можа засцерагчы ўдзельнікаў ад махлярства з любога боку і ўвогуле выключае неабходнасць давяраць.
Мы бачым на гэтым прыкладзе сам прынцып, што такая магчымасць пакрокава задаваць параметры для выканання кожнай умовы дазваляе ствараць сістэмы любой складанасці і глыбіні ўкладзеных узроўняў. Акрамя таго, спачатку ў смарт-кантракце можна вызначыць першую ўмову, а толькі пасля яго выканання ўжо задаваць параметры для наступнай умовы. Інакш кажучы, фармальна ўмова прапісваецца, а параметры для яго могуць задавацца ўжо падчас яго працы.
Класіфікацыя смарт-кантрактаў
Для класіфікацыі можна задаваць розныя групы крытэрыяў. Аднак на дадзены момант развіцця тэхналогій актуальнымі з'яўляюцца чатыры з іх.
Смарт-кантракты можна адрозніваць па асяроддзі выканання, якое можа быць альбо цэнтралізаванай, альбо дэцэнтралізаванай. У выпадку дэцэнтралізацыі мы маем нашмат большую незалежнасць і адмоваўстойлівасць пры выкананні смарт-кантрактаў.
Іх таксама можна адрозніваць па працэсе задання і выкананні ўмоў: яны могуць быць адвольна праграмуемыя, абмежаваныя ці прадусталяваныя, т. е. строга тыпізаваныя. Калі на платформе смарт-кантрактаў існуе толькі 4 вызначаных смарт-кантракта, параметры да іх можна задаваць адвольнай выявай. Адпаведна, задаваць іх нашмат прасцей: мы выбіраем кантракт са спісу і перадаем параметры.
Па спосабе ініцыявання існуюць аўтаматызаваныя смарт-кантракты, гэта значыць пры надыходзе пэўных умоў яны самавыконваюцца, а бываюць такія кантракты, у якіх умовы зададзены, але платформа не правярае аўтаматычна іх выкананне, для гэтага іх трэба асобна ініцыяваць.
Акрамя таго, смарт-кантракты адрозніваюцца па ўзроўні прыватнасці. Яны могуць быць альбо цалкам адчыненыя, альбо часткова, альбо цалкам канфідэнцыйныя. Апошняе значыць, што іншыя назіральнікі не бачаць умовы смарт-кантрактаў. Аднак тэма прыватнасці вельмі шырокая і яе лепш разгледзець асобна ад бягучага артыкула.
Ніжэй мы больш падрабязна спынімся на першых трох крытэрыях, каб унесці больш яснасці ў разуменне бягучай тэмы.
Смарт-кантракты па асяроддзі выканання
Па асяроддзі выканання адрозніваюць цэнтралізаваныя і дэцэнтралізаваныя платформы смарт-кантрактаў. У выпадку цэнтралізаваных лічбавых кантрактаў выкарыстоўваецца адзін сэрвіс, дзе існуе толькі адзін валідатар і можа быць служба рэзервовага капіравання і аднаўлення, якая таксама цэнтралізавана кіруецца. Ёсць адна база даных, якая захоўвае ўсю неабходную інфармацыю для задання ўмоў смарт-кантракта і размеркавання той каштоўнасці, якая ўлічваецца ў гэтай самай базе даных сэрвісу. У такога цэнтралізаванага сервісу ёсць кліент, які пэўнымі запытамі задае ўмовы і карыстаецца такімі кантрактамі. З-за таго, што платформа цэнтралізаваная, механізмы аўтэнтыфікацыі могуць быць менш надзейнымі, чым у криптовалютах.
У якасці прыкладу можна ўзяць правайдэраў мабільнай сувязі (розных мабільных аператараў). Дапушчальны, вызначаны аператар вядзе на сваіх серверах цэнтралізаванай выявай улік трафіку, які можа перадавацца ў розных фарматах, напрыклад: у выглядзе галасавых званкоў, перадачы SMS, трафіку мабільнага інтэрнэту, і па розных стандартах, а таксама вядзе ўлік сродкаў на балансах карыстачоў. Адпаведна, правайдэр мабільнай сувязі можа складаць кантракты па ўліку паслуг і іх аплаце з рознымі ўмовамі. У такім выпадку лёгка задаюцца ўмовы па тыпе "адпраў SMS з вось такім кодам на вось такі нумар і атрымаеш вось такія ўмовы размеркавання трафіку".
Можна яшчэ адзін прыклад прывесці: традыцыйныя банкі з пашыранай функцыянальнасцю інтэрнэт-банкінгу і такія вельмі простыя кантракты, як рэгулярныя плацяжы, аўтаматычная канвертацыя ўваходзячых плацяжоў, аўтаматычнае адлічэнне працэнта на ўказаны рахунак і да т.п.
Калі гаворка ідзе пра смарт-кантракты з дэцэнтралізаваным асяроддзем выканання, тады мы маем групу валідатараў. У ідэальным выпадку валідатарам можа стаць увогуле хто заўгодна. За кошт пратаколу сінхранізацыі базы дадзеных і дасягненні кансэнсусу мы маем некаторую агульную базу дадзеных, якая будзе захоўваць зараз ужо ўсе транзакцыі са строга апісанымі кантрактамі, а не нейкія ўмоўныя запыты, фарматы якіх часта мяняюцца, а адкрытай спецыфікацыі няма. Тут транзакцыі будуць змяшчаць інструкцыі па выкананні кантракта ў адпаведнасці са строгай спецыфікацыяй. Гэтая спецыфікацыя адкрыта і, такім чынам, самі карыстачы платформы могуць праводзіць аўдыт і валідаваць смарт-кантракты. Тут мы бачым, што дэцэнтралізаваныя платформы пераўзыходзяць цэнтралізаваныя па незалежнасці і адмоваўстойлівасці, але іх праектаванне і абслугоўванне пры гэтым значна складаней.
Смарт-кантракты па спосабе задання і выканання ўмоў
Зараз разбяром падрабязней, як смарт-кантракты могуць адрознівацца па спосабе задання і выкананні ўмоў. Тут звернем увагу на смарт-кантракты, якія праграмуюцца адвольна і поўныя па Цьюрынгу. Поўны па Цьюрынгу смарт-кантракт дазваляе задаваць практычна любыя алгарытмы ў якасці ўмоў выканання кантракту: прапісваць цыклы, нейкія функцыі разліку верагоднасцяў і да таго падобнае - аж да сваіх уласных алгарытмаў электроннага подпісу. У дадзеным выпадку маецца на ўвазе сапраўды адвольнае напісанне логікі.
Вылучаюць таксама адвольныя смарт-кантракты, але не поўныя па Цьюрынгу. Сюды можна аднесці Біткоін і Лайткоін са сваім скрыптам. Маецца на ўвазе, што можна ў адвольным парадку выкарыстоўваць толькі пэўныя аперацыі, але ўжо нельга напісаць цыклы і ўласныя алгарытмы.
Акрамя таго, ёсць такія платформы смарт-кантракта, якія рэалізуюць загадзя прадусталяваныя смарт-кантракты. Да іх можна аднесці Bitshares і Steemit. Bitshares мае цэлы шэраг смарт-кантрактаў для гандлю, кіравання акаўнтамі, кіравання самай платформай і яе параметрамі. Steemit – падобная платформа, але яна арыентаваная ўжо не на выпуск токенаў і гандаль, як Bitshares, а на вядзенне блогаў, т. е. яна захоўвае і апрацоўвае кантэнт дэцэнтралізаваным чынам.
Да адвольных поўных па Цьюрынгу кантрактаў можна аднесці платформу Ethereum і RootStock, якая яшчэ знаходзіцца на стадыі распрацоўкі. Таму далей мы крыху больш падрабязна спынімся на платформе смарт-кантрактаў Ethereum.
Смарт-кантракты па спосабе ініцыяцыі
Па спосабе ініцыяцыі смарт-кантракты таксама можна падзяліць мінімум на дзве групы: аўтаматызаваныя і ручныя (не аўтаматызаваныя). Для аўтаматызаваных характэрна, што пры ўсіх вядомых параметрах і насталых умовах, смарт-кантракт цалкам выконваецца аўтаматычна, гэта значыць не патрабуе адпраўкі нейкіх дадатковых транзакцый і марнаванні дадатковай камісіі пры кожным наступным выкананні. Сама платформа мае ўсе дадзеныя, для таго каб разлічыць, якім чынам смарт-кантракт скончыцца. Логіка там не адвольная, а загадзя зададзеная і ўсё гэта прадказальна. Гэта значыць, загадзя можна ацаніць складанасць выканання смарт-кантракту, выкарыстоўваць нейкую канстантную камісію для яго і ўсе працэсы па яго выкананні праходзяць больш эфектыўным чынам.
Для смарт-кантрактаў, якія праграмуюцца адвольнай выявай, выкананне не аўтаматызавана. Для ініцыявання такога смарт-кантракта фактычна на кожным кроку трэба ствараць новую транзакцыю, якая будзе выклікаць ужо наступны этап выканання ці наступны метад смарт-кантракта, аплачваць адпаведную камісію і чакаць пацверджання транзакцыі. Выкананне можа завяршыцца паспяхова ці не, таму што код смарт-кантракта адвольны і могуць з'яўляцца нейкія непрадказальныя моманты, такія як вечны цыкл, недахоп нейкіх параметраў і аргументаў, неапрацаваныя выключныя моманты і да т.п.
Акаўнты ў Ethereum
Тыпы акаўнтаў Ethereum
Разгледзім, якія могуць быць акаўнты на платформе Ethereum. Тут існуе толькі два тыпы акаўнтаў і больш ніякіх варыянтаў няма. Першы тып называецца акаўнт карыстальніка, другі - акаўнт кантракта. Разбярэмся, чым жа яны адрозніваюцца.
Акаўнт карыстальніка кіруецца толькі асабістым ключом электроннага подпісу. Уладальнік акаўнта генеруе сваю пару ключоў для электроннага подпісу па алгарытме ECDSA (Elliptic Curve Digital Signature Algorithm). Змяняць стан гэтага акаўнта могуць толькі падпісаныя гэтым ключом транзакцыі.
Для акаўнта смарт-кантракта прадугледжана асобная логіка. Ён можа кіравацца толькі з дапамогай загадзя зададзенага праграмнага кода, які поўнасцю вызначае паводзіны смарт-кантракта: як ён будзе распараджацца сваімі манетамі пры пэўных абставінах, па ініцыятыве якога карыстальніка і пры якіх дадатковых умовах гэтыя манеты будуць распаўсюджвацца. Калі некаторыя моманты не прадугледжаны распрацоўшчыкамі ў праграмным кодзе, могуць узнікнуць праблемы. Напрыклад, смарт-кантракт можа атрымаць нейкі пэўны стан, пры якім ён не прымае ініцыяванне далейшага выканання ні ад аднаго з карыстальнікаў. У такім выпадку манеты фактычна акажуцца замарожанымі, таму што смарт-кантракт не прадугледжвае выхаду з гэтага стану.
Як ствараюцца акаўнты ў Ethereum
У выпадку з акаўнтам карыстальніка, уладальнік самастойна генеруе пару ключоў па ECDSA. Важна адзначыць, што Ethereum выкарыстоўвае для электроннага подпісу сапраўды такі ж алгарытм і сапраўды такую ж эліптычную крывую, як і Bitcoin, але адрас вылічаецца некалькі іншым чынам. Тут ужо не ўжываецца вынік падвойнага хэшавання, як у Біткоіне, а прадугледжана аднаразовае хэшаванне функцыяй Keccak на даўжыні 256 біт. Ад атрыманага значэння адсякаюцца малодшыя біты, а менавіта 160 малодшых біт выходнага значэння хэш-функцыі. У выніку мы атрымліваем адрас у Ethereum. Фактычна ён займае 20 байт.
Зварачальны ўвага, што ідэнтыфікатар акаўнта ў Ethereum кадуецца ў hex без ужывання кантрольнай сумы, у адрозненне ад Bitcoin і шматлікіх іншых сістэм, дзе адрас кадуецца ў сістэму злічэння па падставе 58 з даданнем кантрольнай сумы. Гэта значыць, што працаваць з ідэнтыфікатарамі акаўнтаў у Ethereum трэба асцярожна: нават адна памылка ў ідэнтыфікатары гарантавана прывядзе да страты манет.
Ёсць важная асаблівасць і яна складаецца ў тым, што акаўнт карыстальніка на ўзроўні агульнай базы дадзеных ствараецца ў той момант, калі ён прымае першы ўваходны плацёж.
У стаўленні стварэння акаўнта смарт-кантракту ўжываецца зусім іншы падыход. Першапачаткова хтосьці з карыстачоў піша зыходны код смарт-кантракта, пасля чаго код прапускаецца праз адмысловы для платформы Ethereum кампілятар, атрымліваючы байт-код для ўласнай віртуальнай машыны Ethereum. Атрыманы байт-код змяшчаецца ў спецыяльнае поле транзакцыі. Яна запэўніваецца ад імя акаўнта ініцыятара. Далей, гэтая транзакцыя распаўсюджваецца па сетцы і размяшчае код смарт-кантракту. Камісія за правядзенне транзакцыі і, адпаведна, за выкананне кантракта здымаецца з балансу акаўнта ініцыятара.
Кожны смарт-кантракт абавязкова змяшчае свой канструктар (гэтага кантракта). Ён можа быць пусты, а можа мець змесціва. Пасля таго, як канструктар выконваецца, ствараецца ідэнтыфікатар акаўнта смарт-кантракта, выкарыстаючы які, можна адпраўляць манеты, выклікаць вызначаныя метады смарт-кантракта і т. д.
Структура транзакцыі Ethereum
Каб было больш зразумела, мы прыступім да разгляду структуры транзакцыі Ethereum і прыкладу кода смарт-кантракту.
Транзакцыя Ethereum складаецца з некалькіх палёў. Першае з іх nonce - гэта некаторы парадкавы нумар транзакцыі адносна самога акаўнта, які яе распаўсюджвае і з'яўляецца яе аўтарам. Гэта трэба для таго, каб адрозніваць двайнікі транзакцый, гэта значыць выключыць выпадак, калі адна і тая ж транзакцыя прымаецца двойчы. Дзякуючы ўжыванню ідэнтыфікатара кожная транзакцыя мае ўнікальнае хэш-значэнне.
Далей ідзе такое поле, як цана на газ. Тут паказваецца кошт, па якім базавая валюта Ethereum канвертуецца ў gas, якім аплачваецца выкананне смарт-кантракта і вылучэнне рэсурса віртуальнай машыны. Што гэта значыць?
У Біткоіне камісіі аплачваюцца непасрэдна базавай валютай — самім біткоінам. Гэта магчыма дзякуючы простаму механізму іх разліку: мы аплачваем строга аб'ём дадзеных, які змяшчаецца ў транзакцыі. У Ethereum сітуацыя больш складаная, таму што ад аб'ёму дадзеных транзакцыі адштурхоўвацца вельмі складана. Тут транзакцыя яшчэ можа змяшчаць праграмны код, які будзе запускацца на віртуальнай машыне, а кожная аперацыя віртуальнай машыны можа мець розную складанасць. Існуюць таксама аперацыі, якія выдзяляюць памяць для зменных. Яны будуць мець складанасць, ад якой будзе залежаць аплата за кожную аперацыю.
Кошт кожнай аперацыі ў эквіваленце gas будзе канстантнай. Ён і ўводзіцца спецыяльна для таго, каб вызначыць канстантны кошт кожнай аперацыі. У залежнасці ад нагрузкі на сетку будзе зменяцца gas price, гэта значыць каэфіцыент, паводле якога базавая валюта будзе канвертавацца ў гэтую дапаможную адзінку для аплаты камісіі.
Ёсць яшчэ адна асаблівасць транзакцыі ў Ethereum: байт-код, які яна ўтрымоўвае для выканання ў віртуальнай машыне, будзе выконвацца датуль, пакуль ён не завершыцца з нейкім вынікам (поспех-няпоспех) альбо пакуль не скончыцца некаторая колькасць манет, вылучанае на аплату камісіі. Менавіта ў пазбяганне сітуацыі, калі з акаўнта адпраўніка ў выпадку нейкай памылкі выдаткаваліся ўсе манеты на камісію (напрыклад, нейкі вечны цыкл запусціўся ў віртуальнай машыне), існуе наступнае поле. start gas (яго часта называюць gas limit) - яно вызначае максімальны аб'ём манет, якія адпраўнік гатовы выдаткаваць на выкананне пэўнай транзакцыі.
Наступнае поле называецца адрас прызначэння. Сюды ўпісваецца адрас атрымальніка манет або адрас канкрэтнага смарт-кантракта, метады якога будуць выклікацца. Пасля яго ідзе поле значэнне, куды ўпісваецца сума манет, якія адпраўляюцца на destination address.
Далей размяшчаецца цікавае поле пад назвай gegevens, куды ўпісваецца цэлая структура Гэта не асобнае поле, а цэлая структура, у якой вызначаецца код для віртуальнай машыны. Сюды можна змяшчаць адвольныя дадзеныя - для гэтага існуюць асобныя правілы.
І апошняе поле называецца подпіс. Яно адначасова змяшчае ў сабе і электронны подпіс аўтара гэтай транзакцыі, і публічны ключ, якім будзе правярацца гэты подпіс. З публічнага ключа можна атрымаць ідэнтыфікатар акаўнта адпраўніка гэтай транзакцыі, гэта значыць унікальна ідэнтыфікаваць акаўнт адпраўніка ў самой сістэме. Па структуры транзакцыі асноўнае мы высветлілі.
Прыклад кода смарт-кантракта на Solidity
Давайце зараз разгледзім падрабязней самы просты смарт-кантракт на прыкладзе.
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);
}
}Вышэй прыведзены спрошчаны зыходны код, які можа ўтрымліваць манеты карыстальнікаў і вяртаць іх па патрабаванні.
Такім чынам, ёсць смарт-кантракт Bank, які выконвае наступныя функцыі: ён назапашвае на сваім балансе манеты, гэта значыць пры пацверджанні транзакцыі і размяшчэнні такога смарт-кантракта ствараецца новы акаўнт, які можа змяшчаць на сваім балансе манеты; ён запамінае карыстальнікаў і размеркаванне манет паміж імі; мае некалькі метадаў кіравання балансамі, гэта значыць ёсць магчымасць папаўнення, вываду і праверкі балансу карыстальніка.
Давайце пройдземся па кожным радку зыходнага кода. У гэтым кантракце ёсць канстантныя палі. Адно з іх, з тыпам address, завецца owner. Тут кантракт запамінае адрас карыстальніка, які стварыў гэты смарт-кантракт. Далей ёсць дынамічная структура, якая захоўвае ў сабе адпаведнасці паміж адрасамі карыстальнікаў і балансамі.
Пасля гэтага варта метад Bank - ён называецца гэтак жа, як і кантракт. Адпаведна, гэта ягоны канструктар. Тут адбываецца прысваенне зменнай owner адраса таго, хто размясціў гэты смарт-кантракт у сетцы. Гэта адзінае, што адбываецца ў гэтым канструктары. Гэта значыць msg у дадзеным выпадку - гэта менавіта тыя дадзеныя, якія былі перададзеныя віртуальнай машыне разам з транзакцыяй, якая змяшчае ўвесь код гэтага кантракту. Адпаведна, msg.sender - гэта аўтар дадзенай транзакцыі, якая размяшчае гэты код. Ён і будзе ўладальнікам смарт-кантракта.
Метад deposit дазваляе перадаць транзакцыяй пэўную колькасць манет на рахунак кантракту. У дадзеным выпадку смарт-кантракт, атрымліваючы гэтыя манеты, пакідае іх у сябе на балансе, але ў структуру balances запісвае, хто менавіта быў адпраўніком гэтых манет, каб ведаць, каму яны належаць.
Наступны метад называецца withdraw і ён прымае адзін параметр - тую суму манет, якую хтосьці хоча вывесці з гэтага банка. Тут ідзе праверка, ці дастаткова манет на балансе карыстальніка, які выклікае гэты метад, каб іх адправіць. Калі іх дастаткова, тады сам смарт-кантракт вяртае таму, хто выклікае гэтую колькасць манет.
Далей ідзе метад праверкі бягучага баланса карыстальніка. Той, хто выклікае гэты метад, будзе выкарыстоўвацца для атрымання гэтага балансу ў смарт-кантракце. Варта адзначыць, што мадыфікатар гэтага метаду – view. Гэта азначае, што сам метад ніяк не мяняе зменныя свайго класа і ён фактычна з'яўляецца толькі метадам чытання. Асобная транзакцыя не ствараецца для выкліку гэтага метаду, камісія не плаціцца, а ўсе вылічэнні выконваюцца лакальна, пасля чаго карыстач атрымлівае вынік.
Метад kill патрэбен для таго, каб знішчыць стан смарт-кантракта. І тут прапісана дадатковая праверка, ці з'яўляецца які выклікае гэтага метаду уладальнікам гэтага кантракту. Калі з'яўляецца, тады кантракт самазнішчваецца, а функцыя знішчэння прымае адзін параметр - ідэнтыфікатар акаўнта, на які кантракт адправіць усе манеты, якія засталіся на яго балансе. У дадзеным выпадку пакінутыя манеты аўтаматычна сыдуць на адрас уладальніка кантракту.
Як працуе поўны вузел сеткі Ethereum?
Разгледзім схематычна, як адбываецца выкананне такіх смарт-кантрактаў на платформе Ethereum і як працуе поўны вузел сеткі.
Поўны вузел сеткі Ethereum прынамсі павінен мець чатыры модуля.
Першым, як і для любога дэцэнтралізаванага пратакола, з'яўляецца P2P networking module - модуль сеткавага злучэння і працы з іншымі вузламі, дзе ідзе абмен блокамі, транзакцыямі, інфармацыяй аб іншых вузлах. Гэта традыцыйны кампанент для ўсіх дэцэнтралізаваных криптовалют.
Далей, у нас ёсць модуль захоўвання дадзеных блокчейна, апрацоўкі, выбару прыярытэтнай галінкі, дапаўненні блокаў, адчаплення блокаў, праверкі гэтых блокаў і г. д.
Трэці модуль называецца EVM (Ethereum virtual machine) - гэта і ёсць віртуальная машына, якая прымае байт-код з Ethereum транзакцыі. Гэты модуль прымае бягучы стан вызначанага акаўнта і выконвае змены яго стану на базе атрыманага байт-кода. Версія віртуальнай машыны на кожным з вузлоў сеткі мусіць быць аднолькавай. Вылічэнні адбываюцца на кожным з вузлоў Ethereum абсалютна аднолькавыя, але яны адбываюцца ў асінхронным парадку: хтосьці раней правярае і прымае гэтую транзакцыю, гэта значыць выконвае ўвесь які змяшчаецца ў ёй код, а хтосьці пазней. Адпаведна, пры стварэнні транзакцыі, яна распаўсюджваецца ў сетку, вузлы яе прымаюць і ў момант верыфікацыі сапраўды гэтак жа, як у Біткоіне выконваецца Bitcoin Script, тут выконваецца байт-код віртуальнай машыны.
Транзакцыя лічыцца праверанай, калі ўвесь які змяшчаецца ў ёй код быў выкананы, было згенеравана новы стан вызначанага акаўнта і захавана датуль, пакуль не будзе зразумела, ужытая гэтая транзакцыя ці не. Калі транзакцыя прыменена, тады гэты стан лічыцца не толькі выкананым, але ўжо і актуальным. Ёсць база дадзеных, якая захоўвае стан кожнага акаўнта для кожнага вузла сеткі. За кошт таго, што ўсе вылічэнні адбываюцца аднолькава і стан блокчейна аднолькавы, то і база дадзеных, утрымоўвальная станы ўсіх акаўнтаў, таксама будзе аднолькавай для кожнага вузла.
Міфы і абмежаванні смарт-кантрактаў
Што да абмежаванняў, якія існуюць для падобных на Ethereum платформаў смарт-кантрактаў, то можна прывесці наступныя:
- code execution;
- allocate memory;
- blockchain data;
- send payments;
- create new contract;
- call other contracts.
Давайце разгледзім тыя абмежаванні, якія накладваюцца на віртуальную машыну, і, адпаведна, развеем некаторыя міфы аб смарт-кантрактах. На віртуальнай машыне, якая можа быць не толькі ў Ethereum, але і ў падобных платформах, можна выконваць сапраўды адвольныя лагічныя аперацыі, гэта значыць напісаць код і ён будзе тамака выконвацца, можна дадаткова вылучаць памяць. Аднак камісія аплачваецца асобна за кожную аперацыю і за кожную дадаткова выдзеленую адзінку аб'ёму памяці.
Далей, віртуальная машына можа чытаць дадзеныя з базы дадзеных блокчейна, для таго каб выкарыстоўваць гэтыя дадзеныя ў якасці трыгера для выканання той ці іншай логікі смарт-кантрактаў. Віртуальная машына можа ствараць і адпраўляць транзакцыі, яна можа ствараць новыя кантракты і выклікаць метады іншых смарт-кантрактаў, якія ўжо апублікаваны ў сетцы: існуюць, даступныя і г.д.
Найбольш распаўсюджаны міф у тым, што смарт-кантракты Ethereum могуць выкарыстоўваць інфармацыю з любых інтэрнэт-рэсурсаў у сваіх умовах. Праўда складаецца ў тым, што віртуальная машына не можа адправіць сеткавы запыт нейкаму вонкаваму інфармацыйнаму рэсурсу ў інтэрнэце, гэта значыць нельга напісаць такі смарт-кантракт, які будзе размяркоўваць каштоўнасць паміж карыстачамі ў залежнасці ад таго, дапусцім, якое надвор'е на вуліцы, альбо. хто выйграў у нейкім чэмпіянаце, альбо на падставе таго, якое яшчэ здарэнне адбылося ў навакольным свеце, таму што інфармацыі аб гэтых здарэннях проста няма ў базе дадзеных самой платформы. Гэта значыць, у блокчейне нічога з гэтай нагоды няма. Калі яно тамака не з'явіцца, то і віртуальная машына не можа выкарыстаць гэтыя дадзеныя ў якасці трыгераў.
Недахопы Ethereum
Давайце пералічым асноўныя з іх. Першы недахоп складаецца ў тым, што існуюць некаторыя складанасці пры праектаванні, распрацоўцы і тэставанні смарт-кантрактаў у Ethereum (у Ethereum для напісання смарт-кантрактаў выкарыстоўваецца мова Solidity). Сапраўды, практыка паказвае, што вельмі вялікі працэнт сярод усіх памылак належыць чалавечаму фактару. Гэта практычна актуальна і для ўжо напісаных смарт-кантрактаў Ethereum, якія маюць складанасць сярэднюю або вышэй. Калі для простых смарт-кантрактаў верагоднасць памылкі малая, то ў складаных смарт-кантрактах вельмі часта сустракаюцца памылкі, якія прыводзяць да крадзяжу сродкаў, да іх замарозкі, да знішчэння смарт-кантрактаў непрадбачанай выявай і т. п. Ужо шмат такіх выпадкаў вядома.
Другі недахоп заключаецца ў тым, што сама віртуальная машына не ідэальная, бо яна таксама напісана людзьмі. Яна можа выконваць адвольныя каманды і ў гэтым крыецца ўразлівасць: можна вызначанай выявай сканфігураваць шэраг каманд, якія прывядуць да непрадбачаных загадзя наступстваў. Гэта вельмі складаная сфера, але існуе ўжо некалькі даследаванняў, якія паказваюць, што гэтыя ўразлівасці ёсць у бягучай версіі сеткі Ethereum і яны могуць прывесці да адмовы працы шматлікіх смарт-кантрактаў.
Яшчэ адна вялікая складанасць, яе можна лічыць недахопам. Яна складаецца ў тым, што можна практычнай ці тэхнічнай выявай прыйсці да таго, што калі скампіляваць байт-код кантракту, які будзе выконвацца на віртуальнай машыне, можна вызначыць некаторы спецыфічны парадак аперацый. Пры выкананні ў сукупнасці гэтыя аперацыі вельмі моцна нагрузяць віртуальную машыну і замарудзяць яе непрапарцыйна той камісіі, якая была аплачана за выкананне гэтых аперацый.
У мінулым быў ужо такі перыяд развіцця Ethereum, калі шмат рабят, якія разбіраліся дэталёва ў рабоце віртуальнай машыны, знаходзілі такія ўразлівасці. Фактычна транзакцыі плацілі вельмі маленькую камісію, але практычна вельмі запавольвалі працу ўсёй сеткі. Гэтыя праблемы вырашаюцца вельмі складана, бо трэба іх, па-першае, дэтэрмінаваць, па-другое, скарэктаваць кошт за выкананне гэтых аперацый і, па-трэцяе, правесці хардфорк, што азначае абнаўленне ўсіх вузлоў сеткі на новую версію праграмнага забеспячэння, а затым адначасовую актывізацыю гэтых змен.
Што да Ethereum, то было праведзена вельмі шмат даследаванняў, атрыманы вельмі вялікі практычны досвед: як дадатны, так і адмоўны, але тым не менш застаюцца складанасці і ўразлівасці, з якімі маецца быць яшчэ неяк дужацца.
Такім чынам, тэматычная частка артыкула завершана, пяройдзем да пытанняў, якія ўзнікаюць дастаткова часта.
Часта задаюць пытанні
- Калі ўсе бакі дзеючага смарт-кантракта хочуць змяніць умовы, ці могуць яны адмяніць гэты смарт-кантракт з дапамогай мультыподпісу, а потым стварыць новы смарт-кантракт з абноўленымі ўмовамі яго выканання?
Тут адказ будзе дваякі. Чаму? Таму што з аднаго боку смарт-кантракт аднойчы задаецца і ён ужо не мае на ўвазе ніякіх змен, а з другога боку ён можа мець загадзя прапісаную логіку, якая прадугледжвае поўную ці частковую змену нейкіх умоў. Гэта значыць, калі вы хочаце нешта памяняць у сваім смарт-кантракце, то вы загадзя павінны прапісаць умовы, па якіх вы можаце абнавіць гэтыя ўмовы. Адпаведна, толькі такім прадбачлівым чынам можна арганізаваць абнаўленне кантракта. Але і тут таксама можна напароцца на непрыемнасці: дапусціць нейкую памылку і атрымаць адпаведную ўразлівасць. Таму такія рэчы трэба вельмі дэталёва і старанна праектаваць і тэсціраваць.
- А калі медыятар увойдзе ў змову з адной з бакоў-удзельнікаў: escrow або смарт-кантракту? Ці абавязковы медыятар у смарт-кантракце?
Медыятар неабавязковы ў смарт-кантракце. Яго можа не быць. Калі ў выпадку escrow медыятар увойдзе ў змову з адной з бакоў, то так, гэтая схема тады рэзка губляе ўсю сваю каштоўнасць. Таму медыятары і выбіраюцца такім чынам, што ім давяраюць адначасова ўсе бакі, уцягнутыя ў гэты працэс. Адпаведна, вы проста не будзеце пераводзіць манеты на multisignature адрас з тым медыятарам, якому не давяраеце.
- Ці можна адной транзакцыяй Ethereum перавесці шмат розных токенаў са свайго адрасу на розныя мэтавыя адрасы, напрыклад біржавыя адрасы, дзе гандлююцца гэтыя токены?
Гэта добрае пытанне і ён дакранаецца мадэлі транзакцый Ethereum і яе адрозненні ад мадэлі Bitcoin. І адрозненне гэта кардынальна. Калі ў мадэлі транзакцыі Ethereum вы проста пераводзіце манеты, то яны пераводзяцца толькі з аднаго адраса на іншы, без здачы, проста канкрэтная сума, якую вы паказалі. Інакш кажучы, гэта не мадэль невыдаткаваных выхадаў (UTXO), а мадэль менавіта акаўнтаў і адпаведных балансаў. Адной транзакцыяй адправіць адразу некалькі розных токенаў тэарэтычна можна, калі напісаць хітры смарт-кантракт, але ўсё роўна давядзецца зрабіць шмат транзакцый, стварыць кантракт, потым перадаць яму токены і манеты, а потым выклікаць адпаведны метад. Гэта патрабуе намаганняў і часу, адпаведна, на практыцы гэта так не працуе і ўсе плацяжы ў Ethereum здзяйсняюцца асобнымі транзакцыямі.
- Адзін з міфаў аб платформе Ethereum складаецца ў тым, што немагчыма апісаць такія ўмовы, якія будуць залежаць ад дадзеных знешняга інтэрнэт-рэсурсу, як жа быць тады?
Рашэнне заключаецца ў тым, што сам смарт-кантракт можа прадугледжваць аднаго або некалькіх так званых давераных аракулаў, якія збіраюць дадзеныя аб стане рэчаў у знешнім свеце і перадаюць іх у смарт-кантракты праз спецыяльныя метады. Сам кантракт лічыць праўдай тыя дадзеныя, якія ён атрымаў ад давераных бакоў. Для большай надзейнасці проста выбіраюць вялікую групу аракулаў і мінімізуюць рызыку іх змовы. Сам кантракт можа не ўлічваць дадзеныя ад аракулаў, якія супярэчаць большасці.
Дадзенай тэме прысвечана адна з лекцый анлайн-курса па Blockchain.».
Крыніца: habr.com