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

Команды клиентов Ethereum работают вместе, чтобы запустить Pectra devnet.

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

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

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

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

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

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

Например, рассмотрим децентрализованные биржи, такие как Uniswap. Предположим, что на момент T курс обмена USD/ETH на централизованных биржах и на Uniswap составляет $3000. На момент T+11 курс обмена USD/ETH на централизованных биржах повышается до $3005. Но у Ethereum еще не было следующего блока. На момент T+12 оно появляется. Тот, кто создает блок, может сделать свою первую транзакцию серией покупок на Uniswap, выкупая всю доступную ETH на Uniswap по ценам от $3000 до $3004. Это дополнительный доход и называется MEV. У приложений, отличных от DEXes, есть свои аналоги этой проблемы. Бумага 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)в протоколе децентрализованных финансов, поддерживаемом активом, цена которого стремительно падает, вы хотите либо увеличить залог, либо выйти из CDP. Злоумышленные строители могут попытаться сговориться, чтобы отказаться включать вашу транзакцию, задерживая ее до тех пор, пока цены не упадут достаточно, чтобы они могли принудительно ликвидировать ваш CDP. Если это произойдет, вам придется заплатить крупный штраф, а строители получат значительную долю из него. Так как же мы можем предотвратить строителей от исключения транзакций и осуществления подобных атак?

Вот где включаются списки.

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

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

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

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

Я считаю, что идеи в этом направлении - действительно толкают карантинный ящик быть как можно меньше - действительно интересны, и я за то, чтобы двигаться в этом направлении. Это изменение от «философии эпохи 2021 года»: в философии эпохи 2021 года мы были более восторженны идеей того, что, поскольку у нас теперь есть строители, мы можем «перегружать» их функциональность и заставлять их обслуживать пользователей более сложными способами, например, поддерживаяРынки комиссий ERC-4337. В этой новой философии части проверки транзакций ERC-4337 должны были бы быть закреплены в протоколе. К счастью, команда ERC-4337 уже@yoav/AA-roadmap-May-2024#Native-AA---a-modular-roadmap">увлечение этим направлением становится все более теплым.

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

Ликвидный стейкинг

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

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

1. Большинство людей, которые не занимаются соло-стейкингом, указывают своей основной причиной минимум в 32 ETH.
2. Из тех, кто указывает на другие причины, самая высокая - техническое испытание запуска и поддержания узла валидатора.
3. Потеря мгновенной доступности ETH, риски безопасности "горячих" приватных ключей и потеря возможности одновременного участия в протоколах децентрализованных финансовых услуг являются значительными, но менее важными проблемами.

Основные причины, по которым люди не занимаются соло-стейкингом, согласно опросам Farcaster.

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

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

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

1. Verkle treesплюсEIP-4444позволяют узлам стейкинга функционировать с очень низкими требованиями к жесткому диску. Кроме того, они позволяют узлам стейкинга синхронизироваться практически мгновенно, что значительно упрощает процесс настройки, а также операции, такие как переключение с одной реализации на другую. Они также делают легкие клиенты Ethereum гораздо более жизнеспособными, уменьшая объем данных, необходимых для предоставления доказательств для каждого доступа к состоянию.
2. Исследование (например, эти предложения)для того, чтобы позволить намного более крупный набор валидаторов (обеспечивая гораздо меньшие минимальные ставки), в то же время снижая нагрузку на узлы консенсуса. Эти идеи могут быть реализованы в рамкаходноразовая финальность слота. Делая это, также делает легкие клиенты безопаснее, поскольку они смогут проверить полный набор подписей вместо того, чтобы полагаться на синхронные комитеты).
3. Постоянные оптимизации клиента Ethereum продолжают снижать стоимость и сложность запуска узла валидатора, несмотря на увеличение объема истории.
4. Исследование поштрафы по капитализациивозможно, это смогло бы смягчить опасения относительно риска частного ключа и позволить стейкерам одновременно ставить свои ETH в протоколах децентрализованных финансовых инструментов, если они этого захотят.
5. 0x01 Учетные данные выводапозволяет стейкерам установить адрес ETH в качестве своего адреса для вывода. Это делает децентрализованные пулы стейкинга более жизнеспособными, давая им преимущество перед централизованными пулами стейкинга.

Однако снова есть больше, что мы могли бы сделать. Теоретически возможно разрешить валидаторам выводить средства гораздо быстрее: Casper FFG остается безопасным даже если набор валидаторов меняется на несколько процентов каждый раз, когда он завершает (т. е. один раз за эпоху). Следовательно, мы могли бы сократить период вывода средств еще больше, если бы приложили усилия. Если бы мы хотели значительно снизить минимальный размер депозита, мы могли бы принять трудное решение о компромиссе в других направлениях, например, если бы мы увеличили время окончательности в 4 раза, это позволило бы @VitalikButerin/параметризация-каспера-компромисс-между-децентрализацией-временем-окончательности-и-издержками-3f2011672735">Уменьшение размера минимального депозита в 4 раза. Однократная окончательность слота позже устранила это, перейдя полностью к модели «каждый стейкер участвует в каждой эпохе».

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

Требования к аппаратному обеспечению узлов

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

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

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

Описанное выше видение часто называется "The Verge".

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

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

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

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

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

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

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

Выводы

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

Мы этого не делаем.

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

Но есть еще многое, что мы могли бы сделать, чтобы продвинуться в этом направлении, по всем трем осям, о которых я говорил выше, а также по многим другим важным осям.Гелиоссделал большой прогресс в предоставлении Ethereum «фактического легкого клиента». Теперь нам нужно включить его по умолчанию в кошельки Ethereum, и заставить поставщиков RPC предоставлять доказательства вместе со своими результатами, чтобы их можно было проверить, и расширить технологию легкого клиента на протоколы уровня 2. Если Ethereum масштабируется по схеме, ориентированной на роллапы, протоколы уровня 2 должны получать те же гарантии безопасности и децентрализации, что и уровень 1. В мире, ориентированном на роллапы, есть много других вещей, на которые мы должны обращать больше внимания; децентрализованные и эффективные мосты между уровнями 2 — один из многих примеров. Многие dapp-ы получают свои журналы через централизованные протоколы, так как сканирование журналов Ethereum стало слишком медленным. Мы могли бы улучшить это с помощью специализированного децентрализованного дополнительного протокола;@vbuterin"/parallel_post_state_roots">это одно из моих предложений о том, как это можно сделать.

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

Disclaimer：

1. Эта статья перепечатана из [[Виталик Бутерин]], Все авторские права принадлежат оригинальному автору [Виталик Бутерин]. Если есть возражения к этому перепечатыванию, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно справятся с этим.
2. Ответственность за отказ от ответственности: Взгляды и мнения, высказанные в этой статье, являются исключительно точкой зрения автора и не являются инвестиционными советами.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.