Автор: Виталик, основатель Ethereum; Перевод: Золотая Финансовая Сеть xiaozhou
Наиболее распространенной критикой повышения предела L1 Gas, помимо опасений по поводу безопасности сети, является то, что это усложнит работу полных узлов. Особенно в контексте дорожной карты, сосредоточенной на "разъединении полных узлов", чтобы решить эту проблему, необходимо сначала понять смысл существования полных узлов.
Традиционная точка зрения считает, что полные узлы используются для верификации данных на цепочке. Если это единственная проблема, то ZK-EVM сможет разблокировать масштабирование L1: единственное ограничение заключается в том, чтобы поддерживать достаточно низкие затраты на создание блоков и доказательства, чтобы оба могли сохранять антикоррупционность 1 из n и формировать конкурентный рынок.
Но в реальности это не единственный фактор. Другим важным аспектом является: работа полного узла позволяет вам иметь локальный RPC-сервер, который обеспечивает чтение данных с цепочки в доверительном, антицензурном и защищающем конфиденциальность режиме. В этой статье будет обсуждено, как скорректировать текущую дорожную карту расширения L1 для достижения этой цели.
1、Почему недостаточно децентрализации и конфиденциальности, достигнутых с помощью ZK-EVM+PIR?
В прошлом месяце я опубликовал дорожную карту конфиденциальности, в которой утверждается: в краткосрочной перспективе следует использовать решения TEE + ORAM, а в долгосрочной – перейти к технологии PIR. В сочетании с верификацией Helios и ZK-EVM пользователи могут быть полностью уверены, что: (i) полученные цепочные данные корректны, (ii) конфиденциальность данных защищена. Это поднимает вопрос: почему бы не остановиться на этом? Эти передовые криптографические решения делают самообслуживаемые узлы устаревшими?
У меня есть несколько ответов на это:
--Полностью децентрализованные криптографические решения (например, односерверный PIR) имеют высокую стоимость. Текущие затраты слишком велики и нецелесообразны, даже после многократной оптимизации эффективности они могут оставаться высокими.
--Проблемы с конфиденциальностью метаданных. Время запроса IP-адреса, модели запросов и другие метаданные сами по себе могут раскрыть большое количество информации о пользователе.
--Проверка уязвимостей: Рыночная структура, контролируемая несколькими поставщиками RPC, будет подвергаться сильному давлению со стороны пользователей в виде блокировок или цензуры. Многие поставщики RPC уже начали полностью блокировать определенные страны.
Таким образом, продолжение обеспечения удобства работы личных узлов по-прежнему имеет ценность.
2、Краткосрочные приоритеты
Отдайте приоритет полному развертыванию EIP-4444, чтобы хранить данные на каждом узле только в течение 36 дней. Это значительно снизит требования к пространству на жестком диске, которые в настоящее время являются препятствием номер один, мешающим людям запускать узлы. После этого требования к хранилищу ноды будут состоять только из: (i) данных о состоянии, (ii) ветви Меркла состояния, (iii)36 дней исторических данных.
Создание распределенной системы хранения истории, позволяющее каждому узлу хранить небольшое количество устаревших данных. Максимальная надежность достигается за счет технологии кодов исправления ошибок. Это обеспечивает как характеристику "постоянного хранения блокчейна", так и избавляет от зависимости от централизованных поставщиков или тяжелой нагрузки на операторов узлов.
Настройка стратегии ценообразования Gas, увеличение затрат на хранение и снижение затрат на выполнение. Основное внимание уделяется повышению затрат Gas для следующих операций: (i) выполнение SSTORE для нового слота хранения (storage slot), (ii) создание кода контракта, (iii) перевод ETH на счет с нулевым балансом/нулевым nonce.
3. Промежуточная цель: безсостояние верификация
После реализации безсостояния проверки узлы, поддерживающие RPC (то есть узлы, хранящие состояние), не будут нуждаться в сохранении состояния Меркл-ветвей. Это позволит снизить требования к хранению примерно на 50%.
4, Новый тип узла: некоторые безсостояние узлы
Эта инновационная идея станет ключевой для поддержания работы личных узлов после увеличения предела газа L1 в 10-100 раз.
Мы добавили новый тип узла: проверка блоков без состояния, с использованием безсостояния или проверки ZK-EVM для всей цепочки, но поддерживается только часть данных состояния. Узел сможет ответить, если необходимые данные для RPC-запроса находятся в этом подмножестве состояния; другие запросы потерпят неудачу (или нужно будет вернуться к внешнему криптографическому решению — решение о возврате должно принимать пользователем).
Конкретные состояния, которые необходимо поддерживать, зависят от конфигурации пользователя, например:
--Исключить все состояния, кроме известных мусорных контрактов.
--состояние, связанное со всеми EOA, SCW счетами и часто используемыми токенами и приложениями ERC20/ERC721.
--Статус активных EOA/SCW счетов за последние два года + статус некоторых популярных токенов ERC20 + статус избранных приложений swap/DeFi/приватности.
Конфигурация может управляться через смарт-контракты: пользователи могут использовать параметр "--save_state_by_config 0x12345...67890" при запуске узла, этот адрес будет определять список адресов, которые узел должен сохранять и обновлять в реальном времени, а также хранилище (storage slot) или правила фильтрации состояния на определенном языке. Обратите внимание, что пользователям не нужно сохранять Меркле-ветвь, нужно только сохранить исходное значение.
Эти узлы обеспечивают как преимущества локального прямого доступа к критическим состояниям, так и полную конфиденциальность доступа.
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Виталик: Оптимизированный план расширения с акцентом на местные узлы.
Автор: Виталик, основатель Ethereum; Перевод: Золотая Финансовая Сеть xiaozhou
Наиболее распространенной критикой повышения предела L1 Gas, помимо опасений по поводу безопасности сети, является то, что это усложнит работу полных узлов. Особенно в контексте дорожной карты, сосредоточенной на "разъединении полных узлов", чтобы решить эту проблему, необходимо сначала понять смысл существования полных узлов.
Традиционная точка зрения считает, что полные узлы используются для верификации данных на цепочке. Если это единственная проблема, то ZK-EVM сможет разблокировать масштабирование L1: единственное ограничение заключается в том, чтобы поддерживать достаточно низкие затраты на создание блоков и доказательства, чтобы оба могли сохранять антикоррупционность 1 из n и формировать конкурентный рынок.
Но в реальности это не единственный фактор. Другим важным аспектом является: работа полного узла позволяет вам иметь локальный RPC-сервер, который обеспечивает чтение данных с цепочки в доверительном, антицензурном и защищающем конфиденциальность режиме. В этой статье будет обсуждено, как скорректировать текущую дорожную карту расширения L1 для достижения этой цели.
1、Почему недостаточно децентрализации и конфиденциальности, достигнутых с помощью ZK-EVM+PIR?
В прошлом месяце я опубликовал дорожную карту конфиденциальности, в которой утверждается: в краткосрочной перспективе следует использовать решения TEE + ORAM, а в долгосрочной – перейти к технологии PIR. В сочетании с верификацией Helios и ZK-EVM пользователи могут быть полностью уверены, что: (i) полученные цепочные данные корректны, (ii) конфиденциальность данных защищена. Это поднимает вопрос: почему бы не остановиться на этом? Эти передовые криптографические решения делают самообслуживаемые узлы устаревшими?
У меня есть несколько ответов на это:
--Полностью децентрализованные криптографические решения (например, односерверный PIR) имеют высокую стоимость. Текущие затраты слишком велики и нецелесообразны, даже после многократной оптимизации эффективности они могут оставаться высокими.
--Проблемы с конфиденциальностью метаданных. Время запроса IP-адреса, модели запросов и другие метаданные сами по себе могут раскрыть большое количество информации о пользователе.
--Проверка уязвимостей: Рыночная структура, контролируемая несколькими поставщиками RPC, будет подвергаться сильному давлению со стороны пользователей в виде блокировок или цензуры. Многие поставщики RPC уже начали полностью блокировать определенные страны.
Таким образом, продолжение обеспечения удобства работы личных узлов по-прежнему имеет ценность.
2、Краткосрочные приоритеты
Отдайте приоритет полному развертыванию EIP-4444, чтобы хранить данные на каждом узле только в течение 36 дней. Это значительно снизит требования к пространству на жестком диске, которые в настоящее время являются препятствием номер один, мешающим людям запускать узлы. После этого требования к хранилищу ноды будут состоять только из: (i) данных о состоянии, (ii) ветви Меркла состояния, (iii)36 дней исторических данных.
Создание распределенной системы хранения истории, позволяющее каждому узлу хранить небольшое количество устаревших данных. Максимальная надежность достигается за счет технологии кодов исправления ошибок. Это обеспечивает как характеристику "постоянного хранения блокчейна", так и избавляет от зависимости от централизованных поставщиков или тяжелой нагрузки на операторов узлов.
Настройка стратегии ценообразования Gas, увеличение затрат на хранение и снижение затрат на выполнение. Основное внимание уделяется повышению затрат Gas для следующих операций: (i) выполнение SSTORE для нового слота хранения (storage slot), (ii) создание кода контракта, (iii) перевод ETH на счет с нулевым балансом/нулевым nonce.
3. Промежуточная цель: безсостояние верификация
После реализации безсостояния проверки узлы, поддерживающие RPC (то есть узлы, хранящие состояние), не будут нуждаться в сохранении состояния Меркл-ветвей. Это позволит снизить требования к хранению примерно на 50%.
4, Новый тип узла: некоторые безсостояние узлы
Эта инновационная идея станет ключевой для поддержания работы личных узлов после увеличения предела газа L1 в 10-100 раз.
Мы добавили новый тип узла: проверка блоков без состояния, с использованием безсостояния или проверки ZK-EVM для всей цепочки, но поддерживается только часть данных состояния. Узел сможет ответить, если необходимые данные для RPC-запроса находятся в этом подмножестве состояния; другие запросы потерпят неудачу (или нужно будет вернуться к внешнему криптографическому решению — решение о возврате должно принимать пользователем).
! qWmAn09ZE4jt0rEyydlCshCydJI7aVcg5fEeT5qk.png
Конкретные состояния, которые необходимо поддерживать, зависят от конфигурации пользователя, например:
--Исключить все состояния, кроме известных мусорных контрактов.
--состояние, связанное со всеми EOA, SCW счетами и часто используемыми токенами и приложениями ERC20/ERC721.
--Статус активных EOA/SCW счетов за последние два года + статус некоторых популярных токенов ERC20 + статус избранных приложений swap/DeFi/приватности.
Конфигурация может управляться через смарт-контракты: пользователи могут использовать параметр "--save_state_by_config 0x12345...67890" при запуске узла, этот адрес будет определять список адресов, которые узел должен сохранять и обновлять в реальном времени, а также хранилище (storage slot) или правила фильтрации состояния на определенном языке. Обратите внимание, что пользователям не нужно сохранять Меркле-ветвь, нужно только сохранить исходное значение.
Эти узлы обеспечивают как преимущества локального прямого доступа к критическим состояниям, так и полную конфиденциальность доступа.