История до запуска Эфириума

Автор: Vitalik Buterin

Исходное название: 《Предыстория протокола Ethereum》

Дата публикации: 14 сентября 2017 года

Несмотря на то, что идеи, стоящие за текущим протоколом Ethereum, в основном стабилизировались на протяжении двух лет, Ethereum не появился сразу и не сформировался полностью в текущем концепте. Перед запуском блокчейна протокол прошел через множество значительных разработок и проектных решений. Цель этой статьи — просмотреть различные эволюции протокола с момента его запуска; бесчисленные работы, проведенные по реализации протоколов, таких как Geth, Cppethereum, Pyethereum и Ethereumj, а также история приложений и бизнеса в экосистеме Ethereum, намеренно выходят за рамки.

Также рассматривается история исследований Casper и Sharding. Хотя мы, безусловно, могли бы опубликовать больше блогов, обсуждая все идеи Владa, Гэвина, меня и других, включая "доказательство работы", "радиальные цепи", "гиперкубы", теневые цепи (можно сказать, предшественник Plasma), цепные волокна и различные итерации Casper, и Влад (Vlad) в одном посте, который мы сейчас опустим.

Давайте начнем с самого раннего варианта, который в конечном итоге стал Ethereum, когда его даже не называли Ethereum. Когда я посетил Израиль в октябре 2013 года, я провел много времени с командой Mastercoin и даже предложил им несколько функций. После нескольких размышлений о том, что они делают, я отправил команде предложение сделать протокол более универсальным и поддерживать больше типов контрактов без добавления таких же больших и сложных функций:

https://web.archive.org/web/20150627031414/http://vbuterin.com/ultimatescripting.html

Обратите внимание, что это далеко от более широкой концепции Ethereum, которая позже возникла: это было чисто то, что Mastercoin пытался специально исследовать, а именно контракты между двумя сторонами, где стороны A и B вносят средства, а затем они позже получают средства в соответствии с некоторыми формулами, указанными в контракте (например, ставка может сказать: "если произойдет X, все средства идут к A, иначе все средства идут к B"). Язык сценариев не был завершенным.

Команда Mastercoin была впечатлена, но они не были заинтересованы в том, чтобы отказаться от всего, что они делали, чтобы двигаться в этом направлении, и я все больше убеждался, что это правильный выбор. Таким образом, вот версия 2 от 2 декабря:

https://web.archive.org/web/20131219030753/http://vitalik.ca/ethereum.html

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

Кроме того, обратите внимание, что теперь существует встроенный механизм оплаты:

На этом этапе эфир фактически является газом. После каждого вычислительного шага баланс контракта, требуемый биржей, будет уменьшаться, и если контракт исчерпает средства для выполнения, он остановится. Обратите внимание, что этот механизм "оплата получателем" означает, что контракт сам должен требовать от отправителя оплаты за выполнение контракта и немедленно выходить, если такой оплаты нет; протокол выделяет 16 бесплатных шагов выполнения, чтобы позволить контракту отклонить неоплаченные транзакции.

Это было время, когда протокол Ethereum был полностью моим творением. Однако с этого момента новые участники начали присоединяться к процессу. Наиболее выдающимся аспектом протокола на тот момент был Гэвин Вуд (Gavin Wood), который связался со мной в декабре 2013 года.

Главный разработчик клиента GO Джеффри Уилк (Jeffrey Wilcke) (тогда называвшийся "Ethereal") также вышел на связь примерно в то же время, хотя его вклад больше касался разработки клиента, а не исследований протокола.

"Эй, Джеффри, рад видеть, что ты заинтересован в Ethereum…"

Первоначальный вклад Гэвина был двойным. Во-первых, вы, возможно, заметили, что модель вызова контракта в первоначальном дизайне была асинхронной: хотя контракт A мог создавать "внутренние транзакции" для контракта B (внутренние транзакции — это термин Etherscan; изначально они просто назывались "транзакциями", а затем позже "сообщениями" или "вызовами"), выполнение внутренних транзакций не начиналось до тех пор, пока выполнение первой транзакции не завершится полностью. Это означало, что транзакции не могли использовать внутренние транзакции как способ получения информации из других контрактов; единственным способом был Extro OpCode (что-то вроде того, что вы можете использовать для чтения хранилища других контрактов Sload), который затем был удален с поддержкой Гэвина и других.

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

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

Гэвин также во многом обязан видению о том, чтобы рассматривать Ethereum как платформу для создания программируемых финансов, с контрактами на основе блокчейна, которые могут хранить цифровые активы и передавать их в соответствии с заранее установленными правилами, а затем переходить к универсальной вычислительной платформе. Это началось с тонких изменений в акцентах и терминах, которые позже стали более сильными с увеличением внимания к "Web 3", который рассматривал Ethereum как набор децентрализованных технологий, два других из которых — Whisper и Swarm.

