Тэхнічная дакументацыя Ethereum
Гэты ўступны артыкул быў упершыню апублікаваны ў 2014 Віталікам Бутэрыным, заснавальнікам Ethereum, перад запускам праекта ў 2015 годзе. Трэба адзначыць, што Ethereum, як і мноства іншых праектаў с адкрытым зыходным кодам, развіваўся з моманту яго заснавання.
Не гледзячы на тое, што гэтаму артыкулу ўжо некалькі гадоў, мы захоўваем яго, бо ён працягвае быць карысным кіраўніцтвам і дакладным адлюстраваннем Ethereum і яго бачання. Каб даведацца больш пра апошнія навіны ў распрацоўцы Ethereum, і як робяцца змяненні ў пратакол, мы прапануем вам азнаёміцца з гэтым кіраўніцтвам.
Платформа наступнага пакалення для разумных кантрактаў і дэцэнтралізаваных дадаткаў
Стварэнне Біткойна ў 2009 годзе Сатошы Накамота часта называюць радыкальным прарывам у галіне грошай і валюты і з'яўляецца першым прыкладам лічбавага актыву, які адначасова не мае ні забеспячэння, ні «унутранай вартасці(opens in a new tab)», ні цэнтралізаванага эмітэнта або кантролера. Тым не менш, іншая, магчыма, больш важная частка эксперымента Біткойна — гэта базавая тэхналогія блокчэйн як інструмент размеркаванага кансэнсусу, і ўвага хутка пачынае зрушвацца да гэтага аспекту Біткойна. Часта згадваюцца альтэрнатыўныя дадаткі тэхналогіі блокчэйн, якія ўключаюць выкарыстанне лічбавых актываў на блокчэйне для прадстаўлення карыстальніцкіх валют і фінансавых інструментаў («каляровых манет(opens in a new tab)»), права ўласнасці на падлягаючы фізічны аб'ект («разумная ўласнасць(opens in a new tab)»), неўзаемазамяняльныя актывы, такія як даменныя імёны («Namecoin(opens in a new tab)»), а таксама больш складаныя дадаткі, у якіх лічбавыя актывы непасрэдна кантралююцца часткай кода, якая рэалізуе адвольныя правілы («разумныя кантракты(opens in a new tab)») або нават заснаваныя на блокчэйне «дэцэнтралізаваныя аўтаномныя арганізацыі(opens in a new tab)» (DAOs). Тое, што Ethereum плануе прадставіць, — гэта блокчэйн з убудаванай, поўнай па Т'юрынгу мовай праграмавання з магчымасцю стварэння «кантрактаў», якія могуць быць выкарыстаны для кадавання адвольных функцый пераходу стану, дазваляючы карыстальнікам ствараць любыя з сістэм, як апісаных вышэй, так і многіх іншых, якія мы яшчэ нават не прыдумалі, проста запісаўшы логіку ў некалькіх радках кода.
Уводзіны ў Біткоін і існуючыя канцэпцыі
Гісторыя
Канцэпцыя дэцэнтралізаванай лічбавай валюты, як і альтэрнатыўныя дадаткі, такія як рэестры ўласнасці, існуе ўжо некалькі дзесяцігоддзяў. Пратаколы ананімных электронных плацяжоў 1980-х і 1990-х гадоў, якія ў асноўным абапіраліся на крыптаграфічны прымітыў, вядомыя як схаванне Чаума, забяспечвалі высокую ступень канфідэнцыяльнасці валюты, але пратаколы не змаглі заваяваць папулярнасць ў значнай ступені з-за іх залежнасці ад цэнтралізаванага пасрэдніка. У 1998 годзе b-money(opens in a new tab) Вэй Дая сталі першым прапанаваннем, якое ўводзіла ідэю стварэння грошай шляхам рашэння вылічальных галаваломак, а таксама дэцэнтралізаванага кансэнсусу, але ў прапанаванні было недастаткова інфармацыі аб тым, як дэцэнтралізаваны кансэнсус можа быць рэалізаваны. У 2005 годзе Хэл Фінні прадставіў канцэпцыю «шматразовых доказаў працы(opens in a new tab)», сістэму, якая выкарыстоўвала ідэі b-money і вылічальна складаныя Hashcash галаваломкі Адама Бэка для стварэння канцэпцыі крыптавалюты, але зноў жа не дацягнула да ідэалу, абапіраючыся на надзейныя вылічэнні у якасці бэкэнда. У 2009 годзе дэцэнтралізаваная валюта была ўпершыню рэалізавана на практыцы Сатошы Накамота, сумяшчаючы складзеныя прымітывы для кіравання правам уласнасці праз публічны крыптаграфічны ключ з алгарытмам кансэнсусу для адсочвання ўладальнікаў манет, вядомым як «доказ працы».
Механізм, які ляжаў у аснове доказу працы, быў значным прарывам, бо ён адначасова вырашыў дзве праблемы. Па-першае, ён забяспечыў просты і ўмерана эфектыўны алгарытм кансэнсусу, дазваляючы вузлам у сетцы калектыўна ўзгадніць набор кананічных абнаўленняў да стану рэестра Біткоіна. Па-другое, ён забяспечыў механізм, які дазваляе свабодна ўмешвацца ў працэс кансэнсусу, вырашаючы палітычную задачу аб тым, хто атрымае магчымасць уплываць на кансэнсус, адначасова прадухіляючы атакі Сівілы. Гэта дасягаецца шляхам замены фармальнага бар'ера для ўдзелу, такога як патрабаванне быць зарэгістраваным як унікальная арганізацыя ў канкрэтны спіс, на эканамічны бар'ер — вага асобнага вузла ў працэсе кансэнсуснага галасавання прама прапарцыянальна вылічальнай магутнасці, якой валодае вузел. З тых часоў быў прапанаваны альтэрнатыўны падыход, які называецца доказам валодання, які вылічвае вагу вузла прапарцыянальна яго валютным запасам, а не вылічальным рэсурсам; абмеркаванне адносных вартасцей двух падыходаў выходзіць за рамкі дадзенага артыкула, але варта адзначыць, што абодва падыходы могуць быць выкарыстаны ў якасці асновы для крыптавалюты.
Біткоін як сістэма пераходу стану
З тэхнічнага пункту гледжання, рэестр крыптавалюты, такой як Біткоін, можа быць разгледжаны як сістэма пераходу стану, дзе ёсць «стан», які складаецца са статусу ўласнасці ўсіх існуючых біткоінаў, і «функцыя пераходу стану», якая бярэ стан і транзакцыю і выводзіць новы выніковы стан. У стандартнай банкаўскай сістэме, напрыклад, станам з'яўляецца баланс, транзакцыяй — запыт на перамяшчэнне $X ад A да B, а функцыя пераходу стану зніжае значэнне на рахунку A на $X і павялічвае значэнне на рахунку B на $X. Калі рахунак А мае менш $X, тады функцыя пераходу стану вяртае памылку. Такім чынам, фармальна можна вызначыць:
APPLY(S,TX) -> S' or ERROR
У банкаўскай сістэме, вызначанай вышэй:
APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }
Аднак:
APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR
«Стан» у Біткоіне — гэта сукупнасць усіх манет (тэхнічна, «выхад незрасходаванай транзакцыі» або UTXO), якія былі створаны і яшчэ не зрасходаваны, прычым кожны UTXO мае намінал і ўладальніка (вызначаецца 20-байтавым адрасам, які па сутнасці з'яўляецца крыптаграфічным публічным ключомfn1). Транзакцыя ўтрымлівае адзін або больш уваходаў, дзе кожны ўваход утрымлівае спасылку на існуючы UTXO і крыптаграфічны подпіс, створаны з дапамогай прыватнага ключа, звязанага з адрасам уладальніка, і адзін або больш выхадаў, кожны з якіх утрымлівае новы UTXO для дабаўлення да стану.
Функцыя пераходу стану APPLY(S,TX) -> S'
можа быць вызначана прыкладна наступным чынам:
- Для кожнага ўваходу ў
TX
:- Калі згаданы UTXO адсутнічае ў
S
, вярнуць паведамленне пра памылку. - Калі прадстаўлены подпіс не адпавядае ўладальніку UTXO, то вяртаецца паведамленне пра памылку.
- Калі згаданы UTXO адсутнічае ў
- Калі сума наміналаў усіх уваходных UTXO меншая за суму наміналаў усіх выхадных UTXO, вярнуць паведамленне пра памылку.
- Вярнуць
S
з выдаленнем усіх уваходных UTXO і дабаўленнем усіх выходных UTXO.
Першая палова першага кроку не дазваляе адпраўнікам транзакцый траціць неіснуючыя манеты, другая палова першага кроку не дазваляе адпраўнікам транзакцый траціць чужыя манеты, а другі крок забяспечвае захаванне каштоўнасці. Для таго каб выкарыстоўваць гэта для аплаты, пратакол такі. Мяркуем, што Аліса хоча адправіць Бобу 11,7 BTC. Спачатку Аліса будзе шукаць набор даступных UTXO, якімі яна валодае і ў суме даюць як мінімум 11,7 BTC. Па сутнасці, Аліса не зможа атрымаць роўна 11,7 BTC; скажам, што найменшае, што яна можа атрымаць, гэта 6+4+2=12. Пасля гэтага яна стварае транзакцыю з гэтымі трыма ўваходнымі данымі і двума выходнымі данымі. Першы выхад будзе 11,7 BTC з адрасам Боба як уладальніка, а другі выхад будзе пакінутым «рэштай» у 0,3 BTC, уладальнікам якой з'яўляецца сама Аліса.
Майнінг
Калі б у нас быў доступ да надзейнай цэнтральнай службы, то гэтая сістэма была б банальнай для рэалізацыі; яе можна было б проста напісаць з дапамогай кода дакладна так, як апісана, выкарыстоўваючы жорсткі дыск цэнтральнага сервера для адсочвання стану. Аднак з Біткоінам мы спрабуем пабудаваць дэцэнтралізаваную валютную сістэму, таму нам трэба будзе аб'яднаць сістэму пераходу стану з сістэмай кансэнсусу, каб гарантаваць, што ўсе згодныя з парадкам транзакцый. Дэцэнтралізаваны кансэнсусны працэс Біткоіна патрабуе наяўнасці вузлоў у сетцы, каб пастаянна спрабаваць ствараць пакеты з транзакцый, якія называюцца «блокамі». Сетка разлічана на стварэнне прыблізна аднаго блока кожныя дзесяць хвілін, дзе кожны блок утрымлівае часовую метку, якая называецца «nonce», спасылку на папярэдні блок (г.зн. яго хэш) і спіс усіх транзакцый, якія адбыліся пасля папярэдняга блока. З часам гэта стварае нязменны ланцуг блокаў (так званы «блокчэйн»), які пастаянна расце і абнаўляецца, каб прадстаўляць апошні стан рэестра Біткоіна.
Алгарытм праверкі дакладнасці блока ў гэтай мадэлі такі:
- Праверыць, што мінулы блок спасылаецца на існуючы сапраўдны блок.
- Праверыць, што часавая метка блока больш, чым часавая метка папярэдняга блокаfn2 і прайшло менш за 2 гадзіны з моманту стварэння папярэдняга блока
- Праверыць, што доказ працы над блокам з'яўляецца сапраўдным.
- Няхай
S[0]
будзе станам у канцы папярэдняга блока. - Мяркуем, што
TX
з'яўляецца спісам транзакцый блока зn
транзакцыямі. Для ўсіхi
у дыяпазоне0...n-1
, задацьS[i+1] = APPLY(S[i],TX[i])
. Калі якое-небудзь прымяненне звяртае памылку, выйсці і вярнуць false. - Вярнуць значэнне true і ўсталяваць
S[n]
як стан у канцы гэтага блока.
Па сутнасці, кожная транзакцыя ў блоку павінна забяспечваць дакладны пераход стану ад таго, што было кананічным станам да выканання транзакцыі, да якога-небудзь новага стану. Звярніце ўвагу, што стан ніяк не закадзіраваны; гэта чыстая абстракцыя, якая запамінаецца вузлом праверкі і можа быць (бяспечна) вылічана для любога блока толькі пачынаючы з стану генезісу і пры паслядоўным прымяненні кожнай транзакцыі ў кожным блоку. Акрамя таго, звярніце ўвагу, што важны парадак, у якім лайнер уключае транзакцыі ў блок; калі дзве транзакцыі A і B у блоку такія, што B траціць UTXO, створаны A, тады блок будзе сапраўдным, калі A размяшчаецца раней за B, але не наадварот.
Адной з умоў сапраўднасці, прыведзеных у спісе вышэй, якая не сустракаецца ў іншых сістэмах, з'яўляецца патрабаванне «доказу працы». Дакладная ўмова складаецца ў тым, што падвойны SHA256 хэш кожнага блока, разглядаецца як 256-бітны лік, павінен быць менш дынамічна настроенага мэтавага значэння, якое на час гэтага запісу складае прыблізна 2187. Мэта складаецца ў тым, каб зрабіць стварэнне блокаў «складаным» для вылічэння, тым самым не дазваляючы зламыснікам з дапамогай атакі Сівілы перарабіць увесь блокчэйн у сваю карысць. Паколькі алгарытм SHA256 распрацаваны як цалкам непрадказальная псеўдавыпадковая функцыя, то адзіны спосаб стварыць сапраўдны блок — метадам спроб і памылак, пастаянна павялічваючы лік nonce і правяраючы, ці адпавядае новы хэш умове.
Пры цяперашнім мэтавым значэнні ~2187, сетка павінна зрабіць у сярэднім ~269 спроб, перш чым будзе знойдзены дапушчальны блок; як правіла, мэта пералічваецца сеткай кожныя 2016 блокаў, так што ў сярэднім новы блок ствараецца якім-небудзь вузлом у сетцы кожныя дзесяць хвілін. Каб кампенсаваць майнерам гэтую вылічальную працу, майнер кожнага блока мае права ўключыць транзакцыю, даючы сабе 25 BTC ніадкуль. Акрамя таго, калі якая-небудзь транзакцыя мае намінал у яе ўваходах больш, чым у выхадах, то розніца таксама ідзе майнеру як «камісія». Дарэчы, гэта таксама адзіны механізм, з дапамогай якога выпускаюцца BTC; стан генезісу наогул не ўтрымліваў манет.
Каб лепш зразумець мэту майнінгу, давайце разгледзім, што адбываецца ў выпадку злоснай атакі. Паколькі асноватворная крыптаграфія Біткоіна бяспечная, то зламыснік будзе нацэлены на частку сістэмы Біткоіна, якая не абаронена крыптаграфіяй наўпрост — парадак транзакцый. Стратэгія зламысніка простая:
- Адправіць 100 BTC прадаўцу ў абмен на пэўны тавар (пажадана лічбавы тавар з хуткай дастаўкай)
- Дачакацца дастаўкі тавару
- Стварыць яшчэ адну транзакцыю, адпраўляючы тыя ж самыя 100 BTC самому сабе
- Паспрабаваць пераканаць сетку ў тым, што яго транзакцыя самому сабе прыйшла першай.
Як толькі першы крок (1) здарыцца, праз некалькі хвілін нейкі майнер уключыць транзакцыю ў блок, дапусцім у блок нумар 270000. Прыкладна праз гадзіну яшчэ пяць блокаў будуць дададзены ў ланцужок пасля гэтага блока, кожны з якіх ускосна ўказвае на транзакцыю і такім чынам «пацвярджае» яе. На гэтым этапе прадавец прыме плацеж як завершаны і даставіць тавар; паколькі мы мяркуем, што гэта лічбавы тавар, дастаўка будзе імгненнай. Цяпер атакуючы стварае яшчэ адну транзакцыю, адпраўляючы 100 BTC сабе. Калі злачынца проста створыць яе, то транзакцыя не будзе апрацавана; майнеры паспрабуюць запусціць APPLY(S,TX)
і заўважаць, што TX
расходуе UTXO, якога ўжо няма ў стане. Таму замест гэтага злачынца стварае «форк» блокчэйна, пачынаючы са здабычы іншай версіі блока 270000, які ўказвае на той самы блок 269999 у якасці бацькоўскага, але з новай транзакцыяй замест старой. Паколькі дадзеныя блока адрозніваюцца, гэта патрабуе паўторнага выканання працэсу доказу працы. Акрамя таго, новая версія блока 270000 злачынцы мае іншы хэш, таму зыходныя блокі з 270001 па 270005 не «указваюць» на яго; такім чынам, зыходны ланцужок і новы ланцужок злачынцы цалкам падзелены. Правіла такое, што ў форку самы доўгі блокчэйн лічыцца сапраўдным, таму майнеры будуць працаваць над ланцугом з апошнім блокам 270005, у той час як атакуючы будзе працаваць сам над блокам 270000. Каб злачынца зрабіў свой блокчэйн самым доўгім, яму спатрэбіцца больш вылічальнай магутнасці, чым у астатняй сеткі разам узятай, каб нагнаць упушчанае (гэта значыць здзейсніць «атаку 51%»).
Дрэвы Меркла
Злева: дастаткова прадставіць толькі невялікую колькасць вузлоў у дрэве Меркла, каб пацвердзіць правільнасць галіны.
Справа: любая спроба змяніць любую частку дрэва Меркла ў канчатковым выніку прывядзе да несупадзення дзесьці ўверсе ланцужка.
Важнай асаблівасцю маштабавання Біткоіна з'яўляецца тое, што блок захоўваецца ў шматузроўневай структуры даных. «Хэш» блока на самай справе з'яўляецца ўсяго толькі хэшам загалоўка блока, прыкладна 200-байтавым фрагментам дадзеных, які змяшчае часавую метку, nonce, хэш папярэдняга блока і каранёвы хэш структуры дадзеных, якая называецца дрэвам Меркла, у якім захоўваюцца ўсе транзакцыі ў блоку. Дрэва Меркла ўяўляе сабой від бінарнага дрэва, якое складаецца з мноства вузлоў з вялікай колькасцю канчатковых вузлоў у ніжняй частцы дрэва, якія змяшчаюць зыходныя даныя, і мноства прамежкавых вузлоў, у якіх кожны вузел — гэта хэш яго двух дзяцей, і, нарэшце, адзін каранёвы вузел, які таксама ўтвараецца з хэша двух сваіх дзяцей, прадстаўляючы «верх» дрэва. Мэта дрэва Меркла складаецца ў тым, каб дазволіць пастаўку даных блока часткамі: вузел можа загружаць толькі загаловак блока з адной крыніцы, невялікую частку дрэва, якая адносіцца да іх, з іншай крыніцы, і пры гэтым быць упэўненым, што ўсе даныя правільныя. Прычына, па якой гэта працуе, заключаецца ў тым, што хэшы распаўсюджваюцца ўверх: калі злачынца спрабуе замяніць падробленую транзакцыю ў ніжняй частцы дрэва Меркла, то гэтая замена выкліча змену ў вузле вышэй, і потым змену ў вузле, які яшчэ вышэй, і, нарэшце, зменіць корань дрэва і, адпаведна, хэш блока — у выніку пратакол зарэгіструе яго як зусім іншы блок (амаль напэўна з несапраўдным доказам працы).
Пратакол дрэва Меркла несумненна неабходны для доўгатэрміновай устойлівасці. «Поўны вузел» у сетцы Біткоіна, які захоўвае і апрацоўвае цалкам кожны блок, займае каля 15 ГБ дыскавай прасторы па стане на красавік 2014 года, і расце больш чым на гігабайт кожны месяц. У цяперашні час гэта магчыма для некаторых настольных камп'ютараў, але не для тэлефонаў, і ў далейшай будучыні ўдзельнічаць змогуць толькі кампаніі і аматары. Пратакол, вядомы як «спрошчаная праверка аплаты» (SPV), дазваляе існаваць іншаму класу вузлоў, які называецца «лёгкія вузлы», якія загружаюць загалоўкі блокаў, правяраюць доказ працы на загалоўках блокаў, а потым загружаюць толькі «галінкі», звязаныя з транзакцыямі, якія маюць да іх дачыненне. Гэта дазваляе лёгкім вузлам з надзейнай гарантыяй бяспекі вызначаць статус любой транзакцыі біткоіна і бягучы баланс пры загрузцы толькі вельмі невялікай часткі ўсяго блокчэйна.
Альтэрнатыўныя блокчэйн-дадаткі
Ідэя ўзяць аснову блокчэйну і прымяніць яе да іншых канцэпцый таксама мае доўгую гісторыю. У 2005 годзе Нік Сабо выступіў з канцэпцыяй «абароны праў уласнасці з паўнамоцтвамі ўладальніка(opens in a new tab)», дакументам, які апісвае, як «новыя дасягненні ў тэхналогіі рэплікавання баз дадзеных» дазволяць стварыць заснаваную на блокчэйне сістэму для захоўвання рэестра ўладальнікаў зямлі, ствараючы старанна прадуманую структуру, якая ўключае такія паняцці, як прысядзібны ўчастак, незаконнае валоданне і зямельны падатак Генры Джорджа. Аднак, на жаль, у той час не было эфектыўнай рэплікаванай сістэмы баз дадзеных, і таму пратакол ніколі не быў рэалізаваны на практыцы. Але пасля 2009 года, як толькі быў распрацаваны дэцэнтралізаваны кансэнсус біткоіна, хутка пачаў з'яўляцца шэраг альтэрнатыўных дадаткаў.
- Namecoin, створаны ў 2010 годзе. Namecoin(opens in a new tab) лепш за ўсё апісваецца як дэцэнтралізаваная база даных рэгістрацыі імёнаў. У дэцэнтралізаваных пратаколах, такіх як Tor, Bitcoin і BitMessage, павінен быць нейкі спосаб ідэнтыфікацыі акаўнтаў, каб іншыя людзі маглі ўзаемадзейнічаць з імі, але ва ўсіх існуючых рашэннях адзіным даступным ідэнтыфікатарам з'яўляецца псеўдавыпадковы хэш, напрыклад,
1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy
. У ідэале хацелася б мець магчымасць мець акаўнт з імем, напрыклад «george». Аднак праблема ў тым, што калі адзін чалавек можа стварыць акаўнт з імем «george», то пасля хтосьці іншы таксама можа зарэгістравацца як «george» і выдаць сябе за яго. Адзінае рашэнне — парадыгма першай рэгістрацыі, калі першы зарэгістраваны атрымлівае поспех, а другі церпіць няўдачу — праблема, якая ідэальна падыходзіць для кансэнсусу пратаколу біткоіна. Namecoin — найстарэйшая і найбольш паспяховая рэалізацыя сістэмы рэгістрацыі імёнаў, якая выкарыстоўвае такую ідэю. - Каляровыя манеты — мэта каляровых манет(opens in a new tab) — служыць пратаколу, які дазваляе людзям ствараць свае ўласныя лічбавыя валюты, або, у важным трывіяльным выпадку, валюту з адной адзінкай, лічбавыя токены, на блокчэйне біткоіна. У пратаколе каляровых манет хтосьці «выпускае» новую валюту, публічна прызначаючы колер пэўнаму UTXO біткоіна, і пратакол рэкурсіўна вызначае колер іншых UTXO такім жа, як колер уваходных дадзеных транзакцыі, якая стварае іх (некалькі спецыяльных правілаў прымяняюцца ў выпадку ўваходных дадзеных з некалькімі колерамі). Гэта дазваляе карыстальнікам падтрымліваць гаманцы, якія ўтрымліваюць толькі UTXO пэўнага колеру і адпраўляць іх навакольным таксама, як звычайныя біткоіны, праглядваючы блокчэйн для вызначэння колеру любога UTXO, які яны атрымліваюць.
- Мэтакоіны — ідэя мэтакоіна ў тым, каб мець пратакол, які жыве паверх біткоіна, выкарыстоўваючы транзакцыі біткоіна для захоўвання транзакцый мэтакоіна, але які мае іншую функцыю пераходу стану,
APPLY'
. Таму што пратакол мэтакоіна не можа прадухіліць з'яўленне несапраўдных транзакцый мэтакоінаў у блокчэйне біткоіна, дадаецца правіла, згодна з якім, каліAPPLY'(S,TX)
вяртае памылку, то пратакол па змаўчанні мае значэннеAPPLY'(S,TX) = S
. Гэта забяспечвае просты механізм для стварэння адвольнага пратаколу крыптавалюты, патэнцыйна з пашыранымі нерэалізаванымі ўнутры самога біткоіна функцыямі, але з вельмі нізкімі выдаткамі на распрацоўку, паколькі такія складанасці, як майнінг і сеткавае ўзаемадзеянне ўжо апрацоўваюцца пратаколам біткоіна. Мэтакоіны выкарыстоўваліся для рэалізацыі некаторых класаў фінансавых кантрактаў, рэгістрацыі імёнаў і дэцэнтралізаванай біржы.
Такім чынам, існуюць два асноўныя падыходы да пабудовы кансэнсусных пратаколаў: стварэнне незалежнай сеткі і пабудова пратакола на базе біткоіна. Першы падыход, хоць і досыць паспяховы ў выпадку такіх дадаткаў, як Namecoin, яго цяжка рэалізаваць; кожная асобная рэалізацыя патрабуе запуску асобнага блокчэйна, а таксама стварэння і тэставання ўсяго неабходнага кода для пераходу стану і кода для сеткавага ўзаемадзеяння. Акрамя таго, мы прагназуем, што набор дадаткаў для дэцэнтралізаваных тэхналогій, заснаваных на кансэнсусе, будзе адпавядаць закону размеркавання ступені, дзе пераважная большасць дадаткаў будуць занадта малыя, каб апраўдаць наяўнасць уласнага блокчэйну. Таксама мы адзначаем, што існуе вялікая колькасць класаў дэцэнтралізаваных дадаткаў, у прыватнасці, дэцэнтралізаваных аўтаномных арганізацый, якія маюць патрэбу ва ўзаемадзеянні паміж сабой.
З іншага боку, падыход на аснове сеткі біткоін мае недахопы, паколькі ён не атрымлівае ў спадчыну спрошчаныя функцыі праверкі плацяжоў біткоінам. Простая праверка аплаты (SPV) працуе для біткоіна, таму што яна выкарыстоўвае глыбіню блокчэйну як давер для праверкі; калі ў нейкі момант продкі транзакцыі заходзяць дастаткова далёка, можна з упэўненасцю сказаць, што яны законна былі часткай стану. З іншага боку, мэта-пратаколы, заснаваныя на блокчэйне, не могуць прымусіць блокчэйн не ўключаць транзакцыі, якія не з'яўляюцца сапраўднымі ў кантэксце іх уласных пратаколаў. Таму ўкараненне цалкам бяспечнага мэта-пратакола SPV патрабавала б поўнага сканіравання з самага пачатку блокчэйна біткоіна, каб вызначыць сапраўднасць пэўных транзакцый. У цяперашні час усе «лёгкія» рэалізацыі заснаваных на біткоіне мэта-пратаколаў абапіраюцца на давераны сервер для прадстаўлення даных, што з'яўляецца вельмі неаптымальным рашэннем, асабліва з улікам таго, што адной з першачарговых мэт крыптавалюты з'яўляецца ліквідацыя патрэбы ў даверы.
Сцэнарыі
Нават без якіх-небудзь пашырэнняў пратакол біткоіна фактычна забяспечвае простую версію канцэпцыі «разумных кантрактаў». UTXO у біткоіне можа належаць не толькі публічнаму ключу, але і больш складанаму сцэнарыю, выражанаму на простай мове праграмавання на аснове стэка. У гэтай мадэлі транзакцыя, якая траціць дадзены UTXO, павінна прадстаўляць даныя, якія адпавядаюць сцэнарыю. Насамрэч, нават самы базавы механізм валодання публічным ключом рэалізуецца праз сцэнарый: ён прымае падпісаны на аснове эліптычнай крывой подпіс як увод, правярае яго на адпаведнасць транзакцыі і адраса, якому належыць UTXO, і ў выпадку паспяховай праверкі вяртае 1, а ў адваротным выпадку — 0. Існуюць і іншыя, больш складаныя сцэнарыі для розных дадатковых варыянтаў выкарыстання. Напрыклад, можна стварыць сцэнарый, для праверкі якога патрабуюцца подпісы двух з трох дадзеных прыватных ключоў («мультыпадпісанне»), наладка, карысная для карпаратыўных рахункаў, бяспечных ашчадных рахункаў і некаторых сітуацый з умовай укладаў. Сцэнарыі могуць быць таксама прымянімыя для аплаты ўзнагарод за рашэнні вылічальных задач, і можна нават скласці сцэнарый, які кажа нешта накшталт «гэты UTXO біткоіна будзе ваш, калі вы зможаце даць SPV доказ таго, што вы мне паслалі транзакцыю з вось такой сумай Dogecoin», што па сутнасці дазваляе дэцэнтралізаваны абмен розных крыптавалют.
Аднак мова сцэнарыяў, рэалізаваная ў біткоіне, мае некалькі важных абмежаванняў:
- Адсутнасць паўнаты па Т'юрынгу — гэта значыць, хоць існуе велізарная падгрупа вылічэнняў, якія падтрымлівае мова сцэнарыяў біткоіна, яна падтрымлівае далёка не ўсе. Асноўная катэгорыя, якая адсутнічае — гэта цыклы. Гэта неабходна дзеля таго, каб пазбегнуць бясконцых цыклаў падчас праверкі транзакцый; тэарэтычна, такая перашкода пераадольная для распрацоўшчыкаў сцэнарыяў, паколькі любы цыкл можа быць змадэляваны простым паўторам базавага кода шмат разоў з дапамогай аператара if, але гэта прыводзіць да сцэнарыяў, якія вельмі неэфектыўныя з пункта гледжання выкарыстання прасторы. Напрыклад, рэалізацыя альтэрнатыўнага алгарытму для заснаванага на эліптычнай крывой подпісу запатрабуе каля 256 паўторных этапаў множання, якія асобна ўваходзяць у код.
- Цэннасная слепата — у сцэнарыях UTXO няма метаду для забеспячэння дакладнага кантролю над сумай, якая можа быць знятая. Напрыклад, адным з магутных варыянтаў выкарыстання кантракта аракула мог бы быць кантракт на хэджаванне, дзе А і В укладваюць BTC на суму 1000 долараў, і праз 30 дзён скрыпт адпраўляе BTC на суму 1000 долараў А, а астатняе — В. Для гэтага патрэбны быў бы аракул, які вызначае кошт 1 BTC у USD, але нават у гэтым выпадку гэта значнае паляпшэнне з пункту гледжання даверу і патрабаванняў інфраструктуры ў параўнанні з цэнтралізаванымі рашэннямі, якія цяпер даступныя. Аднак, паколькі UTXO працуе па прынцыпе «усё або нічога», адзіны метад дасягнення гэтага — з дапамогай вельмі неэфектыўнага рашэння — наяўнасць вялікай колькасці UTXO розных наміналаў (напрыклад, адзін UTXO са значэннем 2k для кожнага k да 30) і выбар аракула, які UTXO адпраўляць А, а які В.
- Адсутнасць стану — UTXO можа быць як патрачаны, так і не патрачаны; няма магчымасці для выкарыстання шматступеньчатых кантрактаў або сцэнарыяў, якія захоўваюць любы іншы ўнутраны стан, акрамя гэтага. Гэта ўскладняе стварэнне шматступеньчатых кантрактаў з варыянтамі выбару, прапаноў дэцэнтралізаванага абмену ці двухступеньчатых пратаколаў крыптаграфічных абавязацельстваў (неабходных для бяспечных вылічальных узнагарод). Гэта таксама азначае, што UTXO можа быць выкарыстаны толькі для пабудовы простых, аднаразовых кантрактаў, а не больш складаных кантрактаў з захаваннем стану, такіх як дэцэнтралізаваныя арганізацыі, і ўскладняе рэалізацыю мэта-пратаколаў. Бінарнае становішча ў спалучэнні з цэннаснай слепатой таксама азначае, што яшчэ адно важнае прыкладанне, ліміт на вывад, з'яўляецца немагчымым.
- Блокчэйн-слепата — UTXO не бачыць дадзеныя блокчэйну, такія як nonce, метка часу і хэш папярэдняга блока. Гэта сур'ёзна абмяжоўвае прымяненне ў азартных гульнях і некаторых іншых катэгорыях, пазбаўляючы мову сцэнарыяў патэнцыйна каштоўнай крыніцы выпадковасці.
Такім чынам, мы бачым тры падыходы да стварэння пашыраных дадаткаў на аснове крыптавалюты: стварэнне новага блокчэйну, выкарыстанне сцэнарыяў на аснове Біткоіна і пабудова мэта-пратакола на аснове Біткоіна. Стварэнне новага блокчэйну дае неабмежаваную свабоду ў пабудове набору функцый, але патрабуе значных выдаткаў часу на распрацоўку, намаганняў па запуску і забеспячэнні бяспекі. Выкарыстанне сцэнарыяў лёгка рэалізаваць і стандартызаваць, але яны вельмі абмежаваныя ў сваіх магчымасцях, а мэта-пратаколы, хоць і простыя, пакутуюць ад праблем маштабавання. З дапамогай Ethereum мы маем намер стварыць альтэрнатыўную платформу, якая забяспечыць яшчэ большы выйгрыш у прастаце распрацоўкі, а таксама больш лёгкія кліенцкія ўласцівасці, пры гэтым дазваляючы дадаткам сумесна выкарыстоўваць эканамічнае асяроддзе і бяспеку блокчэйну.
Ethereum
Мэтай Ethereum з'яўляецца стварэнне альтэрнатыўнага пратакола для стварэння дэцэнтралізаваных дадаткаў, які забяспечвае іншы набор кампрамісаў, якія, на нашу думку, будуць вельмі карысныя для вялікага класа дэцэнтралізаваных дадаткаў, з асаблівым акцэнтам на сітуацыях, калі важнымі фактарамі з'яўляюцца хуткая распрацоўка і бяспека для невялікіх дадаткаў, якія рэдка выкарыстоўваюцца, і здольнасць розных дадаткаў вельмі эфектыўна ўзаемадзейнічаць. Ethereum робіць гэта, ствараючы тое, што па сутнасці з'яўляецца вышэйшым абстрактным базавым узроўнем: блокчэйн з убудаванай мовай праграмавання, поўнай па Т'юрынгу, якая дазваляе любому чалавеку пісаць разумныя кантракты і дэцэнтралізаваныя дадаткі, дзе людзі могуць ствараць свае ўласныя правілы валодання, фарматы транзакцый і функцыі пераходу стану. Простая версія Namecoin можа быць напісана ў двух радках кода, а іншыя пратаколы, такія як валюты і сістэмы рэпутацыі, могуць быць зроблены менш чым за дваццаць радкоў. Разумныя кантракты — гэта крыптаграфічныя «скрынкі», якія змяшчаюць каштоўнасць і адкрываюць яе толькі пры выкананні пэўных умоў, таксама могуць быць пабудаваны па-над платформай і валодаць значна большай магутнасцю, чым сцэнарыі Біткоіна, дзякуючы дадатковым магчымасцям паўнаты па Т'юрынгу, дасведчанасці аб каштоўнасці, блокчэйну і стану.
Акаўнты Ethereum
У Ethereum стан складаецца з аб'ектаў, званых «акаўнтамі», кожны акаўнт мае 20-байтны адрас, а пераходы стану з'яўляюцца прамымі пераводамі сум і інфармацыі паміж акаўнтамі. Акаўнт у Ethereum мае чатыры палі:
- Лічыльнік nonce, які выкарыстоўваецца для таго, каб кожная транзакцыя магла быць апрацавана толькі адзін раз
- Цяперашні баланс эфіру на акаўнце
- Код кантракта акаўнта, калі ён ёсць
- Сховішча акаўнта (па змоўчванні пустое)
«Эфір» з'яўляецца асноўным унутраным крыптаграфічным палівам Ethereum і выкарыстоўваецца для аплаты камісій за транзакцыі. Увогуле, ёсць два тыпы акаўнтаў: знешнія акаўнты, якія кантралююцца прыватнымі ключамі, і акаўнты кантрактаў, якія кантралююцца кодам свайго кантракта. Знешні акаўнт не мае кода, і з яго можна адпраўляць паведамленні, ствараючы і падпісваючы транзакцыю; у акаўнце кантракта кожны раз, калі акаўнт кантракта атрымлівае паведамленне, яго код актывіруецца, дазваляючы яму чытаць і запісваць ва ўнутраную памяць і адпраўляць іншыя паведамленні або ствараць кантракты ў адказ.
Звярніце ўвагу, што «кантракты» у Ethereum не павінны выглядаць як нешта, што павінна быць зроблена або выканана; хутчэй яны больш падобныя на «аўтаномных агентаў», якія жывуць унутры асяроддзя выканання Ethereum, заўсёды выконваюць вызначаны фрагмент кода у адказ на паведамленне або транзакцыю, і маюць прамы кантроль над прыналежным ім балансам эфіру і іх уласным сховішчам ключоў і значэнняў для адсочвання пастаянных пераменных.
Паведамленні і транзакцыі
Тэрмін «транзакцыя» выкарыстоўваецца ў Ethereum для спасылкі на падпісаны пакет даных, што захоўваюць паведамленне, якое павінна быць адпраўлена са знешняга акаўнта. Транзакцыі маюць:
- Атрымальніка паведамлення
- Подпіс, які ідэнтыфікуе адпраўніка
- Колькасць эфіру для пераводу ад адпраўніка атрымальніку
- Неабавязковае поле даных
- Значэнне
STARTGAS
, якое прадстаўляе максімальную дазволеную колькасць вылічальных крокаў для выканання транзакцыі - Значэнне
GASPRICE
, што прадстаўляе сабой камісію, якую адпраўнік плаціць за кожны вылічальны крок
Першыя тры палі — стандарт у любой крыптавалюце. Поле даных не мае функцыі па змоўчванню, але віртуальная машына мае код аперацыі, выкарыстоўваючы які, кантракт можа мець доступ да гэтых даных; напрыклад, калі кантракт функцыяніруе як служба рэгістрацыі даменаў у блокчэйну, то ён, магчыма, пажадае інтэрпрэтаваць атрыманыя ім даныя, як тыя, што змяшчаюць два «палі», першае «поле» — дамен для рэгістрацыі і другое «поле» — IP-адрас для яго рэгістрацыі. Кантракт будзе счытваць гэтыя значэнні з дадзеных паведамлення і адпаведна размяшчаць іх у сховішчы.
Палі STARTGAS
і GASPRICE
маюць вырашальнае значэнне ў Ethereum для прадухілення адмовы ў абслугоўванні. Каб прадухіліць выпадковыя ці варожыя бясконцыя цыклы ці іншыя вылічальныя страты ў кодзе, кожная транзакцыя павінна мець абмежаванне на колькасць вылічальных крокаў выканання кода, якую яна можа выкарыстоўваць. Фундаментальная адзінка вылічэння гэта «газ»; звычайна, вылічальны крок каштуе 1 адзінку газа, але некаторыя аперацыі каштуюць большай колькасці газа, таму што яны з'яўляюцца даражэйшымі ў сэнсе вылічэння, або павялічваюць аб'ём даных, якія неабходна захоўваць, як частку стану. Таксама існуе камісія ў 5 адзінак газу за кожны байт даных транзакцыі. Мэта сістэмы камісій — патрабаваць зламыснікаў плаціць прапарцыянальны кошт за кожны рэсурс, які яны спажываюць, уключаючы вылічэнні, прапускную здольнасць і захоўванне; такім чынам, любая транзакцыя, якая вядзе да спажывання сеткай большай колькасці гэтых рэсурсаў, павінна мець прыкладна прапарцыянальны прырост платы за газ.
Паведамленні
Кантракты маюць магчымасць адпраўляць «паведамленні» іншым кантрактам. Паведамленні — гэта віртуальныя аб'екты, якія ніколі не серыялізуюцца і існуюць толькі ў асяроддзі выканання Ethereum. Паведамленне мае:
- Адпраўніка паведамлення (няяўна)
- Атрымальніка паведамлення
- Колькасць эфіру для перасылання разам з паведамленнем
- Неабавязковае поле даных
- Значэнне
STARTGAS
Па сутнасці, паведамленне падобна да транзакцыі, за выключэннем таго, што яно ствараецца кантрактам, а не знешнім аб'ектам. Паведамленне ствараецца, калі кантракт, які выконвае ў цяперашні час код, выконвае код аперацыі CALL
, якая стварае і выконвае паведамленне. Падобна транзакцыі, паведамленне вядзе да ўліковага запісу атрымальніка, які запускае яго код. Такім чынам, кантракты могуць узаемадзейнічаць з іншымі кантрактамі, так жа, як гэта могуць рабіць знешнія аб'екты.
Звярніце ўвагу, што расход газу, прызначаны транзакцыяй або кантрактам, распаўсюджваецца на агульную колькасць газу, спажытага гэтай транзакцыяй і ўсімі дадатковымі выкананнямі. Напрыклад, знешні суб'ект А пасылае транзакцыю з 1000 адзінак газу суб'екту B, і B ужывае 600 адзінак газу перад адпраўкай паведамлення C, а ўнутранае выкананне C спажывае 300 адзінак газу перад зваротам, то B можа выкарыстаць яшчэ 100 адзінак газу, перш чым як ён скончыцца.
Функцыя пераходу стану Ethereum
Функцыя пераходу стану Ethereum APPLY(S,TX) -> S'
можа быць вызначана наступным чынам:
- Правярае, ці добра сфарміравана транзакцыя (мае патрэбную колькасць значэнняў), ці сапраўдны подпіс, і ці супадае nonce транзакцыі з nonce у акаўнце адпраўніка. Калі не, то вяртае памылку.
- Вылічае камісію за транзакцыю як
STARTGAS * GASPRICE
, і вызначае адрас адпраўніка зыходзячы з подпісу. Бярэ камісію з балансу акаўнта адпраўніка і павялічвае nonce адпраўніка. Калі балансу недастаткова, вяртае памылку. - Ініцыялізуе
GAS = STARTGAS
і адымае пэўную колькасць газу за кожны байт для аплаты кожнага байту транзакцыі. - Пераводзіць суму транзакцыі з акаўнта адпраўніка на акаўнт атрымальніка. Калі акаўнта атрымальніка пакуль не існуе, то стварае яго. Калі акаўнт атрымальніка з'яўляецца кантрактам, запускае код кантракта або да яго завяршэння, або да таго часу, пакуль не скончыцца газ.
- Калі перавод сумы не атрымаўся, з-за таго, што адпраўнік не мае дастатковай сумы грошай, або пры выкананні кода скончыўся газ, то адмяняюцца ўсе змены стану, акрамя аплаты камісіі і яе залічэння на акаўнт майнера.
- Інакш вяртае адпраўніку ўвесь газ, што застаўся, і адпраўляе камісію за ўжыты газ майнеру.
Напрыклад, дапусцім, што код кантракта такі:
if !self.storage[calldataload(0)]:
self.storage[calldataload(0)] = calldataload(32)
Звярніце ўвагу, што код кантракта на самой справе напісаны на мове EVM нізкага ўзроўню; для яснасці, гэты прыклад напісаны на мове Serpent, адной з нашых моў высокага ўзроўню, і якая можа быць скампілявана ў код EVM. Няхай сховішча кантракта першапачаткова пустое, і транзакцыя адпраўляецца з 10 эфірамі, 2000 адзінкамі газу, з коштам GASPRICE у 0,001 эфіра і 64 байтамі даных, з байтамі 0-31, якія ўяўляюць лік 2
і байтамі 32-63, якія ўяўляюць радок CHARLIE
. Працэс функцыі пераходу стану ў гэтым выпадку выглядае наступным чынам:
- Правярае, што транзакцыя сапраўдная і добра сфарміравана.
- Правярае, што адпраўнік транзакцыі мае як мінімум 2000 * 0.001 = 2 эфіры. Калі гэта так, то адымае 2 эфіры з акаўнта адпраўніка.
- Ініцыялізуе газ = 2000; улічваючы, што транзакцыя складае 170 байт, а плата за байт 5 адзінак газу, адымае 850 і такім чынам застаецца 1150 газу.
- Аднімае яшчэ 10 эфіраў з акаўнта адпраўніка і дадае іх на акаўнт кантракта.
- Запускае код. У гэтым выпадку ён просты: правярае, ці выкарыстоўваецца сховішча кантракта па індэксу
2
, заўважае, што гэта не так, і ўсталёўвае ў значэнне сховішчы па індэксе2
значэннеCHARLIE
. Выкажам здагадку, што для гэтага патрабуецца 187 адзінак газу, так што застанецца: 1150 - 187 = 963 адзінак газу - Пераводзіць 963 * 0,001 = 0,963 эфіру назад на акаўнт адпраўніка і вяртае выніковы стан.
Калі ў прыёмным канцы транзакцыі няма кантракта, то агульная сума камісійных проста была б роўнай суме GASPRICE
, памножанай на велічыню транзакцыі ў байтах, і даныя, якія адпраўляюцца разам з транзакцыяй, не мелі б значэння.
Звярніце ўвагу, што паведамленні працуюць эквівалентна транзакцыям з пункту гледжання скасавання: калі для выканання паведамлення недастаткова газу, тады выкананне гэтага паведамлення і ўсе іншыя выкананні, выкліканыя ім, скасуюцца, але бацькоўскім выкананням не трэба скасавацца. Гэта азначае, што кантракту бяспечна выклікаць іншы кантракт, бо калі А выклікае B, спажываючы G газу, то выкананне A гарантавана губляе максімум G газу. Нарэшце, звярніце ўвагу, што існуе аперацыйны код CREATE
, які стварае кантракт; яго механіка выканання, як правіла, падобна да CALL
, за выключэннем таго, што вынік выканання вызначае код створанага новага кантракта.
Выкананне кода
Код у кантрактах Ethereum напісаны на стэкавай байт-код мове нізкага ўзроўню, званай «Код віртуальнай машыны Ethereum» або «код EVM». Код складаецца з набору байтаў, дзе кожны байт уяўляе аперацыю. У агульным выпадку, выкананне кода — гэта бясконцы цыкл, які складаецца са шматразовага выканання аперацыі на бягучым лічыльніку праграмы (які пачынаецца з нуля) і затым павелічэння лічыльніка праграмы на адзінку, пакуль не будзе дасягнуты канец кода, выяўлена памылка або інструкцыя STOP
ці RETURN
. Аперацыі маюць доступ да трох тыпаў прасторы для захоўвання даных:
- Стэку, кантэйнеру прынцыпу «апошнім прыйшоў — першым выйшаў» і аперацыямі push і pop
- Памяці — масіву байтаў, які бясконца пашыраецца
- Доўгатэрміноваму сховішчу кантракта, якое захоўвае ключы і іх значэнні. У адрозненне ад стэка і памяці, якія скідваюцца пасля завяршэння вылічэнняў, сховішча захоўваецца на працяглы час.
Код таксама можа атрымаць доступ да значэння, адпраўніка і даным уваходнага паведамлення, а таксама да даных загалоўка блока. Код таксама можа вяртаць масіў байтаў даных у якасці вываду.
Фармальная мадэль выканання кода EVM дзіўна простая. Падчас працы віртуальнай машыны Ethereum яе поўны вылічальны стан можа быць вызначаны картэжам (block_state, transaction, message, code, memory, stack, pc, gas)
, дзе block_state
з'яўляецца глабальным станам, які змяшчае ўсе акаўнты, балансы і сховішча. У пачатку кожнага раўнда выканання, бягучая інструкцыя знаходзіцца, беручы pc
байт з code
(або 0 калі pc >= len(code)
), і кожная інструкцыя мае сваё ўласнае вызначэнне ў тым плане, як яна ўплывае на картэж. Напрыклад, ADD
выцягвае два элементы са стэка і штурхае іх суму, памяншае gas
на 1 і павялічвае pc
на 1, а SSTORE
выцягвае два верхніх элементы са стэка і ўстаўляе другі элемент у сховішча кантракта па індэксе, які вызначае першы элемент. Нягледзячы на тое, што ёсць шмат спосабаў аптымізаваць выкананне віртуальнай машыны Ethereum з дапамогай JIT-кампіляцыі, базавая рэалізацыя Ethereum можа быць зроблена ў некалькіх сотнях радкоў кода.
Блокчэйн і майнінг
Блокчэйн Ethereum шмат у чым падобны на блокчэйн Bitcoin, хоць і мае некаторыя адрозненні. Галоўнае адрозненне паміж Ethereum і Біткоінам у дачыненні архітэктуры блокчэйну ў тым, што, у адрозненні ад Біткоіна, блокі Ethereum змяшчаюць копію як спісу транзакцый, так і копію самага апошняга стану. Апроч гэтага, два іншых значэнні, нумар блока і яго складанасць, таксама захоўваюцца ў блоку. Асноўны алгарытм валідацыі блока ў Ethereum наступны:
- Праверка, ці існуе і сапраўдны папярэдні зазначаны блок.
- Праверка, што часавая метка блока больш, чым у папярэдняга зазначанага блока і прайшло менш за 15 хвілін з моманту стварэння папярэдняга блока
- Праверка, што нумар блока, складанасць, корань транзакцыі, корань «дзядзькі» і ліміт на газ (розныя спецыфічныя для Ethereum канцэпцыі нізкага ўзроўню) з'яўляюцца сапраўднымі.
- Праверыць, што доказ працы над блокам з'яўляецца сапраўдным.
- Няхай
S[0]
будзе станам у канцы папярэдняга блока. - Няхай
TX
будзе спісам транзакцый блока зn
транзакцыямі. Для ўсіхi
у дыяпазоне0...n-1
, задацьS[i+1] = APPLY(S[i],TX[i])
. Калі якія-небудзь дадаткі вяртаюць памылку або калі агульны аб'ём газу, спажытага ў блоку да гэтага месца, перавышаеGASLIMIT
, вярнуць памылку. - Няхай
S_FINAL
будзеS[n]
, але з дабаўленнем узнагароджання за блок, якое выплачваецца майнеру. - Праверка, ці аднолькавыя корань дрэва Меркла стану
S_FINAL
і корань канчатковага стану, зазначанага ў загалоўку блока. Калі гэта так, то блок сапраўдны, у адваротным жа выпадку ён такім не з'яўляецца.
На першы погляд такі падыход можа здацца вельмі неэфектыўным, таму што ён павінен захоўваць увесь стан з кожным блокам, але ў рэчаіснасці эфектыўнасць павінна быць параўнальнай з эфектыўнасцю Біткоіна. Прычына ў тым, што стан захоўваецца ў структуры дрэва, і пасля кожнага блока толькі невялікая частка гэтага дрэва павінна быць зменена. Таму ў агульным выпадку, паміж двума суседнімі блокамі пераважная большасць дрэва павінна быць аднолькавай, і таму даныя могуць быць захаваны адзін раз і спасылацца двойчы з дапамогай паказальнікаў (хешаў паддрэваў). Для гэтага выкарыстоўваецца спецыяльны від дрэва, вядомы як «дрэва віду Patricia», ён уключае мадыфікацыю канцэпцыі дрэва Меркла, якая дазваляе эфектыўна ўстаўляць і выдаляць вузлы, а не толькі змяняць іх. Акрамя таго, паколькі ўся інфармацыя аб стане з'яўляецца часткай апошняга блока, няма неабходнасці захоўваць усю гісторыю блокчэйну — гэта стратэгія, якая дазволіла б сэканоміць у 5–20 разоў больш месца, калі яна магла быць прыменена да Біткоіна.
Часта задаецца пытанне: «дзе» выконваецца код кантракта, у тэрмінах фізічнага абсталявання? Гэтае пытанне мае просты адказ: працэс выканання кода кантракта з'яўляецца часткай вызначэння функцыі пераходу стану, якая з'яўляецца часткай алгарытму праверкі блокаў. Такім чынам, калі транзакцыя дадаецца ў блок B
, то выкананне кода, згенераванага гэтай транзакцыяй, будзе выконвацца ўсімі вузламі, зараз і ў будучыні, якія загружаюць і правяраюць блок B
.
Дадаткі
Увогуле ёсць тры тыпы дадаткаў па-над Ethereum. Першая катэгорыя — гэта фінансавыя дадаткі, якія падаюць карыстальнікам больш эфектыўныя спосабы кіравання і заключэння кантрактаў з выкарыстоўваннем сваіх грошай. Сюды ўваходзяць субвалюты, вытворныя фінансавыя інструменты, кантракты для хэджыравання, ашчадныя гаманцы, завяшчанні і, у канчатковым выніку, нават некаторыя віды паўнавартасных працоўных дагавораў. Другая катэгорыя — гэта паў фінансавыя дадаткі, у якіх выкарыстоўваюцца грошы, але іх астатнія функцыі не звязаны с грашыма; выдатным прыкладам з'яўляюцца самарэалізуемыя ўзнагароды за рашэнне вылічальных задач. І нарэшце, ёсць дадаткі для анлайн галасавання і дэцэнтралізаванага кіравання, якія наогул не з'яўляюцца фінансавымі.
Сістэмы токенаў
Сістэмы токенаў на блокчэйну маюць шмат дадаткаў, пачынаючы ад субвалют, якія прадстаўляюць такія актывы як долар або золата, да акцый кампаній, індывідуальных токенаў, якія прадстаўляюць разумную ўласнасць, бяспечных непадрабляльных купонаў і нават сістэм токенаў без прывязкі да традыцыйных каштоўнасцяў наогул, якія выкарыстоўваюцца ў якасці сістэм ачкоў для ўзнагароджванняў. Сістэмы токенаў дзіўна лёгка рэалізаваць у Ethereum. Ключавы момант, які трэба зразумець, складаецца ў тым, што ўся валюта ці сістэма токенаў, па сутнасці, з'яўляецца базай даных з адной аперацыяй: адняць Х адзінак у А і даць Х адзінак B, з умовай, што (i) А меў мінімум Х адзінак да аперацыі і (2) транзакцыя адобрана А. Усё, што трэба для рэалізацыі сістэмы токенаў — гэта рэалізаваць гэтую логіку ў кантракце.
Просты код для рэалізацыі сістэмы токенаў на мове Serpent выглядае так:
def send(to, value):
if self.storage[msg.sender] >= value:
self.storage[msg.sender] = self.storage[msg.sender] - value
self.storage[to] = self.storage[to] + value
Гэта, па сутнасці, літаральнае ажыццяўленне функцыі пераходу стану «банкаўскай сістэмы», апісанай вышэй у гэтым дакуменце. Трэба дадаць некалькі дадатковых радкоў кода, каб у першую чаргу забяспечыць пачатковы этап размеркавання грашовых адзінак і некалькі іншых памежных выпадкаў, і ў ідэале дадаць функцыю, якая дазваляе іншым кантрактам запытваць баланс адраса. Гэта ўсё, што патрабуецца. У тэорыі, заснаваныя на Ethereum сістэмы токенаў, якія дзейнічаюць у якасці субвалют, могуць патэнцыйна ўключаць яшчэ адну важную функцыю, якая адсутнічае ў мета-валют заснаваных на блокчэйну Біткоіна: магчымасць плаціць за транзакцыю непасрэдна ў гэтай валюце. Гэта будзе ажыццяўляцца такім чынам: у кантракце будзе падтрымлівацца баланс эфіра, з дапамогай якога кантракт будзе адпраўляць эфір, патрэбны для аплаты камісіі, адпраўніку. Кантракт папаўняў бы гэты баланс, збіраючы ўнутраныя валютныя адзінкі, якія ён бярэ ў якасці камісіі, і перапрадаючы іх на пастаянным аўкцыёне. Такім чынам, карыстальнікам трэба будзе «актываваць» свае акаўнты з эфірам, але як толькі эфір будзе там, ён будзе паўторна выкарыстоўвацца, таму што кантракт будзе кампенсаваць яго кожны раз.
Вытворныя фінансавыя інструменты і валюты са стабільнай вартасцю
Фінансавыя дэрыватывы — найбольш распаўсюджанае прымяненне «разумнага кантракта», і адно з самых простых для рэалізацыі ў кодзе. Галоўная праблема пры рэалізацыі фінансавых кантрактаў заключаецца ў тым, што для большасці з іх патрабуецца сувязь са знешнім трэкерам цаны; напрыклад, вельмі жаданы дадатак — разумны кантракт, які хэджуе валацільнасць эфіру (ці іншай крыптавалюты) у адносінах да долара ЗША, але для гэтага кантракт павінен ведаць кошт ETH/USD. Самы просты спосаб вырашыць гэта — з дапамогай кантракта «патоку даных», які падтрымліваецца пэўным бокам (напрыклад, NASDAQ), распрацаванага такім чынам, каб гэты бок меў магчымасць абнаўляць кантракт па меры неабходнасці і даваць інтэрфейс, які дазваляе іншым кантрактам адпраўляць паведамленні гэтаму кантракту і атрымліваць адказ з патрэбнай цаной.
З улікам гэтага важнага нюансу кантракт хэджыравання будзе выглядаць наступным чынам:
- Чакае, пакуль бок A унясе 1000 адзінак эфіру.
- Чакае, пакуль бок B унясе 1000 адзінак эфіру.
- Запісвае ў сховішча кошт 1000 адзінак эфіру ў доларах ЗША, вылічаны шляхам запыту да кантракта патока даных, няхай, гэта $x.
- Праз 30 дзён дазваляе A ці B паўторна актываваць кантракт, каб адправіць эфір на суму $x (разлічаную шляхам паўторнага запыту да кантракту патоку даных для атрымання новага кошту) боку A, а астатнюю суму — боку B.
Такі кантракт меў бы значны патэнцыял у крыпта-камерцыі. Адна з асноўных праблем, звязаных з крыптавалютай, заключаецца ў яе валацільнасці; хоць многім карыстальнікам і прадаўцам можа спатрэбіцца бяспека і зручнасць, якую дае праца з крыптаграфічнымі актывамі, яны могуць не жадаць сутыкацца з такой перспектывай, як страта 23% кошту сваіх сродкаў за адзін дзень. Да гэтага часу найбольш часта прапануемым рашэннем былі актывы, забяспечаныя эмітэнтам; ідэя складаецца ў тым, што эмітэнт стварае субвалюту, у якой ён мае права чаканіць і адклікаць адзінкі гэтай самай валюты, а таксама даваць іх любому, хто дасць ім (ужывую) адну адзінку зазначанага базавага актыву (напрыклад золата ці долар ЗША). Затым эмітэнт абяцае даць адну адзінку базавага актыву любому, хто адправіць яму адну адзінку яго крыптавалютнага актыву. Гэты механізм дазваляе «пераўтварыць» любы некрыптаграфічны актыў у крыптаграфічны, пры ўмове, што эмітэнту можна давяраць.
Аднак на практыцы эмітэнты не заўсёды заслугоўваюць даверу, а ў некаторых выпадках банкаўская інфраструктура занадта слабая, ці занадта варожая да існавання такіх паслуг. Фінансавыя дэрыватывы з'яўляюцца альтэрнатывай гэтаму. Тут, замест аднаго эмітэнта, які дае сродкі для забеспячэння актыву, ролю выконвае дэцэнтралізаваны рынак спекулянтаў, якія робяць стаўкі на тое, што кошт вызначанага крыптаграфічнага актыву (напрыклад, ETH) будзе расці. У параўнанні з эмітэнтамі, спекулянты не маюць магчымасці не выканаць сваю частку пагаднення, таму што кантракт хэджыравання трымае іх сродкі ва ўмоўным дэпаніраванні. Звярніце ўвагу, што гэты падыход не з'яўляецца цалкам дэцэнтралізаваным, таму што для прадастаўлення трэкера цаны па-ранейшаму неабходна надзейная крыніца, хоць, магчыма, нават гэта ўсё ж значнае паляпшэнне з пункту гледжання зніжэння патрабаванняў да інфраструктуры (у адрозненне ад выпадку з эмітэнтам, праблема перадачы патоку даных аб цане не патрабуе ліцэнзій і, верагодна, можа быць кваліфікавана як вольныя словы) і зніжае імавернасць махлярства.
Сістэмы ідэнтыфікацыі і рэпутацыі
Самая першая альтэрнатыўная крыптавалюта, Namecoin(opens in a new tab), паспрабавала выкарыстаць Біткоін-падобны блокчэйн для забеспячэння сістэмы рэгістрацыі імёнаў, у якой карыстальнікі могуць зарэгістраваць свае імёны ў агульнадаступнай базе даных разам з іншымі данымі. У асноўным згадваецца варыянт выкарыстання сістэмы DNS(opens in a new tab), якая супастаўляе даменныя імёны, такія як «bitcoin.org» (або, у выпадку Namecoin, «bitcoin.bit») з IP-адрасам. Іншыя варыянты выкарыстання ўключаюць аўтэнтыфікацыю па электроннай пошце і патэнцыйна больш прасунутыя сістэмы рэпутацыі. Вось просты кантракт для забеспячэння сістэмы рэгістрацыі імёнаў, падобнай да Namecoin, у Ethereum:
def register(name, value):
if !self.storage[name]:
self.storage[name] = value
Кантракт вельмі просты; па сутнасці, гэта база даных унутры сеткі Ethereum, у якую можна дадаваць, але нельга змяняць або выдаляць элементы. Любы можа зарэгістраваць пэўнае імя, і гэтая рэгістрацыя застанецца назаўжды. Больш складаны кантракт рэгістрацыі імёнаў таксама будзе мець функцыю ўмовы, якая дазваляе іншым кантрактам запытваць яе, а таксама механізм для «уладальніка» (першага зарэгістраванага) гэтага імя, каб ён мог змяняць даныя або перадаваць правы ўласнасці. Можна нават дадаць функцыі рэпутацыі і функцыянальнасць сэрвісу web-of-trust.
Дэцэнтралізаванае сховішча файлаў
За апошнія некалькі гадоў з'явілася некалькі папулярных анлайн-стартапаў па захоўванні файлаў, найболей вядомым з іх з'яўляецца Dropbox. Яны імкнуцца даць карыстальнікам магчымасць загружаць рэзервовую копію свайго цвёрдага дыску і атрымаць паслугу захоўвання рэзервовай копіі, а гэтак жа падаць карыстальніку доступ да яе ў абмен на штомесячную аплату. Аднак на дадзены момант рынак файлавых сховішчаў адносна неэфектыўны; збеглы погляд на розныя існуючыя рашэнні паказвае, што, асабліва на ўзроўні «злавеснай даліны» у 20–200 ГБ на які не дзейнічаюць ні бясплатныя квоты, ні скідкі для кампаній, штомесячныя цэны за захоўванне файлаў такія, што вы плаціце больш кошту цэлага цвёрдага дыска ў месяц. Кантракты Ethereum могуць дазволіць распрацаваць дэцэнтралізаваную экасістэму захоўвання файлаў, дзе асобныя карыстальнікі могуць зарабляць невялікія сумы грошай, здаючы ў арэнду ўласныя цвёрдыя дыскі і невыкарыставаную памяць, што можа быць скарыстана для наступнага паніжэння кошту захоўвання файлаў.
Ключавым элементам такой прылады будзе тое, што мы назвалі «дэцэнтралізаваны кантракт Dropbox». Гэты кантракт працуе наступным чынам. Спачатку ён падзяляе патрэбныя даныя на блокі, зашыфраваўшы кожны блок для прыватнасці, і будуе з іх дрэва Меркла. Потым ён стварае кантракт з правілам, што кожныя N блокаў гэты кантракт будзе выбіраць выпадковы індэкс у дрэве Меркла (выкарыстоўваючы хэш папярэдняга блока, даступны з кода кантракта, як крыніцу выпадковасці), і даваць Х эфіру першаму аб'екту, які прадаставіць транзакцыю са спрошчанай праверкай плацяжу — як доказ валодання блокам на тым канкрэтным індэксе ў дрэве. Калі карыстальнік жадае перазагрузіць свой файл, ён можа выкарыстаць пратакол канала мікраплацяжу (напрыклад, плаціць 1 сабо за 32 кілабайта) для аднаўлення файла. Найбольш эфектыўным з пункту гледжання платы падыходам з'яўляецца такі: плацельшчык не публікуе транзакцыю да канца, замест гэтага замяняючы транзакцыю на крыху больш выгадную з тым жа nonce пасля кожных 32 кілабайт.
Важная асаблівасць пратакола складаецца ў тым, што хаця можа здавацца, што чалавек давярае выпадковым вузлам у тым, што яны не забудуць яго файл, гэты ж чалавек можа паменшыць рызыку амаль да нуля, падзяліўшы файл на шмат частак праз таемны абмен, і сочачы за кантрактамі, каб бачыць, што кожная частка файла ўсё яшчэ захоўваецца ў нейкім вузле. Калі кантракт усё яшчэ выплачвае грошы, гэта дае крыптаграфічны доказ таго, што нехта ўсё яшчэ захоўвае файл с дапамогай яго.
Дэцэнтралізаваныя аўтаномныя арганізацыі
Дэцэнтралізаванай аўтаномнай арганізацыяй называецца віртуальная арганізацыя, якая складаецца з пэўных членаў або акцыянераў, якія, пры наяўнасці большасці галасоў (напрыклад, 67%) могуць прымаць рашэнні ад імя ўсёй арганізацыі (напрыклад, аб траце сродкаў з фонду арганізацыі або аб мадыфікацыі яе праграмнага кода). Члены калектыўна вырашаюць, як арганізацыя павінна размяркоўваць свае сродкі. Варыянты размеркавання сродкаў DAO могуць вар'іравацца ад выплаты бонусаў і зарплат да нават больш экзатычных механізмаў, такіх як унутраная валюта для ўзнагароджання за працу. Па сутнасці, гэта паўтарае прававыя атрыбуты традыцыйнай кампаніі або некамерцыйнай арганізацыі, але выкарыстоўваючы толькі крыптаграфічную тэхналогію блокчэйна для выканання ўсяго. Да гэтага часу большая частка размоў вакол DAO была пра «капіталістычную» мадэль «дэцэнтралізаванай аўтаномнай карпарацыі» з акцыямі, якія можна прадаць, і акцыянерамі, якія атрымліваюць дывідэнды; альтэрнатыва, магчыма, апісваецца як «дэцэнтралізаваная аўтаномная супольнасць», якая прадугледжвае, што ўсе члены будуць мець роўную долю ў працэсе прыняцця рашэнняў і 67% існуючых членаў павінны пагадзіцца на дадаванне або выдаленне члена. Патрабаванне, каб адзін чалавек мог мець толькі адно членства, павінна быць у такім выпадку падмацавана калектыўна групай.
Агульныя накіды аб тым, як запраграмаваць DAO, наступныя. Самая простая канструкцыя — гэта проста кавалак кода, які можа сам сябе мяняць, і які змяняецца, калі дзве трэці членаў згодны са зменай. Хоць код тэарэтычна нязменны, гэта можна лёгка абысці і мець дэ-факта яго змяняльнасць, маючы фрагменты кода ў асобных кантрактах і адрас для выкліку выбранага кантракта, што захоўваецца ў сховішчы, якое можна мяняць. Пры простай рэалізацыі такога кантракта DAO, будзе тры тыпы транзакцый, яны адрозніваюцца данымі, якія ідуць з транзакцыяй:
[0,i,K,V]
для рэгістрацыі прапановы з індэксамi
для змены адраса ў сховішчы з індэксамK
на значэннеV
[1,i]
для рэгістрацыі голасу на карысць прапановыi
[2,i]
для сканчэння прапановыi
пры атрыманні дастатковай колькасці галасоў
Кантракт будзе змяшчаць палажэнні для кожнага з гэтых тыпаў. Ён будзе весці ўлік усіх агульнадаступных змен сховішча, разам са спісам тых, хто галасаваў за гэтыя змены. Ён таксама будзе мець спіс усіх членаў. Калі любая змена сховішча атрымлівае галасы дзвюх трэціх членаў, завяршальная транзакцыя можа здзейсніць гэту змену. Больш складаная канструкцыя таксама мела б убудаваную магчымасць галасавання для такіх функцый, як адпраўка транзакцыі, даданне і выдаленне членаў, і магла б нават забяспечыць дэлегаванне галасоў у стылі Ліквіднай Дэмакратыі(opens in a new tab) (калі любы можа прызначыць кагосьці галасаваць замест яго, а прызначэнне з'яўляецца транзітыўным, таму калі А прызначае B, а B прызначае C, тады C вызначае голас А). Такі дызайн дазволіў бы DAO арганічна расці як дэцэнтралізаванай супольнасці, дазваляючы людзям у канчатковым выніку дэлегаваць задачу праверкі членаў спецыялістам, хоць у адрозненне ад «сучаснай сістэмы» спецыялісты могуць лёгка з'яўляцца і знікаць з часам, па меры таго, як асобныя члены супольнасці змяняюць свае пазіцыі.
Альтэрнатыўная мадэль — гэта дэцэнтралізаваная карпарацыя, дзе любы акаўнт можа мець нуль альбо больш акцый, а трымальнікі дзвюх трэціх акцый павінны прымаць рашэнне. Поўная канструкцыя будзе ўключаць функцыянальнасць кіравання актывамі, магчымасць рабіць прапанову аб куплі або продажы акцый і магчымасць прымаць прапановы (пажадана з механізмам супастаўлення па парадку ўнутры кантракта). Таксама будзе існаваць дэлегацыя ў стылі Ліквіднай Дэмакратыі, якая абагульняе канцэпцыю «савета дырэктараў».
Дадатковыя прымяненні
1. Ашчадныя гаманцы. Дапусцім, Аліса жадае захоўваць свае сродкі ў бяспецы, але хвалюецца аб тым, што яна страціць або хтосьці можа ўзламаць яе прыватны ключ. Яна кладзе эфір у кантракт, заключаны з Бобам, банкам, наступным чынам:
- Аліса ў адзіночку можа здымаць максімум 1% сродкаў за дзень.
- Боб у адзіночку можа здымаць максімум 1% сродкаў у дзень, але Аліса мае магчымасць здзейсніць транзакцыю з дапамогай свайго ключа, якая выключыць гэтую магчымасць.
- Аліса і Боб разам могуць зняць любую суму.
Як правіла, 1% у дзень дастаткова для Алісы, але калі Аліса хоча зняць больш, яна можа звярнуцца да Боба за дапамогай. Калі ключ Алісы ўзламаюць, то яна бяжыць да Боба, каб перавесці сродкі ў новы кантракт. Калі яна страціць ключ, Боб у канчатковым выніку зніме ўсе сродкі. Калі Боб апынецца зламыснікам, тады яна зможа адключыць яму магчымасць зняцця сродкаў.
2. Страхаванне ўраджаю. Можна лёгка зрабіць фінансавы вытворны кантракт з выкарыстаннем крыніцы даных аб надвор'і замест цаны індэкса. Калі фермер з Аявы купляе вытворны інструмент, які прыносіць даход, зыходзячы з колькасці ападкаў у Аяве, то пры засусе фермер аўтаматычна атрымае грошы, а калі дажджоў дастаткова, фермер будзе шчаслівы, таму што яго ўраджай будзе добра расці. Гэта можа быць распаўсюджана ўвогуле на страхаванне ад стыхійных бедстваў.
3. Дэцэнтралізаваны паток даных. Для фінансавых кантрактаў на розніцу цаны, насамрэч можна дэцэнтралізаваць паток даных праз пратакол пад назвай «SchellingCoin(opens in a new tab)». SchellingCoin у асноўным працуе наступным чынам: усе N бакоў уносяць у сістэму значэнне пэўнага элемента даных (напрыклад, цану ETH/USD), значэнні сартуюцца, і кожны бок паміж 25-м і 75-м працэнцілем атрымлівае адзін токен у якасці ўзнагароды. Кожны мае стымул даваць адказ, які даюць іншыя, і адзінае значэнне, на якое рэальна можа пагадзіцца вялікая колькасць людзей — гэта відавочны стандарт: праўда. Гэта стварае дэцэнтралізаваны пратакол, які тэарэтычна можа даць абы-колькі значэнняў, уключаючы цану ETH/USD, тэмпературу ў Берліне ці нават вынік канкрэтнага складанага вылічэння.
4. Разумнае дэпаніраванне з мультыподпісам. Bitcoin дапускае існаванне кантрактаў з мультыподпісам для транзакцый, дзе, напрыклад, трох з пяці ключоў дастаткова для траты сродкаў. У Ethereum жа магчымасцяў дэталізацыі больш: напрыклад, чатыры з пяці могуць патраціць усё, тры з пяці могуць траціць да 10% у дзень, а два з пяці могуць траціць да 0,5% у дзень. Акрамя таго, мультыподпіс у Ethereum асінхронны — два бакі могуць зарэгістраваць свае подпісы ў блокчэйну ў розны час, а апошні подпіс аўтаматычна адправіць транзакцыю.
5. Воблачныя вылічэнні. Тэхналогія EVM таксама можа быць скарыстана для стварэння вылічальнага асяроддзя, якое можна праверыць і якое дазваляе карыстальнікам прасіць іншых выконваць вылічэнні, а потым пры неабходнасці запытваць доказы таго, што вылічэнні на пэўных выпадкова абраных кантрольных кропках былі выкананы правільна. Гэта дазваляе стварыць рынак воблачных вылічэнняў, у якім можа ўдзельнічаць любы карыстальнік са сваім настольным камп'ютарам, ноўтбукам або спецыялізаваным серверам, а выбарачная праверка разам з закладнымі дэпазітамі можа выкарыстоўвацца для забеспячэння надзейнасці сістэмы (гэта значыць, што вузлы не могуць ашукваць з выгадай для сябе). Але такая сістэма можа падысці не для ўсіх задач; напрыклад, задачы, якія патрабуюць высокага ўзроўню ўзаемадзеяння між працэсамі, нялёгка рэалізаваць на вялікім воблаку вузлоў. Аднак іншыя задачы зрабіць паралельнымі значна лягчэй; такія праекты, як SETI@home, folding@home і генетычныя алгарытмы, могуць быць лёгка рэалізаваны на аснове такой платформы.
6. Аднарангавыя азартныя гульні. Любая колькасць аднарангавых гульнявых пратаколаў, такіх як Cyberdice(opens in a new tab) Фрэнка Стажана і Рычарда Клэйтана, можа быць рэалізавана на блокчэйну Ethereum. Самы просты гульнявы пратакол насамрэч уяўляе сабой проста кантракт на розніцу цаны ў наступным хэшы блока, і на гэтым прынцыпе можна ствараць больш прасунутыя пратаколы, напрыклад гульнявыя сэрвісы з амаль нулявой камісіяй і без магчымасці падману.
7. Рынкі прагназіравання. Пры наяўнасці аракула або SchellingCoin, рынкі прагнозаў таксама лёгка рэалізаваць, а рынкі прагнозаў разам з SchellingCoin могуць апынуцца першым масавым ужываннем футархіі(opens in a new tab) у якасці пратакола кіравання для дэцэнтралізаваных арганізацый.
8. Дэцэнтралізаваныя гандлёвыя пляцоўкі ў сетцы, якія выкарыстоўваюць у якасці асновы сістэму ідэнтыфікацыі і рэпутацыі.
Рознае іншае і праблемы
Мадыфікаваная рэалізацыя GHOST
Пратакол «Greedy Heaviest Observed Subtree» (GHOST) — гэта інавацыя, упершыню ўведзеная Ёнатанам Самалінскім і Авівам Зохарам у Снежні 2013(opens in a new tab). Матыў GHOST заключаецца ў тым, што блокчэйны з хуткім пацверджаннем у цяперашні час пакутуюць ад паніжанай бяспекі з-за высокай хуткасці старэння блокаў — таму што блокам патрабуецца пэўны час для распаўсюджвання па сетцы: калі майнер А здабывае блок, а потым майнер В здабывае іншы блок перад тым, як блок майнера A распаўсюдзіцца да B, то блок майнера B будзе дарэмны і не будзе спрыяць бяспецы сеткі. Акрамя таго, існуе праблема цэнтралізацыі: калі майнер A з'яўляецца майнінг-пулам з 30% магутнасці сеткі, а B мае 10% магутнасці сеткі, тады A будзе рызыкаваць вырабіць састарэлы блок у 70% выпадкаў (паколькі астатнія 30% часу A стварыў апошні блок і, такім чынам, адразу атрымае даныя майнінга), у той час як B будзе мець рызыку вырабіць састарэлы блок у 90% выпадкаў. Такім чынам, калі інтэрвал блока досыць кароткі, каб хуткасць старэння была высокай, A будзе значна больш эфектыўным з-за свайго памеру. У спалучэнні гэтых двух эфектаў блокчэйны, якія хутка вырабляюць блокі, з вялікай доляй імавернасці прывядуць да таго, што адзін майнінг-пул будзе мець дастаткова вялікі працэнт магутнасці сеткі, каб фактычна кантраляваць працэс майнінгу.
Як было апісана Сампалінскім і Зохарам, GHOST вырашае першую праблему страты бяспекі сеткай, уключыўшы ўстарэлыя блокі ў разлік таго, які ланцуг з'яўляецца самым доўгім; гэта значыць не толькі бацькоўскія і далейшыя продкі блока, але таксама і ўстарэлыя нашчадкі продка блока (на жаргоне Ethereum — «дзядзькі») дадаюцца да вылічэння таго, які блок мае найбольшы агульны доказ працы, што падтрымлівае гэты блок. Каб вырашыць другую праблему прадузятасці цэнтралізацыі, мы выходзім за рамкі пратакола, апісанага Сампалінскім і Зохарам, а таксама даем узнагароду за блок устарэлым блокам: устарэлы блок атрымлівае 87,5% сваёй базавай узнагароды, а пляменнік, які ўключае ўстарэлы блок, атрымлівае пакінутыя 12,5%. Аднак камісія за транзакцыі не налічваецца «дзядзькам».
Ethereum рэалізуе спрошчаную версію GHOST, якая спускаецца толькі на сем узроўняў уніз. У прыватнасці, яна вызначаецца наступным чынам:
- Блок павінен паказваць на бацькоўскі блок, і таксама ён павінен паказваць на 0 ці больш дзядзькаў
- Дзядзька, уключаны ў блок В, павінен мець наступныя ўласцівасці:
- Ён павінен быць прамым даччыным продкам B k-га пакалення, дзе
2 <= k <= 7
. - Ён не можа быць продкам B
- У яго павінен быць дапушчальны загаловак блока, але дзядзька неабавязкова павінен быць раней правераным ці нават сапраўдным блокам
- Дзядзька павінен адрознівацца ад усіх дзядзькаў, уключаных у папярэднія блокі, і ўсіх іншых дзядзькаў, уключаных у гэты ж самы блок (без падвойнага ўключэння)
- Ён павінен быць прамым даччыным продкам B k-га пакалення, дзе
- За кожнага дзядзьку U у блоку B майнер блока B атрымлівае дадатковыя 3,125% да яго ўзнагароджання, а майнер U атрымлівае 93,75% ад стандартнай узнагароды.
Гэтая абмежаваная версія GHOST, у якую ўваходзяць толькі дзядзькі да 7 пакалення, выкарыстоўвалася па дзвюм прычынам. Па-першае, GHOST без абмежаванняў будзе мець занадта шмат цяжкасцей пры вылічэнні дапушчальных дзядзькаў для дадзенага блока. Па-другое, неабмежаваны GHOST з кампенсацыяй, пры выкарыстанні ў Ethereum, пазбаўляе майнера стымулу майніць у асноўным ланцужку, а не ў ланцужку публічнага атакуючага.
Камісіі
Паколькі кожная транзакцыя, апублікаваная ў блокчэйну, накладае на сетку выдаткі на яе загрузку і праверку, то існуе неабходнасць у нейкім рэгуліровачным механізме, які, як правіла, уключае камісіі за транзакцыі для прадухілення злоўжыванняў. Стандартны падыход, які выкарыстоўваецца ў Bitcoin, заключаецца ў наяўнасці выключна дабравольных камісій, пры гэтым майнеры выступаюць у ролі кантралёраў і ўстанаўліваюць дынамічныя мінімальныя значэнні. Такі падыход быў вельмі пазітыўна ўспрыняты ў супольнасці Bitcoin, асабліва таму, што ён «рыначны», і дазваляе вызначаць камісію дзякуючы попыту і прапанаванню паміж майнерамі і адпраўнікамі транзакцый. Аднак праблема ў гэтых разважаннях заключаецца ў тым, што апрацоўка транзакцый не з'яўляецца рынкам; хоць інтуітыўна прывабна разглядаць апрацоўку транзакцый як паслугу, якую майнер прапануе адпраўніку, у рэчаіснасці ж кожная транзакцыя, якую ўключае майнер, павінна быць апрацавана кожным вузлом у сетцы, таму пераважная большасць выдаткаў на апрацоўку транзакцый нясуць трэція бакі, а не майнер, які прымае рашэнне уключаць яе ў блок ці не. Такім чынам, вельмі імаверна ўзнікненне праблема трагедыі агульных рэсурсаў.
Аднак гэты недахоп рынкавага механізму пры некаторых дапушчэннях магічна знікае. Аргумент выглядае наступным чынам. Выкажам здагадку, што:
- Транзакцыя складаецца з
k
аперацый і прапануе камісію ў памерыkR
майнеру, які ўключыць яе ў блокчэйн, дзеR
задаецца адпраўніком, аk
іR
вядомыя (прыблізна) майнеру загадзя. - Аперацыя мае кошт апрацоўкі
C
для любога вузла (усе вузлы маюць аднолькавую эфектыўнасць) - Усяго
N
вузлоў, якія майняць, кожны з аднолькавай вылічальнай магутнасцю (г.зн.1/N
ад агульнай магутнасці) - Не існуе поўных вузлоў, якія не майняць.
Майнер будзе гатовы апрацаваць транзакцыю, калі чаканая ўзнагарода перавышае кошт апрацоўкі. Такім чынам, чаканая ўзнагарода роўна kR/N
, паколькі майнер мае шанс 1/N
апрацаваць наступны блок, а кошт апрацоўкі для майнера — kC
. Такім чынам, майнер будзе ўключаць у блок транзакцыі, дзе kR/N > kC
альбо R > NC
. Звярніце ўвагу, што R
— гэта плата за кожную аперацыю, якую ўстанаўлівае адпраўнік, і, такім чынам, гэта ніжняя мяжа выгады, якую адпраўнік атрымлівае ад транзакцыі, а NC
— гэта кошт апрацоўкі аперацыі ўсёй сеткай разам. Таму майнеры маюць стымул уключаць толькі тыя транзакцыі, для якіх агульная выгада перавышае кошт іх апрацоўкі.
Аднак у рэчаіснасці ёсць некалькі важных адхіленняў ад гэтых здагадак:
- Майнеру выходзіць даражэй апрацоўка транзакцыі, чым іншым вузлам праверкі, паколькі дадатковы час праверкі затрымлівае распаўсюджванне блока і, такім чынам, павялічвае імавернасць таго, што блок стане ўстарэлым.
- Існуюць поўныя вузлы, якія не займаюцца майнінгам.
- Размеркаванне магутнасці майнінгу на практыцы можа аказацца вельмі нераўнамерным.
- Спекулянты, палітычныя ворагі і вар'яты, чыя функцыя ўключае ў сябе нанясенне шкоды сетцы, сапраўды існуюць, і яны могуць прадумана ствараць кантракты, у якіх кошт шмат ніжэй кошту, які выплачваецца іншымі вузламі праверкі.
(1) забяспечвае тэндэнцыю для майнера ўключаць менш транзакцый; (2) павялічвае NC
; такім чынам, гэтыя два эфекты па меншай меры часткова пакрываюць адзін аднаго.Як?(opens in a new tab) (3) і (4) з'яўляюцца асноўнымі праблемамі. Каб вырашыць іх, мы проста ўсталёўваем плаваючае абмежаванне: ніводны блок не можа мець больш аперацый, чым BLK_LIMIT_FACTOR
памножаны на доўгатэрміновую экспаненцыяльную зменную сярэднюю. У прыватнасці:
blk.oplimit = floor((blk.parent.oplimit \* (EMAFACTOR - 1) +
floor(parent.opcount \* BLK\_LIMIT\_FACTOR)) / EMA\_FACTOR)
BLK_LIMIT_FACTOR
і EMA_FACTOR
— гэта канстанты, якія на дадзены момант будуць усталяваны на значэнні 65536 і 1,5, але, хутчэй за ўсё, будуць зменены пасля далейшага аналізу.
Ёсць яшчэ адзін фактар, які перашкаджае стварэнню большых блокаў у Bitcoin: вялікія блокі будуць даўжэй распаўсюджвацца, і, такім чынам, вышэй іх імавернасць устарэць. У Ethereum распаўсюджванне блокаў з высокім спажываннем газу таксама можа заняць больш часу, паколькі яны фізічна большыя і патрабуецца больш часу на апрацоўку праверкі пераходаў станаў транзакцый. Гэты фактар затрымкі мае важнае значэнне ў Bitcoin, але ў Ethereum ён менш важны з-за пратаколу GHOST; такім чынам, апора на рэгуляваныя абмежаванні блокаў забяспечвае больш стабільную аснову.
Вылічэнне і паўната па Т'юрынгу
Важна адзначыць, што віртуальная машына Ethereum з'яўляецца поўнай па Т'юрынгу. Гэта азначае, што код EVM можа закадзіраваць любое вылічэнне, якое можна выканаць, уключаючы бясконцыя цыклы. Код EVM дазваляе рабіць цыклы двума спосабамі. Першы — гэта інструкцыя JUMP
, якая дазваляе праграме вярнуцца да папярэдняга месца ў кодзе, і інструкцыя JUMPI
для выканання ўмоўных пераходаў, якая дазваляе выкарыстоўваць такія інструкцыі, як while x < 27: x = x * 2
. Другі — кантракты могуць выклікаць іншыя кантракты, патэнцыйна дазваляючы зацыклівацца праз рэкурсію. Гэта натуральным чынам прыводзіць да праблемы: ці могуць зламыснікі па сутнасці адключыць майнераў і поўныя вузлы, прымусіўшы іх увайсці ў бясконцы цыкл? Гэтая праблема ўзнікае з-за праблемы ў камп'ютарнай навуцы, вядомай як праблема прыпынку: у агульным выпадку немагчыма сказаць, ці спыніцца калі-небудзь дадзеная праграма.
Як апісана ў раздзеле пераходу стану, наша рашэнне працуе, патрабуючы ад транзакцыі ўстанавіць максімальную колькасць вылічальных крокаў, якія ёй дазволена выканаць, і калі выкананне патрабуе больш крокаў, то вылічэнні адмяняюцца, але камісія ўсё роўна плаціцца. Паведамленні працуюць такім жа чынам. Каб паказаць матыў, які стаіць за нашым рашэннем, разгледзім наступныя прыклады:
- Атакуючы стварае кантракт, які запускае бясконцы цыкл, а затым адпраўляе майнеру транзакцыю, якая актывуе гэты цыкл. Майнер апрацуе транзакцыю, запусціўшы бясконцы цыкл, і будзе чакаць, пакуль у ёй не скончыцца газ. Нават калі пры апрацоўцы заканчваецца газ і яна спыняецца на паўдарозе, транзакцыя ўсё яшчэ сапраўдная, і майнер па-ранейшаму возьме ў атакуючага камісію за кожны вылічальны крок.
- Атакуючы стварае вельмі доўгі бясконцы цыкл з мэтай прымусіць майнера працягваць вылічэнні на працягу настолькі доўгага часу, што да моманту завяршэння вылічэнняў будуць створаны яшчэ некалькі блокаў, і майнер не зможа ўключыць транзакцыю ў блок, каб атрымаць камісію. Аднак зламысніку запатрабуецца даць значэнне для
STARTGAS
, якое абмяжоўвае колькасць вылічальных крокаў, якія можна выканаць, таму майнер будзе загадзя ведаць, што вылічэнне зойме празмерна вялікую колькасць крокаў. - Атакуючы бачыць кантракт з кодам у некаторай форме, напрыклад
send(A,contract.storage[A]); contract.storage[A] = 0
, і адпраўляе транзакцыю з дастатковай колькасцю газу толькі для выканання першага кроку, але не другога (г.зн. выводзіць сродкі, але не дае балансу паменшыцца). Аўтару кантракта не трэба турбавацца аб бяспецы ад падобных атак, паколькі калі выкананне транзакцыі спыняецца на паўдарозе, то змены адмяняюцца. - Фінансавы кантракт працуе выкарыстоўваючы медыяннае значэнне дзевяці ўласных каналаў даных з мэтай азімізацыі рызыкі. Атакуючы захоплівае адзін з каналаў даных, які распрацаваны з магчымасцю змянення з дапамогай механізму выкліку з пераменным адрасам, апісанага ў раздзеле аб DAO, і пераўтварае яго ў запуск бясконцага цыклу, тым самым спрабуючы прымусіць любыя спробы атрымаць сродкі з фінансавага кантракта вычэрпваць газ. Аднак фінансавы кантракт можа ўстанавіць ліміт газу ў паведамленні, каб пазбегнуць гэтай праблемы.
Альтэрнатывай паўнаты па Т'юрынгу з'яўляецца непаўната па Т'юрынгу, у якой JUMP
і JUMPI
не існуюць, і толькі адна копія кожнага кантракта можа існаваць у стэку выклікаў у любы момант часу. У гэтай сістэме апісаная вышэй сістэма камісій і нявызначанасці адносна эфектыўнасці нашага рашэння можа аказацца лішняй, паколькі кошт выканання кантракта будзе абмежаваны яго памерам. Акрамя таго, непаўната па Т'юрынгу не з'яўляецца такім ужо вялікім абмежаваннем: з усіх прыкладаў кантрактаў, якія мы задумалі ўнутры, толькі адзін патрабаваў цыкла, і нават гэты цыкл можна было б выдаліць, выканаўшы 26 паўтораў аднарадковага фрагмента кода. Улічваючы сур'ёзныя вынікі паўнаты па Т'юрынгу і абмежаваныя перавагі, чаму б проста не выкарыстоўваць няпоўную па Т'юрынгу мову? Аднак насамрэч непаўната па Т'юрынгу далёка не ідэальнае рашэнне праблемы. Каб зразумець з-за чаго, разгледзьце наступныя кантракты:
C0: call(C1); call(C1);
C1: call(C2); call(C2);
C2: call(C3); call(C3);
...
C49: call(C50); call(C50);
C50: (run one step of a program and record the change in storage)
Цяпер адпраўце транзакцыю карыстальніку A. Такім чынам, у 51-й транзакцыі мы маем кантракт, які займае 250 вылічальных крокаў. Майнеры маглі б спрабаваць выявіць такія лагічныя бомбы наперад, захоўваючы значэнне побач з кожным кантрактам, якое паказвае максімальную колькасць магчымых вылічальных крокаў, і вылічваючы яго для кантрактаў, рэкурсіўна выклікаючых іншыя кантракты, але гэта патрабавала б ад майнераў забараніць кантракты, якія ствараюць іншыя кантракты (паколькі стварэнне і выкананне ўсіх 26 кантрактаў вышэй можна было б лёгка аб'яднаць у адзін кантракт). Іншай праблемай з'яўляецца тое, што поле адраса ў паведамленні з'яўляецца пераменнай, таму ў агульным выпадку немагчыма загадзя сказаць, якія іншыя кантракты выкліча дадзены кантракт. Такім чынам, у цэлым, мы прыходзім да дзіўнай высновы: справіцца з паўнатой па Т'юрынгу на дзіва лёгка, а з адсутнасцю паўнаты па Т'юрынгу таксама на дзіва складана, калі толькі не будуць рэалізаваныя дакладна такія ж элементы кіравання.
Валюта і Выпуск
Сетка Ethereum уключае ў сябе ўбудаваную валюту — эфір, якая служыць для двух мэт: забеспячэння першаснай пластычнасці для эфектыўнага абмену рознымі відамі лічбавых актываў і, што яшчэ больш важна, стварэння механізму аплаты камісіі за транзакцыі. Для зручнасці і каб пазбегнуць спрэчак у будучыні (гл. бягучыя дэбаты mBTC/uBTC/сатошы ў Біткойне), наміналы будуць папярэдне пазначаны:
- 1: wei
- 1012: szabo
- 1015: finney
- 1018: ether
Гэта трэба ўспрымаць як пашыраны варыянт паняццяў «долары» і «цэнты» або «BTC» і «сатошы». Мы чакаем, што ў бліжэйшай будучыні ether («эфір») будзе выкарыстоўвацца для звычайных транзакцый, finney («финні») для мікратранзакцый, а szabo («сабо») і wei («вей») для тэхнічных абмеркаванняў вакол камісій і рэалізацыі пратакола; астатнія намінацыі могуць спатрэбіцца пазней і на дадзены момант не ўключаны ў кліенты.
Мадэль выпуску будзе наступнай:
- Эфір будзе прадавацца па цане 1000-2000 эфіраў за BTC — механізм, прызначаны для фінансавання арганізацыі Ethereum і аплаты распрацоўкі, які паспяхова выкарыстоўваўся іншымі платформамі, такімі як Mastercoin і NXT. Першыя пакупнікі атрымаюць вялікія зніжкі. BTC, атрыманыя ад продажу, будуць цалкам выкарыстаны для выплаты заработнай платы і ўзнагароджанняў распрацоўшчыкам і інвеставання ў розныя камерцыйныя і некамерцыйныя праекты ў экасістэме Ethereum і крыптавалют.
- 0,099x ад агульнай прададзенай сумы (60102216 ETH) будзе выдзелена арганізацыі для кампенсацыі першым укладчыкам і аплаты расходаў, выяўленых у ETH, да першага блока.
- 0,099x ад агульнай прададзенай сумы будзе захоўвацца ў якасці доўгатэрміновага рэзерву.
- Пасля гэтага моманту 0,26x ад агульнай сумы продажу будзе кожны год выдзяляцца майнерам.
Група | Пры старце | Праз 1 год | Праз 5 гадоў |
---|---|---|---|
Грашовыя адзінкі | 1,198X | 1,458X | 2,498X |
Пакупнікі | 83,5% | 68,6% | 40,0% |
Рэзерв выдаткаваны перад продажам | 8,26% | 6,79% | 3,96% |
Рэзерв, выкарыстаны пасля продажу | 8,26% | 6,79% | 3,96% |
Майнеры | 0% | 17,8% | 52,0% |
Доўгатэрміновы рост прапанавання (у працэнтах)
Нягледзячы на лінейную эмісію валюты, як і ў выпадку з Bitcoin, з часам тэмпы росту прапанавання імкнуцца да нуля.
Дзвюма асноўнымі варыянтамі ў вышэйпаказанай мадэлі з'яўляюцца: 1) існаванне і памер пула ахвяраванняў, 2) існаванне прапанавання, якое пастаянна лінейна расце, што адрозніваецца ад абмежаванай колькасці Bitcoin. Абгрунтаванне пула ахвяраванняў наступнае. Калі б пула ахвяраванняў не існавала, а лінейная эмісія была б зменшана да 0,217x для забеспячэння таго ж узроўню інфляцыі, то агульная колькасць эфіру была б на 16,5% менш, а кожная адзінка была б на 19,8% больш каштоўнай. Таму, для раўнавагі, на 19,8% больш эфіру было б адведзена на продаж, каб кожная адзінка была зноў такой жа каштоўнай, як і раней. Тады ў арганізацыі таксама будзе ў 1,198 больш BTC, якія можна лічыць падзеленымі на дзве часткі: зыходныя BTC і дадатковыя 0,198х. Хоць гэтая сітуацыя і цалкам эквівалентная ахвяраванню, але з адным важным адрозненнем: арганізацыя захоўвае выключна BTC і таму не зацікаўлена ў падтрымцы кошту адзінкі эфіру.
Мадэль сталага лінейнага росту прапановы паніжае рызыку, якую некаторыя лічаць празмернай канцэнтрацыяй багацця ў бітконах, і дае людзям, якія жывуць у цяперашні час і ў будучыні, справядлівы шанец набываць грашовыя адзінкі, адначасова захоўваючы моцны стымул атрымліваць і захоўваць эфір, паколькі тэмп росту прапановы ў працэнтных адносінах усё яшчэ з часам імкнецца да нуля. Мы таксама мяркуем, што, паколькі манеты з часам заўсёды губляюцца з-за неасцярожнасці, смерці і г. д., і страты манет можна змадэліраваць як працэнт ад агульнага аб'ёму выпуску ў год, то агульны аб'ём выпуску валюты ў абарачэнні ў канчатковым выніку стабілізуецца на ўзроўні, роўным гадавому выпуску, падзеленаму на ўзровень страт (напрыклад, пры ўзроўні страт 1%, як толькі аб'ём выпуску дасягне 26 адзінак, то 0,26 адзінак будзе здабывацца і 0,26 адзінак будзе губляцца кожны год, што створыць раўнавагу).
Звярніце ўвагу, што ў будучыні Ethereum, хутчэй за ўсё, для забеспячэння бяспекі пяройдзе на мадэль доказу валодання, знізіўшы патрабаванні да выпуску да ўзроўню 0–0,05X у год. У выпадку, калі арганізацыя Ethereum страціць фінансаванне або па якой-небудзь іншай прычыне знікне, мы пакідаем адкрытым «сацыяльны кантракт»: любы мае права стварыць будучую версію-кандыдата Ethereum з адзінай умовай, што колькасць эфіру павінна быць не больш за 60102216 * (1,198 + 0,26 * n)
, дзе n
— колькасць гадоў пасля першага блока. Стваральнікі для аплаты распрацоўкі могуць свабодна прадаваць або іншым чынам перадаваць частку або ўсю розніцу паміж максімальна дапушчальным пашырэннем прапановы і пашырэннем прапановы, атрыманым пры пераходзе да доказу валодання. Абнаўленні-кандыдаты, якія не адпавядаюць сацыяльнаму кантракту, могуць быць законна адгалінаваныя ў сумяшчальныя версіі.
Цэнтралізацыя майнінгу
Алгарытм майнінгу Bitcoin працуе за кошт таго, што майнеры вылічваюць SHA256 на злёгку змененых версіях загалоўка блока мільёны разоў зноў і зноў, пакуль у канчатковым выніку адзін вузел не прапануе версію, хэш якой менш мэтавага (у цяперашні час каля 192). Аднак гэты алгарытм майнінгу ўразлівы да дзвюх формаў цэнтралізацыі. Па-першае, у экасістэме майнінгу сталі дамінаваць ASIC (спецыялізаваныя інтэгральныя схемы) — камп'ютарныя чыпы, распрацаваныя, і, такім чынам, у тысячы разоў больш эфектыўныя для дадзенай задачы, майнінгу Bitcoin. Гэта азначае, што майнінг Bitcoin больш не з'яўляецца высока дэцэнтралізаванай і эгалітарнай дзейнасцю, а таксама патрабуе мільёны долараў для эфектыўнага ўдзелу ў забеспячэнні бяспекі сеткі. Па-другое, большасць біткоін-майнераў на самай справе не праводзяць праверку блокаў лакальна; для прадстаўлення загалоўкаў блока яны спадзяюцца на цэнтралізаваны майнінг-пул. Гэтая праблема, магчыма, яшчэ горшая за першую: на момант напісання гэтага артыкула тры вядучых майнінг-пула ўскосна кантралююць прыкладна 50% магутнасці ў сетцы Bitcoin. Хаця трэба прымаць пад увагу той факт, што майнеры могуць пераключыцца на іншыя майнінг-пулы, калі пул або кааліцыя пулаў паспрабуе правесці атаку 51%.
Цяперашняя мэта Ethereum — выкарыстоўваць алгарытм майнінгу, у якім майнерам неабходна здабываць выпадковыя дадзеныя з стану, вылічваць некаторыя выпадкова выбраныя транзакцыі з апошніх N блокаў блокчэйну і вяртаць хэш выніку. У гэтым ёсць дзве важныя перавагі. Па-першае, кантракты Ethereum могуць уключаць у сябе любыя віды вылічэнняў, таму ASIC для Ethereum па сутнасці будзе ASIC для вылічэнняў у агульным, г. зн. лепшым працэсарам. Па-другое, майнінгу неабходны доступ да ўсяго блокчэйну, што прымушае майнераў захоўваць увесь блокчэйн і, прынамсі, мець магчымасць правяраць кожную транзакцыю. Гэта ліквідуе неабходнасць у цэнтралізаваных пулах для майнінгу; хаця пулы для майнінгу па-ранейшаму могуць выконваць законную ролю ўраўнаважвання выпадковасці размеркавання ўзнагароды, гэтую функцыю могуць з роўным поспехам выконваць і аднарангавыя пулы без цэнтралізаванага кантролю.
Тэсціраванне падобнай мадэлі яшчэ не выконвалася, і могуць узнікнуць складанасці з абыходам некаторых разумных аптымізацый пры выкарыстанні кантрактаў як алгарытму для майнінгу. Адна цікавая асаблівасць гэтага алгарытму заключаецца ў тым, што ён дазваляе каму заўгодна «атруціць калодзеж» шляхам увядзення кантрактаў у блокчэйн, якія здольныя зрабіць непрыдатнымі для іх вылічэння той ці іншы ASIC. Вытворцы ASIC, у тэорыі, маюць фінансавы стымул выкарыстоўваць гэтую асаблівасць для атакі адзін на аднаго. Такім чынам, рашэнне, якое мы распрацоўваем — хутчэй адаптыўнае і эканамічна-сацыяльнае, а не строга тэхнічнае.
Scalability
Адной з распаўсюджаных праблем Ethereum з'яўляецца праблема маштабавання. Як і Bitcoin, Ethereum пакутуе ад недахопу, які складаецца ў тым, што кожная транзакцыя павінна апрацоўвацца кожным вузлом у сетцы. У Bitcoin сучасны памер блокчэйну складае каля 15 ГБ, павялічваючыся прыкладна на 1 МБ у гадзіну. Калі б сетка Bitcoin апрацоўвала 2000 транзакцый у секунду, як Visa, яна б расла на 1 МБ кожныя тры секунды (1 ГБ у гадзіну, 8 ТБ у год). Ethereum, хутчэй за ўсё, сутыкнецца з падобнай мадэллю росту, якая пагаршаецца тым фактам, што па-над блокчэйнам Ethereum будзе створана мноства дадаткаў, а не толькі валюта, як у выпадку з Bitcoin, але змякчальным фактам будзе тое, што поўныя вузлы Ethereum павінны захоўваць толькі стан, а не ўсю гісторыю блокчэйну.
Праблема з такім вялікім блокчэйнам — гэта рызыка цэнтралізацыі. Калі памер блокчэйну павялічыцца, скажам, да 100 ТБ, то верагодным сцэнарыем будзе тое, што толькі вельмі малая колькасць буйных бізнесаў будзе запускаць поўныя вузлы, а ўсе звычайныя карыстальнікі будуць выкарыстоўваць лёгкія вузлы з простай праверкай плацяжоў. У такой сітуацыі ўзнікае патэнцыяльная небяспека таго, што поўныя вузлы могуць яднацца і дамаўляцца аб махлярстве якім-небудзь прыбытковым спосабам (напрыклад, змяняць узнагароду за блок, прысвойваць сабе BTC). Лёгкія вузлы не змогуць адразу гэта выявіць. Вядома, па меншай меры адзін сумленны поўны вузел, хутчэй за ўсё, будзе існаваць, і праз некалькі гадзін інфармацыя аб махлярстве з'явіцца на такіх платформах, як Reddit, але ўжо будзе занадта позна: звычайным карыстальнікам давядзецца арганізавацца і ўнесці гэтыя блокі ў чорны спіс, што ўяўляе сабой вялікую і, магчыма, невыканальную каардынацыйную праблему такога ж маштабу, як і правядзенне паспяховай атакі 51%. У выпадку з Bitcoin гэта на дадзены момант з'яўляецца праблемай, але існуе мадыфікацыя блокчэйну, прапанаваная Пітэрам Тоддам(opens in a new tab), якая вырашае гэтую праблему.
У найбліжэйшай будучыні Ethereum будзе выкарыстоўваць дзве дадатковыя стратэгіі супраць гэтай праблемы. Першая — з-за алгарытмаў майнінгу на аснове блокчэйну, па меншай меры кожны майнер будзе вымушаны стаць поўным вузлом, што стварае ніжнюю мяжу колькасці поўных вузлоў. Другая і больш важная — гэта тое, што мы ўключым прамежкавы корань дрэва стану ў блокчэйн пасля апрацоўкі кожнай транзакцыі. Нават калі праверка блокаў будзе цэнтралізаванай, пакуль існуе хаця б адзін сумленны правяраючы вузел, праблему цэнтралізацыі можна абысці з дапамогай пратакола праверкі. Калі майнер апублікуе несапраўдны блок, гэты блок будзе альбо дрэнна адфарматаваны, альбо стан S[n]
будзе няправільным. Паколькі вядома, што S[0]
з'яўляецца правільным, то павінен быць нейкі першы стан S[i]
, які з'яўляецца няправільным, а S[i-1]
правільны. Вузел праверкі прадставіць індэкс i
разам з «доказам несапраўднасці», які складаецца з падмноства вузлоў дрэва Patricia, якія неабходна апрацаваць APPLY(S[i-1],TX[i]) -> S[i]
. Вузлы змогуць выкарыстоўваць гэтыя вузлы дрэва для выканання гэтай часткі вылічэнняў і ўбачаць, што згенерыраванае S[i]
не адпавядае прадстаўленаму S[i]
.
Іншая, больш складаная атака ўключае публікацыю майнерамі-зламыснікамі няпоўных блокаў, таму нават не існуе поўнай інфармацыі, якая дазваляе вызначыць, ці з'яўляюцца блокі сапраўднымі. Рашэннем гэтай праблемы з'яўляецца пратакол выкліку і адказу: правяраючыя вузлы адпраўляюць «выклікі» ў форме індэксаў мэтавых транзакцый, і пасля атрымання вузла дрэва лёгкі вузел лічыць блок ненадзейным да таго часу, пакуль іншы вузел, няхай гэта будзе майнер ці іншы правяраючы, не прадставіць падмноства вузлоў дрэва Patricia у якасці доказу сапраўднасці.
Заключэнне
Ethereum, як пратакол, першапачаткова разлічаны на тое, каб быць палепшанай версіяй крыптавалюты, падаючы дадатковыя магчымасці, такія як гарант-сэрвіс на блокчэйну, заданне абмежаванняў на зняцце грашовых сум, фінансавыя кантракты, рынкі азартных гульняў і іншае падобнае з дапамогай мовы праграмавання высокага ўзроўню. Ethereum не «падтрымлівае» ніякі з дадаткаў непасрэдна, але наяўнасць поўнай па Т'юрынгу мовы праграмавання азначае, што кантракты могуць быць, у тэорыі, створаны для любых транзакцый і дадаткаў. Аднак што больш цікава ў Ethereum, гэта тое, што пратакол Ethereum выходзіць далёка за рамкі простай крыптавалюты. Пратаколы для дэцэнтралізаванага захоўвання файлаў, дэцэнтралізаваных вылічэнняў і дэцэнтралізаваных рынкаў прагнозаў, а таксама дзясяткі іншых канцэпцый, маюць патэнцыял значна павялічыць эфектыўнасць вылічальнай індустрыі і прыдаць магутны імпульс іншым аднарангавым пратаколам дзякуючы дададзенаму ўпершыню ўзроўню эканомікі. У рэшце рэшт, існуе таксама вялікая колькасць дадаткаў, якія не маюць ніякага дачынення да грошай.
Канцэпцыя функцыі адвольнага пераходу стану, рэалізаваная ў пратаколе Ethereum, забяспечвае платформу унікальным патэнцыялам. Ethereum не з'яўляецца закрытым пратаколам вузкага прызначэння для пэўнага набору дадаткаў у галіне захоўвання даных, азартных гульняў або фінансаў, а з'яўляецца адкрытым па задумцы, і мы лічым, што ён выдатна падыходзіць для таго, каб служыць базавым узроўнем для вялікай колькасці як фінансавых, так і нефінансавых пратаколаў у бліжэйшыя гады.
Заметкі і дадатковая літаратура
Заметкі
- Дасведчаны чытач можа заўважыць, што насамрэч адрас Bitcoin з'яўляецца хэшам публічнага ключа на аснове эліптычнай крывой, а не публічным ключом. Тым не менш, у крыптаграфіі сапраўды дапушчальна называць хэш публічнага ключа публічным ключом. Гэта таму, што крыптаграфію Bitcoin можна лічыць спецыяльным алгарытмам лічбавага подпісу, дзе публічны ключ складаецца з хэша публічнага ключа ECC, подпіс складаецца з публічнага ключа ECC, злучанага з подпісам ECC, а алгарытм праверкі ўключае праверку публічнага ключа ECC у подпісе з хэшам публічнага ключа ECC, прадстаўленым як публічны ключ, а затым праверку подпісу ECC з публічным ключом ECC.
- Тэхнічна, гэта медыяна 11 папярэдніх блокаў.
- Унутрана, 2 і «CHARLIE» з'яўляюцца лікамі fn3, дзе апошні элемент прадстаўлены ў фармаце big-endian базы 256. Лікі могуць быць ад 0 да 2256-1.
Further Reading
- Унутраная вартасць(opens in a new tab)
- Разумная ўласнасць(opens in a new tab)
- Разумныя кантракты(opens in a new tab)
- B-money(opens in a new tab)
- Шматразовыя доказы працы(opens in a new tab)
- Ахова ўласнасці з правамі ўласнасці(opens in a new tab)
- Дакументацыя для Біткоіна(opens in a new tab)
- Namecoin(opens in a new tab)
- Трыкутнік Zooko(opens in a new tab)
- Дакументацыя для каляровых манет(opens in a new tab)
- Дакументацыя для Mastercoin(opens in a new tab)
- Дэцэнтралізаваныя аўтаномныя карпарацыі, Bitcoin Magazine(opens in a new tab)
- Спрошчаная праверка плацяжоў(opens in a new tab)
- Дрэвы Меркла(opens in a new tab)
- Дрэвы тыпу Patricia(opens in a new tab)
- GHOST(opens in a new tab)
- StorJ і аўтаномныя агенты, Джэф Гарзік(opens in a new tab)
- Майк Хэрн пра разумную ўласнасць на фестывалі Т'юрынга(opens in a new tab)
- Ethereum RLP(opens in a new tab)
- Дрэва Меркла тыпу Patricia у Ethereum(opens in a new tab)
- Пітэр Тодд пра сумавыя дрэвы Меркла(opens in a new tab)
Гісторыю дакументацыі можна знайсці ў гэтай вікі(opens in a new tab).
Ethereum, як і многія праекты праграмнага забяспячэння з адкрытым зыходным кодам, кіруемыя супольнасцю, развіваўся з моманту свайго стварэння. Каб даведацца больш пра апошнія навіны ў распрацоўцы Ethereum і як робяцца змяненні ў пратакол, мы прапануем вам наведаць гэтае кіраўніцтва.