Ця стаття походить від: співзасновника 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) державна Меркле-гілка; (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 гілки; вони повинні зберігати тільки початкові значення.
Цей тип вузла дозволяє користувачам безпосередньо отримувати доступ до статусу, який потребує уваги, і максимально захищає конфіденційність доступу до цього статусу.
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Vitalik: Новий план для вирішення проблеми масштабованості Ethereum L1
Ця стаття походить від: співзасновника Ethereum Віталіка
Перекладач | 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) що конфіденційність їхніх даних захищена. Тому ми не можемо не запитати: чому ми не можемо зупинитися на цьому? Чи не зроблять ці передові крипто-рішення самостійно керовані вузли застарілими реликвії?
Тут я можу дати кілька відповідей:
З цих причин продовження забезпечення більш зручного функціонування особистих вузлів є цінним.
Короткострокові пріоритети
Проміжні пріоритети: безстанна верифікація
Якщо ми активуємо безстанну перевірку, стане можливим запускати вузли з функціональністю RPC (тобто вузли, що зберігають стан) без зберігання стану Merkle гілок. Це ще більше знизить вимоги до зберігання приблизно в 2 рази.
Новий тип вузла: частково безстанційний вузол
Це нова ідея, яка є ключем до дозволу роботи особистих вузлів у випадку, якщо обмеження L1 Gas зросте в 10-100 разів.
Ми додали новий тип вузла, який може безстанно перевіряти блоки, перевіряти всю ланцюг (через безстанну перевірку або ZK-EVM) і підтримувати частину стану в актуальному стані. Як тільки необхідні дані знаходяться в цьому підмножині стану, вузол може реагувати на запити RPC; інші запити зазнають невдачі (або повинні бути повернені до зовнішнього управління криптографічним рішенням; чи робити це, повинні вирішувати користувачі).
Конкретна частина стану, яку потрібно зберегти, залежить від конфігурації, обраної користувачем. Приклад наведено нижче.
Конфігурація може управлятися за допомогою смарт-контрактів: користувач може запустити свій вузол, використовуючи --save_state_by_config 0x 12345...67890, ця адреса вказуватиме список адрес, слотів зберігання або інших фільтрувальних областей, де вузол буде зберігати та підтримувати актуальний стан. Зверніть увагу, що користувачеві не потрібно зберігати Merkle гілки; вони повинні зберігати тільки початкові значення.
Цей тип вузла дозволяє користувачам безпосередньо отримувати доступ до статусу, який потребує уваги, і максимально захищає конфіденційність доступу до цього статусу.