Біла книга Ethereum

Цю вступну статтю спочатку опублікував у 2014 році Віталік Бутерін, засновник Ethereum, перед запуском проєкту у 2015 році. Варто зазначити, що платформа Ethereum, як і багато інших проєктів програмного забезпечення з відкритим вихідним кодом, що керуються спільнотою, еволюціонувала з моменту її створення.

Попри те, що цій статті вже кілька років, ми зберігаємо її, оскільки вона є корисним довідковим ресурсом і точним відображенням Ethereum і нашого бачення. Щоб дізнатися про останні розробки Ethereum і про те, як вносяться зміни до протоколу, ми рекомендуємо цей посібник.

Дослідникам та науковцям, які шукають історичну або канонічну версію офіційного документа [від грудня 2014 року], слід використовувати цей PDF-файл.

Платформа нового покоління для смарт-контрактів та децентралізованих застосунків

Розробка Bitcoin Сатоші Накамото у 2009 році часто віталася як радикальний розвиток грошей і валюти, будучи першим прикладом цифрового активу, який одночасно не має забезпечення або "внутрішньої вартостіopens in a new tab" і не має централізованого емітента чи контролера. Однак інша, і, можливо, більш важлива, частина експерименту з Bitcoin — це базова технологія блокчейн як інструмент розподіленого консенсусу, і увага швидко починає зміщуватися на цей інший аспект Bitcoin. Часто згадувані альтернативні сфери застосування технології блокчейн включають використання цифрових активів на блокчейні для представлення власних валют і фінансових інструментів ("кольорові монетиopens in a new tab"), володіння базовим фізичним пристроєм ("розумна власністьopens in a new tab"), незамінних активів, таких як доменні імена ("Namecoinopens in a new tab"), а також більш складні застосування, що передбачають безпосереднє керування цифровими активами за допомогою програмного коду, який реалізує довільні правила ("смарт-контрактиopens in a new tab") або навіть "децентралізовані автономні організаціїopens in a new tab" (DAO) на основі блокчейну. Ethereum має намір надати блокчейн із вбудованою повноцінною мовою програмування, повною за Тюрінгом, яку можна використовувати для створення "контрактів", що можуть бути використані для кодування довільних функцій переходу стану, що дозволяє користувачам створювати будь-яку з описаних вище систем, а також багато інших, які ми ще навіть не уявляли, просто написавши логіку в кількох рядках коду.

Вступ до Bitcoin та існуючих концепцій

Історія

Концепція децентралізованої цифрової валюти, а також альтернативні застосування, такі як реєстри власності, існують десятиліттями. Анонімні протоколи електронних грошей 1980-х і 1990-х років, які в основному покладалися на криптографічний примітив, відомий як засліплення за Чаумом, забезпечували валюту з високим ступенем конфіденційності, але протоколи в основному не змогли набути популярності через свою залежність від централізованого посередника. У 1998 році b-moneyopens in a new tab Вея Дая стала першою пропозицією, яка ввела ідею створення грошей шляхом розв’язання обчислювальних головоломок, а також децентралізованого консенсусу, але в пропозиції було замало деталей щодо того, як децентралізований консенсус може бути реалізований на практиці. У 2005 році Гел Фінні представив концепцію «доказів виконаної роботи багаторазового використанняopens in a new tab» — систему, яка використовує ідеї з b-money разом із обчислювально складними головоломками Hashcash Адама Бека для створення концепції криптовалюти, але знову ж таки не досягла ідеалу, покладаючись на довірені обчислення як на бекенд. У 2009 році Сатоші Накамото вперше на практиці реалізував децентралізовану валюту, поєднавши вже існуючі примітиви для керування власністю за допомогою криптографії з відкритим ключем з алгоритмом консенсусу для відстеження того, хто володіє монетами, відомим як "доказ виконання роботи".

Механізм доказу виконання роботи став проривом у цій галузі, оскільки він одночасно вирішив дві проблеми. По-перше, він надав простий і помірно ефективний алгоритм консенсусу, що дозволяє вузлам у мережі колективно узгоджувати набір канонічних оновлень стану реєстру Bitcoin. По-друге, він надав механізм для вільного входу в процес консенсусу, вирішивши політичну проблему вирішення того, хто може впливати на консенсус, і одночасно запобігаючи атакам Сивілли. Це робиться шляхом заміни формального бар'єру для участі, такого як вимога бути зареєстрованим як унікальна сутність у певному списку, економічним бар'єром - вага одного вузла в процесі голосування консенсусу прямо пропорційна обчислювальній потужності, яку вузол надає. Відтоді був запропонований альтернативний підхід під назвою доказ частки володіння, який обчислює вагу вузла пропорційно його валютним активам, а не обчислювальним ресурсам; обговорення відносних переваг цих двох підходів виходить за рамки цього документа, але слід зазначити, що обидва підходи можуть слугувати основою для криптовалюти.

Bitcoin як система переходу стану

З технічної точки зору, реєстр криптовалюти, такої як Bitcoin, можна розглядати як систему переходу стану, де є «стан», що складається зі статусу власності всіх існуючих біткоїнів, і «функція переходу стану», яка приймає стан і транзакцію та видає новий стан, що є результатом. У стандартній банківській системі, наприклад, стан — це балансовий звіт, транзакція — це запит на переміщення $X з A до B, а функція переходу стану зменшує вартість на рахунку A на $X і збільшує вартість на рахунку B на $X. Якщо на рахунку A спочатку менше $X, функція переходу стану повертає помилку. Отже, формально можна визначити:

ЗАСТОСУВАТИ(S,TX) -> S' або ПОМИЛКА

У банківській системі, яка визначена вище:

APPLY({ Alice: $50, Bob: $50 },"надіслати 20 $ від Еліс Бобу") = { Alice: $30, Bob: $70 }

Але:

APPLY({ Alice: $50, Bob: $50 },"надіслати 70 $ від Еліс Бобу") = ERROR

«Стан» у біткойні — це сукупність усіх монет (технічно, «невитрачених результатів транзакцій» або UTXO), які були викарбувані та ще не витрачені, причому кожен UTXO має номінал та власника (визначається 20-байтовою адресою, яка по суті є криптографічним відкритим ключем^fn1). Транзакція містить один або кілька входів, причому кожен вхід містить посилання на існуючий UTXO та криптографічний підпис, створений приватним ключем, пов’язаним з адресою власника, та один або кілька виходів, причому кожен вихід містить новий UTXO, який потрібно додати до стану.

Функцію переходу стану APPLY(S,TX) -> S' можна визначити приблизно так:

1. Для кожного входу в TX:

   • Якщо UTXO, на який є посилання, відсутній у S, повернути помилку.
   • Якщо наданий підпис не збігається з власником UTXO, повернути помилку.
2. Якщо сума номіналів усіх вхідних UTXO менша за суму номіналів усіх вихідних UTXO, повернути помилку.
3. Повернути S з усіма видаленими вхідними UTXO та доданими всіма вихідними UTXO.

Перша половина першого кроку не дозволяє відправникам транзакцій витрачати монети, яких не існує, друга половина першого кроку не дозволяє відправникам транзакцій витрачати чужі монети, а другий крок забезпечує збереження вартості. Щоб використовувати це для оплати, протокол виглядає наступним чином. Припустимо, Аліса хоче надіслати 11,7 BTC Бобу. Спочатку Аліса шукатиме набір доступних UTXO, якими вона володіє, на загальну суму не менше 11,7 BTC. Реалістично Аліса не зможе отримати рівно 11,7 BTC; скажімо, найменше, що вона може отримати, це 6+4+2=12. Потім вона створює транзакцію з цими трьома входами та двома виходами. Перший вихід становитиме 11,7 BTC з адресою Боба як власника, а другий вихід — решта 0,3 BTC «решти», власником якої буде сама Аліса.

Майнінг

Якби ми мали доступ до надійної централізованої служби, цю систему було б тривіально реалізувати; її можна було б просто закодувати точно так, як описано, використовуючи жорсткий диск централізованого сервера для відстеження стану. Однак з Bitcoin ми намагаємося побудувати децентралізовану валютну систему, тому нам потрібно буде поєднати систему переходу стану з системою консенсусу, щоб забезпечити згоду всіх щодо порядку транзакцій. Процес децентралізованого консенсусу Bitcoin вимагає від вузлів у мережі постійно намагатися створювати пакети транзакцій, що називаються «блоками». Мережа призначена для створення приблизно одного блоку кожні десять хвилин, причому кожен блок містить позначку часу, nonce, посилання на (тобто хеш) попередній блок та список усіх транзакцій, що відбулися з моменту попереднього блоку. З часом це створює постійний, постійно зростаючий «блокчейн», який постійно оновлюється, щоб відображати останній стан реєстру Bitcoin.

Алгоритм перевірки дійсності блоку, виражений у цій парадигмі, виглядає наступним чином:

1. Перевірте, чи існує та є дійсним попередній блок, на який посилається даний блок.
2. Переконайтеся, що мітка часу блоку більша, ніж у попереднього блоку^fn2 і менше ніж через 2 години в майбутньому
3. Перевірте, що доказ виконання роботи для блоку є дійсним.
4. Нехай S[0] буде станом на кінець попереднього блоку.
5. Припустимо, TX — це список транзакцій блоку з n транзакціями. Для всіх i в 0...n-1 встановіть S[i+1] = APPLY(S[i],TX[i]). Якщо будь-яке застосування повертає помилку, вийдіть і поверніть false.
6. Повернути true і зареєструвати S[n] як стан на кінець цього блоку.

По суті, кожна транзакція в блоці повинна забезпечувати дійсний перехід стану від канонічного стану до виконання транзакції до якогось нового стану. Зауважте, що стан ніяк не закодований у блоці; це суто абстракція, яку повинен пам’ятати вузол перевірки, і її можна (безпечно) обчислити для будь-якого блоку, починаючи зі стану генезису та послідовно застосовуючи кожну транзакцію в кожному блоці. Крім того, зауважте, що порядок, у якому майнер включає транзакції в блок, має значення; якщо в блоці є дві транзакції A і B, такі що B витрачає UTXO, створений A, то блок буде дійсним, якщо A йде перед B, але не навпаки.

Єдина умова дійсності, наведена у списку вище, яка не зустрічається в інших системах, — це вимога «доказу виконання роботи». Точна умова полягає в тому, що подвійний хеш SHA256 кожного блоку, що розглядається як 256-бітове число, повинен бути меншим за динамічно регульовану ціль, яка на момент написання цього тексту становить приблизно 2¹⁸⁷. Мета цього — зробити створення блоків обчислювально «складним», тим самим запобігаючи атакам Сивілли з метою переписати весь блокчейн на свою користь. Оскільки SHA256 розроблено як абсолютно непередбачувану псевдовипадкову функцію, єдиний спосіб створити дійсний блок — це метод спроб і помилок, багаторазово збільшуючи nonce і перевіряючи, чи збігається новий хеш.

При поточному цільовому значенні ~2¹⁸⁷ мережа повинна зробити в середньому ~2⁶⁹ спроб, перш ніж буде знайдено дійсний блок; загалом, цільове значення перекалібровується мережею кожні 2016 блоків, щоб у середньому новий блок створювався якимось вузлом у мережі кожні десять хвилин. Щоб компенсувати майнерам цю обчислювальну роботу, майнер кожного блоку має право включити транзакцію, що надає йому 25 BTC з нізвідки. Крім того, якщо будь-яка транзакція має більший загальний номінал у своїх входах, ніж у виходах, різниця також йде майнеру як «комісія за транзакцію». До речі, це також єдиний механізм випуску BTC; у генезисному стані монет взагалі не було.

Щоб краще зрозуміти мету майнінгу, розгляньмо, що відбувається у випадку зловмисної атаки. Оскільки базова криптографія Bitcoin відома своєю безпекою, зловмисник буде націлюватися на ту частину системи Bitcoin, яка не захищена криптографією безпосередньо: порядок транзакцій. Стратегія нападника проста:

1. Надіслати 100 BTC продавцю в обмін на якийсь товар (бажано цифровий товар зі швидкою доставкою)
2. Зачекати, поки продукт не буде доставлено
3. Зробити іншу транзакцію, надіславши ті самі 100 BTC собі
4. Спробувати переконати мережу, що його транзакція самому собі була першою.

Після того, як крок (1) відбудеться, через кілька хвилин якийсь майнер включить транзакцію в блок, скажімо, блок номер 270000. Приблизно через годину до ланцюжка буде додано ще п’ять блоків після цього блоку, причому кожен з цих блоків опосередковано вказуватиме на транзакцію і таким чином «підтверджуватиме» її. У цей момент продавець прийме платіж як остаточний і доставить товар; оскільки ми припускаємо, що це цифровий товар, доставка миттєва. Тепер зловмисник створює іншу транзакцію, надсилаючи собі 100 BTC. Якщо зловмисник просто випустить її в мережу, транзакція не буде оброблена; майнери спробують запустити APPLY(S,TX) і помітять, що TX споживає UTXO, якого більше немає в стані. Тому натомість зловмисник створює «форк» блокчейну, починаючи з майнінгу іншої версії блоку 270000, що вказує на той самий блок 269999 як батьківський, але з новою транзакцією замість старої. Оскільки дані блоку відрізняються, це вимагає повторного доказу виконання роботи. Крім того, нова версія блоку 270000 зловмисника має інший хеш, тому оригінальні блоки з 270001 по 270005 не «вказують» на нього; таким чином, оригінальний ланцюжок і новий ланцюжок зловмисника повністю розділені. Правило полягає в тому, що у форку найдовший блокчейн вважається істинним, і тому легітимні майнери працюватимуть над ланцюжком 270005, тоді як зловмисник один працює над ланцюжком 270000. Щоб зловмисник зробив свій блокчейн найдовшим, йому знадобиться більше обчислювальної потужності, ніж у решти мережі разом узятої, щоб наздогнати (звідси й «атака 51%»).

Дерева Меркла

Ліворуч: достатньо представити лише невелику кількість вузлів у дереві Меркла, щоб надати доказ дійсності гілки.

Праворуч: будь-яка спроба змінити будь-яку частину дерева Меркла зрештою призведе до невідповідності десь вище в ланцюжку.

Важливою особливістю масштабованості Bitcoin є те, що блок зберігається в багаторівневій структурі даних. «Хеш» блоку насправді є лише хешем заголовка блоку, приблизно 200-байтового фрагмента даних, що містить позначку часу, nonce, хеш попереднього блоку та кореневий хеш структури даних, яка називається деревом Меркла і зберігає всі транзакції в блоці. Дерево Меркла — це тип бінарного дерева, що складається з набору вузлів з великою кількістю листових вузлів у нижній частині дерева, що містять базові дані, набору проміжних вузлів, де кожен вузол є хешем двох своїх дочірніх елементів, і, нарешті, одного кореневого вузла, який також утворений з хешу двох його дочірніх елементів, що представляє «вершину» дерева. Мета дерева Меркла полягає в тому, щоб дозволити доставку даних у блоці частинами: вузол може завантажити лише заголовок блоку з одного джерела, невелику частину дерева, що стосується його, з іншого джерела, і все одно бути впевненим, що всі дані правильні. Причина, чому це працює, полягає в тому, що хеші поширюються вгору: якщо зловмисник спробує підмінити фальшиву транзакцію внизу дерева Меркла, ця зміна спричинить зміну у вузлі вище, а потім зміну у вузлі ще вище, що в кінцевому підсумку змінить корінь дерева і, отже, хеш блоку, змушуючи протокол зареєструвати його як абсолютно інший блок (майже напевно з недійсним доказом виконання роботи).

Протокол дерева Меркла, можливо, є важливим для довгострокової стійкості. «Повний вузол» у мережі Bitcoin, який зберігає та обробляє всі дані кожного блоку, займає близько 15 ГБ дискового простору в мережі Bitcoin станом на квітень 2014 року і зростає більш ніж на гігабайт на місяць. Наразі це можливо для деяких настільних комп'ютерів, але не для телефонів, а в майбутньому брати участь зможуть лише підприємства та ентузіасти. Протокол, відомий як «спрощена перевірка платежів» (SPV), дозволяє існувати іншому класу вузлів, які називаються «легкими вузлами», що завантажують заголовки блоків, перевіряють доказ виконання роботи на заголовках блоків, а потім завантажують лише «гілки», пов'язані з транзакціями, які для них релевантні. Це дозволяє легким вузлам визначати з високою гарантією безпеки статус будь-якої транзакції Bitcoin та їхній поточний баланс, завантажуючи лише дуже малу частину всього блокчейну.

Альтернативні застосування блокчейну

Ідея взяти за основу ідею блокчейну та застосувати її до інших концепцій також має довгу історію. У 2005 році Нік Сабо висунув концепцію «захищених прав власності з повноваженнями власникаopens in a new tab», документ, що описує, як «нові досягнення в технології реплікованих баз даних» дозволять створити систему на основі блокчейну для зберігання реєстру того, хто володіє якою землею, створюючи складну структуру, що включає такі концепції, як гомстединг, набувальна давність та грузинський земельний податок. Однак, на жаль, на той час не було ефективної реплікованої системи баз даних, тому протокол ніколи не був реалізований на практиці. Проте після 2009 року, коли було розроблено децентралізований консенсус Bitcoin, швидко почали з’являтися численні альтернативні застосування.

• Namecoin - створений у 2010 році, Namecoinopens in a new tab найкраще описується як децентралізована база даних для реєстрації імен. У децентралізованих протоколах, таких як Tor, Bitcoin і BitMessage, повинен бути якийсь спосіб ідентифікації акаунтів, щоб інші люди могли взаємодіяти з ними, але в усіх існуючих рішеннях єдиним доступним ідентифікатором є псевдовипадковий хеш, наприклад 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. В ідеалі, хотілося б мати акаунт з іменем на кшталт «george». Однак проблема в тому, що якщо одна людина може створити акаунт з ім’ям «george», то хтось інший може використати той самий процес, щоб зареєструвати «george» для себе і видавати себе за неї. Єдиним рішенням є парадигма «хто перший подав», де перший реєстратор успішний, а другий зазнає невдачі — проблема, ідеально пристосована для протоколу консенсусу Bitcoin. Namecoin є найстарішою та найуспішнішою реалізацією системи реєстрації імен, що використовує таку ідею.
• Кольорові монети - мета кольорових монетopens in a new tab — слугувати протоколом, що дозволяє людям створювати власні цифрові валюти — або, у важливому тривіальному випадку валюти з однією одиницею, цифрові токени на блокчейні Bitcoin. У протоколі кольорових монет «випускають» нову валюту, публічно присвоюючи колір певному UTXO Bitcoin, і протокол рекурсивно визначає колір інших UTXO як такий самий, як колір входів, які витратила транзакція, що їх створила (деякі спеціальні правила застосовуються у випадку входів змішаного кольору). Це дозволяє користувачам підтримувати гаманці, що містять лише UTXO певного кольору, і надсилати їх так само, як звичайні біткоїни, відстежуючи блокчейн для визначення кольору будь-якого отриманого UTXO.
• Метакоїни — ідея метакоїна полягає в тому, щоб мати протокол, який живе поверх Bitcoin, використовуючи транзакції Bitcoin для зберігання транзакцій метакоїнів, але маючи іншу функцію переходу стану, APPLY'. Оскільки протокол метакоїнів не може запобігти появі недійсних транзакцій метакоїнів у блокчейні Bitcoin, додається правило, що якщо APPLY'(S,TX) повертає помилку, протокол за замовчуванням встановлює APPLY'(S,TX) = S. Це забезпечує простий механізм для створення довільного протоколу криптовалюти, потенційно з розширеними функціями, які не можуть бути реалізовані всередині самого Bitcoin, але з дуже низькими витратами на розробку, оскільки складнощі майнінгу та мережевої взаємодії вже вирішені протоколом Bitcoin. Метакоїни використовувалися для реалізації деяких класів фінансових контрактів, реєстрації імен та децентралізованого обміну.

