Біла книга Етеріуму

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

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

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

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

Історія

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

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

Біткоїн як система переходу станів

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

APPLY(S,TX) -> S' or ERROR

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

APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }

Але:

APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR

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

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

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 «решти», власником якої буде сама Аліса.

Майнінг

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

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

1. Перевірити, чи існує попередній блок, на який посилається цей блок, і чи є він валідним.
2. Перевірити, що мітка часу блоку більша за мітку часу попереднього блоку^fn2 і не перевищує 2 години в майбутньому.
3. Перевірити, що доказ виконання роботи (PoW) для блоку є валідним.
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, але не навпаки.

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

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

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

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%»).

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

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

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

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

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

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

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

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

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

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

Скриптинг

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

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

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

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

Етеріум

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

Акаунти Етеріуму

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

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

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

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

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

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

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

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

Поля STARTGAS та GASPRICE є критично важливими для моделі захисту Етеріуму від відмови в обслуговуванні (anti-denial of service). Щоб запобігти випадковим або ворожим нескінченним циклам чи іншим обчислювальним марнотратствам у коді, кожна транзакція має вимогу встановлювати ліміт на те, скільки обчислювальних кроків виконання коду вона може використати. Фундаментальною одиницею обчислень є «газ»; зазвичай обчислювальний крок коштує 1 газ, але деякі операції коштують більшу кількість газу, оскільки вони є більш обчислювально витратними або збільшують обсяг даних, які повинні зберігатися як частина стану. Також стягується комісія у розмірі 5 газу за кожен байт у даних транзакції. Намір системи комісій полягає в тому, щоб вимагати від зловмисника платити пропорційно за кожен ресурс, який він споживає, включаючи обчислення, пропускну здатність та сховище; отже, будь-яка транзакція, яка призводить до того, що мережа споживає більшу кількість будь-якого з цих ресурсів, повинна мати комісію за газ, приблизно пропорційну цьому збільшенню.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Перевірити, чи існує та чи є дійсним попередній блок, на який є посилання.
2. Перевірити, що часова мітка блоку більша за часову мітку попереднього блоку, на який є посилання, і менша ніж 15 хвилин у майбутньому.
3. Перевірити, чи є дійсними номер блоку, складність, корінь транзакцій, корінь uncle-блоків та ліміт газу (різні низькорівневі концепції, специфічні для Етеріуму).
4. Перевірити, чи є дійсним доказ виконання роботи (PoW) для блоку.
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 дорівнює кореню кінцевого стану, наданому в заголовку блоку. Якщо так, блок є дійсним; інакше він недійсний.

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

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

Застосунки

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

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

Системи токенів на блокчейні мають багато застосувань: від субвалют, що представляють такі активи, як USD або золото, до акцій компаній, індивідуальних токенів, що представляють розумну власність, безпечних купонів, які неможливо підробити, і навіть систем токенів, які взагалі не прив'язані до традиційної вартості та використовуються як системи балів для заохочення. Системи токенів напрочуд легко реалізувати в Етеріумі. Ключовий момент, який слід розуміти, полягає в тому, що будь-яка валюта або система токенів — це, по суті, база даних з однією операцією: відняти 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

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

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

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

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

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

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

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

Системи ідентифікації та репутації

Найперша альтернативна криптовалюта, Namecoin (opens in a new tab), спробувала використати блокчейн, подібний до Біткоїна, для створення системи реєстрації імен, де користувачі можуть реєструвати свої імена в публічній базі даних разом з іншими даними. Основним згаданим варіантом використання є система DNS (opens in a new tab), яка зіставляє доменні імена, такі як «bitcoin.org» (або, у випадку Namecoin, «bitcoin.bit»), з IP-адресою. Інші варіанти використання включають автентифікацію електронної пошти та потенційно більш просунуті системи репутації. Ось базовий контракт для забезпечення системи реєстрації імен, подібної до Namecoin, в Етеріумі:

def register(name, value):
  if !self.storage[name]:
    self.storage[name] = value

Контракт дуже простий; це лише база даних усередині мережі Етеріум, до якої можна додавати дані, але не можна їх змінювати чи видаляти. Будь-хто може зареєструвати ім'я з певним значенням, і ця реєстрація залишається назавжди. Більш складний контракт реєстрації імен також матиме «функціональне положення», що дозволятиме іншим контрактам робити до нього запити, а також механізм для «власника» (тобто першого реєстратора) імені для зміни даних або передачі права власності. Можна навіть додати функціонал репутації та мережі довіри (web-of-trust) поверх цього.

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

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

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

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

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

Загальна концепція «децентралізованої автономної організації» (DAO) полягає у віртуальній сутності, яка має певний набір учасників або акціонерів, які, можливо, більшістю у 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. Ощадні гаманці. Припустимо, що Аліса хоче зберегти свої кошти в безпеці, але хвилюється, що вона втратить свій приватний ключ або хтось його зламає. Вона вносить етер у контракт із Бобом, банком, таким чином:

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

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

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

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

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

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

