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

Продвинутый5/21/2025, 5:52:14 AM
Виталик Бутерин предложил модифицировать дорожную карту масштабирования Ethereum, отстаивая концепцию 'бессостоятельных клиентов' для одновременного решения проблем производительности, конфиденциальности и верифицируемости. Статья предоставляет глубокий анализ будущих путей эволюции для оптимизации хранения данных, механизмов сохранения конфиденциальности и парадигм доступа к цепочке.

Особая благодарность Мика Золту, Тони Варштеттеру, Джастину Траглиа и пкаверсаччио за обсуждение

Самая распространенная критика увеличения лимита газа L1, помимо обеспокоенности безопасностью сети, заключается в том, что становится сложнее запускать полный узел.

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

Исторически считалось, что полные узлы предназначены для проверки цепочки; см.здесьдля моего собственного изложения того, что может произойти, если обычные пользователи не смогут подтвердить. Если это единственная проблема, то L1 масштабирование разблокируется с помощью ZK-EVMs: единственное ограничение - поддерживать достаточно низкие затраты на построение блока и доказательства, чтобы оба могли оставаться1-из-nнесгибаемость цензуры и конкурентоспособность рынка.

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

Почему бы не остановиться на отсутствии доверия и конфиденциальности через ZK-EVM + PIR?

дорожная карта конфиденциальности, опубликованная мной в прошлом месяцефокусируется на TEEs +ORAMкак краткосрочное решение плюсPIRкак долгосрочное решение. Вместе с Helios и верификацией ZK-EVM это позволит любому пользователю подключаться к внешним RPC и быть уверенным, что (i) цепочка, которую они получают, правильна, и (ii) их конфиденциальность данных защищена. Таким образом, стоит задать вопрос: почему бы не остановиться здесь? Разве такие передовые криптографические решения не делают самостоятельные узлы устаревшим артефактом?

Здесь я могу дать несколько ответов:

  • Полностью децентрализованные криптографические решения (т. е. 1-серверный PIR) будут дорогими. В настоящее время издержки несоизмеримо высоки, и даже после многих улучшений эффективности вероятно останутся дорогими.
  • Конфиденциальность метаданных. Данные о том, с каких IP-адресов поступают запросы в какое время и образец запросов, в себе достаточно, чтобы раскрыть много информации о пользователях.
  • Уязвимость цензуры: рыночная структура, контролируемая несколькими поставщиками RPC, будет подвергаться сильному давлению на децентрализацию или цензуру пользователей. Многие поставщики RPC уже исключают целые страны.

Поэтим причинам важно продолжать обеспечивать большую легкость запуска персонального узла.

Краткосрочные приоритеты

  • Повысьте приоритет полного внедрения EIP-4444, доведя его до конечного состояния, когда каждый узел хранит данные только ~36 дней. Это значительно снизит требования к дисковому пространству, которые являются основной проблемой, мешающей большему количеству людей запускать узлы. После этого требования к дисковому пространству для узла будут составлять (i) размер состояния, (ii) ветви состояния Merkle, (iii) 36 дней истории.
  • Построить распределенное решение для хранения исторических данных, при котором каждый узел может хранить небольшой процент исторических данных, старше определенной даты. Использовать кодирование стирания для максимизации надежности. Это обеспечивает свойство "блокчейн вечен" без зависимости от централизованных провайдеров или создания тяжелых бремен для узловых операторов.
  • Увеличить цену газа, чтобы сделать хранение дороже и выполнение дешевле. Особенно важным является увеличение стоимости газа при создании нового состояния: (i) SSTORE для новых слотов хранения, (ii) создание кода контракта, (iii) отправка ETH на счета, у которых еще нет баланса или nonce.

Приоритет на средний срок: бесгосударственная верификация

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

Новый тип узла: частично бесхозные узлы

Это новая идея, и она будет ключевой для возможности личной работы узла даже в контексте, где лимит газа L1 увеличивается на 10-100 раз.

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


partial_statelessness.drawio776×341 19.9 KB

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

  • Все государственные кроме контрактов, которые известны как спам
  • Состояние, связанное со всеми EOA и SCW, а также со всеми широко используемыми токенами и приложениями ERC20 и ERC721.
  • Состояние, связанное со всеми EOA и SCW, к которым был доступ за последние два года, некоторые часто используемые токены ERC20, плюс ограниченный отобранный набор приложений для обмена, defi и конфиденциальности

Конфигурацию можно управлять с помощью контракта onchain: пользователь запустит свой узел с —save_state_by_config 0x12345…67890, и адрес будет указывать на каком-то языке список адресов, слотов хранения или иным образом отфильтрованные области состояния, которые узел будет сохранять и поддерживать в актуальном состоянии. Обратите внимание, что пользователю не нужно сохранять Merkle-ветви; им просто нужно сохранить исходные значения.

Этот тип узла даст преимущества прямого локального доступа к состоянию, о котором пользователь должен заботиться, а также максимальную полную конфиденциальность доступа к этому состоянию.

Отказ от ответственности:

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

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

