Pengantar

Masa depan adalah multichain. Pencarian skalabilitas telah membawa Ethereum menuju roll-up. Pergeseran menuju blockchain modular telah menghidupkan kembali perhatian pada rantai aplikasi. Dan di kemudian hari, kita akan mendengar desas-desus tentang roll-up, L3, dan rantai kedaulatan khusus aplikasi.

Namun hal ini harus dibayar dengan fragmentasi. Oleh karena itu, gelombang pertama jembatan dasar diluncurkan untuk memenuhi kebutuhan akan jembatan, namun seringkali fungsinya terbatas dan bergantung pada penandatangan terpercaya untuk keamanan.

Seperti apa akhir dari web3 yang saling terhubung? Kami percaya bahwa semua jembatan akan berkembang menjadi pesan lintas rantai atau protokol “Penerusan Pesan Sewenang-wenang” (AMP) untuk membuka kasus penggunaan baru, dengan memungkinkan aplikasi meneruskan pesan sewenang-wenang dari sumber ke rantai tujuan. Kita juga akan melihat munculnya “lanskap mekanisme kepercayaan”, di mana para pembangun melakukan berbagai pengorbanan dalam hal kegunaan, kompleksitas, dan keamanan.

Setiap solusi AMP memerlukan dua kemampuan penting:

• Verifikasi: Kemampuan untuk memverifikasi validitas pesan dari rantai sumber pada rantai tujuan
• Keaktifan: Kemampuan menyampaikan informasi dari sumber ke tujuan

Verifikasi tanpa kepercayaan 100% tidak dapat dicapai dan pengguna diharuskan memercayai kode, teori permainan, manusia (atau entitas), atau kombinasi dari semuanya, bergantung pada apakah verifikasi dilakukan secara on-chain atau off-chain.

Kami membagi keseluruhan lanskap interoperabilitas berdasarkan mekanisme kepercayaan dan arsitektur integrasi.

Mekanisme Kepercayaan:

1. Kode/matematika kepercayaan: Untuk solusi ini, bukti on-chain ada dan dapat diverifikasi oleh siapa saja. Solusi ini umumnya bergantung pada klien ringan untuk memvalidasi konsensus rantai sumber pada rantai tujuan atau memverifikasi validitas transisi keadaan untuk rantai sumber pada rantai tujuan. Verifikasi melalui klien ringan dapat dibuat jauh lebih efisien melalui bukti Zero Knowledge untuk mengompresi penghitungan panjang secara offline dan memberikan verifikasi sederhana secara on-chain untuk membuktikan penghitungan.
2. Teori permainan kepercayaan: Ada asumsi kepercayaan tambahan ketika pengguna/aplikasi harus mempercayai pihak ketiga atau jaringan pihak ketiga untuk keaslian transaksi. Mekanisme ini dapat dibuat lebih aman melalui jaringan tanpa izin yang dipadukan dengan teori permainan seperti insentif ekonomi dan keamanan yang optimis.
3. Percayai manusia: Solusi ini mengandalkan kejujuran dari mayoritas validator atau independensi entitas yang menyampaikan informasi berbeda. Hal ini membutuhkan kepercayaan pada pihak ketiga selain mempercayai konsensus dari dua rantai yang berinteraksi. Satu-satunya hal yang dipertaruhkan di sini adalah reputasi entitas yang berpartisipasi. Jika cukup banyak entitas peserta yang menyetujui bahwa suatu transaksi adalah sah, maka transaksi tersebut dianggap sah.

Penting untuk dicatat bahwa semua solusi, pada tingkat tertentu, memerlukan kepercayaan pada kode dan juga manusia. Solusi apa pun dengan kode yang salah dapat dieksploitasi oleh peretas dan setiap solusi memiliki elemen manusia dalam penyiapan, peningkatan, atau pemeliharaan basis kode.

Arsitektur integrasi:

1. Model Point-to-Point: Saluran komunikasi khusus perlu dibangun antara setiap sumber dan tujuan.
2. Model Hub and Spoke: Saluran komunikasi perlu dibuat dengan hub pusat yang memungkinkan konektivitas dengan semua blockchain lain yang terhubung ke hub tersebut.

Model Point to Point relatif sulit untuk diukur karena diperlukan saluran komunikasi berpasangan untuk setiap blockchain yang terhubung. Mengembangkan saluran-saluran ini dapat menjadi tantangan bagi blockchain dengan konsensus dan kerangka kerja yang berbeda. Namun, jembatan berpasangan memberikan lebih banyak fleksibilitas untuk menyesuaikan konfigurasi, jika diperlukan. Pendekatan hibrid juga dimungkinkan, misalnya dengan menggunakan protokol Komunikasi Antar-Blockchain (IBC) dengan perutean multi-hop melalui hub, yang menghilangkan kebutuhan akan komunikasi berpasangan langsung, namun menimbulkan lebih banyak kompleksitas dalam keamanan, latensi, dan biaya. pertimbangan.

Kode kepercayaan/matematika

Bagaimana cara klien ringan memvalidasi konsensus rantai sumber pada rantai tujuan?

Klien/node ringan adalah perangkat lunak yang terhubung ke node penuh untuk berinteraksi dengan blockchain. Klien ringan pada rantai tujuan biasanya menyimpan riwayat header blok (secara berurutan) dari rantai sumber yang cukup untuk memverifikasi transaksi. Agen off-chain seperti relayer memantau kejadian di rantai sumber, menghasilkan bukti penyertaan kriptografi, dan meneruskannya bersama dengan header blok, ke klien ringan di rantai tujuan. Klien ringan dapat memverifikasi transaksi saat mereka menyimpan header blok secara berurutan dan setiap header blok berisi hash root Merkle yang dapat digunakan untuk membuktikan status. Fitur utama dari mekanisme ini adalah:

1. Keamanan:

• Selain kepercayaan pada kode, asumsi kepercayaan lainnya diperkenalkan selama inisialisasi klien ringan. Ketika seseorang membuat klien ringan baru, klien ini diinisialisasi dengan header dari ketinggian tertentu dari rantai rekanan. Header yang disediakan mungkin salah dan klien ringan nantinya dapat diakali dengan header palsu lebih lanjut. Tidak ada asumsi kepercayaan yang diperkenalkan setelah klien ringan diinisialisasi. Namun, ini adalah asumsi kepercayaan yang lemah karena siapa pun dapat memeriksa inisialisasi.
• Ada asumsi keaktifan pada relayer karena diperlukan untuk mengirimkan informasi.

1. Implementasi: Tergantung pada ketersediaan dukungan untuk primitif kriptografi yang diperlukan untuk verifikasi

• Jika jenis rantai yang sama dihubungkan (kerangka aplikasi dan algoritma konsensus yang sama), maka implementasi klien ringan di kedua sisi akan sama. Contoh: IBC untuk semua rantai berbasis Cosmos SDK.
• Jika dua jenis rantai yang berbeda (kerangka aplikasi atau jenis konsensus yang berbeda) dihubungkan maka implementasi klien ringan akan berbeda. Contoh: Pembiayaan yang dapat dikomposisi berupaya untuk memungkinkan rantai Cosmos SDK terhubung melalui IBC ke Substrat (kerangka aplikasi ekosistem Polkadot). Hal ini memerlukan klien ringan Tendermint pada rantai media dan apa yang disebut klien ringan besar yang ditambahkan ke rantai Cosmos SDK

1. Tantangan:

• Intensifitas sumber daya: Menjalankan klien ringan berpasangan di semua rantai adalah hal yang mahal karena penulisan pada blockchain mahal dan tidak layak untuk dijalankan pada rantai dengan set validator dinamis seperti Ethereum.
• Ekstensibilitas: Implementasi klien ringan diperlukan untuk setiap kombinasi rantai. Mengingat penerapannya bervariasi berdasarkan arsitektur rantai, sulit untuk mengukur dan menghubungkan ekosistem yang berbeda.
• Eksploitasi kode: Kesalahan dalam kode dapat menyebabkan kerentanan. Eksploitasi rantai BNB pada bulan Oktober 2022 mengungkap kerentanan keamanan kritis yang memengaruhi semua rantai yang mendukung IBC.

Bagaimana bukti ZK memverifikasi validitas transisi negara untuk rantai sumber pada rantai tujuan?

