Ethereum легкий клієнт Helios: бездоверчий доступ до даних у блокчейні

8 листопада відома венчурна компанія представила легкий клієнт Ethereum Helios. Цей клієнт, написаний мовою Rust, має на меті забезпечити повністю бездоказовий доступ до Ethereum.

Однією з великих переваг технології блокчейн є те, що не потрібно довіряти третім особам. Завдяки блокчейну користувачі можуть самостійно контролювати свої багатства та дані. Блокчейни, такі як Ethereum, дійсно виконали цю обіцянку в більшості випадків: наші активи дійсно належать нам.

Однак, щоб досягти зручності, ми також зробили деякі компроміси. Один з них – це використання централізованих RPC (віддалених викликів) серверів. Користувачі зазвичай отримують доступ до Ethereum через централізованих постачальників. Ці компанії працюють на хмарних серверах, запускаючи високопродуктивні вузли, що допомагає користувачам легко отримувати дані у блокчейні. Коли гаманець запитує баланс токенів або перевіряє, чи були упаковані очікувані транзакції, ці послуги централізованих постачальників майже завжди використовуються.

Проблема поточної системи полягає в тому, що користувачі повинні довіряти цим постачальникам, не маючи можливості перевірити точність результатів запитів.

Helios є легким клієнтом Ethereum, основаним на Rust, який може забезпечити повністю бездостовірний доступ до Ethereum. Він використовує протокол легкого клієнта, реалізований після переходу Ethereum на PoS, щоб перетворювати дані з неперевірених централізованих RPC постачальників у безпечні та перевіряємо локальні RPC. У поєднанні з централізованим RPC, Helios може перевіряти достовірність даних без необхідності запускати повний вузол.

Важко забезпечити зручність і децентралізацію – це загальна проблема. Цей новий клієнт (відкритий для подальшої розробки публікою) може завершити синхронізацію приблизно за дві секунди і не потребує місця для зберігання, користувачі можуть безпечно отримувати доступ до даних у блокчейні з будь-якого пристрою (включаючи мобільні телефони та браузерні плагіни). Отже, які потенційні ризики залежності від централізованої інфраструктури? У цій статті ми детально розглянемо ці ризики, представимо дизайн Helios і надамо кілька порад, які допоможуть розробникам внести свій внесок у кодову базу.

Потенційні ризики централізованої інфраструктури: теоретичні загрози в екосистемі Ethereum

У екосистемі Ethereum існує теоретична загроза. Вона не шукає цілі в пулі пам'яті транзакцій (Mempool), а намагається створити пастки, імітуючи централізовану інфраструктуру, на яку ми покладаємося. Користувачі, які потрапляють у цю пастку, не зробили нічого поганого: вони просто заходять на знайомий DEX, встановлюють розумний сліп та здійснюють торгові операції з токенами... Їхні дії не містять жодних помилок, але вони можуть стати жертвами нового типу атак "сендвіч", яка є ретельно розставленою пасткою на вході до екосистеми Ethereum — постачальника RPC.

Перед тим, як детально пояснити, давайте спочатку подивимось, як DEX обробляє транзакції. Коли користувач здійснює обмін токенів, він надає смарт-контракту кілька параметрів: токени, які потрібно обміняти, суму обміну та, що найважливіше, мінімальну кількість токенів, яку користувач готовий прийняти. Останній параметр визначає "мінімальний вихід", якого потрібно досягти для обміну, в іншому випадку транзакція буде скасована. Це зазвичай називається "сліпом", оскільки він ефективно обмежує максимальні коливання цін, які можуть виникнути з моменту відправлення транзакції до мемпулу до упаковки в блок. Якщо сліп налаштований занадто низько, користувач може отримати лише невелику кількість токенів. Ця ситуація також може призвести до атаки "сендвіч", коли зловмисник може вставити транзакцію користувача між двома шкідливими транзакціями. Ці транзакції підвищують спотову ціну, змушуючи користувача здійснити угоду за несприятливою ціною. Потім зловмисник миттєво продає токени, отримуючи невеликий прибуток.

