Што нам варта блокчэйн пабудаваць?

Уся гісторыя чалавецтва - гэта бесперапыннае збавенне ад ланцугоў і стварэнне новых, яшчэ мацнейшых. (Ананімны аўтар)

Аналізуючы шматлікія blockchain праекты (Bitshares, Hyperledger, Exonum, Ethereum, Bitcoin і інш.), я разумею, што з тэхнічнага пункта гледжання ўсе яны пабудаваны па адных прынцыпам. Блокчейны нагадваюць хаты, у якіх пры ўсёй разнастайнасці канструкцый, дэкору і прызначэнняў маюцца падмурак, сцены, дах, вокны, дзверы, якія злучаны сябар з сябрам вызначанымі спосабамі. І калі зразумець асноўныя прынцыпы праектавання будынкаў, ведаць уласцівасці прымяняюцца матэрыялаў, то можна вызначыць мэтавае прызначэнне канкрэтнага дома. У цяперашні час з блокчэйнам узнікла сітуацыя, што ўсё пра яго чулі, але мала хто разумее архітэктуру і прынцыпы працы. Таму ўзнікае неразуменне для чаго і як мае сэнс выкарыстоўваць тэхналогіі блокчейна.

У дадзеным артыкуле мы разбяром агульныя для ўсіх блокчейнов уласцівасці і прынцыпы. Далей паглядзім на задачы, якія можна вырашаць з дапамогай блокчейна і для замацавання матэрыялу пабудуем маленькі, але сапраўдны блокчейн на сваім віртуальным участку!

Такім чынам, давайце ўспомнім якія праблемы першапачаткова вырашыў блокчэйн.

Упэўнены, што многія скажуць пра размеркаваную, дэцэнтралізаваную, публічную і нязменную базу дадзеных. Але навошта гэта ўсё было патрэбна?

Я аддаю перавагу пачынаць вывучэнне любой тэхналогіі з чытання стандартаў, бо менавіта на іх засноўваюцца ўсе артыкулы і кнігі па доследнай тэме. Але стандарты блокчейна ў цяперашні час адсутнічаюць, у ISO створаны толькі камітэты для іх распрацоўкі. На бягучы момант у кожным публічным блокчейн праекце ёсць свой дакумент White paper, які па сутнасці з'яўляецца тэхнічным заданнем. Першы агульнавядомы блокчэйн праект – гэта сетка Bitcoin. Ідзем на афіцыйны сайт сеткі і глядзім з чаго ўсё пачыналася.

Задача блокчейна

Такім чынам, задача, якую вырашыў блокчейн у сетцы піянеры Bitcoin – гэта здзяйсненне давернай перадачы ўласнасці на лічбавыя актывы (assets) у недаверным асяроддзі без пасярэднікаў. Напрыклад, у сетцы Bitcoin лічбавы актыў - гэта лічбавыя манеты bitcoin. І ўсе тэхнічныя рашэнні Bitcoin і іншых блокчейнов зводзяцца да рашэння гэтай задачы.

Праблемы, якія вырашае блокчэйн

Дапусцім нейкая фінансавая арганізацыя кажа, што пабудавала сетку па ўсім свеце, з дапамогай якой можна пераводзіць грошы любому чалавеку. Ці паверыце вы ёй? Калі гэтая арганізацыя Visa ці MasterCard, хутчэй за ўсё, паверыце, а калі, умоўна кажучы, AnonymousWorldMoney, мусіць, не. Чаму ж? А таму, што мы цудоўна ведаем, як робяцца размеркаваныя сістэмы прыватнымі кампаніямі, з якімі мэтамі, і да чаго гэта можа прывесці. Разгледзім падрабязней праблемы такіх сістэм, і як яны могуць быць вырашаны з ужываннем тэхналогій блокчейна.

Дапушчальны, ва ўмоўнай AnonymousWorldMoney стаяць серверы з базамі дадзеных, і добра, калі іх будзе некалькі ў розных дата-цэнтрах. Калі адпраўнік пераводзіць грошы, рэгіструецца транзакцыя, якая рэплікуецца на ўсе серверы, і грошы даходзяць да атрымальніка.

Што нам варта блокчэйн пабудаваць?

У ідэальным свеце такая схема выдатна працуе, у нашым жа ўзнікаюць наступныя праблемы:

  1. Праблема ідэнтыфікацыі ўдзельнікаў з аднаго боку і неабходнасць ананімнасці транзакцый з другога. Г.зн. трэба перавесці грошы канкрэтнаму атрымальніку і так, каб аб гэтай транзакцыі ніхто не ведаў, акрамя ўдзельнікаў здзелкі. У банкаў ёсць нумары рахункаў і банкаўскіх карт, прывязаных да канкрэтнай фізічнай або юрыдычнай асобы, а банкаўская таямніца абараняе інфармацыю аб транзакцыях. А хто гарантуе, што ўмоўная AnonymousWorldMoney не выкарыстоўвае персанальныя дадзеныя і інфармацыю аб транзакцыях у сваіх мэтах?
  2. Як упэўніцца, што атрымальнік атрымаў менавіта тую суму, якую яму перавялі? Умоўна кажучы, адпраўнік перавёў $100, а атрымальнік атрымаў $10. Прыходзіць адпраўнік у офіс AnonymousWorldMoney са сваёй квітанцыяй, а клерк паказвае сваю версію, дзе запісана, што адпраўнік перавёў толькі $10.
  3. Праблема недавернага асяроддзя, напрыклад, махлярства, званае double-spending. Нядобрасумленны ўдзельнік можа выдаткаваць свой баланс некалькі разоў, пакуль плацёж не рэплікаваўся на ўсе сервера. CAP тэарэму, вядома, ніхто не адмяняў, і ўзгодненасць у канчатковым выніку будзе дасягнута, але нехта не атрымае грошы за аказаныя паслугі або тавары. Таму, калі няма поўнага даверу да плацежнай арганізацыі або ўдзельнікам здзелак, то трэба будаваць сетку, заснаваную не на даверы, а на крыптаграфіі.
  4. Умоўная AnonymousWorldMoney мае канчатковы лік сервераў, якія могуць стаць недаступнымі ненаўмысна або па злому намеру.
  5. AnonymousWorldMoney возьме сваю адчувальную камісію.
  6. Магчымасць кіравання. У працэсе эксплуатацыі Bitcoin высветлілася, што людзі жадаюць не толькі перакладаць манеты адзін аднаму, але і правяраць розныя ўмовы праходжання транзакцыі, праграмаваць сцэнары працы, аўтаматычна выконваць дзеянні ў залежнасці ад умоў і г.д.

Як блокчэйн вырашае гэтыя праблемы

  1. Ідэнтыфікацыя ўдзельнікаў ажыццяўляецца з дапамогай пары ключоў: прыватнага і адкрытага, а алгарытм лічбавага подпісу адназначна ідэнтыфікуе адпраўніка і атрымальніка, пакідаючы іх асобы ананімнымі.
  2. Транзакцыі збіраюцца ў блокі, вылічаецца хэш блока, які запісваецца ў наступны блок. Такая паслядоўнасць запісу хэшаў у блоках і дала назву тэхналогіі blockchain, і яна ж робіць немагчымым незаўважнае змяненне / выдаленне блокаў або асобных транзакцый з блокаў. Такім чынам, калі транзакцыя патрапіла ў блокчэйн, то можна быць упэўненым, што яе дадзеныя застануцца нязменнымі.
  3. Махлярства double-spending прадухіляецца шляхам дасягнення кансенсусу ў сетцы, якія дадзеныя лічыць дакладнымі, а якія адкідаць. У сетцы Bitcoin кансэнсус дасягаецца доказам выканання працы PoW (Proof-of-Work).
  4. Надзейнасць функцыянавання сеткі дасягаецца тым, што блокчейн з'яўляецца публічным, дзе кожны ўдзельнік можа запусціць сваю ноду, атрымаць поўную копію блокчейна і, больш за тое, самастойна пачаць правяраць транзакцыі на правільнасць. Трэба адзначыць, што сучасныя блокчейны дазваляюць будаваць не толькі публічныя (адкрытыя), але і дзелі (закрытыя) блокчейны, а таксама выкарыстоўваць камбінаваныя схемы.
  5. Цалкам ад камісіі ў блокчэйне не пазбавіцца, т.я. трэба плаціць людзям, якія падтрымліваюць сетку, але ў блокчейне неабходнасць камісіі даказваецца так пераканаўча, што не застаецца сумневаў у яе неабходнасці.
  6. Сучасныя блокчейны маюць магчымасць рэалізоўваць бізнэс логіку, якая ў блокчейне завецца Smart Contracts. Логіка смарт кантрактаў рэалізуюцца на розных мовах высокага ўзроўню.

Далей разгледзім гэтыя рашэнні падрабязней.

Архітэктура блокчэйна

Складовыя часткі блокчэйна

Кожны ўдзельнік можа запусціць сваю ноду з поўнай копіяй блокчейна (full node). Поўныя ноды, якія могуць запісваць транзакцыі ў блокчэйн, называюцца вузламі кансэнсусу (witness) або майнерамі (miner). Поўныя ноды, якія толькі правяраюць правільнасць транзакцый называюцца вузламі аўдыту (audit). Лёгкія кліенты (light clients) не захоўваюць поўных дзід блокчейна, а ўзаемадзейнічаюць з сеткай, выкарыстаючы поўныя ноды.
Большасць карыстальнікаў для здзяйснення транзакцый выкарыстоўваюць менавіта лёгкіх кліентаў ці web кашалькі. Усе ноды звязаны адна з адной. Пры такім наборы элементаў архітэктура сеткі становіцца больш устойлівай:

Што нам варта блокчэйн пабудаваць?

Жыццёвы цыкл транзакцыі

Паглядзім на жыццёвы цыкл транзакцыі і разбяром яго па частках:

Што нам варта блокчэйн пабудаваць?

Тэхналогіі блокчейна

Спынімся падрабязней на тэхнічных рашэннях і іх сувязях сябар з сябрам.

ідэнтыфікацыя

Кожная блокчейн транзакцыя павінна быць падпісана лічбавым подпісам. Таму для здзяйснення транзакцыі кожны ўдзельнік павінен мець пару ключоў: private/public. Часам пару ключоў завуць кашалёк (wallet), т.я. ключы адназначна звязаны з унікальным лічбавым адрасам і балансам удзельніка. У рэальнасці ключы і адрасы - гэта проста радкі лічбаў у розных сістэмах злічэння. Прыклады ключоў і адрасы кашалька:

Private key: 0a78194a8a893b8baac7c09b6a4a4b4b161b2f80a126cbb79bde231a4567420f
Public key: 0579b478952214d7cddac32ac9dc522c821a4489bc10aac3a81b9d1cd7a92e57ba
Address: 0x3814JnJpGnt5tB2GD1qfKP709W3KbRdfb27V

Для стварэння лічбавага подпісу ў блокчейнах выкарыстоўваецца алгарытм, заснаваны на эліптычных крывых: Elliptic Curve Digital Signature Algorithm (ECDSA). Для яго працы прыватны ключ (256 бітны лік), як правіла, бярэцца выпадкова. Лік варыянтаў ключоў складае 2 у ступені 256, таму можна казаць аб практычнай немагчымасці супадзення значэнняў прыватных ключоў.

