Avalanche Interchain Token Transfer

Published in

Avalanche Indonesia

9 min readJul 22, 2024

Dengan diperkenalkannya permissionless chain, “Subnet” sekarang akan disebut sebagai “L1”.

TL;DR

Ava Labs memperkenalkan Avalanche Interchain Token Transfer (Avalanche ICTT), solusi aman dan efisien bagi pengembang mana pun untuk menerapkan kontrak transfer token di Avalanche. Inovasi ini menyederhanakan proses pembuatan dan audit kontrak pintar yang biasanya rumit dan mahal untuk menjembatani token antara blockchain Lapisan 1 (L1). Dengan smart contract yang dibuat sebelumnya, diaudit secara menyeluruh, dan permissionless, Avalanche ICTT memungkinkan penghubungan token seperti USDC dan BTC yang mulus antara berbagai L1 di Avalanche. Peningkatan ini menghemat waktu dan sumber daya sekaligus memastikan keamanan dan standarisasi di seluruh transaksi cross chain.

Intro: Masalah Dengan Bridging

Dalam dunia teknologi blockchain yang terus berkembang, komunikasi yang lancar antara berbagai jaringan blockchain sangatlah penting. Di sinilah peran Teleporter — sebuah protokol komunikasi cross-chain mutakhir yang dirancang untuk memungkinkan Avalanche L1 (sebelumnya dikenal sebagai Subnet) bertukar informasi dengan mudah, serupa dengan cara negara berdagang dan berkomunikasi.

Namun Teleporter sendiri hanyalah landasan untuk komunikasi cross-chain. Ini tidak menyertakan logika bawaan yang disesuaikan untuk aplikasi tertentu. Misalnya, untuk mentransfer token antar L1 di Avalanche, Anda biasanya perlu mempekerjakan solidity engineer, meminta mereka menulis smart contract yang diperlukan, lalu mencari auditor untuk mengaudit kontrak ini. Proses ini mahal dan memakan waktu, seringkali memerlukan waktu beberapa bulan untuk menyelesaikannya. Selain itu, bridging tradisional sering kali dipenuhi dengan asumsi kepercayaan tambahan, tidak transparan atau terbuka, dan memiliki titik-titik utama kegagalan.

Untuk membuatnya lebih konkrit, berikut beberapa contoh hal yang mungkin ingin Anda lakukan dan mengapa hal tersebut sulit:

Anda menginginkan USDC di L1 Anda, tetapi untuk melakukan ini memerlukan kemitraan dengan Circle, yang mungkin memerlukan waktu dan sumber daya.
Anda ingin BTC di beberapa L1 di Avalanche, namun hal ini memerlukan masing-masing L1 untuk berkoordinasi, menyepakati proses penghubungan standar, lalu mencari penyedia pihak ketiga untuk mengimplementasikan kontrak.
Anda ingin menyesuaikan L1 Anda dengan menggunakan ERC-20 Anda sendiri sebagai token gas. Hal ini memerlukan kemitraan dengan penyedia bridging pihak ketiga, yang memerlukan waktu, uang, sumber daya teknik, dan asumsi kepercayaan tambahan.

Untuk meningkatkan pengalaman pengembang dan menyederhanakan proses ini, Ava Labs telah mengembangkan solusi komprehensif.

Solusi: Avalanche Interchain Token Transfer

Avalanche Interchain Token Transfer (Avalanche ICTT) mengatasi kelemahan tradisional bridge dengan memanfaatkan teknologi dasar Teleporter dan Avalanche Warp Messaging. Avalanche ICTT TIDAK bergantung pada sebagian kecil node, operator pusat, atau multisig untuk pengoperasiannya. Sebaliknya, ia memanfaatkan kumpulan validator dari blockchain sumber L1, yang dapat terdiri dari jumlah validator yang tidak terbatas. Tidak seperti solusi penghubung pihak ketiga lainnya, Avalanche ICTT TIDAK memperkenalkan asumsi kepercayaan tambahan — validator L1 sudah cukup.

Selain itu, Avalanche ICTT menyederhanakan dan mempercepat transfer token lintas rantai dengan mengurangi kompleksitas dan penundaan yang biasanya terkait dengan bootstrapping: Kami telah mengembangkan dan mengaudit kontrak pintar yang penting, memastikan kontrak tersebut aman dan siap digunakan. Artinya, Anda dapat fokus pada hal yang paling penting — membangun dan berinovasi — sementara Avalanche ICTT menangani seluk-beluk komunikasi cross chain.

