Белая книга Эфириума

Несмотря на то, что этому документу уже несколько лет, мы сохраняем оригинальный текст ниже, поскольку он продолжает служить полезным справочным материалом и точным отражением Эфириума и его видения.

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

Создание Биткоина Сатоши Накамото в 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) Вэя Дая (Wei Dai) стало первым предложением, в котором была представлена идея создания денег путем решения вычислительных головоломок, а также децентрализованного консенсуса, но в этом предложении было мало деталей о том, как децентрализованный консенсус может быть реализован на практике. В 2005 году Хэл Финни представил концепцию «многоразовых доказательств выполнения работы (opens in a new tab)» — систему, которая использует идеи из b-money вместе с вычислительно сложными головоломками Hashcash Адама Бэка для создания концепции криптовалюты, но она снова оказалась далека от идеала, полагаясь на доверенные вычисления в качестве бэкенда. В 2009 году децентрализованная валюта была впервые реализована на практике Сатоши Накамото, объединив устоявшиеся примитивы для управления владением с помощью криптографии с открытым ключом с алгоритмом консенсуса для отслеживания того, кому принадлежат монеты, известным как «доказательство выполнения работы (PoW)».

Механизм, лежащий в основе доказательства выполнения работы (PoW), стал прорывом в этой области, поскольку он одновременно решил две проблемы. Во-первых, он предоставил простой и умеренно эффективный алгоритм консенсуса, позволяющий узлам в сети коллективно согласовывать набор канонических обновлений состояния реестра Биткоина. Во-вторых, он предоставил механизм, обеспечивающий свободный вход в процесс консенсуса, решая политическую проблему определения того, кто получает право влиять на консенсус, и одновременно предотвращая атаки Сивиллы. Это делается путем замены формального барьера для участия, такого как требование быть зарегистрированным в качестве уникального субъекта в определенном списке, экономическим барьером — вес одного узла в процессе голосования за консенсус прямо пропорционален вычислительной мощности, которую предоставляет этот узел. С тех пор был предложен альтернативный подход, называемый доказательством доли владения (PoS), при котором вес узла рассчитывается пропорционально его валютным запасам, а не вычислительным ресурсам; обсуждение относительных достоинств этих двух подходов выходит за рамки данной белой книги, но следует отметить, что оба подхода могут использоваться в качестве основы криптовалюты.

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

С технической точки зрения реестр криптовалюты, такой как Биткоин, можно рассматривать как систему переходов состояний, где есть «состояние», состоящее из статуса владения всеми существующими биткоинами, и «функция перехода состояния», которая принимает состояние и транзакцию и выводит новое состояние, которое является результатом. В стандартной банковской системе, например, состояние — это балансовый отчет, транзакция — это запрос на перевод $X от A к B, а функция перехода состояния уменьшает значение на аккаунте A на $X и увеличивает значение на аккаунте B на $X. Если на аккаунте A изначально меньше $X, функция перехода состояния возвращает ошибку. Следовательно, можно формально определить:

APPLY(S,TX) -> S' или 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, но не наоборот.

Единственное условие валидности, присутствующее в приведенном выше списке, которое не встречается в других системах, — это требование «доказательства выполнения работы (PoW)». Точное условие заключается в том, что двойной хеш 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 в качестве родительского, но с новой транзакцией вместо старой. Поскольку данные блока отличаются, это требует повторного выполнения доказательства выполнения работы (PoW). Кроме того, новая версия блока 270000 злоумышленника имеет другой хеш, поэтому исходные блоки с 270001 по 270005 не «указывают» на него; таким образом, исходная цепь и новая цепь злоумышленника полностью разделены. Правило гласит, что при форке самый длинный блокчейн принимается за истину, поэтому легитимные майнеры будут работать над цепью 270005, в то время как злоумышленник в одиночку работает над цепью 270000. Для того чтобы злоумышленник сделал свой блокчейн самым длинным, ему потребовалось бы иметь больше вычислительной мощности, чем у остальной сети вместе взятой, чтобы догнать ее (отсюда и «атака 51%»).

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

Слева: достаточно представить лишь небольшое количество узлов в дереве Меркла, чтобы предоставить доказательство валидности ветви.

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

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

