Запуск полного узла позволяет вам иметь локальный RPC сервер, что позволяет считывать данные в блокчейне без доверия, с защитой от цензуры и с соблюдением конфиденциальности.
Автор: Виталик, основатель Эфириума
Перевод: Золотая экономика 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», этот адрес будет определять список адресов, которые узел должен сохранять и обновлять в реальном времени, хранилище (storage slot) или правила фильтрации состояния на определенном языке. Обратите внимание, что пользователям не нужно сохранять Меркл-ветви, достаточно сохранить исходные значения.
Этот тип узлов предоставляет как местные прямые преимущества доступа к ключевым состояниям, так и обеспечивает полную конфиденциальность доступа.
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Виталик: оптимизация дорожной карты масштабирования, сосредоточенная на локальных узлах
Автор: Виталик, основатель Эфириума
Перевод: Золотая экономика xiaozhou
Самая распространенная критика повышения лимита газа L1, помимо опасений по поводу безопасности сети, заключается в том, что это усложнит работу полных узлов. Особенно в контексте дорожной карты, сосредоточенной на «развязывании полных узлов», для решения этой проблемы необходимо сначала понять значение существования полных узлов.
Традиционная точка зрения считает, что полный узел используется для проверки данных в блокчейне. Если это единственная проблема, то ZK-EVM может разблокировать масштабирование L1: единственное ограничение заключается в поддержании низкой стоимости создания блоков и доказательств, чтобы оба могли сохранять антикоррупционность 1 из n и создавать конкурентный рынок.
Но на практике это не единственный фактор. Другим важным аспектом является то, что запуск Полного узла позволяет вам иметь локальный RPC-сервер, что позволяет считывать данные в блокчейне без доверия, с защитой от цензуры и с сохранением конфиденциальности. В этой статье будет обсуждено, как скорректировать текущую дорожную карту масштабирования L1 для достижения этой цели.
1. Почему не удовлетвориться децентрализацией и конфиденциальностью, реализованными с помощью ZK-EVM+PIR?
Дорожная карта конфиденциальности, которую я выпустил в прошлом месяце, выступает за внедрение TEEs+ORAM в краткосрочной перспективе и переход на технологию PIR в долгосрочной перспективе. В сочетании с валидацией Helios и ZK-EVM пользователи могут подключаться к внешним RPC с полной уверенностью в том, что (i) получает правильные данные цепочки и (ii) конфиденциальность данных защищена. Возникает вопрос: почему бы не остановиться на этом? Делают ли эти передовые схемы шифрования автономные узлы устаревшими?
У меня есть несколько ответов на это:
Поэтому продолжение обеспечения удобства работы личного узла по-прежнему имеет значение.
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-запроса, находятся в этом подмножестве состояния; остальные запросы потерпят неудачу (или должны вернуться к внешнему хранилищу криптографического решения — решение о том, возвращаться ли, должно принимать пользователем).
!
Конкретные поддерживаемые состояния зависят от конфигурации пользователя, например:
Конфигурация может управляться через в блокчейне контракт: пользователи, запускающие узел, используют параметр «--save_state_by_config 0x12345...67890», этот адрес будет определять список адресов, которые узел должен сохранять и обновлять в реальном времени, хранилище (storage slot) или правила фильтрации состояния на определенном языке. Обратите внимание, что пользователям не нужно сохранять Меркл-ветви, достаточно сохранить исходные значения.
Этот тип узлов предоставляет как местные прямые преимущества доступа к ключевым состояниям, так и обеспечивает полную конфиденциальность доступа.