Починаючи з «Літа написів» у 2023 році, технології Layer2 від Bitcoin були в авангарді революції Web3. Незважаючи на те, що Bitcoin вийшов на поле пізніше, ніж рішення Layer2 від Ethereum, він скористався унікальною привабливістю POW і плавним запуском спотових ETF, вільних від ризиків «сек'юритизації», щоб залучити мільярди доларів інвестицій у цей зростаючий сектор всього за шість місяців. Серед них Merlin виділяється як найзначніша та найпослідовніша організація в ландшафті Bitcoin Layer2, що володіє мільярдами загальної заблокованої вартості (TVL). Завдяки чітким стимулам для стейкінгу та вражаючим прибуткам Merlin швидко став відомим, перевершивши навіть відому екосистему Blast за лічені місяці. Зі зростанням ажіотажу навколо Merlin дослідження його технічної інфраструктури захоплює все більшу аудиторію. У цій статті Geek Web3 зосереджується на розшифровці технічних стратегій, що лежать в основі Merlin Chain. Розкриваючи загальнодоступні документи та обґрунтування дизайну протоколу, ми прагнемо демістифікувати операційні процеси Merlin і покращити розуміння його системи безпеки, надаючи більш чітке уявлення про те, як функціонує це провідне рішення Bitcoin Layer2.

Мерлінова децентралізована мережа оракулів: Відкритий оффлайн комітет DAC

Для кожної технології Layer2 питання доступності даних (DA) та вартості публікації даних залишається критичним викликом, чи то для Ethereum Layer2, чи для Bitcoin Layer2. Беручи до уваги вроджені обмеження мережі Bitcoin, яка має проблеми з великим пропускним здатністю даних, стратегічно використовувати цінний простір DA - великий випробування для творчості розробників Layer2.

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

Серед тих, хто використовує першу стратегію, виділяється Citrea. Вони мають на меті завантажувати зміни в станах Layer2 через певні інтервали, що включає запис результатів змін стану по різних рахунках, разом з відповідними доказами нульового знання (ZKPs), на біткойн-блокчейні. За цією угодою будь-хто може отримати доступ до різниці стану та ZKPs з Bitcoin mainnet для відстеження змін стану Citrea. Цей підхід ефективно зменшує розмір даних, завантажених на блокчейн, на понад 90%.

Хоча це значно стискає розмір даних, загатоці ще очевидний. Якщо велика кількість облікових записів змінюють свій статус протягом короткого періоду часу, Шар 2 повинен узагальнити та завантажити всі зміни в цих облікових записах на біткойн-ланцюг. Вартість остаточного випуску даних не може бути дуже низькою. Це правда в багатьох Ефірах. Це можна побачити в ZK Rollup.

Багато Bitcoin Layer 2 просто йдуть другим шляхом: безпосередньо використовують рішення DA під ланцюгом Bitcoin, будують DA шар самостійно або використовують Celestia, EigenDA, тощо. B^Square, BitLayer і головний герой цієї статті, Мерлін, всі використовують це рішення розширення DA поза ланцюгом.

Попередня стаття на гік веб3——«Аналіз технологічної дорожньої карти нової версії B^2: необхідність шару DA та верифікації під ланцюгом Bitcoin», ми зазначили, що B^2 безпосередньо імітував Celestia та побудував мережу DA, яка підтримує функцію вибірки даних під ланцюгом, яку називають B^2 Hub. «DA дата», така як дані транзакцій або різниця в стані, зберігається під ланцюгом Bitcoin, і лише datahash / merkle root завантажується на головну мережу Bitcoin.

Це в суті ставить Bitcoin у якості безпідозрісної дошки оголошень: кожен може прочитати datahash з ланцюжка Bitcoin. Після отримання даних DA від постачальника даних поза ланцюжком ви можете перевірити, відповідає він datahash на ланцюжку, тобто hash(data1) == datahash1? Якщо існує відповідність між ними, це означає, що дані, надані вам постачальником даних поза ланцюжком, є вірними.

DA Layer in Bitcoin’s Layer2 Пояснено:

(Джерело зображення: Гік веб3)

