З літа написів у 2023 році і до сьогодні Біткойн Рівень 2 завжди був родзинкою всього Web3. Незважаючи на те, що зростання цієї сфери набагато пізніше, ніж у Рівень 2 в Ethereum, з неповторним шармом військовополонених і плавною посадкою Спот ETF, Біткойн без урахування ризику «сек'юритизації» всього за півроку привернула увагу десятків мільярдів доларів капіталу для похідного треку Рівень 2.
У Біткойн Рівень 2 треку Merlin, який має мільярди доларів у TVL, безсумнівно, має найбільшу об'єм і найбільшу кількість лонг підписників. Маючи чіткі стимули для стейкінгу та пристойну прибутковість, Merlin з'явився майже за лічені місяці, створивши екологічний міф, який виходить за межі Blast. З ростом популярності Merlin обговорення його технічних рішень стає все більш лонг темою.
У цій статті Geek Web3 зосередиться на технічних рішеннях Merlin Chain, інтерпретуватиме його опубліковані документи та протокол дизайнерські ідеї, і ми прагнемо дати більшій кількості лонг людей зрозуміти загальний робочий процес Merlin і мати більш чітке розуміння його моделі безпеки, щоб кожен міг зрозуміти, як працює цей «головний Біткойн Рівень 2» більш інтуїтивно зрозумілим способом.
Мережа децентралізований оракул Мерліна: відкрита рада поза блокчейном ЦАП
Для всіх рівнів 2, будь то Ethereum Рівень 2 чи Біткойн Рівень 2, витрати на DA та публікацію даних є однією з найважливіших проблем, які потрібно вирішити. У зв'язку з найтривалішими проблемами самої Біткойн мережі, яка за своєю суттю не підтримка велику пропускну здатність даних, як користуватися цим DA shorts, стало складною проблемою для перевірки уяви Рівень 2 проектів.
Висновок очевидний: якщо Рівень 2 «безпосередньо» опублікує в Біткойн Блок необроблені дані про транзакції, вона не зможе досягти високої пропускної здатності або низьких комісій. Найбільш популярним рішенням є або стиснення розміру даних якомога меншого розміру за допомогою високого стиснення і завантаження їх на Біткойн Блок, або публікація даних безпосередньо на Біткойн поза блокчейном. **
Ймовірно, найвідомішим з Рівень 2 шарів, які використовують перший підхід, є Citrea, який має намір завантажувати різницю станів Рівень 2 за певний період часу, тобто результати зміни стану на лонг рахунок, разом з відповідними доказами ZK, до Біткойн у блокчейні. У цьому випадку будь-хто може завантажити state diff і ZKP з Біткойн Основна мережа для моніторингу результатів зміни стану Citrea. Цей метод дозволяє зменшити розмір даних у ланцюжку більш ніж на 90%.
Хоча це може значно зменшити розмір даних, вузьке місце все одно є значним. Якщо за шорт проміжок часу відбувається велика кількість змін рахунок стану, Рівень 2 потрібно узагальнити і завантажити всі зміни цих рахунок в Біткойн у блокчейні, а підсумкову вартість випуску даних не можна тримати дуже низькою, що можна побачити в самому лонг Ethereum ZK Rollup.
Дуже лонг Біткойн Рівень 2 просто піти другим шляхом: безпосередньо використовувати рішення Біткойн поза блокчейном DA, або будувати шар DA самостійно, або використовувати Celestia, EigenDA і т.д. B^Square, BitLayer і Merlin, головний герой цієї статті, дотримуються цієї схеми масштабування поза блокчейном DA.
У попередній статті Geek web3 - "Analysis the New Version of B^2 Technology Roadmap: The Necessity of Біткойн поза блокчейном DA and Verification Layer" ми згадували, що **B^2 безпосередньо імітує Celestia і будує мережу DA, яка підтримує функцію вибірки даних у поза блокчейном під назвою B^2 Hub. «Дані DA», такі як дані про транзакції або різницю станів, зберігаються в Біткойн поза блокчейном, і в Біткойн Основна мережа завантажується лише кореневий файл datahash/merkle. **
Він дійсно ставиться до Біткойн як до дошки оголошень Ненадійний: будь-хто може прочитати datahash з Біткойн у блокчейні. Коли ви отримуєте дані DA від постачальника даних поза блокчейном, ви можете перевірити, чи відповідають вони у блокчейні datahash, тобто хеш(data1) == datahash1 ?. Якщо між ними є відповідність, це означає, що постачальник даних за поза блокчейном надав вам потрібні дані.
Описаний вище процес може гарантувати, що дані, надані вам поза блокчейном Нода, пов'язані з певними «підказками» на рівні 1, запобігаючи зловмисному наданню неправдивих даних на рівні DA. Але тут є дуже важливий сценарій контакту: що робити, якщо джерело даних, Секвенсер, взагалі не надсилає відповідні дані datahash, а лише надсилає datahash на Біткойн у блокчейні, але навмисно приховує відповідні дані від будь-кого, хто їх читає?
Подібні сценарії включають, але не обмежуються цим, лише публікацію ZK-Proof та StateRoot, але не публікацію відповідних даних DA (різницю станів або даних про транзакції), хоча люди можуть перевірити, чи є процес обчислення ZKProof дійсним, і переконатися, що процес обчислення від Prev_Stateroot до New_Stateroot є дійсним, але вони не знають, який рахунок стан (стан) змінився. У цьому випадку, незважаючи на те, що активи користувача в безпеці, ви взагалі не можете визначити фактичний стан мережі, і ви не знаєте, які транзакції були упаковані в ланцюжок і які контракти були оновлені.
Насправді це "приховування даних", і Данкрад з Ethereum Foundation коротко обговорив подібну проблему в Twitter у серпні 2023 року, звичайно, він в основному свічка з довгим хвостом за те, що називається "DAC".
Найдовший Ethereum Layer2, який використовує поза блокчейном рішення DA, часто створює кілька вузлів зі спеціальними дозволами для формування комітету, повна назва Data Availability Committee (DAC). Цей комітет DAC виступає гарантом, стверджуючи, що Sequencer публікує повні дані DA (дані про транзакції або різницю станів) поза блокчейном. Потім ЦАП Нода колективно генерує лонгуючий, лонг як найдовший відповідає пороговим вимогам (наприклад, 2/4), відповідний контракт на рівні 1 буде дефолтним, а Секвенсер пройшов перевірку комітету ЦАП і правдиво оприлюднив повний поза блокчейном даних DA.
Комітет DAC Ethereum Рівень 2 в основному дотримується моделі довіреності, дозволяючи лише кільком KYC або офіційно призначеним вузлам приєднатися до комітету DAC, що робить DAC синонімом «централізованого» та «консорціумного блокчейну». Крім того, в деяких Ethereum Рівень 2, які використовують модель ЦАП, секвенсор відправляє дані DA тільки вузлам-членам ЦАП, і майже ніколи не завантажує дані в інше місце, і будь-хто, хто хоче отримати дані DA, повинен отримати дозвіл комітету DAC, який принципово не відрізняється від Блокчейн консорціуму.
Немає жодних сумнівів у тому, що ЦАП має бути Децентралізація, і Рівень 2 не можемо завантажувати дані DA безпосередньо на рівень 1, але орган доступу комітету DAC має бути відкритим для зовнішнього світу, щоб запобігти змові кількох людей з метою вчинення зла. (Для обговорення сценарію пустощів DAC, будь ласка, зверніться до попередньої заяви Данкрада у Twitter)
**BlobStream, раніше запропонований Celestia, по суті, має замінити централізований ЦАП на Celestia, **Ethereum секвенсор L2 може публікувати дані DA в Celestia у блокчейні, якщо 2/3 вузла Celestia підпише його, ексклюзивний контракт Layer2, розгорнутий на Ethereum, вважає, що секвенсер правдиво оприлюднює дані DA, що фактично дозволяє Celestia Нода виступати в якості гаранта. Враховуючи, що Celestia має сотні вузлів-валідаторів, ми можемо вважати цей великий ЦАП відносно децентралізованим.
** Рішення DA, яке використовує Merlin, насправді близьке до BlobStream від Celestia, який відкриває права доступу DAC у вигляді POS, щоб зробити його децентралізованим. Будь-хто може запустити ЦАП Нода настільки лонг, наскільки він застейкати достатньо активів. У документації Merlin вищезгаданий Нода DAC згадується як Oracle, і вказується, що буде підтримуватися стейкінг активів токенів BTC, MERL і навіть BRC-20, що дозволить гнучкий механізм стейкінгу, а також стейкінг проксі-серверів, аналогічний Lido. (POS-застейкати протокол Оракул-машина — це, по суті, один із наступних основних наративів Мерліна, і надані застейкати Процентна ставка відносно високі)
Ось короткий опис робочого процесу Merlin (малюнок нижче):
Отримавши велику кількість запитів на транзакції, секвенсер агрегує їх і генерує пакет даних, який передається в Prover Нода і Oracle Нода (Децентралізація ЦАП).
Merlin's Prover Нода Децентралізація, використовуючи Prover від Lumoz як сервісну послугу. Після отримання найдовших пакетів даних майнінг-пул Prover згенерує відповідний zk-SNARKs, після чого ZKP буде відправлений на Нода Oracle для перевірки.
Оракул Нода перевірить, чи відповідає доказ ZK, надісланий ZK Майнінговий пул Lmuoz, пакету даних, надісланим секвенсером. Якщо ці два поняття можуть бути відповідні, і немає інших помилок, це перевіряється. У цьому процесі Децентралізація Oracle Nodes будуть генерувати лонгуючий сигнатури через порогові сигнатури, і оголошувати зовні - секвенсор повністю видав дані DA, і дійсним є відповідний ZKP, який пройшов перевірку Oracle Нода.
Секвенсер збирає лонг результати підпису з Нода Oracle, і коли кількість підписів відповідає пороговим вимогам, він надсилає інформацію про підпис Біткойн у блокчейні з хешем даних пакета даних DA та передає її зовнішньому світу для читання та підтвердження.
Oracle Нода спеціальну обробку свого процесу обчислень, щоб перевірити ZK Proof, згенерувати зобов'язання Commitment, відправити його на Біткойн у блокчейні і дозволити будь-кому оскаржити «зобов'язання», і процес в цьому процесі в основному такий же, як і доказ шахрайства протокол bitVM. Якщо виклик буде успішним, Нода Oracle, який опублікує Зобов'язання, буде фінансово покараний. Звичайно, дані, які Oracle хоче опублікувати в Біткойн у блокчейні, включаючи хеш поточного стану Рівень 2 - StateRoot, і сам ZKP, повинні бути опубліковані в Біткойн у блокчейні для виявлення зовнішнім світом.
Є ще кілька деталей, які потрібно уточнити, перш за все, в дорожній карті Merlin згадується, що в майбутньому Oracle буде створювати резервні копії даних DA в Celestia, щоб Oracle Нода могла належним чином видаляти місцеві історичні дані і не повинна була зберігати дані локально вічно. У той же час, Зобов'язання, згенероване Oracle Network, фактично є коренем Дерево Меркла, і недостатньо розкрити корінь зовнішньому світу, але для розкриття всіх повних наборів даних, що відповідають Зобов'язанням, необхідно знайти сторонню платформу DA, якою можуть бути Celestia, EigenDA або інші шари DA.
Аналіз моделі безпеки: оптимістичний сервіс MPC ZKRollup+Cobo
Вище ми коротко описали робочий процес Merlin, і я думаю, що ви вже добре розумієте його основну структуру. Неважко помітити, що Merlin в основному дотримується тієї ж моделі безпеки, що і B^Square, BitLayer і Citrea - оптимістичний ZK-Rollup.
Перше прочитання цього слова може змусити багатьох лонг Ethereum ентузіастів здивуватися, що таке «оптимістичний ZK-Rollup»? У сприйнятті Ethereum-спільноти «теоретична модель» ZK Rollup повністю заснована на достовірності Криптографія розрахунків, і немає необхідності вводити припущення про довіру, а слово оптимізм якраз і вводить припущення про довіру, а значить, люди повинні бути оптимістами, що Rollups не помиляються і надійні, коли вони лонг велику кількість разів. І як тільки станеться помилка, оператор Rollup може бути покараний доказ шахрайства, звідки походить назва Optimistic Rollup, також відома як OP Rollup.
Для Ethereum екосистеми домашньої бази Rollup оптимістичний ZK-Rollup може здатися дещо незвичним, але це точно відповідає поточній ситуації Біткойн Рівень 2. У зв'язку з технічними обмеженнями, Біткойн у блокчейні не може повністю перевірити ZK Proof, може перевірити лише певний крок процесу обчислення ZKP за особливих обставин, за цієї передумови, Біткойн у блокчейні насправді може лише підтримка доказ шахрайства протокол, люди можуть вказати, що ZKP у процесі перевірки поза блокчейном, певний крок обчислення має помилку, і через доказ шахрайства спосіб оскаржити, звичайно, це не можна порівняти з ZK Rollup у стилі Ethereum, але це вже Біткойн найнадійніший і Найнадійніша модель безпеки.
Згідно з наведеною вище оптимістичною схемою ZK-Rollup, за умови, що в мережі Рівень 2 є N авторизованих претендентів, лонг 1 з цих N претендентів є чесним і надійним, і може виявляти помилки та ініціювати доказ шахрайства в будь-який час, перехід стану Рівень 2 є безпечним. Звичайно, оптимістично налаштовані роллапи з відносно високим ступенем завершеності потребують забезпечення того, щоб їхні мости виведення також були захищені доказ шахрайства протокол, і в даний час майже всі Біткойн Рівень 2 не можуть досягти цієї передумови і повинні покладатися на лонг signature/MPC, тому як вибрати рішення лонг signature/MPC стало проблемою, тісно пов'язаною з безпекою Рівень 2.
Merlin вибрав послугу Cobo MPC за схемою міст, використовуючи такі заходи, як холодна та гаряча ізоляція гаманця, активами мостів спільно керують Cobo та Merlin Chain, і будь-яке зняття коштів має здійснюватися спільно MPC учасниками Cobo та Merlin Chain, по суті, забезпечуючи надійність виведення міст шляхом кредитного схвалення установи. Звичайно, це лише тимчасовий захід на даному етапі, і з поступовим удосконаленням проекту міст виведення коштів може бути замінено «оптимістичним міст» припущення про довіру 1/N шляхом введення BitVM і доказ шахрайства протокол, але приземлитися буде складніше (в даний час майже всі офіційні мости Layer2 покладаються на лонг знак).
В цілому можна розібратися, що Merlin представила ЦАП на базі POS, оптимістичний ZK-Rollup на базі BitVM і MPC рішення для зберігання активів на базі Cobo, вирішила проблему DA, відкривши дозволи ЦАП, забезпечила безпеку переходу стану, впровадивши BitVM і доказ шахрайства протокол, а також забезпечила надійність виведення міст, представивши MPC сервіс відомої платформи зберігання активів Cobo.
Схема двоетапної перевірки ZKP на основі Lumoz
Раніше ми прочісували модель безпеки Merlin і ввели концепцію оптимістичного ZK-rollup. У технологічній дорожній карті Merlin також обговорюється Децентралізація Prover. Як ми всі знаємо, Prover відіграє ключову роль в архітектурі ZK-Rollup, яка відповідає за генерацію ZKProofs для партій, випущених Sequencer, і процес генерації zk-SNARKs є дуже ресурсомістким апаратним ресурсом і дуже складною проблемою.
Для прискорення генерації доказів ЗК розпаралелювання задачі є однією з найпростіших операцій. ** Так зване розпаралелювання полягає в тому, щоб розділити задачу генерації доказів ZK на різні частини, які виконуються окремо різними проверами, і, нарешті, агрегатор агрегатора агрегує найдовший доказ в єдине ціле.
У ордер, щоб прискорити процес генерації доказів ZK, Merlin використовуватиме Prover від Lumoz як сервісне рішення, яке фактично полягає в тому, щоб зібрати велику кількість апаратних пристроїв разом, щоб сформувати майнінг-пул, а потім призначити обчислювальні завдання різним пристроям і призначити відповідні стимули, подібно до майнінгу POW.
У цій схемі Децентралізація Prover існує клас сценаріїв атаки, широко відомих як атаки з випередженням: припустимо, агрегатор-агрегатор сформував ZKP, і він відправляє ZKP в надії отримати винагороду. Після того, як контент ЗКП побачили інші агрегатори, вони кинулися викладати перед ним такий самий контент, стверджуючи, що цей ЗКП зробив їхній власний чоловік, як вирішити цю ситуацію?
Одне з найбільш інстинктивних рішень, яке може прийти в голову, - це присвоїти кожному агрегатору конкретний номер завдання, наприклад, тільки агрегатор А може взяти завдання 1, а всі інші не отримають винагороду, навіть якщо виконають завдання 1. Але одна з проблем цього підходу полягає в тому, що він не захищає від однієї точки ризику. Якщо агрегатор A зазнає збою продуктивності або розриває зв'язок, завдання 1 застрягне та не зможе його виконати. Більше того, така практика призначення завдань одному суб'єкту господарювання не є хорошим способом підвищення продуктивності за допомогою конкурентних стимулів.
Polygon zkEVM запропонував метод під назвою Proof of efficiency у своєму блозі, який стверджує, що різні агрегатори повинні бути просунуті, щоб конкурувати один з одним у конкурентній боротьбі, і що стимули повинні розподілятися в порядку живої черги, і що перші агрегатори, які подадуть ZK-Proof до мережі, можуть отримати винагороду. Звичайно, він не згадав, як вирішити проблему MEV фронту.
Lumoz використовує метод подання доказів ZK з двоетапною верифікацією, після того, як агрегатор генерує доказ ZK, йому не потрібно надсилати повний вміст, а лише публікує хеш ZKP, іншими словами, публікує хеш (ZKP+Aggregator Адреса). Таким чином, навіть якщо інші бачать значення хеш, вони не знають відповідного змісту ZKP і не можуть безпосередньо поспішати;
Якщо хтось просто скопіює весь хеш і опублікує його першим, це не має сенсу, тому що хеш містить Адреса конкретного агрегатора Х, і навіть якщо агрегатор А опублікує хеш першим, при виявленні вихідного образу хеш всі побачать, що агрегатор, Адреса міститься в ньому, - це Х, а не А.
За допомогою цієї схеми двоступеневої перевірки ZKP Merlin (Lumoz) може вирішити проблему попереднього процесу подання ZKP, а потім реалізувати висококонкурентні стимули для генерації zk-SNARKs, тим самим покращуючи швидкість генерації ZKP.
Merlin's Phantom: найдовша сумісність ланцюгів
Згідно з технічною дорожньою картою Merlin, вони також підтримка сумісність між Merlin та іншими EVM ланцюгами, і його шлях реалізації в основному такий самий, як і попередня ідея Zetachain, якщо Merlin використовується як вихідний ланцюг, а інші ланцюги EVM використовуються як цільовий ланцюг, коли Нода Merlin сприйме запит на крос-ланцюг сумісності, зроблений користувачем, це запустить подальший робочий процес над цільовим у блокчейні.
Наприклад, рахунок EOA, керований мережею Merlin, може бути розгорнутий на Polygon, ** Коли користувач публікує інструкцію з інтероперабельності крос-ланцюг на Merlin Chain, мережа Merlin спочатку аналізує його вміст і генерує дані транзакції, виконані на цільовому у блокчейні, а потім обробка підпису Oracle Network MPC транзакції генерує цифровий підпис транзакції. Потім Merlin's Relayer Нода випускає транзакцію** на Polygon, завершуючи подальші операції через активи Merlin в EOA рахунок на цільовому у блокчейні.
Коли операція, необхідна користувачеві, буде завершена, відповідний актив буде перенаправлений безпосередньо на адресу користувача в цільовому у блокчейні, а також теоретично може безпосередньо перейти в ланцюжок Merlin. Це рішення має деякі очевидні переваги: воно може уникнути зносу комісій, що генеруються традиційними контрактами на крос-ланцюг та кросчейн міст активів, і воно безпосередньо гарантується мережею Oracle Network Merlin для забезпечення безпеки крос-ланцюг операцій, і лонгуючий не потрібно покладатися на зовнішню інфраструктуру. Незважаючи на те, лонг користувачі довіряють Merlin Chain, немає проблем із тим, щоб за замовчуванням використовувати таку крос-ланцюг сумісність.
Підсумки
У цій статті ми даємо коротке пояснення загального технічного рішення Merlin Chain, яке, як вважається, допомагає більшій кількості лонг людей зрозуміти загальний робочий процес Merlin і мати більш чітке уявлення про його модель безпеки. З огляду на нинішнє Біткойн екології в самому розпалі, ми вважаємо, що така поведінка популяризації технічної науки є цінною і потрібною широкому загалу, ** У майбутньому ми проведемо лонг-річне спостереження за Merlin і bitLayer, B^Square та іншими проектами**, а також проведемо більш глибокий аналіз його технічних рішень, тому слідкуйте за новинами!
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Технічна інтерпретація механізму роботи Merlin
Автор: Фауст, гік web3
З літа написів у 2023 році і до сьогодні Біткойн Рівень 2 завжди був родзинкою всього Web3. Незважаючи на те, що зростання цієї сфери набагато пізніше, ніж у Рівень 2 в Ethereum, з неповторним шармом військовополонених і плавною посадкою Спот ETF, Біткойн без урахування ризику «сек'юритизації» всього за півроку привернула увагу десятків мільярдів доларів капіталу для похідного треку Рівень 2.
У Біткойн Рівень 2 треку Merlin, який має мільярди доларів у TVL, безсумнівно, має найбільшу об'єм і найбільшу кількість лонг підписників. Маючи чіткі стимули для стейкінгу та пристойну прибутковість, Merlin з'явився майже за лічені місяці, створивши екологічний міф, який виходить за межі Blast. З ростом популярності Merlin обговорення його технічних рішень стає все більш лонг темою.
У цій статті Geek Web3 зосередиться на технічних рішеннях Merlin Chain, інтерпретуватиме його опубліковані документи та протокол дизайнерські ідеї, і ми прагнемо дати більшій кількості лонг людей зрозуміти загальний робочий процес Merlin і мати більш чітке розуміння його моделі безпеки, щоб кожен міг зрозуміти, як працює цей «головний Біткойн Рівень 2» більш інтуїтивно зрозумілим способом.
Мережа децентралізований оракул Мерліна: відкрита рада поза блокчейном ЦАП
Для всіх рівнів 2, будь то Ethereum Рівень 2 чи Біткойн Рівень 2, витрати на DA та публікацію даних є однією з найважливіших проблем, які потрібно вирішити. У зв'язку з найтривалішими проблемами самої Біткойн мережі, яка за своєю суттю не підтримка велику пропускну здатність даних, як користуватися цим DA shorts, стало складною проблемою для перевірки уяви Рівень 2 проектів.
Висновок очевидний: якщо Рівень 2 «безпосередньо» опублікує в Біткойн Блок необроблені дані про транзакції, вона не зможе досягти високої пропускної здатності або низьких комісій. Найбільш популярним рішенням є або стиснення розміру даних якомога меншого розміру за допомогою високого стиснення і завантаження їх на Біткойн Блок, або публікація даних безпосередньо на Біткойн поза блокчейном. **
Ймовірно, найвідомішим з Рівень 2 шарів, які використовують перший підхід, є Citrea, який має намір завантажувати різницю станів Рівень 2 за певний період часу, тобто результати зміни стану на лонг рахунок, разом з відповідними доказами ZK, до Біткойн у блокчейні. У цьому випадку будь-хто може завантажити state diff і ZKP з Біткойн Основна мережа для моніторингу результатів зміни стану Citrea. Цей метод дозволяє зменшити розмір даних у ланцюжку більш ніж на 90%.
Хоча це може значно зменшити розмір даних, вузьке місце все одно є значним. Якщо за шорт проміжок часу відбувається велика кількість змін рахунок стану, Рівень 2 потрібно узагальнити і завантажити всі зміни цих рахунок в Біткойн у блокчейні, а підсумкову вартість випуску даних не можна тримати дуже низькою, що можна побачити в самому лонг Ethereum ZK Rollup.
Дуже лонг Біткойн Рівень 2 просто піти другим шляхом: безпосередньо використовувати рішення Біткойн поза блокчейном DA, або будувати шар DA самостійно, або використовувати Celestia, EigenDA і т.д. B^Square, BitLayer і Merlin, головний герой цієї статті, дотримуються цієї схеми масштабування поза блокчейном DA.
У попередній статті Geek web3 - "Analysis the New Version of B^2 Technology Roadmap: The Necessity of Біткойн поза блокчейном DA and Verification Layer" ми згадували, що **B^2 безпосередньо імітує Celestia і будує мережу DA, яка підтримує функцію вибірки даних у поза блокчейном під назвою B^2 Hub. «Дані DA», такі як дані про транзакції або різницю станів, зберігаються в Біткойн поза блокчейном, і в Біткойн Основна мережа завантажується лише кореневий файл datahash/merkle. **
Він дійсно ставиться до Біткойн як до дошки оголошень Ненадійний: будь-хто може прочитати datahash з Біткойн у блокчейні. Коли ви отримуєте дані DA від постачальника даних поза блокчейном, ви можете перевірити, чи відповідають вони у блокчейні datahash, тобто хеш(data1) == datahash1 ?. Якщо між ними є відповідність, це означає, що постачальник даних за поза блокчейном надав вам потрібні дані.
Описаний вище процес може гарантувати, що дані, надані вам поза блокчейном Нода, пов'язані з певними «підказками» на рівні 1, запобігаючи зловмисному наданню неправдивих даних на рівні DA. Але тут є дуже важливий сценарій контакту: що робити, якщо джерело даних, Секвенсер, взагалі не надсилає відповідні дані datahash, а лише надсилає datahash на Біткойн у блокчейні, але навмисно приховує відповідні дані від будь-кого, хто їх читає?
Подібні сценарії включають, але не обмежуються цим, лише публікацію ZK-Proof та StateRoot, але не публікацію відповідних даних DA (різницю станів або даних про транзакції), хоча люди можуть перевірити, чи є процес обчислення ZKProof дійсним, і переконатися, що процес обчислення від Prev_Stateroot до New_Stateroot є дійсним, але вони не знають, який рахунок стан (стан) змінився. У цьому випадку, незважаючи на те, що активи користувача в безпеці, ви взагалі не можете визначити фактичний стан мережі, і ви не знаєте, які транзакції були упаковані в ланцюжок і які контракти були оновлені.
Насправді це "приховування даних", і Данкрад з Ethereum Foundation коротко обговорив подібну проблему в Twitter у серпні 2023 року, звичайно, він в основному свічка з довгим хвостом за те, що називається "DAC".
Найдовший Ethereum Layer2, який використовує поза блокчейном рішення DA, часто створює кілька вузлів зі спеціальними дозволами для формування комітету, повна назва Data Availability Committee (DAC). Цей комітет DAC виступає гарантом, стверджуючи, що Sequencer публікує повні дані DA (дані про транзакції або різницю станів) поза блокчейном. Потім ЦАП Нода колективно генерує лонгуючий, лонг як найдовший відповідає пороговим вимогам (наприклад, 2/4), відповідний контракт на рівні 1 буде дефолтним, а Секвенсер пройшов перевірку комітету ЦАП і правдиво оприлюднив повний поза блокчейном даних DA.
Комітет DAC Ethereum Рівень 2 в основному дотримується моделі довіреності, дозволяючи лише кільком KYC або офіційно призначеним вузлам приєднатися до комітету DAC, що робить DAC синонімом «централізованого» та «консорціумного блокчейну». Крім того, в деяких Ethereum Рівень 2, які використовують модель ЦАП, секвенсор відправляє дані DA тільки вузлам-членам ЦАП, і майже ніколи не завантажує дані в інше місце, і будь-хто, хто хоче отримати дані DA, повинен отримати дозвіл комітету DAC, який принципово не відрізняється від Блокчейн консорціуму.
Немає жодних сумнівів у тому, що ЦАП має бути Децентралізація, і Рівень 2 не можемо завантажувати дані DA безпосередньо на рівень 1, але орган доступу комітету DAC має бути відкритим для зовнішнього світу, щоб запобігти змові кількох людей з метою вчинення зла. (Для обговорення сценарію пустощів DAC, будь ласка, зверніться до попередньої заяви Данкрада у Twitter)
**BlobStream, раніше запропонований Celestia, по суті, має замінити централізований ЦАП на Celestia, **Ethereum секвенсор L2 може публікувати дані DA в Celestia у блокчейні, якщо 2/3 вузла Celestia підпише його, ексклюзивний контракт Layer2, розгорнутий на Ethereum, вважає, що секвенсер правдиво оприлюднює дані DA, що фактично дозволяє Celestia Нода виступати в якості гаранта. Враховуючи, що Celestia має сотні вузлів-валідаторів, ми можемо вважати цей великий ЦАП відносно децентралізованим.
** Рішення DA, яке використовує Merlin, насправді близьке до BlobStream від Celestia, який відкриває права доступу DAC у вигляді POS, щоб зробити його децентралізованим. Будь-хто може запустити ЦАП Нода настільки лонг, наскільки він застейкати достатньо активів. У документації Merlin вищезгаданий Нода DAC згадується як Oracle, і вказується, що буде підтримуватися стейкінг активів токенів BTC, MERL і навіть BRC-20, що дозволить гнучкий механізм стейкінгу, а також стейкінг проксі-серверів, аналогічний Lido. (POS-застейкати протокол Оракул-машина — це, по суті, один із наступних основних наративів Мерліна, і надані застейкати Процентна ставка відносно високі)
Ось короткий опис робочого процесу Merlin (малюнок нижче):
Oracle Нода спеціальну обробку свого процесу обчислень, щоб перевірити ZK Proof, згенерувати зобов'язання Commitment, відправити його на Біткойн у блокчейні і дозволити будь-кому оскаржити «зобов'язання», і процес в цьому процесі в основному такий же, як і доказ шахрайства протокол bitVM. Якщо виклик буде успішним, Нода Oracle, який опублікує Зобов'язання, буде фінансово покараний. Звичайно, дані, які Oracle хоче опублікувати в Біткойн у блокчейні, включаючи хеш поточного стану Рівень 2 - StateRoot, і сам ZKP, повинні бути опубліковані в Біткойн у блокчейні для виявлення зовнішнім світом.
Є ще кілька деталей, які потрібно уточнити, перш за все, в дорожній карті Merlin згадується, що в майбутньому Oracle буде створювати резервні копії даних DA в Celestia, щоб Oracle Нода могла належним чином видаляти місцеві історичні дані і не повинна була зберігати дані локально вічно. У той же час, Зобов'язання, згенероване Oracle Network, фактично є коренем Дерево Меркла, і недостатньо розкрити корінь зовнішньому світу, але для розкриття всіх повних наборів даних, що відповідають Зобов'язанням, необхідно знайти сторонню платформу DA, якою можуть бути Celestia, EigenDA або інші шари DA.
Аналіз моделі безпеки: оптимістичний сервіс MPC ZKRollup+Cobo
Вище ми коротко описали робочий процес Merlin, і я думаю, що ви вже добре розумієте його основну структуру. Неважко помітити, що Merlin в основному дотримується тієї ж моделі безпеки, що і B^Square, BitLayer і Citrea - оптимістичний ZK-Rollup.
Перше прочитання цього слова може змусити багатьох лонг Ethereum ентузіастів здивуватися, що таке «оптимістичний ZK-Rollup»? У сприйнятті Ethereum-спільноти «теоретична модель» ZK Rollup повністю заснована на достовірності Криптографія розрахунків, і немає необхідності вводити припущення про довіру, а слово оптимізм якраз і вводить припущення про довіру, а значить, люди повинні бути оптимістами, що Rollups не помиляються і надійні, коли вони лонг велику кількість разів. І як тільки станеться помилка, оператор Rollup може бути покараний доказ шахрайства, звідки походить назва Optimistic Rollup, також відома як OP Rollup.
Для Ethereum екосистеми домашньої бази Rollup оптимістичний ZK-Rollup може здатися дещо незвичним, але це точно відповідає поточній ситуації Біткойн Рівень 2. У зв'язку з технічними обмеженнями, Біткойн у блокчейні не може повністю перевірити ZK Proof, може перевірити лише певний крок процесу обчислення ZKP за особливих обставин, за цієї передумови, Біткойн у блокчейні насправді може лише підтримка доказ шахрайства протокол, люди можуть вказати, що ZKP у процесі перевірки поза блокчейном, певний крок обчислення має помилку, і через доказ шахрайства спосіб оскаржити, звичайно, це не можна порівняти з ZK Rollup у стилі Ethereum, але це вже Біткойн найнадійніший і Найнадійніша модель безпеки.
Згідно з наведеною вище оптимістичною схемою ZK-Rollup, за умови, що в мережі Рівень 2 є N авторизованих претендентів, лонг 1 з цих N претендентів є чесним і надійним, і може виявляти помилки та ініціювати доказ шахрайства в будь-який час, перехід стану Рівень 2 є безпечним. Звичайно, оптимістично налаштовані роллапи з відносно високим ступенем завершеності потребують забезпечення того, щоб їхні мости виведення також були захищені доказ шахрайства протокол, і в даний час майже всі Біткойн Рівень 2 не можуть досягти цієї передумови і повинні покладатися на лонг signature/MPC, тому як вибрати рішення лонг signature/MPC стало проблемою, тісно пов'язаною з безпекою Рівень 2.
Merlin вибрав послугу Cobo MPC за схемою міст, використовуючи такі заходи, як холодна та гаряча ізоляція гаманця, активами мостів спільно керують Cobo та Merlin Chain, і будь-яке зняття коштів має здійснюватися спільно MPC учасниками Cobo та Merlin Chain, по суті, забезпечуючи надійність виведення міст шляхом кредитного схвалення установи. Звичайно, це лише тимчасовий захід на даному етапі, і з поступовим удосконаленням проекту міст виведення коштів може бути замінено «оптимістичним міст» припущення про довіру 1/N шляхом введення BitVM і доказ шахрайства протокол, але приземлитися буде складніше (в даний час майже всі офіційні мости Layer2 покладаються на лонг знак).
В цілому можна розібратися, що Merlin представила ЦАП на базі POS, оптимістичний ZK-Rollup на базі BitVM і MPC рішення для зберігання активів на базі Cobo, вирішила проблему DA, відкривши дозволи ЦАП, забезпечила безпеку переходу стану, впровадивши BitVM і доказ шахрайства протокол, а також забезпечила надійність виведення міст, представивши MPC сервіс відомої платформи зберігання активів Cobo.
Схема двоетапної перевірки ZKP на основі Lumoz
Раніше ми прочісували модель безпеки Merlin і ввели концепцію оптимістичного ZK-rollup. У технологічній дорожній карті Merlin також обговорюється Децентралізація Prover. Як ми всі знаємо, Prover відіграє ключову роль в архітектурі ZK-Rollup, яка відповідає за генерацію ZKProofs для партій, випущених Sequencer, і процес генерації zk-SNARKs є дуже ресурсомістким апаратним ресурсом і дуже складною проблемою.
Для прискорення генерації доказів ЗК розпаралелювання задачі є однією з найпростіших операцій. ** Так зване розпаралелювання полягає в тому, щоб розділити задачу генерації доказів ZK на різні частини, які виконуються окремо різними проверами, і, нарешті, агрегатор агрегатора агрегує найдовший доказ в єдине ціле.
У ордер, щоб прискорити процес генерації доказів ZK, Merlin використовуватиме Prover від Lumoz як сервісне рішення, яке фактично полягає в тому, щоб зібрати велику кількість апаратних пристроїв разом, щоб сформувати майнінг-пул, а потім призначити обчислювальні завдання різним пристроям і призначити відповідні стимули, подібно до майнінгу POW.
У цій схемі Децентралізація Prover існує клас сценаріїв атаки, широко відомих як атаки з випередженням: припустимо, агрегатор-агрегатор сформував ZKP, і він відправляє ZKP в надії отримати винагороду. Після того, як контент ЗКП побачили інші агрегатори, вони кинулися викладати перед ним такий самий контент, стверджуючи, що цей ЗКП зробив їхній власний чоловік, як вирішити цю ситуацію?
Одне з найбільш інстинктивних рішень, яке може прийти в голову, - це присвоїти кожному агрегатору конкретний номер завдання, наприклад, тільки агрегатор А може взяти завдання 1, а всі інші не отримають винагороду, навіть якщо виконають завдання 1. Але одна з проблем цього підходу полягає в тому, що він не захищає від однієї точки ризику. Якщо агрегатор A зазнає збою продуктивності або розриває зв'язок, завдання 1 застрягне та не зможе його виконати. Більше того, така практика призначення завдань одному суб'єкту господарювання не є хорошим способом підвищення продуктивності за допомогою конкурентних стимулів.
Polygon zkEVM запропонував метод під назвою Proof of efficiency у своєму блозі, який стверджує, що різні агрегатори повинні бути просунуті, щоб конкурувати один з одним у конкурентній боротьбі, і що стимули повинні розподілятися в порядку живої черги, і що перші агрегатори, які подадуть ZK-Proof до мережі, можуть отримати винагороду. Звичайно, він не згадав, як вирішити проблему MEV фронту.
Lumoz використовує метод подання доказів ZK з двоетапною верифікацією, після того, як агрегатор генерує доказ ZK, йому не потрібно надсилати повний вміст, а лише публікує хеш ZKP, іншими словами, публікує хеш (ZKP+Aggregator Адреса). Таким чином, навіть якщо інші бачать значення хеш, вони не знають відповідного змісту ZKP і не можуть безпосередньо поспішати;
Якщо хтось просто скопіює весь хеш і опублікує його першим, це не має сенсу, тому що хеш містить Адреса конкретного агрегатора Х, і навіть якщо агрегатор А опублікує хеш першим, при виявленні вихідного образу хеш всі побачать, що агрегатор, Адреса міститься в ньому, - це Х, а не А.
За допомогою цієї схеми двоступеневої перевірки ZKP Merlin (Lumoz) може вирішити проблему попереднього процесу подання ZKP, а потім реалізувати висококонкурентні стимули для генерації zk-SNARKs, тим самим покращуючи швидкість генерації ZKP.
Merlin's Phantom: найдовша сумісність ланцюгів
Згідно з технічною дорожньою картою Merlin, вони також підтримка сумісність між Merlin та іншими EVM ланцюгами, і його шлях реалізації в основному такий самий, як і попередня ідея Zetachain, якщо Merlin використовується як вихідний ланцюг, а інші ланцюги EVM використовуються як цільовий ланцюг, коли Нода Merlin сприйме запит на крос-ланцюг сумісності, зроблений користувачем, це запустить подальший робочий процес над цільовим у блокчейні.
Наприклад, рахунок EOA, керований мережею Merlin, може бути розгорнутий на Polygon, ** Коли користувач публікує інструкцію з інтероперабельності крос-ланцюг на Merlin Chain, мережа Merlin спочатку аналізує його вміст і генерує дані транзакції, виконані на цільовому у блокчейні, а потім обробка підпису Oracle Network MPC транзакції генерує цифровий підпис транзакції. Потім Merlin's Relayer Нода випускає транзакцію** на Polygon, завершуючи подальші операції через активи Merlin в EOA рахунок на цільовому у блокчейні.
Коли операція, необхідна користувачеві, буде завершена, відповідний актив буде перенаправлений безпосередньо на адресу користувача в цільовому у блокчейні, а також теоретично може безпосередньо перейти в ланцюжок Merlin. Це рішення має деякі очевидні переваги: воно може уникнути зносу комісій, що генеруються традиційними контрактами на крос-ланцюг та кросчейн міст активів, і воно безпосередньо гарантується мережею Oracle Network Merlin для забезпечення безпеки крос-ланцюг операцій, і лонгуючий не потрібно покладатися на зовнішню інфраструктуру. Незважаючи на те, лонг користувачі довіряють Merlin Chain, немає проблем із тим, щоб за замовчуванням використовувати таку крос-ланцюг сумісність.
Підсумки
У цій статті ми даємо коротке пояснення загального технічного рішення Merlin Chain, яке, як вважається, допомагає більшій кількості лонг людей зрозуміти загальний робочий процес Merlin і мати більш чітке уявлення про його модель безпеки. З огляду на нинішнє Біткойн екології в самому розпалі, ми вважаємо, що така поведінка популяризації технічної науки є цінною і потрібною широкому загалу, ** У майбутньому ми проведемо лонг-річне спостереження за Merlin і bitLayer, B^Square та іншими проектами**, а також проведемо більш глибокий аналіз його технічних рішень, тому слідкуйте за новинами!