Узагальнення: Мості ZK розгортають розумні контракти на ланцюжку A, щоб безпосередньо отримувати та перевіряти заголовки блоків та відповідні нульові докази з ланцюжка B, підтверджуючи валідність міжланцюжкових повідомлень. Це найбезпечніша схема моста.

• Оптимістичні/OP мости використовують докази шахрайства, щоб викликати недійсні міжланцюжкові повідомлення на ланцюжку. Наявність лише одного надійного викликача може забезпечити безпеку фондів пулу міжланцюжкового мосту.
• Через технічні обмеження головна мережа Біткойн не може безпосередньо впроваджувати ZK мости, але може досягти оптимістичних мостів через BitVM та докази шахрайства. Команди, такі як Bitlayer та Citrea, прийняли схему мосту BitVM, вводячи попередні підписи та включаючи концепції каналів, що дозволяють користувачам передбачити процес обробки після виконання депозиту, запобігаючи перехресному ланцюжковому мосту використовувати депозити користувачів.
• Міст BitVM фактично діє на моделі "передплата-відшкодування", при цьому конкретні вузли оператора надають кошти користувачам виводу. Оператори можуть періодично подавати заявки на відшкодування з публічної адреси депозиту. Якщо оператор подає фальшиву заявку на відшкодування, її можна оскаржити та зменшити будь-ким.
• Хоча теоретично безпечний, міст БітВМ має проблеми з живістю/зручністю використання і не відповідає конкретним потребам користувачів щодо незалежності від фондів та протидії відмиванню грошей (оскільки він в основному використовує модель фонду фондів). Bitlayer вирішує це за допомогою рішення моста OP-DLC. Це рішення, схоже на DLC.link, вводить докази шахрайства на основі каналів та DLC, щоб запобігти зловживанню оракулом.
• З урахуванням складнощів впровадження BitVM та доказів шахрайства, мости DLC будуть спочатку розгорнуті як тимчасова заміна. Поки ризики довіри до оракулів вирішуються, інтегруються більш надійні та досвідчені сторонні оракули, мости DLC можуть стати безпечнішою схемою підтвердження виведення, ніж мости з багато-підписовими у поточному етапі.

Вступ: Після безумства щодо напису минулого року екосистема Bitcoin увійшла в період стрімкого зростання. За півроку кількість проектів під прапором BTC Layer2 збільшилася майже до 100. Воно просто стало новим континентом, повним хаосу, де можливості та обмани існують поруч. Не перебільшуючи, можна сказати, що поточна екосистема Bitcoin вже є «багатонаціональним тигелем» Єтереуму, Космосу та Селестії, CKB та рідної екосистеми Bitcoin. Разом з відсутністю авторитетних голосів екосистема Bitcoin просто як у 19 столітті. Подібно до Сполучених Штатів, це стало новим світом, що привертає сили з усіх сфер життя. Це приносить процвітання та життєву силу всій наративі Web3, але також вносить великі ризики.

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

Недавно Монанаут, засновник браузера блокчейнів Mempool, публічно скритикував поточні проблеми екосистеми Біткоїна. Він різко вказав, що якщо Біткойн Рівень 2 просто використовує міст для виведення багато-підписових операцій, і не може дозволити користувачам виводити активи у будь-який момент у формі, яка не потребує довіри, такий проект не є справжнім Рівнем 2. Цікаво, Віталік раніше вказував, що Рівень 2 принаймні повинен бути більш безпечним з точки зору безпеки, ніж системи, які спираються виключно на багато-підписові операції.

Можна сказати, що Монанаут та Віталік відверто вказали на технічні проблеми Bitcoin Layer 2: Багато L2 мостів для зняття фінансів суттєво є мостами з багатьма підписами. Або кілька відомих установ кожна має ключ, або використовується децентралізований підпис на основі POS, але в будь-якому випадку його безпекова модель базується на припущенні про чесність більшості, тобто вона за замовчуванням передбачає, що більшість учасників багатопідписників не змовляться, щоб робити зло.

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

Але це ще не все в екосистемі Біткойн. Деякі керівники проектів висловили свої думки щодо ідей оптимізації мосту виведення. У тексті ми коротко проаналізуємо міст Бітлейр і БітВМ-міст Citrea, а також представимо міст OP-DLC, запропонований Бітлейром, для вирішення недоліків мосту БітВМ, щоб більше людей могли зрозуміти ризики та ідеї конструкції міжланцюжкових мостів. Це критично для більшості учасників екосистеми Біткойн.