Продвинутый5/21/2025, 5:52:14 AM
Виталик Бутерин предложил модифицировать дорожную карту масштабирования Ethereum, отстаивая концепцию 'бессостоятельных клиентов' для одновременного решения проблем производительности, конфиденциальности и верифицируемости. Статья предоставляет глубокий анализ будущих путей эволюции для оптимизации хранения данных, механизмов сохранения конфиденциальности и парадигм доступа к цепочке.

Особая благодарность Мика Золту, Тони Варштеттеру, Джастину Траглиа и пкаверсаччио за обсуждение

Самая распространенная критика увеличения лимита газа L1, помимо обеспокоенности безопасностью сети, заключается в том, что становится сложнее запускать полный узел.

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

Исторически считалось, что полные узлы предназначены для проверки цепочки; см.здесьдля моего собственного изложения того, что может произойти, если обычные пользователи не смогут подтвердить. Если это единственная проблема, то L1 масштабирование разблокируется с помощью ZK-EVMs: единственное ограничение - поддерживать достаточно низкие затраты на построение блока и доказательства, чтобы оба могли оставаться1-из-nнесгибаемость цензуры и конкурентоспособность рынка.

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

Почему бы не остановиться на отсутствии доверия и конфиденциальности через ZK-EVM + PIR?

дорожная карта конфиденциальности, опубликованная мной в прошлом месяцефокусируется на TEEs +ORAMкак краткосрочное решение плюсPIRкак долгосрочное решение. Вместе с Helios и верификацией ZK-EVM это позволит любому пользователю подключаться к внешним RPC и быть уверенным, что (i) цепочка, которую они получают, правильна, и (ii) их конфиденциальность данных защищена. Таким образом, стоит задать вопрос: почему бы не остановиться здесь? Разве такие передовые криптографические решения не делают самостоятельные узлы устаревшим артефактом?

Здесь я могу дать несколько ответов:

  • Полностью децентрализованные криптографические решения (т. е. 1-серверный PIR) будут дорогими. В настоящее время издержки несоизмеримо высоки, и даже после многих улучшений эффективности вероятно останутся дорогими.
  • Конфиденциальность метаданных. Данные о том, с каких IP-адресов поступают запросы в какое время и образец запросов, в себе достаточно, чтобы раскрыть много информации о пользователях.
  • Уязвимость цензуры: рыночная структура, контролируемая несколькими поставщиками RPC, будет подвергаться сильному давлению на децентрализацию или цензуру пользователей. Многие поставщики RPC уже исключают целые страны.

Поэтим причинам важно продолжать обеспечивать большую легкость запуска персонального узла.

Краткосрочные приоритеты

  • Повысьте приоритет полного внедрения EIP-4444, доведя его до конечного состояния, когда каждый узел хранит данные только ~36 дней. Это значительно снизит требования к дисковому пространству, которые являются основной проблемой, мешающей большему количеству людей запускать узлы. После этого требования к дисковому пространству для узла будут составлять (i) размер состояния, (ii) ветви состояния Merkle, (iii) 36 дней истории.
  • Построить распределенное решение для хранения исторических данных, при котором каждый узел может хранить небольшой процент исторических данных, старше определенной даты. Использовать кодирование стирания для максимизации надежности. Это обеспечивает свойство "блокчейн вечен" без зависимости от централизованных провайдеров или создания тяжелых бремен для узловых операторов.
  • Увеличить цену газа, чтобы сделать хранение дороже и выполнение дешевле. Особенно важным является увеличение стоимости газа при создании нового состояния: (i) SSTORE для новых слотов хранения, (ii) создание кода контракта, (iii) отправка ETH на счета, у которых еще нет баланса или nonce.

Приоритет на средний срок: бесгосударственная верификация

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

Новый тип узла: частично бесхозные узлы

Это новая идея, и она будет ключевой для возможности личной работы узла даже в контексте, где лимит газа L1 увеличивается на 10-100 раз.

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


partial_statelessness.drawio776×341 19.9 KB

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

  • Все государственные кроме контрактов, которые известны как спам
  • Состояние, связанное со всеми EOA и SCW, а также со всеми широко используемыми токенами и приложениями ERC20 и ERC721.
  • Состояние, связанное со всеми EOA и SCW, к которым был доступ за последние два года, некоторые часто используемые токены ERC20, плюс ограниченный отобранный набор приложений для обмена, defi и конфиденциальности

Конфигурацию можно управлять с помощью контракта onchain: пользователь запустит свой узел с —save_state_by_config 0x12345…67890, и адрес будет указывать на каком-то языке список адресов, слотов хранения или иным образом отфильтрованные области состояния, которые узел будет сохранять и поддерживать в актуальном состоянии. Обратите внимание, что пользователю не нужно сохранять Merkle-ветви; им просто нужно сохранить исходные значения.

Этот тип узла даст преимущества прямого локального доступа к состоянию, о котором пользователь должен заботиться, а также максимальную полную конфиденциальность доступа к этому состоянию.

Отказ от ответственности:

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