Протокол дерева Меркла, возможно, имеет важное значение для долгосрочной устойчивости. «Полный узел» в сети Биткоин, который хранит и обрабатывает каждый блок целиком, по состоянию на апрель 2014 года занимает около 15 ГБ дискового пространства в сети Биткоин и растет более чем на гигабайт в месяц. В настоящее время это жизнеспособно для некоторых настольных компьютеров, но не для телефонов, а в будущем участвовать смогут только предприятия и энтузиасты. Протокол, известный как «упрощенная верификация платежей» (SPV), позволяет существовать другому классу узлов, называемых «легкими нодами», которые загружают заголовки блоков, проверяют доказательство выполнения работы (PoW) в заголовках блоков, а затем загружают только «ветви», связанные с транзакциями, которые к ним относятся. Это позволяет легким нодам с надежной гарантией безопасности определять статус любой транзакции Биткоина и свой текущий баланс, загружая при этом лишь очень небольшую часть всего блокчейна.

Альтернативные применения блокчейна

Идея взять за основу идею блокчейна и применить ее к другим концепциям также имеет долгую историю. В 2005 году Ник Сабо (Nick Szabo) выступил с концепцией «безопасных прав собственности с полномочиями владельца (opens in a new tab)» — документом, описывающим, как «новые достижения в технологии реплицируемых баз данных» позволят создать систему на основе блокчейна для хранения реестра того, кому принадлежит какая земля, создавая сложную структуру, включающую такие концепции, как гомстединг, приобретательная давность и георгианский земельный налог. Однако, к сожалению, в то время не было доступной эффективной системы реплицируемых баз данных, и поэтому протокол так и не был реализован на практике. Однако после 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 слепы к данным блокчейна, таким как нонс, временная метка и хеш предыдущего блока. Это серьезно ограничивает приложения в сфере азартных игр и нескольких других категориях, лишая язык скриптов потенциально ценного источника случайности.

Таким образом, мы видим три подхода к созданию продвинутых приложений поверх криптовалюты: создание нового блокчейна, использование скриптов поверх Биткоина и создание метапротокола поверх Биткоина. Создание нового блокчейна дает неограниченную свободу в создании набора функций, но ценой времени на разработку, усилий по запуску и безопасности. Использование скриптов легко реализовать и стандартизировать, но оно очень ограничено в своих возможностях, а метапротоколы, хотя и просты, страдают от недостатков масштабируемости. С помощью Эфириума мы намерены создать альтернативный фреймворк, который обеспечивает еще больший выигрыш в простоте разработки, а также еще более сильные свойства легкого клиента, в то же время позволяя приложениям совместно использовать экономическую среду и безопасность блокчейна.

Эфириум

Цель Эфириума — создать альтернативный протокол для разработки децентрализованных приложений (dapp), предоставляя другой набор компромиссов, который, как мы полагаем, будет очень полезен для большого класса децентрализованных приложений, с особым акцентом на ситуации, где важны быстрое время разработки, безопасность для небольших и редко используемых приложений, а также способность различных приложений очень эффективно взаимодействовать друг с другом. Эфириум делает это путем создания того, что по сути является идеальным абстрактным базовым слоем: блокчейна со встроенным полным по Тьюрингу языком программирования, позволяющим любому писать смарт-контракты и децентрализованные приложения, в которых они могут создавать свои собственные произвольные правила владения, форматы транзакций и функции перехода состояния. Базовую версию Namecoin можно написать в двух строках кода, а другие протоколы, такие как валюты и системы репутации, можно создать менее чем в двадцати. Смарт-контракты, криптографические «ящики», которые содержат ценность и разблокируют ее только при выполнении определенных условий, также могут быть созданы поверх платформы, обладая значительно большей мощностью, чем та, что предлагается скриптами Биткоина, благодаря добавленным возможностям полноты по Тьюрингу, осведомленности о ценности, осведомленности о блокчейне и состояния.

Аккаунты Эфириума

В Эфириуме состояние состоит из объектов, называемых «аккаунтами», при этом каждый аккаунт имеет 20-байтовый адрес, а переходы состояния представляют собой прямые переводы ценности и информации между аккаунтами. Аккаунт Эфириума содержит четыре поля:

• Нонс, счетчик, используемый для того, чтобы каждая транзакция могла быть обработана только один раз
• Текущий баланс эфира аккаунта
• Код контракта аккаунта, если он присутствует
• Хранилище аккаунта (пустое по умолчанию)

«Эфир» — это основное внутреннее криптотопливо Эфириума, которое используется для оплаты комиссий за транзакции. В целом, существует два типа аккаунтов: внешне принадлежащие аккаунты, контролируемые приватными ключами, и контрактные аккаунты, контролируемые их кодом контракта. Внешне принадлежащий аккаунт не имеет кода, и можно отправлять сообщения с внешне принадлежащего аккаунта путем создания и подписания транзакции; в контрактном аккаунте каждый раз, когда контрактный аккаунт получает сообщение, его код активируется, позволяя ему читать и писать во внутреннее хранилище, а также отправлять другие сообщения или создавать контракты в свою очередь.

Обратите внимание, что «контракты» в Эфириуме не следует рассматривать как нечто, что должно быть «выполнено» или «соблюдено»; скорее, они больше похожи на «автономных агентов», которые живут внутри среды выполнения Эфириума, всегда выполняя определенный фрагмент кода при «подталкивании» сообщением или транзакцией, и имея прямой контроль над своим собственным балансом эфира и собственным хранилищем пар ключ/значение для отслеживания постоянных переменных.

Сообщения и транзакции

Термин «транзакция» используется в Эфириуме для обозначения подписанного пакета данных, который хранит сообщение для отправки с внешне принадлежащего аккаунта. Транзакции содержат:

• Получателя сообщения
• Подпись, идентифицирующую отправителя
• Количество эфира для перевода от отправителя к получателю
• Необязательное поле данных
• Значение STARTGAS, представляющее максимальное количество вычислительных шагов, которое разрешено выполнить при выполнении транзакции
• Значение GASPRICE, представляющее комиссию, которую отправитель платит за каждый вычислительный шаг

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

Поля STARTGAS и GASPRICE имеют решающее значение для модели защиты Эфириума от отказа в обслуживании. Чтобы предотвратить случайные или враждебные бесконечные циклы или другие вычислительные потери в коде, каждая транзакция должна устанавливать лимит на то, сколько вычислительных шагов выполнения кода она может использовать. Фундаментальной единицей вычислений является «газ»; обычно вычислительный шаг стоит 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-компиляции, базовая реализация Эфириума может быть выполнена в нескольких сотнях строк кода.

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

Блокчейн Эфириума во многом похож на блокчейн Биткоина, хотя у него есть некоторые отличия. Главное отличие Эфириума от Биткоина в отношении архитектуры блокчейна заключается в том, что, в отличие от Биткоина, блоки Эфириума содержат копию как списка транзакций, так и самого последнего состояния. Помимо этого, в блоке также хранятся два других значения: номер блока и сложность. Базовый алгоритм валидации блока в Эфириуме выглядит следующим образом:

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 корню конечного состояния, указанному в заголовке блока. Если да, блок действителен; в противном случае он недействителен.

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

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

Приложения

В целом, поверх Эфириума существует три типа приложений. Первая категория — это финансовые приложения, предоставляющие пользователям более мощные способы управления своими деньгами и заключения контрактов с их использованием. Сюда входят субвалюты, финансовые деривативы, контракты хеджирования, сберегательные кошельки, завещания и, в конечном счете, даже некоторые классы полномасштабных трудовых контрактов. Вторая категория — это полуфинансовые приложения, где задействованы деньги, но также присутствует весомая немонетарная сторона того, что делается; отличным примером являются самоисполняемые вознаграждения за решения вычислительных задач. Наконец, существуют такие приложения, как онлайн-голосование и децентрализованное управление, которые вообще не являются финансовыми.

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

Системы токенов в блокчейне имеют множество применений: от субвалют, представляющих такие активы, как доллары США или золото, до акций компаний, индивидуальных токенов, представляющих умную собственность, защищенных от подделки купонов и даже систем токенов, вообще не привязанных к традиционной ценности, используемых в качестве систем баллов для стимулирования. Системы токенов удивительно легко реализовать в Эфириуме. Ключевой момент, который необходимо понять, заключается в том, что любая валюта или система токенов по своей сути — это база данных с одной операцией: вычесть 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. Самый простой способ сделать это — использовать контракт «ценового фида», поддерживаемый определенной стороной (например, NASDAQ), разработанный таким образом, чтобы эта сторона имела возможность обновлять контракт по мере необходимости, и предоставляющий интерфейс, который позволяет другим контрактам отправлять сообщение этому контракту и получать в ответ цену.

