Створення Helios: повністю безнадійний доступ до Ethereum

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

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

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

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

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

Підводні камені централізованої інфраструктури: теоретичні створіння в «темному лісі» Ethereum

(Теоретична) істота ховається в темний ліс. Він не шукає свою здобич у мемпулі Ethereum, а натомість розставляє пастки, імітуючи централізовану інфраструктуру, на яку ми звикли покладатися. Користувачі, які потрапили в цю пастку, не роблять жодних помилок: вони відвідують свою улюблену децентралізовану біржу, встановлюють розумний допуск до прослизання та купують і продають токени, як зазвичай… Вони роблять усе правильно, але все одно стають жертвами нового типу сендвіч-атака, пастка, ретельно встановлена ​​на самому вході в темний ліс Ethereum: провайдери RPC.

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

Поки цей мінімальний вихідний параметр встановлено близько до справедливої ​​вартості, ви захищені від сендвіч-атак. Але що, якщо ваш постачальник RPC не надає точну цінову котирування зі смарт-контракту децентралізованої біржі? Тоді користувача можна обманом змусити підписати транзакцію обміну з нижчим мінімальним вихідним параметром і, що ще гірше, відправити транзакцію прямо шкідливому постачальнику RPC. Замість того, щоб транслювати цю транзакцію в загальнодоступний mempool, де десятки ботів змагаються за виконання сендвіч-атаки, провайдер може утримати її та надіслати пакет транзакцій атаки безпосередньо до Flashbots, забезпечуючи прибуток для себе.

Основною причиною цієї атаки є довіра комусь іншому отримати інформацію про стан блокчейну. Досвідчені користувачі традиційно вирішують цю проблему, запускаючи власні вузли Ethereum — це вимагає часу та ресурсів, що вимагає щонайменше постійної онлайнової машини, сотень гігабайт пам’яті та близько дня для синхронізації з нуля. Цей процес, звичайно, легший, ніж був раніше; групи, як Ethereum на ARM невпинно працювали над тим, щоб зробити можливим запуск вузлів на недорогому апаратному забезпеченні (наприклад, Raspberry Pi із прив’язаним до нього зовнішнім жорстким диском). Але навіть із цими відносно мінімальними вимогами запустити вузол все ще важко для більшості користувачів, особливо для тих, хто використовує мобільні пристрої.

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

Представляємо Helios: повністю безнадійний доступ до Ethereum

Представивши легкий клієнтський протокол (що став можливим завдяки нещодавньому переходу на Proof of Stake), Ethereum відкрив нові захоплюючі можливості для швидкої взаємодії з блокчейном і перевірки кінцевих точок RPC з мінімальними вимогами до обладнання. За місяць з тих пір Злиття, ми бачили, як нова група легких клієнтів з’являється незалежно один від одного (Лодестар, німб, і на основі JavaScript Кевлар), які використовували різні підходи для досягнення однієї мети: ефективний і надійний доступ без використання повного вузла.

Наше рішення, 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 рівня виконання для надання перевірених даних рівня виконання. Потім доступ до цих даних можна отримати через сервер RPC, локально розміщений Helios.

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

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

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

Використання Геліоса в дикій природі

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

Крім того, підтримка Rust для WebAssembly дозволяє розробникам додатків легко вбудовувати Helios у програми Javascript (наприклад, гаманці та dapps). Ці інтеграції зроблять Ethereum безпечнішим і зменшать нашу потребу довіряти централізованій інфраструктурі.

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

• Підтримка отримання легких даних клієнта безпосередньо з мережі P2P, а не через RPC
• Реалізуйте деякі з відсутніх методів RPC
• Створіть версію Helios, яка компілюється до WebAssembly
• Інтегруйте Helios безпосередньо в програмне забезпечення гаманця
• Створіть веб-панель для перегляду балансу токенів, яка отримує дані з Helios, вбудованого у веб-сайт, за допомогою WebAssembly
• Впровадити API двигуна, щоб рівень консенсусу Helios можна було підключити до існуючого повного вузла рівня виконання

Перевірте кодову базу щоб розпочати — ми раді вашим повідомленням про помилки, запитам щодо функцій і коду. І якщо ви створите щось більше, поділіться цим з нами Twitter, Telegram, або Farcaster @a16zcrypto.

***
Погляди, висловлені тут, є поглядами окремих співробітників AH Capital Management, LLC («a16z»), які цитуються, і не є поглядами a16z або його філій. Певна інформація, що міститься тут, була отримана зі сторонніх джерел, зокрема від портфельних компаній фондів, якими керує a16z. Хоча отримано з джерел, які вважаються надійними, a16z не перевіряв таку інформацію незалежно та не робить жодних заяв щодо поточної чи довгострокової точності інформації чи її відповідності певній ситуації. Крім того, цей вміст може містити рекламу третіх сторін; a16z не переглядав такі оголошення та не схвалює будь-який рекламний вміст, що міститься в них.

Цей вміст надається лише в інформаційних цілях, і на нього не можна покладатися як на юридичну, ділову, інвестиційну чи податкову консультацію. Ви повинні проконсультуватися з власними радниками щодо цих питань. Посилання на будь-які цінні папери чи цифрові активи наведено лише з метою ілюстрації та не є інвестиційною рекомендацією чи пропозицією надати інвестиційні консультаційні послуги. Крім того, цей вміст не призначений для будь-яких інвесторів чи потенційних інвесторів і не призначений для використання ними, і за жодних обставин на нього не можна покладатися при прийнятті рішення інвестувати в будь-який фонд, яким керує a16z. (Пропозиція інвестувати у фонд a16z буде зроблена лише на підставі меморандуму про приватне розміщення, угоди про підписку та іншої відповідної документації будь-якого такого фонду, і її слід читати повністю.) Будь-які інвестиційні чи портфельні компанії, згадані, згадані або описані не є репрезентативними для всіх інвестицій у транспортні засоби, якими керує a16z, і не може бути гарантії, що інвестиції будуть прибутковими або що інші інвестиції, здійснені в майбутньому, матимуть подібні характеристики чи результати. Список інвестицій, здійснених фондами під управлінням Andreessen Horowitz (за винятком інвестицій, щодо яких емітент не надав дозволу a16z на оприлюднення, а також неоголошених інвестицій у публічні цифрові активи) доступний за адресою https://a16z.com/investments /.

Наведені в ньому діаграми та графіки призначені виключно для інформаційних цілей, і на них не слід покладатися під час прийняття інвестиційних рішень. Минулі результати не вказують на майбутні результати. Зміст відповідає лише вказаній даті. Будь-які прогнози, оцінки, прогнози, цілі, перспективи та/або думки, висловлені в цих матеріалах, можуть бути змінені без попередження та можуть відрізнятися або суперечити думкам, висловленим іншими. Додаткову важливу інформацію можна знайти на сторінці https://a16z.com/disclosures