Користувачі Bitcoin повинні мати лише BTC на Bitcoin, щоб змусити вивести свій BTC з BOB назад на Bitcoin. Ми працюємо над гібридним рішенням: за замовчуванням Ethereum як DA, дозволяючи користувачам примусово включати транзакції на BOB за допомогою спеціальної транзакції на Bitcoin. Ми раді поділитися нашою роботою, що ведеться, у цьому дописі в блозі.

tl;dr

• L2 повинні мати таку ж опірність до цензури, як L1, на якій вони базуються
• На BOB користувачі вже можуть примусово виводити свої активи з BOB на Ethereum за допомогою транзакції Ethereum
• Для своего моста BitVM BOB работает над интеграцией Bitcoin в качестве способа обеспечения транзакций на BOB
• Користувачі Bitcoin зможуть зняти свої BTC з BOB, не надсилаючи транзакцію на BOB

Одна з основних властивостей L2 полягає в тому, що їх стан повинен рухатися навіть коли секвенсор відключеноL2s досягають цього шляхом зчитування та запису свого стану з рівня доступності даних (DA), який може бути оновлений незалежно від того, що L2 перебуває в мережі. Таким чином, користувачі можуть змусити включення своїх транзакцій навіть тоді, коли послідовник знаходиться в автономному режимі або послідовник не приймає їх транзакції безпосередньо.

Для мосту BitVM BOB це становить цікаву проблему. Зараз BOB використовує блоки Ethereum EIP-4844 як свій шар DA. Користувачі Ethereum можуть легко викликати зняття коштів назад на Bitcoin через міст BitVM. Однак для цього потрібно, щоб у користувачів були ETH на Ethereum.

Цього недостатньо для нас: користувачі Біткоїн повинні мати можливість виводити свій Біткоїн з BOB назад на Біткоїн, використовуючи лише BTC. Ми працюємо над гібридним рішенням: за замовчуванням переходячи на Ethereum як DA, дозволяючи користувачам виконувати транзакції на BOB через спеціальну транзакцію на Біткоїн. Ми раді поділитися нашою роботою, яка триває, у цьому дописі в блозі.

Основи DA та похідного

Процес походження є досить важливим для L2s: весь стан L2 BOB потрібно побудувати з L1 та шару DA. Це дозволяє L2 користуватися таким же опором цензурі, як і рівень DA, в нашому випадку Ethereum.

Спрощений, у роллапах (зокрема, у ланцюгах OP Stack) ми маємо два типи даних на L1:

• Транзакції депозитівздійснено до контракту "OptimismPortal". Це транзакції, які здійснюють користувачі на Ethereum, зазвичай для внесення своїх активів в BOB. Ці транзакції з внесення також можуть бути використані для виконання інших транзакцій на BOB.
• Групи, надіслані послідовником (або op-batcher, щоб бути точнішим), із L2 транзакцій. Сюди входять всі транзакції, здійснені безпосередньо користувачами на BOB і врешті-решт повертаються до блобів Ethereum.

Bitcoin як DA Layer

Якщо ми хочемо, щоб Bitcoin був у якості шару DA, чому б не перейти повністю до використання Bitcoin як DA шару? Відповідь, насамперед,вартість. Bitcoin має дуже обмежене сховище (приблизно 4 МБ приблизно кожні 10 хвилин), тому вартість зберігання висока.

Однак, у нашому випадку, BOB все ще може використовувати Ethereum як свій «головний» шар DA, де він публікує всі свої транзакційні дані, але додає Bitcoin як високоцензурний запасний шар, якщо Ethereum DA недоступний. По суті, Ethereum стає оптимістичним шаром DA, а Bitcoin стає дорогим, але стійким останнім варіантом.

Гібридний похідний конвеєр

Базовим рішенням є додавання Bitcoin до BOB як частини конвеєра деривативації, таким чином, щоб BOB (і, зокрема, "операційний вузол") обробляв вхідні дані в такому порядку:

1. Bitcoin forced withdrawal transactions (новостворені спеціально для BOB)
2. Депозити Ethereum до контракту OptimismPortal (стандарт OP Stack) BOB
3. Пакети Ethereum від op-batcher (стандарт OP Stack)

Давайте перейдем до можливого рішення для кодування транзакцій з примусовим виведенням Bitcoin в конвеєр похідних BOB. Зверніть увагу, що це все ще досліджується, тому можливі зміни.

Транзакції примусового виведення Bitcoin

Нам знадобиться три частини, щоб створити примусову транзакцію на виведення:

1. Побудуйте примусову транзакцію зняття коштів на Bitcoin.
2. Зберігайте транзакцію примусового зняття коштів у біткойнах у межах лімітів розміру біткойнів.
3. Обробляйте витрати на газ для примусової транзакції зняття коштів на Bitcoin.

1. Побудуйте транзакцію примусового вилучення

Стек OPтранзакція депозиту має таку структуру:

• bytes32 sourceHash: походження депозиту унікально ідентифікується джерело-хешем.
• адреса від: Адреса облікового запису відправника.
• адреса до: Адреса рахунку отримувача або нульова (нульова довжина) адреса, якщо внесена транзакція є створенням контракту.
• uint256 mint: Значення ETH для виготовлення на L2.
• uint256 значення: ETH-значення для відправки на рахунок одержувача.
• uint64 газу: Обмеження газу для L2-транзакції.
• bool isSystemTx: Якщо true, транзакція не взаємодіє з пулом газу блоку L2.
• байтів даних: calldata.

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

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