Таким чином, загалом існує два підходи до побудови протоколу консенсусу: побудова незалежної мережі та побудова протоколу поверх Bitcoin. Перший підхід, хоча й досить успішний у випадку таких застосувань, як Namecoin, важко реалізувати; кожна окрема реалізація потребує завантаження незалежного блокчейну, а також створення та тестування всього необхідного коду для переходу стану та мережевої взаємодії. Крім того, ми прогнозуємо, що набір застосунків для технології децентралізованого консенсусу буде слідувати степеневому закону розподілу, де переважна більшість застосунків буде занадто малою, щоб виправдати власний блокчейн, і ми зауважуємо, що існують великі класи децентралізованих застосунків, зокрема децентралізовані автономні організації, які потребують взаємодії між собою.

Підхід, заснований на Bitcoin, з іншого боку, має недолік, що він не успадковує функції спрощеної перевірки платежів Bitcoin. SPV працює для Bitcoin, оскільки він може використовувати глибину блокчейну як проксі для дійсності; у певний момент, коли предки транзакції йдуть досить далеко назад, можна з упевненістю сказати, що вони були законною частиною стану. Мета-протоколи на основі блокчейну, з іншого боку, не можуть змусити блокчейн не включати транзакції, які не є дійсними в контексті їхніх власних протоколів. Отже, повністю безпечна реалізація метапротоколу SPV вимагала б зворотного сканування аж до самого початку блокчейну Bitcoin, щоб визначити, чи є певні транзакції дійсними. Наразі всі «легкі» реалізації метапротоколів на основі Bitcoin покладаються на довірений сервер для надання даних, що, можливо, є вкрай неоптимальним результатом, особливо коли однією з основних цілей криптовалюти є усунення потреби в довірі.

Скрипти

Навіть без будь-яких розширень, протокол Bitcoin фактично полегшує слабку версію концепції «смарт-контрактів». UTXO в Bitcoin може належати не лише відкритому ключу, але й більш складному скрипту, вираженому простою мовою програмування на основі стека. У цій парадигмі транзакція, що витрачає цей UTXO, повинна надавати дані, які задовольняють скрипт. Дійсно, навіть базовий механізм володіння відкритим ключем реалізовано за допомогою скрипта: скрипт приймає підпис еліптичної кривої як вхідні дані, перевіряє його відносно транзакції та адреси, яка володіє UTXO, і повертає 1, якщо перевірка успішна, і 0 в іншому випадку. Існують інші, більш складні скрипти для різних додаткових випадків використання. Наприклад, можна створити скрипт, який вимагає підписів від двох із трьох заданих приватних ключів для валідації («мультипідпис»), налаштування, корисне для корпоративних акаунтів, захищених ощадних рахунків та деяких ситуацій з ескроу-рахунками продавців. Скрипти також можуть використовуватися для виплати винагород за розв’язання обчислювальних завдань, і можна навіть створити скрипт, який говорить щось на кшталт «цей Bitcoin UTXO ваш, якщо ви можете надати доказ SPV, що ви надіслали мені транзакцію Dogecoin цього номіналу», що по суті дозволяє децентралізований обмін між криптовалютами.

Однак мова сценаріїв, реалізована в Bitcoin, має кілька важливих обмежень:

• Відсутність повноти за Тюрінгом — тобто, хоча існує велика підмножина обчислень, яку підтримує мова сценаріїв Bitcoin, вона далеко не підтримує все. Основна категорія, якої бракує, — це цикли. Це робиться для уникнення нескінченних циклів під час верифікації транзакцій; теоретично це переборна перешкода для програмістів скриптів, оскільки будь-який цикл можна симулювати, просто повторюючи базовий код багато разів з оператором if, але це призводить до дуже неефективних з точки зору простору скриптів. Наприклад, реалізація альтернативного алгоритму підпису еліптичної кривої, ймовірно, вимагатиме 256 повторюваних раундів множення, кожен з яких буде окремо включений до коду.
• Сліпота до вартості — скрипт UTXO не може забезпечити детальний контроль над сумою, яку можна вивести. Наприклад, один потужний випадок використання контракту оракула — це хеджувальний контракт, де A і B вкладають BTC на суму 1000 доларів, і через 30 днів скрипт надсилає BTC на суму 1000 доларів A, а решту — B. Це вимагало б від оракула визначення вартості 1 BTC в доларах США, але навіть тоді це значне покращення з точки зору довіри та вимог до інфраструктури порівняно з повністю централізованими рішеннями, які доступні зараз. Однак, оскільки UTXO є «все або нічого», єдиний спосіб досягти цього — це дуже неефективний трюк з наявністю багатьох UTXO різних номіналів (наприклад, один UTXO 2^k для кожного k до 30) і дорученням оракулу вибору, які UTXO надіслати А, а які — В.
• Відсутність стану — UTXO може бути або витраченим, або невитраченим; немає можливості для багатоетапних контрактів або скриптів, які зберігають будь-який інший внутрішній стан поза цим. Це ускладнює створення багатоетапних опціонних контрактів, пропозицій децентралізованого обміну або двоетапних протоколів криптографічних зобов’язань (необхідних для безпечних обчислювальних винагород). Це також означає, що UTXO можна використовувати лише для створення простих, одноразових контрактів, а не більш складних «зберігаючих стан» контрактів, таких як децентралізовані організації, і ускладнює реалізацію метапротоколів. Бінарний стан у поєднанні зі сліпотою до вартості також означає, що інше важливе застосування, обмеження на зняття коштів, є неможливим.
• Сліпота до блокчейну — UTXO сліпі до даних блокчейну, таких як nonce, позначка часу та хеш попереднього блоку. Це суттєво обмежує застосування в азартних іграх та кількох інших категоріях, позбавляючи мову скриптів потенційно цінного джерела випадковості.

Таким чином, ми бачимо три підходи до створення передових застосунків на основі криптовалюти: створення нового блокчейну, використання скриптів на основі Bitcoin і створення метапротоколу на основі Bitcoin. Створення нового блокчейну дозволяє необмежену свободу у створенні набору функцій, але за рахунок часу на розробку, зусиль на початкове завантаження та безпеки. Використання скриптів легко реалізувати та стандартизувати, але воно дуже обмежене у своїх можливостях, а метапротоколи, хоч і прості, страждають від недоліків у масштабованості. З Ethereum ми маємо намір створити альтернативну структуру, яка забезпечує ще більші переваги у простоті розробки, а також ще сильніші властивості легких клієнтів, водночас дозволяючи застосункам спільно використовувати економічне середовище та безпеку блокчейну.

Ethereum

Мета Ethereum — створити альтернативний протокол для створення децентралізованих застосунків, надаючи інший набір компромісів, які, на нашу думку, будуть дуже корисними для великого класу децентралізованих застосунків, з особливим акцентом на ситуаціях, де важливі швидкий час розробки, безпека для невеликих і рідко використовуваних застосунків, а також здатність різних застосунків дуже ефективно взаємодіяти. Ethereum досягає цього, створюючи по суті остаточний абстрактний фундаментальний шар: блокчейн із вбудованою повною за Тюрінгом мовою програмування, що дозволяє будь-кому писати смарт-контракти та децентралізовані застосунки, де вони можуть створювати власні довільні правила власності, формати транзакцій та функції переходу стану. Спрощену версію Namecoin можна написати у двох рядках коду, а інші протоколи, такі як валюти та системи репутації, можна створити менш ніж за двадцять. Смарт-контракти, криптографічні «скриньки», що містять цінність і розблоковують її лише за виконання певних умов, також можуть бути створені на платформі з набагато більшою потужністю, ніж та, що пропонується скриптами Bitcoin, завдяки додатковим можливостям повноти за Тюрінгом, усвідомлення вартості, усвідомлення блокчейну та стану.

Акаунти Ethereum

У Ethereum стан складається з об'єктів, що називаються «акаунтами», кожен акаунт має 20-байтову адресу, а переходи стану є прямими передачами вартості та інформації між акаунтами. Акаунт Ethereum містить чотири поля:

• Nonce — лічильник, який використовується для того, щоб кожна транзакція могла бути оброблена лише один раз
• Поточний баланс ether акаунта
• Код контракту акаунта, якщо він є
• Сховище акаунта (порожнє за замовчуванням)

«Ether» — це основне внутрішнє криптопаливо Ethereum, яке використовується для сплати комісій за транзакції. Загалом, існує два типи акаунтів: зовнішні керовані акаунти, що контролюються приватними ключами, та контрактні акаунти, що контролюються їхнім контрактним кодом. Зовнішній керований акаунт не має коду, і можна надсилати повідомлення з зовнішнього керованого акаунта, створюючи та підписуючи транзакцію; у контрактному акаунті щоразу, коли він отримує повідомлення, його код активується, дозволяючи йому читати та писати у внутрішнє сховище, а також надсилати інші повідомлення або створювати контракти.

Зауважте, що «контракти» в Ethereum не слід розглядати як щось, що має бути «виконано» або «дотримано»; скоріше, вони більше схожі на «автономних агентів», що живуть у середовищі виконання Ethereum, завжди виконуючи певний фрагмент коду, коли їх «штовхає» повідомлення або транзакція, і мають прямий контроль над власним балансом ether і власним сховищем ключ/значення для відстеження постійних змінних.

Повідомлення та транзакції

Термін «транзакція» використовується в Ethereum для позначення підписаного пакета даних, що зберігає повідомлення, яке надсилається з зовнішнього акаунта. Транзакції містять такі дані:

• Отримувач повідомлення
• Підпис, що ідентифікує відправника
• Сума в ether для переказу від відправника отримувачу
• Необов’язкове поле даних
• Значення STARTGAS, що представляє максимальну кількість обчислювальних кроків, які може виконати транзакція
• Значення GASPRICE, що представляє комісію, яку відправник сплачує за обчислювальний крок