Далей, публічны ключ атрымліваецца з прыватнага шляхам множання яго значэння на каардынаты кропкі, якая знаходзіцца на эліптычнай крывой, у выніку чаго атрымліваюцца каардынаты новай кропкі гэтай жа крывой. Гэтае дзеянне гарантуе атрыманне пары ключоў, прыдатнай для лічбавых подпісаў транзакцый. І нарэшце адрас кашалька адназначна вылічаецца з публічнага ключа.

Ёсць маса артыкулаў з падрабязнасцямі па крыптаграфіі, якая выкарыстоўваецца ў блокчейне, напрыклад: Bitcoin in a nutshell - Cryptography

Прыватны ключ павінен быць строга сакрэтны і захоўвацца ў бяспецы. Публічны ключ вядомы ўсім. Пры страце прыватнага ключа доступ да актыву (манетам) аднавіць немагчыма і грошы будуць страчаны назаўжды. Таму задача надзейнага захоўвання прыватных ключоў вельмі актуальная, т.я. гэта не банк, куды заўсёды можна прыйсці з пашпартам і аднавіць рахунак. Існуе цэлая індустрыя па вытворчасці, так званых, халодных криптокошельков, падобных на флэшкі:

Што нам варта блокчэйн пабудаваць?

ці можна выкарыстоўваць больш надзейныя спосабы, як прыклад, выбіваць значэнне прыватнага ключа на жэтонах:

Што нам варта блокчэйн пабудаваць?

Транзакцыі

Падрабязней пра структуру транзакцыі можна паглядзець у артыкуле Bitcoin in a nutshell - Transaction. Нам жа важна разумець, што кожная транзакцыя мае прынамсі наступныя дадзеныя:

From: 0x48C89c341C5960Ca2Bf3732D6D8a0F4f89Cc4368 - цифровой адрес отправителя
To: 0x367adb7894334678b90аfe7882a5b06f7fbc783a - цифровой адрес получателя
Value: 0.0001 - сумма транзакции
Transaction Hash: 0x617ede331e8a99f46a363b32b239542bb4006e4fa9a2727a6636ffe3eb095cef - хэш транзакции

Далей транзакцыя падпісваецца прыватным ключом і рассылаецца (гл. падрабязнасці па працы пратакола Bitcoin in a nutshell-Protocol) усім нодам у блокчейне, якія правяраюць транзакцыі на валіднасць. Алгарытм праверкі транзакцыі нетрывіяльны і ўключае два дзясяткі крокаў.

Блокі транзакцый

Праверыўшы валіднасць транзакцый, ноды фарміруюць з іх блокі. Апроч транзакцый у блок запісваецца хэш папярэдняга блока, лік (лічыльнік Nonce), і адбываецца вылічэнне хеша бягучага блока па алгарытме SHA-256. Хеш павінен валодаць усталяваным умовам складанасці. Напрыклад, у сетцы Bitcoin складанасць хеша аўтаматычна змяняецца раз у 2 тыдні ў залежнасці ад магутнасці сеткі так, каб блок генераваўся прыкладна раз у 10 хвілін. Складанасць вызначацца наступнай умовай: знойдзены хэш павінен быць менш загадзя зададзенага ліку. Калі дадзеная ўмова не выконваецца, то да Nonce дадаецца 1, і праца па вылічэнні хеша паўтараецца. Для падбору хеша выкарыстоўваецца поле Nonce, т.я. гэта адзіныя дадзеныя ў блоку, якія можна змяніць, астатнія павінны заставацца нязменнымі. Правільны хэш павінен мець пэўную колькасць нулёў у пачатку, напрыклад, адзін з рэальных хэшаў:

000000000000000000000bf03212e7dd1176f52f816fa395fc9b93c44bc11f91

Паспяховае знаходжанне хеша і з'яўляецца доказам праведзенай працы (Proof-of-Work, PoW) для сетак Bitcoin ці Ethereum. Працэс знаходжання хэшаў завецца майнінгам (mining), па аналогіі са здабычай золата. Назва дастаткова дакладна вызначае сутнасць працэсу, т.я. адбываецца просты перабор варыянтаў, і калі хтосьці знайшоў прыдатны хэш, то гэта сапраўды поспех. Гэта як знайсці рэальны самародак золата ў тонах пустой пароды. Узнагароджанне за блок зараз складае 12.5/3900 BTC і калі памножыць на актуальны курс біткоіна $ XNUMX, то атрымліваецца больш кілаграма чыстага золата. Ёсць завошта пазмагацца!

Пасля паспяховага знаходжання хеша блок і сам знойдзены хэш запісваюцца ў блокчейн наступным блокам. Падрабязней па структуру блокаў можна паглядзець у артыкуле Bitcoin у nutshell-Blockchain, а ніжэй прывяду спрошчаную схему:

Што нам варта блокчэйн пабудаваць?

Блокчейн пачынаецца з блока, у якога яшчэ няма хеша папярэдняга блока. Такі блок у блокчейне адзін і мае ўласную назву Genesis block. У астатніх блокаў аднолькавая структура і адрозніваюцца яны толькі лікам транзакцый. Рэальныя транзакцыі і блокі ствараюцца ў наш час у Bitcoin ці Ethereum можна глядзець у Блакаванне Правадыра.

Памер блокаў у Bitcoin абмежаваны 1Мб і пры мінімальным аб'ёме інфармацыі ў транзакцыі каля 200 байт, максімальна ў блоку можа быць каля 6000 транзакцый. Адгэтуль, дарэчы, і вынікае прадукцыйнасць Bitcoin, над якой усё смяюцца: блок генеруецца прыкладна раз у 10 мін*60 сек = 600 сек, што і дае фармальную прадукцыйнасць каля 10 TPS. Хоць насамрэч - гэта не прадукцыйнасць, а свядома рэалізаваны алгарытм працы. У Ethereum для канкурэнцыі проста зрабілі час генерацыі блока 15 сек. і прадукцыйнасць фармальна ўзляцела. Таму ў блокчейнах, выкарыстоўвалых PoW у якасці кансэнсусу наогул бессэнсоўна параўноўваць прадукцыйнасць, т.к. яна напрамую залежыць ад складанасці вылічэнні кэша, якую можна прызначыць любую.

Форкі

А што адбываецца, калі, напрыклад, некалькі вузлоў знайшлі хешы, якія задавальняюць умовам складанасці, але розныя па значэнні (іншымі словамі, прыйшлі да розных кансэнсусаў) і запісалі блокі ў блокчэйн? Давайце паглядзім, як блокчейн абараняецца ад дадзенай сітуацыі. У гэтым выпадку адбываецца, так званы, форк ('відэлец'), і блокчейн мае дзве версіі ланцужкі:

Што нам варта блокчэйн пабудаваць?

Што адбываецца далей? Далей частка сеткі пачынае працаваць над блокам N+2 ад аднаго ланцужка, а частка ад іншай:

Што нам варта блокчэйн пабудаваць?

Які-небудзь з гэтых блокаў будзе знойдзены раней і адпраўлены ў блокчейн і тады па правілах блокчейн павінен будзе пераключыцца на даўжэйшы ланцужок і адмяніць усе транзакцыі з альтэрнатыўнага блока:

Што нам варта блокчэйн пабудаваць?

Пры гэтым можа скласціся сітуацыя, калі транзакцыя ўдзельніка знаходзілася толькі ў адным з блокаў форку, які і быў адменены. Таму, каб быць упэўненым, што патрэбная транзакцыя запісалася ў блокчэйн, ёсць агульная рэкамендацыя - перш чым давяраць транзакцыі трэба пачакаць пакуль наступныя некалькі блокаў не будуць дададзены ў блокчейн. Рэкамендацыі, колькі блокаў чакаць для розных блокчейнов адрозніваюцца. Напрыклад, для сеткі Bitcoin мінімум – гэта 2 блокі, максімум 6.

Такая ж карціна з форкам блокаў будзе назірацца і пры, так званым, нападзе 51% — гэта калі група майнераў будзе спрабаваць вырасціць альтэрнатыўны ланцужок блокаў, дамагаючыся адмены ланцужка са сваімі ашуканскімі транзакцыямі. Хоць цяпер, замест махлярства, больш выгадна траціць свае магутнасці на сумленны майнінг.

Кансэнсус

Для запісу блока ў блокчейн сетка павінна прыйсці да кансэнсусу. Давайце ўспомнім, задачу дасягнення кансэнсусу ў кампутарных сетках сувязі. Праблема фармулюецца, як задача візантыйскіх генералаў BFT (Візантыйская вінавая памяркоўнасць). Апускаючы жывапіснае апісанне праблем візантыйскай арміі, задачу можна сфармуляваць так: як вузлам сеткі прыйсці да агульнага выніку, калі частка вузлоў сеткі могуць свядома іх скажаць. Існуючыя алгарытмы рашэння задачы BFT паказваюць, што сетка можа функцыянаваць правільна, калі ашуканцаў менш за 1/3. Чаму ў сетцы Bitcoin не быў ужыты кансэнсус BFT? Навошта трэба было выкарыстоўваць PoW? Ёсць некалькі прычын:

  • BFT добра працуе з невялікім фіксаваным наборам нод, а ў публічным блокчейне лік нод непрадказальна і, больш за тое, ноды могуць адвольна ўключацца-выключацца.
  • Неабходна матываваць людзей запускаць блокчейн ноды. Для гэтага людзі павінны атрымліваць узнагароду. У BFT фармальна няма за што атрымліваць узнагароду, а вось завошта ідзе ўзнагарода ў PoW усім зразумела на інтуітыўным узроўні: за электрычнасць, спажытае працэсарам падчас знаходжання хеша блока.

Акрамя PoW існуе яшчэ некалькі кансэнсусаў, якія выкарыстоўваюцца ў сучасных блокчейнах, напрыклад:

  • PoS (Proof-of-Stake) - у блокчейне Hyperledger
  • DPoS (Delegated Proof-of-Stake) - у блокчейне BitShares
  • Мадыфікацыі BFT: SBFT ( Simplified BFT ) і PBFT ( Practical BFT ), напрыклад, у блокчейне Exonum

Трохі спынімся на кансэнсусе PoS, т.я. менавіта PoS і яго разнавіднасці атрымалі найбольшае распаўсюджванне ў прыватных блокчейнах. Чаму менавіта ў прыватных? З аднаго боку, характарыстыкі PoS лепш у параўнанні з PoW, т.я. для дасягнення кансэнсусу патрэбныя меншыя вылічальныя рэсурсы, а значыць павялічваецца хуткасць запісу дадзеных у блокчейн. Але з іншага боку ў PoS больш магчымасцяў для махлярства, таму для нейтралізацыі гэтага ўсе ўдзельнікі блокчейна павінны быць вядомыя.