Другие изменения также были предложены примерно в начале 2014 года. После того как идея была предложена Эндрю Миллером (Andrew Miller) и другими, мы в конечном итоге вернулись к стековой архитектуре.

Чарльз Хоскинсон (Charles Hoskinson) предложил перейти с SHA256 биткойна на новый SHA3 (или, точнее, Keccak256). Несмотря на некоторое время споров, обсуждения с Гэвином, Эндрю и другими привели к тому, что было решено, что размер значения на стеке должен быть ограничен 32 байтами. Другой альтернативой, рассматриваемой, были целые числа неограниченного размера, но существовала проблема с тем, чтобы понять, сколько газа, добавления, умножения и других операций.

Первоначальный алгоритм майнинга, который мы придумали, появился еще в январе 2014 года и назывался Dagger:

https://github.com/ethereum/wiki/blob/master/Dagger.md

Dagger назван в честь "направленного ациклического графа" (DAG), математической структуры, используемой в этом алгоритме. Идея заключалась в том, что каждые n блоков новый dag будет генерироваться псевдослучайно из семени, а основа dag будет представлять собой набор узлов, которые требуют нескольких гигабайт для хранения. Однако для генерации любого отдельного значения в DAG требуется вычислить тысячи записей. "Dagger вычисление" включает в себя получение некоторых значений в случайных местах этого базового набора данных, а затем их объединение. Это означает, что существует быстрый способ выполнить Dagger вычисление — данные уже хранятся в памяти, а не в памяти, требующей больших затрат, — от каждого значения, которое вам нужно получить с нуля.

Цель алгоритма заключалась в том, чтобы иметь такие же "памятные" свойства, как и популярные в то время алгоритмы, такие как Scrypt, но при этом оставаться дружелюбным к легким клиентам. Майнеры будут использовать быстрый способ, поэтому их майнинг будет ограничен пропускной способностью памяти (теоретически потребительская RAM уже очень ценится, поэтому сложно оптимизировать его с помощью ASIC), но легкие клиенты могут использовать более медленную версию без памяти для проверки. Быстрый способ может занять несколько микросекунд, а способ без памяти медленно, но без миллисекунд, поэтому для легких клиентов это все равно было очень жизнеспособно.

С этого момента алгоритм будет многократно изменяться в процессе разработки Ethereum. Следующей идеей, которую мы рассмотрели, было "адаптивное доказательство работы". Здесь доказательство работы будет включать выполнение случайно выбранных контрактов Ethereum, и есть умное обоснование, почему это будет устойчиво к ASIC: если будет разработан ASIC, то конкурирующие майнеры будут мотивированы создавать и публиковать множество контрактов, показывающих, что эти контракты не подходят для выполнения ASIC. Эта история не имеет отношения к чему-то вроде ASIC для общего вычисления, потому что это просто CPU, поэтому мы можем использовать этот механизм противодействия для создания по сути доказательства работы, выполняющего общее вычисление.

Причина, по которой это провалилось, проста: удаленные атаки. Атакующий может начать цепочку с блока 1, заполнив ее простыми контрактами, для которых они могут создать специализированное оборудование, и быстро обогнать основную цепь. Так что… вернемся к чертежной доске.

Следующий алгоритм называется "случайные цепи", описанный в этом документе Google, предложенном мной и Владом Замфиром (Vlad Zamfir), и проанализированном такими, как Мэтью Уэмплер-Доти. Идея здесь также заключалась в том, чтобы смоделировать общее вычисление в алгоритме майнинга, на этот раз путем выполнения случайно сгенерированных цепей. Ничего сложного в доказательстве не было, основанном на этих принципах, но компьютерные эксперты, с которыми мы связывались в 2014 году, часто были очень пессимистичны по этому поводу. Сам Мэтью Уэмплер-Доти предложил основанное на SAT решение для доказательства работы, но в конечном итоге оно также было отклонено.

В конце концов, мы завершили цепь с алгоритмом, называемым "Dagger Hashimoto". "dashimoto" иногда называют "dashimoto", заимствовав многие идеи из hashimoto, Hashimoto — это алгоритм доказательства работы Таддеуса Дрйи (Thaddeus Dryja), который впервые предложил концепцию "доказательства работы I/O", где основным ограничивающим фактором скорости майнинга является не количество хешей в секунду, а большой диапазон доступа к RAM в секунду. Однако он сочетал это с набором данных, сгенерированным DAG, дружелюбным к легким клиентам Dagger. После того, как я сам провел множество корректировок, Мэтью, Тим и другие, эти идеи наконец объединились в алгоритм, который мы сейчас называем ethash.