Перші три — це стандартні поля, характерні для будь-якої криптовалюти. Поле даних за замовчуванням не має функції, але віртуальна машина має опкод, за допомогою якого контракт може отримати доступ до даних; як приклад використання, якщо контракт функціонує як служба реєстрації доменів на блокчейні, він може інтерпретувати дані, що передаються йому, як такі, що містять два «поля», перше поле — це домен для реєстрації, а друге — IP-адреса, на яку його потрібно зареєструвати. Контракт зчитував би ці значення з даних повідомлення і належним чином розміщував їх у сховищі.

Поля STARTGAS і GASPRICE є критично важливими для моделі захисту від відмови в обслуговуванні Ethereum. Щоб запобігти випадковим або ворожим нескінченним циклам, чи іншим обчислювальним втратам у коді, кожна транзакція повинна встановлювати обмеження на кількість обчислювальних кроків виконання коду, які вона може використовувати. Основною одиницею обчислення є «газ»; зазвичай обчислювальний крок коштує 1 газ, але деякі операції коштують більше газу, оскільки вони більш обчислювально затратні або збільшують кількість даних, які повинні зберігатися як частина стану. За кожен байт даних транзакції також стягується плата в 5 газ. Мета системи комісій — вимагати від зловмисника пропорційної оплати за кожен спожитий ресурс, включаючи обчислення, пропускну здатність і зберігання; отже, будь-яка транзакція, яка призводить до споживання мережею більшої кількості будь-якого з цих ресурсів, повинна мати плату за газ, приблизно пропорційну приросту.

Повідомлення

Контракти мають можливість надсилати «повідомлення» іншим контрактам. Повідомлення є віртуальними об’єктами, які ніколи не серіалізуються та існують лише в середовищі виконання Ethereum. Повідомлення містить такі дані:

• Відправник повідомлення (неявний)
• Отримувач повідомлення
• Сума в ether для переказу разом із повідомленням
• Необов’язкове поле даних
• Значення STARTGAS

По суті, повідомлення — це як транзакція, за винятком того, що воно створюється контрактом, а не зовнішнім актором. Повідомлення створюється, коли контракт, що виконує код, виконує опкод CALL, який створює та виконує повідомлення. Як і транзакція, повідомлення призводить до того, що акаунт одержувача запускає свій код. Таким чином, контракти можуть мати стосунки з іншими контрактами точно так само, як і зовнішні актори.

Зауважте, що ліміт газу, призначений транзакцією або контрактом, застосовується до загального газу, спожитого цією транзакцією та всіма під-виконаннями. Наприклад, якщо зовнішній актор A надсилає транзакцію до B з 1000 газу, і B споживає 600 газу перед надсиланням повідомлення до C, а внутрішнє виконання C споживає 300 газу перед поверненням, то B може витратити ще 100 газу, перш ніж газ закінчиться.

Функція переходу стану Ethereum

Функцію переходу стану Ethereum, APPLY(S,TX) -> S', можна визначити наступним чином:

1. Перевірте, чи правильно сформована транзакція (тобто має правильну кількість значень), чи дійсний підпис, і чи nonce відповідає nonce в акаунті відправника. Якщо ні, завершується помилкою.
2. Обчисліть комісію за транзакцію як STARTGAS * GASPRICE та визначте адресу відправлення за підписом. Відніміть комісію з балансу акаунта відправника та збільште nonce відправника. Якщо балансу недостатньо для витрачання коштів, завершується помилкою.
3. Ініціалізуйте GAS = STARTGAS і зніміть певну кількість газу за байт для оплати байтів у транзакції.
4. Перекажіть вартість транзакції з акаунта відправника на акаунт одержувача. Якщо акаунт одержувача ще не існує, створіть його. Якщо акаунт одержувача є контрактом, запустіть код контракту до завершення або доки виконання не вичерпає газ.
5. Якщо переказ вартості не вдався, оскільки у відправника не було достатньо грошей, або виконання коду вичерпало газ, скасуйте всі зміни стану, крім сплати комісій, і додайте комісії на акаунт майнера.
6. В іншому випадку поверніть комісію за весь залишковий газ відправнику та надішліть сплачену за спожитий газ комісію майнеру.

Наприклад, припустимо, що код контракту такий:

if !self.storage[calldataload(0)]:
  self.storage[calldataload(0)] = calldataload(32)

Зауважте, що в реальності код контракту пишеться низькорівневим кодом EVM; цей приклад написаний на Serpent, одній з наших високорівневих мов, для ясності, і може бути скомпільований у код EVM. Припустимо, що сховище контракту спочатку порожнє, і надсилається транзакція з вартістю 10 ether, 2000 газу, ціною газу 0.001 ether і 64 байтами даних, де байти 0-31 представляють число 2, а байти 32-63 представляють рядок CHARLIE. Процес для функції переходу стану в цьому випадку виглядає наступним чином:

1. Перевірте, чи є транзакція дійсною та добре сформованою.
2. Перевірте, чи має відправник транзакції щонайменше 2000 * 0.001 = 2 ether. Якщо так, відніміть 2 ether з облікового запису відправника.
3. Ініціалізуйте газ = 2000; припускаючи, що транзакція має довжину 170 байтів, а комісія за байт становить 5, відніміть 850, щоб залишилося 1150 газу.
4. Відніміть ще 10 ether з акаунта відправника та додайте їх на акаунт контракту.
5. Запустіть код. У цьому випадку все просто: він перевіряє, чи використовується сховище контракту за індексом 2, помічає, що ні, і тому встановлює сховище за індексом 2 у значення CHARLIE. Припустимо, це займає 187 газу, тому залишок газу становить 1150 - 187 = 963
6. Додайте 963 * 0.001 = 0.963 ether назад на акаунт відправника та поверніть отриманий стан.

Якщо на приймаючій стороні транзакції не було контракту, то загальна комісія за транзакцію просто дорівнювала б наданому GASPRICE, помноженому на довжину транзакції в байтах, а дані, надіслані разом з транзакцією, були б нерелевантними.

Зауважте, що повідомлення працюють еквівалентно транзакціям з точки зору скасування: якщо виконання повідомлення вичерпує газ, то виконання цього повідомлення та всі інші виконання, викликані цим виконанням, скасовуються, але батьківські виконання не потребують скасування. Це означає, що для контракту «безпечно» викликати інший контракт, оскільки якщо A викликає B з G газу, то виконання A гарантовано втратить щонайбільше G газу. Нарешті, зауважте, що існує опкод CREATE, який створює контракт; його механіка виконання загалом схожа на CALL, за винятком того, що результат виконання визначає код новоствореного контракту.

Виконання коду

Код у контрактах Ethereum пишеться низькорівневою байт-кодовою мовою на основі стека, що називається «кодом віртуальної машини Ethereum» або «кодом EVM». Код складається з послідовності байтів, де кожен байт представляє операцію. Загалом, виконання коду — це нескінченний цикл, що полягає в повторному виконанні операції за поточним лічильником команд (який починається з нуля), а потім збільшенні лічильника команд на одиницю, доки не буде досягнуто кінця коду або не буде виявлено помилку чи інструкцію STOP або RETURN. Операції мають доступ до трьох типів простору для зберігання даних:

• Стек — контейнер «останнім увійшов — першим вийшов», до якого можна додавати та вилучати значення
• Пам'ять — нескінченно розширюваний байтовий масив
• Довготривале сховище контракту — сховище ключ/значення. На відміну від стека та пам'яті, які скидаються після завершення обчислень, сховище зберігається надовго.

Код також може отримувати доступ до вартості, відправника та даних вхідного повідомлення, а також до даних заголовка блоку, і код також може повертати байтовий масив даних як вихід.

Офіційна модель виконання коду EVM дуже проста. Під час роботи віртуальної машини Ethereum її повний обчислювальний стан можна визначити кортежем (block_state, transaction, message, code, memory, stack, pc, gas), де block_state — це глобальний стан, що містить усі акаунти, включаючи баланси та сховище. На початку кожного раунду виконання поточна інструкція знаходиться шляхом взяття pc-го байта коду (або 0, якщо pc >= len(code)), і кожна інструкція має власне визначення з точки зору того, як вона впливає на кортеж. Наприклад, ADD витягує два елементи зі стека і поміщає туди їхню суму, зменшує gas на 1 і збільшує pc на 1, а SSTORE витягує два верхні елементи зі стека і вставляє другий елемент у сховище контракту за індексом, вказаним першим елементом. Хоча існує багато способів оптимізувати виконання віртуальної машини Ethereum за допомогою JIT-компіляції, базову реалізацію Ethereum можна виконати в кількох сотнях рядків коду.

Блокчейн і майнінг

Блокчейн Ethereum багато в чому схожий на блокчейн Bitcoin, хоча й має деякі відмінності. Основна відмінність між Ethereum і Bitcoin щодо архітектури блокчейну полягає в тому, що, на відміну від Bitcoin, блоки Ethereum містять копію як списку транзакцій, так і найновішого стану. Крім того, у блоці зберігаються ще два значення: номер блоку та складність. Базовий алгоритм валідації блоку в Ethereum виглядає наступним чином:

1. Перевірте, чи існує попередній блок, на який є посилання, і чи дійсний він.
2. Перевірте, що позначка часу блоку більша, ніж у попереднього блоку, на який є посилання, і менша ніж 15 хвилин у майбутньому
3. Перевірте, що номер блоку, складність, корінь транзакцій, корінь «дядьків» та ліміт газу (різні низькорівневі специфічні для Ethereum концепції) є дійсними.
4. Перевірте, що доказ виконання роботи для блоку є дійсним.
5. Нехай S[0] буде станом на кінець попереднього блоку.
6. Нехай TX буде списком транзакцій блоку з n транзакціями. Для всіх i в 0...n-1 встановіть S[i+1] = APPLY(S[i],TX[i]). Якщо будь-яке застосування повертає помилку, або якщо загальний спожитий газ у блоці до цього моменту перевищує GASLIMIT, повернути помилку.
7. Нехай S_FINAL буде S[n], але з додаванням винагороди за блок, сплаченої майнеру.
8. Перевірте, чи корінь дерева Меркла стану S_FINAL дорівнює кінцевому кореневому стану, наданому в заголовку блоку. Якщо так, блок є дійсним; інакше, він не є дійсним.

