Penulis: Lisa A., Taiko Labs; Terjemahan: Golden Finance xiaozou
Artikel ini akan mengeksplorasi berbagai metode pesan lintas rantai L2 dari perspektif rollup, dengan fokus pada komunikasi lintas rantai yang tidak dapat dipercaya. Kita akan melihat sekilas pendekatan status baca langsung, pendekatan klien ringan, dan bukti penyimpanan. Kami juga akan membahas mekanisme agregasi bukti, transmisi pesan lintas rantai pihak ketiga yang tepercaya, dan solusi lintas rantai inti ZK. Terakhir, mari kita lihat bagaimana L2 yang berbeda mengimplementasikan pesan lintas rantai saat ini.
1. Pengantar pesan lintas rantai
Untuk komunikasi lintas rantai, semua pihak (L2, L3, dll.) harus memiliki akses langsung ke root status Ethereum terbaru.
Semua lapisan deposit memiliki mekanisme lintas rantai "bawaan" yang dapat digunakan untuk mengakses root status L1, yang akan diteruskan ke L2 sebagai pesan deposit.
1.1 Dua jenis akses akar negara
Tipe 1: Pembacaan langsung dari root status - dapat dilakukan melalui opcode atau dikompilasi sebelumnya. Namun hal itu belum dilaksanakan sehingga tidak perlu pembuktian.
· Brecht Devos menjelaskan metode yang mungkin untuk membaca keadaan secara langsung dalam sebuah artikel penelitian: “…kita dapat mengekspos kontrak yang telah dikompilasi sebelumnya yang dapat secara langsung memanggil kontrak pintar pada rantai target. Prakompilasi ini secara langsung Rantai sumber menyisipkan dan mengeksekusi kode kontrak pintar rantai lainnya. Hal ini memastikan bahwa kontrak pintar selalu memiliki akses ke status terbaru yang tersedia dengan cara yang efisien dan mudah dibuktikan.”
· Ada juga deskripsi terkait dalam RFP Optimisme "Bukti Konsep Panggilan Statis Jarak Jauh".
Tipe 2: Pembuatan bukti – yaitu membuktikan pernyataan tentang satu blockchain pada blockchain lain.
Ada dua metode "pesan lintas rantai dengan bukti":
· Komunikasi lintas rantai yang tidak dapat dipercaya—yaitu, tidak ada pihak ketiga yang tepercaya (misalnya, menggunakan klien ringan atau bukti penyimpanan). Pendekatan tanpa kepercayaan dapat digunakan baik bagi pihak ketiga untuk menghasilkan bukti maupun bagi peserta komunikasi lintas rantai untuk menghasilkan bukti sendiri.
· Bagikan bukti antara rollup yang berbeda untuk memastikan operasi lintas rantai. Metode ini tidak akan dibahas dalam artikel ini karena saat ini sedang dalam tahap penelitian dan eksplorasi dan belum dianggap sebagai solusi yang mungkin dapat digunakan secara luas.
1.2 Metode “Pesan lintas rantai disampaikan dengan bukti”.
1.2.1 Pesan lintas rantai klien yang ringan
Buktikan data pada rantai B
· Dapatkan data bukti Merkel dari simpul penuh rantai B (simpul arsip jika bukti penyimpanan keadaan sejarah tertentu diperlukan);
· Kirim header blok dan data bukti yang sesuai dengan blok rantai B yang berisi keadaan yang ingin kita verifikasi sebagai data panggilan ke kontrak pembuktian pada rantai A;
· Kontrak pembukti menghitung nilai hash blok berdasarkan data header blok, menanyakan kontrak pintar klien ringan pada rantai A (melacak nilai hash blok rantai B), dan memeriksa apakah nilai hash valid;
· Data bukti diverifikasi terhadap root status bytes32 di header blok.
1.2.2 Bukti Penyimpanan
Ada dua opsi "alur kerja" untuk bukti penyimpanan:
· Hasilkan bukti penyimpanan → gunakan pada rantai
· Hasilkan bukti penyimpanan → hasilkan bukti zk → gunakan pada rantai
Mungkin juga ada entitas yang mengemas beberapa kumpulan bukti menjadi satu bukti (termasuk bukti penyimpanan dan bukti zk). Ini adalah langkah pengoptimalan opsional dan belum akan dibahas.
Mari kita lihat tiga tahap utama "alur kerja" bukti penyimpanan: menghasilkan bukti penyimpanan, menghasilkan bukti zk, dan menggunakannya pada rantai.
(1) Menghasilkan sertifikat penyimpanan
· Bukti penyimpanan memungkinkan kami menggunakan komitmen kerahasiaan untuk membuktikan bahwa informasi tertentu ada di blockchain dan asli;
· Bukti penyimpanan telah menjadi bagian dari komunitas kriptografi sejak munculnya pohon Merkle pada tahun 1979. Namun, sertifikat penyimpanan vanilla biasanya berukuran cukup besar. Inovasi modern terletak pada penggabungan bukti penyimpanan dengan komputasi yang dapat dibuktikan untuk menciptakan bukti ringkas yang dapat diverifikasi secara on-chain.
Untuk menghasilkan bukti penyimpanan, blok data tertentu dan jalur Merkle atau Verkle yang terkait di pohon Merkle harus disediakan. Jalur tersebut terdiri dari hash saudara yang diperlukan untuk merekonstruksi hash root menggunakan algoritma hashing yang sama.
Untuk memverifikasi bukti penyimpanan, penerima dapat menghitung ulang hash root menggunakan data yang disediakan dan jalur Merkle atau Verkle. Jika hash akar yang dihitung ulang cocok dengan hash akar yang diketahui, penerima dapat yakin bahwa data tersebut asli dan merupakan bagian dari kumpulan data yang dikirimkan.
(2) Menghasilkan ZKP (bukti tanpa pengetahuan)
Namun, bukti penyimpanan tipe Ethereum berukuran sekitar 4kb - cukup besar untuk mempublikasikan seluruh bukti penyimpanan ke rantai target, karena verifikasi bukti akan sangat mahal. Oleh karena itu, masuk akal untuk menggunakan ZKP (misalnya ZK-SNARK) untuk kompresi, yang dapat membuat bukti lebih kecil dan biaya verifikasi lebih rendah.
（3）Buka gulungan ZKP
Setelah mendapatkan ZKP, pengguna di rantai target dapat membuka gulungan bukti yang mereka peroleh (misalnya, mengakses status historis melalui header blok atau hash blok).
Pembukaan gulungan dapat dilakukan dengan cara berikut:
Akumulasi on-chain: Seluruh proses rekonstruksi header blok dari bukti dilakukan langsung di blockchain. Kekurangan: biaya bahan bakar tinggi dan konsumsi sumber daya komputasi Keuntungan: tidak ada waktu pembuktian tambahan, latensi rendah karena tidak perlu menghasilkan bukti di luar blockchain.
Kompresi on-chain: Hapus informasi yang berlebihan atau tidak perlu dari data, atau gunakan struktur data yang dioptimalkan untuk efisiensi ruang. Data terkompresi dikirim ke blockchain dan dapat didekompresi bila diperlukan. Kekurangan: Mengompresi dan mendekompresi data mungkin memerlukan komputasi tambahan, namun penundaan ini mungkin dapat diabaikan. Algoritme kompresi yang digunakan mungkin berdampak negatif pada keamanan data. Keuntungannya: mengurangi biaya data;
Penyimpanan off-chain: Menyimpan data secara off-chain dan menempatkan blok data tertentu secara on-chain sesuai permintaan. Hal ini relevan untuk solusi yang perlu menyimpan data dalam jumlah besar karena alasan tertentu (misalnya node arsip Ethereum mulai dari blok genesis). Kekurangan: Sama seperti kompresi on-chain; Keuntungan: lebih mengurangi biaya data.
1.2.3 Pihak ketiga yang tepercaya
Solusi lintas rantai yang lengkap juga harus melibatkan solusi pengiriman pesan silang dengan pihak ketiga yang tepercaya (seperti oracle, jembatan terpusat, dll.).
1.2.4 Sistem pembuktian “Universal”.
Dalam hal menggunakan mekanisme platform agregasi bukti bersama, pengiriman pesan dapat dipercepat dengan menerima hash blok yang diselesaikan dalam platform agregasi, dan penyelesaian di sini juga akan menangani pengiriman pesan (tetapi jika terjadi kesalahan dengan platform agregasi bukti, apa yang harus dilakukan? ).
1.2.5 Beberapa masalah yang tidak diketahui dalam perpesanan lintas rantai ZK
Apakah perpesanan lintas rantai dapat dilakukan tanpa pihak ketiga yang tepercaya (yang dapat berupa satu entitas atau beberapa entitas)? Apa mekanisme yang efektif untuk pengiriman pesan lintas rantai? Secara umum, untuk Ethereum L2 (yang memiliki akses langsung ke hash blok L1) dan Ethereum itu sendiri, jika sebuah rantai dapat menjalankan klien ringan dll. pada rantai lain, ia dapat memverifikasi asal-usul dari header blok rantai eksternal tersebut, yang cukup untuk trustless pesan lintas rantai.
Apakah sirkuit ZK yang digunakan untuk pembangkitan bukti lintas rantai sesuai skalanya? Dalam beberapa kasus, terutama ketika lapisan konsensus (yang memerlukan verifikasi operasi lintas rantai) sangat besar, sirkuit yang digunakan untuk pesan lintas rantai ZK mungkin berukuran lebih besar daripada penyimpanan rollup dan on-chain, dan overhead komputasi juga akan menjadi besar. Agaknya masalah ini bisa diatasi dengan pendekatan yang lebih terpusat.
2. Contoh solusi pesan lintas rantai
· Succinct Labs menggunakan klien ringan untuk memverifikasi konsensus dari rantai sumber ke lapisan konsensus rantai target. Ide spesifiknya adalah adanya protokol klien ringan untuk memastikan bahwa node dapat menyinkronkan header blok dari status akhir blockchain. ZKP digunakan untuk menghasilkan bukti konsensus.
· Lagrange Labs membuat bukti status lintas rantai non-interaktif. Jaringan bukti Lagrange bertanggung jawab untuk menciptakan root negara. Setiap node Lagrange berisi bagian dari kunci pribadi shard, yang digunakan untuk membuktikan status rantai tertentu. Setiap akar keadaan adalah akar Verkle bertanda ambang batas yang dapat digunakan untuk membuktikan keadaan rantai tertentu pada waktu tertentu. Akar negara sepenuhnya universal dan dapat digunakan dalam pembuktian negara untuk membuktikan keadaan kontrak atau dompet mana pun dalam rantai saat ini.
· Herodotus menggunakan bukti penyimpanan ZKP untuk menyediakan kontrak pintar dan secara sinkron mengakses data on-chain dari lapisan Ethereum lainnya. Untuk verifikasi, ia menggunakan pesan L1<>L2 asli untuk menyinkronkan hash blok antara rollup Ethereum.
· =nil; Foundation (Mina, L1) mengizinkan kontrak pintar di Ethereum untuk memverifikasi validitas status Mina. Hasilkan bukti negara tujuan khusus yang murah untuk diverifikasi di Ethereum (bukti asli Mina mahal di Ethereum). Diasumsikan bahwa (di masa depan) aplikasi dapat langsung menggunakan alat pembuat bukti Mina untuk memeriksa validitas transaksi lintas rantai. =nil; Foundation juga memiliki Pasar Bukti di mana pengguna/proyek terutama dapat membeli/menjual sertifikat SNARK yang memungkinkan akses data tanpa kepercayaan.
Aksioma: Jika Axiom telah menghasilkan ZKP untuk buku besar sejauh ini - Aksioma tidak perlu membuat ZKP untuk blok data tertentu - Aksioma dapat meneruskan ZKP ini ke rantai (sebagai relayer) dan bahkan memberikan akses ke Akses ZKP ini.
3. Pesan lintas rantai L2
Penafian: Pesan lintas rantai masih berkembang untuk sebagian besar L2. Semua analisis di bawah ini didasarkan pada informasi sumber terbuka. Meskipun demikian, solusi yang disebutkan dalam artikel mungkin masih dalam tahap eksplorasi dan pengujian, dan rollup pada akhirnya dapat mengadopsi metode lain.
（1）Taiko
· Taiko menyimpan nilai hash blok dari setiap rantai. Untuk setiap pasangan rantai, ia menyebarkan dua kontrak pintar yang menyimpan hash satu sama lain. Dalam kasus L2←→L1, setiap kali blok L2 dibuat di Taiko, hash dari blok sekitarnya di L1 disimpan dalam kontrak TaikoL2. Metode operasi yang sama digunakan dalam kasus L1←→L2.
· Akar Merkle terbaru yang diketahui yang disimpan di rantai target dapat diperoleh dengan memanggil getCrossChainBlockHash(0) pada kontrak TaikoL1/TaikoL2 dan mendapatkan nilai/pesan untuk diverifikasi. Hash saudara terbaru yang diketahui dari root Merkle dapat diperoleh dengan memanggil permintaan eth_getProof menggunakan RPC standar pada "rantai asal".
· Kemudian, kirimkan saja untuk diverifikasi terhadap hash blok terbaru yang diketahui yang disimpan dalam daftar di "rantai target". Validator akan mengambil nilai (daun pada pohon Merkle) dan hash saudaranya untuk menghitung ulang root Merkle dan memeriksa apakah cocok dengan root yang disimpan dalam daftar hash blok rantai target.
（2）Starknet
Starknet menggunakan bukti penyimpanan untuk pengiriman pesan lintas rantai yang tidak dapat dipercaya.
L2→L1 protokol pesan
· Selama pelaksanaan transaksi Starknet, kontrak di Starknet mengirimkan pesan L2→L1.
· Kemudian tambahkan parameter pesan (berisi kontrak penerima dan data terkait di L1) ke pembaruan status yang relevan (pohon penyimpanan utama).
· Pesan L2 disimpan di L1 kontrak pintar.
· Memancarkan acara di L1 (menyimpan parameter pesan).
· Alamat penerima di L1 dapat mengakses dan menggunakan pesan sebagai bagian dari transaksi L1 dengan memberikan kembali parameter pesan.
· Pesan lintas rantai disimpan di pohon tulang punggung.
L2 → L1
L1 → L2
（3）Optimisme
· Komunikasi antara L1 dan L2 dicapai melalui dua kontrak pintar khusus yang disebut "messenger".
· Untuk transaksi dari Optimism (L2) ke Ethereum (L1), perlu memberikan bukti Merkle tentang pesan di L1 setelah state root ditulis. Setelah transaksi bukti menjadi bagian dari rantai L1, periode tantangan kesalahan dimulai. Setelah masa tunggu ini, setiap pengguna dapat "menyelesaikan" transaksi dengan memicu transaksi kedua di Ethereum, mengirimkan pesan ke kontrak L1 target.
· Pesan lintas rantai disimpan di pohon tulang punggung.
(4) Arbitrase
· Tiket yang dapat dicoba ulang adalah metode kanonik Arbitrum untuk membuat pesan L1 ke L2, yaitu transaksi L1 yang menginisialisasi pesan untuk dieksekusi di L2. Retryable dapat dikirimkan pada L1 dengan biaya tetap (hanya bergantung pada ukuran data panggilannya). Pohon status utama digunakan untuk komunikasi lintas rantai format data khusus dalam kontrak pintar. Mengirimkan tiket yang dapat dicoba ulang di L1 dapat dipisahkan/asinkron dari eksekusi di L2. Dapat dicoba ulang memberikan atomisitas antara operasi lintas rantai. Jika permintaan transaksi L1 berhasil dikirimkan (yaitu tidak ada rollback), maka ada jaminan kuat bahwa eksekusi Retryable pada L2 pada akhirnya akan berhasil.
· Arbitrum memiliki dua batang: Rantai Nitro dipertahankan dalam format pohon negara Ethereum, yaitu pohon Merkle. Pohon Assertion menyimpan keadaan rantai Arbitrum yang dikonfirmasi di Ethereum melalui "penegasan". Aturan untuk memajukan rantai Arbitrum bersifat deterministik. Artinya, mengingat keadaan rantai dan beberapa nilai masukan baru, hanya ada satu keluaran yang valid. Oleh karena itu, jika pohon bukti berisi banyak daun, maka paling banyak satu daun dapat mewakili keadaan rantai yang valid.
· Sistem Kotak Keluar Arbitrum memungkinkan panggilan kontrak apa pun dari L2 ke L1, yaitu pesan dimulai dari L2 dan akhirnya dieksekusi di L1. Pesan L2 ke L1 (alias "pesan keluar") memiliki banyak kesamaan dengan pesan L1 ke L2 Arbitrum (Dapat Dicoba Ulang), meskipun ada beberapa perbedaan mencolok. Bagian dari status L2 rantai Arbitrum - bagian yang dibuktikan di setiap RBlock - adalah akar Merkle dari semua pesan L2 hingga L1 dalam riwayat rantai. Setelah RBlock yang terbukti dikonfirmasi (biasanya sekitar seminggu setelah pembuktian), root Merkle yang terdapat dalam kontrak Kotak Keluar dipublikasikan ke L1. Kontrak Kotak Keluar kemudian memungkinkan pengguna untuk mengeksekusi pesan mereka.
（5）Poligon zkEVM
· Bridge SC zkEVM menggunakan pohon Merkle khusus yang disebut Pohon Keluar untuk setiap jaringan yang berpartisipasi dalam komunikasi atau transaksi aset.
· Ia menggunakan akar Merkle (dalam pohon negara terpisah) dan diagram arsitektur jembatan dapat ditemukan di github.
· Penerapan zkEVM Bridge SC telah membuat beberapa perubahan berdasarkan kontrak deposit Ethereum 2.0. Misalnya, ia menggunakan pohon Merkle tambahan yang dirancang khusus tetapi mengadopsi logika yang sama dengan kontrak deposit Ethereum 2.0. Perbedaan lainnya terkait dengan hash dasar dan node daun.
· Fitur utama dari kontrak pintar Polygon zkEVM Bridge adalah penggunaan Exit Tree dan global Exit Tree, di mana akar dari Exit Tree global adalah sumber utama status kebenaran. Jadi ada dua root manager Exit global yang berbeda untuk L1 dan L2, dan logika terpisah untuk Bridge SC.
（6）Gulir
· Kontrak jembatan yang diterapkan pada Ethereum dan Scroll memungkinkan pengguna untuk meneruskan pesan sewenang-wenang antara L1 dan L2. Selain protokol perpesanan ini, kami juga membangun protokol penghubung yang tidak dapat dipercaya untuk memungkinkan pengguna menjembatani aset ERC-20 antara L1 dan L2. Untuk mengirim pesan atau dana dari Ethereum ke Scroll, pengguna memanggil transaksi sendMessage pada kontrak Bridge. Relai akan mengindeks transaksi ini pada L1 dan mengirimkannya ke sequencer untuk dimasukkan ke dalam blok L2. Pada kontrak jembatan L2, proses pengiriman pesan dari Scroll back ke Ethereum serupa.
· Pesan lintas rantai disimpan dalam antrian pesan reguler. Sequencer menyerap pesan lintas rantai dari antrean ini dan menambahkannya ke rantai sebagai transaksi reguler.
（7）Era zksync
Penafian: Bagian ini hanya tentang Era zksync dan mungkin berbeda dari perpesanan lintas rantai di ZK Stack, kerangka kerja modular untuk membangun superchain ZK yang berdaulat.
· Setiap paket transaksi memiliki pesan L2->L1 terpisah.
· Tidak mungkin mengirim transaksi langsung dari L2 ke L1. Namun, Anda dapat mengirim pesan dengan panjang berapa pun ke Ethereum dari zkSync Era dan kemudian menggunakan kontrak pintar L1 untuk memproses pesan yang diterima di Ethereum. zkSync Era memiliki fungsi bukti permintaan yang akan mengembalikan parameter boolean yang menunjukkan apakah pesan berhasil dikirim ke L1. Ambil bukti Merkle yang terdapat dalam pesan dengan mengamati di Ethereum atau menggunakan metode zks_getL2ToL1LogProof dari API zksync-web3.
· Untuk L1→L2, kontrak pintar zkSync Era memungkinkan pengirim meminta transaksi di Ethereum L1 dan meneruskan data ke zkSync Era L2.
· Kontrak jembatan: https://github.com/matter-labs/era-contracts/blob/main/ethereum/contracts/bridge/L1ERC20Bridge.sol
4. Kesimpulan
Komunikasi lintas rantai sangat diperlukan untuk aplikasi yang “harus dimiliki” untuk adopsi massal blockchain (misalnya, dompet pemulihan sosial lintas rantai yang dijelaskan dalam artikel Buterin). Sebagian besar solusi lintas rantai yang saat ini digunakan dirancang untuk L1←→L2 untuk mencakup fungsionalitas penarikan. Solusi ini dapat diperluas ke lebih banyak blockchain. Namun pada saat yang sama, solusi komunikasi lintas rantai yang lebih canggih dapat diterapkan, seperti "status baca langsung" yang tidak memerlukan bukti sama sekali atau "bukti penyimpanan" yang tidak memerlukan kepercayaan. Bagi sebagian besar L2, masih ada ruang untuk pengembangan dan kemajuan dalam komunikasi lintas rantai.