Якщо параметри мінімального виходу встановлені в межах розумного, користувач не постраждає від атаки «сендвіч». Але що, якщо постачальник RPC не надасть точну ціну DEX смарт-контракту? У такому випадку користувач може бути введений в оману, підписуючи угоду на обмін з низьким мінімальним виходом. Ще гірше, користувач може надіслати угоду безпосередньо зловмисному постачальнику RPC. Постачальник може вибрати не транслювати цю угоду в публічний мемпул (де багато роботів змагаються в атаках «сендвіч»), а натомість тримати її в таємниці і безпосередньо надіслати атакований пакет угод на певну платформу для отримання прибутку.

Корінна причина цієї атаки полягає в довірі до інших у отриманні стану у блокчейні. Щоб вирішити цю проблему, досвідчені користувачі зазвичай обирають запускати власний вузол Ethereum. Це вимагає значних витрат часу та ресурсів, принаймні, потрібен один пристрій, що постійно підключений до Інтернету, сотні ГБ місця для зберігання та приблизно один день часу для синхронізації з нуля. Хоча цей процес значно спростився порівняно з минулим, деякі команди продовжують працювати над допомогою користувачам у запуску вузлів за допомогою недорогого обладнання (наприклад, Raspberry Pi з зовнішнім жорстким диском). Але навіть якщо вимоги значно знижуються, для більшості користувачів, особливо для тих, хто використовує мобільні пристрої, запуск вузла залишається важким завданням.

Слід звернути увагу на те, що хоча атаки централізованих RPC постачальників цілком можливі, наразі це лише теоретичний ризик, насправді таких випадків ще не було. Незважаючи на те, що минулі записи основних постачальників заслуговують на довіру, все ж рекомендується провести ретельне дослідження перед додаванням незнайомих RPC постачальників у гаманець.

Опис Helios: повний доступ до Ethereum без необхідності довіряти

Протокол легкого клієнта, запущений Ethereum, відкрив захоплюючі можливості для швидкої взаємодії з у блокчейні та перевірки RPC-кінець з найнижчими вимогами до апаратного забезпечення. Протягом місяця після злиття з'явилося кілька незалежних легких клієнтів, які використовують різні підходи, але всі вони намагаються досягти однієї мети: ефективного доступу без довіри без використання повних вузлів.

Helios є легким клієнтом Ethereum, який може завершити синхронізацію приблизно за дві секунди, не потребуючи місця для зберігання, і забезпечує повністю бездокументований доступ до Ethereum. Як і всі клієнти Ethereum, Helios складається з виконавчого шару та шару консенсусу. Але на відміну від більшості інших клієнтів, Helios тісно поєднує ці два шари, що дозволяє користувачам встановлювати та запускати єдине програмне забезпечення.

Це працює так: консенсусний шар Helios використовує відомий хеш блоку сигнальної мережі та підключається до ненадійного RPC, щоб перевіреним способом синхронізуватися з поточним блоком. Виконавчий шар Helios об'єднує ці перевірені блоки сигнальної мережі з ненадійним RPC виконавчого шару для перевірки різної інформації про стан у блокчейні, такої як залишки рахунків, зберігання контрактів, квитанції про транзакції та результати викликів смарт-контрактів. Ці компоненти працюють разом, щоб надати користувачам повністю ненадійний RPC, без необхідності запускати повний вузол.

рівень консенсусу

Легкий клієнт рівня консенсусу дотримується стандартів легкого клієнта сигналізаційного ланцюга та використовує синхронізаційний комітет сигналізаційного ланцюга (введений у хардфорку Altair до злиття). Синхронізаційний комітет складається з випадково вибраних 512 валідаторів, період служби яких становить близько 27 годин.

Після входу валідаторів до синхронізуючого комітету вони підписують всі заголовки блоків сигнальної ланцюга, які вони бачать. Якщо більше двох третин членів комітету підписують заголовок блоку, цей блок, ймовірно, знаходиться у стандартній сигнальній ланцюзі. Якщо Helios знає склад поточного синхронізуючого комітету, він може з високою впевненістю відстежити голову ланцюга, звернувшись до ненадійного RPC для запиту останніх підписів синхронізуючого комітету.

