Переслати оригінальний заголовок «TeleportDAO: гра безпеки та ефективності перевірки даних - останній практичний дизайн легкої вузла»

TL;DR

TeleportDAO та Eigen Labs нещодавно спільно опублікували статтю, присвячену проблемам безпеки та ефективності, з якими стикаються легкі ноди під час доступу та перевірки ончейн-даних у блокчейнах із доказом частки володіння (PoS). У цьому документі пропонується нове рішення для забезпечення безпеки та ефективності легких вузлів у блокчейнах PoS за допомогою низки заходів, таких як економічні стимули та застраховані механізми попередньої безпеки, а також індивідуальна «програмована безпека» та економічна ефективність. Вона дуже далекоглядна і заслуговує на глибоке вивчення.

Примітка: Eigen Labs - це розробник протоколів Restaking EigenLayer та EigenDA. Eigen Labs наразі залучила понад 150 мільйонів доларів США від відомих венчурних капіталістичних установ, таких як a16z, Polychain та Blockchain Capital.

TeleportDAO розташований у Ванкувері, Канада. Це проект інфраструктури міжланцюжкової комунікації, який фокусується на громадських ланцюжках Bitcoin та EVM. Протокол успішно залучив $9 мільйонів у публічному раунді продажів і фінансування через Coinlist. В цьому раунді фінансування взяли участь кілька інвесторів, включаючи Appworks, OIG Capital, DefinanceX, Oak Grove Ventures, Candaq Ventures, TON, Across та bitSmiley.

Існуючі проблеми в дизайні легкого вузла

На даний момент, у блокчейнах PoS валідатори беруть участь в мережі консенсусу, блокуючи певну кількість ставки (наприклад, 32 ETH в Ethereum), щоб забезпечити безпеку мережі. Таким чином, суть безпеки блокчейна PoS захищена економічно, тобто чим більше загальна ставка, тим більші витрати або збитки потрібно для атаки мережі консенсусу. Реалізація цього механізму стриження ґрунтується на функції, що називається «відповідальність за безпеку», тобто, якщо валідатор підписує конфліктний стан, ставка може бути знижена.

Повні ноди відіграють життєво важливу роль у підтримці цілісності блокчейну PoS. Вони зберігають всю інформацію про транзакції блоку, перевіряють консенсусні підписи, копіюють повну копію історії транзакцій і виконують оновлення стану. Ці процеси вимагають багато обчислювальних ресурсів і складного обладнання. Наприклад, для запуску повноцінного вузла Ethereum потрібно щонайменше 2 ТБ SSD-сховища. Навпаки, легкі ноди зменшують вимоги до обчислювальних ресурсів і зберігають лише заголовки блоків, тому вони підходять лише для сценаріїв, де певні транзакції/статуси перевіряються, таких як мобільні гаманці та кросчейн-мости. Крім того, легкі ноди покладаються на повні ноди для надання інформації про блок під час перевірки транзакцій, але поточна частка ринку постачальників послуг вузлів відносно концентрована, тому безпека, незалежність і миттєвість не можуть бути повністю гарантовані. Тому в цьому документі досліджується компроміс між вартістю збору даних і затримкою для легких вузлів для досягнення оптимальної безпеки.

Існуючі рішення дизайну легкого вузла

Bitcoin представив Simple Payment Verification (SPV) як протокол легкого вузла. SPV дозволяє легким вузлам використовувати Merkle Proof і заголовки блоків, щоб перевірити, чи включена транзакція в конкретний блок. Тому легким нодам потрібно лише завантажити заголовок блоку блокчейну, щоб перевірити остаточність транзакції, перевіривши глибину блоку. У цьому випадку обчислювальні витрати на перевірку консенсусу легкими нодами в Bitcoin відносно низькі. Однак у блокчейнах PoS, таких як Ethereum, дизайн перевірки консенсусу за своєю суттю складніший. Це передбачає підтримку всього набору валідаторів, відстеження змін їхніх стейкінгів і виконання багатьох перевірок сигнатур для мережі консенсусу. З іншого боку, безпека легких вузлів PoW ґрунтується на припущенні, що більшість повних вузлів є чесними. Щоб усунути обмеження SPV, FlyClient і Non-Interactive Proof of Work (NiPoPoW) доводять ці блоки клієнтам за сублінійну ціну. Однак їх застосовність до моделі консенсусу PoS слабка.