На перший погляд, підхід може здатися вкрай неефективним, оскільки потрібно зберігати весь стан з кожним блоком, але в реальності ефективність повинна бути порівнянною з ефективністю Bitcoin. Причина в тому, що стан зберігається в структурі дерева, і після кожного блоку потрібно змінити лише невелику частину дерева. Таким чином, загалом між двома суміжними блоками переважна більшість дерева має бути однаковою, і тому дані можна зберігати один раз і посилатися на них двічі за допомогою покажчиків (тобто хешів піддерев). Для цього використовується спеціальний вид дерева, відомий як «дерево Патриції», що включає модифікацію концепції дерева Меркла, яка дозволяє ефективно вставляти та видаляти вузли, а не просто змінювати їх. Крім того, оскільки вся інформація про стан є частиною останнього блоку, немає потреби зберігати всю історію блокчейну — стратегія, яка, якби її можна було застосувати до Bitcoin, за розрахунками, забезпечила б економію простору в 5-20 разів.

Часто ставлять питання, «де» виконується код контракту з точки зору фізичного обладнання. Відповідь проста: процес виконання коду контракту є частиною визначення функції переходу стану, яка є частиною алгоритму валідації блоку, тому якщо транзакція додається до блоку B, виконання коду, ініційоване цією транзакцією, буде виконано всіма вузлами, зараз і в майбутньому, які завантажують і валідують блок B.

Застосунки

Загалом є три види застосування на базі технології Ethereum. Перша категорія — це фінансові застосунки, що надають користувачам більш потужні способи управління та укладення контрактів за допомогою їхніх грошей. Це включає суб-валюти, фінансові деривативи, хеджувальні контракти, ощадні гаманці, заповіти і, зрештою, навіть деякі класи повномасштабних трудових договорів. Друга категорія — напівфінансові застосунки, де задіяні гроші, але є й значна негрошова складова того, що робиться; ідеальним прикладом є самовиконувані винагороди за розв’язання обчислювальних завдань. Нарешті, існують застосунки, такі як онлайн-голосування та децентралізоване управління, які взагалі не є фінансовими.

Системи токенів

Системи токенів на блокчейні мають багато застосувань, від субвалют, що представляють активи, такі як долар США або золото, до акцій компаній, індивідуальних токенів, що представляють розумну власність, захищених непідробних купонів, і навіть систем токенів, що не мають жодного зв'язку зі звичайною вартістю, які використовуються як системи балів для стимулювання. Системи токенів на диво легко реалізувати в Ethereum. Ключовий момент, який потрібно зрозуміти, полягає в тому, що будь-яка валюта, або система токенів, по суті, є базою даних з однією операцією: відняти X одиниць від A і дати X одиниць B, за умови, що (i) A мав щонайменше X одиниць до транзакції та (2) транзакція схвалена A. Все, що потрібно для реалізації системи токенів, — це реалізувати цю логіку в контракті.

Базовий код для реалізації системи токенів на 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, що діють як субвалюти, потенційно можуть включати ще одну важливу функцію, якої бракує мета-валютам на базі Bitcoin, що працюють на блокчейні: можливість сплачувати комісії за транзакції безпосередньо в цій валюті. Це було б реалізовано таким чином: контракт підтримував би баланс ether, з якого він повертав би ether, використані для сплати комісій, відправнику, і він поповнював би цей баланс, збираючи внутрішні одиниці валюти, які він отримує як комісію, і перепродаючи їх на постійному аукціоні. Таким чином, користувачам потрібно було б «активувати» свої акаунти за допомогою ether, але як тільки ether там з'являться, вони будуть багаторазовими, оскільки контракт повертатиме їх щоразу.

Фінансові деривативи та валюти зі стабільною вартістю

Фінансові деривативи є найпоширенішим застосуванням «смарт-контракту» і одним з найпростіших для реалізації в коді. Основна проблема при реалізації фінансових контрактів полягає в тому, що більшість з них вимагають посилання на зовнішній ціновий тикер; наприклад, дуже бажаним застосуванням є смарт-контракт, який хеджує від волатильності ether (або іншої криптовалюти) відносно долара США, але для цього контракт повинен знати, яка вартість ETH/USD. Найпростіший спосіб зробити це — через контракт «каналу даних», який підтримується певною стороною (наприклад, NASDAQ), розроблений так, що ця сторона має можливість оновлювати контракт за потреби, і надає інтерфейс, який дозволяє іншим контрактам надсилати повідомлення цьому контракту та отримувати відповідь, що надає ціну.

Враховуючи цей критичний інгредієнт, хеджувальний контракт виглядав би наступним чином:

1. Зачекайте, доки сторона A введе 1000 ether.
2. Зачекайте, доки сторона B введе 1000 ether.
3. Записати в сховище вартість 1000 ether у доларах США, розраховану шляхом запиту до контракту каналу даних, скажімо, це $x.
4. Через 30 днів дозволити A або B «реактивувати» контракт, щоб надіслати A ether на суму $x (розраховану шляхом повторного запиту до контракту каналу даних для отримання нової ціни), а решту — B.

Такий контракт матиме значний потенціал у криптокомерції. Одна з головних проблем, що згадуються щодо криптовалюти, — це її волатильність; хоча багато користувачів і продавців можуть хотіти безпеки та зручності роботи з криптографічними активами, вони можуть не бажати стикатися з перспективою втратити 23% вартості своїх коштів за один день. Досі найчастіше пропонованим рішенням були активи, забезпечені емітентом; ідея полягає в тому, що емітент створює суб-валюту, в якій він має право випускати та відкликати одиниці, і надає одну одиницю валюти будь-кому, хто надає йому (офлайн) одну одиницю зазначеного базового активу (наприклад, золото, долар США). Потім емітент обіцяє надати одну одиницю базового активу кожному, хто поверне одну одиницю криптоактиву. Цей механізм дозволяє будь-якому некриптографічному активу бути «піднятим» до криптографічного активу, за умови, що емітенту можна довіряти.

Однак на практиці емітенти не завжди є надійними, а в деяких випадках банківська інфраструктура занадто слабка або занадто ворожа для існування таких послуг. Фінансові деривативи забезпечують альтернативу. Тут, замість одного емітента, який надає кошти для забезпечення активу, цю роль відіграє децентралізований ринок спекулянтів, які роблять ставки на те, що ціна криптографічного довідкового активу (наприклад, ETH) зросте. На відміну від емітентів, спекулянти не мають можливості відмовитися від своїх зобов'язань, оскільки хеджувальний контракт утримує їхні кошти на ескроу-рахунку. Зауважте, що цей підхід не є повністю децентралізованим, оскільки все ще потрібне надійне джерело для надання цінового тикера, хоча, можливо, це все одно є значним покращенням з точки зору зменшення вимог до інфраструктури (на відміну від емітента, видача цінового каналу не вимагає ліцензій і, ймовірно, може бути класифікована як свобода слова) та зменшення потенціалу для шахрайства.

Системи ідентичності та репутації

Найперша альтернативна криптовалюта, Namecoinopens in a new tab, намагалася використовувати блокчейн, подібний до Bitcoin, для створення системи реєстрації імен, де користувачі можуть реєструвати свої імена в публічній базі даних разом з іншими даними. Основний наведений випадок використання — для системи DNSopens 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, до якої можна додавати, але не змінювати чи видаляти дані. Кожен може зареєструвати ім'я з певним значенням, і ця реєстрація залишається назавжди. Більш досконалий контракт на реєстрацію імен також матиме «функціональну умову», що дозволяє іншим контрактам робити до нього запити, а також механізм для «власника» (тобто першого реєстратора) імені змінювати дані або передавати право власності. Можна навіть додати функціональність репутації та мережі довіри.

Децентралізоване зберігання файлів

За останні кілька років з'явилося чимало популярних стартапів онлайн-зберігання файлів, найвідомішим з яких є Dropbox, які прагнуть дозволити користувачам завантажувати резервну копію свого жорсткого диска, а сервіс зберігатиме цю копію та дозволить користувачеві отримувати до неї доступ в обмін на щомісячну плату. Однак на даний момент ринок зберігання файлів часом відносно неефективний; поверхневий погляд на різні існуючі рішення показує, що, особливо на рівні «моторошної долини» 20-200 ГБ, на якому не діють ні безкоштовні квоти, ні корпоративні знижки, щомісячні ціни на основне зберігання файлів такі, що ви платите більше, ніж вартість усього жорсткого диска за один місяць. Контракти Ethereum можуть дозволити розробку децентралізованої екосистеми зберігання файлів, де окремі користувачі можуть заробляти невеликі суми грошей, здаючи в оренду власні жорсткі диски, а невикористаний простір можна використовувати для подальшого зниження витрат на зберігання файлів.

Ключовим елементом такого пристрою буде те, що ми назвали «децентралізованим контрактом Dropbox». Цей контракт працює таким чином. Спочатку бажані дані розбиваються на блоки, кожен блок шифрується для конфіденційності, і з них будується дерево Меркла. Потім створюється контракт з правилом, що кожні N блоків контракт вибиратиме випадковий індекс у дереві Меркла (використовуючи хеш попереднього блоку, доступний з коду контракту, як джерело випадковості) і даватиме X ether першій сутності, яка надасть транзакцію з доказом власності на блок за цим конкретним індексом у дереві, подібним до спрощеної перевірки платежу. Коли користувач хоче повторно завантажити свій файл, він може використовувати протокол мікроплатіжних каналів (наприклад, платити 1 szabo за 32 кілобайти) для відновлення файлу; найефективніший з точки зору комісії підхід для платника — не публікувати транзакцію до кінця, а натомість замінювати її на трохи вигіднішу з тим самим nonce після кожних 32 кілобайтів.