Оптимістичний міст: схема перевірки мосту на основі доказів про шахрайство

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

Традиційні міжланцюгові мости, як правило, використовують свідка багатопідпису. Вони призначать кількох свідків під ланцюгом. Свідки будуть запускати вузли кожного громадського ланцюжка та відслідковувати, чи хтось вніс кошти на адресу оплати мосту міжланцюгового.

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

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

Наприклад, ZK-міст, який охоплює ETH та Polygon, розгорне контракт перевірки на Polygon, наразі назвемо його Верифікатором. Вузол Relayer ZK-моста буде пересилати останній заголовок блоку Ethereum та доказ ZK, який підтверджує його валідність Верифікатору, який його перевірить. Це еквівалентно тому, що контракт Верифікатора синхронізується на ланцюгу Polygon та перевіряє останній заголовок блоку Ethereum. Merkle root, записаний у заголовку блоку, пов'язаний з набором транзакцій, які містяться у блоку, і може бути використаний для перевірки того, чи включена певна транзакція в блок.

Якщо блок Ethereum з висотою блоку 101 містить 10 заяв про міжланцюжковий переказ з ETH на Polygon, Релеєр згенерує доказ Меркля, пов'язаний з цими 10 транзакціями, та надішле доказ до контракту Верифікатора на ланцюжку Polygon:

Блок Ethereum No101 містить 10 кроссчейн-транзакцій від ETH до Polygon. Звичайно, міст ZK може конвертувати Merkle Proof в ZK і безпосередньо подавати ZK Proof в контракт Verifier. Під час усього цього процесу користувачам потрібно лише вірити в те, що смарт-контракт кросчейн-мосту не має лазівок, а сама технологія доказу з нульовим розголошенням є безпечною та надійною. Немає необхідності вводити занадто багато припущень про довіру, як традиційні мости з мультипідписом.

і "Оптимістичний міст" трохи відрізняється. Деякі оптимістичні мости зберігають налаштування, схожі на свідків, але вводять докази шахрайства та вікна викликів., після того як свідок генерує багатопідпис для міжланцюжкового повідомлення, хоча воно буде подано на цільовий ланцюжок, його валідність не буде визнана одразу. Йому потрібно пройти віконний період, і ніхто не питає про це, перш ніж його можна буде визнати як дійсний. Це фактично дещо схоже на ідею Оптимістичного Роллапу. Звичайно, у "Оптимістичного мосту" є інші моделі продуктів, але в кінцевому підсумку безпеку гарантує протокол доказів шахрайства.

Припущення про довіру моста з мультипідписом M/N дорівнює N-(M-1)/N. Ви повинні припустити, що кількість зловмисників у мережі становить не більше М-1, а кількість чесних осіб не менше N-(М-1). Припущення про довіру мосту ZK є незначним, тоді як припущення про довіру оптимістичного мосту, засноване на доказах шахрайства, становить 1/N, лише один із N свідків повинен бути чесним і готовим оскаржити недійсні кросчейн-повідомлення, надіслані до цільового ланцюга, щоб забезпечити безпеку мосту.

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

в попередніх статтях«Мінімалістична інтерпретація BitVM: Як перевірити докази шахрайства на ланцюжку BTC», ми коротко введемо, сутність доказу шахрайства BitVM полягає в тому, щоб розбити складні обчислювальні завдання, які виконуються поза ланцюгом, на велику кількість простих кроків, а потім вибрати певний крок для безпосередньої перевірки на ланцюгу Bitcoin. Ця ідея схожа на оптимістичні роллапи Ethereum, такі як Arbitrum та Optimism.

(Документація BitVM2 зазначає, що обчислювальне завдання буде розбито на велику кількість проміжних кроків за допомогою підписів Лампорта, після чого будь-хто може викликати проміжний крок)

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

Ми коротко представимо BitLayer, Citrea, BOB і навіть офіційно розроблений BitVM власний міст BitVM з позиції дизайну продукту та механізму, і як Bitlayer полегшує гальмування мосту BitVM через міст OP-DLC., щоб показати вам, як розробити вищезгадане рішення зняття моста на ланцюгу Bitcoin.

(Схематична діаграма мостового рішення Bitlayer)

Короткий аналіз принципу моста BitVM між Bitlayer та Citrea

нижче ми використовуємо рішення моста BitVM, оголошене компанією Bitlayer, Citrea та Bob, як матеріал для пояснення загального процесу роботи моста BitVM.

У своїх офіційних документах та технічних блогах вищезгадана проектна сторона чітко пояснила ідеї дизайну продукту моста для зняття BitVM (наразі на теоретичному етапі). По-перше, коли користувач знімає гроші через міст BitVM, йому потрібно використовувати контракт моста на Рівні 2 для генерації заяви про зняття. У заяві про зняття вказані наступні ключові параметри:

Кількість відображених BTC, які потрібно знищити у L2 (наприклад, 1 BTC);

Комісія за обробку міжланцюгових операцій, яку збирається сплатити виводящий (припускається, що це 0,01 BTC);

Адреса виведення виводу в L1: L1_receipt;

Сума виведення вивідника (тобто 1 — 0.01 = 0.99BTC)

Після цього виписка про виведення, зазначена вище, буде включена в блок Layer2. Міст BitVM. Вузол Relayer буде синхронізувати блок Layer2, відслідковувати виписку про виведення, що міститься в ній, і пересилати її в вузол Оператора, який виплатить користувачеві, який зробив виведення.

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

При подачі заявки на відшкодування Оператору необхідно надати підтвердження авансового платежу в ланцюжку Bitcoin (тобто довести, що він перевів гроші на адресу, вказану користувачем виведення на L1, і повинен витягти конкретний запис переказу, що міститься в блоці Bitcoin) . У той же час Оператор також повинен видати заяву про вихід, згенеровану відкликачем в L2 (за допомогою Merkle Proof, доведено, що видана заява про вихід походить з блоку L2 і не сфабрикована на порожньому місці). після того, як оператор повинен довести наступне:

Кошти, передані Оператором тягачу від імені моста BitVM, дорівнюють сумі, запитаній тягачем у заяві;

Коли Оператор подає заявку на відшкодування, сума відшкодування не повинна перевищувати суму відображеного BTC, знищеного вивідником на 2 рівні;

Оператор дійсно обробив всі виписки про зняття коштів рівня 2-рівня 1 протягом певного періоду часу, і кожну виписку про зняття коштів можна зіставити з записом про зняття коштів на ланцюжку Біткойн;

