Виталик: новое решение проблемы масштабируемости Ethereum L1

Это сообщение от: соучредителя Ethereum Виталик

Компиляция | Ежедневная газета Odaily (@OdailyChina)

Переводчик | Ethan（@ethanzhang_web3）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Все состояния, кроме известных как мусорные контракты
• Связано со всеми EOA и SCW, а также со всеми распространенными токенами и приложениями ERC 20 и ERC 721.
• Состояние, связанное со всеми EOA и SCW, которые были посещены за последние два года, а также с некоторыми распространенными токенами ERC 20, плюс ограниченный набор обменов, DeFi и приложений для обеспечения конфиденциальности.

Настройки могут управляться через смарт-контракты: пользователи могут использовать –save_state_by_config 0x 12345…67890 для запуска своего узла, этот адрес будет указывать на адреса, хранилища или другие области фильтрации, где узел будет сохранять и поддерживать актуальное состояние на определенном языке. Обратите внимание, что пользователям не нужно сохранять Merkle ветви; им нужно лишь сохранить исходные значения.

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