Dengan Avalanche ICTT, Anda memperoleh:

Aksesibilitas: Siapa pun dapat menerapkan kontrak ini — kontrak ini sepenuhnya tanpa izin dan dirancang terbuka.
Efisiensi Biaya: Tidak perlu berinvestasi dalam proses pengembangan dan audit yang ekstensif.
Penghematan Waktu: Percepat jadwal proyek Anda dengan kontrak pintar yang siap digunakan.
Keamanan: Andalkan kontrak yang telah diaudit secara menyeluruh untuk memastikan transfer token Anda aman. Berbeda dengan jembatan tradisional, tidak ada asumsi kepercayaan tambahan yang diperkenalkan.

Beberapa L1 lama dan baru akan segera mengintegrasikan Avalanche ICTT melalui AvaCloud. Di antara mitra peluncuran terdapat nama-nama terkemuka seperti Lamina1, GoGoPool, dan ZeroOne. Rasakan kemudahan dan efisiensi penghubungan token lintas rantai dengan Avalanche ICTT dan buka kemungkinan baru untuk proyek Anda di Avalanche.

Cara Kerja: Technical Overview

Kontrak Avalanche ICTT tidak dapat ditingkatkan, sehingga memberikan kekekalan dan memastikan bahwa perilaku kontrak di setiap alamat tidak berubah. Antarmukanya menyediakan proses standar yang sederhana untuk mentransfer token ERC-20 atau Native (token yang digunakan untuk membayar biaya transaksi pada chain tertentu) dari chain sumber ke chain tujuan, yang kemudian direpresentasikan sebagai token baru. Representasi token pada chain tujuan ini dapat berupa token ERC-20 atau Native, yang memungkinkan pengguna memiliki kombinasi token ERC-20 dan Native antara chain sumber dan tujuan:

ERC-20 <> ERC-20
ERC-20 <> Native
Native <> ERC-20
Native <> Native

Kontrak memungkinkan logika kustom diimplementasikan untuk pencetakan, pembakaran, atau transfer kustom. Seperti yang ditunjukkan dalam repositori, kontrak sumber dikenal sebagai kontrak “Home”, dan kontrak tujuan dikenal sebagai kontrak “Remote”, jadi kami akan menggunakan istilah ini di masa mendatang.

Beberapa konsep kunci yang perlu dipahami:

Satu kontrak “Home” dapat memiliki beberapa kontrak “Remote”.
Kontrak “Remote” hanya berinteraksi dengan satu kontrak “Home”.
Setiap kombinasi kontrak ditentukan berdasarkan per aset.
Setiap L1 dapat menerapkan beberapa kontrak transfer token independen.

Contoh di bawah masing-masing menggambarkan salah satu konsep di atas:

Satu kontrak “Home” USDC di Avalanche C-Chain dapat terhubung ke beberapa kontrak “Remote” USDC di berbagai L1. Kontrak “Remote” dapat mentransfer USDC sebagai ERC-20 atau sebagai token gas asli L1 tersebut.
Sebuah kontrak “Home” memegang jaminan untuk kontrak “Remote” tertentu. Kontrak “Remote” memiliki tepat satu “Home”.
Kontrak “Home” dan “Remote” yang terpisah perlu diterapkan untuk token yang berbeda, misalnya USDC dan AVAX memiliki setnya sendiri.
Karena siapa pun dapat menerapkan kontrak ini, mungkin terdapat beberapa kontrak untuk token tertentu di L1. Untuk menghindari fragmentasi, L1 dapat mengaktifkan Prakompilasi Manajer Kontrak untuk membatasi siapa yang dapat menerapkan kontrak pada L1.

Untuk memulai Avalanche ICTT, lihat Avalanche Starter-Kit, Avalanche Academy course, atau terapkan kontrak transfer token Anda sendiri di Avalanche CLI dengan mengikuti petunjuknya. Untuk pendekatan tanpa kode, L1 dapat mengunjungi AvaCloud dan menanyakan tentang interoperabilitas.

Kasus Penggunaan dan Contoh Alur

Ingin memahami lebih lanjut tentang alur end-to-end? Mari kita lihat contoh ERC-20 <> ERC-20 untuk menjembatani USDC native di Avalanche C-Chain ke L1.