Це в суті є покаранням для Оператора за неправдиву інформацію про передоплату або відмову обробляти заяву на виведення (що може вирішити проблему, пов'язану з цензурою, у мосту виведення). Оператору потрібно порівняти та підтвердити ключові поля сертифікату передоплати та заяви на виведення поза ланцюжком, щоб довести, що сума BTC, що зацікавлена в обох, є рівною.

Якщо оператор мосту виведення неправдиво повідомляє про авансовану суму, це означає, що оператор стверджує, що доказ оплати на L1 відповідає заяві про виведення, виданій вивідником L2, але насправді ситуації не відповідають одна одній.

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

Що потрібно підкреслити, це те, що Бітлейєр, Сітреа, БОБ, ZKBase тощо всі прийняли останній маршрут BitVM2, який є новою версією рішення BitVM. Це рішення зробить офлайн обчислювальні завдання ZKize, тобто згенерує ZK Proof для процесу офлайн обчислень, потім перевірить Proof, а потім перетворить процес перевірки ZKP у вигляд, зручний для BitVM, щоб полегшити подальші виклики.

У той же час, використовуючи Лампорта та попередній підпис, багатораундове інтерактивне виклик оригінального БітVM може бути оптимізоване до однораундового неінтерактивного виклику, що значно знижує складність виклику.

Процес виклику BitVM потребує використання чогось, що називається "зобов'язанням", тобто Зобов'язанням. Давайте пояснимо, що таке "зобов'язання". Загалом кажучи, хто-небудь, хто публікує "зобов'язання" на ланцюгу Bitcoin, стверджуватиме, що певні дані, збережені позаланцюгово / обчислювальні завдання, які відбуваються позаланцюгово, є точними, і відповідне заявлення, опубліковане на ланцюзі, є "зобов'язанням".

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

У рішенні моста BitVM2 та Citrea та BitLayer, якщо хтось вважає, що зобов'язання, видається Оператором Моста Виведення на ланцюжку, пов'язане з недійсним процесом перевірки ZKP, він або вона може ініціювати виклик, а авторитет виклику є Бездозвільним. (Процес взаємодії всередині є досить складним і тут не пояснюється)

Оскільки Оператор передає кошти для фонду BitVM для оплати виведення, а потім подає заявку на відшкодування з фонду, при поданні заявки Оператор повинен видати Зобов'язання, щоб довести, що гроші, які він переказує для виведення на L1, дорівнюють сумі виведення. Платник заявляє на L2, що бажає отримати гроші. Якщо Зобов'язання пройшло вікно доказу шахрайства і не було оспорено, Оператор може вивести суму відшкодування, яку він потребує.

Тут ми хочемо пояснити, як зберігається грошовий пул загального фонду моста BitVM, і це саме найважливіша частина моста міжланцюжкового зв'язку. Як ми всі знаємо, кошти, які міжланцюжковий міст може виплатити отримувачеві, походять від активів, внесених вкладниками або іншими LP, а гроші, передбачені Оператором, в кінцевому підсумку будуть зняті з грошового пулу загального фонду, тому це залежить виключно від коштів. В результаті переказу сума внесків вкладника, поглинута мостом BitVM, повинна дорівнювати сумі зняття вивідника. Тому дуже важливо знати, як зберігати кошти вкладу.

У більшості рішень з переходу на другий рівень Bitcoin громадські активи часто управляються через багатопідписність. Внески користувачів агрегуються на рахунок з багатопідписною угодою. Коли потрібно зробити виведення, цей рахунок з багатопідписною угодою відповідає за здійснення платежу. Очевидно, є великий ризик довіри в цьому рішенні.

Bitlayer і міст BitVM від Citrea використовує ідеї, подібні до Lightning Network і каналів. Перш ніж внести депозит, користувач спочатку зв'яжеться з BitVM Alliance і попросить останнього попередньо підписати підпис для досягнення наступних ефектів:

Після того як користувач переказує депозит на адресу поповнення, кошти будуть безпосередньо заблоковані на адресі Taproot і можуть бути зібрані лише оператором моста. Більше того, оператор може вимагати кошти з адреси Taproot вищезазначеного депозиту, подавши заявку на відшкодування після передачі коштів для зняття користувача. Після закінчення строку виклику оператор може зняти певну суму депозитів користувача.

У рішенні мосту BitVM існує Федерація BitVM (Федерація BitVM), утворена N учасниками, які розподіляють депозити користувачів. Однак ці N учасники не можуть зловживати депозитами користувачів приватно, оскільки користувачі вимагатимуть від Альянсу BitVM попереднього підпису перед переказом коштів на визначену адресу, щоб забезпечити те, що ці депозити можуть бути законно стягнуті тільки Оператором.

(Схема оптимістичного моста BitVM2)

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

Якщо вищевказане рішення може бути реалізоване, міст BitVM стане одним з найбезпечніших мостів для виведення Bitcoin: У цьому мості відсутні проблеми з безпекою, лише проблеми доступності / працездатності. Коли користувачі намагаються внести кошти на BitVM, їх можуть цензурувати або відмовити співпрацювати з альянсом BitVM, що призводить до неможливості успішного внесення коштів. Однак це не має нічого спільного з безпекою, а є питанням доступності / працездатності.

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

Для вирішення вищезазначеної проблеми з активністю моста BitVM та забезпечення незалежного та чистого каналу входу та виходу коштів для людей з конкретними потребами, команда BitLayer додала додаткове рішення моста між ланцюжками під назвою OP-DLC. Окрім оптимістичного моста BitVM2, використовується міст DLC, аналогічний DLC.link. Надає користувачам два входи та виходи, міст BitVM та міст OP-DLC, для зменшення залежності від моста BitVM навіть від Альянсу BitVM.

(Схема DLC)

DLC: Обережний Логічний Контракт

DLC (Discreet Log Contracts) називається дискретним контрактом реєстрації. Цю технологію запропонував Ініціатива цифрової валюти MIT. Цю технологію вперше використовували для реалізації легкого смарт-контракту на Bitcoin. Для цього не потрібно завантажувати вміст контракту на ланцюжок. Шляхом взаємодії поза ланцюжком та попереднього підписування реалізуються функції смарт-контракту, які захищають конфіденційність на ланцюжку Bitcoin. Нижче ми використовуємо випадок азартних ігор для пояснення принципу роботи DLC.

Припустимо, що Еліс та Боб хочуть зробити ставку на результат матчу між Реал Мадридом і Барселоною, який відбудеться через три дні, і кожен з них платить 1 btc. Якщо перемагає Реал Мадрид, Еліс може отримати 1,5 BTC, а Боб може отримати лише 0,5 BTC, що еквівалентно тому, що Еліс заробляє 0,5 BTC, а Боб втрачає 0,5 BTC; якщо перемагає Барселона, Еліс може отримати лише 0,5 BTC, а Боб може забрати 1,5 BTC. У випадку нічиєї обидва гравці отримають по 1 BTC назад.

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

Візьмемо за приклад попередні Алісу та Боба,по-перше, обидві сторони створюють транзакцію фонду поза мережею, яка може заблокувати 1 BTC один одного на 2/2 адреси мультипідпису., якщо ця транзакція фонду набуде чинності, 2 BTC в адресі мультипідпису повинні бути авторизовані обома сторонами, перш ніж їх можна буде витратити.

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

У першій фазі створення DLC ми можемо визначити, що обидві сторони заблокують свої 1 BTC на мультисигнатурну адресу у майбутньому.

На другому етапі обидві сторони продовжують виводити можливі майбутні події та результати: наприклад, коли оголошуються результати футбольного матчу, може бути кілька можливостей, таких як перемога Еліс і програш Боба, програш Еліс і перемога Боба, нічия тощо. Це призведе до різних результатів розподілу біткоїнів на зазначеній вище адресі мультипідпису 2/2.

Різні результати потрібно спричиняти різними торговельними інструкціями. Ці “Інструкції здійснення угод, які можуть бути завантажені на ланцюжок у майбутньому” називаються CET, тобто контрактна операція здійснення. Аліса та Боб повинні передбачити всі CET наперед і згенерувати набір даних операції, що містить всі CET.

Наприклад, на основі можливих результатів ставки між Еліс та Бобом, згаданих вище, Еліс створює наступні CETs:

CET1: Еліс може отримати 1,5 BTC з адреси багато підписів, а Боб може отримати 0,5 BTC;

CET2: Еліс може отримати 0,5 BTC з адреси багатопідпису, а Боб може отримати 1,5 BTC;

CET3: Обидві сторони можуть отримати по 1 BTC.

Давайте візьмемо CET1 як приклад (Аліса отримує 1,5 BTC, Боб отримує 0,5 BTC):

Змістом цієї транзакції є передача 1,5 BTC на адресу з багато-підписовими до адреси Taproot, яка викликана результатами виведення від Аліси та оракульної машини, та передача інших 0,5 BTC на адресу Боба. Відповідні події на цей час: Реал Мадрид перемагає, Аліса виграє 0,5 BTC, а Боб втрачає 0,5 BTC.

Звичайно, Щоб витратити ці 1,5 BTC, Алісі потрібно отримати підпис результату «Реал Мадрид перемагає», відправлений оракулом.. Іншими словами, лише тоді, коли оракул виведе повідомлення «Реал Мадрид перемагає», Алісі дозволено переказати 1,5 BTC. Щодо вмісту CET2 та CET3, ми можемо вивести їх таким же чином і не будемо зараз глибоко вдаватися в деталі.

Варто зауважити, що CET в основному є транзакцією, яку потрібно завантажити на ланцюг для набуття чинності. Що станеться, якщо Еліс випереджає CET1 заздалегідь, або в разі 'Перемоги Барселони' все ще розміщує CET1 на ланцюгу, який може бути успішно активований лише після 'Перемоги Реал Мадрида'?

На попередньому діаграмі ми зазначили, що після того, як CET1 буде доданий до ланцюжка, 2 BTC, заблоковані в початковій адресі з багато підписами, будуть перекладені, 0,5 BTC будуть перекладені Бобу, а 1,5 BTC будуть перекладені на адресу Taproot. Оракульна машина виводить «Тільки після перемоги Реалу» Аліса може розблокувати BTC, заблоковані в адресі Taproot. Результати, як показано нижче.

У той же час, ця адреса Taproot підлягає часовому замку. Якщо Аліса не зможе успішно вивести 1,5 BTC протягом часового періоду, вказаного часовим замком, Боб має право взяти гроші безпосередньо.

Таким чином, якщо оракул є чесним, Еліс не може забрати 1,5 BTC. Коли закінчиться термін блокування часу, Боб може забрати 1,5 BTC. Крім 0,5 BTC, які були передані безпосередньо Бобу, коли CET1 був завантажений на ланцюг, увесь гроші в кінцевому підсумку належатимуть Бобу.

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

Фактично, коли було сконструйовано вищезгаданий CET, підпис schnorr Taproot був покращений, що можна розуміти як використання відкритого ключа оракула + результатів подій для конструювання незалежних адрес для різних результатів. Після цього тільки тоді, коли машина оракула оголосить підпис, відповідний певному результату, можна витратити BTC, заблоковані на адресі, відповідній результату.

Звісно, тут є додаткова можливість. Що, якщо Еліс знає, що вона програла і просто не викладає СЕТ1, яку вона побудувала на ланцюжок? Це легко вирішити, оскільки Боб може побудувати спеціальний СЕТ для питання «Еліс програє, Боб перемагає». Ефект, досягнутий цим СЕТ, в основному такий самий, як СЕТ, побудований Еліс, але конкретні деталі відрізняються, але результат однаковий.

Те, що описано вище, - це найважливіший процес побудови CET. Третій крок DLC передбачає спілкування Аліси та Боба, перевірку побудованої іншою стороною транзакції CET та нанесення власного підпису на CET. Після правильної перевірки вони можуть довіряти одне одному та інвестувати по 1 BTC, блокуючи початкові 2/2 адреси багато підписів Аліси та Боба, а потім чекати, поки певний CET буде завантажений на ланцюг для тригерування подальшого процесу.

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

Хтось може запитати, як DLC відрізняється від звичайного багато-підпису 2/3? По-перше, якщо підписано більше 2/3, будь-які дві сторони можуть змовитися, щоб викрасти всі активи, а DLC дозволяє супротивникам обмежити всі сценарії, побудувавши набір CET заздалегідь. Навіть якщо оракул бере участь у змові, завдані збитки часто обмежені.

По-друге, для багато-підписової потрібно, щоб всі сторони підписали певні транзакції, які будуть завантажені на ланцюг, тоді як у налаштуванні DLC оракулу потрібно лише підписати результати певних подій. Йому не потрібно знати вміст CET/транзакцій, які будуть завантажені на ланцюг. Навіть не потрібно знати, що є дві особи, Еліс та Боб. Йому лише потрібно діяти як звичайний оракул. Просто взаємодіяти з користувачем нормально, як машиною.

Ми можемо вважати, що суть DLC полягає в тому, щоб перетворити довіру між учасниками багатопідписних угод в довіру до оракулів. Поки машина-оракул не бере участь у злочинних діях, можна забезпечити, що дизайн протоколу DLC достатньо надійний. Теоретично, DLC може використовувати досить зрілого та повного стороннього оракула, щоб уникнути злочинних дій. DLC.link та BitLayer використовують цю функцію DLC для передачі проблеми довіри мосту сторонньому оракулу.

Крім того, міст DLC Bitlayer також підтримує власні вузли оракулів, додаючи шар доказу шахрайства поверх цього. Коли власний вузол оракула ставить недійсний CET на ланцюг, будь-хто може викликати це. Щодо принципу його моста OP-DLC, ми коротко описуємо його нижче.

OP-DLC Міст: Канал DLC + Доказ шахрайства

Ми пояснюємо принцип роботи мосту OP-DLC від усього процесу депозиту та виведення. Припустимо, що Еліс зараз вносить 1 BTC до L2 через міст OP-DLC, згідно з двоетапним механізмом транзакцій, пан Аліса генерує передфондову транзакцію, як показано нижче:

Фактично спочатку перекажіть 1 BTC на адресу Taproot, спільно контрольовану Алісою та членами альянсу BitVM, а потім розпочніть серію процесів для створення CET. Якщо член альянсу моста BitVM відмовиться співпрацювати з запитом Аліси на депозит, Аліса зможе вивести гроші негайно після закінчення часового блокування.

Якщо учасники альянсу BitVM згодні співпрацювати з Алісою, обидві сторони можуть використовувати поза ланцюжкову комунікацію для спочатку генерування формальної транзакції депонування Фонду (ще не на ланцюжку), а також всі CET у сценарії виведення. Після завершення генерації та верифікації CET обидві сторони можуть подати транзакцію Фонду на ланцюжок.

У свідченні / даних підпису транзакції фонду, Аліса вказує свою платіжну адресу на Рівні 2; Після того, як транзакція фонду буде завантажена на ланцюг, Аліса може надіслати вищезазначені дані про транзакцію фонду до контракту мосту на Рівні 2, щоб довести, що вона завершила дію з депонування на ланцюзі Bitcoin і має право на те, щоб L2 містковий контракт випустив Токен на вказану платіжну адресу.

Після того, як спрацює операція Фонду, депозит фактично блокується на адресі мультипідпису Taproot, спільно контрольованій Алісою та членами альянсу BitVM. Однак слід зауважити, що мультипідпис може розблокувати BTC, заблоковані адресою, лише через CET, а альянс BitVM не може переказати гроші безпідставно.

Наступне, давайте проаналізуємо CET, побудовані заздалегідь Алісою та альянсом BitVM. Ці CET використовуються для вирішення потенційних сценаріїв майбутніх виведень. Наприклад, Аліса може бути здепонувала 1 BTC, але вона вивела лише 0,3 BTC під час свого першого виведення, а залишок 0,7 BTC був переданий до громадського фонду альянсу BitVM. Щоб контролювати, але якщо ви хочете зняти гроші, ви можете це зробити тільки через згаданий вище міст BitVM;

Або просто використовуйте цих 0.7 Біткойн для ініціювання нового попереднього депозиту. Як новий актив для моста DLC, ви можете повторити процес транзакції фонду та будівництва CET, згаданий вище.

Вищезазначений процес не є важким для розуміння. Насправді, вкладник Еліс та альянс bitVM виступають контрагентами один одному, створюють CET для подій виведення різних сум, а потім дозволяють оракулу прочитати заяву про виведення, ініційовану Еліс у Рівень 2, щоб визначити, яку транзакцію Еліс хоче спровокувати. Один CET (на яку суму ви хочете зняти гроші).

Ризик тут полягає в тому, що машина-оракул може вступити в змову з BitVM Alliance. Наприклад, Аліса заявляє, що хоче вивести 0,5 BTC, але машина-оракул підробляє заяву про виведення, що в кінцевому підсумку призводить до того, що «Аліса виводить 0,1 BTC, а BitVM Alliance отримує 0,9 BTC». Помилка CET на ланцюжку.

Є кілька рішень цієї проблеми. Перше - використовувати стороннього оракула з досить повним дизайном. Запобігати такій змові (для альянсу BitVM надзвичайно важко змовлятися з оракулами наразі), або дозволити оракулу виконувати стейкінг. Оракул повинен регулярно публікувати Зобов'язання на ланцюжку Bitcoin, заявляючи, що відкритий вирахування видачі витрати видачі чесно. Будь-хто може викликати Зобов'язання через протокол доказу шахрайства BitVM. Якщо виклик вдалий, злий оракул буде зменшений.

Під дизайном моста OP-DLC користувачі завжди можуть «брати участь» у власних активах, щоб запобігти їх несанкціонованому використанню Союзом BitVM. Крім того, такий дизайн каналу надає більшу автономію користувачам і не потребує змішування власних коштів з коштами інших осіб. Це більше схоже на рішення з P2P попереднього внесення та виведення коштів.

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

Узагальнити

Рішення моста BitLayer та BitVM від Citrea суттєво є моделлю "авансовий платіж-відшкодування", є окремий вузол Оператора для переказу коштів користувачам для зняття грошей, і Оператор може регулярно подавати заявку на відшкодування на публічну адресу депозиту. Якщо оператор подає недійсну заявку на відшкодування, її можна оскаржити та зменшити будь-ким.

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

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

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

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

Disclaimer：

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