Ця система забезпечує, що дані від вузлів поза ланцюжком взаємодіють з конкретними «слідами» або доказами на Layer1, захищаючи від можливої проблеми, коли DA-шар надає недостовірну інформацію. Однак виникає важлива проблема, якщо початковник даних — Послідовник — не розповсюджує фактичні дані, пов'язані з datahash. Припустимо, що Послідовник передає лише datahash на біткойн-ланцюжок, при цьому навмисно утримуючи відповідні дані від загального доступу. Що тоді станеться?

Розгляньте сценарії, де публікуються лише ZK-доказ та StateRoot, але супровідні дані DA (наприклад, різниці в стані або дані про транзакції) не публікуються. Хоча можливо перевірити ZK-доказ та забезпечити точність переходу від Prev_Stateroot до New_Stateroot, залишається невідомим, які стани рахунків змінилися. У таких умовах, навіть якщо активи користувачів залишаються безпечними, фактичний стан мережі залишається невизначеним. Ніхто не знає, які транзакції були включені в блокчейн або які стани контрактів були оновлені, що фактично призводить до недієздатності Layer2, майже ніби він вийшов з ладу.

Ця практика відома як «утримання даних». У серпні 2023 року Данкрад з Фонду Ethereum ініціював обговорення на Twitter на тему концепції, відомої як «DAC».

У багатьох Ethereum Layer2 налаштуваннях, які використовують рішення для доступності даних поза ланцюжком (DA), часто є кілька вузлів з особливими привілеями, які формують комітет, відомий як Комітет доступності даних (DAC). Цей комітет служить гарантом, забезпечуючи, що Секвенсор дійсно випустив повні дані DA (дані транзакцій або різницю в стані) поза ланцюжком. Члени DAC потім створюють колективний багатопідпис. Якщо цей багатопідпис досягає необхідного порогу (наприклад, 2 з 4), відповідні контракти на Layer1 призначені для припущення, що Секвенсор відповів стандартам перевірки DAC та дійсно випустив повні дані DA поза ланцюжком.

Комітети DAC другого рівня Ethereum в основному дотримуються моделі Proof of Authority (POA), обмежуючи членство лише для вибраної групи вузлів, які пройшли KYC або були офіційно визначені. Цей підхід ефективно зробив DAC візитною карткою «централізації» та «консорціумного блокчейну». Додатково, в деяких Ethereum Layer2s, які використовують підхід DAC, секвенатор розповсюджує дані DA виключно на членів DAC, з мінімальним зовнішнім розповсюдженням. Отже, кожен, хто шукає дані DA, повинен забезпечити схвалення від DAC, схоже на роботу в межах консорціумного блокчейну.

Очевидно, що DAC потребує децентралізації. Хоча для завантаження даних DA безпосередньо на Layer1, можливо, не потрібен Layer2, доступ до членства в DAC повинен бути загальнодоступним, щоб уникнути змови та злочинності деяких осіб. (Для отримання додаткової інформації з цього питання, зверніться до попередніх обговорень Dankrad на Twitter.)

Пропозиція Celestia щодо BlobStream має на меті в основному замінити централізований DAC на Celestia. За цією моделлю секвенсор Ethereum L2 буде публікувати дані DA на блокчейн Celestia. Якщо дві третини вузлів Celestia підтвердять ці дані, спеціалізований контракт Layer2 на Ethereum підтвердить, що секвенсор правильно опублікував дані DA, тим самим позиціонуючи вузли Celestia як гарантів. Оскільки Celestia працює з сотнями валідаторів, ця більша конфігурація DAC вважається досить децентралізованою.

Рішення DA, яке прийняв Merlin, фактично досить близьке до BlobStream Celestia, який відкриває доступ до DAC через POS, роблячи його більш децентралізованим. Будь-хто може запустити вузол DAC, якщо він ставить достатньо активів. У документації Merlin вищезазначений вузол DAC називається Oracle, і вказується, що він підтримує активні заявки на BTC, MERL і навіть токени BRC-20 для впровадження гнучкого механізму заявок, а також підтримує повірені заявки, схожі на Lido. (Угода про POS-заявку машин Oracle, фактично, є однією з наступних ключових наративів Merlin, а надані ставки зацікавленості застави відносно високі)