Terapkan kontrak “Home” ERC-20 di C-Chain, yang ditentukan untuk USDC sebagai aset.
Terapkan kontrak “Remote” ERC-20 pada L1 yang diinginkan, ditentukan untuk USDC dan dipetakan ke kontrak “Home”.
Untuk mentransfer USDC dari C-Chain ke L1:
- USDC pertama kali dikirim ke kontrak “Home” di C-Chain, di mana USDC dikunci dalam kontrak ini sebagai jaminan.
- Dalam transaksi kedua, kontrak “Remote” mencetak jumlah yang setara dengan USDC pada L1.
Untuk menebus USDC kembali ke C-Chain, USDC yang dibungkus di L1 dibakar oleh kontrak “Remote”, lalu transaksi kedua melepaskan USDC yang dikunci dalam kontrak “Home” di C-Chain.

Sekarang mari kita lihat contoh token native ERC-20 <> untuk menerapkan USDC sebagai token gas native L1.

Daripada menerapkan kontrak “Home” USDC baru di C-Chain, kontrak yang diterapkan pada langkah 1 pada contoh sebelumnya dapat digunakan kembali. Ingatlah bahwa satu kontrak sumber dapat memiliki beberapa kontrak tujuan.
Mendapatkan USDC sebagai token gas native L1 ini sedikit sulit, karena sejumlah token Native harus ada untuk membayar biaya gas untuk 1) penerapan kontrak “Remote” USDC, dan 2) mencetak USDC yang ditransfer dari C-Chain. Untuk menyiasatinya, pertama-tama alokasikan L1 dengan beberapa USDC dengan mengirimkannya airdrop di genesis. USDC ini secara efektif tidak bernilai pada saat ini karena belum dijaminkan.
Sekarang L1 memiliki airdrop USDC, alias beberapa representasi gas, kontrak Native Token “Remote” dapat diterapkan di L1. Sebagai pengingat, pastikan untuk memetakan kontrak “Home” yang benar saat menerapkan kontrak “Remote”.
Langkah terakhir adalah menjaminkan kontrak “Home” di C-Chain dengan mengirimkan USDC yang cukup hingga 1:1 cocok dengan USDC yang dicetak di L1 dalam kontrak “Remote”. Catatan: Sampai kontrak dijaminkan, token baru tidak dapat dicetak di tempat tujuan.
Sekarang setelah kontrak diatur dengan benar, USDC dapat dicetak di L1 dengan Native Minter Precompile. Prakompilasi ini sederhana — ini memberikan kontrak “Remote” dengan kemampuan untuk mencetak token Asli dan mengirimkannya ke alamat penerima yang ditunjuk. Kontrak “Remote” mengandung logika untuk memastikan bahwa mulai saat ini dan seterusnya, jumlah token yang dicetak di sisi tujuan (L1) sama dengan atau kurang dari USDC yang dijaminkan di sumbernya (C-Chain).

Skenario lain yang perlu diperhatikan adalah kasus multihop, di mana USDC ditransfer antara dua L1 yang berbeda, tidak ada satupun yang merupakan “home chain” untuk USDC.

Pertama, kontrak “Remote” USDC harus diterapkan di kedua chain— sebut saja L1a dan L1b — yang dipetakan ke kontrak “Home” USDC yang sama di C-Chain.
Karena USDC bukan native dari kedua L1, diperlukan multihop, artinya ada 3 transaksi, bukan 2 transaksi biasa:
- USDC pertama kali dibakar di L1a. Sebuah pesan (pemberitahuan) dikirim ke chain asal token (dalam hal ini, C-Chain).
- C-Chain melacak saldo USDC di seluruh L1 pada “accounting ledger” lalu meneruskan pesan ke L1b untuk mencetak USDC yang setara.
- L1b mencetak jumlah yang setara dengan USDC.

Manfaat utama dari desain ini adalah keamanan dan efisiensi: kontrak tujuan hanya perlu mempercayai kontrak sumber, dan tidak ada aset yang dibungkus lebih dari satu kali. Jika L1a diretas, hal ini tidak dapat memengaruhi saldo di tujuan lain (misalnya L1b), karena kontrak sumber selalu melacak berapa banyak saldo yang dimiliki setiap kontrak tujuan. Tidak ada aset yang dibungkus lebih dari satu kali karena jumlah maksimum transaksi yang diperlukan untuk setiap token yang ditransfer adalah 3.

Konten Bonus: Fitur Lanjutan

Salah satu fitur menarik yang disertakan dalam kontrak adalah kemampuan untuk menggunakan token yang ditransfer dalam interaksi smart contract dalam satu pesan Teleporter. Fitur ini, yang dikenal sebagai sendAndCall, mengurangi jumlah interaksi pengguna.