2. Збережіть транзакцію примусового вилучення на Bitcoin

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

Хоча легко визначити транзакцію депозиту (яка може включати зняття коштів) на Ethereum, оскільки вона надсилається до контракту OptimismPortal BOB, визначити транзакцію примусового зняття на Bitcoin не так легко.

Серіалізація даних: Примусова транзакція зняття коштів серіалізується за допомогою скриптів Taproot у структурі «конверта». Це noops в мережі Bitcoin і використовуються, наприклад, для порядкових чисел. Ми адаптуємо структуру під наші потреби.

Не встановлено
OP_FALSE OP_IF
OP_PUSH "bob"
OP_1
OP_PUSH "транзакція"
OP_0
OP_PUSH $WITHDRAWAL_TRANSACTION_DATA
OP_ENDIF
Двофазна схема фіксації/розкриття:
Як і з порядковими числами, користувачам доведеться надіслати дві транзакції на біткоїн:

• Здійсніть транзакцію: створює вихідний вихід Taproot, зобов'язуючись до сценарію, що містить вміст напису. Ця транзакція ще не розкриває дані, і нам знадобиться друга транзакція для повних вузлів BOB та послідовників, щоб включити транзакцію зняття коштів.
• Розкриття транзакції: Витрачає вихід від транзакції коміту, розкриваючи напис, який знаходиться на ланцюжку, тобто розкриваючи транзакцію зняття коштів користувача для включення в BOB.

3. Обробка витрат на газ для транзакції примусового зняття

Це найбільш відкрита проблема наразі, що перебуває під розглядом двох варіантів.

• Встановіть газ на 0 для примусової операції зняття коштів з Bitcoin та зніміть витрати на газ з балансу ETH користувача на BOB. Таким чином, можуть примусово виводити кошти лише користувачі, у яких є ETH на BOB. Однак це не є хорошим варіантом, оскільки це вимагатиме від користувачів мати ETH на BOB для примусового зняття, тобто користувачі, у яких є BTC на Bitcoin, не зможуть примусово знімати кошти.
• Газ оплачується користувачами у BTC на Bitcoin. Мережі BOB потрібно мати адресу на Bitcoin, яка може отримувати BTC та ефективно обмінювати отримані користувачем BTC на ETH на BOB, щоб оплатити частину витрат на газ L1 плюс витрати на виконання. Ця опція ймовірна за допомогоюBOB gateта встановлення адреси EVM BOB DAO як отримувача BTC.

Ми також експериментуємо з більшою кількістю ідей, тому слідкуйте за оновленнями!

Об'єднавши все разом

Будь-хто може визначити стан BOB, перевіривши дані про Bitcoin та Ethereum:

1. Прочитайте всі зняття транзакцій з біткойна. Вони кодуються як дві транзакції для кожного зняття, тобто одна транзакція commit і одна транзакція reveal. Це додаток, який ми робимо до OP Stack і де ми покращуємо процес похідної.
2. Прочитайте всі транзакції, здійснені за контрактом BOB OptimismPortal на Ethereum. Це вже частина стандартного конвеєра виведення OP Stack.
3. Читайте всі транзакції, здійснені безпосередньо на BOB та інтегровані як частина пакетів на Ethereum. Важливо, що повні ноди не зчитують безпосередньо з секвенсора, щоб отримати підтверджені транзакції, але вони зчитують з хмар Ethereum. Це вже частина стандартного конвеєра виведення OP Stack.

Технічні виклики

Збереження даних: Хоча забезпечення збереження даних між ланцюжками Ethereum та Bitcoin є важливим, просте наявність даних про транзакції на обох ланцюжках не гарантує їхньої валідності. Транзакції повинні представляти дійсні переходи стану відповідно до функції переходу стану rollup, щоб бути вважаними законними. Рішення передбачає впровадження логіки перевірки всередині op-вузла (або інших реалізацій рівня консенсусу), яка спочатку перевіряє, чи транзакція призводить до дійсної зміни стану перед тим, як приймати її.

Докази про шахрайство та валідність: Система доказів шахрайства для BitVM та Ethereum потребує поліпшення для обробки даних з обох ланцюгів, що може зробити вирішення суперечок складнішим. Щоб вирішити це, нам потрібно точно враховувати можливі транзакції з Bitcoin та Ethereum як частину моста BitVM та розрахунків BOB на Ethereum.

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

Наступні кроки

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

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

1. Цю статтю перепринтували з [BOB]. Усі авторські права належать оригінальному автору [Dominik Harz]. Якщо є зауваження до цього перепринту, будь ласка, зв'яжіться з Гейт Лернкоманда, і вони оперативно займуться цим.
2. Відмова відповідальності: погляди та думки, висловлені в цій статті, є виключно особистими поглядами автора і не є інвестиційними порадами.
3. Команда Learn від Gate переклала статтю на інші мови. Копіювання, поширення або плагіат перекладених статей заборонені, якщо не зазначено інше.