Ethereum легкий клієнт Helios: реалізація доступу до Блокчейн без довіри
8 листопада офіційно запущено новий легкий клієнт Ethereum Helios. Цей клієнт розроблений на мові Rust і покликаний забезпечити повністю бездокладний доступ до Ethereum.
Основною метою використання Блокчейн є досягнення без необхідності у довірі. Через Блокчейн ми можемо самостійно контролювати своє багатство та дані. У більшості випадків, Ethereum та інші Блокчейн дійсно виконали цю обіцянку: наші активи справді належать нам.
Проте, для досягнення зручності ми також зробили деякі компроміси. Одним з них є використання централізованого RPC( для віддаленого виклику ) серверів. Користувачі зазвичай отримують доступ до Ethereum через централізованих постачальників. Ці компанії запускають високопродуктивні вузли на хмарних серверах, допомагаючи всім легко отримувати дані з блокчейну. Коли гаманець запитує баланс токенів або перевіряє статус транзакції, майже завжди використовуються ці централізовані постачальники.
Проблема поточної системи полягає в тому, що користувачі повинні довіряти цим постачальникам і не можуть перевірити, чи є результати запиту правильними.
Helios є легким клієнтом Ethereum, створеним на основі Rust, який може забезпечити повністю бездовірчий доступ до Ethereum. Він використовує протокол легкого клієнта, реалізований після переходу Ethereum на PoS, для перетворення даних з ненадійних централізованих постачальників RPC на безпечні та перевірені локальні RPC. У поєднанні з централізованим RPC, Helios може перевіряти достовірність даних без необхідності запускати повний вузол.
Цей клієнт може завершити синхронізацію приблизно за дві секунди та не потребує зберігання, користувачі можуть безпечно отримувати доступ до даних в ланцюгу з будь-якого пристрою (, включаючи мобільні телефони та браузерні плагіни ). Але які потенційні ризики пов'язані із залежністю від централізованої інфраструктури? Наступні розділи проаналізують ці ризики, представлять рішення дизайну Helios та нададуть деякі думки для вдосконалення кодової бази.
Потенційні ризики централізованої інфраструктури
Одним з теоретичних способів атаки є潜伏 в "чорному лісі" Ethereum. Це не пошук цілей у пулі транзакцій, а створення пасток шляхом імітації централізованої інфраструктури, на яку ми покладаємося. Користувачі, навіть не помиляючись, можуть потрапити в пастку: вони просто торгують на DEX, встановлюючи розумний сліп, ... але все ж можуть зіткнутися з новим типом сандвіч-атаки, яка є ретельно налаштованою пасткою у постачальника RPC.
При обробці транзакцій на децентралізованій біржі користувачам потрібно надати кілька параметрів для смарт-контракту: токени, які потрібно обміняти, суму обміну та, найголовніше, мінімальну кількість токенів, яку користувач готовий прийняти. Останній параметр вказує на "мінімальний вихід", якого потрібно досягти під час обміну, інакше транзакція буде скасована. Це зазвичай називається "сліпом", він ефективно встановлює максимальну різницю в ціні, яка може виникнути між відправкою транзакції та її внесенням до блокчейну. Якщо сліп встановлений занадто низько, користувач може отримати менше токенів і навіть піддатися атаці "сендвіч".
Якщо параметри мінімального виходу встановлені в розумних межах, то атаки "сендвіч" не будуть можливі. Але що, якщо постачальник RPC не надає точні котирування смарт-контракту DEX? Це може ввести користувачів в оману, змушуючи їх підписувати обмінні транзакції з нижчими параметрами мінімального виходу. Ще гірше, користувачі можуть прямо надсилати транзакції зловмисному постачальнику RPC. Постачальник може не транслювати транзакцію до публічного мемпулу, а замість цього утримувати її приватно і безпосередньо надсилати пакет атакованих транзакцій певним установам для отримання прибутку.
Основною причиною цієї атаки є довіра до інших для отримання стану Блокчейн. Щоб вирішити цю проблему, досвідчені користувачі зазвичай запускають власні вузли Ethereum, але це вимагає значних затрат часу та ресурсів, принаймні одного постійно онлайн пристрою, кількох сотень ГБ місця для зберігання та приблизно одного дня для синхронізації з нуля. Хоча зараз поріг для запуску вузлів знижено, для більшості користувачів це все ще важко, особливо для тих, хто використовує мобільні пристрої.
Слід зазначити, що атаки централізованих RPC-провайдерів, хоча і цілком можливі, зазвичай є простою фішинговою атакою, тип атаки, про яку ми говоримо, ще не відбулася. Незважаючи на те, що минулі записи провідних провайдерів викликають довіру, перед використанням незнайомих RPC-провайдерів все ж варто провести більше досліджень.
Helios: реалізація бездокументного доступу до Ethereum
Ethereum запровадив протокол легкого клієнта, відкриваючи нові можливості для швидкої взаємодії з Блокчейн та верифікації RPC-ендпоінтів з мінімальними вимогами до апаратного забезпечення. Протягом місяця після The Merge було випущено кілька незалежних легких клієнтів, які використовують різні методи, але мають однакову мету: забезпечити ефективний доступ без довіри без необхідності запуску повних вузлів.
Helios є легким клієнтом Ethereum, який може завершити синхронізацію приблизно за дві секунди, не вимагаючи зберігання, і забезпечує повноцінний доступ до Ethereum без довіри. Як і всі клієнти Ethereum, Helios містить виконавчий шар і шар консенсусу. Але на відміну від більшості клієнтів, Helios тісно поєднує ці два шари, тому користувачам потрібно лише встановити та запустити одне програмне забезпечення.
Принцип роботи Helios такий: рівень консенсусу використовує відомий хеш блоку сигнальної ланцюга та підключає ненадійний RPC, щоб у верифікаційний спосіб синхронізуватися до поточного блоку. Рівень виконання поєднує ці перевірені блоки сигнальної ланцюга з ненадійним RPC рівня виконання, щоб перевірити різну інформацію про стан ланцюга, таку як баланс рахунку, зберігання контракту, квитанції про транзакції та результати викликів смарт-контрактів. Ці компоненти працюють разом, щоб надати користувачам повністю ненадійний RPC, без необхідності запускати повний вузол.
Шар консенсусу
Консенсусний рівень легкого клієнта дотримується специфікацій легкого клієнта Beacon Chain, використовуючи синхронізаційний комітет Beacon Chain. Синхронізаційний комітет складається з випадково обраних 512 валідаторів, термін служби яких становить приблизно 27 годин.
Після входу валідаторів до синхронного комітету, вони підпишуть всі побачені заголовки блоків сигналізації. Якщо понад 2/3 членів комітету підпишуть заголовок блоку, то цей блок, ймовірно, знаходиться в стандартному ланцюгу сигналізації. Якщо Helios знає склад поточного синхронного комітету, він може надійно відслідковувати голову ланцюга, запитуючи нещодавні підписи синхронного комітету.
Завдяки агрегації BLS-підписів, достатньо одного запиту для завершення перевірки нового заголовка блоку. Якщо підпис дійсний і більше 2/3 членів комітету завершили підпис, це гарантує, що блок включено в ланцюг. Звісно, відстеження фінальності блоку може забезпечити більш надійну гарантію.
У цій стратегії також потрібно вирішити, як знайти проблему поточного синхронізаційного комітету. Перш за все, необхідно отримати довірений корінь, який називається перевіркою слабкої суб'єктивності. Він представляє собою старий хеш блоку, який можна гарантувати, що був включений у ланцюг у певний момент минулого. Щодо часу існування контрольної точки, теоретичний аналіз показує, що в найгіршому випадку це близько двох тижнів, тоді як фактична оцінка може досягати кількох місяців.
Якщо контрольна точка занадто стара, теоретично існує можливість обманути вузли, щоб вони слідували за помилковим ланцюгом. У цьому випадку отримання контрольної точки зі слабкою суб'єктивністю виходить за межі можливостей протоколу. Рішення Helios полягає в наданні початкової контрольної точки, зафіксованої в кодовій базі, (, що легко може бути перекрите ); вона зберігатиме останній остаточний хеш блоку локально, щоб використовувати його як контрольну точку під час синхронізації вузлів.
Через хеш-операції, блоки сигнальної мережі можуть легко генерувати унікальний хеш блоку сигналу. Це дозволяє легко запитувати повний блок сигналу, а потім за допомогою порівняння хешів підтверджувати дійсність вмісту блоку. Helios використовує цю властивість для отримання та перевірки ключових полів в блоках контрольних точок з слабкою суб'єктивністю, включаючи поточну синхронізаційну комісію та наступну синхронізаційну комісію. Найважливіше, що легкі клієнти можуть використовувати цей механізм для швидкого перегляду історії блокчейну.
Маючи контрольні точки з слабкою суб'єктивністю, ми можемо отримати та перевірити поточний та наступний синхронний комітет. Якщо поточний заголовок блоку та контрольна точка знаходяться в одному циклі синхронного комітету, ми можемо негайно використовувати підписаний заголовок синхронного комітету для перевірки нового блоку. Якщо контрольна точка йде після кількох синхронних комітетів, тоді можна:
Використовуйте наступний синхронний комітет після контрольної точки, щоб отримати та перевірити блок, який буде згенеровано в майбутньому синхронним комітетом.
Використовуйте цей новий блок для отримання наступного комітету синхронізації.
Якщо контрольна точка ще позаду, поверніться до кроку 1.
Завдяки наведеному процесу ми можемо швидко переглядати історію цього блокчейну за одиницею часу в 27 годин, починаючи з будь-якого хешу блоку з минулого і синхронізуючись до поточного хешу блоку.
Виконавчий рівень
Метою легкого клієнта виконавчого шару є поєднання заголовків сигналів блоків, перевірених на рівні консенсусу, з ненадійними RPC виконавчого шару, щоб надати перевірені дані виконавчого шару. Ці дані можна отримати через Helios на локальному сервері RPC.
Наступний простий приклад отримання балансу рахунку, спочатку коротко розглянемо, як Ethereum зберігає стан. Кожен рахунок містить кілька полів, таких як хеш коду контракту, випадкове число, хеш зберігання та баланс. Ці рахунки зберігаються в налаштованому великому дереві Merkle-Patricia, яке називається деревом стану. Знаючи лише корінь дерева стану, можна перевірити Merkle-докази, щоб підтвердити, чи існує будь-який рахунок у дереві. Цей доказ не може бути підроблений.
Helios отримує перевірений корінь стану з рівня консенсусу. Завдяки ненадійним RPC застосуванням цього кореня стану та запитам Меркле-доказів, Helios може локально перевіряти всі дані, що зберігаються в Ethereum.
Ми використовуємо різні технології для перевірки різних даних, які використовуються на рівні виконання, що дозволяє перевіряти всі дані з ненадійних RPC. Ненадійні RPC можуть відмовити у наданні доступу до даних, але не можуть надати неправильні результати.
Перспективи застосування Helios
Важко поєднати зручність і децентралізацію, що є поширеною проблемою. Завдяки легкому клієнту Helios користувачі можуть отримувати доступ до безпечних даних на Блокчейні з будь-якого пристрою (, включаючи мобільні телефони та браузерні плагіни ). Це дозволить більшій кількості людей отримувати доступ до даних Ethereum без необхідності у довірі, незалежно від використовуваного апаратного забезпечення. Користувачі можуть використовувати Helios як постачальника RPC у своїх гаманцях для отримання безпечного доступу до різних DApp, без жодних інших змін.
Крім того, підтримка Rust для WebAssembly дозволяє розробникам додатків легко вбудовувати Helios у Javascript-додатки (, такі як гаманці та DApp ). Ці інтеграції підвищать безпеку Ethereum і зменшать нашу залежність від централізованої інфраструктури.
Спільнота може внести свій внесок у Helios різними способами, окрім вдосконалення кодової бази, також можна створювати програмне забезпечення, інтегроване з Helios, щоб скористатися його перевагами. Ось кілька потенційних напрямків розвитку:
Підтримка прямого отримання даних легкого клієнта з P2P-мережі, а не покладаючись на RPC
Реалізувати відсутні RPC-методи
Розробка версії Helios, яка може компілюватися до WebAssembly
Інтегрувати Helios безпосередньо у програмне забезпечення гаманця
Створити мережеву панель для перегляду залишків токенів, вбудувати Helios у веб-сайт, що використовує WebAssembly, для отримання даних
Розгортання API двигуна, підключення шару консенсусу Helios до повного вузла існуючого виконавчого шару
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Helios легкий клієнт: реалізація повністю довіреного доступу до даних у блокчейні Ethereum
Ethereum легкий клієнт Helios: реалізація доступу до Блокчейн без довіри
8 листопада офіційно запущено новий легкий клієнт Ethereum Helios. Цей клієнт розроблений на мові Rust і покликаний забезпечити повністю бездокладний доступ до Ethereum.
Основною метою використання Блокчейн є досягнення без необхідності у довірі. Через Блокчейн ми можемо самостійно контролювати своє багатство та дані. У більшості випадків, Ethereum та інші Блокчейн дійсно виконали цю обіцянку: наші активи справді належать нам.
Проте, для досягнення зручності ми також зробили деякі компроміси. Одним з них є використання централізованого RPC( для віддаленого виклику ) серверів. Користувачі зазвичай отримують доступ до Ethereum через централізованих постачальників. Ці компанії запускають високопродуктивні вузли на хмарних серверах, допомагаючи всім легко отримувати дані з блокчейну. Коли гаманець запитує баланс токенів або перевіряє статус транзакції, майже завжди використовуються ці централізовані постачальники.
Проблема поточної системи полягає в тому, що користувачі повинні довіряти цим постачальникам і не можуть перевірити, чи є результати запиту правильними.
Helios є легким клієнтом Ethereum, створеним на основі Rust, який може забезпечити повністю бездовірчий доступ до Ethereum. Він використовує протокол легкого клієнта, реалізований після переходу Ethereum на PoS, для перетворення даних з ненадійних централізованих постачальників RPC на безпечні та перевірені локальні RPC. У поєднанні з централізованим RPC, Helios може перевіряти достовірність даних без необхідності запускати повний вузол.
Цей клієнт може завершити синхронізацію приблизно за дві секунди та не потребує зберігання, користувачі можуть безпечно отримувати доступ до даних в ланцюгу з будь-якого пристрою (, включаючи мобільні телефони та браузерні плагіни ). Але які потенційні ризики пов'язані із залежністю від централізованої інфраструктури? Наступні розділи проаналізують ці ризики, представлять рішення дизайну Helios та нададуть деякі думки для вдосконалення кодової бази.
Потенційні ризики централізованої інфраструктури
Одним з теоретичних способів атаки є潜伏 в "чорному лісі" Ethereum. Це не пошук цілей у пулі транзакцій, а створення пасток шляхом імітації централізованої інфраструктури, на яку ми покладаємося. Користувачі, навіть не помиляючись, можуть потрапити в пастку: вони просто торгують на DEX, встановлюючи розумний сліп, ... але все ж можуть зіткнутися з новим типом сандвіч-атаки, яка є ретельно налаштованою пасткою у постачальника RPC.
При обробці транзакцій на децентралізованій біржі користувачам потрібно надати кілька параметрів для смарт-контракту: токени, які потрібно обміняти, суму обміну та, найголовніше, мінімальну кількість токенів, яку користувач готовий прийняти. Останній параметр вказує на "мінімальний вихід", якого потрібно досягти під час обміну, інакше транзакція буде скасована. Це зазвичай називається "сліпом", він ефективно встановлює максимальну різницю в ціні, яка може виникнути між відправкою транзакції та її внесенням до блокчейну. Якщо сліп встановлений занадто низько, користувач може отримати менше токенів і навіть піддатися атаці "сендвіч".
Якщо параметри мінімального виходу встановлені в розумних межах, то атаки "сендвіч" не будуть можливі. Але що, якщо постачальник RPC не надає точні котирування смарт-контракту DEX? Це може ввести користувачів в оману, змушуючи їх підписувати обмінні транзакції з нижчими параметрами мінімального виходу. Ще гірше, користувачі можуть прямо надсилати транзакції зловмисному постачальнику RPC. Постачальник може не транслювати транзакцію до публічного мемпулу, а замість цього утримувати її приватно і безпосередньо надсилати пакет атакованих транзакцій певним установам для отримання прибутку.
Основною причиною цієї атаки є довіра до інших для отримання стану Блокчейн. Щоб вирішити цю проблему, досвідчені користувачі зазвичай запускають власні вузли Ethereum, але це вимагає значних затрат часу та ресурсів, принаймні одного постійно онлайн пристрою, кількох сотень ГБ місця для зберігання та приблизно одного дня для синхронізації з нуля. Хоча зараз поріг для запуску вузлів знижено, для більшості користувачів це все ще важко, особливо для тих, хто використовує мобільні пристрої.
Слід зазначити, що атаки централізованих RPC-провайдерів, хоча і цілком можливі, зазвичай є простою фішинговою атакою, тип атаки, про яку ми говоримо, ще не відбулася. Незважаючи на те, що минулі записи провідних провайдерів викликають довіру, перед використанням незнайомих RPC-провайдерів все ж варто провести більше досліджень.
Helios: реалізація бездокументного доступу до Ethereum
Ethereum запровадив протокол легкого клієнта, відкриваючи нові можливості для швидкої взаємодії з Блокчейн та верифікації RPC-ендпоінтів з мінімальними вимогами до апаратного забезпечення. Протягом місяця після The Merge було випущено кілька незалежних легких клієнтів, які використовують різні методи, але мають однакову мету: забезпечити ефективний доступ без довіри без необхідності запуску повних вузлів.
Helios є легким клієнтом Ethereum, який може завершити синхронізацію приблизно за дві секунди, не вимагаючи зберігання, і забезпечує повноцінний доступ до Ethereum без довіри. Як і всі клієнти Ethereum, Helios містить виконавчий шар і шар консенсусу. Але на відміну від більшості клієнтів, Helios тісно поєднує ці два шари, тому користувачам потрібно лише встановити та запустити одне програмне забезпечення.
Принцип роботи Helios такий: рівень консенсусу використовує відомий хеш блоку сигнальної ланцюга та підключає ненадійний RPC, щоб у верифікаційний спосіб синхронізуватися до поточного блоку. Рівень виконання поєднує ці перевірені блоки сигнальної ланцюга з ненадійним RPC рівня виконання, щоб перевірити різну інформацію про стан ланцюга, таку як баланс рахунку, зберігання контракту, квитанції про транзакції та результати викликів смарт-контрактів. Ці компоненти працюють разом, щоб надати користувачам повністю ненадійний RPC, без необхідності запускати повний вузол.
Шар консенсусу
Консенсусний рівень легкого клієнта дотримується специфікацій легкого клієнта Beacon Chain, використовуючи синхронізаційний комітет Beacon Chain. Синхронізаційний комітет складається з випадково обраних 512 валідаторів, термін служби яких становить приблизно 27 годин.
Після входу валідаторів до синхронного комітету, вони підпишуть всі побачені заголовки блоків сигналізації. Якщо понад 2/3 членів комітету підпишуть заголовок блоку, то цей блок, ймовірно, знаходиться в стандартному ланцюгу сигналізації. Якщо Helios знає склад поточного синхронного комітету, він може надійно відслідковувати голову ланцюга, запитуючи нещодавні підписи синхронного комітету.
Завдяки агрегації BLS-підписів, достатньо одного запиту для завершення перевірки нового заголовка блоку. Якщо підпис дійсний і більше 2/3 членів комітету завершили підпис, це гарантує, що блок включено в ланцюг. Звісно, відстеження фінальності блоку може забезпечити більш надійну гарантію.
У цій стратегії також потрібно вирішити, як знайти проблему поточного синхронізаційного комітету. Перш за все, необхідно отримати довірений корінь, який називається перевіркою слабкої суб'єктивності. Він представляє собою старий хеш блоку, який можна гарантувати, що був включений у ланцюг у певний момент минулого. Щодо часу існування контрольної точки, теоретичний аналіз показує, що в найгіршому випадку це близько двох тижнів, тоді як фактична оцінка може досягати кількох місяців.
Якщо контрольна точка занадто стара, теоретично існує можливість обманути вузли, щоб вони слідували за помилковим ланцюгом. У цьому випадку отримання контрольної точки зі слабкою суб'єктивністю виходить за межі можливостей протоколу. Рішення Helios полягає в наданні початкової контрольної точки, зафіксованої в кодовій базі, (, що легко може бути перекрите ); вона зберігатиме останній остаточний хеш блоку локально, щоб використовувати його як контрольну точку під час синхронізації вузлів.
Через хеш-операції, блоки сигнальної мережі можуть легко генерувати унікальний хеш блоку сигналу. Це дозволяє легко запитувати повний блок сигналу, а потім за допомогою порівняння хешів підтверджувати дійсність вмісту блоку. Helios використовує цю властивість для отримання та перевірки ключових полів в блоках контрольних точок з слабкою суб'єктивністю, включаючи поточну синхронізаційну комісію та наступну синхронізаційну комісію. Найважливіше, що легкі клієнти можуть використовувати цей механізм для швидкого перегляду історії блокчейну.
Маючи контрольні точки з слабкою суб'єктивністю, ми можемо отримати та перевірити поточний та наступний синхронний комітет. Якщо поточний заголовок блоку та контрольна точка знаходяться в одному циклі синхронного комітету, ми можемо негайно використовувати підписаний заголовок синхронного комітету для перевірки нового блоку. Якщо контрольна точка йде після кількох синхронних комітетів, тоді можна:
Використовуйте наступний синхронний комітет після контрольної точки, щоб отримати та перевірити блок, який буде згенеровано в майбутньому синхронним комітетом.
Використовуйте цей новий блок для отримання наступного комітету синхронізації.
Якщо контрольна точка ще позаду, поверніться до кроку 1.
Завдяки наведеному процесу ми можемо швидко переглядати історію цього блокчейну за одиницею часу в 27 годин, починаючи з будь-якого хешу блоку з минулого і синхронізуючись до поточного хешу блоку.
Виконавчий рівень
Метою легкого клієнта виконавчого шару є поєднання заголовків сигналів блоків, перевірених на рівні консенсусу, з ненадійними RPC виконавчого шару, щоб надати перевірені дані виконавчого шару. Ці дані можна отримати через Helios на локальному сервері RPC.
Наступний простий приклад отримання балансу рахунку, спочатку коротко розглянемо, як Ethereum зберігає стан. Кожен рахунок містить кілька полів, таких як хеш коду контракту, випадкове число, хеш зберігання та баланс. Ці рахунки зберігаються в налаштованому великому дереві Merkle-Patricia, яке називається деревом стану. Знаючи лише корінь дерева стану, можна перевірити Merkle-докази, щоб підтвердити, чи існує будь-який рахунок у дереві. Цей доказ не може бути підроблений.
Helios отримує перевірений корінь стану з рівня консенсусу. Завдяки ненадійним RPC застосуванням цього кореня стану та запитам Меркле-доказів, Helios може локально перевіряти всі дані, що зберігаються в Ethereum.
Ми використовуємо різні технології для перевірки різних даних, які використовуються на рівні виконання, що дозволяє перевіряти всі дані з ненадійних RPC. Ненадійні RPC можуть відмовити у наданні доступу до даних, але не можуть надати неправильні результати.
Перспективи застосування Helios
Важко поєднати зручність і децентралізацію, що є поширеною проблемою. Завдяки легкому клієнту Helios користувачі можуть отримувати доступ до безпечних даних на Блокчейні з будь-якого пристрою (, включаючи мобільні телефони та браузерні плагіни ). Це дозволить більшій кількості людей отримувати доступ до даних Ethereum без необхідності у довірі, незалежно від використовуваного апаратного забезпечення. Користувачі можуть використовувати Helios як постачальника RPC у своїх гаманцях для отримання безпечного доступу до різних DApp, без жодних інших змін.
Крім того, підтримка Rust для WebAssembly дозволяє розробникам додатків легко вбудовувати Helios у Javascript-додатки (, такі як гаманці та DApp ). Ці інтеграції підвищать безпеку Ethereum і зменшать нашу залежність від централізованої інфраструктури.
Спільнота може внести свій внесок у Helios різними способами, окрім вдосконалення кодової бази, також можна створювати програмне забезпечення, інтегроване з Helios, щоб скористатися його перевагами. Ось кілька потенційних напрямків розвитку: