Автор оригинала: Виталик

Оригинальный сборник: Дэн Тонг, Golden Finance

Пока я сижу здесь и пишу это в последний день Ethereum Developer Interop в Кении, мы добились большого прогресса во внедрении и доработке технических деталей важных предстоящих улучшений Ethereum, в первую очередь PeerDAS, перехода дерева Verkle и децентрализованных методов хранения истории. в контексте EIP 4444. С моей точки зрения, темпы развития Ethereum и наша способность предоставлять крупные и важные функции, которые значительно улучшают работу операторов узлов и пользователей (L1 и L2), постоянно растут.

Команда клиентов Ethereum работает вместе над созданием Pectra devnet.

Учитывая рост технологических возможностей, возникает важный вопрос: движемся ли мы к правильным целям? Недавняя серия недовольных твитов от давнего разработчика ядра Geth Питера Силадьи заставила нас задуматься об этом:

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

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

Зависимости MEV и строителя

Раньше блоки Ethereum создавались майнерами, которые использовали относительно простые алгоритмы для создания блоков. Пользователи отправляют транзакции в общедоступную p2p-сеть, часто называемую «мемпулом» (или «txpool»). Майнеры прослушивают мемпул, принимают действительные транзакции и платят комиссию. Они включают в себя транзакции, которые можно совершить, и если места недостаточно, они располагаются в порядке наибольшей комиссии.

Это очень простая система, подходящая для децентрализации: как майнер, вы просто запускаете программное обеспечение по умолчанию и получаете тот же уровень комиссионного дохода от блока, что и от высокопрофессиональной майнинговой фермы. Однако примерно в 2020 году люди начали пользоваться преимуществами так называемой извлекаемой майнерами ценности (MEV): дохода, который можно получить только путем реализации сложных стратегий, которые понимают действия, происходящие внутри различных протоколов defi.

Например, рассмотрим децентрализованную биржу, такую ​​как Uniswap. Предположим, что в момент времени T обменный курс USD/ETH на централизованных биржах и Uniswap составляет 3000 долларов США. В Т+11 курс доллара США к ETH на централизованной бирже вырос до 3005 долларов США. Но у Эфириума пока нет следующего блока. Ко времени Т+12 это действительно так. Кто бы ни создал блок, его первой транзакцией может стать серия покупок Uniswap для покупки всего ETH, доступного на Uniswap, по цене от 3000 до 3004 долларов США. Это дополнительный доход, называемый MEV. Приложения, отличные от DEX, имеют аналогичные проблемы. В документе Flash Boys 2.0, опубликованном в 2019 году, это подробно описано.

Диаграмма в статье Flash Boys 2.0 показывает сумму дохода, которую можно получить, используя каждый из вышеперечисленных методов.

Проблема в том, что это разрушает причину, по которой майнинг (или предложения блоков после 2022 года) может быть «справедливым»: теперь крупные игроки с лучшими способностями оптимизировать такие алгоритмы добычи могут получать больше в каждом блоке. Хорошая прибыль.

С тех пор продолжаются дебаты между двумя стратегиями, которые я называю минимизацией MEV и изоляцией MEV. Минимизация MEV осуществляется в двух формах: (i) активная разработка альтернатив Uniswap без MEV (например, Cowswap) и (ii) создание внутрипротокольных технологий, таких как пулы криптографической памяти, которые сокращают объем информации, доступной для производителей блоков, тем самым снижая их доходы. что можно получить. В частности, зашифрованные мемпулы предотвращают такие стратегии, как сэндвич-атаки, при которых транзакции размещаются до и после пользовательских транзакций, чтобы использовать их с экономической точки зрения («предварительный запуск»).