Кансэнсус PoS заснаваны на выбары вузла, які можа запісаць блок з транзакцыямі ў блокчейн у залежнасці ад колькасці сродкаў на рахунку, дакладней, не на рахунку, а ў закладзе, Г.зн. чым у цябе больш сродкаў у закладзе, тым з большай верагоднасцю сетка выбера твой вузел для запісу блока. Заклад не вернецца, калі блок апынецца невалідным. Такім чынам рэалізавана абарона ад махлярства. Ёсць наступныя варыяцыі PoS:

  • Кансэнсус Delegated PoS (DPoS) падзяляе ўдзельнікаў на «галасуючыя» і «якія валідуюць». Трымальнікі манет (якія галасуюць удзельнікі) дэлегуюць сваё права правяраць і запісваць транзакцыі ў блокчейн іншым удзельнікам. Такім чынам, валідатары выконваюць усю вылічальную працу і атрымліваюць за гэтую ўзнагароду, а наяўнасць галасуючых удзельнікаў гарантуе сумленнасць валідатараў, т.я. іх можна змяніць у любы момант.
  • Кансэнсус LPoS (Leased Proof-of-Stake) дазваляе аддаць свае сродкі ў арэнду іншым вузлам, каб тыя мелі больш шанцаў для праверкі блокаў. В.а. можна атрымліваць камісію за транзакцыі, пры гэтым не ўдзельнічаючы ў самой праверцы транзакцый і майнінгу блокаў.

Існуе яшчэ шэраг кансэнсусаў, якія пакуль не атрымалі шырокага распаўсюджвання, тут проста пералічу для інфармацыі, а агляд саміх алгарытмаў кансэнсусу можна паглядзець, напрыклад, у артыкуле: Алгарытмы Кансэнсусу ў Блокчэйне.

  • PoET ( Proof-of-Elapsed Time )
  • PoC ( Proof-of-Capacity )
  • PoB ( Proof-of-Burn )
  • PoWeight (Proof-of-Weight)
  • PoA ( Proof-of-Activity ) - PoW + PoS
  • PoI ( Proof-of-Importans )

Надзейнасць і мадэлі разгортвання блокчейнов

Публічны блокчэйн

ўстойлівасць грамадскага ці іншую назву Permissionless blockchain дасягаецца тым, што кожны можа падлучыцца і прагледзець інфармацыю ці нават падлучыць свой вузел, а давер будуецца на кансэнсусе PoW.

Прыватны блокчэйн

прыватны або Private Permissioned blockchain. У гэтых блокчейнах толькі вызначаная група ўдзельнікаў (арганізацый ці людзей) мае доступ да інфармацыі. Такія блокчейны будуюць арганізацыі з мэтай павелічэння агульнай выгады ці эфектыўнасці. Іх надзейнасць забяспечваецца агульнымі мэтамі ўдзельнікаў і алгарытмамі кансенсусу PoS і BFT.

Блокчэйн-кансорцыум

Існуюць Consortium або Public Permissioned blockchain. Гэта такія блокчейны, да якіх кожны можа падлучыцца для прагляду, але дадаваць інфармацыю ці падлучыць свой вузел удзельнік можа толькі з дазволу іншых удзельнікаў. Такія блокчейны будуюць арганізацыі з мэтай павышэння даверу з боку заказчыкаў ці спажыўцоў прадукцыі або грамадства ў цэлым. Тут надзейнасць таксама дасягаецца прысутнасцю даверу паміж удзельнікамі і тымі ж алгарытмамі кансэнсусу PoS і BFT.

Смарт-кантракты

У блокчейны, рэалізаваныя пасля Bitcoin, у той ці ступені дададзена магчымасць выканання смарт-кантрактаў. Па сутнасці смарт-кантракт - гэта транзакцыя, у якой змешчаны праграмны код для выканання. Смарт-кантракты ў сетцы Ethereum выконваюцца ў EVM (Ethereum Virtual Machine). Для пачатку выканання смарт-кантракта яго трэба відавочна запусціць іншай транзакцыяй, ці павінна выканацца перадумовы для выканання. Вынікі выканання смарт-кантракта таксама запішуцца ў блокчэйн. Атрыманне дадзеных звонку блокчейна магчыма, але вельмі абмежавана.

Якую бізнэс логіку можна рэалізаваць з дапамогай смарт-кантракта? Насамрэч не так ужо шмат, напрыклад праверка ўмоў па дадзеных з блокчейна, змена ўласнікаў лічбавых актываў у залежнасці ад гэтых умоў, запіс дадзеных у сталае сховішча ўсярэдзіне блокчейна. Рэалізуецца логіка на спецыяльнай мове высокага ўзроўню Solidity.

Класічным прыкладам функцыянальнасці, якую рэалізуюць з выкарыстаннем смарт-кантрактаў - гэта выпуск токенаў для правядзення ICO. Напрыклад, мной быў рэалізаваны смарт-кантракт на выпуск сціплых 500 AlexToken. Па спасылцы ў Etherscan знаходзіцца

зыходны код смарт-кантракта на мове Solidity