Тут ми коротко описуємо робочий процес Мерліна (зображення нижче):

1. Після отримання послідовника великої кількості запитів на транзакції, він агрегує їх і генерує пакет даних (пакет даних), який передається вузлу Провідника та вузлу Оракула (децентралізований DAC).

2. Вузол довірника Мерліна децентралізований і використовує сервіс Prover від lumoz як сервіс. Після отримання кількох партій даних пул з добування доказів буде генерувати відповідні докази з нульовою знаністю. Після цього ZKP буде відправлено на вузол Oracle для перевірки.

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

4. Послідовник збирає результати багато-підписових відповідей від вузлів Oracle. Коли кількість підписів відповідає вимогам порогу, інформація про підписи надсилається на ланцюг Bitcoin разом із datahash DA-даних (пакет даних) та передається зовнішньому світу для читання та підтвердження.

(Принцип роботи Мерліна діаграми джерело: Geek web3)

1. Оракульні вузли виконують спеціальну обробку у процесі перевірки обчислень з підтвердженням ZK Proof, генерують зобов'язання зобов'язань та надсилають їх на ланцюг Bitcoin, дозволяючи кому завгодно викликати "зобов'язання". Процес тут в основному такий самий, як у протоколі доказу обману bitVM. Якщо виклик буде успішним, Оракульний вузол, який випустив Зобов'язання, буде фінансово покарано. Звичайно, дані, які Оракул хоче опублікувати на ланцюг Bitcoin, також включають хеш поточного стану Layer 2 - StateRoot, а також сам ZKP, який повинен бути опублікований на ланцюг Bitcoin для зовнішнього виявлення.

References:«Мінімалістична інтерпретація BitVM: Як перевірити докази шахрайства на ланцюзі BTC»

Тут потрібно розглянути кілька деталей. По-перше, в роудмапі Merlin зазначено, що Oracle у майбутньому буде резервувати DA дані в Celestia. Таким чином, вузли Oracle можуть належним чином усувати локальні історичні дані без необхідності локального збереження даних. В той же час, зобов'язання, створене мережею Oracle, фактично є коренем дерева Меркля. Недостатньо розкривати корінь зовнішньому світу. Повний набір даних, що відповідає зобов'язанню, повинен бути зроблений громадським. Це вимагає знаходження сторонньої платформи DA. Ця платформа може бути Celestia або EigenDA, або інші шари DA.

References:“Аналіз шляху розвитку технології нової версії B^2: необхідність ЦА та шару перевірки під ланцюгом Bitcoin”

Аналіз безпеки моделі: Оптимістичний ZKRollup + Служба MPC від Cobo

Вище ми коротко описали робочий процес Мерліна, і я впевнений, що ви вже володієте його базовою структурою. Не важко помітити, що Мерлін, B^Square, BitLayer та Citrea в основному використовують ту ж саму модель безпеки - оптимістичний ZK-Rollup.

Коли вперше читаєте це слово, багато прихильників Ethereum можуть відчувати дивні відчуття. Що таке 'оптимістичний ZK-Rollup'? У розумінні спільноти Ethereum, 'теоретична модель' ZK Rollup повністю базується на надійності криптографічних обчислень і не потребує введення довірчих припущень. Слово 'оптимістичний' точно вводить довірче припущення, що означає, що люди більшість часу повинні бути оптимістичними, що Rollup не містить помилок і є надійним. Якщо виникає помилка, оператор Rollup може бути покараний шляхом доказу шахрайства. Ось звідки походить назва Optimistic Rollup, також відома як OP Rollup.

Для екосистеми Ethereum на базі Rollup оптимістичний ZK-Rollup може бути трохи непоказним, але він точно відповідає поточній ситуації на Bitcoin Layer 2. За технічних обмежень ланцюг Bitcoin не може повністю перевірити ZK Proof. Він може перевірити лише певний етап обчислювального процесу ZKP в особливих обставинах. За такої умови ланцюг Bitcoin фактично може підтримувати тільки протокол доказу шахрайства. Люди можуть вказати на помилку в певному обчислювальному етапі ZKP під час позаланцюжкової перевірки, і оскаржити це за допомогою доказу шахрайства. Звичайно, це не можна порівняти з Ethereum-style ZK Rollup, але це вже найкраще, що Bitcoin Layer 2 може досягти на даний момент. Надійна та найбільш безпечна модель безпеки.