Сегрегация MEV работает, принимая MEV, но пытаясь ограничить его влияние на централизацию ставок путем разделения рынка на два типа участников: валидаторы несут ответственность за подтверждение и предложение блоков, но задача выбора содержимого блока осуществляется через протокол аукциона. Отдельным стейкерам теперь больше не нужно самим беспокоиться об оптимизации арбитража DeFi; они просто присоединяются к протоколу аукциона и принимают самую высокую ставку. Это называется разделением предлагающего/строителя (PBS). Этот подход имеет прецеденты в других отраслях: одна из основных причин, по которой ресторанам удается оставаться настолько децентрализованными, заключается в том, что они склонны полагаться на довольно централизованную группу поставщиков для своих различных операций, что действительно дает огромную экономию за счет масштаба. На данный момент PBS довольно успешно обеспечивает равные условия для малых и крупных валидаторов, по крайней мере, в том, что касается MEV. Однако это создает еще одну проблему: задача выбора того, какие транзакции включать, становится более централизованной.

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

Если разработчик имеет право полностью исключить транзакции из блока, атаки могут легко произойти. Допустим, у вас есть обеспеченная долговая позиция (CDP) в протоколе defi, обеспеченная активом, цена которого быстро падает. Вы хотите добавить залог или выйти из CDP. Злоумышленники могут попытаться вступить в сговор, чтобы отклонить сделки, в которых участвуете вы, откладывая сделки до тех пор, пока цена не упадет настолько, чтобы вызвать ликвидацию вашего CDP. Если это произойдет, вам придется заплатить солидный штраф, а застройщику достанется большая часть. Так как же нам помешать разработчикам исключать транзакции и совершать атаки такого типа?

Здесь на помощь приходят включенные списки.

Источник: ethresear.ch

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

MEV — сложная проблема, даже в приведенном выше описании упущены многие важные нюансы. Как говорится: «Возможно, вы не ищете MEV, но MEV ищет вас». Исследователи Ethereum очень последовательно работают над достижением цели «минимального сдерживания», минимизируя вред, который могут нанести разработчики (например, исключая или задерживая транзакции как способ атаки на конкретное приложение).

Тем не менее, я думаю, мы можем пойти дальше. Исторически списки включения часто считались «особенностью особого случая»: обычно вы о них не задумывались, но если злонамеренный сборщик начнет делать сумасшедшие вещи, они дадут вам «второй путь». Такое отношение отражено в текущих проектных решениях: в текущем EIP лимит газа для списков включения составляет примерно 2,1 миллиона. Но мы можем внести философский сдвиг в то, как мы думаем о списках включения: думать о списках включения как о блоках, а о роли строителя как о вспомогательной функции, которая добавляет некоторые транзакции для сбора MEV. Что делать, если у застройщика лимит газа в 2,1 миллиона?

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

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

Ставка на ликвидность

Сегодня отдельные стейкеры составляют относительно небольшой процент всех ставок Ethereum, и большая часть ставок осуществляется различными провайдерами — некоторыми централизованными операторами и другими DAO, такими как Lido и RocketPool.

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

Подавляющее большинство людей, которые не делают ставки индивидуально, называют основной причиной минимум 32 ETH.

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

Потеря мгновенной доступности ETH, риски безопасности, связанные с «горячими» закрытыми ключами, а также потеря возможности одновременного участия в протоколах DeFi — все это важные, но более мелкие проблемы.

Опрос Farcaster выявил основные причины, по которым люди не делают ставки индивидуально.

Исследование ставок должно ответить на два ключевых вопроса:

Как нам решить эти проблемы?

Несмотря на то, что существуют действенные решения большинства проблем, если большинство людей по-прежнему не хотят делать ставки в одиночку, как мы можем, несмотря на это, сохранить протокол стабильным и устойчивым к атакам?

Многие текущие проекты исследований и разработок направлены именно на решение этих проблем:

Деревья Веркла в сочетании с EIP-4444 позволяют узлам размещения работать с очень низкими требованиями к жесткому диску. Кроме того, они позволяют практически мгновенно синхронизировать узлы ставок, что значительно упрощает такие вещи, как настройка и переключение с одной реализации на другую. Они также делают легкие клиенты Ethereum более жизнеспособными за счет уменьшения пропускной способности данных, необходимой для предоставления доказательств доступа к каждому состоянию.

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

Несмотря на растущую историю, постоянная оптимизация клиента Ethereum продолжает снижать стоимость и сложность запуска узла валидатора.

Исследование пределов штрафов может снять опасения по поводу риска приватного ключа и позволить заинтересованным сторонам одновременно размещать свои ETH в протоколах DeFi, если они того пожелают.

