Jelajahi komunikasi lintas rantai dari perspektif rollup

Penulis: Lisa A., Taiko Labs; terjemahan: Jinse Finance xiaozou

Artikel ini akan membahas berbagai metode perpesanan lintas rantai L2 dari perspektif rollup, berfokus pada komunikasi lintas rantai tanpa kepercayaan. Kami akan secara singkat melihat pendekatan pembacaan status langsung, pendekatan klien ringan, dan bukti penyimpanan. Kami juga akan membahas mekanisme agregasi bukti, transmisi pesan lintas rantai pihak ketiga tepercaya, dan solusi lintas rantai inti ZK. Terakhir, mari kita lihat bagaimana L2 yang berbeda mengimplementasikan perpesanan lintas rantai saat ini.

1. Pengantar perpesanan 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 cross-chain "built-in" yang dapat digunakan untuk mengakses root status L1, yang akan diteruskan ke L2 sebagai pesan deposit.

1**.1** Dua jenis akses ke root negara

Tipe 1: Baca status root secara langsung - dapat dilakukan melalui opcode atau dikompilasi sebelumnya. Namun, sejauh ini belum dilaksanakan, jadi tidak ada bukti yang diperlukan.

Brecht Devos menjelaskan cara yang mungkin untuk membaca status secara langsung dalam artikel penelitian: "...kita dapat mengekspos kontrak yang telah dikompilasi yang dapat langsung memanggil kontrak pintar pada rantai target. Ini dikompilasi langsung di Rantai sumber menyisipkan dan mengeksekusi kode kontrak pintar rantai lain Hal ini memastikan bahwa smart contract selalu memiliki akses ke status terbaru yang tersedia dengan cara yang efisien dan mudah dibuktikan.”

· Juga dijelaskan dalam RFP Optimisme "Bukti Konsep Doa Statis Jarak Jauh".

Tipe 2: Proof Generation - yaitu membuktikan pernyataan tentang satu blockchain di blockchain lain.

"Pesan lintas rantai dengan bukti" memiliki dua pendekatan:

· 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 untuk pembuatan bukti pihak ketiga maupun untuk peserta komunikasi lintas rantai untuk menghasilkan bukti sendiri.

Bukti dibagikan di antara rollup yang berbeda untuk memastikan operasi lintas rantai. Pendekatan ini, yang tidak banyak dibahas dalam artikel ini, saat ini sedang dalam tahap penelitian dan eksplorasi dan tidak dianggap sebagai solusi yang dapat diterapkan secara luas.

1**.2** Metode “Pesan Lintas Rantai dengan Bukti”

1.2.1 Perpesanan lintas rantai klien ringan

Buktikan data pada rantai B

Dapatkan data bukti Merkle dari simpul penuh rantai B (simpul pengarsipan arsip jika bukti penyimpanan untuk status historis tertentu diperlukan);

Kirim header blok dan data bukti yang sesuai dengan blok rantai B yang berisi status yang ingin kami verifikasi ke kontrak pembukti pada rantai A sebagai calldata;

Kontrak pembukti menghitung nilai hash blok berdasarkan data header blok, menanyakan kontrak cerdas 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

Bukti Penyimpanan memiliki dua opsi "alur kerja":

· Hasilkan bukti penyimpanan → gunakan on-chain

· Hasilkan bukti penyimpanan → hasilkan bukti zk → gunakan pada rantai

Entitas juga dapat mengemas beberapa koleksi bukti menjadi satu bukti (bukti penyimpanan dan bukti zk). Ini adalah langkah pengoptimalan opsional dan belum dibahas.

Mari kita lihat tiga tahap utama dari "alur kerja" bukti penyimpanan: menghasilkan bukti penyimpanan, menghasilkan bukti zk, dan menggunakannya pada rantai.

(1) Hasilkan Bukti Penyimpanan

· Bukti penyimpanan memungkinkan kami menggunakan komitmen rahasia untuk membuktikan bahwa informasi tertentu ada di blockchain dan benar;

Proof-of-storage telah menjadi bagian dari ruang crypto sejak munculnya pohon Merkle pada tahun 1979. Namun, bukti penyimpanan vanilla biasanya cukup besar. Inovasi modern terletak pada penggabungan proof-of-storage dengan perhitungan 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 terdiri dari hash saudara yang diperlukan untuk merekonstruksi hash root menggunakan algoritme hashing yang sama.

Untuk memverifikasi Bukti Penyimpanan, penerima dapat menggunakan data yang disediakan dan jalur Merkle atau Verkle untuk menghitung ulang root hash. Jika root hash yang dihitung ulang cocok dengan root hash yang diketahui, penerima dapat yakin bahwa data tersebut asli dan merupakan bagian dari kumpulan data yang dikirimkan.

(2) Hasilkan ZKP (Zero-Knowledge Proof)

Namun, Proof of Storage tipe Ethereum adalah sekitar 4kb - agak besar untuk memposting seluruh Proof of Storage pada rantai target, karena verifikasi bukti akan sangat mahal. Oleh karena itu, masuk akal untuk menggunakan ZKP (misalnya, ZK-SNARK) untuk kompresi, yang dapat membuat pembuktian menjadi lebih kecil dan lebih murah untuk diverifikasi.

（3）A****roll ZKP

Setelah mendapatkan ZKP, pengguna di rantai target dapat membuka gulungan bukti yang mereka peroleh (mis., mengakses status riwayat melalui header blok atau hash blok).

Membuka gulungan dapat dilakukan sebagai berikut:

Akumulasi on-chain: Seluruh proses merekonstruksi header blok dari bukti dilakukan langsung di blockchain. Kekurangan: biaya bahan bakar tinggi, menghabiskan 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 diperlukan dari data, atau gunakan struktur data yang dioptimalkan untuk efisiensi ruang. Data terkompresi dikirim ke blockchain dan dapat didekompresi bila diperlukan. Kontra: Mengompresi dan mendekompresi data dapat berarti komputasi tambahan, tetapi latensi ini dapat diabaikan. Algoritma kompresi yang digunakan mungkin berdampak negatif pada keamanan data; keuntungan: mengurangi biaya data.

Penyimpanan off-chain: Menyimpan data off-chain, dan menempatkan blok data tertentu secara on-chain sesuai permintaan. Ini relevan untuk solusi yang perlu menyimpan data dalam jumlah besar karena beberapa alasan (mis. Node arsip Ethereum dari blok genesis). Kontra: Sama seperti kompresi on-chain; Kelebihan: Kurangi biaya data lebih lanjut.

1**.2.3** Pihak Ketiga Tepercaya

Solusi lintas rantai lengkap juga harus melibatkan solusi perpesanan silang dengan pihak ketiga tepercaya (seperti oracle, jembatan terpusat, dll.).

1**.2.4** Sistem Pembuktian “Universal”

Dalam kasus mekanisme platform bukti agregasi bersama, perpesanan dapat dipercepat dengan menerima hash blok yang diselesaikan dalam platform agregasi, dan penyelesaian di sini juga akan menangani perpesanan (tetapi jika ada masalah dengan platform agregasi apa yang harus dilakukan?).

1**.2.5 Beberapa masalah ZK****perpesanan lintas rantai yang tidak diketahui**

Apakah perpesanan lintas rantai dapat dilakukan tanpa pihak ketiga tepercaya (yang dapat berupa satu entitas atau beberapa entitas)? Apa mekanisme yang efisien untuk pengiriman pesan lintas rantai? Secara umum, untuk Ethereum L2 (dengan akses langsung untuk memblokir hash L1) dan Ethereum itu sendiri, jika satu rantai dapat menjalankan klien ringan, dll., yang cukup untuk perpesanan lintas rantai yang tidak dapat dipercaya.

Apakah sirkuit ZK yang digunakan untuk pembuatan bukti lintas rantai diskalakan dengan benar? Dalam beberapa kasus, terutama ketika lapisan konsensus (yang perlu diverifikasi untuk operasi lintas rantai) sangat besar, sirkuit yang digunakan untuk pengiriman pesan lintas rantai ZK dapat menjadi urutan besarnya lebih besar daripada penyimpanan rollup dan on-chain, dan overhead komputasi juga sangat besar. Agaknya masalah ini dapat diatasi dengan pendekatan yang lebih terpusat.

2**、Contoh solusi perpesanan lintas rantai**

· Laboratorium Ringkas*** menggunakan klien ringan untuk memverifikasi konsensus dari rantai sumber ke lapisan konsensus rantai target. Idenya adalah bahwa terdapat protokol klien ringan untuk memastikan bahwa node dapat menyinkronkan header blok dari status blockchain akhir. ZKP digunakan untuk menghasilkan bukti konsensus.

· La****grange Labs membuat bukti status lintas rantai non-interaktif. Lagrange membuktikan bahwa jaringan bertanggung jawab untuk membuat root negara. Setiap node Lagrange berisi sebagian dari kunci pribadi beling, yang membuktikan keadaan rantai tertentu. Setiap root status adalah root Verkle bertanda ambang batas yang dapat digunakan untuk membuktikan status rantai tertentu pada waktu tertentu. Akar status sepenuhnya umum dan dapat digunakan sebagai bukti status untuk membuktikan status saat ini dari salah satu kontrak atau dompet dalam rantai.

· He****rodotus menggunakan bukti penyimpanan ZKP untuk menyediakan kontrak pintar dan mengakses data pada rantai lapisan Ethereum lainnya secara sinkron. Untuk validasi, ia menggunakan perpesanan L1<>L2 asli untuk menyinkronkan hash blok antara rollup Ethereum.

=nil; Foundation (Mina, L1) mengizinkan smart contract di Ethereum untuk memverifikasi validitas status Mina. Hasilkan bukti negara dengan tujuan khusus, murah untuk diverifikasi di Ethereum (bukti Mina lokal di Ethereum mahal). Secara hipotetis (suatu saat nanti) aplikasi dapat langsung menggunakan alat penghasil bukti Mina untuk memeriksa validitas transaksi lintas rantai. =nil; Foundation juga memiliki Pasar Bukti di mana pengguna/proyek terutama dapat membeli/menjual bukti SNARK yang memungkinkan akses data tanpa kepercayaan.

Axiom: Jika Axiom telah menghasilkan ZKP untuk buku besar sejauh ini - tidak perlu menghasilkan ZKP untuk blok tertentu - dapat meneruskan ZKP ini ke rantai (sebagai relai), atau bahkan Menyediakan akses ke ZKP ini.

3. Perpesanan lintas rantai L2

*Penafian: Perpesanan lintas rantai masih berkembang untuk sebagian besar L2. Semua analisis di bawah ini didasarkan pada informasi sumber terbuka. Yang mengatakan, solusi yang disebutkan dalam artikel mungkin dalam tahap eksplorasi dan pengujian, dan rollup pada akhirnya dapat mengadopsi metode lain. *

**（1）**Taiko

Taiko menyimpan hash blok untuk setiap rantai. Untuk setiap pasangan rantai, ini menyebarkan dua kontrak pintar yang menyimpan hash satu sama lain. Dalam contoh L2←→L1, setiap kali blok L2 dibuat di Taiko, nilai hash dari blok periferal di L1 disimpan dalam kontrak TaikoL2. Juga dalam kasus L1←→L2, mode operasinya sama.

Akar Merkle terbaru yang diketahui disimpan pada rantai target dapat diperoleh dengan memanggil getCrossChainBlockHash(0) pada kontrak TaikoL1/TaikoL2 dan mendapatkan nilai/pesan untuk diverifikasi. Hash saudara dari root Merkle terbaru yang diketahui dapat diperoleh dengan memanggil permintaan eth_getProof menggunakan RPC standar pada "rantai sumber".

Kemudian, cukup kirim mereka 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 saudara untuk menghitung ulang root Merkle dan memeriksa apakah cocok dengan root yang disimpan dalam daftar hash blok rantai target.

**（2）**Starknet

Starknet menggunakan Proof of Storage untuk perpesanan lintas rantai yang tidak dapat dipercaya.

Protokol Pesan L2→L1

· Selama pelaksanaan transaksi Starknet, kontrak di Starknet mengirimkan pesan L2→L1.

Parameter pesan (berisi kontrak penerima dan data terkait di L1) kemudian ditambahkan ke pembaruan status yang relevan (pohon penyimpanan utama).

· Pesan L2 disimpan di L1 kontrak pintar.

· Keluarkan acara di L1 (simpan parameter pesan).

Alamat penerima di L1 dapat mengakses dan menggunakan pesan sebagai bagian dari transaksi L1 dengan menyediakan kembali parameter pesan.

· Pesan lintas rantai disimpan di pohon batang.

L2 → L1

L1 → L2

**（3）**Optimisme

Komunikasi antara L1 dan L2 diimplementasikan oleh dua smart contract khusus yang disebut "messengers".

· Untuk transaksi Optimism (L2) ke Ethereum (L1), perlu untuk memberikan bukti Merkle dari pesan di L1 setelah akar status ditulis. Setelah transaksi bukti ini 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 batang.

（4）Ar****bitrum

Tiket yang dapat dicoba kembali adalah metode kanonik yang digunakan Arbitrum untuk membuat perpesanan L1 ke L2, yaitu transaksi L1 yang menginisialisasi pesan untuk dijalankan pada L2. Retryable dapat diajukan pada L1 dengan biaya tetap (hanya bergantung pada ukuran data panggilannya). Pohon keadaan utama digunakan untuk komunikasi lintas rantai dari format data khusus dalam kontrak pintar. Mengirimkan tiket yang dapat dicoba ulang di L1 dapat dipisahkan/tidak sinkron dari eksekusi di L2. Retryables memberikan atomisitas antara operasi lintas rantai. Jika permintaan transaksi L1 berhasil dikirim (yaitu tanpa rollback), maka eksekusi Retryable pada L2 memiliki jaminan kuat bahwa pada akhirnya akan berhasil.

