Особлива подяка Міка Золту, Тоні Варстеттер, Джастіну Траглія та pcaversaccio за обговорення

Найпоширеніша критика щодо збільшення ліміту газу L1, поза обуренням мережевою безпекою, полягає в тому, що це ускладнює запуск повного вузла.

Особливо в контексті дорожньої карти, орієнтованої на роз'єднанняповний вузол, щоб це зрозуміти, потрібно розуміти, для чого призначені повні вузли.

Історично вважалося, що повні вузли призначені для перевірки ланцюга; дивисьтутдля моєї власної експозиції того, що може трапитися, якщо звичайні користувачі не зможуть підтвердити. Якщо це єдине питання, то масштабування L1 розблоковане за допомогою ZK-EVMs: єдиним обмеженням є збереження витрат на побудову блоків та підтвердження настільки низьким, щоб обидва могли залишатися1-з-знезалежний від цензури та конкурентний ринок.

Проте, насправді це не єдине питання. Ще одне важливе питання полягає в тому, що важливо мати повний вузол, щоб мати локальний RPC-сервер, який можна використовувати для читання ланцюжка способом, який не потребує довіри, стійкого до цензури та дружелюбного до конфіденційності. У цьому документі будуть обговорені зміни в поточному шляху масштабування L1, які зроблять це можливим.

Чому б не зупинитися на відсутності довіри та конфіденційності за допомогою ZK-EVM + PIR?

дорожня карта конфіденційності, яку я опублікував минулого місяцязосереджується на TEEs +ORAMяк тимчасове патчPIRяк довгострокове рішення. Це, разом з верифікацією Helios та ZK-EVM, дозволить будь-якому користувачеві підключатися до зовнішніх RPC та бути повністю впевненим, що (i) ланцюг, який вони отримують, є правильним, і (ii) їхні дані захищені. Тому варто задати питання: чому б не зупинитися тут? Чи не зроблять ці типи передових криптографічних рішень самостійні вузли застарілим реліквієм?

Тут я можу дати кілька відповідей:

• Повністю довірчі криптографічні рішення (тобто 1-серверний PIR) будуть дорогими. Наразі накладні витрати надто високі, і навіть після багатьох покращень ефективності вони ймовірно залишаться дорогими.
• Конфіденційність метаданих. Дані про те, з якої IP-адреси надходять запити, в який час, і шаблон запитів, вже достатньо для виявлення великої кількості інформації про користувачів.
• Вразливість цензури: ринкова структура, що контролюється кількома постачальниками RPC, стикається з сильним тиском на виключення користувачів або цензуру. Багато постачальників RPC вже виключають цілі країни.

З цих причин є цінність у подальшому забезпеченні більшої легкості запуску особистого вузла.

Короткострокові пріоритети

• Надати пріоритет повному розгортанню EIP-4444, аж до кінцевого стану, де кожен вузол зберігає дані лише протягом ~36 днів. Це значно зменшує вимоги до дискового простору, які є основною проблемою, яка перешкоджає більшій кількості людей запускати вузли. Після цього вимоги до дискового простору для вузла будуть становити (i) розмір стану, (ii) станові гілки Меркла, (iii) 36 днів історії.
• Створіть рішення для розподіленого зберігання історії, за допомогою якого кожен вузол може зберігати невеликий відсоток історичних даних, старших за граничне значення. Використовуйте кодування стирання, щоб максимізувати надійність. Це гарантує властивість того, що «блокчейн є назавжди», не залежачи від централізованих постачальників і не створюючи великого навантаження на операторів вузлів
• Налаштувати ціну газу, щоб збільшити вартість зберігання і зменшити вартість виконання. Особливо важливою є збільшення вартості газу при створенні нового стану: (i) SSTORE для нових слотів зберігання, (ii) створення коду контракту, (iii) відсилання ETH на рахунки, які ще не мають балансу або nonce.

Середньостроковий пріоритет: бездержавна перевірка

Як тільки ми увімкнемо безстандартну перевірку, стає можливим запуск вузла, здатного до виконання RPC (тобто такого, який зберігає стан), без зберігання гілок Merkle стану. Це додатково зменшує вимоги до сховища приблизно вдвічі.

Новий тип вузла: частково безстатеві вузли

Це нова ідея, яка стане ключовою для можливості особистої операції вузла навіть в умовах збільшення ліміту газу L1 на 10-100 разів.

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

partial_statelessness.drawio776×341 19.9 КБ

Точна частина держави, яка буде утримуватися, залежатиме від конфігурації, обраної користувачем. Деякі приклади можуть бути:

• Всі стани, за винятком контрактів, які відомо, що є спамом
• Стан, пов'язаний з усіма EOA та SCW, а також усіма поширеними токенами та додатками ERC20 та ERC721
• Стан, пов'язаний з усіма EOAs та SCWs, які були використані протягом останніх двох років, деякі часто використовувані токени ERC20, а також обмежений відібраний набір програм для обміну, defi та конфіденційності

Конфігурацію можна керувати за допомогою контракту onchain: користувач запустить свій вузол з параметром —save_state_by_config 0x12345…67890, і адреса буде вказувати мовою список адрес, слотів для зберігання або інших фільтрованих областей стану, які вузол буде зберігати і оновлювати. Зверніть увагу, що користувачу не потрібно зберігати гілки Merkle; їм потрібно лише зберігати необроблені значення.

Цей тип вузла надасть користувачеві переваги безпосереднього місцевого доступу до стану, про який користувач повинен дбати, а також максимальної повної конфіденційності доступу до цього стану.

Відмова від відповідальності:

1. Цю статтю перепечатано зethresear]. Усі авторські права належать оригінальному автору [Віталій Бутерін]. Якщо є зауваження до цього перевидання, будь ласка, зв'яжіться з Ворота Навчаннякоманда, і вони оперативно з цим впораються.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, належать виключно автору і не становлять жодної інвестиційної поради.
3. Переклади статей на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонено.