Огляд:

B^2 Network створив шар доступності даних (DA) під назвою B^2 Hub в ланцюжку Bitcoin, інспіруючись концепціями Celestia. Ця мережа шару DA реалізує вибірковий збір даних та кодування знищення для забезпечення швидкого розподілу нових даних до численних зовнішніх вузлів та запобігання приховуванню даних. Крім того, Комітер у мережі B^2 Hub відповідає за завантаження індексу зберігання та хешу даних DA в ланцюжок Bitcoin для загального доступу.

Для полегшення навантаження на вузли шару DA, історичні дані в B^2 Hub не зберігаються постійно. Отже, B^2 прагнув відновити мережу сховищ, використовуючи механізм стимулювання зберігання, схожий на Arweave, для стимулювання більшої кількості вузлів для зберігання повних історичних наборів даних в обмін на винагороди за зберігання.

· Щодо перевірки статусу, B^2 використовує гібридний підхід до підтвердження ZK-доказів поза ланцюгом та використовує концепцію bitVM для виклику слідів перевірки ZK-доказів на ланцюжку. Безпека мережі B^2 забезпечується, коли викликаючий вузол ініціює виклик при виявленні помилки, узгоджуючись з моделлю довіри протоколу протишахрайства. Однак через використання ZK-доказів цей процес перевірки статусу суттєво гібридний за своєю природою;

·Відповідно до майбутньої дорожньої карти B^2 Network, сумісний з EVM B^2 Hub має потенціал служити як офлайн-шар верифікації та DA-шар, який з'єднує кілька рішень Layer 2 Bitcoin. Він має на меті перетворитися на шар функціонального розширення Bitcoin поза ланцюгом, схожий на BTCKB. Оскільки Bitcoin обмежений у підтримці різних сценаріїв, розвиток шару функціонального розширення поза ланцюгом передбачається стати поширеною практикою в екосистемі Layer 2.

B^2 Hub: універсальний шар доступності даних (DA) та верифікації в межах ланцюжка Bitcoin

Поточна екосистема Bitcoin нагадує обширну простору можливостей та ризиків, де наслідки Літніх Інскультів надихнули нове життя в цій галузі, схоже на плодючу необроблену землю з ароматом багатства, що лине в повітрі. Поява Bitcoin Layer 2 раніше цього року перетворила цей колись пустельний пейзаж в центр амбіцій для численних візіонерів.

Повертаючись до суть справи: визначення Layer 2 залишається предметом суперечок серед осіб. Чи це бічний ланцюг? Індексатор? Чи термін Layer 2 охоплює ланцюги, які встановлюють зв'язки? Чи може простий плагін, залежний від Bitcoin та Ethereum, вважатися Шаром? Ці запитання нагадують нерозв'язані рівняння без остаточного рішення.

Згідно з поглядами спільнот Ethereum та Celestia, Layer 2 представляє собою відокремлену інстанцію модульного блокчейну. У цьому контексті існує тісна взаємозалежність між так званим «другим рівнем» та «першим рівнем». Безпека Layer 1 може бути частково або значно успадкована другим рівнем мережі. Сама безпека охоплює різні підкатегорії, включаючи DA, перевірку статусу, перевірку виведення, резистентність до цензури та резистентність до реорганізації.

З урахуванням вроджених обмежень мережі Bitcoin вона не є сприятливою для підтримки всеосяжної мережі другого рівня. Наприклад, з точки зору DA, потужність обробки даних Bitcoin значно відстає від потужності Ethereum. З середнім часом генерації блоку 10 хвилин максимальна швидкість обробки даних Bitcoin становить лише 6,8 КБ/с, що приблизно в 1/20 від потужності Ethereum. В результаті перенасиченого блокування простору виникають підвищені витрати на публікацію даних.

(Вартість публікації даних у блоку Bitcoin може сягати навіть $5 за КБ)

Якщо Layer 2 безпосередньо публікує нові дані про транзакції до блоку Bitcoin, це не дозволить досягти високої пропускної здатності або низьких комісій за транзакції. Для вирішення цього один з підходів полягає в значному стисненні даних перед завантаженням їх до блоку Bitcoin. Citrea наразі використовує цей метод, заявляючи, що вони будуть завантажувати зміни стану (state diff), які відбуваються в кількох облікових записах до ланцюжка Bitcoin, супроводжуючи їх відповідними ZK-сертифікатами протягом певного періоду.

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