При наличии этого критически важного компонента контракт хеджирования выглядел бы следующим образом:

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

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

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

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

Самая ранняя альтернативная криптовалюта из всех, Namecoin (opens in a new tab), попыталась использовать блокчейн, подобный Биткоину, для создания системы регистрации имен, где пользователи могут регистрировать свои имена в публичной базе данных наряду с другими данными. Основным упоминаемым вариантом использования является система DNS (opens in a new tab), сопоставляющая доменные имена, такие как «bitcoin.org» (или, в случае Namecoin, «bitcoin.bit»), с IP-адресом. Другие варианты использования включают аутентификацию электронной почты и, потенциально, более продвинутые системы репутации. Вот базовый контракт для обеспечения системы регистрации имен, подобной Namecoin, в Эфириуме:

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

Контракт очень прост; все, что он собой представляет, — это база данных внутри сети Эфириум, в которую можно добавлять данные, но нельзя изменять или удалять их. Любой может зарегистрировать имя с некоторым значением, и эта регистрация затем сохраняется навсегда. Более сложный контракт регистрации имен также будет иметь «функциональное условие», позволяющее другим контрактам запрашивать его, а также механизм для «владельца» (т. е. первого зарегистрировавшего) имени для изменения данных или перевода права собственности. Поверх этого можно даже добавить функциональность репутации и сети доверия.

Децентрализованное хранение файлов

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

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

Важной особенностью протокола является то, что, хотя может показаться, будто вы доверяете множеству случайных узлов в том, что они не решат забыть файл, этот риск можно свести почти к нулю, разделив файл на множество частей с помощью разделения секрета и наблюдая за контрактами, чтобы убедиться, что каждая часть все еще находится во владении какого-либо узла. Если контракт все еще выплачивает деньги, это служит криптографическим доказательством того, что кто-то где-то все еще хранит файл.

Децентрализованные автономные организации