0x 01 Сертификат вывода позволяет стейкеру установить адрес ETH в качестве адреса вывода. Это делает децентрализованные пулы ставок более осуществимыми, давая им преимущество перед централизованными пулами ставок.

Однако мы еще можем сделать больше. Валидаторам теоретически можно разрешить вывод средств быстрее: даже если набор валидаторов меняется на несколько процентных пунктов каждый раз при его финализации (т. е. один раз в эпоху), Casper FFG все равно будет в безопасности. Так что, если мы будем усердно работать, мы сможем значительно сократить цикл. Если бы мы хотели значительно уменьшить минимальный размер депозита, нам пришлось бы принять трудное решение пойти на компромисс в других направлениях. Например, если мы увеличим время финализации в 4 раза, то минимальный размер депозита уменьшится в 4 раза. Финализация с одним слотом позже решит эту проблему, полностью выйдя за рамки модели «каждый участник участвует в каждой эпохе».

Еще одной важной частью всего этого вопроса является экономика ставок. Ключевой вопрос: хотим ли мы, чтобы стейкинг стал относительно нишевым видом деятельности, или мы хотим, чтобы каждый или почти каждый ставил на стейкинг весь свой ETH? Если все делают ставки, какую ответственность мы хотим, чтобы каждый нес? Если люди в конечном итоге просто делегируют обязанности из-за лени, это в конечном итоге может привести к централизации. Здесь возникают важные и глубокие философские вопросы. Неправильный ответ может привести Ethereum по пути централизации и «воссоздать традиционную финансовую систему с помощью дополнительных шагов», правильный ответ может создать яркий пример успешной экосистемы с широкими и разнообразными независимыми заинтересованными сторонами и высоко децентрализованным пулом ставок; Эти проблемы затрагивают основную экономику и ценности Эфириума, поэтому нам необходимо более разнообразное участие.

Требования к оборудованию узла

Многие из ключевых проблем, связанных с децентрализацией Ethereum, в конечном итоге сводятся к одному вопросу, который определил десятилетие блокчейна: насколько легко мы хотим запускать узлы и как нам это сделать?

В наши дни запустить узел сложно. Большинство людей этого не делают. На ноутбуке, который я использую для написания этой статьи, есть reth-узел, занимающий 2,1 ТБ — уже результат героической разработки и оптимизации программного обеспечения. Мне нужно приобрести дополнительный жесткий диск емкостью 4 ТБ и установить его в ноутбук для хранения узла. Мы все хотим упростить работу узлов. В моем идеальном мире люди могли бы запускать узлы на своих телефонах.

Как я писал выше, EIP-4444 и деревья Веркла — две ключевые технологии, приближающие нас к этому идеалу. Если оба варианта будут реализованы, требования к оборудованию узла могут в конечном итоге снизиться до менее ста гигабайт или ближе к нулю, если мы полностью снимем ответственность за хранение истории (вероятно, только для узлов, не участвующих в стейкинге). ZK-EVM типа 1 избавит от необходимости самостоятельно выполнять расчеты EVM, поскольку вы сможете просто проверить подтверждение правильности выполнения. В моем идеальном мире мы объединяем все эти технологии вместе, и даже кошельки расширений браузера Ethereum (например, Metamask, Rabby) имеют встроенный узел для проверки этих доказательств, выборки доступности данных и проверки правильности цепочки.

Это видение часто называют «Грани».

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

Более свежая версия этой проблемы — дискомфорт, который многие испытывают из-за EIP-4444: если обычным узлам Ethereum больше не нужно хранить старую историю, то кто это делает? Общий ответ таков: должно быть достаточно крупных игроков (например, исследователей блоков, бирж, уровня 2) со стимулом хранить эти данные, а цепочка Ethereum мала по сравнению со 100 петабайтами, хранящимися в Wayback Machine. Поэтому идея о том, что любая история фактически будет потеряна, абсурдна.