На противагу цьому, блокчейни PoS отримують безпеку завдяки механізмам скорочення. Система покладається на те, що учасники консенсусу раціонально налаштовані та не атакують мережу, якщо вартість атаки перевищує будь-який потенційний прибуток. Щоб зменшити витрати на верифікацію, поточний протокол легких вузлів Ethereum покладається на комітет синхронізації, що складається з 512 випадково обраних валідаторів Ethereum, кожен з яких здійснює стейкінг 32 Ethereum, але процес підписання не буде оштрафований. Цей непохитний дизайн має серйозний недолік безпеки, і нечесні підписи в комітеті синхронізації можуть ввести в оману легкі вузли, змусивши їх прийняти недійсні дані без покарання. Навіть із запровадженням механізмів слешінгу загальна частка Sync Committee все ще невелика порівняно з величезним пулом валідаторів Ethereum (станом на березень 2024 року кількість валідаторів Ethereum перевищила 1 мільйон). Тому такий підхід не може забезпечити легкі ноди безпекою, еквівалентною набору валідаторів Ethereum. Ця модель являє собою особливий варіант багатосторонніх обчислень в раціональних умовах, але не в змозі забезпечити економічно обґрунтовані гарантії або усунути загрози, пов'язані зі шкідливими, ірраціональними постачальниками даних.

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

Ще один дослідницький підхід спрямований на використання доказів з нульовим розголосом для створення стислих доказів. Наприклад, Mina та Plumo ефективно сприяють верифікації легкого згоди за допомогою рекурсивної композиції SNARK та доказів переходу у стан на основі SNARK. Однак ці підходи накладають значні обчислювальні витрати на блок-виробників для генерування доказів, і вони не вирішують проблему компенсації легких вузлів за можливі втрати. У контексті інших протоколів PoS, таких як протокол Tendermint, використаний в Cosmos, роль легких вузлів досліджується у їхньому протоколі міжблокчейній комунікації (IBC). Однак ці реалізації специфічні для їхніх відповідних екосистем і не є безпосередньо застосовними до Ethereum або різних інших PoS блокчейнів.

Новий дизайн вузла світла

Загалом нове рішення вводить економічний модуль безпеки для досягнення "програмованої безпеки", а легкі вузли можуть вирішувати різні варіанти рішень на основі власних потреб у безпеці. Безпекове припущення в основному складає 1/N + 1/M, тобто, поки в повній вузловій і прокурорській мережі є чесний і дійсний вузол, може бути гарантовано нормальне функціонування мережі.

Пов'язані модулі/ролі

• Блокчейн: Протокол побудований на програмованому блокчейні, а правила завершення блоків детерміновані. Наприклад, на блокчейні Ethereum завершення блоку потребує принаймні двох наступних епох, що зазвичай займає близько 13 хвилин.
• Скорочення Смарт-контракт: Протокол включає в себе скорочувальний контракт на ланцюжку, який відповідає стандартній абстракції смарт-контракту. Він має доступ до хешу блоку попереднього блоку в блокчейні. Усі сторони можуть надсилати повідомлення на цей контракт.
• Постачальники даних: Постачальники даних запускають повні вузли та відстежують останній стан блокчейну. Вони зобов'язують активи та надають послуги з підтвердження правомірності стану, запитаного легкими вузлами. Вони підписують всі дані, відправлені легким вузлам, секретним ключем, що відповідає їхньому відкритому ключу, тим самим підтверджуючи джерело й цілісність даних.
• Прокурори: Прокурори - це повноцінні вузли, підключені до легких вузлів для допомоги в перевірці даних. Будь-хто може стати прокурором та заробляти, моніторивши та зменшуючи винних сторін, які поводяться неправильно. Для спрощення, наступна схема передбачає, що кожен легкий вузол підключений принаймні до одного чесного прокурора.
• Легка Нода: Легка Нода перевіряє, чи включений конкретний стан/транзакція в блокчейн за найнижчою вартістю. Під час процесу перевірки легка нода з'єднується з групою постачальників даних та прокурорів.
• Мережа: постачальники даних утворюють мережу взаємозв'язку (p2p) та використовують протокол Gossip для розповсюдження даних. Легкі вузли підключаються до деяких постачальників даних для відправлення запитів та отримання відповідей.

Варіант 1: Безпека на першому місці

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

Конкретний процес запиту даних легким вузлом:

1. Легкий вузол отримує останній список постачальників даних з поточної мережі та визначає період виклику. Варто зазначити, що цей період виклику є незалежним серед різних легких вузлів, але верхня межа періоду виклику поширюється на всі легкі вузли. Період виклику є найдовшим часом для мережі прокурорів перевіряти достовірність даних, тому чим довше час, тим довше затримка на кожну транзакцію.
2. Після отримання списку легка нода вибере групу постачальників даних та переконається, що їх відповідні заставлені кошти більше, ніж значення поточної транзакції. Теоретично, чим вище заставлені кошти, тим вищі витрати по недобросовісному поведінці постачальника даних, і тим нижчі витрати на довіру легкої ноди.
3. Легкий вузол надсилає відповідний запит на дані цій групі постачальників даних, який включає відповідний номер блоку та цільовий стан (доказ включення цієї транзакції).
4. Постачальник даних надсилає відповідний хеш блоку та доказ включення транзакції, а також додає підпис.
5. Після того, як легка нода отримує вищезазначені матеріали, вона пересилає їх поточній підключеній мережі прокурорів. Якщо після завершення періоду виклику не отримано попередження про вірогідність даних, легка нода перевірить цей підпис та пройде тест на вірогідність даних, якщо не виникне помилка.

1. Проте, якщо мережею прокурора отримано попередження, легка вузол повинен відкинути раніше отриману підпис. Мережа прокурорів надішле відповідне докази до модуля покарань смарт-контракту. Якщо смарт-контракт після перевірки даних виявить, що порушення дійсно сталося, то буде здійснено покарання ставки відповідного постачальника даних. Оскільки частина / всі обрані постачальники даних були покарані, легка вузол повинен повторно отримати новий список постачальників даних від поточної мережі, щоб підтвердити, що подія стриження дійсно сталася.

Інші пункти:

• Будь-який повний вузол може приєднатися до мережі постачальника даних або вийти з неї, ініціювавши запити на «реєстрацію» та «виведення коштів» до смарт-контракту. Існує мінімальний поріг стейкінгу для реєстрації для участі в мережі постачальника даних. Як тільки повний вузол вирішить ініціювати виведення коштів, його статус у мережі негайно зміниться на «вихід», і він більше не зможе отримувати запити від легких вузлів, щоб запобігти потенційній зловмисній поведінці швидкого входу та виходу. Крім того, мережа постачальників даних оновлює список активних на даний момент постачальників даних циклами, протягом яких постачальники даних не можуть отримувати кошти для виведення коштів. Запит на виведення коштів набуде чинності в останньому блоці поточного циклу оновлення, а частота оновлень буде вищою за ліміт періоду виклику, щоб переконатися, що всі тести доступності даних легких вузлів завершені. У зв'язку з активністю мережі постачальників даних, легкі вузли повинні заново отримувати список активних провайдерів щоразу, коли мережа оновлюється. Якщо цикл оновлення подовжується, легкі ноди можуть насолоджуватися більш спрощеним процесом верифікації (оцінюючи поточний активний список за допомогою запитів на реєстрацію та «відкликання» попереднього циклу), але вузли, які бажають вийти, зіткнуться з довшим часом очікування.
• Отримавши підпис даних, прокурор перевіряє, чи належить підпис постачальнику даних, і оцінює, чи були дані «остаточно підтверджені» в мережі консенсусу. Якщо дані не з'являються в розумному ланцюжку, є два варіанти. По-перше, дані ще остаточно не підтверджені поточним блокчейном, різні ланцюжки мають різні правила фіналізації, наприклад, принцип найдовшого ланцюга. По-друге, транзакція знаходиться в блоці іншого розумного ланцюжка. Якщо вищезазначені дані виявляться сфальсифікованими, мережа прокурорів надішле запит на слешінг смарт-контракту, який включає публічний ключ постачальника даних, підпис постачальника даних, номер блоку, і в той же час надішле доказ події слешінгу, щоб нагадати про це світловому вузлу. Після отримання цих даних смарт-контракт вимірює, чи відповідає поточний остаточно підтверджений номер блоку отриманим даним відповідно до принципу остаточності рівня консенсусу. Якщо вони несумісні, то запускається подія слешінгу. Крім того, якщо постачальник даних, обраний світлим вузлом, буде скорочений через іншу групу запитів на дані, мережа прокурорів негайно надішле подію слешінгу, щоб нагадати легкому вузлу, що довіра до даних постачальника даних низька, а потім легкий вузол повторно отримає список і вибере інших постачальників.

Оцініть:

• Безпека: Легка нода визначає вартість зловмисної поведінки для раціональних та ірраціональних постачальників даних через модуль стейкінгу та мережу прокурорів, покращуючи довіру до даних. Однак, оскільки весь протокол ґрунтується на мережі консенсусу (ця робота тестується на Ethereum), коли атакується шар консенсусу, протокол може також стати перед потенційною кризою довіри. Тому може бути подальше введення механізму репутації для забезпечення системного ризику в екстремальних ситуаціях.
• Безпека на рівні повної вузлової Ноди: Ця схема спрямована на забезпечення безпеки, еквівалентної припущенню PoS Ethereum, тобто, повні вузли повинні нести ризик відслідковування за надання хибних заяв.
• Активність мережі: якщо поточна мережа має лише кількох раціональних постачальників даних, легкий вузол стикатиметься з кількома раундами затримки, але оскільки пропускна здатність кожного постачальника даних не дорівнює нулю, кожний запит завжди буде виконаний. Тому, якщо в мережі є хоча б один раціональний повний вузол, це може забезпечити продовження роботи мережі. Тим часом, оскільки дохід постачальників даних пов'язаний з обсягом стейкінгу, це також підтримує повні вузли в захисті мережі шляхом стейкінгу більше, ніж потрібно.
• Ефективність: Команда авторів статті передбачає, що валідатори Ethereum є основними користувачами, які беруть участь у постачальниках даних, оскільки валідатори вже працюють з повними вузлами і можуть отримувати додатковий дохід через цей протокол. Невеликі транзакції можуть отримувати достовірні дані через одного постачальника даних (легкий вузол потрібно перевірити лише один раз), тоді як великі транзакції можуть потребувати кілька постачальників даних для отримання достовірних даних (кількість перевірок зростає лінійно з кількістю постачальників).

Варіант 2: Ефективність на першому місці

Рішення 2 реалізує швидке підтвердження даних, запропонувавши механізм страхування на основі Рішення 1. Зрозуміло, що після того, як легкий вузол визначає страховку відповідно до суми полісу та тривалості, частина / вся застава постачальника даних може бути компенсована для наступних втрат легкого вузла через злоумисне використання даних. Тому після того, як легкий вузол отримує та перевіряє підпис даних, наданий постачальником, він може визначити початкову довіру до даних.

Конкретний процес запиту даних легким вузлом:

1. Світлова нода розраховує максимальну можливу втрату поточної транзакції, а потім встановлює суму страхової поліси та строк страхування. Сума коштів, яку надає постачальник даних для страхування, повинна бути більшою, ніж сума страхової поліси, щоб забезпечити достатні кошти для повернення.
2. Світлова нода визначає період виклику для транзакції. Варто зауважити, що період політики може охоплювати перевірку включення кількох транзакцій, тому загальний період виклику, вибраний світловою нодою, не може перевищувати період політики, інакше деякі транзакції можуть не бути охоплені.
3. Після вибору параметрів (сума полісу, термін полісу, сума коштів, яку надавач даних гарантує для страхування, список призначених надавачів даних), легка нода може надіслати запит на розумний контракт. Потім, після очікування кінцевого часу підтвердження блоку, вона може перевірити, чи успішна покупка страховки. Якщо вона не вдалася, це може бути тому, що інші легкі вузли також вибрали надавача даних і вирішили першими, тому залишок гарантії не вистачає для відповідності його початковій вимозі.
4. Легкий вузол відправляє запит на дані, який включає номер страховки, а також номер блоку та цільовий стан (доказ про включення транзакції).
5. Постачальник даних відправляє дані та підпис, легка нода перевіряє підпис та передає його в мережу прокурорів, після чого транзакція була попередньо підтверджена.
6. Після отримання даних та підпису прокурор спочатку перевірить достовірність даних. Якщо виявиться яка-небудь зловмисна поведінка, прокурор надішле докази до смарт-контракту та наложить штраф на відповідного постачальника даних, який буде розподілено серед легких вузлів.

Інші пункти:

• Ставлені токени страховки постачальника даних є незалежними один від одного між різними запитами легкого вузла для запобігання ризику множинних відшкодувань по страхуванню. Після того, як легкий вузол вибирає постачальника даних, смарт-контракт заблокує відповідні токени, які були взяті на страхування, і інші легкі вузли не зможуть розподілити цю частину застави до завершення періоду страхування. Якщо транзакції є незалежними, сума страхування дорівнює максимальній сумі транзакції. В іншому випадку сума страхування дорівнює загальній сумі транзакцій. При однаковій сумі застави легкі вузли загалом вибирають якомога менше постачальників даних, щоб забезпечити ефективність перевірки.
• Незважаючи на те, що постачальник даних може ініціювати запит на "виведення" до закінчення строку страхування, сума виведення буде отримана лише після закінчення строку страхування.
• Строго кажучи, термін дії страхової полісу повинен бути більшим, ніж час підтвердження останнього блоку + загальний період виклику + затримка у комунікації + затримка у обчисленні/перевірці. Чим більше постачальників даних ви виберете, тим довший буде термін дії страхової полісу на основі загального періоду виклику.

Оцінити:

• Масштабованість: Масштабованість опції 2 визначається загальною кількістю токенів, яку постачальники даних готові ставити на страхування.
• Вартість політики: оскільки більш високі рівні безпеки пов'язані з циклом виклику, це означає, що постачальник даних повинен ставити на грубість на період, більший або рівний до циклу виклику. Тому, чим вищі вимоги до безпеки, тим довший цикл ставок і вища плата, яку сплачує легкий вузол. Згідно з формулою, вартість ставки постачальника даних розраховується за допомогою доходів вузла постачальника даних / (середнє використання ставок протягом року, помножене на загальну кількість блоків на рік). Ціна, яку повинен сплатити легкий вузол, - це вартість ставки, помножена на строк і розмір політики.

Ефективність рішення

Спочатку, щодо ефективності обчислень легких вузлів, обидва рішення демонструють ефективність перевірки на рівні мілісекунд (легкі вузли потребують перевірки даних лише один раз).

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

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

Напрямок розширення

• Більше застави: наразі токен, закладений постачальниками даних, - це ETH, але інформація про транзакції розраховується на основі стандарту U, що означає, що легкі вузли повинні вимірювати обмінний курс ETH кожного разу, коли отримують дані, щоб забезпечити достатню величину застави. Якщо дозволено заставляти кілька токенів, постачальники даних можуть мати більше варіантів застави, тим самим уникнувши ризику викладеності одній валюті.
• Авторизація: Схоже на спільний майнінг, деякі роздрібні інвестори можуть брати участь в мережі постачальників даних, авторизовуючи свій власний ETH до повного вузла, а прибуток розподіляється згідно з власною угодою. Будь ласка, зверніться до LSD.
• Гарантія блоку: Щоб уникнути очікування фінального періоду підтвердження (12-13 секунд в Ethereum), легкі вузли можуть використовувати гарантію для скорочення цього часу очікування. Легкий вузол спочатку додасть символ/ідентифікатор при запиті даних і визначить, який вид гарантії потрібний (фінальне підтвердження/запропоноване). Постачальник даних надає відповідні дані та підпис після отримання запиту. Коли постачальник даних не має запропонованого блоку в умовах 'запропонованої гарантії', його буде оштрафовано.
  \
  Примітка: Запропоновані блоки врешті-решт будуть узгоджені або стануть блоками-дядьками.
• Вартість та комісії: Для мережі прокурорів їм потрібно вкласти певну кількість токенів (більше, ніж газ), щоб надіслати докази до смарт-контракту. Крім того, вартість цієї частини доказів може бути зменшена за допомогою методу zkp. Крім того, за механізмом страхування премії, які подаються світловими вузлами, будуть передані постачальникам даних, тоді як мережа прокурорів вилучатиме частину доходу від штрафів від зловживаючих постачальників.
• Доступність даних: Постачальники даних, в сутності, є повними вузлами. Крім участі в мережі рівня консенсусу, вони також можуть перевірити доступність даних. Існують два типи схем для перевірки доступності: модель витягування та модель відправлення. Перше відноситься до того, що легкий вузол випадковим чином витягує дані, отримані від повного вузла. Останнє відноситься до того, що виробник блоків розподіляє різні блоки постачальникам даних. Для постачальників даних, які використовують модель витягування, вони відповідальні за повернення запитів на вибірку. Після отримання даних легкий вузол пересилає їх до довіреного вузла/валідатора, і вони намагаються відновити блок. Якщо вони зазнають невдачі, постачальника даних буде оштрафовано. Протокол легкого вузла в цій статті пропонує механізм страхування на цій основі, надаючи новий напрямок дослідження доступності даних.

Висновок та оцінка

Запропоноване в цій статті рішення для легких вузлів надає «програмовану безпеку» для відповідності вимогам безпеки в різних ситуаціях. Варіант 1 обмінює вищу затримку на високу безпеку, тоді як Варіант 2 надає послуги «миттєвого підтвердження» для легких вузлів, вводячи механізм страхування. Ці рішення можуть бути використані в сценаріях, де потрібно підтвердження остаточності транзакцій, таких як атомні транзакції та міжланцюжкові.

Disclaimer：

1. Ця стаття була написана з [ Партнери Євріка]. Переслати оригінальний заголовок ‘TeleportDAO: гра безпеки та ефективності перевірки даних — останні практики в дизайні легкого вузла’. Усі авторські права належать оригінальному автору [Andy、Arthur]*. Якщо є виклики до цього репринту, будь ласка, зв'яжіться Gate Learnкоманда, і вони оперативно займуться цим.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, належать виключно автору і не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено, копіювання, поширення або плагіатування перекладених статей заборонене.