Особая благодарность Мика Золту, Тони Варштеттеру, Джастину Траглиа и пкаверсаччио за обсуждение
Самая распространенная критика увеличения лимита газа L1, помимо обеспокоенности безопасностью сети, заключается в том, что становится сложнее запускать полный узел.
Особенно в контексте дорожной карты, сосредоточенной нараспаковкаполный узел, для понимания этого требуется понимание того, для чего предназначены полные узлы.
Исторически считалось, что полные узлы предназначены для проверки цепочки; см.здесьдля моего собственного изложения того, что может произойти, если обычные пользователи не смогут подтвердить. Если это единственная проблема, то L1 масштабирование разблокируется с помощью ZK-EVMs: единственное ограничение - поддерживать достаточно низкие затраты на построение блока и доказательства, чтобы оба могли оставаться1-из-nнесгибаемость цензуры и конкурентоспособность рынка.
Однако на практике это на самом деле не единственная проблема. Другая основная проблема заключается в том, что ценно иметь полный узел, чтобы у вас был локальный сервер RPC, который вы можете использовать для чтения цепи способом, который не требует доверия, устойчив к цензуре и дружелюбен к конфиденциальности. В этом документе будет обсуждаться корректировка текущего плана масштабирования L1, чтобы это произошло.
дорожная карта конфиденциальности, опубликованная мной в прошлом месяцефокусируется на TEEs +ORAMкак краткосрочное решение плюсPIRкак долгосрочное решение. Вместе с Helios и верификацией ZK-EVM это позволит любому пользователю подключаться к внешним RPC и быть уверенным, что (i) цепочка, которую они получают, правильна, и (ii) их конфиденциальность данных защищена. Таким образом, стоит задать вопрос: почему бы не остановиться здесь? Разве такие передовые криптографические решения не делают самостоятельные узлы устаревшим артефактом?
Здесь я могу дать несколько ответов:
Поэтим причинам важно продолжать обеспечивать большую легкость запуска персонального узла.
После включения безсостоянийной верификации становится возможным запуск узла, способного к RPC (т.е. хранящего состояние), без хранения ветвей Merkle состояния. Это дополнительно уменьшает требования к хранению примерно в 2 раза.
Это новая идея, и она будет ключевой для возможности личной работы узла даже в контексте, где лимит газа L1 увеличивается на 10-100 раз.
Мы добавляем тип узла, который проверяет блоки в бессостоятельном режиме, и проверяет всю цепочку (либо через бессостоятельную валидацию, либо через ZK-EVM) и поддерживает в актуальном состоянии часть состояния. Узел способен отвечать на запросы RPC, пока необходимые данные находятся в этом подмножестве состояния; другие запросы завершатся неудачей (или им придется воспользоваться внешне-размещенным криптографическим решением; решение о том, делать это или нет, должно быть выбором пользователя).
partial_statelessness.drawio776×341 19.9 KB
Точная часть государства, которая будет удерживаться, будет зависеть от выбранной пользователем конфигурации. Некоторые примеры могут быть:
Конфигурацию можно управлять с помощью контракта onchain: пользователь запустит свой узел с —save_state_by_config 0x12345…67890, и адрес будет указывать на каком-то языке список адресов, слотов хранения или иным образом отфильтрованные области состояния, которые узел будет сохранять и поддерживать в актуальном состоянии. Обратите внимание, что пользователю не нужно сохранять Merkle-ветви; им просто нужно сохранить исходные значения.
Этот тип узла даст преимущества прямого локального доступа к состоянию, о котором пользователь должен заботиться, а также максимальную полную конфиденциальность доступа к этому состоянию.
Особая благодарность Мика Золту, Тони Варштеттеру, Джастину Траглиа и пкаверсаччио за обсуждение
Самая распространенная критика увеличения лимита газа L1, помимо обеспокоенности безопасностью сети, заключается в том, что становится сложнее запускать полный узел.
Особенно в контексте дорожной карты, сосредоточенной нараспаковкаполный узел, для понимания этого требуется понимание того, для чего предназначены полные узлы.
Исторически считалось, что полные узлы предназначены для проверки цепочки; см.здесьдля моего собственного изложения того, что может произойти, если обычные пользователи не смогут подтвердить. Если это единственная проблема, то L1 масштабирование разблокируется с помощью ZK-EVMs: единственное ограничение - поддерживать достаточно низкие затраты на построение блока и доказательства, чтобы оба могли оставаться1-из-nнесгибаемость цензуры и конкурентоспособность рынка.
Однако на практике это на самом деле не единственная проблема. Другая основная проблема заключается в том, что ценно иметь полный узел, чтобы у вас был локальный сервер RPC, который вы можете использовать для чтения цепи способом, который не требует доверия, устойчив к цензуре и дружелюбен к конфиденциальности. В этом документе будет обсуждаться корректировка текущего плана масштабирования L1, чтобы это произошло.
дорожная карта конфиденциальности, опубликованная мной в прошлом месяцефокусируется на TEEs +ORAMкак краткосрочное решение плюсPIRкак долгосрочное решение. Вместе с Helios и верификацией ZK-EVM это позволит любому пользователю подключаться к внешним RPC и быть уверенным, что (i) цепочка, которую они получают, правильна, и (ii) их конфиденциальность данных защищена. Таким образом, стоит задать вопрос: почему бы не остановиться здесь? Разве такие передовые криптографические решения не делают самостоятельные узлы устаревшим артефактом?
Здесь я могу дать несколько ответов:
Поэтим причинам важно продолжать обеспечивать большую легкость запуска персонального узла.
После включения безсостоянийной верификации становится возможным запуск узла, способного к RPC (т.е. хранящего состояние), без хранения ветвей Merkle состояния. Это дополнительно уменьшает требования к хранению примерно в 2 раза.
Это новая идея, и она будет ключевой для возможности личной работы узла даже в контексте, где лимит газа L1 увеличивается на 10-100 раз.
Мы добавляем тип узла, который проверяет блоки в бессостоятельном режиме, и проверяет всю цепочку (либо через бессостоятельную валидацию, либо через ZK-EVM) и поддерживает в актуальном состоянии часть состояния. Узел способен отвечать на запросы RPC, пока необходимые данные находятся в этом подмножестве состояния; другие запросы завершатся неудачей (или им придется воспользоваться внешне-размещенным криптографическим решением; решение о том, делать это или нет, должно быть выбором пользователя).
partial_statelessness.drawio776×341 19.9 KB
Точная часть государства, которая будет удерживаться, будет зависеть от выбранной пользователем конфигурации. Некоторые примеры могут быть:
Конфигурацию можно управлять с помощью контракта onchain: пользователь запустит свой узел с —save_state_by_config 0x12345…67890, и адрес будет указывать на каком-то языке список адресов, слотов хранения или иным образом отфильтрованные области состояния, которые узел будет сохранять и поддерживать в актуальном состоянии. Обратите внимание, что пользователю не нужно сохранять Merkle-ветви; им просто нужно сохранить исходные значения.
Этот тип узла даст преимущества прямого локального доступа к состоянию, о котором пользователь должен заботиться, а также максимальную полную конфиденциальность доступа к этому состоянию.