(Раніше білий папір Polygon Hermez пояснює принцип вищезазначеної схеми стиснення)

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

В результаті багато рішень другого рівня Bitcoin вибирають не завантажувати дані DA в основну мережу Bitcoin, а використовувати сторонні шари DA, такі як Celestia. На відміну від цього, B^2 реалізує різний підхід, створюючи мережу доступності даних (DA) безпосередньо під ланцюгом, відому як B^2 Hub. У цьому дизайні важливі дані, такі як дані транзакцій або відмінності стану, зберігаються поза ланцюгом, і лише їхні індекси зберігання та хеші данів (називаються дані для простоти) завантажуються в основну мережу Bitcoin.

Ці хеш-дані та зберігані індекси зберігаються на ланцюгу Біткойн, схожому на написи. Запустивши вузол Біткойн, особи можуть локально отримати доступ до хеш-даних та збереженого індексу. За допомогою значення індексу вони можуть витягнути початкові дані з позаналанкового DA або збереженого шару B^2. Хеш-дані дозволяють перевірити правильність даних, отриманих з позаналанкового шару DA, порівняно з відповідним хешем на ланцюзі Біткойн. Цей прямолінійний підхід дозволяє рішенням Шару 2 зменшити залежність від головного мережі Біткойн для питань DA, зменшити витрати на транзакції та досягти високої пропускної здатності.

Проте важливо усвідомити, що сторонні платформи DA під ланцюгом можуть займатися практикою утримання даних, що запобігає зовнішньому доступу до нових даних - феномен, відомий як "атака утримання даних". Різні рішення DA вирішують це питання по-різному, з загальною метою швидкого та широкого поширення даних для запобігання контролю доступу до даних обраними вузлами.

Згідно з оновленою офіційною дорожньою картою B^2 Network, його рішення DA ґрунтується на Celestia. У цьому останньому дизайні сторонні постачальники даних безперервно будуть надавати дані мережі Celestia. Виробники блоків Celestia будуть організовувати ці фрагменти даних у вигляді дерева Меркла, заповнювати їх у блоки TIA та ретранслювати їх у мережу. Валідатор/повний вузол.

Оскільки даних багато, а блоки досить великі, більшість людей не можуть собі дозволити запуск повних вузлів і можуть запускати лише легкі вузли. Легкий вузол не синхронізує повний блок, а лише синхронізує заголовок блоку з коренем дерева Меркла, записаним на ньому.

Згідно з останньою дорожньою картою B^2 Network, його рішення DA бере натхнення з Celestia. За цією конструкцією зовнішні постачальники даних постійно постачають дані в мережу Celestia. Блочні виробники всередині Celestia організовують ці фрагменти даних у структуру дерева Меркля, вбудовують їх в блоки TIA та розповсюджують їх серед перевіряючих та повних вузлів мережі. За рахунок значного обсягу даних і великих розмірів блоків багато людей вибирають запуск лише легких вузлів замість повних вузлів. Легкі вузли синхронізують лише заголовки блоків, які містять корінь дерева Меркля.

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

(Джерело зображення: W3 Hitchhiker)

У мережі Celestia існує безліч легких вузлів, які займаються високочастотним збором даних з різних повних вузлів. Ці легкі вузли випадковим чином вибирають конкретні фрагменти даних з дерева Меркля та швидко й ефективно розповсюджують їх до інших підключених вузлів, спрямовуючи їх на розподіл даних серед широкої аудиторії людей та пристроїв. Цей підхід сприяє швидкому розповсюдженню даних, забезпечуючи тим самим, що достатня кількість вузлів отримує найновіші дані, тим самим усуваючи потребу в обмеженій групі постачальників даних. Ця фундаментальна мета підкреслює основну сутність доступності даних (DA) та розподілу даних.

Однак, незважаючи на ефективність вищезгаданого рішення щодо забезпечення швидкого доступу до даних, воно не гарантує цілісності джерела даних. Наприклад, виробник блоків Celestia може потенційно вставити помилкові дані в блок, ускладнюючи зусилля зі відновлення повного та точного набору даних. Навіть якщо люди отримають всі фрагменти даних у блоку, вони не можуть відновити повний набір даних, який «повинен бути включений». (Примітка: Тут важливе слово «повинен»).

