Вступ:

Поточна сцена Bitcoin Layer2 кишить різноманітними технологічними рішеннями, що сходяться в плавильному котлі екосистеми BTC. Враховуючи швидкі темпи ітерацій у сфері блокчейну, де професійна лексика та стандарти постійно розвиваються завдяки дослідженням, інноваціям та інженерному впровадженню, багато проєктів вдаються до «створення концепції» або «подорожі автостопом» для диференціації та уваги, стаючи негласним правилом у галузі. Наприклад, кілька модульних блокчейн-проєктів, які спочатку були активні в екосистемі Ethereum/Celestia, перейшли на платформу «Bitcoin Layer2», називаючи себе «Rollups», незважаючи на те, що їхні технічні рішення часто не відповідають стандартам Rollup. Однак термін «Rollup» має значне визнання, що робить його вигідним у рекламних цілях. Багато операторів проектів або нав'язливо позначають себе як Rollups, або розгалужують основну концепцію Rollup з розпливчастими уточненнями, такими як «Sovereign Rollup». Відкинувши шари цих «XX Rollups», багато проектів, по суті, засновані на «перевірці на стороні клієнта» або «сайдчейнах», просто використовуючи слоган «XX Rollup» для зручності. Хоча ця рекламна стратегія є поширеною, вона, як правило, вводить в оману, завдаючи більше шкоди, ніж користі тим, хто шукає правду.

(Цей підхід, узагальнений міністром пропаганди нацистів Геббельсом як «пропаганда на основі брехні», часто спостерігається серед операторів проєктів.) Як тоді можна розрізнити таку поведінку «підвішування концепції Rollup»? Можливо, починаючи з перших принципів, визначення різних категорій проєктів Layer2 та їх рівнів безпеки та функціональності на основі широко прийнятих стандартів на Заході та в галузі загалом, може принести ясність. Тут не обов'язково йти шляхом вибору рішення; суть полягає в тому, чи забезпечує механізм проєкту безпеку та надійність мережі Layer2 та дійсно наділяє мережу BTC головної мережі потужністю.

