Blockchain yang berbeda perlu memiliki cara untuk berkomunikasi sehingga pengguna dapat berinteraksi dengan data dan aset di beberapa blockchain dengan mudah dan oleh karena itu protokol Komunikasi Antar-Blockchain (IBC) didirikan untuk berfungsi sebagai lapisan transportasi antara blockchain. Ekosistem Cosmos mengadopsi IBC terlebih dahulu, tetapi karena itu adalah protokol yang dapat digeneralisasikan, IBC telah ditemukan di banyak ekosistem lainnya.

ICS-02 menguraikan persyaratan konstruksi klien ringan, termasuk bagaimana IBC mengelola data klien ringan. Klien diperlukan agar IBC dapat berfungsi, yang merupakan algoritma verifikasi sembarangan untuk membuktikan informasi on-chain, yang biasanya dienkripsi dalam format IBC, dari satu tempat ke tempat lain.

Dari perspektif IBC, setiap rantai biasanya diidentifikasi oleh kliennya yang ringan. Verifikasi yang paling umum terjadi antara dua mesin keadaan yang berkomunikasi; menggunakan klien yang ringan, rantai sumber dapat memverifikasi pembaruan dari rantai tujuan tanpa mengunduh seluruh datanya. Karena klien yang ringan adalah alat yang serbaguna, mereka dapat menggunakan metode-metode berbeda untuk melakukan verifikasi keadaan.

Verifikasi Bukti Konsensus

Catatan Tentang Algoritma Konsensus

Konsensus Blockchain memastikan bahwa semua node yang berpartisipasi dalam jaringan sinkron. Menggunakan verifikasi konsensus, klien ringan membuktikan bahwa cukup banyak validator yang menandatangani header. Jenis verifikasi ini adalah penggunaan IBC yang paling populer.

Algoritma konsensus umumnya bervariasi dalam peraturan mereka dan apa yang mereka prioritaskan. Namun, perbedaan dalam dua algoritma konsensus yang berbeda mungkin membuatnya sulit bagi rantai untuk berkomunikasi melalui IBC. Misalnya, rantai Cosmos menggunakan algoritma konsensus Tendermint yang memiliki finalitas slot tunggal, juga dikenal sebagai finalitas cepat. Di sisi lain, konsensus Ethereum tidak memiliki finalitas slot tunggal dan oleh karena itu finalitas yang lebih lambat karena itu memprioritaskan kelangsungan hidup daripada keamanan sedangkan IBC paling kompatibel dengan algoritma konsensus yang mengutamakan keamanan. Karena perbedaan dalam kapan blok dianggap 'final', ada kesulitan dalam bagaimana kedua rantai dapat mengirim dan memverifikasi blok antara satu sama lain.

Dalam kasus seperti itu, klien ringan virtual dapat diimplementasikan yang dapat melihat ke dalam klien ringan pada tinggi blok tertentu sebelum finalitas tercapai. Awalnya IBC berfokus pada adopsinya di dalam rantai yang berbasis Tendermint, yang terlihat dalam bagaimana spesifikasi klien dan implementasi didefinisikan. Setelah fase awal ini, Refaktor Klienpeningkatan fleksibilitas dan kemudahan dalam mengembangkan klien ringan untuk rantai dengan algoritma konsensus dan fitur lainnya.

Klien Ringan: Mesin Negara

Sebuah 'mesin keadaan' dapat menjadi seluruh blockchain (replicated ledger) atau satu proses yang menandatangani operasi dengan kunci pribadi (konsensus minimal), seperti laptop atau ponsel.

Umumnya, kita menganggap mesin negara sebagai blockchain dengan buku besar terdistribusi, sehingga ketika mendirikan IBC antara blockchain, klien ringan rantai tujuan dihoskan oleh rantai sumber. Rantai sumber juga mempertahankan status terpercaya dari rantai tujuan, yang dibentuk oleh jabat tangan koneksi antara kedua rantai tersebut. Protokol IBC menggunakan predikat validitas, yang merupakan algoritma yang memeriksa apakah pembaruan status dari rantai tujuan valid. Untuk berfungsi, klien ringan memerlukan predikat validitas dan status tepercaya untuk rantai sumber.