pragma solidity ^0.4.23;
library SafeMath {
/**
* @dev Multiplies two numbers, throws on overflow.
**/
function mul(uint256 a, uint256 b) internal pure returns (uint256 c) {
if (a == 0) {
return 0;
}
c = a * b;
assert(c / a == b);
return c;
}
/**
* @dev Integer division of two numbers, truncating the quotient.
**/
function div(uint256 a, uint256 b) internal pure returns (uint256) {
// assert(b > 0); // Solidity automatically throws when dividing by 0
/**
* @title SafeMath
* @dev Math operations with safety checks that throw on error
*/
// uint256 c = a / b;
// assert(a == b * c + a % b); // There is no case in which this doesn't hold
return a / b;
}
/**
* @dev Subtracts two numbers, throws on overflow (i.e. if subtrahend is greater than minuend).
**/
function sub(uint256 a, uint256 b) internal pure returns (uint256) {
assert(b <= a);
return a - b;
}
/**
* @dev Adds two numbers, throws on overflow.
**/
function add(uint256 a, uint256 b) internal pure returns (uint256 c) {
c = a + b;
assert(c >= a);
return c;
}
}
/**
* @title Ownable
* @dev The Ownable contract has an owner address, and provides basic authorization control
* functions, this simplifies the implementation of "user permissions".
**/
contract Ownable {
address public owner;
event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);
/**
* @dev The Ownable constructor sets the original `owner` of the contract to the sender account.
**/
constructor() public {
owner = msg.sender;
}
/**
* @dev Throws if called by any account other than the owner.
**/
modifier onlyOwner() {
require(msg.sender == owner);
_;
}
/**
* @dev Allows the current owner to transfer control of the contract to a newOwner.
* @param newOwner The address to transfer ownership to.
**/
function transferOwnership(address newOwner) public onlyOwner {
require(newOwner != address(0));
emit OwnershipTransferred(owner, newOwner);
owner = newOwner;
}
}
/**
* @title ERC20Basic interface
* @dev Basic ERC20 interface
**/
contract ERC20Basic {
function totalSupply() public view returns (uint256);
function balanceOf(address who) public view returns (uint256);
function transfer(address to, uint256 value) public returns (bool);
event Transfer(address indexed from, address indexed to, uint256 value);
}
/**
* @title ERC20 interface
* @dev see https://github.com/ethereum/EIPs/issues/20
**/
contract ERC20 is ERC20Basic {
function allowance(address owner, address spender) public view returns (uint256);
function transferFrom(address from, address to, uint256 value) public returns (bool);
function approve(address spender, uint256 value) public returns (bool);
event Approval(address indexed owner, address indexed spender, uint256 value);
}
/**
* @title Basic token
* @dev Basic version of StandardToken, with no allowances.
**/
contract BasicToken is ERC20Basic {
using SafeMath for uint256;
mapping(address => uint256) balances;
uint256 totalSupply_;
/**
* @dev total number of tokens in existence
**/
function totalSupply() public view returns (uint256) {
return totalSupply_;
}
/**
* @dev transfer token for a specified address
* @param _to The address to transfer to.
* @param _value The amount to be transferred.
**/
function transfer(address _to, uint256 _value) public returns (bool) {
require(_to != address(0));
require(_value <= balances[msg.sender]);
balances[msg.sender] = balances[msg.sender].sub(_value);
balances[_to] = balances[_to].add(_value);
emit Transfer(msg.sender, _to, _value);
return true;
}
/**
* @dev Gets the balance of the specified address.
* @param _owner The address to query the the balance of.
* @return An uint256 representing the amount owned by the passed address.
**/
function balanceOf(address _owner) public view returns (uint256) {
return balances[_owner];
}
}
contract StandardToken is ERC20, BasicToken {
mapping (address => mapping (address => uint256)) internal allowed;
/**
* @dev Transfer tokens from one address to another
* @param _from address The address which you want to send tokens from
* @param _to address The address which you want to transfer to
* @param _value uint256 the amount of tokens to be transferred
**/
function transferFrom(address _from, address _to, uint256 _value) public returns (bool) {
require(_to != address(0));
require(_value <= balances[_from]);
require(_value <= allowed[_from][msg.sender]);
balances[_from] = balances[_from].sub(_value);
balances[_to] = balances[_to].add(_value);
allowed[_from][msg.sender] = allowed[_from][msg.sender].sub(_value);
emit Transfer(_from, _to, _value);
return true;
}
/**
* @dev Approve the passed address to spend the specified amount of tokens on behalf of msg.sender.
*
* Beware that changing an allowance with this method brings the risk that someone may use both the old
* and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this
* race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards:
* https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
* @param _spender The address which will spend the funds.
* @param _value The amount of tokens to be spent.
**/
function approve(address _spender, uint256 _value) public returns (bool) {
allowed[msg.sender][_spender] = _value;
emit Approval(msg.sender, _spender, _value);
return true;
}
/**
* @dev Function to check the amount of tokens that an owner allowed to a spender.
* @param _owner address The address which owns the funds.
* @param _spender address The address which will spend the funds.
* @return A uint256 specifying the amount of tokens still available for the spender.
**/
function allowance(address _owner, address _spender) public view returns (uint256) {
return allowed[_owner][_spender];
}
/**
* @dev Increase the amount of tokens that an owner allowed to a spender.
*
* approve should be called when allowed[_spender] == 0. To increment
* allowed value is better to use this function to avoid 2 calls (and wait until
* the first transaction is mined)
* From MonolithDAO Token.sol
* @param _spender The address which will spend the funds.
* @param _addedValue The amount of tokens to increase the allowance by.
**/
function increaseApproval(address _spender, uint _addedValue) public returns (bool) {
allowed[msg.sender][_spender] = allowed[msg.sender][_spender].add(_addedValue);
emit Approval(msg.sender, _spender, allowed[msg.sender][_spender]);
return true;
}
/**
* @dev Decrease the amount of tokens that an owner allowed to a spender.
*
* approve should be called when allowed[_spender] == 0. To decrement
* allowed value is better to use this function to avoid 2 calls (and wait until
* the first transaction is mined)
* From MonolithDAO Token.sol
* @param _spender The address which will spend the funds.
* @param _subtractedValue The amount of tokens to decrease the allowance by.
**/
function decreaseApproval(address _spender, uint _subtractedValue) public returns (bool) {
uint oldValue = allowed[msg.sender][_spender];
if (_subtractedValue > oldValue) {
allowed[msg.sender][_spender] = 0;
} else {
allowed[msg.sender][_spender] = oldValue.sub(_subtractedValue);
}
emit Approval(msg.sender, _spender, allowed[msg.sender][_spender]);
return true;
}
}
/**
* @title Configurable
* @dev Configurable varriables of the contract
**/
contract Configurable {
uint256 public constant cap = 1000000000*10**18;
uint256 public constant basePrice = 100*10**18; // tokens per 1 ether
uint256 public tokensSold = 0;
uint256 public constant tokenReserve = 500000000*10**18;
uint256 public remainingTokens = 0;
}
/**
* @title CrowdsaleToken 
* @dev Contract to preform crowd sale with token
**/
contract CrowdsaleToken is StandardToken, Configurable, Ownable {
/**
* @dev enum of current crowd sale state
**/
enum Stages {
none,
icoStart, 
icoEnd
}
Stages currentStage;
/**
* @dev constructor of CrowdsaleToken
**/
constructor() public {
currentStage = Stages.none;
balances[owner] = balances[owner].add(tokenReserve);
totalSupply_ = totalSupply_.add(tokenReserve);
remainingTokens = cap;
emit Transfer(address(this), owner, tokenReserve);
}
/**
* @dev fallback function to send ether to for Crowd sale
**/
function () public payable {
require(currentStage == Stages.icoStart);
require(msg.value > 0);
require(remainingTokens > 0);
uint256 weiAmount = msg.value; // Calculate tokens to sell
uint256 tokens = weiAmount.mul(basePrice).div(1 ether);
uint256 returnWei = 0;
if(tokensSold.add(tokens) > cap){
uint256 newTokens = cap.sub(tokensSold);
uint256 newWei = newTokens.div(basePrice).mul(1 ether);
returnWei = weiAmount.sub(newWei);
weiAmount = newWei;
tokens = newTokens;
}
tokensSold = tokensSold.add(tokens); // Increment raised amount
remainingTokens = cap.sub(tokensSold);
if(returnWei > 0){
msg.sender.transfer(returnWei);
emit Transfer(address(this), msg.sender, returnWei);
}
balances[msg.sender] = balances[msg.sender].add(tokens);
emit Transfer(address(this), msg.sender, tokens);
totalSupply_ = totalSupply_.add(tokens);
owner.transfer(weiAmount);// Send money to owner
}
/**
* @dev startIco starts the public ICO
**/
function startIco() public onlyOwner {
require(currentStage != Stages.icoEnd);
currentStage = Stages.icoStart;
}
/**
* @dev endIco closes down the ICO 
**/
function endIco() internal {
currentStage = Stages.icoEnd;
// Transfer any remaining tokens
if(remainingTokens > 0)
balances[owner] = balances[owner].add(remainingTokens);
// transfer any remaining ETH balance in the contract to the owner
owner.transfer(address(this).balance); 
}
/**
* @dev finalizeIco closes down the ICO and sets needed varriables
**/
function finalizeIco() public onlyOwner {
require(currentStage != Stages.icoEnd);
endIco();
}
}
/**
* @title LavevelToken 
* @dev Contract to create the Lavevel Token
**/
contract AlexToken is CrowdsaleToken {
string public constant name = "AlexToken";
string public constant symbol = "ALT";
uint32 public constant decimals = 18;
}

