Pengenalan

Pada akhir 2020, Ethereum merangkul sebuah pendekatan rollup-centricuntuk memberikan transaksi cepat dan murah. Namun, hal ini datang dengan biaya peningkatan fragmentasi, karena pengguna dan likuiditas tersebar di berbagai rollups. Fragmentasi ini merupakan tantangan bagi seluruh ekosistem yang mencegah pengalaman Ethereum yang terpadu.

Dalam artikel ini, kami akan memeriksa akar dari fragmentasi ini, memeriksa salah satu tantangan inti dari interop rollup, ekuivokasi, dan mengategorikan solusi yang ada untuk menangani masalah ini. Dengan menggambarkan berbagai solusi yang diusulkan mengenai interoperabilitas rollup dan menyoroti kompromi yang terlibat, kami berharap dapat memberikan gambaran tentang masa depan interoperabilitas rollup dan bagaimana membangun masa depan rollup yang lebih terhubung.

Masalah fragmentasi

Fragmentasi negara di berbagai rollups yang berbeda mengarah pada pengalaman pengguna yang buruk, efisiensi modal yang berkurang, dan kurangnya komposabilitas asli:

Pengalaman Pengguna: Fragmentasi memaksa pengguna untuk sering beralih jaringan, mengelola banyak salinan token yang sama, dan jongkok di berbagai dompet. Hal ini menambah gesekan dan kompleksitas, membuat lebih sulit bagi pengguna untuk menikmati pengalaman Ethereum yang mulus dan "langsung bekerja". Sebagai contoh, misalkan Alice memiliki dana di rollup A tetapi ingin membeli token yang hanya tersedia di Rollup B. Alih-alih hanya mengklik "Beli," dia harus terlebih dahulu beralih jaringan, mentransfer dana dari A ke B, menunggu konfirmasi L1, dan kemudian melakukan perdagangan.

Likuiditas: Dengan likuiditas tersebar di banyak rollup, pasangan perdagangan kurang dalam dan efisien. Hal ini menyebabkan harga yang lebih buruk, hasil yang berkurang untuk protokol peminjaman, dan eksekusi perdagangan yang suboptimal.

Komposabilitas: Pada satu rantai, sebuah protokol peminjaman dapat segera likuidasi posisi dengan memanggil kontrak DEX dalam transaksi yang sama—semuanya terjadi dalam satu transaksi atom, synchronousLangkah. Dalam dunia yang terfragmentasi dan multi-rollup, proses tersebut menjadi asinkron. Protokol mungkin memicu likuidasi di satu rollup, kemudian menunggu pesan untuk diselesaikan di DEX rollup lainnya. Jika ada yang salah, membalik proses tersebut tidaklah mudah. Tidak ada juga alat yang disediakan secara native oleh Ethereum untuk melakukan panggilan kontrak lintas-rollup atau menjamin eksekusi cepat dari panggilan-panggilan ini. Kehilangan interaksi langsung, atomik merusak komposabilitas yang membuat ekosistem Ethereum begitu kuat.

Interoperabilitas

Pada intinya, interoperabilitas berarti memungkinkan transaksi yang dimulai di satu rollup dan memperbarui status di rollup lainnya — seperti mengirim token dari Rollup A ke Rollup B. Idealnya, tindakan ini semudah mengurangi saldo Anda di A dan menambah saldo Anda di B, semuanya sekaligus. Namun, dalam praktiknya, mencapai perilaku “semua-atau-tidak sama sekali” yang mulus menantang antara rollup yang berbeda.

Ideally, interaksi lintas rollups akan berfungsi persis seperti yang dilakukan di Ethereum L1—secara sinkron. Dalam pengaturan synchronous, panggilan berulang ke kontrak-kontrak berbeda di rollups yang berbeda dapat digabungkan ke dalam satu transaksi yang entah berhasil sepenuhnya atau gagal sepenuhnya, memberikan hasil yang segera dan atomik.

Sebaliknya, komposabilitas asinkron melibatkan beberapa langkah yang tersebar sepanjang waktu di berbagai rollups yang berbeda. Alih-alih transaksi atom tunggal, tindakan mungkin memicu suatu peristiwa di satu rollup dan kemudian menunggu konfirmasi sebelum menyelesaikan interaksi di rollup lainnya. Komposabilitas asinkron perlu menangani pembatalan: hanya salah satu rollup yang mungkin melakukan tindakan tepat waktu, dan kemudian mungkin perlu mengembalikan transisi status parsial ini (karena rollup mitra tidak melakukannya). Komposabilitas sinkron dan asinkron memiliki banyak tantangan umum yang kita bahas di sini.

Artikel ini berfokus pada solusi interoperabilitas rollup asli yang memerlukan integrasi tingkat protokol. Kami mengecualikan solusi jembatan eksternal yang bergantung pada penyedia likuiditas dan hanya mendukung transfer token yang dapat dipertukarkan.

Tantangan interoperabilitas

Mencapai interoperabilitas yang sejati antara rollups bukan hanya tentang mengirim pesan bolak-balik; itu tentang memastikan transaksi diselesaikan dengan aman dan cepat. Bergantung hanya pada Ethereum L1 dapat berarti penundaan yang lama dan biaya tinggi. Alice memiliki dana di rollup A tetapi ingin membeli token yang hanya tersedia di Rollup B. Dua pilihan mungkin terjadi:

• Rollup B hanya menerima dana Alice jika dibridging melalui Ethereum. Dalam kasus ini, Alice perlu menarik dana ke L1, kemudian mendepositokannya ke rollup B, dan akhirnya membeli token di rollup B, menimbulkan keterlambatan dan biaya yang tinggi.
• Rollup B menyediakan jalur yang lebih cepat dan lebih murah dengan memproses transfer secara langsung daripada menyelesaikan di Ethereum Layer 1 terlebih dahulu. Namun, seperti yang kami jelaskan di bawah ini, hal ini membuat Rollup B rentan terhadap risiko reorg potensial jika Rollup A bersikap tidak konsisten, tidak menyelesaikan, atau mengirimkan transisi state yang tidak valid.

Ketika dua L2 berinteraksi pada latensi lebih cepat dari Ethereum (yaitu, sebelum mereka bahkan melakukan komit atau menyelesaikan transisi status ke L1), ada tiga isu mendasar yang rollups perlu tangani: ekivokasi, ketidakvalidan, dan ketidakpenyelesaian.

• Keraguan: Rollup menyiarkan status yang bertentangan ke rantai yang berbeda, secara efektif menjanjikan aset yang sama beberapa kali.
• Invaliditas: Sebuah transisi keadaan mungkin tidak pernah dapat dibuktikan benar di L1.
• Non-penyelesaian: Proses pembuatan bukti atau penyelesaian mungkin akan terhenti secara tak terbatas.

Mari kita reiterasi di sini bahwa semua masalah ini dapat mudah diselesaikan dengan menunggu finalisasi L1 - ketika transisi status sepenuhnya diselesaikan di Ethereum. Namun, kami tertarik untuk memungkinkan interaksi cross-rollup yang aman dengan latensi lebih cepat dari Ethereum. Kami mengeksplorasi solusi yang menjaga keamanan saat beroperasi di jendela sub-finalitas ini.

Mari kita mengilustrasikan tantangan-tantangan ini dengan contoh: misalkan Alice memiliki 10 ETH di mainnet Scroll dan ingin mentransfernya ke Bob di Arbitrum. Idealnya, Alice dapat memindahkan likuiditas antara kedua rantai tersebut secara alami dengan latensi lebih cepat dari Ethereum. Misalkan solusi tersebut ada, di mana Arbitrum mengkrediti Alice dengan 10 ETH di Arbitrum sebelum Scroll mengirimkan apa pun ke L1, apa yang bisa salah untuk Arbitrum?

• Equivocation: Scroll berbelit-belit dengan melakukan transisi keadaan yang berbeda di L1 di mana transaksi Alice tidak disertakan, efektif mencuri 10 ETH dari Arbitrum (yang perlu direorganisasi untuk dapat diselesaikan).
• Invaliditas: Scroll tidak ekuivokasi, tetapi transisi negara yang berisi transaksi tersebut tidak valid, dan oleh karena itu Scroll tidak pernah dapat menyelesaikannya (yaitu membuktikannya) di L1 dan memberikan dana ke Arbitrum. Sekali lagi, Arbitrum perlu melakukan reorganisasi untuk dapat menyelesaikan.
• Non-penyelesaian: Scroll tidak berkelit dan transisi keadaan valid, tetapi penyedia yang ditunjuk oleh Scroll menjadi offline dan karena itu penyelesaian tidak pernah terjadi. Arbitrum perlu melakukan reorganisasi lagi.

Dengan Arbitrum mengintegrasikan 10 ETH yang dikirim dari Alice di Scroll sebelum Scroll mengkonfirmasi di L1 (dalam kasus ekuivokasi) dan sebelum Scroll diselesaikan (dalam kasus ketidakvalidan dan tidak penyelesaian), Arbitrum mengambil risiko dalam rantai yang bergantung pada pertimbangan keamanan Scroll.

Aspek penting dari interoperabilitas rollup adalah bagaimana sistem menangani kesalahan. Arsitektur yang berbeda mengambil pendekatan yang berbeda. Dalam beberapa sistem seperti OP Superchain, rollups dirancang untuk reorganisasi bersama - jika satu rollup bersalah, semua rollup terhubung harus merombak status mereka untuk mempertahankan konsistensi di seluruh sistem, sebuah properti yang disebut blok kontingen lintas rantai. Arsitektur lain fokus pada mencegah kesalahan sama sekali melalui berbagai mekanisme yang akan kita telusuri di bawah ini.

Baik non-settlement dan ketidakabsahan akan diselesaikan secara sepele setelah pembuatan bukti zk secara real-time menjadi praktis (alias pembuktian real-time). Namun masalah ketidakjelasan pada dasarnya berbeda. Bukti zk dapat membuktikan bahwa Alice mengirim 10 ETH ke Bob di Arbitrum, tetapi tidak menjamin bahwa Scroll akan melakukan transisi ini pada L1. Bukti Zk saja tidak dapat menyelesaikan dan tidak akan pernah menyelesaikan keraguan. Kemudian lagi, menunggu penyelesaian L1 memecahkan ketidaksamaan tetapi dengan harga keunggulan kecepatan rollup. Oleh karena itu, kami fokus pada ketidakjelasan pra-penyelesaian, yaitu, jaminan pencegahan keraguan sebelum penyelesaian ke Ethereum. Seperti yang akan kita lihat, setiap pendekatan melibatkan trade-off yang berbeda, terutama dalam hal asumsi kepercayaan yang kita bahas di bawah ini.

Arsitektur Interoperabilitas

Kami menyajikan dua pendekatan berbeda yang telah dieksplorasi untuk interoperabilitas pada kecepatan yang lebih cepat dari Ethereum, yang kami sebut jaring dan pusat.

Singkatnya, model mesh adalah di mana rollup secara langsung saling berhubungan satu sama lain dalam kelompok di mana mereka semua saling percaya untuk tidak meragukan untuk mencapai finalitas pra-penyelesaian.

Model hub memperkenalkan lapisan bersama, yang rollups bergantung pada untuk menangani pencegahan ekuivokasi interaksi lintas-rantai dengan latensi lebih cepat dari Ethereum. Mari kita jelajahi apa arti perbedaan ini dalam praktek.

Mesh

Model jaringan bekerja persis seperti yang mungkin Anda harapkan, dengan rollups berkomunikasi satu sama lain secara langsung sambil tetap bertanggung jawab atas penyelesaian ke Ethereum L1 sendiri:

Saat rollups semakin terhubung dalam jaringan besar ini, transitivitas kepercayaan dan ketergantungan menjadi masalah untuk skalabilitas. Jika Arbitrum mempercayai Scroll tetapi tidak mempercayai zkSync, maka Scroll tidak dapat mempercayai zkSync sambil tetap mempertahankan kepercayaan Arbitrum. Hanya "kelompok kepercayaan" yang terpisah, yaitu kelompok rollups, yang dapat berinteraksi satu sama lain dalam jaringan. Masalah ketergantungan ini diperparah ketika semakin banyak rollups terlibat dalam kasus interoperabilitas yang kompleks, di mana keamanan keseluruhan terbatas pada keamanan rollup terlemah.

Sementara sistem mesh mengandalkan kepercayaan untuk keamanan pra-penyelesaian, mereka dapat mendeteksi ketidaksamaan saat penyelesaian, memicu reorg di semua rollup yang terhubung.

Oleh karena itu, meskipun model interop ini memiliki beberapa kekurangan, itu benar-benar cocok untuk kasus di mana operasi lintas-rantai yang diinginkan terbatas pada rollups utama yang terbukti aman dan/atau tepercaya, dan yang bersedia menciptakan ketergantungan kepercayaan ini dalam sistem mereka. Namun, dengan cepat menjadi jelas bahwa model ini tidak dapat berkembang dengan baik jika kita ingin menambahkan lebih banyak rollups, L2 lainnya, dan bahkan appchain L3 dalam mesh.

Pusat

Dalam model hub, kekurangan dari model mesh diatasi dengan memperkenalkan lapisan bersama. Setiap rollup perlu mempercayai lapisan ini, yang bertindak sebagai sumber kebenaran untuk interaksi, sehingga mengaitkan satu rollup lagi ke lapisan tersebut jauh lebih mudah. Secara alami, kita perlu agar lapisan ini seaman mungkin untuk menawarkan jaminan non-equivocation terbaik pada latensi yang lebih cepat dari Ethereum.

Keuntungan dari solusi ini adalah bahwa menambahkan rollup ekstra dalam campuran tidak menciptakan lebih banyak masalah dependensi, karena lapisan interop bertindak sebagai "perisai" di antara setiap rollup. Ini dapat mencakup rantai L2 yang sewenang-wenang, serta L3 dan rollup aplikasi - yang harus mereka lakukan adalah diintegrasikan ke dalam hub dan menikmati manfaatnya.

Trade-off utama dari pendekatan ini adalah bahwa semua rollups memiliki dependensi bersama yang sama di pusat, yang mendapatkan kekuatan signifikan.

Secara khusus, untuk mencegah persamaan sebelum penyelesaian, kita harus memastikan bahwa pusat tidak akan berkolusi dengan rollup yang bersifat persamaan. Sistem pusat dengan demikian menggantikan kepercayaan timbal balik antara rollups dalam desain jaringan, dengan kepercayaan pada lapisan bersama tunggal yang tidak boleh berkolusi dengan rollups lain untuk bersikap persamaan.

Maka tidak mengherankan bahwa pusat harus dibangun dengan keamanan dan desentralisasi dalam pikiran. Ada beberapa pilihan yang berbeda untuk membangun pusat seperti itu:

• Menggunakan rollup yang sudah ada: Pilihan ini memiliki keuntungan karena merupakan yang paling sederhana, karena rollup tersebut sudah ada dan kemungkinan telah diuji dalam pertempuran, dan hanya perlu mendeploy kontrak pintar di atasnya.
• Membuat komponen khusus: Alih-alih meminta rollups mengandalkan semua properti keamanan dari rollup yang sudah ada, kita malah membuat komponen khusus baru untuk bertindak sebagai pusat. Keuntungannya di sini adalah komponen baru ini akan memiliki vektor permukaan bug/eksploitasi yang diminimalkan dengan disesuaikan secara khusus untuk kebutuhan lintas-rantai (dan bahkan bisa diverifikasi secara formal!).
• Menggunakan Ethereum L1 itu sendiri: Pilihan ini melibatkan menggunakanberdasarkan pra-konfirmasilangsung di Layer 1 untuk mendapatkan yang terbaik dari kedua dunia: gunakan lapisan yang terdesentralisasi secara maksimal untuk ketersediaan dan keamanan puncak sambil memiliki konfirmasi instan, waktu penarikan yang diminimalkan, dll.

