Автор: Віталік, засновник Ethereum; Переклад: Золотий Фінанс xiaozhou
Найпоширеніша критика підвищення ліміту газу L1, окрім занепокоєння безпекою мережі, полягає в тому, що це ускладнить роботу повних вузлів. Особливо в контексті дорожньої карти, що зосереджується на "розв'язанні повних вузлів", для вирішення цієї проблеми спочатку потрібно зрозуміти сенс існування повних вузлів.
Традиційна точка зору вважає, що повні вузли використовуються для перевірки даних на блокчейні. Якщо це єдина проблема, тоді ZK-EVM може розблокувати L1 масштабування: єдине обмеження - це підтримувати достатньо низькі витрати на побудову блоків і доведення, щоб обидва могли зберігати антикорупційність 1 з n та формувати конкурентний ринок.
Але в реальності це не єдине міркування. Іншим важливим фактором є: запуск повного вузла дозволяє вам мати локальний RPC-сервер, що дає змогу зчитувати дані з блокчейну без довіри, стійко до цензури та з захистом конфіденційності. У цій статті буде обговорено, як налаштувати поточну дорожню карту розширення L1 для досягнення цієї мети.
1. Чому не задовольняє децентралізація та конфіденційність, реалізовані за допомогою ZK-EVM+PIR?
Дорожня карта конфіденційності, яку я опублікував минулого місяця, пропагує прийняття TEEs + ORAM у короткостроковій перспективі та перехід на технологію PIR у довгостроковій перспективі. У поєднанні з верифікацією Helios та ZK-EVM користувачі можуть бути повністю впевнені в коректності даних ланцюга, отриманих (i), при підключенні до зовнішнього ПКС, (ii) конфіденційність даних захищена. У зв'язку з цим виникає питання: чому б не зупинитися на досягнутому? Чи роблять ці передові криптографічні схеми застарілими вузли, розміщені на власному хостингу?
На це я маю кілька відповідей:
--Цілком бездоверчі криптографічні рішення (як-от односерверний PIR) є дорогими. Актуальні витрати є надто високими, навіть після численних оптимізацій ефективності вони можуть залишатися на високому рівні.
--Проблема конфіденційності метаданих. Час запиту IP-адреси, модель запиту та інші метадані самі по собі можуть розкрити велику кількість інформації про користувачів.
--Перевірка вразливості: Ринкова структура, що контролюється невеликою кількістю постачальників RPC, буде піддаватися сильному тиску з боку користувачів на блокування або цензуру. Багато постачальників RPC вже почали повністю блокувати певні країни.
Тому продовження забезпечення зручності роботи особистих вузлів все ще має значення.
2、Короткострокові пріоритети
Пріоритетне всебічне впровадження EIP-4444, що врешті-решт дозволить кожному вузлу зберігати приблизно 36 днів даних. Це суттєво зменшить вимоги до місця на жорсткому диску — нинішня головна перешкода для людей, які хочуть запускати вузли. Після цього вимоги до зберігання для вузлів будуть включати лише: (i) стан даних, (ii) мерклеві гілки стану, (iii) 36 днів історичних даних.
Побудова розподіленої історичної системи зберігання, що дозволяє кожному вузлу зберігати невелику кількість застарілих історичних даних. Максимізація надійності за допомогою технології кодування з корекцією помилок. Це дозволяє забезпечити характеристику "постійного зберігання блокчейну", не покладаючись на централізованих постачальників або накладаючи важкий тягар на операторів вузлів.
Коригування стратегії ціноутворення Gas, підвищення витрат на зберігання, зниження витрат на виконання. Основна увага приділяється підвищенню вартості Gas для наступних операцій: (i) виконання SSTORE для нового слота зберігання (storage slot), (ii) створення коду контракту, (iii) переказ ETH на рахунок з нульовим балансом/нульовим nonce.
Після реалізації безстанного підтвердження, вузли, що підтримують RPC (тобто вузли, які зберігають стан), більше не будуть зобов'язані зберігати стан Меркле-галузі. Це дозволить зменшити вимоги до зберігання ще приблизно на 50%.
4, Нові вузли: часткові безстанційні вузли
Ця інноваційна концепція стане ключовою для підтримання роботи особистих вузлів після підвищення верхньої межі газу L1 у 10-100 разів.
Ми додали новий тип вузлів: перевірка блоків без стану, перевірка всього ланцюга за допомогою верифікації без стану або ZK-EVM, але збереження лише частини даних стану. До тих пір, поки дані, необхідні для запиту RPC, знаходяться в цій підмножині стану, вузол може відповісти; Інші запити зазнають невдачі (або доведеться повертатися до криптографічного рішення, розміщеного ззовні - резервний варіант повинен вибирати користувач).
Конкретні стани, які слід підтримувати, залежать від налаштувань користувача, наприклад:
--Виключити всі стани, окрім відомих сміттєвих контрактів.
--статус, пов'язаний з усіма EOA, SCW рахунками та поширеними ERC20/ERC721 токенами і додатками.
--Статус активних EOA/SCW рахунків за останні два роки + статус деяких популярних токенів ERC20 + статус обраних додатків swap/DeFi/приватності.
Конфігурацією можна керувати за допомогою ончейн-контракту: коли користувач запускає вузол, використовуйте "--save_state_by_config 0x12345... 67890", який визначить список адрес, слотів зберігання або фільтрів статусу, які необхідно зберегти та оновити в режимі реального часу вузлом на певній мові. Зверніть увагу, що користувачеві не потрібно зберігати гілку Merkle, тільки оригінальне значення.
Цей тип вузлів може забезпечити як місцевий прямий доступ до ключових станів, так і повну приватність доступу.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Vitalik: оптимізований план розширення, що зосереджується на локальних Нодах
Автор: Віталік, засновник Ethereum; Переклад: Золотий Фінанс xiaozhou
Найпоширеніша критика підвищення ліміту газу L1, окрім занепокоєння безпекою мережі, полягає в тому, що це ускладнить роботу повних вузлів. Особливо в контексті дорожньої карти, що зосереджується на "розв'язанні повних вузлів", для вирішення цієї проблеми спочатку потрібно зрозуміти сенс існування повних вузлів.
Традиційна точка зору вважає, що повні вузли використовуються для перевірки даних на блокчейні. Якщо це єдина проблема, тоді ZK-EVM може розблокувати L1 масштабування: єдине обмеження - це підтримувати достатньо низькі витрати на побудову блоків і доведення, щоб обидва могли зберігати антикорупційність 1 з n та формувати конкурентний ринок.
Але в реальності це не єдине міркування. Іншим важливим фактором є: запуск повного вузла дозволяє вам мати локальний RPC-сервер, що дає змогу зчитувати дані з блокчейну без довіри, стійко до цензури та з захистом конфіденційності. У цій статті буде обговорено, як налаштувати поточну дорожню карту розширення L1 для досягнення цієї мети.
1. Чому не задовольняє децентралізація та конфіденційність, реалізовані за допомогою ZK-EVM+PIR?
Дорожня карта конфіденційності, яку я опублікував минулого місяця, пропагує прийняття TEEs + ORAM у короткостроковій перспективі та перехід на технологію PIR у довгостроковій перспективі. У поєднанні з верифікацією Helios та ZK-EVM користувачі можуть бути повністю впевнені в коректності даних ланцюга, отриманих (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, знаходяться в цій підмножині стану, вузол може відповісти; Інші запити зазнають невдачі (або доведеться повертатися до криптографічного рішення, розміщеного ззовні - резервний варіант повинен вибирати користувач).
! qWmAn09ZE4jt0rEyydlCshCydJI7aVcg5fEeT5qk.png
Конкретні стани, які слід підтримувати, залежать від налаштувань користувача, наприклад:
--Виключити всі стани, окрім відомих сміттєвих контрактів.
--статус, пов'язаний з усіма EOA, SCW рахунками та поширеними ERC20/ERC721 токенами і додатками.
--Статус активних EOA/SCW рахунків за останні два роки + статус деяких популярних токенів ERC20 + статус обраних додатків swap/DeFi/приватності.
Конфігурацією можна керувати за допомогою ончейн-контракту: коли користувач запускає вузол, використовуйте "--save_state_by_config 0x12345... 67890", який визначить список адрес, слотів зберігання або фільтрів статусу, які необхідно зберегти та оновити в режимі реального часу вузлом на певній мові. Зверніть увагу, що користувачеві не потрібно зберігати гілку Merkle, тільки оригінальне значення.
Цей тип вузлів може забезпечити як місцевий прямий доступ до ключових станів, так і повну приватність доступу.