К лету 2014 года протокол значительно стабилизировался, и, кроме алгоритма доказательства работы, протокол не достиг стадии Ethash до начала 2015 года и существовал в полупрофессиональной спецификации в виде жёлтой книги Гэвина.

В августе 2014 года я разработал и представил механизм дяди, который обеспечивал более короткое время блока и большую пропускную способность для блокчейна Ethereum, одновременно снижая риски централизации. Это было введено как часть POC6.

Обсуждения с командой Bitshares привели нас к рассмотрению добавления стека в качестве первоклассной структуры данных, хотя из-за нехватки времени мы в конечном итоге этого не сделали, а последующие проверки безопасности и атаки DOS показали, что на самом деле это было гораздо сложнее, чем мы думали, когда мы думали о безопасном выполнении этого.

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

Также были рассмотрены другие идеи, такие как создание дерева Меркла из всего следа выполнения транзакции, чтобы доказать что-либо. Выбор журналов был сделан из-за компромисса между простотой и полнотой.

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

Гэвин также был ключевым первоначальным голосом в разработке концепции "абстракции протокола" — перемещения многих частей протокола, таких как баланс эфира, алгоритм подписи транзакций, nonce и т. д., как контракты сами по себе, с теоретической конечной целью, чтобы весь протокол Ethereum можно было описать как ситуацию, когда функции вызываются в виртуальной машине с некоторым исходным состоянием. Эти идеи не получили достаточно времени, чтобы войти в первоначальную передовую версию, но ожидалось, что принципы начнут медленно интегрироваться через некоторые изменения Константинополя, контракты Casper и спецификации шардирования.

Все это было реализовано в POC7; после POC7 протокол не претерпел значительных изменений, кроме незначительных, хотя в некоторых случаях важные, детали, которые будут получены в результате проверки безопасности…

В начале 2015 года Ютта Штайнер (Jutta Steiner) и другие организовали предвыпускной аудит безопасности, который включал в себя проверку программного кода и академическую проверку. Программный аудит в основном проводился Гэвином Вудом и Джеффри Уилком, которые руководили реализацией на C++ и GO, хотя в моей реализации Pyethereum также был небольшой аудит. В двух этих академических проверках одна была проведена Иттаем Эялем (Ittay Eyal, ставшим известным благодаря "эгоистичному майнингу"), а другая — Эндрю Миллером и другими с минимальными полномочиями. Аудит EYAL привел к небольшим изменениям в протоколе: общая сложность цепи не включала дяди. Аудит с минимальными полномочиями сосредоточился на смарт-контрактах и экономике газа, а также на дереве Патриции. Этот аудит привел к нескольким изменениям в протоколе. Одним из небольших изменений было использование sha3(addr) и sha3(key) в качестве ключей trie, а не прямых адресов и ключей; это сделало бы наиболее грубые атаки на Trie более сложными.

Предупреждение может быть немного слишком далеко от своего времени…

Еще одной важной темой, которую мы обсуждали, был механизм голосования по ограничению газа. В то время мы уже беспокоились о недостатке прогресса в дебатах о размере биткойна и хотели иметь более гибкий дизайн в Ethereum, который можно было бы корректировать по мере необходимости с течением времени. Но проблема заключалась в следующем: каков оптимальный лимит? Моя первоначальная идея заключалась в том, чтобы установить динамический лимит, основанный на долгосрочном экспоненциальном скользящем среднем фактического использования газа, так что в долгосрочной перспективе средний блок будет полным. Однако Эндрю, который в некоторых отношениях был использован, — в частности, майнеры, желающие повысить лимит, будут включать в свои блоки только транзакции, которые потребляют много газа, но требуют мало времени для обработки, поэтому всегда создается целый блок без затрат. Таким образом, по крайней мере в восходящем направлении, модель безопасности была довольно близка к тому, чтобы просто позволить майнерам голосовать за лимит газа.

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

После небольшого черного марафона между Гэвином, Джеффом и мной, POC9 был запущен в марте и предназначался для того, чтобы стать окончательным доказательством концепции. Используя схему, предназначенную для использования в Livenet, и установив долгосрочный план Ethereum, использовалась тестовая сеть, работающая в течение четырех месяцев. Винай Гупта (Vinay Gupta) написал блог "Процесс запуска Ethereum", в котором описал четыре ожидаемых этапа разработки Ethereum Livenet и дал им текущие названия: Frontier, Homestead, Mesropolis и Serenity.

Хакатон длился четыре месяца. В первые два месяца было обнаружено множество ошибок в различных реализациях, произошли сбои консенсуса и другие проблемы, но к июню сеть явно стабилизировалась. В июле было решено заморозить код, а затем выпустить релиз, который состоялся 30 июля.