a16z Crypto запустила легкий клієнт Helios: забезпечення справжнього бездоверчого доступу до Ethereum
8 листопада 2023 року a16z Crypto випустила легкий клієнт Ethereum Helios, цей інструмент, розроблений на основі мови Rust, має на меті забезпечити повністю довірений доступ до мережі Ethereum.
Однією з основних цінностей технології блокчейн є те, що користувачам не потрібно покладатися на довіру третьої сторони, що дозволяє їм справжнім чином контролювати свої фінанси та дані. Блокчейни, такі як Ethereum, в значній мірі реалізували цю обіцянку, забезпечуючи, що наші активи насправді належать нам.
Однак заради зручності більшість користувачів йдуть на деякі компроміси при використанні блокчейна. Одним з найбільш очевидних компромісів є залежність від централізованих RPC( віддалених дзвінків ) серверах. Користувачі зазвичай отримують доступ до мережі Ethereum через певних централізованих постачальників послуг. Ці компанії використовують високопродуктивні вузли на хмарних серверах, щоб допомогти користувачам легко отримати доступ до даних у ланцюжку. Коли гаманець запитує баланс токенів або перевіряє статус транзакції, це майже завжди робиться через ці централізовані сервіси.
Основна проблема існуючої системи полягає в тому, що користувачі повинні довіряти цим постачальникам і не можуть самостійно перевірити точність отриманої інформації.
Helios:легкий клієнт і повністю перевіряється
Як легкий клієнт Ethereum на основі Rust, Helios здатний забезпечити зручний доступ до блокчейну без шкоди для безпеки. Він використовує протокол легкого клієнта, запроваджений після переходу Ethereum на PoS, для перетворення даних від ненадійних централізованих постачальників RPC у безпечні та перевірені рідні RPC. Працюючи з централізованим RPC, Helios здатний перевіряти достовірність даних без запуску повноцінного вузла.
Цей легкий клієнт може завершити синхронізацію приблизно за дві секунди, не вимагаючи додаткового місця для зберігання, користувачі можуть отримувати безпечний доступ до даних на ланцюгу з будь-якого пристрою (, включаючи мобільні телефони та браузерні плагіни ).
Потенційні ризики централізованої інфраструктури
У "чорному лісі" Ethereum ховаються теоретичні ризики. Ці ризики не походять з атак на передню частину в мемпулі (Mempool), а виникають через імітацію пасток на централізованій інфраструктурі, на яку ми покладаємось.
Користувачі, які стали жертвами таких атак, можливо, не зробили жодної помилки: вони просто відвідали звичайний DEX, встановили розумний сліп, провели нормальну торгівлю токенами. Однак вони все ще можуть стикнутися з особливим типом атак-сендвічів, які ховаються на вході до Ethereum — у постачальника RPC.
Коли користувач виконує транзакцію на DEX, смарт-контракту надається кілька параметрів: токен, яким буде торгуватися, кількість транзакцій і мінімальна кількість токенів, яку користувач готовий прийняти ( тобто прослизання ). Якщо прослизання налаштоване правильно, користувач теоретично не постраждає від сендвіч-атаки. Але що робити, якщо постачальник RPC не надає точну цінову пропозицію для контракту DEX? Користувачі можуть бути введені в оману, змушуючи підписувати транзакції з нижчою мінімальною сумою прийняття. Що ще гірше, користувачі можуть надсилати транзакції безпосередньо зловмисним постачальникам RPC, які можуть зберігати ці транзакції в таємниці та надсилати їх безпосередньо виробникам блоків через певні канали для отримання прибутку.
Основною причиною цього типу атак є необхідність для користувачів покладатися на третю сторону для стану блокчейну. Щоб вирішити цю проблему, досвідчені користувачі часто вибирають запуск власного вузла Ethereum, але для цього потрібні значні витрати часу та ресурсів: як мінімум пристрій, який постійно перебуває в мережі, сотні гігабайт сховища та близько доби на синхронізацію. Хоча цей процес набагато простіший, ніж раніше, він все ще складний для більшості користувачів, особливо мобільних користувачів.
Необхідно зазначити, що, хоча атаки з боку централізованих постачальників RPC теоретично цілком можливі, наразі не було виявлено випадків такої поведінки з боку великих, відомих постачальників. Проте перед додаванням незнайомих постачальників RPC до гаманця все ж необхідно провести ретельне дослідження.
Принцип роботи Helios: глибокий аналіз
Впровадження Ethereum протоколу легкого клієнта створило нові можливості для швидкої взаємодії з блокчейном і перевірки кінцевих точок RPC з мінімальними вимогами до обладнання. Протягом місяця після (The Merge) злиття з'явилося кілька окремих проектів легких клієнтів, (Lodestar, Nimbus і Kevlar) на основі JavaScript, кожен з яких мав різний підхід. Але всі вони працюють над однією метою: забезпечити ефективний доступ без використання повної ноди.
Helios, як і всі клієнти Ethereum, складається з виконавчого та консенсусного рівнів. Але на відміну від більшості клієнтів, Helios тісно поєднує ці два рівні, і користувачеві потрібно лише встановити та запустити одне програмне забезпечення.
шар погодження
Легкий клієнт консенсусного шару Helios дотримується стандартів легкого клієнта сигнальної мережі, використовуючи синхронізаційний комітет сигнальної мережі (, що був впроваджений у жорсткому форку Altair ). Синхронізаційний комітет складається з випадково обраних 512 валідаторів і має період обслуговування приблизно 27 годин.
Валідатори підписують всі заголовки блоків сигнальної ланцюга, які вони бачать у синхронізаційній раді. Якщо більше двох третин членів ради підписали заголовок блоку, то цей блок майже напевно буде розташований у нормативному сигнальному ланцюзі. Коли Helios дізнається про склад поточної синхронізаційної ради, він може надійно відстежувати заголовок ланцюга, запитуючи останні підписи синхронізаційної ради.
Завдяки технології агрегації BLS-підписів, перевірку нового заголовка блоку можна виконати лише за один запит. Якщо підпис дійсний і більше двох третин членів комітету підписали його, це гарантує, що цей блок був включений до ланцюга.
Спочатку системі потрібно отримати слабку контрольну точку суб'єктивності (weak суб'єктивності checkpoint) як джерело довіри. Це хеш блоку, який гарантовано був включений в ланцюжок в якийсь момент в минулому. За допомогою цієї контрольної точки Helios може захоплювати та перевіряти поточний та наступний комітети синхронізації, щоб швидко переглянути історію блокчейну та синхронізуватися з останнім блоком.
виконавчий рівень
Мета легкого клієнта виконувального шару полягає в тому, щоб поєднати заголовок блоків сигналізації, перевірений на рівні консенсусу, з ненадійним RPC виконувального шару, щоб надати перевірені дані виконувального шару. Потім доступ до цих даних здійснюється через Helios на локально розміщеному сервері RPC.
Ethereum зберігає інформацію про рахунки за допомогою дерева станів, яке включає хеш коду контракту, випадкове число, хеш зберігання та баланс. Якщо відомий корінь дерева станів, можна перевірити доказ Меркле, щоб підтвердити, чи існує будь-який рахунок у дереві, і це підтвердження не може бути підроблене.
Helios отримує перевірений корінь стану з рівня консенсусу та поєднує його з запитом на Меркле-докази з ненадійного рівня виконання RPC, що реалізує локальну верифікацію всіх даних, зберігаються на Ethereum. Таким чином, ненадійний RPC може відмовити у наданні доступу до даних, але не може надати помилковий результат.
Реальні застосування Helios
Легкий дизайн Helios дозволяє користувачам безпечно отримувати доступ до даних в блокчейні з будь-якого пристрою (, включаючи мобільні телефони та браузерні плагіни ). Користувачі можуть налаштувати Helios як постачальника RPC у MetaMask, щоб без довіри отримувати доступ до різних DApp без будь-яких інших змін.
Крім того, хороша підтримка Rust для WebAssembly дозволяє розробникам застосунків легко вбудовувати Helios у JavaScript-додатки (, такі як гаманці та DApp ). Ці інтеграції підвищать безпеку Ethereum, зменшуючи залежність від централізованої інфраструктури.
Спільнота може внести свій внесок у Helios різними способами, зокрема:
Підтримка прямого отримання даних легкого клієнта з P2P мережі
Реалізувати відсутні RPC-методи
Побудова версії Helios, що може бути скомпільована в WebAssembly
Інтегрувати Helios безпосередньо в програмне забезпечення гаманця
Створити панель моніторингу мережі для перегляду залишків токенів
Підключіть рівень консенсусу Helios до існуючого повного вузла рівня виконання
Ця бібліотека коду проекту вже відкритий вихідний код, запрошуємо зацікавлених розробників долучитися до внесків.
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
a16z представила легкий клієнт Helios: новий спосіб доступу до Ethereum без довіри
a16z Crypto запустила легкий клієнт Helios: забезпечення справжнього бездоверчого доступу до Ethereum
8 листопада 2023 року a16z Crypto випустила легкий клієнт Ethereum Helios, цей інструмент, розроблений на основі мови Rust, має на меті забезпечити повністю довірений доступ до мережі Ethereum.
Однією з основних цінностей технології блокчейн є те, що користувачам не потрібно покладатися на довіру третьої сторони, що дозволяє їм справжнім чином контролювати свої фінанси та дані. Блокчейни, такі як Ethereum, в значній мірі реалізували цю обіцянку, забезпечуючи, що наші активи насправді належать нам.
Однак заради зручності більшість користувачів йдуть на деякі компроміси при використанні блокчейна. Одним з найбільш очевидних компромісів є залежність від централізованих RPC( віддалених дзвінків ) серверах. Користувачі зазвичай отримують доступ до мережі Ethereum через певних централізованих постачальників послуг. Ці компанії використовують високопродуктивні вузли на хмарних серверах, щоб допомогти користувачам легко отримати доступ до даних у ланцюжку. Коли гаманець запитує баланс токенів або перевіряє статус транзакції, це майже завжди робиться через ці централізовані сервіси.
Основна проблема існуючої системи полягає в тому, що користувачі повинні довіряти цим постачальникам і не можуть самостійно перевірити точність отриманої інформації.
Helios:легкий клієнт і повністю перевіряється
Як легкий клієнт Ethereum на основі Rust, Helios здатний забезпечити зручний доступ до блокчейну без шкоди для безпеки. Він використовує протокол легкого клієнта, запроваджений після переходу Ethereum на PoS, для перетворення даних від ненадійних централізованих постачальників RPC у безпечні та перевірені рідні RPC. Працюючи з централізованим RPC, Helios здатний перевіряти достовірність даних без запуску повноцінного вузла.
Цей легкий клієнт може завершити синхронізацію приблизно за дві секунди, не вимагаючи додаткового місця для зберігання, користувачі можуть отримувати безпечний доступ до даних на ланцюгу з будь-якого пристрою (, включаючи мобільні телефони та браузерні плагіни ).
Потенційні ризики централізованої інфраструктури
У "чорному лісі" Ethereum ховаються теоретичні ризики. Ці ризики не походять з атак на передню частину в мемпулі (Mempool), а виникають через імітацію пасток на централізованій інфраструктурі, на яку ми покладаємось.
Користувачі, які стали жертвами таких атак, можливо, не зробили жодної помилки: вони просто відвідали звичайний DEX, встановили розумний сліп, провели нормальну торгівлю токенами. Однак вони все ще можуть стикнутися з особливим типом атак-сендвічів, які ховаються на вході до Ethereum — у постачальника RPC.
Коли користувач виконує транзакцію на DEX, смарт-контракту надається кілька параметрів: токен, яким буде торгуватися, кількість транзакцій і мінімальна кількість токенів, яку користувач готовий прийняти ( тобто прослизання ). Якщо прослизання налаштоване правильно, користувач теоретично не постраждає від сендвіч-атаки. Але що робити, якщо постачальник RPC не надає точну цінову пропозицію для контракту DEX? Користувачі можуть бути введені в оману, змушуючи підписувати транзакції з нижчою мінімальною сумою прийняття. Що ще гірше, користувачі можуть надсилати транзакції безпосередньо зловмисним постачальникам RPC, які можуть зберігати ці транзакції в таємниці та надсилати їх безпосередньо виробникам блоків через певні канали для отримання прибутку.
Основною причиною цього типу атак є необхідність для користувачів покладатися на третю сторону для стану блокчейну. Щоб вирішити цю проблему, досвідчені користувачі часто вибирають запуск власного вузла Ethereum, але для цього потрібні значні витрати часу та ресурсів: як мінімум пристрій, який постійно перебуває в мережі, сотні гігабайт сховища та близько доби на синхронізацію. Хоча цей процес набагато простіший, ніж раніше, він все ще складний для більшості користувачів, особливо мобільних користувачів.
Необхідно зазначити, що, хоча атаки з боку централізованих постачальників RPC теоретично цілком можливі, наразі не було виявлено випадків такої поведінки з боку великих, відомих постачальників. Проте перед додаванням незнайомих постачальників RPC до гаманця все ж необхідно провести ретельне дослідження.
Принцип роботи Helios: глибокий аналіз
Впровадження Ethereum протоколу легкого клієнта створило нові можливості для швидкої взаємодії з блокчейном і перевірки кінцевих точок RPC з мінімальними вимогами до обладнання. Протягом місяця після (The Merge) злиття з'явилося кілька окремих проектів легких клієнтів, (Lodestar, Nimbus і Kevlar) на основі JavaScript, кожен з яких мав різний підхід. Але всі вони працюють над однією метою: забезпечити ефективний доступ без використання повної ноди.
Helios, як і всі клієнти Ethereum, складається з виконавчого та консенсусного рівнів. Але на відміну від більшості клієнтів, Helios тісно поєднує ці два рівні, і користувачеві потрібно лише встановити та запустити одне програмне забезпечення.
шар погодження
Легкий клієнт консенсусного шару Helios дотримується стандартів легкого клієнта сигнальної мережі, використовуючи синхронізаційний комітет сигнальної мережі (, що був впроваджений у жорсткому форку Altair ). Синхронізаційний комітет складається з випадково обраних 512 валідаторів і має період обслуговування приблизно 27 годин.
Валідатори підписують всі заголовки блоків сигнальної ланцюга, які вони бачать у синхронізаційній раді. Якщо більше двох третин членів ради підписали заголовок блоку, то цей блок майже напевно буде розташований у нормативному сигнальному ланцюзі. Коли Helios дізнається про склад поточної синхронізаційної ради, він може надійно відстежувати заголовок ланцюга, запитуючи останні підписи синхронізаційної ради.
Завдяки технології агрегації BLS-підписів, перевірку нового заголовка блоку можна виконати лише за один запит. Якщо підпис дійсний і більше двох третин членів комітету підписали його, це гарантує, що цей блок був включений до ланцюга.
Спочатку системі потрібно отримати слабку контрольну точку суб'єктивності (weak суб'єктивності checkpoint) як джерело довіри. Це хеш блоку, який гарантовано був включений в ланцюжок в якийсь момент в минулому. За допомогою цієї контрольної точки Helios може захоплювати та перевіряти поточний та наступний комітети синхронізації, щоб швидко переглянути історію блокчейну та синхронізуватися з останнім блоком.
виконавчий рівень
Мета легкого клієнта виконувального шару полягає в тому, щоб поєднати заголовок блоків сигналізації, перевірений на рівні консенсусу, з ненадійним RPC виконувального шару, щоб надати перевірені дані виконувального шару. Потім доступ до цих даних здійснюється через Helios на локально розміщеному сервері RPC.
Ethereum зберігає інформацію про рахунки за допомогою дерева станів, яке включає хеш коду контракту, випадкове число, хеш зберігання та баланс. Якщо відомий корінь дерева станів, можна перевірити доказ Меркле, щоб підтвердити, чи існує будь-який рахунок у дереві, і це підтвердження не може бути підроблене.
Helios отримує перевірений корінь стану з рівня консенсусу та поєднує його з запитом на Меркле-докази з ненадійного рівня виконання RPC, що реалізує локальну верифікацію всіх даних, зберігаються на Ethereum. Таким чином, ненадійний RPC може відмовити у наданні доступу до даних, але не може надати помилковий результат.
Реальні застосування Helios
Легкий дизайн Helios дозволяє користувачам безпечно отримувати доступ до даних в блокчейні з будь-якого пристрою (, включаючи мобільні телефони та браузерні плагіни ). Користувачі можуть налаштувати Helios як постачальника RPC у MetaMask, щоб без довіри отримувати доступ до різних DApp без будь-яких інших змін.
Крім того, хороша підтримка Rust для WebAssembly дозволяє розробникам застосунків легко вбудовувати Helios у JavaScript-додатки (, такі як гаманці та DApp ). Ці інтеграції підвищать безпеку Ethereum, зменшуючи залежність від централізованої інфраструктури.
Спільнота може внести свій внесок у Helios різними способами, зокрема:
Ця бібліотека коду проекту вже відкритий вихідний код, запрошуємо зацікавлених розробників долучитися до внесків.