Важливою особливістю протоколу є те, що, хоча може здатися, ніби ви довіряєте багатьом випадковим вузлам не вирішувати забути файл, цей ризик можна зменшити майже до нуля, розділивши файл на багато частин за допомогою таємного розподілу та спостерігаючи за контрактами, щоб переконатися, що кожна частина все ще знаходиться у володінні якогось вузла. Якщо контракт все ще виплачує гроші, це є криптографічним доказом того, що хтось десь все ще зберігає файл.

Децентралізовані автономні організації

Загальна концепція «децентралізованої автономної організації» — це віртуальна сутність, яка має певний набір членів або акціонерів, які, можливо, з більшістю в 67%, мають право витрачати кошти сутності та змінювати її код. Члени колективно вирішуватимуть, як організація повинна розподіляти свої кошти. Методи розподілу коштів DAO можуть варіюватися від винагород, зарплат до ще більш екзотичних механізмів, таких як внутрішня валюта для винагороди за роботу. Це по суті відтворює юридичні атрибути традиційної компанії або некомерційної організації, але з використанням лише криптографічної технології блокчейн для забезпечення виконання. Досі значна частина розмов про DAO точилася навколо «капіталістичної» моделі «децентралізованої автономної корпорації» (DAC) з акціонерами, що отримують дивіденди, та акціями, що торгуються; альтернатива, яку, можливо, можна описати як «децентралізовану автономну спільноту», передбачала б, що всі члени мають рівну частку в прийнятті рішень і вимагала б згоди 67% існуючих членів на додавання або видалення члена. Вимога, щоб одна людина могла мати лише одне членство, тоді повинна була б колективно забезпечуватися групою.

Загальний план, як кодувати DAO, наведено далі. Найпростіша конструкція — це просто фрагмент самомодифікованого коду, який змінюється, якщо дві третини членів погоджуються на зміну. Хоча код теоретично є незмінним, це можна легко обійти і мати де-факто змінність, маючи частини коду в окремих контрактах і зберігаючи адресу контрактів, які потрібно викликати, у модифікованому сховищі. У простій реалізації такого контракту DAO було б три типи транзакцій, що відрізняються даними, наданими в транзакції:

• [0,i,K,V] для реєстрації пропозиції з індексом i про зміну адреси в індексі сховища K на значення V
• [1,i] для реєстрації голосу на користь пропозиції i
• [2,i] для фіналізації пропозиції i, якщо було зроблено достатньо голосів

У контракті будуть умови для кожного випадку. Він би вів запис усіх відкритих змін у сховищі, а також список тих, хто за них проголосував. Також буде надано список усіх учасників. Коли будь-яка зміна у сховищі набирає дві третини голосів членів, фіналізуюча транзакція може виконати зміну. Більш досконала структура також мала б вбудовану можливість голосування за такі функції, як відправлення транзакції, додавання та видалення членів, і навіть могла б передбачати делегування голосів у стилі ліквідної демократіїopens in a new tab (тобто кожен може призначити когось голосувати за нього, і це призначення є транзитивним, тому якщо A призначає B, а B призначає C, то C визначає голос A). Цей дизайн дозволив би DAO органічно рости як децентралізована спільнота, дозволяючи людям з часом делегувати завдання фільтрації членів спеціалістам, хоча на відміну від «поточної системи», спеціалісти можуть легко з'являтися та зникати з часом, оскільки окремі члени спільноти змінюють свої погляди.

Альтернативна модель — це децентралізована корпорація, де будь-який акаунт може мати нуль або більше акцій, і для прийняття рішення потрібно дві третини акцій. Повний каркас включав би функціональність управління активами, можливість робити пропозицію про купівлю або продаж акцій, а також можливість приймати пропозиції (бажано з механізмом зіставлення ордерів усередині контракту). Делегування також існувало б у стилі ліквідної демократії, узагальнюючи концепцію «ради директорів».

Подальші застосування

1. Ощадні гаманці. Припустимо, Аліса хоче зберегти свої кошти в безпеці, але хвилюється, що вона втратить або хтось зламає її приватний ключ. Вона вкладає ether у контракт із Бобом, банком, на таких умовах:

• Еліс сама може вивести лише максимум 1 % коштів на день.
• Боб сам може знімати максимум 1% коштів на день, але Аліса має можливість зробити транзакцію своїм ключем, щоб відключити цю можливість.
• Еліс і Боб разом можуть вивести будь-яку суму.

Зазвичай, 1% на день достатньо для Аліси, і якщо Аліса хоче зняти більше, вона може звернутися до Боба по допомогу. Якщо ключ Аліси зламають, вона біжить до Боба, щоб перевести кошти на новий контракт. Якщо вона втратить свій ключ, Боб з часом виведе кошти. Якщо Боб виявиться зловмисником, вона може вимкнути його можливість знімати кошти.

2. Страхування врожаю. Можна легко створити контракт на фінансові деривативи, але використовуючи дані про погоду замість будь-якого цінового індексу. Якщо фермер в Айові купує дериватив, який виплачує обернено пропорційно до кількості опадів в Айові, то в разі посухи фермер автоматично отримає гроші, а якщо дощу буде достатньо, фермер буде щасливий, бо його врожай буде добрим. Загалом це можна розширити й на страхування від стихійного лиха.

3. Децентралізований канал даних. Для фінансових контрактів на різницю, можливо, вдасться децентралізувати канал даних за допомогою протоколу під назвою "SchellingCoinopens in a new tab". SchellingCoin в основному працює наступним чином: N сторін вводять в систему значення певного даного (наприклад, ціну ETH/USD), значення сортуються, і кожен, хто знаходиться між 25-м і 75-м процентилями, отримує один токен як винагороду. Кожен має стимул надати відповідь, яку нададуть усі інші, і єдине значення, на яке може реально погодитися велика кількість гравців, — це очевидне значення за замовчуванням: правда. Це створює децентралізований протокол, який теоретично може надавати будь-яку кількість значень, включаючи ціну ETH/USD, температуру в Берліні або навіть результат певного складного обчислення.

4. Смартескроу з мультипідписом. Bitcoin дозволяє транзакційні контракти з мультипідписом, де, наприклад, три з п'яти заданих ключів можуть витрачати кошти. Ethereum дозволяє більшу гранулярність; наприклад, чотири з п'яти можуть витрачати все, три з п'яти можуть витрачати до 10% на день, а два з п'яти можуть витрачати до 0,5% на день. Крім того, мультипідпис в Ethereum є асинхронним — дві сторони можуть реєструвати свої підписи на блокчейні в різний час, і останній підпис автоматично надішле транзакцію.

5. Cloud computing. Технологія EVM також може бути використана для створення верифікованого обчислювального середовища, що дозволяє користувачам просити інших виконувати обчислення, а потім за бажанням просити докази того, що обчислення на певних випадково вибраних контрольних точках були виконані правильно. Це дозволяє створити ринок хмарних обчислень, де будь-який користувач може брати участь зі своїм настільним комп'ютером, ноутбуком або спеціалізованим сервером, а вибіркова перевірка разом із заставами безпеки може використовуватися для забезпечення надійності системи (тобто вузли не можуть вигідно шахраювати). Хоча така система може не підходити для всіх завдань; завдання, що вимагають високого рівня міжпроцесорної комунікації, наприклад, не можуть бути легко виконані на великій хмарі вузлів. Однак інші завдання набагато легше паралелізувати; проєкти, такі як SETI@home, folding@home та генетичні алгоритми, можуть бути легко реалізовані на такій платформі.

6. Однорангові азартні ігри. Будь-яку кількість протоколів азартних ігор peer-to-peer, таких як Cyberdiceopens 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 випадково видобуває інший блок до того, як блок майнера A пошириться до B, блок майнера B буде витрачений даремно і не сприятиме безпеці мережі. Крім того, існує проблема централізації: якщо майнер A — це майнінговий пул з 30% хеш-потужності, а B має 10% хеш-потужності, A матиме ризик створити застарілий блок у 70% випадків (оскільки в інших 30% випадків A створив останній блок і тому негайно отримає дані для майнінгу), тоді як B матиме ризик створити застарілий блок у 90% випадків. Таким чином, якщо інтервал між блоками достатньо короткий, щоб рівень застарілих блоків був високим, A буде значно ефективнішим просто завдяки своєму розміру. З урахуванням цих двох ефектів, блокчейни, які швидко створюють блоки, з великою ймовірністю призведуть до того, що один майнінговий пул матиме достатньо великий відсоток хеш-потужності мережі, щоб де-факто контролювати процес майнінгу.

Як описано Сомполінським та Зохаром, GHOST вирішує першу проблему втрати безпеки мережі, включаючи застарілі блоки в розрахунок того, який ланцюжок є «найдовшим»; тобто, не лише батьківський та подальші предки блоку, але й застарілі нащадки предка блоку (в жаргоні Ethereum, «дядьки») додаються до розрахунку того, який блок має найбільший загальний доказ виконаної роботи, що його підтримує. Щоб вирішити другу проблему упередженості до централізації, ми виходимо за рамки протоколу, описаного Сомполінським і Зохаром, і також надаємо винагороди за застарілі блоки: застарілий блок отримує 87,5% своєї базової винагороди, а «племінник», що включає застарілий блок, отримує решту 12,5%. Проте комісія за транзакцію не призначається елементам uncle.

Ethereum реалізує спрощену версію GHOST, яка опускається лише на сім рівнів. Особливо це визначається таким чином:

• Блок має вказувати батьківський елемент, а також указувати 0 або більше елементів uncle
• Елемент uncle, включений у блок B, повинен мати такі властивості:
  • Він має бути прямим нащадком предка k-го покоління B, де 2 <= k <= 7.
  • Він не може бути попередником B.
  • «Дядько» має бути дійсним заголовком блоку, але не обов'язково бути раніше перевіреним або навіть дійсним блоком
  • «Дядько» повинен відрізнятися від усіх «дядьків», включених у попередні блоки, та всіх інших «дядьків», включених у той самий блок (без подвійного включення)