tipe klien vs. instansi klien

Klien ringan dirancang untuk menjadi seefisien mungkin untuk mendukung sejumlah besar instance klien untuk banyak rantai. Untuk mencapai hal ini, algoritma klien ringan tidak memutar ulang semua transisi status, yang sebaliknya akan membuatnya menjadi node penuh.

Klien Ringan: Mesin Solo

Sebuah mesin solo adalah perangkat seperti laptop, antarmuka web, ponsel, atau proses off-chain. Sebuah mesin solo dapat membentuk komunikasidengan ledger yang direplikasi jika blockchain tersebut menggunakan IBC untuk transportasi.

Sebagai contoh, IBC dapat memungkinkan sebuah protokol transfer kustodianyang menurunkan biaya integrasi untuk rantai baru. Ini penting karena penjaga terpusat menghadapi proses yang menjengkelkan dan mahal saat mengintegrasikan jaringan baru yang memerlukan menjalankan node penuh dan infrastruktur RPC untuk setiap rantai yang terintegrasi. Sebagai gantinya, penjaga dapat mengoperasikan klien mesin tunggal yang memfasilitasi transfer lintas rantai, pencetakan/membakar. Verifikasi akan dilakukan oleh klien mesin terhubung yang dijalankan oleh penjaga.

Klien mesin Solo menunjukkan bagaimana IBC membuka konektivitas di luar hanya blockchain. Pada contoh di atas, ini dapat memungkinkan lembaga-lembaga berinteraksi dengan blockchain publik melalui IBC dengan mudah. Ini hanya satu contoh dari garis bisnis yang berhubungan dengan blockchain tanpa harus memulai rantai lengkap atau memelihara perangkat keras berat untuk bekerja dengan mereka.

Verifikasi Melebihi Buktikan Konsensus

Meskipun ada pekerjaan yang sedang dilakukan untuk membuat klien mudah diimplementasikan dan diperbarui, ada opsi untuk melakukan verifikasi dengan bukti keabsahan atau kecurangan.

Optimistic IBC: Klien dapat menerima header masuk secara optimis melalui pengalih luar rantai yang menjalankan program pada mesin virtual tertentu. Dalam skenario ini, ada jendela tantangan di mana bukti penipuan dapat diserahkan. Positifnya adalah bahwa Optimistic IBC mengurangi biaya seluruh sistem. Kerugiannya termasuk periode tantangan penipuan yang panjang dan bergantung pada jaringan, bisa ada biaya dasar tinggi untuk mentransfer aset - untuk Ethereum, ini adalah 21.000 unit gas.

ZK-IBC: Komputasi klien terjadi di luar rantai dan diverifikasi di rantai melalui ZKPs. Tidak ada laten minimum dan biaya lebih rendah daripada verifikasi naif. Namun, verifikasi ZK dapat mahal di rantai dan tidak ada laten maksimum, yang berarti pengguna mungkin harus menunggu beberapa saat untuk mendapatkan konfirmasi. Mungkin juga masalah ketidakcocokan jika skema tanda tangan tidak ramah SNARK.

Karena sistem terpisah di atas dapat memiliki beberapa hambatan yang melarang, Optimistic ZK diusulkan untuk meminjam manfaat dari keduanya. Manfaat menggunakan kedua menurunkan biaya pemeliharaan koneksi dan memperkenalkan batas laten maksimum melalui insentif relayers.

Optimistic ZK: Rantai sumber menerima header secara optimis di rantai (mungkin ada mekanisme staking untuk keamanan). Kemudian, ZKP digunakan sebagai bukti penipuan dalam kasus perilaku buruk atau bukti validitas untuk mengurangi latensi koneksi secara dinamis.

Keamanan dan Perilaku Buruk