Крім того, в сценаріях, де певні дані про транзакції залишаються невідомими для зовнішніх сторін, утримання всього 1% фрагментів даних може ускладнити зовнішнім особам відновлення всього набору даних - ситуація, схожа на атаки з утриманням даних.

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

Для вирішення проблеми атак з утриманням даних Celestia використовує двовимірне кодування стирання. Якщо принаймні 1/4 фрагментів даних (коди стирання) в блоку є дійсними, особи можуть відновити початковий набір даних. Однак, якщо виробник блоку вставляє 3/4 помилкових фрагментів даних, відновлення набору даних стає неможливим. На відмітку слід відзначити, що надмірна кількість сміттяних даних в блоку може бути легко визначена світловими вузлами, діючими як засіб запобігання злочинних дій виробників блоків.

Застосовуючи це рішення, Celestia ефективно зменшує утримання даних на своїй платформі поширення даних. B^2 Network планує використовувати методологію вибіркового відбору даних Celestia як фундаментальну точку посилання у майбутньому, потенційно інтегруючи криптографічні технології, такі як зобов'язання KZG, щоб підвищити ефективність та надійність процесів вибіркового відбору та верифікації даних, які здійснюються легкими вузлами.

Важливо розуміти, що, хоча вищезгадане рішення вирішує зберігання даних безпосередньо в платформі DA, в інфраструктурі 2-го рівня, як платформа DA, так і Послідовник, мають можливості зберігання даних. У робочих процесах, подібних до мережі B^2, Послідовник генерує нові дані, організовуючи та обробляючи користувацькі транзакції та результативні зміни стану у пакети перед їх передачею на вузли B^2 Hub, що виступають в якості шару DA.

У випадках, коли у пакеті, створеному послідовником, виникають аномалії, існує ризик утримання даних або інших зловмисних дій. Отже, отримавши пакет, DA мережа B^2 Hub докладно перевіряє його вміст і відхиляє будь-які проблемні пакети. Таким чином, B^2 Hub працює не лише як шар DA, подібний до Celestia, але й функціонує як позашляховий верифікаційний шар, схожий на CKB в протоколі RGB++.

(Неповна діаграма структури базової мережі B^2)

Відповідно до останньої технічної дорожньої карти B^2 Network, як тільки B^2 Hub отримує та перевіряє партію, він зберігає її протягом певного періоду перед закінченням терміну дії та видаленням її з місцевого вузла. Для вирішення проблем застарілості та втрати даних, схожих на EIP-4844, B^2 Network створює мережу зберігаючих вузлів, які відповідають за постійне зберігання даних партії для легкого отримання історичних даних за потреби.

Однак індивідуалим найімовірніше буде працювати як вузол зберігання B^2 без вагому причини. Щоб заохочувати більше учасників працювати вузлами зберігання та підвищити довіру до мережі, потрібно встановити механізм стимулювання. Реалізація такого механізму потребує заходів щодо запобігання шахрайської діяльності. Наприклад, якщо система стимулювання винагороджує індивідуумів, які зберігають дані локально на своїх пристроях, існує ризик недобросовісної поведінки, коли хтось видаляє частину даних після завантаження, одночасно неправдиво стверджуючи, що їх збережені дані повністю — це занадто поширена форма обману.

Filecoin використовує протоколи підтвердження, відомі як PoRep та PoSt, що дозволяють вузлам зберігання надавати сертифікати зберігання як доказ того, що вони дійсно безпечно зберегли дані протягом визначеного часу. Однак цей підхід до доведення зберігання включає створення ZK-доказів, які вимагають значних обчислювальних зусиль та ставлять значні вимоги до апаратного забезпечення зберігання, що потенційно робить його економічно невигідним.

У найновішій технологічній дорожній карті мережі B^2, вузли зберігання реалізують механізм, схожий на Arweave, конкуруючи за можливість виробляти блоки, щоб заробити токенні стимули. Якщо вузол зберігання приховано видаляє дані, ймовірність стати наступним виробником блоків зменшується. Вузли, які зберігають найбільше даних, мають більшу ймовірність успішного вироблення блоків та отримання більших винагород. Отже, для більшості вузлів зберігання вигідно підтримувати повний історичний набір даних для оптимізації їхніх перспектив вироблення блоків.

Схема перевірки стану, поєднана з ZK та доказом шахрайства

