Vitalik: оптимізований план розширення, що акцентує увагу на локальних Нодах

Автор: Віталік, засновник Ethereum

Компільовано: Золотий фінанс xiaozhou

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

Традиційна думка вважає, що повні вузли використовуються для перевірки даних на ланцюгу. Якщо це єдиною проблемою, тоді 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) або правила фільтрації стану. Зверніть увагу, що користувачам не потрібно зберігати Меркле-дерево, необхідно лише зберігати оригінальні значення.

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