Vitalik: Оптимизированный план расширения, ориентированный на локальные узлы

Автор: Виталик, основатель Ethereum

Компиляция: Золотые финансы xiaozhou

Наиболее распространенная критика повышения лимита газа L1, помимо беспокойства по поводу безопасности сети, заключается в том, что это усложнит работу полных узлов. Особенно в контексте дорожной карты, сосредоточенной на «разъединении полных узлов», для решения этой проблемы сначала необходимо понять смысл существования полных узлов.

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

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

1. Почему недостаточно децентрализации и конфиденциальности, достигнутых с помощью ZK-EVM+PIR?

В опубликованной мною в прошлом месяце дорожной карте конфиденциальности утверждается: в краткосрочной перспективе следует использовать схему TEEs+ORAM, а в долгосрочной — перейти к технологии PIR. В сочетании с верификацией Helios и ZK-EVM пользователи могут быть полностью уверены, что данные цепочки, полученные при подключении к внешнему RPC: (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", который определит список адресов, слотов для хранения или фильтров состояния, которые должны быть сохранены и обновлены узлом в режиме реального времени на определенном языке. Обратите внимание, что пользователю не нужно сохранять ветвь Меркла, только исходное значение.

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