• За кожного «дядька» U в блоці B, майнер B отримує додаткові 3,125% до своєї винагороди coinbase, а майнер U отримує 93,75% стандартної винагороди coinbase.

Ця обмежена версія GHOST, з можливістю включення «дядьків» лише до 7 поколінь, була використана з двох причин. По-перше, необмежений GHOST вніс би занадто багато ускладнень у розрахунок того, які «дядьки» для даного блоку є дійсними. По-друге, необмежений GHOST з компенсацією, як використовується в Ethereum, усуває стимул для майнера майнити на основному ланцюжку, а не на ланцюжку публічного зловмисника.

Комісії

Оскільки кожна транзакція, опублікована в блокчейні, накладає на мережу витрати на її завантаження та перевірку, необхідний певний регуляторний механізм, який зазвичай включає комісії за транзакції, для запобігання зловживанням. Стандартний підхід, який використовується в Bitcoin, полягає в наявності суто добровільних комісій, покладаючись на майнерів як на вартових, які встановлюють динамічні мінімуми. Цей підхід був дуже сприятливо сприйнятий у спільноті Bitcoin, особливо тому, що він є «ринковим», дозволяючи попиту та пропозиції між майнерами та відправниками транзакцій визначати ціну. Проблема з цим міркуванням, однак, полягає в тому, що обробка транзакцій не є ринком; хоча інтуїтивно привабливо розглядати обробку транзакцій як послугу, яку майнер пропонує відправнику, насправді кожна транзакція, яку майнер включає, повинна бути оброблена кожним вузлом у мережі, тому переважна більшість витрат на обробку транзакцій лягає на третіх осіб, а не на майнера, який приймає рішення про те, включати її чи ні. Отже, проблеми трагедії спільного дуже ймовірні.

Однак, як виявляється, цей недолік ринкового механізму, за певного неточного спрощувального припущення, магічно сам себе скасовує. Аргументація така. Припустимо, що:

1. Транзакція призводить до k операцій, пропонуючи винагороду kR будь-якому майнеру, який її включить, де R встановлюється відправником, а k та R (приблизно) видимі майнеру заздалегідь.
2. Операція має вартість обробки C для будь-якого вузла (тобто всі вузли мають однакову ефективність)
3. Існує N майнінгових вузлів, кожен з яких має абсолютно однакову обчислювальну потужність (тобто 1/N від загальної)
4. Не існує повних вузлів, які не здійснюють майнінг.

Майнер буде готовий обробити транзакцію, якщо очікувана винагорода більша за вартість. Таким чином, очікувана винагорода становить kR/N, оскільки майнер має 1/N шанс обробити наступний блок, а вартість обробки для майнера просто kC. Отже, майнери будуть включати транзакції, де kR/N > kC, або R > NC. Зауважте, що R — це плата за операцію, яку надає відправник, і, таким чином, є нижньою межею вигоди, яку відправник отримує від транзакції, а NC — це вартість обробки операції для всієї мережі разом. Отже, майнери мають стимул включати лише ті транзакції, для яких загальна утилітарна вигода перевищує вартість.

Однак у реальності існує кілька важливих відхилень від цих припущень:

1. Майнер сплачує вищу вартість за обробку транзакції, ніж інші вузли-верифікатори, оскільки додатковий час верифікації затримує поширення блоку і таким чином збільшує ймовірність того, що блок стане застарілим.
2. Існують повні вузли, що не займаються майнінгом.
3. Розподіл потужності для майнінгу на практиці може виявитися радикально нерівним.
4. Спекулянти, політичні вороги та божевільні, чия функція корисності включає завдання шкоди мережі, існують, і вони можуть хитро створювати контракти, де їхні витрати набагато нижчі, ніж витрати, які сплачують інші вузли-верифікатори.