Arbitrum memiliki dua batang: Rantai Nitro dipertahankan dalam format pohon status Ethereum, pohon Merkle. Assertion Tree menyimpan keadaan rantai Arbitrum yang dikonfirmasi di Ethereum melalui "pernyataan". Aturan yang memajukan rantai Arbitrum bersifat deterministik. Ini berarti bahwa mengingat keadaan rantai dan beberapa nilai input baru, hanya ada satu output yang valid. Oleh karena itu, jika pohon pembuktian berisi banyak daun, paling banyak satu daun dapat mewakili keadaan rantai yang valid.

Sistem Outbox 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 kembali), meskipun ada beberapa perbedaan penting. Bagian dari status L2 dari rantai Arbitrum—yaitu, bagian yang dibuktikan dalam setiap RBlock—adalah akar Merkle dari semua pesan L2 ke L1 dalam riwayat rantai. Setelah RBlock yang terbukti dikonfirmasi (biasanya sekitar seminggu setelah pembuktian), root Merkle disertakan dalam kontrak Outbox dan dipublikasikan ke L1. Kontrak Outbox kemudian memungkinkan pengguna untuk mengeksekusi pesan mereka.

**（5）**Poligon zkEVM

· Bridge SC dari zkEVM ini menggunakan pohon Merkle khusus yang disebut Exit Tree untuk setiap jaringan yang berpartisipasi dalam komunikasi atau transaksi aset.

Ini menggunakan akar Merkle (dalam pohon keadaan terpisah), diagram arsitektur jembatan dapat ditemukan di github.

Penerapan zkEVM Bridge SC telah membuat beberapa perubahan berdasarkan kontrak deposit Ethereum 2.0. Sebagai contoh, ia menggunakan pohon Merkle khusus tambahan yang dirancang khusus, tetapi menggunakan logika yang sama dengan kontrak deposit Ethereum 2.0. Perbedaan lainnya terkait dengan hash dasar dan simpul daun.

Fitur utama kontrak cerdas Polygon zkEVM Bridge adalah penggunaan Exit Tree dan Global Exit Tree, di mana akar dari Exit Tree global adalah sumber utama dari kondisi kebenaran. Oleh karena itu, L1 dan L2 memiliki dua manajer akar keluar global yang berbeda, dan Bridge SC memiliki logika terpisah.

（6）S****guling

· Kontrak jembatan yang digunakan di Ethereum dan Gulir memungkinkan pengguna untuk menyampaikan pesan sewenang-wenang antara L1 dan L2. Di atas protokol perpesanan ini, kami juga membuat protokol penghubung tanpa kepercayaan 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. Relay akan mengindeks transaksi ini di L1 dan mengirimkannya ke pemesan untuk dimasukkan ke dalam blok L2. Pada kontrak jembatan L2, proses pengiriman pesan dari Gulir kembali ke Ethereum serupa.

· Pesan lintas rantai disimpan dalam antrian pesan biasa. Pemesan mencerna pesan lintas rantai dari antrean ini dan menambahkannya ke rantai sebagai transaksi biasa.

**（7）**Era zksync

*Penafian: Konten di bagian ini hanya tentang Era zksync, yang mungkin berbeda dari perpesanan lintas rantai di ZK Stack, yang merupakan kerangka kerja modular untuk membangun superchain ZK yang berdaulat. *

· Setiap paket transaksi memiliki satu pesan L2->L1.

· Tidak mungkin mengirim transaksi langsung dari L2 ke L1. Namun, Anda dapat mengirim pesan dengan panjang berapa pun dari Era zkSync ke Ethereum, dan kemudian memproses pesan yang diterima di Ethereum menggunakan kontrak cerdas L1. zkSync Era memiliki fungsi bukti permintaan yang akan mengembalikan parameter boolean yang menunjukkan apakah pesan berhasil dikirim ke L1. Ambil bukti Merkle yang terkandung dalam pesan dengan mengamati Ethereum atau menggunakan metode zks_getL2ToL1LogProof dari zksync-web3 API.

· Untuk L1→L2, kontrak pintar Era zkSync memungkinkan pengirim untuk meminta transaksi pada Ethereum L1 dan meneruskan data ke zkSync Era L2.

· Kontrak jembatan:

4. Kesimpulan

Komunikasi lintas rantai merupakan bagian integral dari aplikasi "must-have" untuk adopsi massal blockchain (misalnya, dompet pemulihan sosial lintas rantai yang dijelaskan dalam artikel Vitalik). Sebagian besar solusi rantai silang yang saat ini digunakan dirancang untuk L1←→L2 untuk menutupi fungsi penarikan. Solusi ini dapat diperluas ke lebih banyak blockchain. Tetapi pada saat yang sama, solusi komunikasi lintas rantai yang lebih maju dapat diimplementasikan, seperti "keadaan baca langsung" tanpa bukti sama sekali atau "bukti penyimpanan" tanpa kepercayaan. Untuk sebagian besar L2, masih ada ruang untuk perbaikan dalam komunikasi lintas rantai.