IBC tidak memerlukan asumsi kepercayaan pihak ketiga apa pun, yang sering diambil oleh protokol interoperabilitas yang diverifikasi eksternal. Ini hanya sebuah protokol transportasi dan properti keamanannya bergantung pada jenis klien dan koneksi yang mendasarinya dan bukan pada rantai itu sendiri. Ini juga tergantung pada penggunaan bukti kecurangan koneksi, asumsi mayoritas jujur, keamanan bersama melalui ketersediaan data umum, dll. Protokol IBC tidak perlu mengetahui identitas dari rantai di kedua sisi koneksi, selama klien IBC tetap disinkronkan dengan pembaruan yang valid.

Dalam hal terjadi perilaku buruk, yaitu aturan konsensus yang ditetapkan oleh rantai tujuan dilanggar oleh klien di rantai sumber, klien di rantai host akan dibekukan jika bukti perilaku buruk diverifikasi di rantai sumber. Pihak yang melihat hal ini, seperti pengantar, dapat mengirim pesan dengan bukti perilaku buruk ini. Predikat perilaku buruk adalah algoritma yang dipanggil dalam situasi seperti ini: jika perilaku buruk terbukti, klien akan dibekukan dan semoga ada sistem tata kelola yang siap mengambil tindakan. Dampak dari perilaku buruk ditentukan oleh rantai yang berpartisipasi.

Membangun Dengan Klien Ringan

Meskipun IBC dapat memerlukan beberapa keahlian teknis dalam konsensus dan internal rantai yang mendasarinya, tidak semua kompleksitasnya penting untuk membangun menggunakan IBC – tujuan lain yang kami miliki dengan seri artikel ini. Inti dari sini adalah bahwa IBC adalah alat yang kuat mengingat berbagai implementasi verifikasi yang dapat diambil oleh klien.

Ekosistem IBC sedang aktif bekerja untuk membuat IBC menjadi solusi yang mudah diadopsi oleh para pembangun. Beberapa inisiatif yang telah kita bahas termasuk refactor klien dan klien virtual. Sebagai contoh, jika sebuah rantai ingin meningkatkan konsensus, rantai tersebut perlu meningkatkan setiap rantai yang terhubung dan klien ringannya agar tetap terhubung, yang merupakan proses tata kelola on-chain yang mahal. Klien WASM sedang dikembangkan untuk membuat pengembangan dan peningkatan klien ringan menjadi sederhana melalui instansi klien yang dideploy sebagai kontrak pintar. Hal ini memudahkan untuk meningkatkan klien ringan tanpa menghentikan rantai dan untuk membuat klien dalam bahasa seperti Rust, yang merupakan pilihan populer di antara beberapa mesin negara.

Takeaway dari pemisahan adalah bahwa klien IBC dapat digunakan oleh siapa pun dan mesin apa pun untuk memverifikasi status di seluruh blockchain, menjadikannya katalisator yang kuat untuk bisnis dan layanan baru dalam dunia kripto.

Artikel ini disponsori oleh Polymer untuk mendukung pendidikan komunitas seputar IBC dan interoperabilitas yang benar-benar terdesentralisasi.

Polymer Labs, yang terdiri dari insinyur sistem terdistribusi yang terampil dan infrastruktur, para pionir kripto, dan operator bisnis yang berprestasi, berada di garis depan dalam memajukan interoperabilitas Ethereum dengan IBC. Dengan nilai teknis yang didasarkan pada TCP/IP, misi Polymer adalah untuk membentuk generasi berikutnya dari internet dengan memastikan bahwa lapisan interoperabilitas web terdesentralisasi bersifat netral, terbuka, tanpa izin, dan seragam di seluruh ekosistem. Sebagai pencipta Ethereum Interoperability Hub, Layer 2 pertama yang difokuskan pada memungkinkan interoperabilitas IBC, Polymer menetapkan standar baru dalam teknologi blockchain.

Disclaimer：

1. Artikel ini dicetak ulang dari [eshitanandini]. Semua hak cipta milik penulis asli [ESHITA]. Jika ada keberatan terhadap cetakan ulang ini, silakan hubungiGate Belajartim, dan mereka akan menanganinya dengan cepat.
2. Penolakan Tanggung Jawab Kewajiban: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan saran investasi apapun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.