і бінарнае ўяўленне, як яго бачыць сетка

60806040526000600355600060045533600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff1602179055506000600560146101000a81548160ff021916908360028111156200006f57fe5b0217905550620001036b019d971e4fe8401e74000000600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546200024a6401000000000262000b1d179091906401000000009004565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550620001986b019d971e4fe8401e740000006001546200024a6401000000000262000b1d179091906401000000009004565b6001819055506b033b2e3c9fd0803ce8000000600481905550600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef6b019d971e4fe8401e740000006040518082815260200191505060405180910390a362000267565b600081830190508281101515156200025e57fe5b80905092915050565b611cb880620002776000396000f300608060405260043610610112576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306fdde03146104c7578063095ea7b31461055757806318160ddd146105bc57806323b872dd146105e7578063313ce5671461066c578063355274ea146106a3578063518ab2a8146106ce57806366188463146106f957806370a082311461075e57806389311e6f146107b55780638da5cb5b146107cc578063903a3ef61461082357806395d89b411461083a578063a9059cbb146108ca578063bf5839031461092f578063c7876ea41461095a578063cbcb317114610985578063d73dd623146109b0578063dd62ed3e14610a15578063f2fde38b14610a8c575b60008060008060006001600281111561012757fe5b600560149054906101000a900460ff16600281111561014257fe5b14151561014e57600080fd5b60003411151561015d57600080fd5b600060045411151561016e57600080fd5b3494506101a7670de0b6b3a764000061019968056bc75e2d6310000088610acf90919063ffffffff16565b610b0790919063ffffffff16565b9350600092506b033b2e3c9fd0803ce80000006101cf85600354610b1d90919063ffffffff16565b111561024c576101f66003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b915061022e670de0b6b3a764000061022068056bc75e2d6310000085610b0790919063ffffffff16565b610acf90919063ffffffff16565b90506102438186610b3990919063ffffffff16565b92508094508193505b61026184600354610b1d90919063ffffffff16565b6003819055506102886003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b6004819055506000831115610344573373ffffffffffffffffffffffffffffffffffffffff166108fc849081150290604051600060405180830381858888f193505050501580156102dd573d6000803e3d6000fd5b503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef856040518082815260200191505060405180910390a35b610395846000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef866040518082815260200191505060405180910390a361045184600154610b1d90919063ffffffff16565b600181905550600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc869081150290604051600060405180830381858888f193505050501580156104bf573d6000803e3d6000fd5b505050505050005b3480156104d357600080fd5b506104dc610b52565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561051c578082015181840152602081019050610501565b50505050905090810190601f1680156105495780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b34801561056357600080fd5b506105a2600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610b8b565b604051808215151515815260200191505060405180910390f35b3480156105c857600080fd5b506105d1610c7d565b6040518082815260200191505060405180910390f35b3480156105f357600080fd5b50610652600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610c87565b604051808215151515815260200191505060405180910390f35b34801561067857600080fd5b50610681611041565b604051808263ffffffff1663ffffffff16815260200191505060405180910390f35b3480156106af57600080fd5b506106b8611046565b6040518082815260200191505060405180910390f35b3480156106da57600080fd5b506106e3611056565b6040518082815260200191505060405180910390f35b34801561070557600080fd5b50610744600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291908035906020019092919050505061105c565b604051808215151515815260200191505060405180910390f35b34801561076a57600080fd5b5061079f600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506112ed565b6040518082815260200191505060405180910390f35b3480156107c157600080fd5b506107ca611335565b005b3480156107d857600080fd5b506107e16113eb565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b34801561082f57600080fd5b50610838611411565b005b34801561084657600080fd5b5061084f6114ab565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561088f578082015181840152602081019050610874565b50505050905090810190601f1680156108bc5780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b3480156108d657600080fd5b50610915600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803590602001909291905050506114e4565b604051808215151515815260200191505060405180910390f35b34801561093b57600080fd5b50610944611703565b6040518082815260200191505060405180910390f35b34801561096657600080fd5b5061096f611709565b6040518082815260200191505060405180910390f35b34801561099157600080fd5b5061099a611716565b6040518082815260200191505060405180910390f35b3480156109bc57600080fd5b506109fb600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050611726565b604051808215151515815260200191505060405180910390f35b348015610a2157600080fd5b50610a76600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff169060200190929190505050611922565b6040518082815260200191505060405180910390f35b348015610a9857600080fd5b50610acd600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506119a9565b005b600080831415610ae25760009050610b01565b8183029050818382811515610af357fe5b04141515610afd57fe5b8090505b92915050565b60008183811515610b1457fe5b04905092915050565b60008183019050828110151515610b3057fe5b80905092915050565b6000828211151515610b4757fe5b818303905092915050565b6040805190810160405280600981526020017f416c6578546f6b656e000000000000000000000000000000000000000000000081525081565b600081600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925846040518082815260200191505060405180910390a36001905092915050565b6000600154905090565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff1614151515610cc457600080fd5b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d1157600080fd5b600260008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d9c57600080fd5b610ded826000808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610e80826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610f5182600260008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b600260008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a3600190509392505050565b601281565b6b033b2e3c9fd0803ce800000081565b60035481565b600080600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205490508083111561116d576000600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611201565b6111808382610b3990919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b8373ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008873ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a3600191505092915050565b60008060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549050919050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561139157600080fd5b60028081111561139d57fe5b600560149054906101000a900460ff1660028111156113b857fe5b141515156113c557600080fd5b6001600560146101000a81548160ff021916908360028111156113e457fe5b0217905550565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1681565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561146d57600080fd5b60028081111561147957fe5b600560149054906101000a900460ff16600281111561149457fe5b141515156114a157600080fd5b6114a9611b01565b565b6040805190810160405280600381526020017f414c54000000000000000000000000000000000000000000000000000000000081525081565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff161415151561152157600080fd5b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054821115151561156e57600080fd5b6115bf826000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611652826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a36001905092915050565b60045481565b68056bc75e2d6310000081565b6b019d971e4fe8401e7400000081565b60006117b782600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a36001905092915050565b6000600260008473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054905092915050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff16141515611a0557600080fd5b600073ffffffffffffffffffffffffffffffffffffffff168173ffffffffffffffffffffffffffffffffffffffff1614151515611a4157600080fd5b8073ffffffffffffffffffffffffffffffffffffffff16600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff167f8be0079c531659141344cd1fd0a4f28419497f9722a3daafe3b4186f6b6457e060405160405180910390a380600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff16021790555050565b6002600560146101000a81548160ff02191690836002811115611b2057fe5b021790555060006004541115611c0a57611ba5600454600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc3073ffffffffffffffffffffffffffffffffffffffff16319081150290604051600060405180830381858888f19350505050158015611c89573d6000803e3d6000fd5b505600a165627a7a723058205bbef016cc7699572f944871cb6f05e69915ada3a92a1d9f03a3fb434aac0c2b0029