Під вищезазначеною оптимістичною схемою ZK-Rollup припускається, що в мережі Layer 2 є N осіб, які мають право на ініціювання викликів. Достатньо, щоб один з N викликачів був чесним та надійним, міг виявляти помилки та ініціювати докази шахрайства у будь-який час, тоді перехід стану Layer 2 є безпечним. Звичайно, оптимістичний Rollup з високим рівнем завершення повинен забезпечити, що його міст виводу також захищений протоколом доказів шахрайства. Проте майже всі біткойн Layer 2 наразі не можуть досягти цієї передумови та потребують розрахунку на багато підписів/MPC. Отже, як обрати багатопідпис? Підписання рішення MPC стало питанням, що тісно пов'язане з безпекою Layer 2.

Компанія Merlin обрала послугу MPC від Cobo для рішення мосту. Використовуючи такі заходи, як ізоляція гарячого та холодного гаманця, активами мосту спільно керують Cobo та Merlin Chain. Будь-яка поведінка при виведенні коштів повинна розглядатися спільно учасниками MPC Cobo і Merlin Chain. По суті, надійність мосту виведення коштів гарантується завдяки кредитному схваленню установи. . Звичайно, це лише тимчасовий захід на даному етапі. У міру того, як проект поступово вдосконалюється, міст виведення коштів може бути замінений «оптимістичним мостом» з припущенням про довіру 1/N, впровадивши BitVM і протокол захисту від шахрайства. Однак реалізувати це буде складніше. Великі (майже всі офіційні мости рівня 2 в даний час покладаються на мультипідпис).

Загалом, ми можемо вирішити це, Мерлін представив рішення засноване на POS DAC, оптимістичний ZK-Rollup на основі BitVM та рішення зберігання активів на основі MPC від Cobo, вирішуючи проблему DA шляхом відкриття дозволів DAC; забезпечення безпеки переходів стану шляхом впровадження BitVM та протоколів доказу шахрайства; забезпечення надійності мосту виведення шляхом впровадження сервісу MPC від відомої платформи зберігання активів Cobo.

Стратегія подання ZKP з двоетапною перевіркою Lumoz

У наших попередніх обговореннях ми розглянули безпекову структуру Мерліна та дослідили інноваційну концепцію оптимістичних ZK-rollups. Ключовим елементом технологічної траєкторії Мерліна є децентралізований Prover. Ця роль важлива в архітектурі ZK-Rollup, де йому доручено генерувати ZK-докази для партій, що видані Sequencer. Створення доказів з нульовим рівнем інформації є помітно витратними ресурсами, що становить значний виклик.

Однією з основних стратегій для прискорення генерації ZK-доказів є поділ та паралелізація завдань. Цей процес, відомий як паралелізація, передбачає розбиття генерації ZK-доказів на окремі частини. Кожна частина обробляється різним Prover, і, нарешті, Aggregator об'єднує ці індивідуальні докази в єдине ціле. Цей підхід не лише прискорює процес, але й ефективно розподіляє обчислювальне навантаження.

Для прискорення процесу генерації доказу ZK Merlin прийме рішення Lumoz’s Prover as a service, фактично, це збір великої кількості апаратних пристроїв, щоб сформувати басейн для майнінгу, а потім розподілити обчислювальні завдання на різні пристрої та розподілити відповідні стимули, що дещо схоже на майнінг POW.

У цьому децентралізованому рішенні Prover існує тип сценарію атаки, який загалом відомий як атака фронтраннінгу: Припустимо, що Агрегатор встановив ZKP, і він відправляє ZKP, щоб отримати винагороду. Після того, як інші агрегатори побачили вміст ZKP, вони публікують той самий вміст перед ним, стверджуючи, що він згенерував ZKP першим. Як вирішити цю ситуацію?