Misalnya, Anda menggunakan C-Chain tetapi ingin menggunakan L1. Saat ini Anda memiliki AVAX tetapi pada akhirnya ingin USDC dapat terlibat dalam dApp di L1. Secara tradisional, alur kerja Anda akan seperti ini:

Transfer AVAX dari C-Chain ke L1
Tukar AVAX di C-Chain dengan USDC di L1
Terlibat dalam dApp di L1 dengan USDC

sendAndCall menggabungkan langkah-langkah ini menjadi satu, meningkatkan pengalaman pengguna dan membuatnya lebih mudah untuk memanfaatkan layanan di chain tujuan sesuai dengan kontrak apa pun. Ia melakukannya dengan memberikan izin kontrak yang ditunjuk untuk membelanjakan sebagian dari AVAX Anda sehingga Anda dapat melakukan pertukaran dan meneruskan dana ke dApp yang diinginkan, sehingga menghilangkan kebutuhan untuk beberapa transaksi terpisah.

Catatan penting

sendAndCall memiliki mekanisme fallback di mana jika interaksi kontrak pintar gagal karena alasan apa pun, token akan tetap menyelesaikan operasi penghubungan reguler, namun aset akan ditransfer ke alamat penerima yang ditentukan oleh pengguna. Kontrak pintar untuk layanan ini tidak akan menyimpan token atau dapat menggunakan token tersebut karena interaksi gagal.
Relai masih diperlukan untuk mengirimkan token di antara L1 ini. Anda dapat mempelajari lebih lanjut tentang menyiapkan relayer di sini, atau kunjungi AvaCloud untuk mendapatkan layanan Managed Relayer.
Kontrak Avalanche ICTT tidak dapat ditingkatkan dan tidak dapat diubah setelah diterapkan. Hal ini memberikan kekekalan pada kontrak, dan memastikan bahwa perilaku kontrak di setiap alamat tidak berubah.
Demikian pula, Teleporter Messenger tidak dapat diupgrade, namun versi baru dapat diterapkan dan dilacak melalui Teleporter Registry, yang memberikan aplikasi yang menggunakan instance Teleporter Messenger proses langkah minimal untuk berintegrasi dengan versi baru Teleporter Messenger. Catatan: versi baru didaftarkan melalui pesan Warp off-chain, menjadikan Registry sebagai operasi terdistribusi.
Secara default, kontrak Avalanche ICTT mengirim pesan Teleporter menggunakan versi terbaru yang tersedia di Teleporter Registry di setiap chain. Selain itu, terdapat peran admin Manajer Teleporter yang dapat memilih versi kontrak minimum Teleporter Messenger yang didukung. Admin ini juga memiliki kemampuan untuk menjeda kontrak transfer token dengan menjeda alamat Teleporter Messenger tertentu.
Penting untuk dicatat bahwa Teleporter Manager dapat diatur ke apa saja. Untuk menghindari fungsi admin apa pun, seseorang dapat menyetelnya ke “tidak dimiliki” (yaitu 0x00..01). Namun, sebagian besar akan menganggap fitur ini berguna ketika ada versi Teleporter Messenger yang baru. Dengan demikian, ini dapat diatur ke EOA tunggal, kontrak multi-sig, atau bahkan kontrak yang menggunakan pesan Warp off-chain untuk otentikasi (menjadikannya terdistribusi seperti set validator dari L1 yang aktif). Imbalannya adalah kecepatan untuk bertindak jika terjadi kerentanan vs kendali kontrak yang terpusat. Ini dapat dikonfigurasi, dan titik mana pun di sepanjang kurva tersebut dapat dipilih untuk kebutuhan kasus penggunaan tertentu.

Kesimpulan

Avalanche ICTT mewakili kemajuan signifikan dalam komunikasi lintas rantai menggunakan protokol Teleporter. Dengan menghilangkan kebutuhan akan proses pengembangan dan audit yang ekstensif, ini memberikan cara yang efisien, hemat biaya, dan aman untuk mengelola transfer token di berbagai L1 dalam Avalanche.

Dengan desain tanpa izin, kekekalan, dan rangkaian fitur yang komprehensif, Avalanche ICTT memberdayakan pengembang untuk fokus pada inovasi sambil memastikan integritas dan keamanan proyek mereka.

Baik Anda ingin mentransfer token ERC-20, menggunakan token native, atau menjelajahi fitur-fitur canggih seperti sendAndCall, Avalanche ICTT membuka banyak kemungkinan untuk aplikasi blockchain Anda.

Terjemahan dalam Bahasa Inggris

Penulis: Avalanche