tl;dr

Teleportdao та Eigen Labs нещодавно опублікували статтю, присвячену проблемам безпеки та ефективності, з якими стикаються легкі ноди в блокчейнах Proof of Stake (POS) під час доступу та перевірки даних у ланцюжку. У документі пропонується нове рішення для забезпечення безпеки та ефективності легких вузлів у блокчейнах POS за допомогою економічних стимулів, застрахованих механізмів попередньої безпеки, настроюваної «програмованої безпеки» та економічної ефективності. Цей інноваційний підхід заслуговує на подальші дослідження. Примітка: Eigen Labs, розробник протоколу рестейкінгу Eigenlayer і Eigenda, залучив понад 150 мільйонів доларів від відомих венчурних фірм, таких як A16Z, PolyChain і Blockchain Capital. TeleportDAO, що базується у Ванкувері, Канада, зосереджується на кросчейн-інфраструктурі зв'язку між публічними ланцюгами Bitcoin та EVM. Протокол успішно залучив 9 мільйонів доларів через публічний продаж на Coinlist, серед інвесторів були AppWorks, OIG Capital, DefinanceX, Oak Grove Ventures, Candaq Ventures, TON, ACROSS і Bitsmiley.

проблеми з дизайном легкої ноди

В даний час в блокчейнах POS (Proof of Stake) валідатори забезпечують безпеку мережі, блокуючи певну кількість стейкінгу (наприклад, 32 ETH в Ethereum) для участі в мережі консенсусу. Це означає, що безпека блокчейнів POS економічно захищена: чим більша загальна ставка, тим вища вартість або потенційні втрати для будь-кого, хто спробує атакувати мережу. Цей механізм конфіскації залежить від функції, відомої як «безпека підзвітності», яка дозволяє конфіскувати частку валідатора, якщо він підписує конфліктуючі держави. Повні ноди є життєво важливими для підтримки цілісності блокчейнів POS. Вони зберігають усі дані про транзакції, перевіряють консенсусні підписи, підтримують повну історію транзакцій і виконують оновлення стану. Ці завдання вимагають значних обчислювальних ресурсів і сучасного обладнання; Наприклад, для запуску повного вузла Ethereum потрібно щонайменше 2 ТБ SSD-сховища. З іншого боку, легкі ноди зменшують вимоги до обчислювальних ресурсів, зберігаючи лише заголовки блоків, що робить їх придатними для перевірки конкретних транзакцій/станів у таких програмах, як мобільні гаманці та крос-чейн мости. Однак легкі ноди залежать від повних вузлів для отримання інформації про блок під час перевірки транзакцій. В даний час частка ринку постачальників послуг вузлів досить концентрована, що ставить під загрозу безпеку, незалежність і оперативність. У цій статті розглядаються рішення для балансу між витратами на збір даних і затримкою для досягнення оптимальної безпеки для легких вузлів.

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

Bitcoin представив просту перевірку платежів (SPV) як протокол для легких вузлів. SPV дозволяє легким вузлам перевіряти, чи включена транзакція в конкретний блок, використовуючи докази Меркла та заголовки блоків. Це означає, що легким вузлам потрібно лише завантажити заголовки блоків, щоб перевірити завершеність транзакції, перевіривши глибину блоку. Отже, обчислювальні витрати на перевірку консенсусу легких вузлів у Bitcoin відносно низькі. Однак у блокчейнах POS, таких як Ethereum, перевірка консенсусу за своєю суттю є складнішою. Вони передбачають підтримку всього набору валідаторів, відстеження змін у їхніх ставках і виконання численних перевірок сигнатур для мережі консенсусу. Крім того, безпека Pow Light Node ґрунтується на припущенні, що більшість повних вузлів є чесними. Щоб подолати обмеження SPV, FlyClient та неінтерактивні докази роботи proof-of-work (Nipopow) пропонують клієнтам сублінійні докази вартості. Однак ці методи менш ефективні для моделей консенсусу POS.

У блокчейнах POS безпека досягається за допомогою механізму конфіскації. Ця система передбачає, що учасники консенсусу є раціональними, тобто вони не атакуватимуть мережу, якщо вартість перевищить будь-який потенційний прибуток. Щоб знизити витрати на верифікацію, поточний протокол Ethereum Light Node використовує комітет синхронізації з 512 випадково обраних валідаторів, кожен з яких здійснює стейкінг 32 ETH, але процес підписання не підлягає конфіскації. Цей дизайн, що не передбачає конфіскації, має серйозні недоліки безпеки; Нечесні підписи в комітеті синхронізації можуть ввести в оману легкі вузли, змусивши їх прийняти недійсні дані без будь-якого покарання. Навіть за наявності механізму конфіскації загальна частка комітету синхронізації невелика порівняно з величезним пулом валідаторів Ethereum (понад 1 мільйон станом на березень 2024 року). Тому цей метод не надає легким нодам безпеку, еквівалентну набору валідаторів Ethereum. Ця модель є особливим варіантом багатосторонніх обчислень у раціональних умовах, але не має економічних гарантій і не здатна протистояти загрозам з боку шкідливих, ірраціональних постачальників даних.