Можливо, найінстинктивніше рішення, на яке думає кожен, - це призначити певний номер завдання кожному Агрегатору. Наприклад, лише Агрегатор А може виконати завдання 1, і інші не отримають винагороду навіть у разі його виконання. Проте цей підхід має проблему, а саме нездатність протистояти ризикам єдиного точкового збою. Якщо Агрегатор А має відмову в роботі або втратить з'єднання, завдання 1 залишиться заблокованим і не може бути завершеним. Більше того, цей метод розподілу завдань одній сутності не може підвищити продуктивність через конкурентний стимулюючий механізм і не є гарним підходом.

Polygon zkEVM колись запропонував метод, який називається Доказ ефективності у блозі, в якому вказується, що для стимулювання конкуренції між різними Агрегаторами слід використовувати конкурентні засоби, а поощри слід розподіляти за принципом першим прийшов - першим обслужений. Агрегатор, який першим надсилає ZK-доказ на ланцюг, може отримати винагороду. Звісно, він не згадав, як вирішити проблему фронтраннінгу MEV.

Lumoz використовує двоетапний метод перевірки сертифіката ZK. Після того, як агрегатор генерує сертифікат ZK, йому не потрібно спочатку надсилати повний контент, а лише публікує хеш ZKP. Іншими словами, публікує хеш (ZKP+Aggregator Address). Таким чином, навіть якщо інші бачать хеш-значення, вони не знають відповідного вмісту ZKP і не можуть безпосередньо стрибнути вперед;

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

За допомогою цієї схеми подання ZKP за двохетапною перевіркою Мерлін (Lumoz) може вирішити проблему попереднього розбіжності, що існує в процесі подання ZKP, тим самим досягнувши висококонкурентоспроможних стимулів для генерації доказів з нульовою інформацією, тим самим збільшивши швидкість генерації ZKP.

Фантом Мерліна: багатоцепова взаємодія

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

Наприклад, обліковий запис EOA, керований мережею Мерлін, може бути розгорнутий на Полігоні, коли користувач видає інструкцію щодо міжланцюгової взаємодії на Ланцюгу Мерлін, мережа Мерлін спочатку аналізує її вміст та генерує дані транзакції для виконання на цільовому ланцюжку, а потім мережа Оракул виконує обробку підпису MPC на транзакції для генерації підпису транзакції. Вузол-реле Мерлін потім випускає транзакцію на Полігоні, завершуючи подальші операції через активи Мерлін у обліковому записі EOA на цільовому ланцюжку, такі як.

Коли операція, запитана користувачем, буде завершена, відповідні активи будуть безпосередньо переслані на адресу користувача на цільовому ланцюжку. Теоретично вони також можуть бути безпосередньо перекладені на Merlin Chain. Це рішення має деякі очевидні переваги: воно може уникнути комісій та зносу, спричиненого контрактами місткості між ланцюгами під час традиційного переходу активів між ланцюгами, і безпека міжланцюжкових операцій безпосередньо гарантується Oracle Network Merlin, і немає потреби покладатися на зовнішні сторони. інфраструктура. Якщо користувачі довіряють Merlin Chain, така поведінка міжланцюжкової взаємодії може бути вважана без проблем.

Узагальнити

У цій статті ми коротко інтерпретуємо загальне технічне рішення Merlin Chain, яке, на нашу думку, дозволить більшій кількості людей зрозуміти загальний робочий процес Merlin та мати чітке уявлення про його безпекову модель. З урахуванням того, що поточна екосистема Bitcoin перебуває в розквіті, ми вважаємо, що цей вид популяризації технологій є цінним і необхідним для широкої громадськості. Ми будемо проводити довгострокове вивчення Merlin, bitLayer, B^Square та інших проектів у майбутньому, для більш глибокого аналізу їх технічних рішень, тому слідкуйте за оновленнями!

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

1. Ця стаття взята з [Gateгік веб3], авторські права належать оригінальному автору [Faust], якщо у вас є будь-які зауваження до перевидання, будь ласка, зв'яжіться Команда Gate LearnКоманда якнайшвидше вирішить це відповідно до відповідних процедур.

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

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