Pengguna Bitcoin hanya perlu BTC di Bitcoin untuk memaksa penarikan BTC mereka dari BOB kembali ke Bitcoin. Kami sedang mengerjakan solusi hibrida: beralih ke Ethereum sebagai DA sambil memungkinkan pengguna untuk memasukkan transaksi pada BOB melalui transaksi khusus di Bitcoin. Kami sangat bersemangat untuk membagikan hasil kerja kami dalam posting blog ini.

tl;dr

• L2s harus memiliki ketahanan sensorship yang sama seperti L1s yang mereka dasarkan
• Di BOB, pengguna sudah dapat memaksa menarik aset mereka dari BOB ke Ethereum melalui transaksi Ethereum
• Untuk jembatan BitVM-nya, BOB sedang bekerja untuk mengintegrasikan Bitcoin sebagai cara bagi pengguna untuk menegakkan transaksi di BOB
• Pengguna Bitcoin akan dapat menarik BTC mereka dari BOB tanpa harus mengirim transaksi ke BOB

Salah satu sifat inti dari L2 adalah bahwa keadaannya harus berkembang bahkan ketika Sequencer sedang offline. L2 mencapai ini dengan membaca dan menulis status mereka dari lapisan Ketersediaan Data (DA) yang dapat diperbarui secara independen dari L2 yang sedang online. Dengan cara ini, pengguna dapat memaksa inklusi transaksi mereka bahkan ketika pemutus urutan tidak online, atau pemutus urutan tidak menerima transaksi mereka secara langsung.

Untuk jembatan BitVM BOB, ini menimbulkan masalah menarik. Saat ini, BOB menggunakan blob Ethereum EIP-4844 sebagai lapisan DA-nya. Pengguna di Ethereum dapat dengan mudah memicu penarikan kembali ke Bitcoin melalui jembatan BitVM. Namun, ini membutuhkan pengguna untuk memiliki ETH di Ethereum.

Ini tidak cukup bagus bagi kami: pengguna Bitcoin hanya perlu memiliki BTC di Bitcoin untuk memaksa penarikan BTC mereka dari BOB kembali ke Bitcoin. Kami sedang mengerjakan solusi hibrida: beralih ke Ethereum sebagai DA sambil memungkinkan pengguna memasukkan transaksi pada BOB melalui transaksi khusus di Bitcoin. Kami senang untuk berbagi perkembangan kami dalam posting blog ini.

Latar Belakang tentang DA dan Derivatif

Proses derivasisangat penting bagi L2s: seluruh keadaan L2 BOB harus dibangun dari L1 dan lapisan DA. Ini memungkinkan L2s menikmati ketahanan sensor yang sama seperti lapisan DA, dalam kasus kami, Ethereum.

DisederhanakanDi dalam rollups (khususnya rantai OP Stack), kita memiliki dua jenis data pada L1:

• Transaksi depositdibuat ke kontrak “OptimismPortal”. Ini adalah transaksi yang dilakukan oleh pengguna di Ethereum biasanya untuk mendepositkan aset mereka ke BOB. Transaksi deposit ini juga dapat digunakan untuk mengeksekusi transaksi lain di BOB.
• Batch yang diserahkan oleh pengurut (atau op-batcher untuk lebih tepatnya) dari transaksi L2. Ini termasuk semua transaksi yang dilakukan langsung oleh pengguna di BOB dan akhirnya disertakan kembali ke Ethereum blobs.

Bitcoin sebagai Lapisan DA

Jika kita ingin Bitcoin sebagai lapisan DA, mengapa tidak beralih sepenuhnya ke penggunaan Bitcoin secara keseluruhan sebagai lapisan DA? Jawabannya sebagian besar adalah biaya. Bitcoin memiliki sedikit ruang penyimpanan yang tersedia (sekitar 4MB setiap 10 menit), dan oleh karena itu, biaya penyimpanan tinggi.

Namun, dalam kasus kami, BOB masih dapat menggunakan Ethereum sebagai lapisan DA "utama" di mana ia memposting seluruh data transaksinya, tetapi menambahkan Bitcoin sebagai lapisan cadangan yang sangat tahan sensor jika Ethereum DA tidak tersedia. Pada dasarnya, Ethereum menjadi lapisan DA yang optimis sementara Bitcoin menjadi pilihan terakhir yang mahal tetapi toleran terhadap kesalahan.

Pipa Turunan Hibrid

Solusi dasar adalah menambahkan Bitcoin ke BOB sebagai bagian dari pipeline derivasi, sehingga BOB (dan khususnya “op-node”) memproses input dalam urutan ini:

1. Transaksi penarikan paksa Bitcoin (baru ditambahkan khusus untuk BOB)
2. Deposit Ethereum ke kontrak OptimismPortal BOB (standar OP Stack)
3. Batch Ethereum dari op-batcher (standar tumpukan OP)

Mari kita masuk ke solusi yang mungkin untuk mengkodekan transaksi penarikan terpaksa Bitcoin ke dalam pipa turunan BOB. Perhatikan bahwa ini masih dalam penelitian, jadi perubahan mungkin terjadi.

Transaksi Penarikan Paksa Bitcoin

Kami akan memerlukan tiga bagian untuk membuat transaksi penarikan paksa:

1. Membangun transaksi penarikan paksa di Bitcoin.
2. Simpan transaksi penarikan paksa di Bitcoin dalam batas ukuran Bitcoin.
3. Mengatasi biaya gas untuk transaksi penarikan paksa pada Bitcoin.

1. Membangun Transaksi Penarikan Paksa

Tumpukan OPtransaksi depositmemiliki struktur berikut:

• bytes32 sourceHash: sumber-hash, secara unik mengidentifikasi asal setoran.
• alamat dari: Alamat akun pengirim.
• alamat ke: Alamat akun penerima, atau alamat nol (panjang nol) jika transaksi yang disimpan adalah pembuatan kontrak.
• uint256 mint: Nilai ETH yang akan dicetak di L2.
• uint256 value: Nilai ETH yang akan dikirim ke akun penerima.
• uint64 gas: Batas gas untuk transaksi L2.
• bool isSystemTx: Jika benar, transaksi tidak berinteraksi dengan kolam gas blok L2.
• data byte: Panggilan data.

Transaksi penarikan paksa memerlukan inklusi transaksi penarikan yang telah dienkripsi dalam bidang data transaksi deposit. Hal ini dilakukan dengan menciptakan transaksi di BOB yang memicu penarikan dari BOB ke Bitcoin dan akan berfungsi dengan persis sama jika transaksi tersebut dikirim dari Ethereum.

Kemudian kita dapat menyimpan versi (terkompresi) transaksi penarikan paksa di Bitcoin yang mencakup semua data di atas.

2. Simpan Transaksi Penarikan Paksa pada Bitcoin

Karena data untuk transaksi penarikan paksa lebih besar dari biasanya yang seharusnya disimpan dalam output OP_RETURN, kemungkinan besar kami akan menggunakan Taprootoutput untuk menyimpan data.

Meskipun mudah untuk mengidentifikasi transaksi deposit (yang mungkin termasuk penarikan) di Ethereum karena dikirim ke kontrak OptimismPortal milik BOB, tidak mudah untuk mengidentifikasi transaksi penarikan paksa di Bitcoin.

Serialisasi Data: Transaksi penarikan paksa diserialisasi menggunakan skrip Taproot dalam struktur 'envelope'. Ini adalah noops di jaringan Bitcoin dan digunakan, misalnya, untuk Ordinals juga. Kami menyesuaikan struktur ini sesuai dengan kebutuhan kami.

Tidak diatur
OP_FALSE OP_IF
OP_PUSH "bob"
OP_1
OP_PUSH "transaksi"
OP_0
OP_PUSH $WITHDRAWAL_TRANSACTION_DATA
OP_ENDIF
Skema Komitmen/Reveal Dua Fase:
Seperti halnya Ordinal, pengguna harus mengirimkan dua transaksi ke Bitcoin:

• Commit Transaksi: Membuat keluaran Taproot yang berkomitmen pada skrip yang berisi konten inskripsi. Transaksi ini belum mengungkapkan data dan kita akan memerlukan transaksi kedua untuk node penuh BOB dan pengurut untuk menyertakan transaksi penarikan.
• Transaksi Ungkap: Menghabiskan output dari transaksi komitmen, mengungkapkan inskripsi di rantai, yaitu, mengungkapkan transaksi penarikan pengguna untuk disertakan dalam BOB.

3. Mengatasi Biaya Gas untuk Transaksi Penarikan Paksa

Ini adalah masalah yang paling terbuka hingga saat ini, dengan dua opsi yang saat ini sedang dipertimbangkan:

• Atur gas ke 0 untuk transaksi penarikan paksa di Bitcoin dan kurangi biaya gas dari saldo ETH pengguna di BOB. Dengan cara ini, hanya pengguna yang memiliki ETH di BOB yang dapat melakukan penarikan paksa. Namun, ini bukan pilihan yang baik karena akan membutuhkan pengguna untuk memiliki ETH di BOB untuk melakukan penarikan paksa, yaitu pengguna yang memiliki BTC di Bitcoin tidak dapat melakukan penarikan paksa.
• Gas dibayar oleh pengguna dalam BTC di Bitcoin. Jaringan BOB perlu memiliki alamat di Bitcoin yang dapat menerima BTC dan akan secara efektif menukar BTC yang diterima oleh pengguna menjadi ETH di BOB untuk membayar bagian L1 dari biaya gas ditambah biaya eksekusi. Opsi ini kemungkinan dilakukan dengan menggunakanBOB gatewaydan mengatur alamat EVM BOB DAO sebagai penerima BTC.

Kami juga sedang mencoba beberapa ide lain, jadi tetap terhubung untuk pembaruan lebih lanjut!

Menggabungkannya Semua

Siapa pun dapat menentukan status BOB hanya dengan memeriksa data di Bitcoin dan Ethereum:

1. Baca semua transaksi penarikan dari Bitcoin. Ini dienkripsi sebagai dua transaksi untuk setiap penarikan, yaitu satu transaksi komitmen dan satu transaksi pengungkapan. Ini adalah tambahan yang kami buat untuk OP Stack dan di mana kami meningkatkan pipa derivasi.
2. Baca semua transaksi yang dilakukan ke kontrak OptimismPortal milik BOB di Ethereum. Ini sudah menjadi bagian dari pipa derivasi OP Stack standar.
3. Baca semua transaksi yang dilakukan langsung di BOB dan terintegrasi sebagai bagian dari batch di Ethereum. Yang penting, node lengkap tidak membaca langsung dari pengurutan untuk menerima transaksi yang dikonfirmasi tetapi mereka membaca dari blob Ethereum. Ini sudah menjadi bagian dari pipeline derivasi OP Stack standar.

Tantangan Teknis

Konsistensi Data: Meskipun menjaga konsistensi data antara rantai Ethereum dan Bitcoin penting, keberadaan data transaksi di kedua rantai tersebut tidak menjamin keabsahan. Transaksi harus mewakili perubahan status yang valid sesuai dengan fungsi transisi status rollup untuk dianggap sah. Solusi ini memerlukan implementasi logika validasi di dalam op-node (atau implementasi lapis konsensus lainnya) yang pertama kali memverifikasi apakah transaksi menghasilkan perubahan status yang valid sebelum menerimanya.

Bukti Penipuan dan Validitas: Sistem bukti penipuan untuk BitVM dan Ethereum perlu diperkuat untuk menangani data dari kedua rantai, yang dapat membuat penyelesaian sengketa menjadi lebih kompleks. Untuk mengatasi hal ini, kita perlu menghitung dengan akurat transaksi yang mungkin terjadi dari Bitcoin dan Ethereum sebagai bagian dari jembatan BitVM dan penyelesaian BOB di Ethereum.

Penambahan Penyimpanan: Selain itu, node BOB dalam jaringan menghadapi peningkatan kebutuhan penyimpanan dan bandwidth karena perlu mengolah dan menyimpan data dari Bitcoin dan Ethereum. Namun, kita dapat menguranginya dengan meminta agar transaksi BOB yang dilakukan di Bitcoin harus dimasukkan ke dalam blob Ethereum dengan referensi ke blok Bitcoin terbaru. Dengan cara ini, node hanya perlu menyinkronkan blok Bitcoin terbaru.

Langkah Selanjutnya

Kami sangat bersemangat untuk mendorong batas-batas rollups hybrid yang menggabungkan keamanan Bitcoin dengan inovasi Ethereum. Dalam masalah konkret ini, kami tertarik untuk memiliki ketahanan sensorship transaksi Bitcoin yang digabungkan dengan tumpukan rollup BOB. Kami akan memperbarui pos blog ini dengan informasi lebih lanjut seiring dengan kemajuan yang kami buat.

Disclaimer:

1. Artikel ini dicetak ulang dari [BOB]. Semua hak cipta dimiliki oleh penulis asli [Dominik Harz]. Jika ada keberatan terhadap cetak ulang ini, silakan hubungi Gate Belajartim, dan mereka akan menanganinya dengan segera.
2. Penyangkalan Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata adalah milik penulis dan tidak merupakan saran investasi.
3. Tim Pembelajaran Gate menerjemahkan artikel tersebut ke dalam bahasa lain. Menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang kecuali disebutkan.