(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: (виконати один крок програми та записати зміну у сховищі)

Тепер надішліть транзакцію на A. Таким чином, за 51 транзакцію ми маємо контракт, який займає 2⁵⁰ обчислювальних кроків. Майнери могли б спробувати виявити такі логічні бомби заздалегідь, підтримуючи значення поруч з кожним контрактом, що вказує на максимальну кількість обчислювальних кроків, які він може виконати, і обчислюючи це для контрактів, що рекурсивно викликають інші контракти, але це вимагало б від майнерів заборонити контракти, що створюють інші контракти (оскільки створення та виконання всіх 26 контрактів вище можна легко згорнути в один контракт). Ще одним проблемним моментом є те, що поле адреси повідомлення є змінною, тому загалом може бути навіть неможливо заздалегідь визначити, які інші контракти викликатиме даний контракт. Отже, загалом, ми приходимо до дивного висновку: повнотою за Тюрінгом напрочуд легко керувати, а відсутністю повноти за Тюрінгом так само напрочуд важко керувати, якщо не застосовуються ті самі засоби контролю — але в такому разі чому б просто не дозволити протоколу бути повним за Тюрінгом?

Валюта та емісія

Мережа Ethereum включає власну вбудовану валюту, ether, яка виконує подвійну функцію: забезпечення основного шару ліквідності для ефективного обміну між різними типами цифрових активів і, що важливіше, надання механізму для сплати комісій за транзакції. Для зручності та щоб уникнути майбутніх суперечок (див. поточну дискусію про mBTC/uBTC/satoshi в Bitcoin), номінали будуть попередньо позначені:

• 1: wei
• 10¹²: szabo
• 10¹⁵: finney
• 10¹⁸: ether

Це слід розглядати як розширену версію концепції «доларів» і «центів» або «BTC» і «сатоші». Найближчим часом ми очікуємо, що «ether» буде використовуватися для звичайних транзакцій, «finney» для мікротранзакцій, а «szabo» і «wei» для технічних дискусій щодо комісій та реалізації протоколу; інші номінали можуть стати корисними пізніше і на даний момент не повинні включатися до клієнтів.

Модель випуску буде такою:

• Ether буде випущено в продаж за ціною 1000-2000 ether за BTC, механізм, призначений для фінансування організації Ethereum та оплати розробки, який з успіхом використовувався іншими платформами, такими як Mastercoin та NXT. Ранні покупці отримають більші знижки. Отримані від продажу BTC будуть повністю використані для виплати зарплат і винагород розробникам та інвестовані в різні комерційні та некомерційні проєкти в екосистемі Ethereum та криптовалют.
• 0.099x від загальної проданої суми (60102216 ETH) буде виділено організації для компенсації раннім учасникам та оплати витрат, номінованих в ETH, до генезисного блоку.
• 0.099x від загальної проданої суми буде зберігатися як довгостроковий резерв.
• 0.26x від загальної проданої суми буде виділятися майнерам щороку назавжди після цього моменту.

Темпи довгострокового зростання постачання (у відсотках)

Незважаючи на лінійну емісію валюти, так само, як і в Bitcoin, з часом темпи зростання пропозиції все одно прагнуть до нуля.

Двома основними виборами у наведеній вище моделі є (1) існування та розмір фонду пожертвувань, та (2) існування постійно зростаючої лінійної пропозиції, на відміну від обмеженої пропозиції, як у Bitcoin. Обґрунтування фонду пожертвувань є наступним. Якби фонд пожертвувань не існував, а лінійна емісія зменшилася до 0.217x, щоб забезпечити такий самий рівень інфляції, то загальна кількість ether була б на 16.5% меншою, і тому кожна одиниця була б на 19.8% ціннішою. Отже, в рівновазі на 19.8% більше ether було б куплено під час продажу, тому кожна одиниця знову була б точно такою ж цінною, як і раніше. Організація тоді також мала б на 1,198x більше BTC, які можна розглядати як розділені на дві частини: початкові BTC та додаткові 0,198x. Отже, ця ситуація є точно еквівалентною пожертвуванню, але з однією важливою відмінністю: організація володіє виключно BTC і, отже, не має стимулів підтримувати вартість одиниці ether.

Модель постійного лінійного зростання пропозиції зменшує ризик того, що дехто вважає надмірною концентрацією багатства в Bitcoin, і дає людям, що живуть у сьогоденні та майбутньому, справедливий шанс придбати одиниці валюти, водночас зберігаючи сильний стимул отримувати та утримувати ether, оскільки «темп зростання пропозиції» у відсотках з часом все одно прагне до нуля. Ми також припускаємо, що оскільки монети завжди втрачаються з часом через недбалість, смерть тощо, і втрату монет можна змоделювати як відсоток від загальної пропозиції на рік, то загальна пропозиція валюти в обігу з часом стабілізується на значенні, що дорівнює річній емісії, поділеній на коефіцієнт втрати (наприклад, при коефіцієнті втрати 1%, як тільки пропозиція досягне 26X, то 0.26X буде видобуто і 0.26X втрачено щороку, створюючи рівновагу).

Зауважте, що в майбутньому, ймовірно, Ethereum перейде на модель доказу частки володіння для безпеки, зменшуючи вимоги до емісії до рівня між нулем і 0.05X на рік. У випадку, якщо організація Ethereum втратить фінансування або з будь-якої іншої причини зникне, ми залишаємо відкритим «соціальний контракт»: кожен має право створити майбутню кандидатську версію Ethereum, за єдиної умови, що кількість ether повинна бути не більше 60102216 * (1.198 + 0.26 * n), де n — кількість років після генезисного блоку. Творці вільні проводити крауд-продажі або іншим чином розподіляти частину або всю різницю між розширенням пропозиції на основі PoS та максимально допустимим розширенням пропозиції для оплати розробки. Кандидатські оновлення, які не відповідають соціальному контракту, можуть бути виправдано розгалужені на сумісні версії.

Централізація майнінгу

Алгоритм майнінгу Bitcoin працює так, що майнери обчислюють SHA256 на трохи змінених версіях заголовка блоку мільйони разів, доки нарешті один вузол не знайде версію, хеш якої менший за цільове значення (наразі близько 2¹⁹²). Однак цей алгоритм майнінгу вразливий до двох форм централізації. По-перше, екосистема майнінгу стала домінуватися ASIC (інтегральними схемами спеціального призначення), комп'ютерними чіпами, розробленими для конкретного завдання майнінгу Bitcoin і, отже, у тисячі разів ефективнішими за нього. Це означає, що майнінг Bitcoin більше не є високодецентралізованим та егалітарним заняттям, що вимагає мільйонів доларів капіталу для ефективної участі. По-друге, більшість майнерів Bitcoin насправді не виконують валідацію блоків локально; натомість вони покладаються на централізований майнінговий пул для надання заголовків блоків. Ця проблема, можливо, ще гірша: на момент написання цього тексту три провідні майнінгові пули опосередковано контролюють приблизно 50% обчислювальної потужності в мережі Bitcoin, хоча це пом'якшується тим фактом, що майнери можуть переходити до інших майнінгових пулів, якщо пул або коаліція спробує здійснити атаку 51%.

Поточний намір Ethereum полягає у використанні алгоритму майнінгу, де майнери повинні отримувати випадкові дані зі стану, обчислювати деякі випадково вибрані транзакції з останніх N блоків у блокчейні та повертати хеш результату. Це має дві важливі переваги. По-перше, контракти Ethereum можуть включати будь-які обчислення, тому Ethereum ASIC по суті був би ASIC для загальних обчислень — тобто, кращим ЦП. По-друге, майнінг вимагає доступу до всього блокчейну, змушуючи майнерів зберігати весь блокчейн і принаймні бути здатними перевіряти кожну транзакцію. Це усуває потребу в централізованих майнінгових пулах; хоча майнінгові пули все ще можуть виконувати законну роль вирівнювання випадковості розподілу винагород, цю функцію можуть так само добре виконувати пірингові пули без центрального контролю.

Ця модель не перевірена, і на шляху можуть виникнути труднощі з уникненням певних хитрих оптимізацій при використанні виконання контракту як алгоритму майнінгу. Однак однією особливо цікавою особливістю цього алгоритму є те, що він дозволяє будь-кому «отруїти колодязь», вводячи велику кількість контрактів у блокчейн, спеціально розроблених для перешкоджання певним ASIC. Існують економічні стимули для виробників ASIC використовувати такий трюк для атаки один на одного. Таким чином, рішення, яке ми розробляємо, є в кінцевому підсумку адаптивним економічним людським рішенням, а не суто технічним.

Масштабованість

Одна поширена проблема, що викликає занепокоєння щодо Ethereum, — це проблема масштабованості. Як і Bitcoin, Ethereum страждає від недоліку, що кожна транзакція повинна бути оброблена кожним вузлом у мережі. У Bitcoin розмір поточного блокчейну становить близько 15 ГБ і зростає приблизно на 1 МБ на годину. Якби мережа Bitcoin обробляла 2000 транзакцій Visa на секунду, вона б зростала на 1 МБ кожні три секунди (1 ГБ на годину, 8 ТБ на рік). Ethereum, ймовірно, зазнає подібного зростання, що погіршується тим фактом, що на блокчейні Ethereum буде багато застосунків, а не лише валюта, як у випадку з Bitcoin, але це пом'якшується тим фактом, що повні вузли Ethereum повинні зберігати лише стан, а не всю історію блокчейну.

Проблема такого великого розміру блокчейну — це ризик централізації. Якщо розмір блокчейну збільшиться, скажімо, до 100 ТБ, то ймовірним сценарієм буде те, що лише дуже невелика кількість великих підприємств буде запускати повні вузли, а всі звичайні користувачі використовуватимуть легкі вузли SPV. У такій ситуації виникає потенційне занепокоєння, що повні вузли можуть об'єднатися і всі разом домовитися про шахрайство у вигідний для себе спосіб (наприклад, змінити винагороду за блок, надати собі BTC). Легкі вузли не мали б змоги виявити це негайно. Звичайно, принаймні один чесний повний вузол, ймовірно, існуватиме, і через кілька годин інформація про шахрайство просочиться через такі канали, як Reddit, але на той момент буде вже занадто пізно: звичайним користувачам доведеться організувати зусилля, щоб занести в чорний список дані блоки, що є величезною і, ймовірно, нездійсненною проблемою координації, схожою за масштабом на успішну атаку 51%. У випадку з Bitcoin це наразі є проблемою, але існує модифікація блокчейну, запропонована Пітером Тоддомopens in a new tab, яка полегшить цю проблему.

Найближчим часом Ethereum використовуватиме дві додаткові стратегії для вирішення цієї проблеми. По-перше, через алгоритми майнінгу на основі блокчейну, принаймні кожен майнер буде змушений бути повним вузлом, створюючи нижню межу кількості повних вузлів. По-друге, і що важливіше, ми будемо включати проміжний корінь дерева стану в блокчейн після обробки кожної транзакції. Навіть якщо валідація блоків централізована, доки існує один чесний вузол-верифікатор, проблему централізації можна обійти за допомогою протоколу верифікації. Якщо майнер публікує недійсний блок, цей блок має бути або неправильно відформатований, або стан S[n] є невірним. Оскільки відомо, що S[0] є правильним, має існувати якийсь перший стан S[i], який є невірним, тоді як S[i-1] є правильним. Вузол-верифікатор надасть індекс i разом із «доказом недійсності», що складається з підмножини вузлів дерева Патриції, необхідних для обробки APPLY(S[i-1],TX[i]) -> S[i]. Вузли зможуть використовувати ці вузли для виконання цієї частини обчислень і побачити, що згенерований S[i] не відповідає наданому S[i].

Інша, більш витончена атака, полягала б у тому, що зловмисні майнери публікували б неповні блоки, так що повної інформації для визначення дійсності блоків навіть не існувало б. Рішенням цієї проблеми є протокол «виклик-відповідь»: вузли-верифікатори видають «виклики» у вигляді цільових індексів транзакцій, і після отримання вузла легкий вузол розглядає блок як ненадійний, доки інший вузол, будь то майнер чи інший верифікатор, не надасть підмножину вузлів Патриції як доказ дійсності.

Висновок

Протокол Ethereum спочатку був задуманий як оновлена версія криптовалюти, що надає розширені функції, такі як ескроу на блокчейні, ліміти на зняття коштів, фінансові контракти, ринки азартних ігор тощо, за допомогою високо узагальненої мови програмування. Протокол Ethereum не буде «підтримувати» жоден із застосунків безпосередньо, але існування повної за Тюрінгом мови програмування означає, що довільні контракти теоретично можуть бути створені для будь-якого типу транзакцій або застосунків. Однак що цікавіше в Ethereum, це те, що протокол Ethereum виходить далеко за межі просто валюти. Протоколи, пов'язані з децентралізованим зберіганням файлів, децентралізованими обчисленнями та децентралізованими ринками прогнозів, серед десятків інших подібних концепцій, мають потенціал суттєво підвищити ефективність обчислювальної індустрії та надати значний поштовх іншим піринговим протоколам, вперше додавши економічний шар. Нарешті, існує також значна кількість застосунків, які не мають жодного стосунку до грошей.

Концепція довільної функції переходу стану, реалізована протоколом Ethereum, забезпечує платформу з унікальним потенціалом; замість того, щоб бути закритим, одноцільовим протоколом, призначеним для певного набору застосунків у сфері зберігання даних, азартних ігор або фінансів, Ethereum є відкритим за своєю конструкцією, і ми вважаємо, що він надзвичайно добре підходить для того, щоб слугувати фундаментальним шаром для дуже великої кількості як фінансових, так і нефінансових протоколів у майбутньому.

Примітки та додаткова література

Примітки

1. Досвідчений читач може помітити, що насправді адреса Bitcoin є хешем відкритого ключа еліптичної кривої, а не самим відкритим ключем. Однак, насправді, з точки зору криптографічної термінології цілком законно називати хеш відкритого ключа самим відкритим ключем. Це тому, що криптографію Bitcoin можна розглядати як власний алгоритм цифрового підпису, де відкритий ключ складається з хешу відкритого ключа ECC, підпис складається з відкритого ключа ECC, з'єднаного з підписом ECC, а алгоритм верифікації включає перевірку відкритого ключа ECC в підписі з хешем відкритого ключа ECC, наданим як відкритий ключ, а потім верифікацію підпису ECC з відкритим ключем ECC.
2. Технічно — медіана 11 попередніх блоків.
3. Внутрішньо, 2 і "CHARLIE" обидва є числами^fn3, причому останнє представлено у 256-ричній системі числення. Числа можуть бути від 0 до 2²⁵⁶-1.

Додаткові матеріали

1. Внутрішня вартістьopens in a new tab
2. Розумна власністьopens in a new tab
3. Смарт-контрактиopens in a new tab
4. B-moneyopens in a new tab
5. Докази виконаної роботи багаторазового використанняopens in a new tab
6. Захищені титули власності з повноваженнями власникаopens in a new tab
7. Біла книга Bitcoinopens in a new tab
8. Namecoinopens in a new tab
9. Трикутник Зукоopens in a new tab
10. Біла книга кольорових монетopens in a new tab
11. Біла книга Mastercoinopens in a new tab
12. Децентралізовані автономні корпорації, Bitcoin Magazineopens in a new tab
13. Спрощена перевірка платежівopens in a new tab
14. Дерева Мерклаopens in a new tab
15. Дерева Патриціїopens in a new tab
16. GHOSTopens in a new tab
17. StorJ та автономні агенти, Джефф Гарзікopens in a new tab
18. Майк Херн про розумну власність на фестивалі Тюрінгаopens in a new tab
19. Ethereum RLP
20. Ethereum Merkle Patricia trees
21. Пітер Тодд про дерева сум Мерклаopens in a new tab

Історію білої книги див. у цій вікіopens in a new tab.

Платформа Ethereum, як і багато інших проєктів програмного забезпечення з відкритим вихідним кодом, що керуються спільнотою, еволюціонувала з моменту її створення. Щоб дізнатися про останні розробки Ethereum і про те, як вносяться зміни до протоколу, ми рекомендуємо цей посібник.

Останні оновлення сторінки: 16 лютого 2026 р.

popens in a new tab

mopens in a new tab

wopens in a new tab

+11

Переглянути учасників