Menjalankan klien ringan berpasangan di semua rantai membutuhkan biaya yang mahal dan tidak praktis untuk semua blockchain. Klien ringan dalam implementasi seperti IBC juga diharuskan untuk melacak kumpulan validator rantai sumber yang tidak praktis untuk rantai dengan kumpulan validator dinamis, seperti Ethereum. Bukti ZK memberikan solusi untuk mengurangi gas dan waktu verifikasi. Alih-alih menjalankan seluruh komputasi secara on-chain, hanya verifikasi bukti komputasi yang dilakukan secara on-chain dan komputasi sebenarnya dilakukan secara off-chain. Memverifikasi bukti perhitungan dapat dilakukan dalam waktu yang lebih singkat dan dengan bahan bakar yang lebih sedikit dibandingkan dengan menjalankan kembali perhitungan awal. Fitur utama dari mekanisme ini adalah:

1. Keamanan: zk-SNARK bergantung pada kurva elips untuk keamanannya dan zk-STARK bergantung pada fungsi hash. zk-SNARKs mungkin memerlukan atau tidak memerlukan pengaturan tepercaya. Penyiapan tepercaya hanya diperlukan pada awalnya yang mengacu pada peristiwa pembuatan awal kunci yang digunakan untuk membuat bukti yang diperlukan untuk verifikasi bukti tersebut. Jika rahasia dalam peristiwa penyiapan tidak dimusnahkan, rahasia tersebut dapat digunakan untuk memalsukan transaksi melalui verifikasi palsu. Tidak ada asumsi kepercayaan yang diperkenalkan setelah pengaturan tepercaya selesai.
2. Implementasi: Skema pembuktian ZK yang berbeda seperti SNARK, STARK, VPD, SNARG ada saat ini dan saat ini SNARK adalah yang paling banyak diadopsi. Pembuktian ZK rekursif adalah perkembangan terbaru lainnya yang memungkinkan total pekerjaan pembuktian dibagi antara beberapa komputer, bukan hanya satu. Untuk menghasilkan bukti validitas, primitif inti berikut perlu diterapkan:

• verifikasi skema tanda tangan yang digunakan oleh validator
• penyertaan bukti kunci publik validator dalam komitmen set validator (yang disimpan secara on-chain)
• melacak kumpulan validator yang sering berubah

1. Tantangan:

• Untuk mengimplementasikan berbagai skema tanda tangan di dalam zkSNARK memerlukan penerapan aritmatika di luar lapangan dan operasi kurva elips yang kompleks. Hal ini tidak mudah untuk dicapai dan mungkin memerlukan penerapan yang berbeda untuk setiap rantai tergantung pada kerangka kerja dan konsensusnya.
• Jika waktu dan upaya pembuktian sangat tinggi, maka hanya tim khusus dengan perangkat keras khusus yang dapat melakukan hal yang akan mengarah pada sentralisasi. Waktu pembuatan bukti yang lebih tinggi juga dapat menyebabkan latensi.
• Waktu dan upaya verifikasi yang lebih tinggi akan menyebabkan biaya on-chain yang lebih tinggi.

1. Contoh: Polimer ZK-IBC oleh Polymer Labs, Succinct Labs. Polymer sedang mengerjakan IBC yang mendukung multi-hop untuk meningkatkan konektivitas sekaligus mengurangi jumlah koneksi berpasangan yang diperlukan.

Percayai teori permainan

Protokol interoperabilitas yang mengandalkan teori permainan dapat dibagi menjadi 2 kategori berdasarkan cara protokol tersebut memberi insentif pada perilaku jujur dari entitas yang berpartisipasi:

1. Keamanan ekonomi: Beberapa peserta eksternal (seperti validator) mencapai konsensus mengenai status rantai sumber yang diperbarui. Ini mirip dengan pengaturan multi-sig tetapi untuk menjadi validator, peserta diharuskan mempertaruhkan sejumlah token, yang dapat dipotong jika ada aktivitas jahat yang terdeteksi. Dalam pengaturan tanpa izin, siapa pun dapat mengumpulkan taruhan dan menjadi validator. Ada juga hadiah blok, yang berfungsi sebagai insentif ekonomi, ketika validator yang berpartisipasi mengikuti protokol. Dengan demikian, para peserta diberi insentif ekonomi untuk jujur. Namun, jika jumlah yang dapat dicuri jauh lebih tinggi dari jumlah yang dipertaruhkan, maka peserta dapat berkolusi untuk mencuri dana. Contoh: Axelar, Celer IM
2. Keamanan optimis: Solusi keamanan optimis bergantung pada asumsi kepercayaan minoritas yang mengasumsikan bahwa hanya sebagian kecil peserta blockchain yang hidup, jujur, dan mengikuti aturan protokol. Solusinya hanya memerlukan satu peserta yang jujur untuk memegang jaminan. Contoh paling umum adalah solusi optimal dimana siapa pun dapat mengirimkan bukti penipuan. Ada juga insentif ekonomi di sini, namun secara praktis bahkan bagi pengamat yang jujur sekalipun bisa saja melewatkan transaksi penipuan. Roll-up yang optimis juga memanfaatkan pendekatan ini. Contoh: Pengembara, ChainLink CCIP