6. Однорангові азартні ігри. Будь-яка кількість протоколів однорангових азартних ігор, таких як Cyberdice (opens in a new tab) Френка Стаяно та Річарда Клейтона, може бути реалізована на блокчейні Етеріуму. Найпростіший протокол азартних ігор — це насправді просто контракт на різницю на хеш наступного блоку, і на його основі можна створювати більш просунуті протоколи, створюючи сервіси азартних ігор із майже нульовими комісіями, які не мають можливості шахраювати.

7. Ринки передбачень. За наявності оракула або SchellingCoin ринки передбачень також легко реалізувати, і ринки передбачень разом із SchellingCoin можуть виявитися першим масовим застосуванням футархії (opens in a new tab) як протоколу управління для децентралізованих організацій.

8. Ончейн децентралізовані маркетплейси, що використовують систему ідентифікації та репутації як основу.

Різне та проблеми

Модифікована реалізація GHOST

Протокол "Greedy Heaviest Observed Subtree" (GHOST) — це інновація, вперше представлена Йонатаном Сомполінським (Yonatan Sompolinsky) та Авівом Зохаром (Aviv Zohar) у грудні 2013 року (opens in a new tab). Мотивація створення GHOST полягає в тому, що блокчейни зі швидким часом підтвердження наразі страждають від зниження безпеки через високий рівень застарілих блоків (stale rate) — оскільки поширення блоку мережею займає певний час, якщо майнер A видобуває блок, а потім майнер B випадково видобуває інший блок до того, як блок майнера A пошириться до B, блок майнера B виявиться марним і не сприятиме безпеці мережі. Крім того, існує проблема централізації: якщо майнер A — це майнінг-пул із 30% хешрейту, а B має 10% хешрейту, A матиме ризик створення застарілого блоку в 70% випадків (оскільки в інших 30% випадків A створив останній блок і тому отримає дані для майнінгу негайно), тоді як B матиме ризик створення застарілого блоку в 90% випадків. Таким чином, якщо інтервал між блоками достатньо короткий, щоб рівень застарілих блоків був високим, A буде значно ефективнішим просто завдяки своєму розміру. З поєднанням цих двох ефектів блокчейни, які швидко створюють блоки, з великою ймовірністю призведуть до того, що один майнінг-пул матиме достатньо великий відсоток хешрейту мережі, щоб де-факто контролювати процес майнінгу.

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

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

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

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

Комісії

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

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

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, але, ймовірно, будуть змінені після подальшого аналізу.

Існує ще один фактор, що дестимулює великі розміри блоків у Біткоїні: великі блоки поширюватимуться довше, і тому мають вищу ймовірність стати застарілими. В Етеріумі блоки, що споживають багато газу, також можуть поширюватися довше як через те, що вони фізично більші, так і через те, що обробка переходів стану транзакцій для валідації займає більше часу. Цей дестимул затримки є важливим фактором у Біткоїні, але менш важливим в Етеріумі через протокол GHOST; отже, покладання на регульовані ліміти блоків забезпечує більш стабільну основу.

Обчислення та повнота за Тюрінгом

Важливо зазначити, що віртуальна машина Етеріуму (EVM) є повною за Тюрінгом; це означає, що код EVM може кодувати будь-яке обчислення, яке можна уявити, включаючи нескінченні цикли. Код EVM дозволяє створювати цикли двома способами. По-перше, існує інструкція JUMP, яка дозволяє програмі переходити назад до попереднього місця в коді, та інструкція JUMPI для умовного переходу, що дозволяє використовувати такі оператори, як while x < 27: x = x * 2. По-друге, контракти можуть викликати інші контракти, потенційно дозволяючи створювати цикли за допомогою рекурсії. Це природно призводить до проблеми: чи можуть зловмисники по суті зупинити роботу майнерів та повних вузлів, змусивши їх увійти в нескінченний цикл? Ця проблема виникає через проблему в інформатиці, відому як проблема зупинки: у загальному випадку неможливо визначити, чи зупиниться коли-небудь дана програма.

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