Щоб вирішити проблеми безпеки та ефективності в процесі початкового завантаження POS, Popos представляє сегментовану гру, щоб ефективно кинути виклик змагальному дереву Меркла в часі POS. При досягненні мінімальних вимог до простору та уникненні необхідності для клієнтів постійно бути онлайн і підтримувати ставки, питання дозволу клієнтам виходити в автономний режим і знову приєднуватися до мережі без значних витрат залишається невирішеним.

Інший дослідницький підхід використовує докази з нульовим розголошенням для створення стислих доказів. Наприклад, Mina та Plumo полегшують перевірку консенсусу у легкій вазі, використовуючи рекурсивні комбінації Snark та докази переходу станів на основі Snark. Однак ці методи накладають значне обчислювальне навантаження на виробників блоків для генерації доказів і не стосуються компенсації легких вузлів потенційних втрат. В інших POS-протоколах (наприклад, протоколі Tendermint у Cosmos) роль легких вузлів була досліджена в їхньому протоколі міжблокчейнового зв'язку (IBC). Але ці реалізації адаптовані до конкретних екосистем і не застосовні безпосередньо до Ethereum або інших блокчейнів POS.

проектування нового плану легкої ноди

в цілому, новий план включає модуль економічної безпеки для досягнення “програмованої безпеки,” що дозволяє легким вузлам вибирати різні конструкції в залежності від їх конкретних вимог до безпеки. Припущення про безпеку слідують принципу 1/n + 1/m, що означає, що якщо принаймні одна чесна і ефективна нода в обох мережах повноцінних вузлів та мережі інспекторів, мережа може працювати належним чином.

залучені модулі/ролі

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

план 1: спочатку безпека

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

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

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

інші моменти:

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

оцінити:

• безпека: легка нода використовує модуль стейкінгу та мережу інспекторів, щоб визначити вартість зловживання для раціональних та ірраціональних постачальників даних, тим самим покращуючи надійність даних. Однак, оскільки весь протокол базується на мережі консенсусу (перевірено на Ethereum у цій роботі), якщо шар консенсусу атакують, то цей протокол також може стикнутися з потенційною довірою кризою. Тому можна ввести механізм репутації, щоб забезпечити безпеку системи в екстремальних випадках.
• рівень безпеки повної ноди: це рішення спрямоване на надання припущень про безпеку, еквівалентну до pos ethereum, що означає, що повні вузли повинні нести ризик втрати, якщо вони роблять неправдиві заяви.
• активність мережі: якщо в поточній мережі є лише декілька раціональних постачальників даних, то легка нода буде мати декілька раундів затримки. Однак, оскільки пропускна здатність кожного постачальника даних не дорівнює нулю, кожен запит все одно може бути виконаний. Тому, якщо в мережі є хоча б одна раціональна повна нода, вона може продовжувати працювати. Крім того, оскільки доход постачальників даних пов'язаний з їх кількістю стейків, це стимулює повні вузли до перестрахування для захисту мережі.
• ефективність: автори оцінюють, що валідатори Ethereum стануть основними користувачами, які беруть участь як постачальники даних, оскільки вони вже працюють з повними вузлами та можуть заробляти додатковий дохід за допомогою цього протоколу. Для отримання надійних даних невеликі транзакції можуть отримати дані від одного постачальника даних (для легкої ноди потрібна лише одна перевірка), тоді як великі транзакції можуть потребувати декількох постачальників даних для отримання надійних даних (кількість перевірок лінійно зростає з кількістю постачальників).

план 2: пріоритет ефективності

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

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

інші пункти:

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

оцінка:

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

ефективність плану

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

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

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

• Більше забезпечення: Наразі постачальники даних здійснюють стейкінг токенів ETH, але інформація про транзакції розраховується в доларах США. Це вимагає, щоб легкі вузли оцінювали обмінний курс ETH щоразу, коли вони отримують дані, щоб забезпечити достатню заставу. Дозвіл на стейкінг кількох токенів надасть постачальникам даних більше можливостей і зменшить ризик, пов'язаний з однією валютою.
• Авторизація: Подібно до спільного майнінгу, деякі роздрібні інвестори можуть авторизувати свої ETH повним вузлам для участі в мережі постачальників даних, а прибуток розподіляється відповідно до їхніх угод, подібно до LSD.
• Гарантія блоку: щоб уникнути очікування фінального періоду підтвердження (12-13 секунд на Ethereum), легкі ноди можуть використовувати гарантію, щоб скоротити цей час очікування. Легкі вузли додають символ/ідентифікатор під час надсилання запитів на дані та вказують тип необхідної гарантії (остаточне підтвердження/запропоноване). Потім постачальники даних надають відповідні дані та підпис під час отримання запиту. Якщо постачальники даних не запропонують блокування за сценарієм «запропонованої гарантії», вони будуть покарані.

Примітка: запропоновані блоки в кінцевому рахунку будуть остаточно затверджені або стануть блоками-дядьками.

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

узагальнення та оцінка

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

відмова від відповідальності：

1. ця стаття перепринята з [Партнери Єврека]. всі авторські права належать оригінальному автору [Енді、Артур]. якщо є зауваження до цього повторного видання, будь ласка, зв'яжіться з Навчання воріткоманда, і вони швидко займуться цим.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є жодною інвестиційною порадою.
3. переклади статті на інші мови робить команда Gate.io learn. якщо не зазначено інше, копіювання, поширення або плагіат перекладених статей заборонені.