Общая концепция «децентрализованной автономной организации» (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. Децентрализованный фид данных. Для финансовых контрактов на разницу цен (CFD) на самом деле может быть возможно децентрализовать фид данных с помощью протокола под названием «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 решает первую проблему потери безопасности сети путем включения устаревших блоков в расчет того, какая цепь является «самой длинной». То есть в расчет того, какой блок имеет наибольшее суммарное доказательство выполнения работы (PoW), добавляются не только родительский блок и более далекие предки блока, но и устаревшие потомки предка блока (на жаргоне Эфириума — «дяди» или uncles). Чтобы решить вторую проблему, связанную со склонностью к централизации, мы выходим за рамки протокола, описанного Сомполинским и Зохаром, и также предоставляем вознаграждение за блок для устаревших блоков: устаревший блок получает 87,5% от своего базового вознаграждения, а племянник, который включает устаревший блок, получает оставшиеся 12,5%. Однако комиссия за транзакцию дядям не присуждается.

Эфириум реализует упрощенную версию GHOST, которая опускается только на семь уровней. В частности, она определяется следующим образом:

• Блок должен указывать родителя, и он должен указывать 0 или более дядей.
• Дядя, включенный в блок B, должен обладать следующими свойствами:
  • Он должен быть прямым потомком предка B в k-м поколении, где 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 позволяет создавать циклы двумя способами. Во-первых, существует инструкция JUMP, которая позволяет программе возвращаться к предыдущему месту в коде, и инструкция JUMPI для выполнения условного перехода, что позволяет использовать такие операторы, как while x < 27: x = x * 2. Во-вторых, контракты могут вызывать другие контракты, что потенциально позволяет создавать циклы с помощью рекурсии. Это естественно приводит к проблеме: могут ли злоумышленники по сути отключить майнеров и полные узлы, заставив их войти в бесконечный цикл? Эта проблема возникает из-за задачи в информатике, известной как проблема остановки: в общем случае невозможно определить, остановится ли когда-нибудь данная программа.

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

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

Альтернативой полноте по Тьюрингу является неполнота по Тьюрингу, где JUMP и JUMPI не существуют, и в стеке вызовов в любой момент времени может находиться только одна копия каждого контракта. При такой системе описанная система комиссий и неопределенности вокруг эффективности нашего решения могли бы не понадобиться, поскольку стоимость выполнения контракта была бы ограничена сверху его размером. Кроме того, неполнота по Тьюрингу не является таким уж большим ограничением; из всех примеров контрактов, которые мы придумали внутри компании, пока только один требовал цикла, и даже этот цикл можно было бы удалить, сделав 26 повторений однострочного фрагмента кода. Учитывая серьезные последствия полноты по Тьюрингу и ограниченную выгоду, почему бы просто не использовать неполный по Тьюрингу язык? В реальности, однако, неполнота по Тьюрингу далека от изящного решения проблемы. Чтобы понять почему, рассмотрим следующие контракты:

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

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

Валюта и эмиссия

Сеть Эфириум включает в себя собственную встроенную валюту — эфир, которая служит двойной цели: обеспечивает первичный уровень ликвидности для эффективного обмена между различными типами цифровых активов и, что более важно, предоставляет механизм для оплаты комиссий за транзакции. Для удобства и во избежание будущих споров (см. текущие дебаты о mBTC/uBTC/satoshi в Биткоине) номиналы будут предварительно обозначены:

• 1: Wei
• 10¹²: сабо
• 10¹⁵: финни
• 10¹⁸: эфир

Это следует воспринимать как расширенную версию концепции «долларов» и «центов» или «BTC» и «сатоши». В ближайшем будущем мы ожидаем, что «эфир» будет использоваться для обычных транзакций, «финни» — для микротранзакций, а «сабо» и «Wei» — для технических обсуждений вокруг комиссий и реализации протокола; остальные номиналы могут стать полезными позже и на данном этапе не должны включаться в клиенты.

Модель эмиссии будет следующей:

• Эфир будет выпущен в ходе продажи валюты по цене 1000-2000 эфиров за BTC — механизм, предназначенный для финансирования организации Ethereum и оплаты разработки, который с успехом использовался другими платформами, такими как 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 в год. В случае, если организация Ethereum потеряет финансирование или по любой другой причине исчезнет, мы оставляем открытым «социальный контракт»: любой имеет право создать будущую версию-кандидат Эфириума с единственным условием, что количество эфира должно быть не более 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). Легкие ноды не имели бы возможности обнаружить это немедленно. Конечно, по крайней мере один честный полный узел, вероятно, существовал бы, и через несколько часов информация о мошенничестве просочилась бы через такие каналы, как Реддит. Но к тому моменту было бы слишком поздно: обычным пользователям пришлось бы организовывать усилия по занесению данных блоков в черный список, что является масштабной и, вероятно, невыполнимой проблемой координации, сопоставимой по масштабам с успешным проведением атаки 51%. В случае с Биткоином это в настоящее время является проблемой, но существует модификация блокчейна, предложенная Питером Тоддом (Peter Todd) (opens in a new tab), которая смягчит эту проблему.

В ближайшей перспективе Эфириум будет использовать две дополнительные стратегии, чтобы справиться с этой проблемой. Во-первых, из-за алгоритмов майнинга на основе блокчейна по крайней мере каждый майнер будет вынужден быть полным узлом, что создает нижнюю границу количества полных узлов. Во-вторых, и это более важно, мы будем включать корень промежуточного дерева состояний в блокчейн после обработки каждой транзакции. Даже если валидация блока централизована, до тех пор, пока существует один честный проверяющий узел, проблему централизации можно обойти с помощью протокола верификации. Если майнер публикует недействительный блок, этот блок должен быть либо плохо отформатирован, либо состояние S[n] является неверным. Поскольку известно, что S[0] является верным, должно существовать некоторое первое состояние S[i], которое является неверным, в то время как S[i-1] является верным. Проверяющий узел предоставит индекс i вместе с «доказательством недействительности», состоящим из подмножества узлов дерева Патриции, необходимых для обработки APPLY(S[i-1],TX[i]) -> S[i]. Узлы смогут использовать эти узлы для выполнения этой части вычислений и увидеть, что сгенерированное S[i] не совпадает с предоставленным S[i].

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

Заключение

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

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

Примечания и дополнительная литература

Примечания

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

Эфириум, как и многие проекты программного обеспечения с открытым исходным кодом, управляемые сообществом, развивался с момента своего создания. Чтобы узнать о последних разработках Эфириума и о том, как вносятся изменения в протокол, мы рекомендуем это руководство.