Раніше ми детально розглянули рішення Доступності Даних (DA) мережі B^2, а тепер ми поглибимося в її механізм перевірки стану. Термін "схема перевірки стану" стосується того, як Рівень 2 забезпечує достатньо "недовірчивий" перехід у стані.

(Сайт L2BEAT оцінює п'ять основних показників безпеки для Scroll. Перевірка стану відноситься до схеми перевірки стану)

Як підкреслено на веб-сайті L2BEAT, який оцінює показники безпеки для Scroll, перевірка стану специфічно адресує схему перевірки стану. У мережі B^2 та більшості процесів 2-го рівня нові дані походять від послідовника. Цей суб'єкт консолідує та обробляє транзакції, ініційовані користувачем, разом зі змінами їх статусу після виконання. Ці модифікації упаковуються в партії та поширюються на різні вузли у мережі 2-го рівня, охоплюючи стандартні повні вузли 2-го рівня та вузли B^2 Hub.

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

Діючи як громадський ланцюжок Proof-of-Stake (POS), B^2 Hub розрізняє між виробниками блоків та перевіряючими. Періодично виробники блоків B^2 Hub генерують нові блоки та поширюють їх на інші вузли (валідаторів). Ці блоки увібрали дані партії, що були надіслані послідовником, віддзеркалюючи процес, схожий на Celestia. Зовнішні вузли часто запитують фрагменти даних від вузла B^2 Hub, сприяючи розповсюдженню даних партій на численні вузли, включаючи зазначену вище мережу сховищ.

У межах B^2 Hub діє ключова роль, відома як Зафіксований. Цей суб'єкт хешує дані партії (зокрема корінь Меркля), зберігає індекс та надсилає його на ланцюг Bitcoin у вигляді напису. Доступ до хешу даних та збереженого індексу дозволяє витягувати повні дані з позаланцюжкового шару DA/сховищного шару. Припускаючи, що N вузлів зберігають дані партії під ланцюгом, якщо вузол готовий поділитися даними зовнішніми суб'єктами, будь-яка зацікавлена сторона може отримати необхідні дані. Припущення про довіру в цьому сценарії - 1/N.

Звичайно, очевидно, що в вищезазначеному процесі B^2 Hub, відповідальний за перевірку переходів стану Шару 2, працює незалежно від основної біткойн-мережі, служачи виключно як позамережевий верифікаційний шар. Відповідно, схема верифікації стану Шару 2 на цьому етапі не в змозі повністю відповідати надійності основної біткойн-мережі.

В цілому ZK Rollup має здатність повністю успадковувати безпеку Рівня 1. Однак, враховуючи поточні обмеження ланцюга Bitcoin у підтримці лише базових обчислень та відсутність прямих можливостей перевірки ZK-доказів, жодне рішення Рівня 2 на Bitcoin не може конкурувати з моделлю безпеки Ethereum, особливо ті, які використовують техніки ZK Rollup, такі як Citrea та BOB.

На даний момент більш життєздатний підхід, як пояснюється в технічному документі BitVM, передбачає розвантаження складних обчислювальних процесів з ланцюжка Bitcoin. За потреби в ланцюжок переносяться лише основні обчислення. Наприклад, обчислювальні сліди, згенеровані під час перевірки доказів ZK, можуть бути публічно розкриті та передані зовнішнім організаціям для ретельної перевірки. Якщо виникнуть будь-які розбіжності на складних етапах розрахунку, люди можуть перевірити ці спірні розрахунки в ланцюжку Bitcoin. Це вимагає використання скриптової мови Bitcoin для емуляції функціональних можливостей спеціалізованих віртуальних машин, таких як віртуальна машина Ethereum (EVM). Хоча це зусилля може вимагати значних інженерних зусиль, воно залишається здійсненним заходом.

References:“Мінімалістичне тлумачення BitVM: Як перевірити докази шахрайства на ланцюгу BTC (виконати операційний код EVM або іншого VM)”

У технічному рішенні B^2 Network, як тільки послідовник генерує нову партію, вона передається агрегатору та Prover. Prover тоді ZK-izes процес перевірки даних партії, виробляє сертифікат ZK і, нарешті, передає його вузлу B^2 Hub, сумісному з EVM. ZK Proof автентифікується через контракт Solidity, з усіма обчислювальними процесами, розбитими на складні логічні вентилеві схеми низького рівня. Ці схеми кодуються мовою скрипта Bitcoin, форматуються та подаються на сторонню платформу доступності даних (DA) з достатньою пропускною здатністю.

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

(Загальна структурна схема мережі B^2, за винятком вузлів вибіркового зразка даних)

Так кого ж карають? Власне, це і є Committer. В рамках B^2 Network, Committer не тільки транслює раніше згаданий хеш даних в ланцюжок Bitcoin, але і розкриває перевірочні «зобов'язання» сертифіката ZK до основної мережі Bitcoin. Завдяки певним конфігураціям Bitcoin Taproot фізичні особи зберігають можливість подавати запити та оскаржувати «зобов'язання щодо підтвердження підтвердження ZK», видане Коміттером у ланцюжку Bitcoin у будь-який момент часу.

Щоб розкрити поняття "зобов'язання", це означає, що особи підтверджують точність певних даних поза ланцюжком та публікують відповідну заяву на блокчейні. Ця заява служить як "зобов'язання", де значення обіцянки пов'язані з конкретними даними поза ланцюжком. У рішенні B^2, якщо будь-яка сторона ставить під сумнів зобов'язання перевірки ZK, видане Комітентом, вони мають можливість викликати його.

Хтось може запитати, чому B^2 Hub потрібно перевіряти ZK-сертифікат «повторно і всебічно», якщо він вже підтверджує Партію при отриманні. Чому б не розкрити процес перевірки партії публічно для прямих викликів замість введення доказу ZK? Включення доказу ZK служить для ущільнення слідів обчислень до більш керованого розміру перед випуском. Публічне розголошення процесу верифікації, що включає у себе транзакції рівня 2 та зміни стану в логічних воротах та сценаріях Bitcoin, призведе до значного обсягу даних. ZKізація ефективно стискає ці дані перед їх поширенням.

Ось стислий опис робочого процесу B^2:

1. Послідовник в B^2 генерує нові блоки 2-го рівня та об'єднує кілька блоків у партії даних. Ці партії далі передаються агрегатору та валідатору вузла в мережі B^2 Hub.

2. Агрегатор надсилає пакет даних вузлу Підтверджувача, що дозволяє створення відповідного доказу відсутності знань. Подальше ZK-сертифікат передається до мережі DA та перевіряючого пристрою B^2 (хаб B^2).

3. Вузол B^2 Hub перевіряє, чи ZK Proof від агрегатора співпадає з Batch від Sequencer. Успішна відповідність свідчить про проходження верифікації. Підтверджений хеш даних партії та індекс зберігання передаються на ланцюг Bitcoin визначеним вузлом B^2 Hub (Комітет).

4. Весь процес розрахунку для перевірки ZK Proof публічно оприлюднено B^2 Hub, з Зобов'язанням цього процесу, поданого до ланцюга Bitcoin для можливих викликів. Успішний виклик призводить до економічних пеналтів для випускаючого вузла B^2 Hub (їх UTXO на ланцюзі Bitcoin розблокується та переходить до викликача).

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

За даними членів західної біткойн-спільноти, існують припущення про потенційний майбутній форк біткойн-мейнету для підтримки покращених обчислювальних можливостей. Це може відкрити шлях для прямої перевірки ZK-доказів на біткойн-ланцюгу, що відзначає трансформаційні зміни для всього біткойн-шару 2. Будучи базовим шаром DA та перевірки, B^2 Hub не тільки працює як основна складова B^2 Network, але й надає потужність іншим другим шарам біткойн. У конкурентному світі рішень шару 2 біткойн, шари функціонального розширення поза ланцюжком набувають популярності, з B^2 Hub та BTCKB, які представляють лише уявлення цього змінюючогося ландшафту.

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

1. Ця стаття була відтворена з [Гік Веб3 ), з оригінальною назвою «Аналіз нової дорожньої карти технології B^2: необхідність шару DA та верифікації під ланцюгом Bitcoin.» Авторське право належить оригінальному автору, Фаусту з Geek Web3. Якщо є які-небудь зауваження до репринту, будь ласка, зв'яжітьсяКоманда Gate Learnдля швидкого вирішення відповідно до відповідних процедур.

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

3. Переклади статей на інші мови здійснюються командою Gate Learn. Перекладені статті не можуть бути скопійовані, поширені або плагіатовані без зазначення Gate.io.