Dengan asumsi bukti zk digunakan, ketiga opsi ini dapat memanfaatkan konsep agregasi bukti untuk lebih mengurangi biaya yang terlibat, dengan L1 memverifikasi satu bukti yang menggabungkan banyak bukti individu dari semua rollups yang didukung oleh pusat.

Sistem yang ada

Beberapa proyek telah mengusulkan berbagai solusi interop, yang dapat dikategorikan sebagai berikut.

Sistem jala. OP Superchaindan Arbitrum'sRantai-klaster adalah sistem mesh, di mana rantai harus menetap silang bersama - jika satu rantai samar, semua rantai yang terhubung harus diatur ulang. Rantai harus saling percaya untuk konfirmasi pra-penyelesaian.

Solusi-solusi ini mungkin bertransisi menuju menggunakan semacam pusat karena kelompok-kelompok kepercayaan tidak dapat diperluas melampaui beberapa rollups besar untuk mencapai finalitas pra-penyelesaian yang telah ditetapkan.

Sistem hub.Espressodan zkSync'sRantai Elastissistem-sistem gerbang. Di Scroll, kami telah menjelajahi desain gerbang yang dapat memungkinkan solusi interoperabilitas yang lebih dapat diskalakan dan dapat dipercaya. Kami presentasipada Workshop CryptoEconomics Columbia 2024 memberikan gambaran tentang desain, dengan lebih banyak detail yang akan diikuti dalam pos mendatang.

Sistem lain. Berbasis rollups memiliki potensi untuk memungkinkan komposabilitas simultan tidak hanya satu sama lain, tetapi bahkan dengan Ethereum L1, dan pada gilirannya dapat menggunakan Ethereum L1 untuk mencegah ekuivokasi.

AggLayer Polygon adalah jenis sistem pusat lain yang menyediakan lapisan bersama dengan rollups yang berkomunikasi. Namun, berbeda dengan menghindari asumsi kepercayaan tambahan dalam lapisan bersama itu. Sebaliknya, mereka menunggu penyelesaian dan menggunakan bukti pesimisuntuk memberikan keamanan. Kebingungan thus dicegah hanya pada saat penyelesaian. Pra-konfirmasi dapat opsional digunakan untuk menawarkan jaminan penyelesaian lebih cepat. AggLayer baru-baru ini mengumumkan sebuah mitradengan Sistem Espresso, yang menyediakan mekanisme urutan bersama.

Kesimpulan

Mengembangkan mekanisme pencegahan ekuivokasi untuk interop yang lebih cepat dari Ethereum datang dengan berbagai jenis kompromi yang perlu dipertimbangkan dengan hati-hati demi keamanan, desentralisasi, dan netralitas yang dapat dipercaya. Meskipun pos ini difokuskan pada pencegahan ekuivokasi, ada beberapa tantangan interop kritis lainnya yang belum kita bahas secara mendalam di sini, seperti ketersediaan data, desain lapisan penyelesaian (misalnya, implementasi kontrak jembatan bersama dan rollup antara rollups yang berbeda), protokol pengiriman pesan, dan insentif ekonomi yang diperlukan untuk membuat sistem ini berfungsi. Tetapi seperti yang dikatakan Vitalikdalam cuitan terbaru, kita lebih dekat menyelesaikan masalah-masalah lintas-rantai ini daripada kebanyakan orang pikirkan. Dalam akhir permainan interop ini, kami percaya pengguna akan benar-benar merasa seperti mereka “menggunakan satu Ethereum”, daripada rollups individu seperti saat ini.

Penafian:

1. Artikel ini dicetak ulang dari [Penelitian Gulir]. Semua hak cipta milik penulis asli [Alejandro Ranchal-Pedrosa]. Jika ada keberatan terhadap pencetakan ulang ini, harap hubungi Gate Belajartim, dan mereka akan menanganinya dengan segera.
2. Penolakan Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan saran investasi apa pun.
3. Tim Gate Learn melakukan terjemahan artikel ke dalam bahasa lain. Menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang kecuali disebutkan.