Виталик Новая статья: Улучшение безразрешительной и децентрализованной будущности сети Ethereum

Автор：Vitalik Buterin

Составлено: Дэн Тонг, Золотая Финансовая Газета

Особая благодарность Dankrad Feist, Caspar Schwarz-Schilling и Francesco за быструю обратную связь и рецензию.

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

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

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

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

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

MEV и зависимость от строителей

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

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

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

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

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

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

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

Мое мнение всегда было таковым: минимизация MEV - это хорошо, и мы должны стремиться к этому (я лично часто использую Cowswap!) ------ хотя криптографическая память имеет много проблем, минимизация MEV может быть недостаточной; 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 показывает основные причины, по которым люди не занимаются отдельным стейкингом.

Исследования стейкинга необходимо решить две ключевые проблемы:

Как мы можем решить эти опасения?

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

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

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

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

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

Исследования пределов наказаний могут уменьшить опасения по поводу рисков приватных ключей и позволить стейкерам одновременно ставить свои ETH в DeFi-протоколы (если они этого хотят).

Токены вывода 0x01 позволяют стейкерам установить адрес ETH для вывода. Это делает децентрализованные пулы стейкинга более жизнеспособными, предоставляя им преимущества по сравнению с централизованными пулами.

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

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

Аппаратные требования к узлам

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

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

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

Эта вышеописанная концепция обычно называется "The Verge".

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

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

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

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

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

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

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

Резюме

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

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

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

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