Завдяки агрегації підписів BLS, для перевірки заголовка нового блоку достатньо одного запиту. Якщо підпис дійсний і більше двох третин членів комітету завершили підписання, можна гарантувати, що блок включено в у блокчейні (звичайно, його також можуть видалити з ланцюга, і відстеження остаточності блоку може надати сильніші гарантії).

Але в цій стратегії очевидно не вистачає одного етапу: як знайти поточний синхронний комітет. Спочатку потрібно отримати довірений корінь, який називається перевіркою слабкої суб'єктивності. Це просто старий хеш блоку, який можна гарантувати, що був включений у ланцюг у певний момент у минулому. Щодо точного часу існування контрольної точки, за цим стоять деякі цікаві математичні розрахунки: аналіз найгіршого випадку показує приблизно два тижні, а більш практична оцінка вказує на кілька місяців.

Якщо контрольна точка занадто стара, теоретично існує можливість атак, які можуть спонукати вузли слідувати за неправильним ланцюгом. У цьому випадку отримання контрольної точки з弱主观性 перевищує можливості протоколу. Рішення Helios полягає в наданні початкової контрольної точки, яка жорстко закодована в кодовій базі (яка легко може бути перекрита), яка буде локально зберігати останній фінальний хеш блоку, щоб використовувати його як контрольну точку під час синхронізації вузлів.

За допомогою хешування блоки маякової ланцюга можуть легко генерувати унікальний хеш маякового блоку. Таким чином, можна легко запитувати вузли про повний маяковий блок, а потім, порівнюючи його хеш з відомим хешем блоку, доводити дійсність вмісту блоку. Helios використовує цю особливість для отримання та перевірки деяких полів у блоках контрольних точок з слабкою суб'єктивністю, включаючи два важливих поля: поточний синхронізаційний комітет та наступний синхронізаційний комітет. Найголовніше, легкий клієнт може використовувати цей механізм для швидкої перевірки історії у блокчейні.

Маючи слабкі контрольні точки суб'єктивності, ми можемо отримати та перевірити поточний та наступний синхронний комітет. Якщо поточний голова ланцюга та контрольна точка знаходяться в одному циклі синхронного комітету, ми можемо негайно почати використовувати підписану голову синхронного комітету для верифікації нових блоків. Якщо наша контрольна точка відстає на кілька синхронних комітетів, тоді ми можемо:

1. Використовуйте наступний синхронний комітет після контрольної точки для отримання та перевірки блоку, який буде згенеровано у блокчейні синхронного комітету в майбутньому.

2. Використовуйте цей новий блок для отримання наступного синхронного комітету.

3. Якщо контрольна точка ще позаду, поверніться до кроку 1.

За допомогою цього процесу ми можемо швидко перевірити історію цього блокчейну з одиницею часу 27 годин, починаючи з будь-якого хешу блоку в минулому і синхронізуючи до поточного хешу блоку.

Виконавчий рівень

Метою легкого клієнта виконувального рівня є поєднання заголовків блоків сигнування, перевірених на рівні консенсусу, з ненадійним RPC виконувального рівня, щоб надати перевірені дані виконувального рівня. Ці дані можуть бути доступні через Helios на локально розгорнутому сервері RPC.

Давайте на прикладі отримання балансу рахунку простіше розглянемо, як Ethereum зберігає стан. Кожен рахунок містить кілька полів, таких як хеш коду контракту, випадкове число, хеш зберігання та баланс. Ці рахунки зберігаються в модифікованому великому дереві Меркла-Патриції, яке називається деревом стану. Як тільки відомий корінь дерева стану, можна перевірити доказ Меркла, щоб підтвердити, чи існує будь-який рахунок у дереві. Це підтвердження не може бути підробленим.

Helios отримав перевірений корінь стану з рівня консенсусу. Застосувавши цей корінь стану та запит на доказ Merkle до ненадійного виконуючого рівня 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 до існуючого повного вузла виконавчого рівня