Multi-rantai adalah tren pengembangan masa depan, dan pengejaran skalabilitas telah mengarahkan Ethereum ke pembangunan teknologi Rollup. Dalam perpindahan ke blockchain modular, sekali lagi perhatian diberikan kepada Lisk. Dan dalam waktu yang tidak terlalu lama, kami mendengar desas-desus tentang Rollup khusus aplikasi, L3, dan rantai berdaulat. Tapi ini semua harus dibayar dengan biaya fragmentasi, dan jembatan lintas rantai saat ini sering kali terbatas fungsinya dan bergantung pada penanda tepercaya untuk keamanan.
Jadi, seperti apa nantinya Web3 yang terhubung itu? Kami yakin bahwa jembatan lintas rantai pada akhirnya akan berkembang menjadi perpesanan lintas rantai atau protokol "Pesan Sewenang-wenang" (AMP) untuk membuka kunci skenario aplikasi baru, yang memungkinkan aplikasi meneruskan pesan acak antara rantai sumber dan rantai target. Kami juga akan menyaksikan munculnya "lanskap mekanisme kepercayaan", di mana pembangun akan membuat berbagai trade-off antara kegunaan, kompleksitas, dan keamanan.
Setiap solusi AMP perlu mengimplementasikan dua fungsi utama:
Verifikasi: Kemampuan untuk memverifikasi validitas pesan dari rantai sumber pada rantai target
Liveness: kemampuan untuk menyampaikan informasi dari rantai sumber ke rantai target
Sayangnya, verifikasi tanpa kepercayaan 100% tidak realistis, pengguna harus memilih untuk mempercayai kode, teori permainan, manusia (atau entitas), atau kombinasi dari semuanya, bergantung pada apakah verifikasinya on-chain atau off-chain.
Dalam makalah ini, kami secara vertikal membagi domain interoperabilitas keseluruhan menjadi mekanisme berbasis kepercayaan dan arsitektur berbasis integrasi.
Mekanisme kepercayaan:
Kode kepercayaan dan matematika: Untuk solusi ini, ada bukti rantai yang dapat diverifikasi siapa pun. Solusi ini biasanya bergantung pada klien ringan untuk memverifikasi konsensus rantai sumber pada rantai target atau memverifikasi validitas transisi status rantai sumber pada rantai target. Verifikasi melalui klien ringan dapat meningkatkan efisiensi melalui pembuktian tanpa pengetahuan, mengompresi perhitungan panjang yang sewenang-wenang untuk dilakukan secara offline, sambil memberikan verifikasi on-chain sederhana untuk membuktikan hasil perhitungan.
Teori Permainan Kepercayaan: Ketika pengguna/aplikasi perlu mempercayai pihak ketiga atau jaringan pihak ketiga untuk menjamin keaslian transaksi, asumsi kepercayaan tambahan terlibat. Keamanan mekanisme ini dapat ditingkatkan dengan menggunakan jaringan tanpa izin dan teori permainan seperti insentif ekonomi dan keamanan optimis.
Kepercayaan pada manusia: Solusi ini bergantung pada kejujuran atau independensi mayoritas validator, yang mengkomunikasikan informasi berbeda. Selain mempercayai konsensus dari dua rantai interaktif, Anda juga perlu mempercayai pihak ketiga. Dalam hal ini, satu-satunya risiko adalah reputasi entitas yang berpartisipasi. Suatu transaksi dianggap sah jika cukup banyak entitas yang berpartisipasi setuju bahwa itu sah.
Perlu dicatat bahwa semua solusi membutuhkan kepercayaan pada kode dan manusia sampai taraf tertentu. Solusi apa pun dengan kode buggy dapat dieksploitasi oleh peretas, dan setiap solusi memiliki beberapa elemen manusia dalam penyiapan, pemutakhiran, atau pemeliharaan basis kode.
Arsitektur integrasi:
Model peer-to-peer: Saluran komunikasi khusus perlu dibuat antara setiap rantai sumber dan rantai target.
Model hub pusat: Saluran komunikasi dengan hub pusat perlu dibuat untuk mencapai interkoneksi dengan semua blockchain lain yang terhubung ke hub.
Model peer-to-peer relatif sulit untuk diskalakan karena setiap blockchain yang terhubung membutuhkan saluran komunikasi berpasangan. Mengembangkan saluran ini dapat menjadi tantangan bagi blockchain dengan konsensus dan kerangka kerja yang berbeda. Namun, jembatan berpasangan menawarkan lebih banyak fleksibilitas untuk menyesuaikan konfigurasi jika diinginkan. Pendekatan hibrid juga dimungkinkan, seperti perutean multi-hop melalui relai menggunakan protokol Inter-Blockchain Communication (IBC), yang menghilangkan kebutuhan komunikasi peer-to-peer langsung, tetapi memperkenalkan lebih banyak kerumitan dalam hal keamanan, latensi, dan biaya.
Kode Kepercayaan dan Matematika
Untuk hanya mengandalkan kode/matematika untuk asumsi kepercayaan, klien ringan dapat digunakan untuk memverifikasi konsensus rantai sumber pada rantai target. Klien/node ringan adalah perangkat lunak yang terhubung ke node penuh untuk berinteraksi dengan blockchain. Klien ringan pada rantai target biasanya menyimpan riwayat (dalam urutan) header blok rantai sumber, yang cukup untuk memverifikasi transaksi. Proksi off-chain (seperti relai) memantau peristiwa di rantai sumber, menghasilkan bukti inklusi kriptografi, dan meneruskannya bersama dengan header blok untuk menerangi klien di rantai target. Karena klien ringan menyimpan header blok secara berurutan, masing-masing berisi root hash Merkle yang dapat digunakan untuk membuktikan status, mereka dapat memverifikasi transaksi. Berikut adalah ikhtisar fitur utama dari pendekatan ini:
keamanan
Asumsi kepercayaan diperkenalkan selama inisialisasi klien ringan. Saat membuat klien ringan baru, itu akan diinisialisasi ke header blok dari ketinggian tertentu di rantai lain. Namun, ada kemungkinan bahwa header blok yang diberikan mungkin salah, sehingga memungkinkan untuk mengelabui klien ringan dengan header blok yang dipalsukan. Setelah klien ringan diinisialisasi, tidak ada lagi asumsi kepercayaan yang diperkenalkan. Namun, perlu diperhatikan bahwa proses inisialisasi ini bergantung pada asumsi kepercayaan yang lemah, karena dapat diverifikasi oleh siapa saja. Selain itu, ada asumsi keaktifan untuk transmisi informasi yang terus-menerus oleh relai.
penerapan
Implementasi klien ringan bergantung pada ketersediaan primitif kriptografi yang diperlukan untuk autentikasi. Jika jenis rantai yang sama terhubung, artinya mereka berbagi kerangka kerja aplikasi dan algoritme konsensus yang sama, implementasi klien ringan di kedua ujungnya akan sama. Misalnya, semua rantai berbasis Cosmos SDK menggunakan protokol Inter-Blockchain Communication (IBC). Di sisi lain, implementasi seperti klien ringan bergantung pada dukungan untuk primitif kriptografi yang diperlukan untuk autentikasi. Jika jenis rantai yang sama terhubung, yaitu mereka berbagi kerangka kerja aplikasi dan algoritme konsensus yang sama, maka implementasi klien ringan di kedua sisi akan sama. Misalnya, protokol Inter-Blockchain Communication (IBC) digunakan untuk semua rantai berbasis Cosmos SDK. Di sisi lain, jika dua jenis rantai yang berbeda dihubungkan, seperti kerangka kerja aplikasi yang berbeda atau jenis konsensus, implementasi klien ringan akan berbeda. Salah satu contohnya adalah Composable Finance, yang berupaya menghubungkan rantai Cosmos SDK ke kerangka kerja aplikasi Substrat ekosistem Polkadot melalui IBC. Ini membutuhkan klien ringan Tendermint pada rantai Substrat dan klien ringan "gemuk" pada rantai SDK Cosmos. Baru-baru ini, mereka menjalin hubungan pertama antara Polkadot dan Kusama melalui IBC.
tantangan
Intensitas sumber daya merupakan tantangan penting. Menjalankan pasangan klien ringan di semua rantai bisa jadi mahal karena penulisan di blockchain mahal. Selain itu, intensitas sumber daya dengan verifikator dinamis merupakan tantangan penting. Bisa mahal untuk menjalankan klien ringan berpasangan di semua rantai karena menulis di blockchain itu mahal. Selain itu, untuk rantai dengan set validator dinamis (seperti Ethereum), tidak layak menjalankan klien ringan.
Skalabilitas adalah tantangan lain. Implementasi klien ringan bervariasi sesuai dengan arsitektur rantai, yang membuatnya sulit untuk mengukur dan menghubungkan ekosistem yang berbeda.
Kerentanan kode merupakan risiko potensial karena bug dalam kode dapat menyebabkan kerentanan. Misalnya, pelanggaran rantai BNB Oktober 2022 mengungkapkan kelemahan keamanan kritis yang memengaruhi semua rantai yang mendukung IBC.
Untuk mengatasi biaya dan kepraktisan menjalankan klien ringan berpasangan di semua rantai, solusi alternatif seperti bukti tanpa pengetahuan (ZK) dapat digunakan untuk menghilangkan kebutuhan akan kepercayaan pihak ketiga.
Bukti tanpa pengetahuan sebagai solusi untuk kepercayaan pihak ketiga
Bukti tanpa pengetahuan dapat digunakan untuk memverifikasi validitas transisi status rantai sumber pada rantai target. Dibandingkan dengan melakukan seluruh komputasi on-chain, bukti ZK hanya melakukan bagian verifikasi dari komputasi on-chain, sedangkan komputasi aktual terjadi secara off-chain. Pendekatan ini memungkinkan verifikasi yang lebih cepat dan lebih efisien daripada menjalankan kembali komputasi awal. Beberapa contohnya termasuk Polymer ZK-IBC dari Polymer Labs dan Telepati dari Succinct Labs. Polymer sedang mengembangkan IBC multi-hop untuk meningkatkan konektivitas dan mengurangi jumlah koneksi berpasangan yang diperlukan.
Aspek kunci dari mekanisme tersebut meliputi:
keamanan
Keamanan zk-SNARK bergantung pada kurva eliptik, sedangkan zk-STARK mengandalkan fungsi hash. zk-SNARK mungkin memerlukan penyiapan tepercaya, termasuk pembuatan kunci awal yang digunakan untuk menghasilkan bukti yang digunakan dalam verifikasi. Kuncinya adalah menghancurkan rahasia acara penyiapan untuk mencegah transaksi diautentikasi oleh pemalsuan. Setelah penyiapan tepercaya selesai, tidak ada lagi asumsi kepercayaan yang diperkenalkan. Selain itu, kerangka kerja ZK yang lebih baru seperti Halo dan Halo2 sepenuhnya menghilangkan kebutuhan akan penyiapan tepercaya.
penerapan
Ada berbagai skema pembuktian ZK, seperti SNARK, STARK, VPD dan SNARG, dan SNARK saat ini paling banyak digunakan. Kerangka kerja pembuktian SNARK yang berbeda, seperti Groth16, Plonk, Marlin, Halo, dan Halo2, menawarkan pertukaran dalam hal ukuran pembuktian, waktu pembuktian, waktu verifikasi, persyaratan memori, dan persyaratan penyiapan tepercaya. Bukti ZK rekursif juga telah muncul, memungkinkan beban kerja bukti didistribusikan ke banyak komputer daripada satu komputer. Untuk menghasilkan bukti validitas, primitif inti berikut harus diimplementasikan: memverifikasi skema tanda tangan yang digunakan oleh validator, menyimpan bukti kunci publik validator dalam komitmen set validator yang disimpan dalam rantai, dan melacak set validator, yang mungkin sering berubah.
tantangan
Menerapkan berbagai skema tanda tangan di zkSNARK memerlukan penerapan aritmatika di luar domain dan operasi kurva eliptik kompleks, yang tidak sepele dan mungkin memerlukan implementasi yang berbeda tergantung pada kerangka kerja dan konsensus rantai yang berbeda. Mengaudit sirkuit ZK adalah tugas yang menantang dan rawan kesalahan. Pengembang harus terbiasa dengan bahasa khusus domain seperti Circom, Kairo, dan Noir, atau mengimplementasikan sirkuit secara langsung, keduanya dapat menantang dan dapat memperlambat adopsi. Jika waktu dan upaya terbukti sangat tinggi, mungkin hanya ditangani oleh tim khusus dan perangkat keras khusus, yang berpotensi mengarah ke sentralisasi. Waktu pembuatan bukti yang lebih lama juga menyebabkan penundaan. Teknik seperti Incrementally Verifiable Computation (IVC) dapat mengoptimalkan waktu pembuktian, tetapi banyak di antaranya masih dalam tahap penelitian, menunggu implementasi. Waktu verifikasi dan beban kerja yang lebih lama akan meningkatkan biaya on-chain.
Percayai Teori Permainan
Protokol interoperabilitas berdasarkan teori permainan secara luas dapat dibagi menjadi dua kategori, sesuai dengan bagaimana mereka mendorong perilaku jujur oleh entitas yang berpartisipasi:
Kategori pertama adalah mekanisme keamanan ekonomi di mana banyak aktor eksternal (seperti validator) bekerja sama untuk mencapai konsensus guna menentukan status rantai sumber yang diperbarui. Untuk menjadi validator, peserta perlu mempertaruhkan sejumlah token, yang dapat dikurangi jika terjadi aktivitas berbahaya. Dalam pengaturan tanpa izin, siapa pun dapat mengumpulkan saham dan menjadi validator. Selain itu, insentif ekonomi seperti hadiah blok diberikan kepada validator yang mengikuti protokol untuk memastikan insentif ekonomi untuk perilaku jujur. Namun, jika potensi jumlah yang dicuri melebihi jumlah yang dipertaruhkan, peserta dapat berkolusi untuk mencuri dana. Contoh protokol yang menggunakan mekanisme keamanan ekonomis termasuk Axelar dan Celer IM.
Kategori kedua adalah mekanisme keamanan optimis, di mana solusinya bergantung pada asumsi bahwa hanya sejumlah kecil peserta blockchain yang jujur dan mematuhi aturan protokol. Dalam pendekatan ini, peserta yang jujur bertindak sebagai jaminan. Misalnya, solusi optimal memungkinkan siapa saja mengirimkan bukti penipuan. Meskipun ada insentif finansial, seorang pengamat yang jujur bisa melewatkan transaksi penipuan. Rollup Optimis juga menggunakan mekanisme ini. Nomad dan ChainLink CCIP adalah contoh protokol yang menggunakan mekanisme keamanan optimis. Dalam kasus Nomad, pengamat dapat membuktikan penipuan, meskipun mereka masuk daftar putih pada saat penulisan. ChainLink CCIP berencana untuk menggunakan jaringan anti-penipuan yang terdiri dari jaringan oracle terdistribusi untuk mendeteksi aktivitas jahat, meskipun penerapan jaringan anti-penipuan CCIP tidak diketahui.
keamanan
Dalam hal keamanan, kedua mekanisme mengandalkan partisipasi tanpa izin dari pemverifikasi dan pengamat untuk memastikan validitas teori permainan. Dalam mekanisme keamanan ekonomi, dana lebih rentan jika jumlah yang dipertaruhkan lebih rendah dari jumlah yang dapat dicuri. Di sisi lain, dalam mekanisme keamanan yang optimis, asumsi kepercayaan minoritas dapat dieksploitasi jika tidak ada yang mengajukan bukti penipuan, atau jika pengamat izin dikompromikan atau dihilangkan. Sebaliknya, mekanisme keamanan ekonomi kurang bergantung pada kehidupan untuk menjaga keamanan.
penerapan
Dalam hal implementasi, satu pendekatan melibatkan rantai perantara dengan validatornya sendiri. Dalam pengaturan ini, sekelompok validator eksternal memantau rantai sumber dan mencapai konsensus tentang validitas transaksi saat pemanggilan terdeteksi. Setelah konsensus tercapai, mereka memberikan bukti pada rantai target. Validator biasanya diminta untuk mempertaruhkan sejumlah token, yang dapat dikurangi jika aktivitas berbahaya terdeteksi. Contoh protokol yang menggunakan metode implementasi ini antara lain Axelar Network dan Celer IM.
Metode implementasi lainnya melibatkan penggunaan proxy off-chain. Proksi off-chain digunakan untuk mengimplementasikan solusi seperti Rollups yang optimis. Dalam jangka waktu yang telah ditentukan, proxy off-chain ini dapat mengirimkan bukti penipuan dan membalikkan transaksi jika perlu. Misalnya, Nomad mengandalkan proxy off-chain independen untuk menyampaikan header dan bukti kriptografi. Di sisi lain, ChainLink CCIP berencana untuk memanfaatkan jaringan oracle yang ada untuk memantau dan membuktikan transaksi lintas rantai.
Keuntungan dan Tantangan
Keuntungan utama dari solusi AMP teori permainan adalah pengoptimalan sumber daya, karena proses verifikasi biasanya bersifat off-chain, sehingga mengurangi kebutuhan sumber daya. Selain itu, mekanisme ini dapat diskalakan karena mekanisme konsensus tetap sama untuk berbagai jenis rantai dan dapat dengan mudah diperluas ke blockchain yang heterogen.
Ada juga beberapa tantangan yang terkait dengan mekanisme ini. Jika mayoritas validator berkolusi, asumsi kepercayaan dapat dieksploitasi untuk mencuri dana, membutuhkan tindakan pencegahan seperti pemungutan suara kuadrat dan bukti penipuan. Selain itu, solusi berdasarkan keamanan optimis memperkenalkan kerumitan dalam hal finalitas dan keaktifan, karena pengguna dan aplikasi harus menunggu jendela penipuan untuk memastikan validitas transaksi.
Percayai Manusia
Solusi yang membutuhkan kepercayaan pada entitas manusia juga dapat dibagi secara luas menjadi dua kategori:
Keamanan Reputasi: Solusi ini mengandalkan implementasi multi-tanda tangan, di mana banyak entitas memverifikasi dan menandatangani transaksi. Setelah ambang minimum tercapai, transaksi dianggap sah. Asumsinya di sini adalah bahwa sebagian besar entitas jujur, dan jika mayoritas entitas ini menandatangani transaksi tertentu, maka transaksi tersebut sah. Satu-satunya hal yang dipertaruhkan di sini adalah reputasi entitas yang terlibat. Beberapa contohnya termasuk Multichain (Anycall V6) dan Wormhole. Kerentanan masih bisa ada karena kerentanan kontrak pintar, seperti yang ditunjukkan oleh peretasan Wormhole pada awal 2022.
Kemandirian: Solusi ini membagi seluruh proses perpesanan menjadi dua bagian dan bergantung pada entitas independen yang berbeda untuk mengelola kedua proses tersebut. Asumsinya di sini adalah bahwa kedua entitas ini tidak bergantung satu sama lain dan tidak dapat berkolusi. LayerZero adalah contohnya. Header blok ditransmisikan sesuai permintaan melalui oracle yang didistribusikan, dan bukti transaksi dikirim melalui relai. Jika bukti sesuai dengan header, maka transaksi dianggap sah. Sementara membuktikan kecocokan bergantung pada kode/matematika, peserta perlu percaya bahwa entitas ini tetap independen dan tidak memiliki niat jahat. Aplikasi yang dibangun di atas LayerZero dapat memilih oracle dan relay mereka sendiri (atau menghosting oracle/relay mereka sendiri), sehingga membatasi risiko pada oracle/relay individual. Pengguna akhir harus percaya bahwa LayerZero, pihak ketiga, atau aplikasi itu sendiri menjalankan oracle dan relay secara independen, tanpa niat jahat.
Dalam kedua pendekatan tersebut, reputasi entitas pihak ketiga yang berpartisipasi menghalangi perilaku jahat. Ini biasanya adalah entitas yang dihormati di komunitas validator dan oracle, dan jika mereka berperilaku jahat, mereka berisiko merusak reputasi dan dampak negatif pada aktivitas bisnis lainnya.
Pertimbangan Tambahan untuk Solusi AMP
Saat mempertimbangkan keamanan dan kegunaan solusi AMP, kami juga perlu mempertimbangkan detail di luar mekanisme dasar. Karena ini adalah komponen yang dapat berubah seiring waktu, kami tidak memasukkannya ke dalam perbandingan keseluruhan.
Integritas Kode
Peretasan baru-baru ini telah mengeksploitasi kesalahan kode, menyoroti perlunya audit yang kuat, karunia bug, dan implementasi klien yang beragam. Jika semua pemverifikasi (dalam keamanan ekonomi/optimis/reputasi) menjalankan klien yang sama (perangkat lunak untuk verifikasi), ini meningkatkan ketergantungan pada basis kode tunggal dan mengurangi keragaman klien. Misalnya, Ethereum mengandalkan beberapa klien eksekusi seperti geth, netermind, erigon, besu, akula. Berbagai implementasi dalam berbagai bahasa dapat meningkatkan keragaman, dengan tidak ada satu klien pun yang mendominasi jaringan, menghilangkan potensi satu titik kegagalan. Memiliki banyak klien juga dapat membantu menjaga keaktifan jika sejumlah kecil validator/penanda tangan/klien ringan gagal karena bug/serangan dalam implementasi tertentu.
Penyiapan dan Peningkatan Kemampuan
Pengguna dan pengembang perlu mengetahui apakah validator/pengamat dapat bergabung dengan jaringan tanpa izin, jika tidak, kepercayaan akan disembunyikan oleh entitas yang memilih izin. Upgrade ke smart contract juga dapat memperkenalkan kerentanan yang dapat menyebabkan serangan dan bahkan mungkin mengubah asumsi kepercayaan. Solusi yang berbeda dapat diterapkan untuk mengurangi risiko ini. Misalnya, dalam instantiasi saat ini, gateway Axelar dapat ditingkatkan tetapi memerlukan persetujuan dari komite offline (ambang 4/8), namun, dalam waktu dekat Axelar berencana untuk meminta semua validator untuk secara kolektif menyetujui setiap peningkatan ke gateway. Kontrak inti Wormhole dapat ditingkatkan dan dikelola melalui sistem tata kelola rantai Wormhole. LayerZero bergantung pada kontrak pintar yang tidak dapat diubah dan pustaka yang tidak dapat diubah untuk menghindari pemutakhiran apa pun, tetapi pustaka baru dapat didorong, dapp yang menyetel pengaturan default akan mendapatkan versi yang lebih baru, dapp yang menyetel versi secara manual perlu menyetelnya ke versi baru.
Nilai Maksimum yang Dapat Diekstraksi (MEV)
Blockchain yang berbeda tidak disinkronkan oleh jam umum dan memiliki waktu penyelesaian yang berbeda. Oleh karena itu, urutan eksekusi dan waktu pada rantai target dapat bervariasi dari satu rantai ke rantai lainnya. Di dunia lintas rantai, MEV sulit untuk didefinisikan dengan jelas. Ini memperkenalkan tradeoff antara keaktifan dan urutan eksekusi. Saluran yang dipesan akan memastikan pengiriman pesan sesuai urutan, tetapi jika waktu pesan habis, saluran akan ditutup. Aplikasi lain mungkin lebih suka tanpa pemesanan, tetapi pengiriman pesan lain tidak terpengaruh.
Kepastian rantai sumber
Idealnya, solusi AMP harus menunggu rantai sumber mencapai finalitas sebelum mentransmisikan informasi status rantai sumber ke satu atau beberapa rantai target. Ini akan memastikan bahwa blok pada rantai sumber hampir tidak dapat dibalik atau diubah. Namun, banyak solusi menyediakan pengiriman pesan instan dan membuat asumsi kepercayaan tentang finalitas untuk memberikan pengalaman pengguna terbaik. Dalam kasus ini, jika rantai sumber mengalami rollback status setelah pesan dikirimkan dan aset jembatan diteruskan, ini dapat menyebabkan situasi seperti pengeluaran ganda dana jembatan. Solusi AMP dapat mengelola risiko ini dalam beberapa cara, seperti dengan menetapkan asumsi finalitas yang berbeda untuk rantai yang berbeda, bergantung pada seberapa terdesentralisasi rantai tersebut, atau dengan melakukan kompromi antara kecepatan dan keamanan. Jembatan yang memanfaatkan solusi AMP dapat menetapkan batas jumlah aset yang dijembatani sebelum rantai sumber mencapai finalitas.
Tren dan prospek masa depan Keamanan yang dapat disesuaikan dan dipasang
Untuk melayani berbagai kasus penggunaan dengan lebih baik, solusi AMP diberi insentif untuk memberikan lebih banyak fleksibilitas kepada developer. Axelar memperkenalkan metode untuk mengaktifkan skalabilitas perpesanan dan validasi tanpa mengubah logika lapisan aplikasi. HyperLane V2 memperkenalkan modul yang memungkinkan pengembang memilih dari beberapa opsi seperti keamanan ekonomis, keamanan optimis, keamanan dinamis, dan keamanan hibrid. CelerIM memberikan keamanan optimis tambahan selain keamanan ekonomi. Banyak solusi menunggu sejumlah minimum konfirmasi blok yang telah ditentukan sebelumnya pada rantai sumber sebelum mengirim pesan. LayerZero memungkinkan pengembang untuk memperbarui parameter ini. Kami berharap beberapa solusi AMP terus menawarkan lebih banyak fleksibilitas, tetapi pilihan desain ini memerlukan beberapa diskusi. Haruskah aplikasi dapat mengonfigurasi keamanannya, sejauh mana, dan apa yang terjadi jika aplikasi dirancang dengan desain yang kurang optimal? Kesadaran pengguna akan konsep dasar di balik keamanan sepertinya akan menjadi semakin penting. Pada akhirnya, kami memperkirakan agregasi dan abstraksi solusi AMP, kemungkinan dalam bentuk beberapa bentuk komposisi atau keamanan "add-on".
Kematangan mekanisme "kode kepercayaan dan matematika"
Dalam tahap akhir yang ideal, semua pesan lintas rantai akan diminimalkan kepercayaan melalui penggunaan bukti tanpa pengetahuan (ZK). Kami telah melihat proyek serupa seperti Polymer Labs dan Succinct Labs muncul. Multichain juga menerbitkan kertas putih zkRouter tentang interoperabilitas melalui bukti ZK. Dengan Mesin Virtual Axelar yang baru diumumkan, pengembang dapat memanfaatkan Penguat Interchain untuk membangun koneksi baru ke jaringan Axelar tanpa izin. Misalnya, setelah klien ringan yang kuat dan bukti ZK dikembangkan untuk status Ethereum, pengembang dapat dengan mudah mengintegrasikannya ke dalam jaringan Axelar untuk mengganti atau meningkatkan koneksi yang ada. Celer Network mengumumkan Brevis, platform bukti data lintas rantai ZK yang memungkinkan dApps dan kontrak pintar untuk mengakses, menghitung, dan memanfaatkan data sewenang-wenang di beberapa blockchain. Celer mengimplementasikan aset zkBridge yang berorientasi pada pengguna menggunakan sirkuit klien ringan ZK untuk rantai silang antara testnet Ethereum Goerli dan testnet BNB Chain. LayerZero membahas dalam dokumentasinya kemungkinan menambahkan pustaka pesan bukti baru yang dioptimalkan di masa mendatang. Proyek yang lebih baru seperti Lagrange mengeksplorasi pengumpulan banyak bukti dari berbagai rantai sumber, sementara Herodotus memungkinkan penyimpanan bukti dengan bukti ZK. Namun, transisi ini akan memakan waktu, karena pendekatan ini sulit untuk diukur di seluruh blockchain yang bergantung pada mekanisme dan kerangka kerja konsensus yang berbeda.
ZK adalah teknologi yang relatif baru dan kompleks yang sulit untuk diaudit, dan biaya pembuatan bukti dan verifikasi saat ini tidak optimal. Kami percaya bahwa dalam jangka panjang, untuk mendukung aplikasi lintas rantai yang sangat skalabel di blockchain, banyak solusi AMP kemungkinan akan menggabungkan perangkat lunak yang dapat diverifikasi dengan manusia dan entitas tepercaya karena:
Melalui audit dan bug bounty, kemungkinan eksploitasi kode dapat diminimalkan. Seiring waktu, akan lebih mudah untuk mempercayai sistem ini karena riwayatnya menjadi bukti keamanannya.
Biaya pembuatan bukti ZK akan berkurang. Dengan lebih banyak penelitian dan pengembangan pada ZKP, ZKP rekursif, agregasi bukti, skema pelipatan, dan perangkat keras khusus, kami memperkirakan biaya waktu pembuatan bukti dan verifikasi akan berkurang secara substansial, menjadikannya pendekatan yang lebih hemat biaya.
Blockchain akan menjadi lebih mendukung ZK. Di masa mendatang, zkEVM akan dapat memberikan bukti valid validitas eksekusi yang ringkas, dan solusi ringan berbasis klien akan dapat dengan mudah memverifikasi eksekusi dan konsensus rantai sumber. Pada tahap akhir Ethereum, juga direncanakan untuk "zk-SNARK everything", termasuk mekanisme konsensus.
Bukti Manusia, Reputasi dan Identitas
Keamanan sistem yang kompleks seperti solusi AMP tidak dapat dienkapsulasi oleh satu kerangka kerja saja dan membutuhkan solusi berlapis-lapis. Misalnya, selain insentif ekonomi, Axelar menerapkan mekanisme pemungutan suara kuadrat untuk mencegah konsentrasi kekuatan pemungutan suara di antara subset node dan mempromosikan desentralisasi. Bukti, reputasi, dan identitas manusia lainnya juga dapat melengkapi mekanisme penyiapan dan izin.
Kesimpulannya
Dalam semangat terbuka Web3, kita mungkin melihat masa depan yang majemuk di mana berbagai pendekatan hidup berdampingan. Faktanya, sebuah aplikasi dapat memilih untuk menggunakan beberapa solusi interoperabilitas, baik dengan cara yang berlebihan atau bagi pengguna untuk memilih kombinasi berdasarkan trade-off. Di antara rute "lalu lintas tinggi", solusi titik-ke-titik mungkin diprioritaskan, sedangkan model hub-and-spoke mungkin mendominasi rantai ekor panjang. Pada akhirnya, kami, sebagai komunitas pengguna, pembangun, dan kontributor, akan membentuk bentuk dasar Internet Web3.
Lihat Asli
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
Bagaimana interpretasi mendalam dari protokol pesan sewenang-wenang memecahkan masalah kepercayaan interoperabilitas?
Pengarang：Shi Khai Wei，Raghav Agarwal
Kompilasi: Kxp, BlockBeats
Perkenalan
Multi-rantai adalah tren pengembangan masa depan, dan pengejaran skalabilitas telah mengarahkan Ethereum ke pembangunan teknologi Rollup. Dalam perpindahan ke blockchain modular, sekali lagi perhatian diberikan kepada Lisk. Dan dalam waktu yang tidak terlalu lama, kami mendengar desas-desus tentang Rollup khusus aplikasi, L3, dan rantai berdaulat. Tapi ini semua harus dibayar dengan biaya fragmentasi, dan jembatan lintas rantai saat ini sering kali terbatas fungsinya dan bergantung pada penanda tepercaya untuk keamanan.
Jadi, seperti apa nantinya Web3 yang terhubung itu? Kami yakin bahwa jembatan lintas rantai pada akhirnya akan berkembang menjadi perpesanan lintas rantai atau protokol "Pesan Sewenang-wenang" (AMP) untuk membuka kunci skenario aplikasi baru, yang memungkinkan aplikasi meneruskan pesan acak antara rantai sumber dan rantai target. Kami juga akan menyaksikan munculnya "lanskap mekanisme kepercayaan", di mana pembangun akan membuat berbagai trade-off antara kegunaan, kompleksitas, dan keamanan.
Setiap solusi AMP perlu mengimplementasikan dua fungsi utama:
Sayangnya, verifikasi tanpa kepercayaan 100% tidak realistis, pengguna harus memilih untuk mempercayai kode, teori permainan, manusia (atau entitas), atau kombinasi dari semuanya, bergantung pada apakah verifikasinya on-chain atau off-chain.
Dalam makalah ini, kami secara vertikal membagi domain interoperabilitas keseluruhan menjadi mekanisme berbasis kepercayaan dan arsitektur berbasis integrasi.
Mekanisme kepercayaan:
Kode kepercayaan dan matematika: Untuk solusi ini, ada bukti rantai yang dapat diverifikasi siapa pun. Solusi ini biasanya bergantung pada klien ringan untuk memverifikasi konsensus rantai sumber pada rantai target atau memverifikasi validitas transisi status rantai sumber pada rantai target. Verifikasi melalui klien ringan dapat meningkatkan efisiensi melalui pembuktian tanpa pengetahuan, mengompresi perhitungan panjang yang sewenang-wenang untuk dilakukan secara offline, sambil memberikan verifikasi on-chain sederhana untuk membuktikan hasil perhitungan.
Teori Permainan Kepercayaan: Ketika pengguna/aplikasi perlu mempercayai pihak ketiga atau jaringan pihak ketiga untuk menjamin keaslian transaksi, asumsi kepercayaan tambahan terlibat. Keamanan mekanisme ini dapat ditingkatkan dengan menggunakan jaringan tanpa izin dan teori permainan seperti insentif ekonomi dan keamanan optimis.
Kepercayaan pada manusia: Solusi ini bergantung pada kejujuran atau independensi mayoritas validator, yang mengkomunikasikan informasi berbeda. Selain mempercayai konsensus dari dua rantai interaktif, Anda juga perlu mempercayai pihak ketiga. Dalam hal ini, satu-satunya risiko adalah reputasi entitas yang berpartisipasi. Suatu transaksi dianggap sah jika cukup banyak entitas yang berpartisipasi setuju bahwa itu sah.
Perlu dicatat bahwa semua solusi membutuhkan kepercayaan pada kode dan manusia sampai taraf tertentu. Solusi apa pun dengan kode buggy dapat dieksploitasi oleh peretas, dan setiap solusi memiliki beberapa elemen manusia dalam penyiapan, pemutakhiran, atau pemeliharaan basis kode.
Arsitektur integrasi:
Model peer-to-peer: Saluran komunikasi khusus perlu dibuat antara setiap rantai sumber dan rantai target.
Model hub pusat: Saluran komunikasi dengan hub pusat perlu dibuat untuk mencapai interkoneksi dengan semua blockchain lain yang terhubung ke hub.
Model peer-to-peer relatif sulit untuk diskalakan karena setiap blockchain yang terhubung membutuhkan saluran komunikasi berpasangan. Mengembangkan saluran ini dapat menjadi tantangan bagi blockchain dengan konsensus dan kerangka kerja yang berbeda. Namun, jembatan berpasangan menawarkan lebih banyak fleksibilitas untuk menyesuaikan konfigurasi jika diinginkan. Pendekatan hibrid juga dimungkinkan, seperti perutean multi-hop melalui relai menggunakan protokol Inter-Blockchain Communication (IBC), yang menghilangkan kebutuhan komunikasi peer-to-peer langsung, tetapi memperkenalkan lebih banyak kerumitan dalam hal keamanan, latensi, dan biaya.
Kode Kepercayaan dan Matematika
Untuk hanya mengandalkan kode/matematika untuk asumsi kepercayaan, klien ringan dapat digunakan untuk memverifikasi konsensus rantai sumber pada rantai target. Klien/node ringan adalah perangkat lunak yang terhubung ke node penuh untuk berinteraksi dengan blockchain. Klien ringan pada rantai target biasanya menyimpan riwayat (dalam urutan) header blok rantai sumber, yang cukup untuk memverifikasi transaksi. Proksi off-chain (seperti relai) memantau peristiwa di rantai sumber, menghasilkan bukti inklusi kriptografi, dan meneruskannya bersama dengan header blok untuk menerangi klien di rantai target. Karena klien ringan menyimpan header blok secara berurutan, masing-masing berisi root hash Merkle yang dapat digunakan untuk membuktikan status, mereka dapat memverifikasi transaksi. Berikut adalah ikhtisar fitur utama dari pendekatan ini:
keamanan
Asumsi kepercayaan diperkenalkan selama inisialisasi klien ringan. Saat membuat klien ringan baru, itu akan diinisialisasi ke header blok dari ketinggian tertentu di rantai lain. Namun, ada kemungkinan bahwa header blok yang diberikan mungkin salah, sehingga memungkinkan untuk mengelabui klien ringan dengan header blok yang dipalsukan. Setelah klien ringan diinisialisasi, tidak ada lagi asumsi kepercayaan yang diperkenalkan. Namun, perlu diperhatikan bahwa proses inisialisasi ini bergantung pada asumsi kepercayaan yang lemah, karena dapat diverifikasi oleh siapa saja. Selain itu, ada asumsi keaktifan untuk transmisi informasi yang terus-menerus oleh relai.
penerapan
Implementasi klien ringan bergantung pada ketersediaan primitif kriptografi yang diperlukan untuk autentikasi. Jika jenis rantai yang sama terhubung, artinya mereka berbagi kerangka kerja aplikasi dan algoritme konsensus yang sama, implementasi klien ringan di kedua ujungnya akan sama. Misalnya, semua rantai berbasis Cosmos SDK menggunakan protokol Inter-Blockchain Communication (IBC). Di sisi lain, implementasi seperti klien ringan bergantung pada dukungan untuk primitif kriptografi yang diperlukan untuk autentikasi. Jika jenis rantai yang sama terhubung, yaitu mereka berbagi kerangka kerja aplikasi dan algoritme konsensus yang sama, maka implementasi klien ringan di kedua sisi akan sama. Misalnya, protokol Inter-Blockchain Communication (IBC) digunakan untuk semua rantai berbasis Cosmos SDK. Di sisi lain, jika dua jenis rantai yang berbeda dihubungkan, seperti kerangka kerja aplikasi yang berbeda atau jenis konsensus, implementasi klien ringan akan berbeda. Salah satu contohnya adalah Composable Finance, yang berupaya menghubungkan rantai Cosmos SDK ke kerangka kerja aplikasi Substrat ekosistem Polkadot melalui IBC. Ini membutuhkan klien ringan Tendermint pada rantai Substrat dan klien ringan "gemuk" pada rantai SDK Cosmos. Baru-baru ini, mereka menjalin hubungan pertama antara Polkadot dan Kusama melalui IBC.
tantangan
Intensitas sumber daya merupakan tantangan penting. Menjalankan pasangan klien ringan di semua rantai bisa jadi mahal karena penulisan di blockchain mahal. Selain itu, intensitas sumber daya dengan verifikator dinamis merupakan tantangan penting. Bisa mahal untuk menjalankan klien ringan berpasangan di semua rantai karena menulis di blockchain itu mahal. Selain itu, untuk rantai dengan set validator dinamis (seperti Ethereum), tidak layak menjalankan klien ringan.
Skalabilitas adalah tantangan lain. Implementasi klien ringan bervariasi sesuai dengan arsitektur rantai, yang membuatnya sulit untuk mengukur dan menghubungkan ekosistem yang berbeda.
Kerentanan kode merupakan risiko potensial karena bug dalam kode dapat menyebabkan kerentanan. Misalnya, pelanggaran rantai BNB Oktober 2022 mengungkapkan kelemahan keamanan kritis yang memengaruhi semua rantai yang mendukung IBC.
Untuk mengatasi biaya dan kepraktisan menjalankan klien ringan berpasangan di semua rantai, solusi alternatif seperti bukti tanpa pengetahuan (ZK) dapat digunakan untuk menghilangkan kebutuhan akan kepercayaan pihak ketiga.
Bukti tanpa pengetahuan sebagai solusi untuk kepercayaan pihak ketiga
Bukti tanpa pengetahuan dapat digunakan untuk memverifikasi validitas transisi status rantai sumber pada rantai target. Dibandingkan dengan melakukan seluruh komputasi on-chain, bukti ZK hanya melakukan bagian verifikasi dari komputasi on-chain, sedangkan komputasi aktual terjadi secara off-chain. Pendekatan ini memungkinkan verifikasi yang lebih cepat dan lebih efisien daripada menjalankan kembali komputasi awal. Beberapa contohnya termasuk Polymer ZK-IBC dari Polymer Labs dan Telepati dari Succinct Labs. Polymer sedang mengembangkan IBC multi-hop untuk meningkatkan konektivitas dan mengurangi jumlah koneksi berpasangan yang diperlukan.
Aspek kunci dari mekanisme tersebut meliputi:
keamanan
Keamanan zk-SNARK bergantung pada kurva eliptik, sedangkan zk-STARK mengandalkan fungsi hash. zk-SNARK mungkin memerlukan penyiapan tepercaya, termasuk pembuatan kunci awal yang digunakan untuk menghasilkan bukti yang digunakan dalam verifikasi. Kuncinya adalah menghancurkan rahasia acara penyiapan untuk mencegah transaksi diautentikasi oleh pemalsuan. Setelah penyiapan tepercaya selesai, tidak ada lagi asumsi kepercayaan yang diperkenalkan. Selain itu, kerangka kerja ZK yang lebih baru seperti Halo dan Halo2 sepenuhnya menghilangkan kebutuhan akan penyiapan tepercaya.
penerapan
Ada berbagai skema pembuktian ZK, seperti SNARK, STARK, VPD dan SNARG, dan SNARK saat ini paling banyak digunakan. Kerangka kerja pembuktian SNARK yang berbeda, seperti Groth16, Plonk, Marlin, Halo, dan Halo2, menawarkan pertukaran dalam hal ukuran pembuktian, waktu pembuktian, waktu verifikasi, persyaratan memori, dan persyaratan penyiapan tepercaya. Bukti ZK rekursif juga telah muncul, memungkinkan beban kerja bukti didistribusikan ke banyak komputer daripada satu komputer. Untuk menghasilkan bukti validitas, primitif inti berikut harus diimplementasikan: memverifikasi skema tanda tangan yang digunakan oleh validator, menyimpan bukti kunci publik validator dalam komitmen set validator yang disimpan dalam rantai, dan melacak set validator, yang mungkin sering berubah.
tantangan
Menerapkan berbagai skema tanda tangan di zkSNARK memerlukan penerapan aritmatika di luar domain dan operasi kurva eliptik kompleks, yang tidak sepele dan mungkin memerlukan implementasi yang berbeda tergantung pada kerangka kerja dan konsensus rantai yang berbeda. Mengaudit sirkuit ZK adalah tugas yang menantang dan rawan kesalahan. Pengembang harus terbiasa dengan bahasa khusus domain seperti Circom, Kairo, dan Noir, atau mengimplementasikan sirkuit secara langsung, keduanya dapat menantang dan dapat memperlambat adopsi. Jika waktu dan upaya terbukti sangat tinggi, mungkin hanya ditangani oleh tim khusus dan perangkat keras khusus, yang berpotensi mengarah ke sentralisasi. Waktu pembuatan bukti yang lebih lama juga menyebabkan penundaan. Teknik seperti Incrementally Verifiable Computation (IVC) dapat mengoptimalkan waktu pembuktian, tetapi banyak di antaranya masih dalam tahap penelitian, menunggu implementasi. Waktu verifikasi dan beban kerja yang lebih lama akan meningkatkan biaya on-chain.
Percayai Teori Permainan
Protokol interoperabilitas berdasarkan teori permainan secara luas dapat dibagi menjadi dua kategori, sesuai dengan bagaimana mereka mendorong perilaku jujur oleh entitas yang berpartisipasi:
Kategori pertama adalah mekanisme keamanan ekonomi di mana banyak aktor eksternal (seperti validator) bekerja sama untuk mencapai konsensus guna menentukan status rantai sumber yang diperbarui. Untuk menjadi validator, peserta perlu mempertaruhkan sejumlah token, yang dapat dikurangi jika terjadi aktivitas berbahaya. Dalam pengaturan tanpa izin, siapa pun dapat mengumpulkan saham dan menjadi validator. Selain itu, insentif ekonomi seperti hadiah blok diberikan kepada validator yang mengikuti protokol untuk memastikan insentif ekonomi untuk perilaku jujur. Namun, jika potensi jumlah yang dicuri melebihi jumlah yang dipertaruhkan, peserta dapat berkolusi untuk mencuri dana. Contoh protokol yang menggunakan mekanisme keamanan ekonomis termasuk Axelar dan Celer IM.
Kategori kedua adalah mekanisme keamanan optimis, di mana solusinya bergantung pada asumsi bahwa hanya sejumlah kecil peserta blockchain yang jujur dan mematuhi aturan protokol. Dalam pendekatan ini, peserta yang jujur bertindak sebagai jaminan. Misalnya, solusi optimal memungkinkan siapa saja mengirimkan bukti penipuan. Meskipun ada insentif finansial, seorang pengamat yang jujur bisa melewatkan transaksi penipuan. Rollup Optimis juga menggunakan mekanisme ini. Nomad dan ChainLink CCIP adalah contoh protokol yang menggunakan mekanisme keamanan optimis. Dalam kasus Nomad, pengamat dapat membuktikan penipuan, meskipun mereka masuk daftar putih pada saat penulisan. ChainLink CCIP berencana untuk menggunakan jaringan anti-penipuan yang terdiri dari jaringan oracle terdistribusi untuk mendeteksi aktivitas jahat, meskipun penerapan jaringan anti-penipuan CCIP tidak diketahui.
keamanan
Dalam hal keamanan, kedua mekanisme mengandalkan partisipasi tanpa izin dari pemverifikasi dan pengamat untuk memastikan validitas teori permainan. Dalam mekanisme keamanan ekonomi, dana lebih rentan jika jumlah yang dipertaruhkan lebih rendah dari jumlah yang dapat dicuri. Di sisi lain, dalam mekanisme keamanan yang optimis, asumsi kepercayaan minoritas dapat dieksploitasi jika tidak ada yang mengajukan bukti penipuan, atau jika pengamat izin dikompromikan atau dihilangkan. Sebaliknya, mekanisme keamanan ekonomi kurang bergantung pada kehidupan untuk menjaga keamanan.
penerapan
Dalam hal implementasi, satu pendekatan melibatkan rantai perantara dengan validatornya sendiri. Dalam pengaturan ini, sekelompok validator eksternal memantau rantai sumber dan mencapai konsensus tentang validitas transaksi saat pemanggilan terdeteksi. Setelah konsensus tercapai, mereka memberikan bukti pada rantai target. Validator biasanya diminta untuk mempertaruhkan sejumlah token, yang dapat dikurangi jika aktivitas berbahaya terdeteksi. Contoh protokol yang menggunakan metode implementasi ini antara lain Axelar Network dan Celer IM.
Metode implementasi lainnya melibatkan penggunaan proxy off-chain. Proksi off-chain digunakan untuk mengimplementasikan solusi seperti Rollups yang optimis. Dalam jangka waktu yang telah ditentukan, proxy off-chain ini dapat mengirimkan bukti penipuan dan membalikkan transaksi jika perlu. Misalnya, Nomad mengandalkan proxy off-chain independen untuk menyampaikan header dan bukti kriptografi. Di sisi lain, ChainLink CCIP berencana untuk memanfaatkan jaringan oracle yang ada untuk memantau dan membuktikan transaksi lintas rantai.
Keuntungan dan Tantangan
Keuntungan utama dari solusi AMP teori permainan adalah pengoptimalan sumber daya, karena proses verifikasi biasanya bersifat off-chain, sehingga mengurangi kebutuhan sumber daya. Selain itu, mekanisme ini dapat diskalakan karena mekanisme konsensus tetap sama untuk berbagai jenis rantai dan dapat dengan mudah diperluas ke blockchain yang heterogen.
Ada juga beberapa tantangan yang terkait dengan mekanisme ini. Jika mayoritas validator berkolusi, asumsi kepercayaan dapat dieksploitasi untuk mencuri dana, membutuhkan tindakan pencegahan seperti pemungutan suara kuadrat dan bukti penipuan. Selain itu, solusi berdasarkan keamanan optimis memperkenalkan kerumitan dalam hal finalitas dan keaktifan, karena pengguna dan aplikasi harus menunggu jendela penipuan untuk memastikan validitas transaksi.
Percayai Manusia
Solusi yang membutuhkan kepercayaan pada entitas manusia juga dapat dibagi secara luas menjadi dua kategori:
Keamanan Reputasi: Solusi ini mengandalkan implementasi multi-tanda tangan, di mana banyak entitas memverifikasi dan menandatangani transaksi. Setelah ambang minimum tercapai, transaksi dianggap sah. Asumsinya di sini adalah bahwa sebagian besar entitas jujur, dan jika mayoritas entitas ini menandatangani transaksi tertentu, maka transaksi tersebut sah. Satu-satunya hal yang dipertaruhkan di sini adalah reputasi entitas yang terlibat. Beberapa contohnya termasuk Multichain (Anycall V6) dan Wormhole. Kerentanan masih bisa ada karena kerentanan kontrak pintar, seperti yang ditunjukkan oleh peretasan Wormhole pada awal 2022.
Kemandirian: Solusi ini membagi seluruh proses perpesanan menjadi dua bagian dan bergantung pada entitas independen yang berbeda untuk mengelola kedua proses tersebut. Asumsinya di sini adalah bahwa kedua entitas ini tidak bergantung satu sama lain dan tidak dapat berkolusi. LayerZero adalah contohnya. Header blok ditransmisikan sesuai permintaan melalui oracle yang didistribusikan, dan bukti transaksi dikirim melalui relai. Jika bukti sesuai dengan header, maka transaksi dianggap sah. Sementara membuktikan kecocokan bergantung pada kode/matematika, peserta perlu percaya bahwa entitas ini tetap independen dan tidak memiliki niat jahat. Aplikasi yang dibangun di atas LayerZero dapat memilih oracle dan relay mereka sendiri (atau menghosting oracle/relay mereka sendiri), sehingga membatasi risiko pada oracle/relay individual. Pengguna akhir harus percaya bahwa LayerZero, pihak ketiga, atau aplikasi itu sendiri menjalankan oracle dan relay secara independen, tanpa niat jahat.
Dalam kedua pendekatan tersebut, reputasi entitas pihak ketiga yang berpartisipasi menghalangi perilaku jahat. Ini biasanya adalah entitas yang dihormati di komunitas validator dan oracle, dan jika mereka berperilaku jahat, mereka berisiko merusak reputasi dan dampak negatif pada aktivitas bisnis lainnya.
Pertimbangan Tambahan untuk Solusi AMP
Saat mempertimbangkan keamanan dan kegunaan solusi AMP, kami juga perlu mempertimbangkan detail di luar mekanisme dasar. Karena ini adalah komponen yang dapat berubah seiring waktu, kami tidak memasukkannya ke dalam perbandingan keseluruhan.
Integritas Kode
Peretasan baru-baru ini telah mengeksploitasi kesalahan kode, menyoroti perlunya audit yang kuat, karunia bug, dan implementasi klien yang beragam. Jika semua pemverifikasi (dalam keamanan ekonomi/optimis/reputasi) menjalankan klien yang sama (perangkat lunak untuk verifikasi), ini meningkatkan ketergantungan pada basis kode tunggal dan mengurangi keragaman klien. Misalnya, Ethereum mengandalkan beberapa klien eksekusi seperti geth, netermind, erigon, besu, akula. Berbagai implementasi dalam berbagai bahasa dapat meningkatkan keragaman, dengan tidak ada satu klien pun yang mendominasi jaringan, menghilangkan potensi satu titik kegagalan. Memiliki banyak klien juga dapat membantu menjaga keaktifan jika sejumlah kecil validator/penanda tangan/klien ringan gagal karena bug/serangan dalam implementasi tertentu.
Penyiapan dan Peningkatan Kemampuan
Pengguna dan pengembang perlu mengetahui apakah validator/pengamat dapat bergabung dengan jaringan tanpa izin, jika tidak, kepercayaan akan disembunyikan oleh entitas yang memilih izin. Upgrade ke smart contract juga dapat memperkenalkan kerentanan yang dapat menyebabkan serangan dan bahkan mungkin mengubah asumsi kepercayaan. Solusi yang berbeda dapat diterapkan untuk mengurangi risiko ini. Misalnya, dalam instantiasi saat ini, gateway Axelar dapat ditingkatkan tetapi memerlukan persetujuan dari komite offline (ambang 4/8), namun, dalam waktu dekat Axelar berencana untuk meminta semua validator untuk secara kolektif menyetujui setiap peningkatan ke gateway. Kontrak inti Wormhole dapat ditingkatkan dan dikelola melalui sistem tata kelola rantai Wormhole. LayerZero bergantung pada kontrak pintar yang tidak dapat diubah dan pustaka yang tidak dapat diubah untuk menghindari pemutakhiran apa pun, tetapi pustaka baru dapat didorong, dapp yang menyetel pengaturan default akan mendapatkan versi yang lebih baru, dapp yang menyetel versi secara manual perlu menyetelnya ke versi baru.
Nilai Maksimum yang Dapat Diekstraksi (MEV)
Blockchain yang berbeda tidak disinkronkan oleh jam umum dan memiliki waktu penyelesaian yang berbeda. Oleh karena itu, urutan eksekusi dan waktu pada rantai target dapat bervariasi dari satu rantai ke rantai lainnya. Di dunia lintas rantai, MEV sulit untuk didefinisikan dengan jelas. Ini memperkenalkan tradeoff antara keaktifan dan urutan eksekusi. Saluran yang dipesan akan memastikan pengiriman pesan sesuai urutan, tetapi jika waktu pesan habis, saluran akan ditutup. Aplikasi lain mungkin lebih suka tanpa pemesanan, tetapi pengiriman pesan lain tidak terpengaruh.
Kepastian rantai sumber
Idealnya, solusi AMP harus menunggu rantai sumber mencapai finalitas sebelum mentransmisikan informasi status rantai sumber ke satu atau beberapa rantai target. Ini akan memastikan bahwa blok pada rantai sumber hampir tidak dapat dibalik atau diubah. Namun, banyak solusi menyediakan pengiriman pesan instan dan membuat asumsi kepercayaan tentang finalitas untuk memberikan pengalaman pengguna terbaik. Dalam kasus ini, jika rantai sumber mengalami rollback status setelah pesan dikirimkan dan aset jembatan diteruskan, ini dapat menyebabkan situasi seperti pengeluaran ganda dana jembatan. Solusi AMP dapat mengelola risiko ini dalam beberapa cara, seperti dengan menetapkan asumsi finalitas yang berbeda untuk rantai yang berbeda, bergantung pada seberapa terdesentralisasi rantai tersebut, atau dengan melakukan kompromi antara kecepatan dan keamanan. Jembatan yang memanfaatkan solusi AMP dapat menetapkan batas jumlah aset yang dijembatani sebelum rantai sumber mencapai finalitas.
Tren dan prospek masa depan Keamanan yang dapat disesuaikan dan dipasang
Untuk melayani berbagai kasus penggunaan dengan lebih baik, solusi AMP diberi insentif untuk memberikan lebih banyak fleksibilitas kepada developer. Axelar memperkenalkan metode untuk mengaktifkan skalabilitas perpesanan dan validasi tanpa mengubah logika lapisan aplikasi. HyperLane V2 memperkenalkan modul yang memungkinkan pengembang memilih dari beberapa opsi seperti keamanan ekonomis, keamanan optimis, keamanan dinamis, dan keamanan hibrid. CelerIM memberikan keamanan optimis tambahan selain keamanan ekonomi. Banyak solusi menunggu sejumlah minimum konfirmasi blok yang telah ditentukan sebelumnya pada rantai sumber sebelum mengirim pesan. LayerZero memungkinkan pengembang untuk memperbarui parameter ini. Kami berharap beberapa solusi AMP terus menawarkan lebih banyak fleksibilitas, tetapi pilihan desain ini memerlukan beberapa diskusi. Haruskah aplikasi dapat mengonfigurasi keamanannya, sejauh mana, dan apa yang terjadi jika aplikasi dirancang dengan desain yang kurang optimal? Kesadaran pengguna akan konsep dasar di balik keamanan sepertinya akan menjadi semakin penting. Pada akhirnya, kami memperkirakan agregasi dan abstraksi solusi AMP, kemungkinan dalam bentuk beberapa bentuk komposisi atau keamanan "add-on".
Kematangan mekanisme "kode kepercayaan dan matematika"
Dalam tahap akhir yang ideal, semua pesan lintas rantai akan diminimalkan kepercayaan melalui penggunaan bukti tanpa pengetahuan (ZK). Kami telah melihat proyek serupa seperti Polymer Labs dan Succinct Labs muncul. Multichain juga menerbitkan kertas putih zkRouter tentang interoperabilitas melalui bukti ZK. Dengan Mesin Virtual Axelar yang baru diumumkan, pengembang dapat memanfaatkan Penguat Interchain untuk membangun koneksi baru ke jaringan Axelar tanpa izin. Misalnya, setelah klien ringan yang kuat dan bukti ZK dikembangkan untuk status Ethereum, pengembang dapat dengan mudah mengintegrasikannya ke dalam jaringan Axelar untuk mengganti atau meningkatkan koneksi yang ada. Celer Network mengumumkan Brevis, platform bukti data lintas rantai ZK yang memungkinkan dApps dan kontrak pintar untuk mengakses, menghitung, dan memanfaatkan data sewenang-wenang di beberapa blockchain. Celer mengimplementasikan aset zkBridge yang berorientasi pada pengguna menggunakan sirkuit klien ringan ZK untuk rantai silang antara testnet Ethereum Goerli dan testnet BNB Chain. LayerZero membahas dalam dokumentasinya kemungkinan menambahkan pustaka pesan bukti baru yang dioptimalkan di masa mendatang. Proyek yang lebih baru seperti Lagrange mengeksplorasi pengumpulan banyak bukti dari berbagai rantai sumber, sementara Herodotus memungkinkan penyimpanan bukti dengan bukti ZK. Namun, transisi ini akan memakan waktu, karena pendekatan ini sulit untuk diukur di seluruh blockchain yang bergantung pada mekanisme dan kerangka kerja konsensus yang berbeda.
ZK adalah teknologi yang relatif baru dan kompleks yang sulit untuk diaudit, dan biaya pembuatan bukti dan verifikasi saat ini tidak optimal. Kami percaya bahwa dalam jangka panjang, untuk mendukung aplikasi lintas rantai yang sangat skalabel di blockchain, banyak solusi AMP kemungkinan akan menggabungkan perangkat lunak yang dapat diverifikasi dengan manusia dan entitas tepercaya karena:
Melalui audit dan bug bounty, kemungkinan eksploitasi kode dapat diminimalkan. Seiring waktu, akan lebih mudah untuk mempercayai sistem ini karena riwayatnya menjadi bukti keamanannya.
Biaya pembuatan bukti ZK akan berkurang. Dengan lebih banyak penelitian dan pengembangan pada ZKP, ZKP rekursif, agregasi bukti, skema pelipatan, dan perangkat keras khusus, kami memperkirakan biaya waktu pembuatan bukti dan verifikasi akan berkurang secara substansial, menjadikannya pendekatan yang lebih hemat biaya.
Blockchain akan menjadi lebih mendukung ZK. Di masa mendatang, zkEVM akan dapat memberikan bukti valid validitas eksekusi yang ringkas, dan solusi ringan berbasis klien akan dapat dengan mudah memverifikasi eksekusi dan konsensus rantai sumber. Pada tahap akhir Ethereum, juga direncanakan untuk "zk-SNARK everything", termasuk mekanisme konsensus.
Bukti Manusia, Reputasi dan Identitas
Keamanan sistem yang kompleks seperti solusi AMP tidak dapat dienkapsulasi oleh satu kerangka kerja saja dan membutuhkan solusi berlapis-lapis. Misalnya, selain insentif ekonomi, Axelar menerapkan mekanisme pemungutan suara kuadrat untuk mencegah konsentrasi kekuatan pemungutan suara di antara subset node dan mempromosikan desentralisasi. Bukti, reputasi, dan identitas manusia lainnya juga dapat melengkapi mekanisme penyiapan dan izin.
Kesimpulannya
Dalam semangat terbuka Web3, kita mungkin melihat masa depan yang majemuk di mana berbagai pendekatan hidup berdampingan. Faktanya, sebuah aplikasi dapat memilih untuk menggunakan beberapa solusi interoperabilitas, baik dengan cara yang berlebihan atau bagi pengguna untuk memilih kombinasi berdasarkan trade-off. Di antara rute "lalu lintas tinggi", solusi titik-ke-titik mungkin diprioritaskan, sedangkan model hub-and-spoke mungkin mendominasi rantai ekor panjang. Pada akhirnya, kami, sebagai komunitas pengguna, pembangun, dan kontributor, akan membentuk bentuk dasar Internet Web3.