Больш падрабязнасцяў пра смарт-кантракты можна даведацца ў артыкуле: Што такое смарт-кантракты ў Ethereum.

Заключэнне

Мы пералічылі тэхналогіі на якіх пабудаваны сучасныя блокчейны і як яны звязаны адзін з адным. Цяпер давайце сфармулюем, якія задачы можна вырашыць з дапамогай блокчейна, а рашэнні якіх будзе, у лепшым выпадку, неэфектыўна. Такім чынам, выкарыстанне блокчейна не абавязкова, калі:

  • Транзакцыі здзяйсняюцца ў даверным асяроддзі;
  • Наяўнасць камісіі пасярэднікаў не пагаршае жыццё ўдзельнікаў;
  • Удзельнікі не маюць уласнасці, якую можна прадставіць у выглядзе лічбавых актываў;
  • Няма размеркаванасці ў лічбавых актывах, г.зн. каштоўнасцю валодае ці пастаўляе толькі адзін удзельнік.

Якая будучыня чакае блокчэйн? Цяпер можна толькі меркаваць магчымыя шляхі развіцця блокчейн тэхналогій:

  • Блокчейн стане такой жа звычайнай тэхналогіяй баз дадзеных, як, напрыклад, SQL ці NoSQL для рашэння свайго вызначанага круга задач;
  • Блакчэйн стане шырока распаўсюджаным пратаколам, як HTTP для Інтэрнэту;
  • Блокчэйн стане асновай для новай фінансавай і палітычнай сістэмы планеты!

Мы ж у наступнай частцы паглядзім якія зараз існуюць блокчейны і для чаго яны прымяняюцца ў розных індустрыях.

Гэта толькі пачатак!

Крыніца: habr.com

Дадаць каментар