Однако этот аргумент опирается на небольшое количество крупных игроков. В моей классификации моделей доверия это предположение 1 из N, но N очень мало. Это имеет свои последствия. Единственное, что мы можем сделать, — это хранить старую историю в одноранговой сети, где каждый узел хранит лишь небольшую часть данных. Такая сеть по-прежнему будет достаточно реплицироваться, чтобы обеспечить надежность: будут существовать тысячи копий каждого фрагмента данных, и в будущем мы сможем использовать стирающее кодирование (фактически, помещая историю в большие двоичные объекты в стиле EIP-4844). встроенное стирающее кодирование) для дальнейшего повышения стабильности.

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

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

Для Stateful и ZK-EVM этот распределенный подход более сложен. Чтобы построить эффективный блок, вам просто нужно иметь полное состояние. В этом случае я лично предпочитаю использовать прагматичный подход: мы определяем и настаиваем на определенном уровне требований к оборудованию, необходимому для наличия «узла, который делает все», который выше, чем у простого узла валидатора (в идеале постоянно снижается). цепи, но все же достаточно низкая, чтобы энтузиасты могли себе это позволить. Мы полагаемся на предположение 1 в N, гарантируя, что N достаточно велико.​

Доказательства ZK-EVM, вероятно, являются самой сложной частью. Доказательства ZK-EVM в реальном времени, вероятно, потребуют более мощного оборудования, чем архивные узлы, даже с такими достижениями, как Binius, и границами наихудшего случая для многомерного газа. Мы могли бы работать над распределенной сетью доказательств, где каждый узел берет на себя ответственность за доказательство, скажем: одного процента выполнения блока, а затем производителю блока нужно собрать только сотню доказательств в конце. Покажите, что совокупные деревья могут помочь еще больше. Но если это не сработает, то другим компромиссом было бы повышение требований к оборудованию для доказательств, но при этом гарантировать, что «узлы, которые делают все это» могут напрямую проверять блоки Ethereum (без доказательств) достаточно быстро, чтобы быть эффективными. Участвуйте в сети.

Подведем итог

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

В то же время я думаю, что важно подчеркнуть, что текущие предложения протокола Ethereum значительно отклонились от этой модели и гораздо более серьезно относятся к необходимости действительно децентрализованной сети. Идеи, касающиеся узлов без сохранения состояния, смягчения последствий MEV, однослотовой окончательности и подобных концепций, пошли дальше в этом направлении. Год назад всерьез рассматривалась идея выборки доступности данных через реле в качестве полуцентрализованных узлов. В этом году нам больше не придется этим заниматься, и PeerDAS добился удивительно значительного прогресса.

Но мы можем многое сделать, чтобы продвинуться дальше в этом направлении по всем трем центральным вопросам, которые я затронул выше, а также по многим другим важным вопросам. Helios добился большого прогресса в создании «настоящего легкого клиента» для Ethereum. Теперь нам нужно включить его по умолчанию в кошельки Ethereum и попросить поставщиков RPC предоставить доказательства и их результаты, чтобы их можно было проверить и распространить технологию легкого клиента на протоколы уровня 2. Если Ethereum масштабируется с помощью дорожной карты, ориентированной на объединение, уровень 2 должен получить те же гарантии безопасности и децентрализации, что и уровень 1. В мире, ориентированном на Rollup, есть много других вещей, к которым нам следует относиться более серьезно; децентрализованный и эффективный мост между L2 — один из многих примеров. Многие децентрализованные приложения получают свои журналы через централизованные протоколы, поскольку встроенное сканирование журналов Ethereum стало слишком медленным. Мы можем улучшить это с помощью специальных децентрализованных подпротоколов. Вот одно из моих предложений о том, как это сделать.

Существует почти бесконечное количество блокчейн-проектов, нацеленных на рынок «мы можем быть очень быстрыми, а о децентрализации подумаем позже». Я не думаю, что Ethereum должен присоединиться к этому движению. Ethereum L1 может и, безусловно, должен быть сильным базовым уровнем для проектов уровня 2, использующих гипермасштабируемый подход и использующих Ethereum в качестве основы децентрализации и безопасности. Даже подход, ориентированный на уровень 2, требует, чтобы сам уровень 1 был достаточно масштабируемым для обработки больших объемов операций. Но мы должны глубоко уважать особенности, которые делают Ethereum уникальными, и продолжать работать над поддержанием и улучшением этих функций по мере масштабирования Ethereum.