• Зловмисник створює контракт, який запускає нескінченний цикл, а потім надсилає транзакцію, що активує цей цикл, майнеру. Майнер обробить транзакцію, запустивши нескінченний цикл, і чекатиме, поки в ньому не закінчиться газ. Незважаючи на те, що під час виконання закінчується газ і воно зупиняється на півдорозі, транзакція все ще є дійсною, і майнер все одно стягує комісію зі зловмисника за кожен обчислювальний крок.
• Зловмисник створює дуже довгий нескінченний цикл із наміром змусити майнера продовжувати обчислення так довго, що до моменту завершення обчислень з'явиться ще кілька блоків, і майнер не зможе включити транзакцію, щоб отримати комісію. Однак від зловмисника вимагатиметься надати значення для STARTGAS, що обмежує кількість обчислювальних кроків, які може зайняти виконання, тому майнер заздалегідь знатиме, що обчислення займе надмірно велику кількість кроків.
• Зловмисник бачить контракт із кодом у формі на кшталт send(A,contract.storage[A]); contract.storage[A] = 0 і надсилає транзакцію з кількістю газу, достатньою лише для виконання першого кроку, але не другого (тобто здійснюючи виведення, але не дозволяючи балансу зменшитися). Автору контракту не потрібно турбуватися про захист від таких атак, оскільки якщо виконання зупиняється на півдорозі, зміни скасовуються.
• Фінансовий контракт працює шляхом взяття медіани з дев'яти пропрієтарних каналів цін (data feeds) з метою мінімізації ризику. Зловмисник захоплює один із каналів даних, який розроблений так, щоб його можна було змінювати за допомогою механізму виклику змінної адреси, описаного в розділі про DAO, і перетворює його на виконання нескінченного циклу, тим самим намагаючись змусити будь-які спроби затребування коштів із фінансового контракту вичерпати газ. Однак фінансовий контракт може встановити ліміт газу для повідомлення, щоб запобігти цій проблемі.

Альтернативою повноті за Тюрінгом є неповнота за Тюрінгом, де JUMP та JUMPI не існують, і в стеку викликів у будь-який момент часу дозволено існувати лише одній копії кожного контракту. З цією системою описана система комісій та невизначеності щодо ефективності нашого рішення можуть бути непотрібними, оскільки вартість виконання контракту буде обмежена зверху його розміром. Крім того, неповнота за Тюрінгом не є таким уже й великим обмеженням; з усіх прикладів контрактів, які ми розробили внутрішньо, поки що лише один вимагав циклу, і навіть цей цикл можна було б видалити, зробивши 26 повторень однорядкового фрагмента коду. З огляду на серйозні наслідки повноти за Тюрінгом та обмежену користь, чому б просто не мати неповну за Тюрінгом мову? Насправді ж неповнота за Тюрінгом далека від ідеального вирішення проблеми. Щоб зрозуміти чому, розглянемо такі контракти:

C0: call(C1); call(C1);
C1: call(C2); call(C2);
C2: call(C3); call(C3);
...
C49: call(C50); call(C50);
C50: (run one step of a program and record the change in storage)

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

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

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

• 1: Wei
• 10¹²: сабо
• 10¹⁵: фіні
• 10¹⁸: етер

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

Модель емісії буде такою:

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

Довгостроковий темп зростання пропозиції (у відсотках)

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

Двома основними варіантами вибору в наведеній вище моделі є (1) існування та розмір цільового фонду (endowment pool) і (2) існування постійно зростаючої лінійної пропозиції, на відміну від обмеженої пропозиції, як у Біткоїні. Обґрунтування цільового фонду є таким. Якби цільового фонду не існувало, а лінійна емісія зменшилася б до 0,217x для забезпечення такого ж рівня інфляції, то загальна кількість етеру була б на 16,5% меншою, і тому кожна одиниця була б на 19,8% ціннішою. Отже, у стані рівноваги під час продажу було б придбано на 19,8% більше етеру, тому кожна одиниця знову стала б такою ж цінною, як і раніше. Тоді організація також мала б у 1,198 раза більше BTC, які можна вважати розділеними на дві частини: початкові BTC та додаткові 0,198x. Отже, ця ситуація є абсолютно еквівалентною цільовому фонду, але з однією важливою відмінністю: організація володіє виключно BTC, і тому не має стимулу підтримувати вартість одиниці етеру.

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

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

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

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

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

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

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

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

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

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

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

Висновок

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

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

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

Примітки

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

Додаткова література

1. Внутрішня цінність (opens in a new tab)
2. Розумна власність (opens in a new tab)
3. Смарт-контракти (opens in a new tab)
4. B-money (opens in a new tab)
5. Багаторазові докази виконання роботи (opens in a new tab)
6. Безпечні права власності з повноваженнями власника (opens in a new tab)
7. Біла книга Біткоїна (opens in a new tab)
8. Namecoin (opens in a new tab)
9. Трикутник Зуко (opens in a new tab)
10. Біла книга кольорових монет (opens in a new tab)
11. Біла книга Mastercoin (opens in a new tab)
12. Децентралізовані автономні корпорації, Bitcoin Magazine (opens in a new tab)
13. Спрощена верифікація платежів (opens in a new tab)
14. Дерева Меркла (opens in a new tab)
15. Дерева Патриції (opens in a new tab)
16. GHOST (opens in a new tab)
17. StorJ та автономні агенти, Джефф Гарзік (opens in a new tab)
18. Майк Хірн про розумну власність на Turing Festival (opens in a new tab)
19. RLP Етеріума
20. Дерева Меркла-Патриції в Етеріумі
21. Пітер Тодд про дерева сум Меркла (opens in a new tab)

Історію білої книги дивіться на цій вікі-сторінці (opens in a new tab).

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