У цій статті ми будемо використовувати Chainway, проект Bitcoin Layer2, як тематичне дослідження, щоб проаналізувати природу «перевірки на стороні клієнта», приховану за слоганами деяких проектів «Rollup». Ми прагнемо чітко розмежувати «Sovereign Rollup» і «перевірку на стороні клієнта», а також суттєві відмінності від галузевих стандартів ZKRollups або OPRollups, які покладаються на смарт-контракти. Це не означає, що Sovereign Rollups або валідації на стороні клієнта поступаються ZK Rollups у безпеці та надійності; Все залежить від їх конкретних деталей реалізації. Chainway, як правило, рівень валідації на стороні клієнта, запропонував схему антицензурних транзакцій, запущену на BTC з позаланцюговою перевіркою, використовуючи рекурсивні докази ZK, подібні до тих, що використовуються публічним ланцюгом MINA, позиціонуючи його попереду багатьох проектів Bitcoin Layer2. Ми вважаємо, що дослідження технології Chainway є цінним, пропонуючи важливу інформацію для спостерігачів Bitcoin Layer2. (Рекламні зображення Chainway брендують його як ZK Rollup, але його старим рішенням була перевірка на стороні клієнта, а ZKR був ще одним їхнім проектом. Наразі він не досяг консенсусу клієнтів поза мережею або надійного обміну повідомленнями.

Основний текст: Chainway — це добре відомий проєкт Bitcoin Layer2 у західній спільноті, який багато KOL часто називають «ZK Rollup», тоді як його технічна документація позиціонує його як «Sovereign Rollup». Нещодавно Chainway також оголосила про свій новий проект Citrea, стверджуючи, що це ZK Rollup, заснований на BitVM. Однак, оскільки Citrea ще не описала своє рішення для верифікації ZK на основі BitVM, ця стаття буде присвячена технічній інтерпретації попередніх рішень Chainway. Таким чином, загальнодоступне технічне рішення Chainway передбачає публікацію даних DA через протокол Ordinals, використання BTC як рівня DA та публікацію деталей зміни стану (State diff) + ZK Proof для перевірки правильності змін стану на рівні 1, що еквівалентно публікації повних, перевірених даних транзакцій. Однак, оскільки Layer1 безпосередньо не перевіряє докази ZK, а перевірка проводиться незалежними клієнтами/вузлами поза мережею, а поточна кодова база Chainway не досягла консенсусу серед офчейн-клієнтів і не заявила, що вирішує цю проблему в соціальних мережах, публічно оприлюднене технічне рішення Chainway, по суті, належить до категорії «перевірка на стороні клієнта», навіть нагадуючи криптографічно індексований протокол, що підтримує мости активів. У наступних розділах ми представимо конкретну технічну реалізацію Chainway та проаналізуємо її модель безпеки.

Що таке Суверенний Ролап: Публікація Шару Доступності Даних (DA) + Верифікація поза ланцюгом

У технічній документації Chainway використовується концепція Суверенного Rollup від Celestia. Суверенний Rollup фундаментально відрізняється від загальноприйнятої концепції Rollup у спільноті Ethereum та більш широкій галузі (Rollup з смарт-контрактами). Таким чином, яка саме структура Суверенного Rollup?

У суті, Suvereign Rollup на основі Bitcoin дещо подібний до «клієнтської групи/побічного ланцюжка, яка публікує дані DA поза ланцюжком BTC». Його основна характеристика полягає в тому, що для перевірки переходів стану/міжланцюжкових дій для Layer 2 не потрібні розумні контракти на Layer 1. У суті, він використовує BTC як шар DA, а його модель безпеки в значній мірі подібна до «перевірки клієнта». Звичайно, деякі більш безпечні рішення Suvereign Rollup покладаються на підтвердження третьої сторони поза ланцюжком Bitcoin (аналогічно побічному ланцюжку), щоб виконувати перевірки переходу стану. Крім того, серед різних незалежних клієнтів/повних вузлів існує рівень згоди або надійного передавання повідомлень для досягнення «угоди» щодо певних суперечливих дій. Однак деякі проекти Suvereign Rollup ґрунтуються виключно на «перевірці клієнта», позбавлені надійного передавання повідомлень між незалежними клієнтами/вузлами.

Щоб краще зрозуміти унікальну концепцію "Sovereign Rollup", корисно порівняти її з її аналогом, smart contract Rollup. На Ethereum рішення другого рівня в основному є smart contract Rollups, такі як Arbitrum та StarkNet. Структуру smart contract Rollup можна уявити за наступною діаграмою:

(Уявіть тут діаграму)

На діаграмі ми бачимо кілька термінів, пов'язаних з модульною блокчейн-наративом, пояснені наступним чином:

• Шар виконання: Виконує транзакції користувачів, оновлює стан блокчейну та надсилає дані на рівень DA та рівень розрахунків.

• Шар розрахунків: Підтверджує переходи стану з рівня виконання, вирішує спори (такі як докази шахрайства) та забезпечує модуль моста для обробки активів моста L1-L2.

• Шар доступності даних (DA): Діє як велика дошка оголошень, отримуючи дані про перехід стану, подані шаром виконання, і надаючи ці дані у безпечний спосіб будь-кому.

• Шар консенсусу: Забезпечує остаточність порядку транзакцій. Його функція, здається, дещо наближена до рівня DA (підхід спільноти Ethereum до модулярного шарування блокчейну не включає рівень консенсусу).
  
  З архітектури смарт-контрактів Rollups ми бачимо, що Ethereum відіграє роль останніх трьох шарів, крім виконавчого шару. Інша діаграма може надати більш детальний огляд ролей, які відіграє Ethereum в смарт-контрактах Rollups.
  
  Навпаки, Суверенні Ролапи відрізняються значно тим, що децентралізують деякі з цих відповідальностей від монолітного блокчейну, такого як Ethereum. Зокрема, вони не покладаються на смарт-контракти на базовому рівні (Рівень 1) для верифікації станових переходів або вирішення спорів. Замість цього ці завдання управляються клієнтами поза ланцюжком або через посередній шар розрахунків, підкреслюючи інший підхід до досягнення масштабованості та безпеки в блокчейн системах.

У роллап-контракти на Ethereum надходять або докази дійсності, або докази шахрайства для перевірки дійсності переходів стану Layer 2. Варто зазначити, що роллап-розумні контракти діють як сутності розрахункового шару в модулярній архітектурі блокчейну. Розрахункові контракти розрахункового шару часто включають модулі мостів для обробки активів, які перебувають у мості з Ethereum на Layer 2. Для доступності даних (DA) розрахункові контракти розрахункового шару можуть вимагати від Послідовника опублікувати останні деталі транзакційних даних/зміни стану на ланцюжку. Без публікації DA на ланцюжку неможливо успішно оновити стан L2, записаний у роллап-контрактах.

(ZK Rollup або Optimistic Rollup може примусово публікувати дані DA в мережі; без цього стан, записаний на рівні розрахунків, не може бути оновлений.) Аналізуючи модель безпеки та індикатори ризику рішень рівня 2 Bitcoin/Ethereum за допомогою теорії стволів, стає зрозуміло, що смарт-контракти Rollups значною мірою покладаються на смарт-контракти рівня 1. Для такого рівня 1, як BTC, який намагається підтримувати складну бізнес-логіку, побудова рівня 2, який узгоджується з Ethereum Rollups, по суті, неможлива. З іншого боку, рішення Sovereign Rollup не вимагають контрактів на рівні 1 для державної перевірки/мосту. Їх архітектура така: (Тут відсутній опис архітектури, що означає, що ілюстрація або додаткові деталі повинні були бути включені, але не надані в тексті.)

У суверенних Rollups вузли поза шаром доступності даних (DA) виступають у якості сутностей для виконання та вирішення операцій здійснення транзакцій, пропонуючи вищий рівень свободи. Послідовність дій наступна:

Вузли на рівні виконання суверенного зведення надсилають дані про транзакції/дані про зміну стану на рівень DA, тоді як розрахунковий рівень/клієнти прагнуть отримати та перевірити дані. Важливо відзначити, що оскільки модуль розрахункового рівня не розташований на рівні 1, суверенні зведення, теоретично, не можуть досягти мостів з безпекою, еквівалентної рівню 1. Вони часто покладаються на нотаріальні мости або сторонні мостові рішення. В даний час реалізація суверенних схем верифікації Rollup/клієнта є відносно простою, вимагаючи лише публікації даних про ланцюжок Bitcoin (BTC) за допомогою протоколу, аналогічного Ordinals. Що стосується офчейн-верифікації та консенсусу, то тут існує велика гнучкість. Насправді, багато сайдчейнів просто публікують дані DA в ланцюжку BTC, по суті, стаючи «суверенними зведеннями на основі BTC», хоча конкретна безпека сумнівна. Однак проблема полягає в тому, що пропускна здатність біткойна надзвичайно низька, максимум 4 МБ на блок і середній час блоку 10 хвилин, що означає пропускну здатність даних лише 6 КБ/с. Рішення рівня 2, які претендують на звання суверенних Rollups, можуть бути не в змозі опублікувати всі дані DA в ланцюжку BTC, тому вони можуть вибрати альтернативні методи, такі як публікація даних DA поза мережею та зберігання хешу даних у ланцюжку BTC як форма «зобов'язання», або знайти спосіб сильно стиснути дані DA (наприклад, використовуючи State diff + ZK Proof, як стверджує Chainway). Очевидно, що цей режим не відповідає визначенню «суверенного зведення» або належного зведення, що представляє варіант, безпека якого сумнівна. Ми прогнозуємо, що більшість проєктів рівня 2 з банером «Rollup» в кінцевому підсумку не опублікують усі дані DA в ланцюжку BTC, тому їхні практичні рішення, швидше за все, не відповідатимуть заявам «ZK Rollup» або «OP Rollup», зробленим у їхніх технічних документах.

Наостанок, давайте коротко підсумуємо відмінності між суверенними Rollups і Rollups зі смарт-контрактами:

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

2. Мости:У ідеальних умовах мости для умовних контрактів Rollups відповідають мінімальному рівню довіри, але змінюваність контрактів може вплинути на їх безпеку. За схемою суверенного Rollup розробники повинні будувати компоненти мостів під ланцюгом рівня 1 самостійно, і побудовані мости ймовірно довіряють менше, ніж мости для умовних контрактів.

BTC DA Структура

У вищезазначеному тексті ми зазначили, що для впровадження суверенного Rollup на основі BTC ключове значення має використання протоколу Ordinals, щоб зробити так, щоб BTC служив як шар доступності даних (DA). Chainway вжив це рішення.

Ми можемо розглянути подання даних DA від послідовника Chainway, з хешем транзакції:

24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000, проілюстровано наступним чином:

Цей сценарій транзакції запозичений з підходу протоколу Ordinals, який використовує OP_0 OP_IF для запису даних для запису даних DA (доступності даних) Rollup у ланцюжок BTC. Це передбачає публікацію змін стану та ZK Proofs, що еквівалентно за безпекою публікації оригінальних даних транзакції, але дозволяє значно зменшити розмір даних. На додаток до даних DA, секвенсер також записує деякі дані аутентифікації в транзакцію, причому найважливішим є секвенсер Rollup, який підписує дані DA своїм приватним ключем, щоб гарантувати, що подання надходить із секвенсора. Важливо зазначити, що будь-яка транзакція, пов'язана з надсиланням даних DA, має 16 двійкових нулів наприкінці хешу транзакції (тобто два послідовні байти дорівнюють нулю). Це обмеження можна побачити в коді:

У згаданому раніше прикладі графіка транзакції випадкове число «b715» використовується для коригування хеш-значення транзакції таким чином, щоб її хвіст містив певні 16 нулів. Цей принцип схожий на майнінг біткойнів, де випадкове число nonce додається, щоб початкові N бітів хешу дорівнювали всім нулям, відповідаючи певним умовам обмежень. Ця конструкція має на меті спростити складність отримання даних DA (Data Availability). Коли будь-який вузол Layer2 хоче отримати доступ до даних DA, йому потрібно лише просканувати блок BTC (Bitcoin) на предмет усіх транзакцій, які закінчуються 16 нулями, ефективно відрізняючи транзакції, ініційовані сортувальником Chainway під час надсилання даних від інших транзакцій у блокчейні Bitcoin. У наступному тексті такі транзакції, що містять дані DA і відповідають вимозі закінчуватися на 16 нулів, називаються «стандартними транзакціями Chainway». Основна увага в цій статті зосереджена на тому, як Chainway досягає опору цензурі. Оскільки сортувальник Layer2 може навмисно відхилити запит на транзакцію від конкретного користувача, необхідно використовувати спеціальну схему, що дозволяє користувачам ініціювати транзакції, які не піддаються цензурі. У відповідь на цю проблему Chainway дозволяє користувачам запускати «Примусові транзакції». Після того, як користувач надішле цю декларацію транзакції в блоці BTC, сортувальник Chainway повинен обробити цей запит на транзакцію на рівні 2; В іншому випадку він не зможе нормально створити блок, або створений блок не буде розпізнаний офчейн-клієнтами. Структура параметрів примусової транзакції виглядає наступним чином:

Ця транзакція буде представлена в блокчейні Bitcoin як «транзакція специфікації Chainway», при цьому хеш транзакції закінчується 16 нулями. Сортувальник ChainWay при генерації блоків L2 повинен включати «транзакції специфікації рівня 2», які були розкриті в блокчейні BTC, але ще не записані в реєстрі L2, і об'єднувати їх у дерево Меркла, записуючи свій корінь Меркла в заголовок блоку L2. Після того, як користувач ініціює примусову транзакцію безпосередньо в блокчейні BTC, сортувальник повинен її обробити; В іншому випадку він не може згенерувати наступний дійсний блок. Клієнт Chainway поза ланцюжком BTC може спочатку перевірити доказ ZK, щоб визначити дійсність блоку L2, надісланого сортувальником, перевірити корінь Меркла заголовка блоку L2 і оцінити, чи правдиво сортувальник включив примусовий запит на транзакцію. Робочий процес можна віднести до наступної блок-схеми. Зауважте, що через обмеження простору на діаграмі нижче відсутнє судження про умову в verify_relevant_tx_list:

Таким чином, клієнт/вузол Chainway синхронізується з блоками основної мережі BTC і сканує з них «дані DA», опубліковані сортувальником Chainway. Він перевіряє, що ці дані опубліковані призначеним сортувальником і дійсно містять усі «стандартні транзакції Chainway», надіслані в ланцюжок BTC. Очевидно, що до тих пір, поки користувачі можуть побудувати транзакцію, яка відповідає зазначеним критеріям, як «стандартну транзакцію», і відправити її в ланцюжок BTC, ця транзакція в кінцевому підсумку буде включена в локальний реєстр L2 клієнта Chainway. В іншому випадку блок L2, випущений сортувальником Chainway, буде відхилений клієнтом. У поєднанні з надійною передачею повідомлень консенсусу поза мережею, схема транзакцій проти цензури Chainway наближається до ідеального методу боротьби з цензурою суверенних Rollups. Наприклад, деякі суверенні рішення Rollup прямо заявили, що в разі недійсного блокування попереджувальні повідомлення Alert будуть транслюватися серед офчейн-клієнтів для підвищення безпеки, особливо повідомляючи про мережеві аномалії клієнтам, які не можуть синхронізувати повні дані DA. Якщо блок правдиво не містить «обов'язкових транзакцій», він, очевидно, викличе трансляцію оповіщення поза мережею. Однак Chainway ще не реалізувала цей аспект (по крайней мере, опубліковані на даний момент матеріали і репозиторії коду показують, що вона не взялася за технічну реалізацію цієї частини).

Довідковий матеріал: Дослідники Celestia аналізують 6 типів варіантів зведення: Секвенсер = Агрегатор + Генератор заголовків. Навіть з урахуванням досягнутого консенсусу між офчейн-клієнтами/вузлами, ефективність «примусових транзакцій» Chainway проти цензури не така надійна, як у смарт-контрактів Rollups, таких як Arbitrum, тому що Arbitrum One в кінцевому підсумку забезпечить включення «примусових транзакцій» до реєстру Layer2 через контракти на Layer1, повністю успадкувавши антицензурні властивості Layer1. Очевидно, що Sovereign Rollups не можуть зрівнятися з Rollups смарт-контрактів у цьому аспекті, оскільки їхня ефективність боротьби з цензурою в кінцевому підсумку залежить від компонентів поза мережею. Це також визначає, що підхід схем «Sovereign Rollups» і «верифікація клієнтів» принципово не може повністю успадкувати антицензурні властивості Layer1, такі як Arbitrum One, Loopring, dydx і Degate, оскільки те, чи можуть примусові транзакції бути безперешкодно включені в реєстр Layer2, залежить від рішень офчейн-сутностей Layer2, не пов'язаних із самим Layer1. Очевидно, що підхід Chainway, який покладається виключно на розсуд офчейн-клієнтів, успадковує лише надійність DA Layer1, а не його повні антицензурні властивості. Подібно до рекурсивних доказів ZK MINA.

У цьому розділі ми подробиці розглянемо інші компоненти Chainway, які, крім використання BTC як шару DA, також реалізували рекурсивні ZK-докази, схожі на MINA. Його загальна структура показана на наступній діаграмі:

Сортувальник у мережі Chainway після обробки транзакцій користувача генерує остаточний доказ ZK (Zero-Knowledge) разом із деталями змін стану (state diff) для різних облікових записів і публікує їх у блокчейні Bitcoin (BTC). Повні ноди синхронізуватимуть усі історичні дані Chainway, опубліковані в блокчейні BTC. Кожен доказ ZK повинен не тільки доводити процес переходу стану поточного блоку, але й забезпечувати дійсність доказу ZK попереднього блоку. Виходячи з цієї схеми, ми можемо побачити, що кожного разу, коли генерується новий доказ, він, по суті, підтверджує попередній доказ рекурсивним чином, а останній доказ ZK може гарантувати дійсність усіх доказів ZK, починаючи з генезисного блоку. Ця конструкція схожа на конструкцію MINA. Коли «легкий клієнт», який синхронізує лише заголовки блоків, також відомий як легкий вузол, приєднується до мережі, йому потрібно лише перевірити дійсність останнього доказу ZK, розкритого в блокчейні BTC, щоб підтвердити, що історичні дані всього ланцюга та всі переходи станів дійсні. Якщо сортувальник діє зловмисно, навмисно відмовляючись приймати обов'язкові транзакції або не використовуючи попередній доказ ZK для рекурсивного доведення, то новозгенерований доказ ZK не може бути прийнятий клієнтом (навіть якщо він згенерований, він не розпізнається), як показано на діаграмі нижче:

Опис

Як підсумовано на початку цієї статті, Chainway по суті є суверенною схемою верифікації зведення/клієнта, яка використовує BTC як рівень доступності даних (DA). Щоб посилити стійкість до цензури Rollup, Chainway вводить концепцію примусових транзакцій. З іншого боку, Chainway використовує рекурсивну технологію захисту від ZK, що дозволяє новим вузлам більше довіряти виводу секвенсора та перевіряти точність історичних даних всього ланцюга в будь-який час. Поточна проблема з Chainway полягає в механізмі довіри його кросчейн-мосту. Оскільки компанія використовує суверенний підхід Rollup, не деталізуючи, як вона планує враховувати технічні особливості у своєму рішенні кросчейн-мостів, важко судити про його остаточну безпеку.

Сьогодні, досліджуючи технічне рішення Chainway, ми виявили, що тип технології, що просувається спільнотою проекту, не є Rollup в загальноприйнятому розумінні. Беручи до уваги, що вже існує десятки проектів Bitcoin Layer2 (що може сягнути сотень за півроку), для зменшення пізнавальних витрат технічної термінології ми продовжимо проводити глибоке дослідження класифікації рішень Layer2 та стандартів щодо безпеки, повноти функціональності та оцінки. Слідкуйте за оновленнями!

Disclaimer：

1. Ця стаття розміщена з [Web3 для гіків]. Усі авторські права належать оригінальному автору [Shew & Faust, гік web3]. Якщо є зауваження до цього перевидання, будь ласка, зв'яжіться з Ворота Навчаннякоманда, і вони оперативно розпорядяться цим.
2. Відмова від відповідальності за зобов'язання: погляди та думки, висловлені в цій статті, є виключно авторськими та не становлять жодного інвестиційного поради.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено, копіювання, поширення або плагіатування перекладених статей заборонено.