Запуск повного вузла дозволяє вам мати локальний RPC сервер, що дає можливість читати дані у блокчейні без необхідності довіряти, з антицензурною та захищеною приватністю.
Автор: Віталік, засновник 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 днів історичних даних.
Побудова розподіленої історичної схеми зберігання, щоб кожна Нода зберігала невелику кількість застарілих історичних даних. Максимізація надійності за допомогою технології кодів корекції помилок. Це дозволяє забезпечити характеристику «постійного зберігання блокчейну», не покладаючись на централізованих постачальників або накладаючи важке навантаження на операторів Нод.
Скоригуйте свою стратегію ціноутворення на газ, щоб збільшити витрати на зберігання та зменшити витрати на виконання. Зосередьтеся на збільшенні вартості газу для наступних операцій: (i) Виконати SSTORE для нового слота для зберігання, (ii) створити код договору, (iii) Перекажіть ETH на рахунок з нульовим балансом/нульовим балансом.
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", який визначить список адрес, слотів зберігання або фільтрів станів, які необхідно зберегти та оновити в режимі реального часу вузлом на певній мові. Зверніть увагу, що користувачеві не потрібно зберігати гілку Merkle, тільки оригінальне значення.
Цей тип ноди забезпечує як місцевий прямий доступ до ключових станів, так і повну конфіденційність доступу.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
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), а конфіденційність даних захищена. У зв'язку з цим виникає питання: чому б не зупинитися на досягнутому? Чи роблять ці передові криптографічні схеми застарілими вузли, розміщені на власному хостингу?
У зв'язку з цим я маю кілька відповідей:
Тому продовження забезпечення зручності роботи особистої ноди все ще має значення.
2、Короткострокові пріоритети
Пріоритетно впровадити EIP-4444, щоб зрештою кожна Нода зберігала лише приблизно 36 днів даних. Це суттєво зменшить вимоги до дискового простору — нині це основна перешкода для запуску Нод. Після цього вимоги до зберігання Нод включатимуть лише: (i) стан даних, (ii) стан Меркле-дерева, (iii)36 днів історичних даних.
Побудова розподіленої історичної схеми зберігання, щоб кожна Нода зберігала невелику кількість застарілих історичних даних. Максимізація надійності за допомогою технології кодів корекції помилок. Це дозволяє забезпечити характеристику «постійного зберігання блокчейну», не покладаючись на централізованих постачальників або накладаючи важке навантаження на операторів Нод.
Скоригуйте свою стратегію ціноутворення на газ, щоб збільшити витрати на зберігання та зменшити витрати на виконання. Зосередьтеся на збільшенні вартості газу для наступних операцій: (i) Виконати SSTORE для нового слота для зберігання, (ii) створити код договору, (iii) Перекажіть ETH на рахунок з нульовим балансом/нульовим балансом.
3, Середньострокова мета: безстанова верифікація
Після реалізації безстатевої верифікації, запуск вузлів, які підтримують RPC (тобто вузлів, що зберігають стан), не вимагатиме зберігання меркл-гілок стану. Це зможе знизити вимоги до зберігання ще приблизно на 50%.
4, Новий тип ноди: часткові безстатеві ноди
Ця інноваційна концепція стане ключовою для підтримки роботи особистих Нод навіть після збільшення ліміту газу L1 у 10-100 разів.
Ми додали новий тип Ноди: верифікація блоків без збереження стану, верифікація всієї ланцюга через безстатеву верифікацію або ZK-EVM, але зберігаючи лише частину даних стану. Якщо дані, необхідні для запиту RPC, знаходяться в цьому підмножині стану, Нода зможе відповісти; інші запити зазнають невдачі (або потрібно буде повернутися до зовнішнього управлінського криптографічного рішення — чи повертатися, повинні вибирати користувачі).
!
Конкретні стани, які потрібно підтримувати, залежать від налаштувань користувача, наприклад:
Конфігурацією можна керувати за допомогою ончейн-контракту: коли користувач запускає вузол, використовуйте "--save_state_by_config 0x12345... 67890", який визначить список адрес, слотів зберігання або фільтрів станів, які необхідно зберегти та оновити в режимі реального часу вузлом на певній мові. Зверніть увагу, що користувачеві не потрібно зберігати гілку Merkle, тільки оригінальне значення.
Цей тип ноди забезпечує як місцевий прямий доступ до ключових станів, так і повну конфіденційність доступу.