• Dalam kasus Nomad, pengamat dapat membuktikan adanya penipuan. Namun, pengamat Nomad telah masuk daftar putih pada saat penulisan.
• ChainLink CCIP akan memanfaatkan Jaringan Anti-Penipuan yang terdiri dari jaringan oracle terdesentralisasi dengan tujuan tunggal untuk memantau aktivitas jahat. Implementasi Jaringan Anti-Penipuan CCIP belum terlihat.

Fitur utama dari mekanisme ini adalah:

1. Keamanan: Untuk kedua mekanisme tersebut, penting untuk memiliki partisipasi tanpa izin dari validator dan pengamat agar mekanisme teori permainan menjadi efektif. Berdasarkan mekanisme keamanan ekonomi, dana mungkin lebih berisiko jika jumlah yang dipertaruhkan lebih rendah dari jumlah yang dapat dicuri. Dalam mekanisme keamanan optimis, asumsi kepercayaan minoritas untuk solusi optimis dapat dieksploitasi jika tidak ada yang menyerahkan bukti penipuan, atau jika pengawas yang memiliki izin dikompromikan/dihapus, sedangkan mekanisme keamanan ekonomi tidak memiliki ketergantungan yang sama pada keaktifan keamanan.
2. Penerapan:

• Rantai tengah dengan validatornya sendiri: Sekelompok validator eksternal memantau rantai sumber, mencapai konsensus mengenai validitas transaksi setiap kali panggilan terdeteksi, dan memberikan pengesahan pada rantai tujuan jika konsensus tercapai. Validator biasanya diharuskan mempertaruhkan sejumlah token tertentu yang dapat dikurangi jika aktivitas berbahaya terdeteksi. Contoh: Jaringan Axelar, Celer IM
• Melalui agen Off-chain: Agen off-chain dapat digunakan untuk menerapkan solusi seperti roll-up yang optimis di mana selama jangka waktu yang telah ditentukan, agen off-chain akan diizinkan untuk mengirimkan bukti penipuan dan mengembalikan transaksi. Contoh: Nomad mengandalkan agen off-chain independen untuk menyampaikan header dan bukti kriptografi. ChainLink CCIP akan memanfaatkan jaringan oracle yang ada untuk memantau dan membuktikan transaksi lintas rantai.

1. Tantangan:

• Asumsi kepercayaan dapat dieksploitasi untuk mencuri dana jika mayoritas validator berkolusi, yang memerlukan tindakan pencegahan seperti pemungutan suara kuadrat dan bukti penipuan.
• Finalitas: Solusi AMP berbasis keamanan yang optimis menghadirkan kompleksitas dalam finalitas dan keaktifan karena pengguna dan aplikasi harus menunggu jendela penipuan.

1. Keuntungan:

• Pengoptimalan Sumber Daya: Pendekatan ini biasanya tidak memerlukan banyak sumber daya karena verifikasi biasanya tidak dilakukan secara on-chain
• Ekstensibilitas: Pendekatan ini lebih dapat diperluas karena mekanisme konsensusnya tetap sama untuk semua jenis rantai dan dapat dengan mudah diperluas ke blockchain yang heterogen.

Percayalah pada manusia

1. Asumsi kejujuran mayoritas: Solusi ini mengandalkan implementasi multi-sig di mana banyak entitas memverifikasi dan menandatangani transaksi. Setelah ambang batas minimum tercapai, transaksi dianggap sah. Asumsinya di sini adalah mayoritas entitas tersebut jujur dan jika mayoritas entitas tersebut menandatangani transaksi tertentu, maka asumsi tersebut valid. Satu-satunya hal yang dipertaruhkan di sini adalah reputasi entitas yang berpartisipasi. Contoh: Multichain (Anycall V6), Lubang Cacing. Eksploitasi karena bug kontrak pintar masih mungkin terjadi, terbukti dengan peretasan Wormhole pada awal tahun 2022.
2. Kemandirian: Solusi ini membagi seluruh proses penyampaian pesan menjadi dua bagian dan bergantung pada entitas independen yang berbeda untuk mengelola kedua proses tersebut. Asumsinya di sini adalah kedua entitas tersebut independen satu sama lain dan tidak berkolusi. Contoh: LayerZero. Header blok dialirkan sesuai permintaan oleh oracle terdesentralisasi dan bukti transaksi dikirim melalui relayer. Jika buktinya sesuai dengan header maka transaksi dianggap sah. Meskipun pencocokan bukti bergantung pada kode/matematika, peserta diharuskan memercayai entitas tersebut untuk tetap independen. Aplikasi yang dibangun di LayerZero memiliki opsi untuk memilih Oracle dan Relayer mereka (atau menghosting Oracle/Relayer mereka sendiri), sehingga membatasi risiko kolusi individu Oracle/relayer. Pengguna akhir harus percaya bahwa LayerZero, pihak ketiga, atau aplikasi itu sendiri menjalankan oracle dan relayer secara independen dan tanpa niat jahat.

Dalam kedua pendekatan tersebut, reputasi entitas pihak ketiga yang berpartisipasi akan mendisinsentifkan perilaku jahat. Mereka biasanya merupakan entitas yang dihormati dalam komunitas validator dan oracle dan mereka berisiko terkena konsekuensi reputasi dan dampak negatif pada aktivitas bisnis mereka yang lain jika mereka bertindak jahat.

Melampaui asumsi kepercayaan dan masa depan interoperabilitas

Saat mempertimbangkan keamanan dan kegunaan solusi AMP, kita juga perlu mempertimbangkan detail di luar mekanisme dasar. Karena ini adalah bagian bergerak yang dapat berubah seiring waktu, kami tidak memasukkannya ke dalam perbandingan keseluruhan.

• Integritas kode: Sejumlah peretasan di masa lalu telah memanfaatkan bug dalam kode sehingga memerlukan audit yang andal, bug bounty yang terencana, dan implementasi banyak klien. Jika semua validator (dalam keamanan ekonomi/optimis/reputasi) menjalankan klien yang sama (perangkat lunak untuk verifikasi), hal ini meningkatkan ketergantungan pada satu basis kode dan mengurangi keragaman klien. Ethereum, misalnya, bergantung pada beberapa klien eksekusi seperti geth, nethermind, erigon, besu, akula. Implementasi ganda dalam berbagai bahasa cenderung meningkatkan keragaman tanpa ada klien yang mendominasi jaringan, sehingga menghilangkan potensi satu titik kegagalan. Memiliki banyak klien juga dapat membantu keaktifan jika sebagian kecil validator/penandatangan/klien ringan mengalami gangguan karena eksploitasi/bug dalam satu implementasi tertentu.
• Penyiapan dan Peningkatan: Pengguna dan pengembang perlu menyadari jika validator/pengamat dapat bergabung dengan jaringan tanpa izin, jika tidak, kepercayaan akan disembunyikan oleh pemilihan entitas yang diberi izin. Peningkatan ke kontrak pintar juga dapat menimbulkan bug yang dapat menyebabkan eksploitasi atau bahkan berpotensi mengubah asumsi kepercayaan. Solusi yang berbeda dapat diterapkan untuk memitigasi risiko ini. Misalnya, dalam contoh saat ini, gateway Axelar dapat diupgrade dan harus mendapat persetujuan dari komite offline (ambang batas 4/8), namun, dalam waktu dekat, Axelar berencana mewajibkan semua validator untuk secara kolektif menyetujui setiap upgrade pada gateway. Kontrak inti Wormhole dapat ditingkatkan dan dikelola melalui sistem tata kelola on-chain Wormhole. LayerZero mengandalkan kontrak pintar yang tidak dapat diubah dan perpustakaan yang tidak dapat diubah untuk menghindari peningkatan apa pun, namun, LayerZero dapat mendorong perpustakaan baru, dan dapps dengan pengaturan default akan mendapatkan versi yang diperbarui, dan dapps dengan versi yang disetel secara manual perlu menyetelnya ke yang baru satu .
• MEV: Blockchain yang berbeda tidak disinkronkan melalui jam yang sama dan memiliki waktu penyelesaian yang berbeda. Akibatnya, urutan dan waktu eksekusi pada rantai tujuan dapat bervariasi antar rantai. MEV di dunia lintas rantai sulit untuk didefinisikan dengan jelas. Ini memperkenalkan trade-off antara keaktifan dan urutan eksekusi. Saluran yang dipesan akan memastikan pengiriman pesan yang dipesan tetapi saluran akan ditutup jika satu pesan habis. Aplikasi lain mungkin lebih memilih skenario di mana pemesanan tidak diperlukan namun pengiriman pesan lain tidak terpengaruh.

Tren dan prospek masa depan:

• Keamanan yang dapat disesuaikan dan tambahan: Untuk melayani beragam kasus penggunaan dengan lebih baik, solusi AMP diberi insentif untuk menawarkan lebih banyak fleksibilitas kepada pengembang. Axelar memperkenalkan pendekatan untuk meningkatkan kemampuan penyampaian pesan dan verifikasi, tanpa perubahan apa pun pada logika lapisan aplikasi. HyperLane V2 memperkenalkan modul yang memungkinkan pengembang memilih dari berbagai pilihan seperti keamanan ekonomi, keamanan optimis, keamanan dinamis, dan keamanan hybrid. CelerIM menawarkan keamanan tambahan yang optimis serta keamanan ekonomi. Banyak solusi menunggu jumlah minimum konfirmasi blok yang telah ditentukan sebelumnya pada rantai sumber sebelum mengirimkan pesan. LayerZero memungkinkan pengembang memperbarui parameter ini. Kami memperkirakan beberapa solusi AMP akan terus menawarkan lebih banyak fleksibilitas, namun pilihan desain ini memerlukan beberapa diskusi. Haruskah aplikasi dapat mengonfigurasi keamanannya, sejauh mana, dan apa yang terjadi jika aplikasi mengadopsi arsitektur desain di bawah standar? Kesadaran pengguna akan konsep dasar di balik keamanan mungkin menjadi semakin penting. Pada akhirnya, kami memperkirakan agregasi dan abstraksi solusi AMP, mungkin dalam beberapa bentuk kombinasi atau keamanan “tambahan”.
• Pertumbuhan dan pematangan mekanisme “Trust code/math”: Dalam permainan akhir yang ideal, semua pesan lintas rantai akan diminimalkan kepercayaannya dengan menggunakan bukti nol pengetahuan (ZK) untuk memverifikasi pesan dan status. Kita telah menyaksikan perubahan ini dengan munculnya proyek seperti Polymer Labs dan Succinct Labs. Multichain juga baru-baru ini menerbitkan whitepaper zkRouter untuk memungkinkan interoperabilitas melalui bukti ZK. Dengan Mesin Virtual Axelar yang baru-baru ini diumumkan , pengembang dapat memanfaatkan Interchain Amplifier untuk menyiapkan koneksi baru ke jaringan Axelar tanpa izin. Misalnya, setelah klien ringan & bukti ZK yang kuat untuk status Ethereum dikembangkan, pengembang dapat dengan mudah mengintegrasikannya ke dalam jaringan Axelar untuk menggantikan atau meningkatkan koneksi yang sudah ada. LayerZero dalam dokumentasinya berbicara tentang kemungkinan menambahkan perpustakaan pesan bukti baru yang dioptimalkan di masa depan. Proyek baru seperti Lagrange sedang menjajaki agregasi beberapa bukti dari berbagai rantai sumber dan Herodotus membuat bukti penyimpanan dapat dilakukan melalui bukti ZK. Namun, transisi ini akan memakan waktu karena pendekatan ini sulit untuk diterapkan di antara blockchain yang bergantung pada mekanisme dan kerangka konsensus yang berbeda. ZK adalah teknologi yang relatif baru dan kompleks yang sulit untuk diaudit, dan, saat ini, verifikasi dan pembuatan bukti tidak optimal dari segi biaya. Kami percaya bahwa dalam jangka panjang, untuk mendukung aplikasi lintas rantai yang sangat skalabel di blockchain, banyak solusi AMP yang cenderung melengkapi manusia dan entitas tepercaya dengan perangkat lunak yang dapat diverifikasi karena:
• Kemungkinan eksploitasi kode dapat diminimalkan melalui audit dan bug bounty. Seiring berjalannya waktu, sistem ini akan lebih mudah dipercaya karena sejarahnya akan menjadi bukti keamanannya.
• Biaya pembuatan bukti ZK akan berkurang. Dengan lebih banyak penelitian dan pengembangan di ZKP, ZK rekursif, agregasi bukti, dan perangkat keras khusus, kami memperkirakan waktu dan biaya pembuatan bukti dan verifikasi akan berkurang secara signifikan, menjadikannya pendekatan yang lebih hemat biaya.
• Blockchain akan menjadi lebih ramah terhadap zk. Di masa depan, zkEVM akan dapat memberikan bukti validitas eksekusi yang ringkas, dan solusi ringan berbasis klien akan dapat dengan mudah memverifikasi eksekusi dan konsensus rantai sumber pada rantai tujuan. Di akhir permainan Ethereum, ada juga rencana untuk “zk-SNARK everything” termasuk konsensus.
• Bukti kemanusiaan/reputasi/identitas: Keamanan sistem kompleks seperti solusi AMP tidak dapat diringkas melalui satu kerangka kerja dan memerlukan solusi berlapis. Misalnya, bersama dengan insentif ekonomi, Axelar telah menerapkan pemungutan suara kuadrat untuk mencegah pemusatan hak suara di antara beberapa simpul dan mendorong desentralisasi. Bukti lain mengenai kemanusiaan, reputasi, dan identitas juga dapat melengkapi mekanisme pengaturan dan izin.

Dalam semangat keterbukaan Web3, kita mungkin akan melihat masa depan yang majemuk di mana berbagai pendekatan hidup berdampingan. Faktanya, aplikasi dapat memilih untuk menggunakan beberapa solusi interoperabilitas, baik dengan cara yang berlebihan, atau membiarkan pengguna mencampur dan mencocokkan dengan pengungkapan trade-off. Solusi titik-ke-titik mungkin diprioritaskan di antara rute-rute yang “lalu lintasnya padat”, sedangkan model hub dan ruji mungkin mendominasi rute-rute yang panjang. Pada akhirnya, terserah pada kita, para demo kolektif dan pengguna, pembangun, dan kontributor, untuk membentuk topografi web3 yang saling berhubungan.

Kami ingin mengucapkan terima kasih kepada Bo Du dan Peter Kim dari Polymer Labs, Galen Moore dari Axelar Network, Uma Roy dari Succinct Labs, Max Glassman, dan Ryan Zarick dari LayerZero karena telah meninjau dan memberikan masukan berharga mereka.

Daftar referensi:

• Axelar: https://docs.axelar.dev/
• CelerIM: https://im-docs.celer.network/developer/celer-im-overview
• CCIP ChainLink: https://blog.chain.link/introducing-the-cross-chain-interoperability-protocol-ccip/
• jembatan gantung: https://docs.debridge.finance/
• IBC: https://tutorials.cosmos.network/academy/3-ibc/
• LayerZero: https://layerzero.gitbook.io/docs/
• Multirantai: https://docs.multichain.org/getting-started/introduction
• Pengembara: https://docs.nomad.xyz/nomad-101/introduction
• Lab Polimer: https://polymerlabs.medium.com/
• Lab Ringkas: https://blog.succinct.xyz/
• Lubang Cacing: https://docs.wormhole.com/wormhole/

Daftar bacaan tambahan:

• Menavigasi Jembatan Pesan Sewenang-wenang: Kerangka Perbandingan: https://blog.li.fi/navigating-arbitrary-messaging-bridges-a-comparison-framework-8720f302e2aa
• Kerangka Risiko L2Bridge: https://gov.l2beat.com/t/l2bridge-risk-framework/31
• Horatius di Jembatan: https://maven11.substack.com/p/horatius-at-the-bridge

Penafian:

1. Artikel ini dicetak ulang dari [medium]. Semua hak cipta milik penulis asli [LongHash Ventures]. Jika ada keberatan terhadap cetak ulang ini, silakan menghubungi tim Gate Learn , dan mereka akan segera menanganinya.
2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini adalah sepenuhnya milik penulis dan bukan merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, dilarang menyalin, mendistribusikan, atau menjiplak artikel terjemahan.