Pengantar

Para maxis modular mengatakan masa depan kripto adalah jutaan (atau lebih) domain dan pengguna yang saling terhubung, seperti Alice berjalan-jalan melalui Wonderland. Mengapa tetap dengan satu rantai jika Anda dapat mengakses teknologi terkini, aplikasi baru, pengembalian moonshot pada staking/likuiditas, kinerja tinggi, dan biaya transaksi yang sangat rendah pada rantai kripto lainnya?

Namun beralih antara blockchain jauh lebih rumit daripada perjalanan Alice melalui Wonderland, terutama karena keterbatasan yang melekat dalam pendekatan saat ini terhadap interoperabilitas blockchain (misalnya, jembatan cross-chain). Secara khusus, jembatan cross-chain saat ini entah tidak aman ($2.5M+ hilang dalam peretasan jembatan), lambat, mahal, atau terbatas dalam fungsionalitas—atau menampilkan campuran properti dari daftar tersebut.

Masalah lain yang mengganggu industri bridging lebih halus tetapi tetap cukup untuk mengubah impian modular maxi tentang ekosistem multi-chain menjadi mimpi buruk bagi pengguna dan pengembang—contohnya adalah bagaimana token yang dapat dipertukarkan (seperti ERC-20) menjadi tidak dapat dipertukarkan ketika dijembatani ke rantai yang berbeda melalui berbagai protokol cross-chain sehingga merusak fiturnya sebagai aset yang dapat ditransfer. Dalam artikel ini, kami akan menjelajahi solusi yang bertujuan untuk mempertahankan keberfungsaan token di seluruh rantai tanpa memperdulikan di mana kontrak asli token berada: ERC-7281: Token Sovereign-Bridged.

ERC-7281 memperluas ERC-20—standar de facto untuk menciptakan token yang dapat dipertukarkan di Ethereum—untuk memungkinkan pencetakan dan pembakaran representasi kanonik dari token ERC-20 pada domain remote oleh beberapa jembatan yang disetujui oleh penerbit token. Hal ini memastikan bahwa pengguna yang memindahkan token ERC-20 menerima versi yang dapat dipertukarkan dari token tersebut di tujuan (misalnya, dua token dapat ditukar 1:1), bahkan ketika token dikirim melalui jalur/jembatan yang berbeda. Yang penting, protokol yang mengadopsi ERC-7281 tetap mengendalikan token yang terhubung (tidak seperti keadaan saat ini di mana jembatan mengendalikan token yang terhubung) dan dapat membatasi operasi pencetakan untuk mengurangi paparan dalam kasus kegagalan jembatan.

Mari kita gunakan USDC sebagai contoh ketidakfungsiannya di antara token ERC-20 yang secara teori identik di berbagai rantai. Jaringan Layer 2 (L2) Ethereum, seperti Arbitrum, Base, Optimism, umumnya menggunakan jembatan kanonikal untuk memindahkan token ERC-20 populer dari Ethereum L1 ke rantai-rantai ini. Versi-versi token L2 yang berasal dari L1 ini umumnya disebut hanya sebagai “bridged [insert token name].”

Dalam kasus USDC, simbol umumnya adalah USDC.e, USDC.b, dan sebagainya. Seiring berjalannya waktu, Circle memperluas penyebaran USDC ke jaringan lain, termasuk L2, di mana USDC sudah ada melalui jembatan canonical. Meskipun kedua token ini dicetak oleh entitas yang sama dan memiliki harga yang sama, secara teknis mereka adalah token yang berbeda, tidak dapat dipertukarkan—sedangkan USDC asli dapat dijembatani melalui jembatan CCTP milik Circle, USDC yang dijembatani hanya dapat dikembalikan ke L1 melalui jembatan canonical.

ERC-7281 memperbaiki hal ini dengan memperkenalkan ekstensi ERC-20 di mana pengembang token dapat menetapkan dan memparametrikasikan sumber-sumber bridging yang berbeda untuknya. Dalam contoh di atas, Circle dapat melakukan deploy token USDC universal di semua L2, di mana jembatan-jembatan kanonikal (misalnya, Circle Mint, Circle CCTP, dan jembatan-jembatan yang disetujui lainnya) semuanya ditugaskan sebagai pihak yang mampu melakukan pembuatan token sesuai dengan logika mereka. Untuk meminimalkan risiko penambang yang diretas, pengembang dapat membatasi berapa banyak token yang dapat ditambang dan dibakar oleh setiap penambang dalam periode waktu tertentu—dengan jembatan-jembatan yang lebih andal, seperti L2 kanonikal, memiliki batasan yang lebih tinggi, dan jembatan-jembatan dengan konsensus terpusat memiliki batasan yang lebih rendah.

Meskipun ERC-7281 bukan upaya pertama dalam menciptakan token cross-chain yang dapat saling dipertukarkan, namun ia memperbaiki masalah yang terkait dengan proposal sebelumnya, seperti keterikatan dengan vendor, kehilangan kedaulatan bagi penerbit token, biaya tinggi untuk memulai likuiditas untuk token yang dilintasi, infrastruktur yang berlebihan, dan peningkatan risiko kegagalan jembatan.

Laporan dua bagian ini akan menguji alasan untuk memperkenalkan standar token jembatan kedaulatan dan memberikan gambaran menyeluruh tentang spesifikasi ERC-7281 (juga dikenal sebagai xERC-20). Kami juga akan membahas manfaat positif dan potensi kerugian dari implementasi ERC-7281 untuk pengguna, pengembang, penyedia infrastruktur, dan pihak lain dalam ekosistem Ethereum.

Sekilas tentang jembatan blockchain

Sebelum masuk ke masalah token jembatan non-fungible, membantu untuk memahami mengapa token jembatan ada pada awalnya. Ini, pada gilirannya, memerlukan pemahaman tentang motivasi dan operasi jembatan blockchain—karena operator jembatan lah yang bertanggung jawab atas menciptakan versi token jembatan.

Jembatan adalah mekanisme untuk mentransfer informasi antara blockchain. Selain informasi murni tentang uang, jembatan dapat melewatkan segala informasi yang berguna seperti nilai token dan status kontrak pintar di blockchain lain. Namun, mentransfer aset (token) dari satu blockchain ke blockchain lain adalah kasus penggunaan yang paling umum bagi pengguna yang berinteraksi dengan jembatan saat ini.

Pendekatan untuk memfasilitasi transfer aset cross-chain bervariasi, tetapi alur kerja jembatan token biasanya mengikuti salah satu dari tiga pola tingkat tinggi:

Jembatan Kunci dan Mint

• Seorang pengguna ingin menjembatani token dari rantai asli atau "rumah" (di mana ia awalnya dikeluarkan) ke rantai lain. Kedua blockchain tidak dapat dioperasikan, karena masing-masing rantai mengimplementasikan arsitektur dan desain protokol yang berbeda, yang mencegah pengguna mentransfer token langsung dari alamat dompet di rantai A ke alamat dompet di rantai B.
• Operator jembatan menahan token yang disetor oleh pengguna di rantai asal dalam kontrak pintar dan membuat representasi "dibungkus" dari token asli melalui kontrak token yang diterapkan di rantai target.
• Ketika pengguna ingin melakukan jembatan ke arah sebaliknya (rantai tujuan → rantai asal), mereka mengembalikan token terbungkus ke jembatan di rantai tujuan, yang memverifikasi hal ini sesuai dengan logika di jembatan (misalnya bukti ZK atau kuorum eksternal) dan melepaskan token asli dari escrow di rantai asal.

Membakar dan mencetak jembatan

• Daripada mengunci token dalam escrow, pendekatan ini membakar (menghancurkan) token pada rantai sumber;
• Jembatan kemudian mencetak jumlah yang setara di rantai tujuan;
• Untuk perjalanan balik, token yang terhubung dibakar di rantai tujuan sebelum token baru diciptakan di rantai sumber;
• Hal ini menjaga pasokan total token sambil memungkinkan transfer cross-chain.

Atomic swaps

• Pendekatan ini secara langsung menukar aset di rantai sumber dengan aset di rantai tujuan dengan pihak lain.
• Atomic swaps bekerja melalui saling mengunci dana dengan nilai rahasia yang sama untuk membukanya, yang berarti bahwa jika pada salah satu sisi rahasia tersebut terungkap, itu juga dapat terungkap pada sisi lainnya. Hal ini memberikan swap sifat atomis.
• Atomicity berarti swap tersebut entah berhasil dilakukan secara penuh (dari kedua sisi) atau tidak sama sekali, mencegah penipuan atau transfer sebagian/gagal.

Pendekatan pertama (kunci dan cetak) saat ini adalah yang paling umum. Kesetaraan dalam nilai antara token asli dan representasi terbungkusnya yang dicetak oleh jembatan adalah yang memungkinkan pengguna ''mentransfer'' aset cross-chain dan menggunakan token di rantai terpisah dari tempat awal penerbitannya.

Namun, desain baru - seperti pembuatan jembatan berbasis niat - telah menjadi sangat populer. "Niat" memungkinkan pengguna untuk menyatakan hasil yang diinginkan untuk transaksi ("tukar 100 USDC dengan 100 DAI") daripada menentukan langkah-langkah khusus untuk mencapai hasil tersebut. Niat telah muncul sebagai pengalaman UX yang kuat karena mereka sangat menyederhanakan pengalaman onchain bagi orang-orang dan membuat kripto lebih mudah digunakan, terutama ketika dipasangkan dengan solusi abstraksi rantai.

Niat lintas-rantai Izinkan pengguna untuk mentransfer token antar rantai tanpa khawatir tentang kompleksitas bridging yang mendasarinya. Dalam jembatan berbasis niat, pengguna menyetor dana pada rantai sumber dan menentukan hasil yang diinginkan pada rantai tujuan ("niat" mereka). Operator khusus yang disebut "pengisi" atau "pemecah masalah" dapat memenuhi maksud ini dengan mengirimkan token yang diminta kepada pengguna di rantai tujuan terlebih dahulu. Operator kemudian membuktikan transfer terjadi untuk mengklaim dana yang terkunci pada rantai sumber sebagai penggantian.

Beberapa jembatan berbasis tujuan memanfaatkan mekanisme kunci-dan-cetak di bawahnya. Dalam hal ini, jembatan mencetak token terbungkus yang dikirim baik ke pengisi yang memenuhi tujuan pengguna—atau langsung ke pengguna jika tidak ada pengisi yang masuk. Sementara jembatan berbasis tujuan menambahkan lapisan efisiensi tambahan melalui jaringan solver mereka, mereka masih pada dasarnya mengandalkan prinsip yang sama dengan jembatan kunci-dan-cetak tradisional.

Kita dapat memikirkan setiap token terbungkus, baik diciptakan melalui bridging tradisional atau berbasis intensi, sebagai catatan utang dari operator jembatan yang berjanji untuk melepaskan sejumlah token yang mendasarinya dari kontrak penahanan. Nilai aset terbungkus ini berkorelasi langsung dengan kapasitas operator jembatan (dipersepsikan) untuk memproses permintaan dari pemegang untuk menarik token asli yang ditahan di rantai asal token tersebut.

Jembatan yang diotorisasi untuk mengunci token yang mendasari pada rantai sumber dan mencetak representasi terbungkusnya pada rantai tujuan memastikan bahwa total pasokan token tetap konstan. Untuk satu unit token yang mendasari, tepat satu unit token terbungkus yang sesuai dicetak, dan sebaliknya. Jika suatu aplikasi menerima token terbungkus sebagai medium pertukaran atau menggunakan aset terbungkus sebagai mata uang, pengembang dan pengguna aplikasi mempercayai penyedia jembatan untuk mengamankan aset "nyata" yang mendukung token terbungkus.

Mengapa kita memerlukan jembatan?

Kemampuan untuk melakukan transaksi dengan versi sintetis dari aset pada jaringan yang berbeda—dapat diakses melalui jembatan yang menciptakan representasi dari aset—adalah fitur yang kuat dan memungkinkan pengembang dan pengguna sama-sama memanfaatkan manfaat interoperabilitas cross-chain. Beberapa manfaat ini termasuk akses ke likuiditas yang lebih banyak, eksposur terhadap pengguna baru, dan fleksibilitas bagi pengguna (yang dapat berinteraksi dengan aplikasi favorit dari berbagai jaringan tanpa hambatan).

Untuk lebih memahami bagaimana ini berfungsi dalam praktik dan mengapa ini penting baik bagi pengembang maupun pengguna, mari kita periksa contoh konkret menggunakan pertukaran terdesentralisasi fiktif yang disebut BobDEX. Contoh ini akan menunjukkan bagaimana wrapped token memungkinkan ekspansi cross-chain sambil menyoroti manfaat dan komplikasi potensial yang dapat muncul:

BobDEX adalah pertukaran Automated Market Maker (AMM) yang dibuat oleh Bob di Ethereum untuk memungkinkan pertukaran tanpa kepercayaan antara aset yang berbeda. BobDEX memiliki token asli, $BOB, yang berfungsi ganda sebagai token tata kelola dan token imbalan LP. Dalam kasus terakhir, BobDEX mengeluarkan token BOB kepada penyedia likuiditas (LP), memberikan hak kepada pengguna yang menyediakan likuiditas ke pool untuk persentase dari biaya yang dibayarkan oleh pengguna DEX yang menukar aset yang disimpan di dalam pool.

Pangsa pasar BobDEX telah tumbuh secara signifikan, namun keterbatasan Ethereum L1 menghambat pertumbuhan selanjutnya. Sebagai contoh, beberapa pengguna tidak ingin menggunakan BobDEX pada Ethereum karena biaya gas yang tinggi dan keterlambatan transaksi; demikian pula, pengguna lain ingin terpapar pada harga token $BOB tanpa harus memegang token $BOB asli pada Ethereum.

Untuk memecahkan masalah tersebut, Bob mendeploy versi BobDEX pada Arbitrum (Layer 2 (L2) rollup dengan biaya rendah dan throughput tinggi) dan mendeploy versi wrapped dari token BOB (wBOB) pada L2 melalui jembatan Arbitrum-Ethereum. BobDEX pada Arbitrum identik dengan BobDEX pada Ethereum, kecuali menggunakan wBOB—bukan token BOB asli—untuk hadiah LP dan tata kelola.

Perbedaan dalam token aplikasi (BOB dibungkus vs. BOB asli) tidak membuat perbedaan dari sudut pandang pengguna (misalnya, penyedia likuiditas) berinteraksi dengan BobDEX di Arbitrum. Karena token wBOB didukung oleh token BOB yang sebenarnya yang dipegang di jembatan Arbitrum-Ethereum, pemegang token wBOB dapat dengan mudah menukarkan token BOB ERC-20 asli di Ethereum dengan berinteraksi dengan kontrak jembatan.

Situasinya adalah untung-untungan bagi Bob dan pengguna:

1. Bob dapat menarik lebih banyak pengguna, terutama pengguna yang ingin biaya gas rendah dan konfirmasi transaksi yang cepat saat berdagang di BobDEX
2. LP dapat mendapatkan imbalan dari penyediaan likuiditas ke BobDEX tanpa harus menghadapi biaya gas yang tinggi dan waktu konfirmasi yang lama Ethereum.
3. Hodlers dapat membeli token wBOB di pasar untuk memperoleh keuntungan dari perubahan harga token BOB tanpa berinteraksi dengan kontrak BOB ERC-20 pada Ethereum

Manfaat dari jembatan juga meluas untuk meningkatkan inovasi yang dapat dirangkai dan membuka kasus penggunaan baru yang memanfaatkan likuiditas token yang di-bridge. Misalnya, Alice dapat membuat protokol peminjaman yang disebut AliceLend di Arbitrum yang menerima wBOB sebagai jaminan dari peminjam untuk memperluas utilitas wBOB dan menciptakan pasar baru untuk gate.peminjaman dan pinjaman.

Pemberi pinjaman yang menyediakan likuiditas kepada AliceLend pasti akan menerima deposit: jika pengguna gagal membayar pinjaman, AliceLend secara otomatis mengadakan lelang token wBOB yang dijadikan jaminan untuk mengganti rugi para pemberi pinjaman. Dalam hal ini, pembeli jaminan wBOB yang dilikuidasi mengambil peran sebagai LP di BobDEX dan memiliki jaminan yang sama bahwa token wBOB dapat ditukar 1:1 dengan token BOB asli.

Jembatan lintas-rantai dalam bentuknya saat ini telah memberikan solusi yang dapat dijalankan untuk memastikan interoperabilitas antara Ethereum L2 (sebelumnya terisolasi)dan memfasilitasi aplikasi baru (misalnya, peminjaman lintas-rantai dan DEX lintas-rantai). Namun, ekosistem jembatan saat ini berjuang dengan batasan yang menghambat pertumbuhan lebih lanjut, seperti ketidaktergantungan token lintas-rantai—kita akan menjelajahi masalah ini secara detail kemudian.

Mengapa token jembatan menjadi non-fungible?

Alur kerja jembatan kunci-dan-cetak yang telah dijelaskan sebelumnya terlihat sederhana secara teoritis, namun, dalam kenyataannya, membutuhkan banyak usaha rekayasa dan desain mekanisme untuk bekerja dengan benar.

Tantangan pertama adalah memastikan bahwa versi terbungkus dari token jembatan selalu didukung oleh token asli yang terkunci di rantai sumber. Jika seorang penyerang mencetak representasi token di rantai remote tanpa mendepositokan token asli di rantai sumber, hal itu dapat membuat jembatan tidak likuid dengan menukar (yang dicetak secara curang) token terbungkus dengan token asli di rantai utama dan mencegah pengguna yang sah — yang mendepositokan di kontrak jembatan sebelum mencetak token terbungkus — untuk menarik deposit mereka.

Tantangan kedua lebih kompleks dan berasal dari sifat token jembatan: dua representasi token yang dicetak oleh penyedia jembatan di remote chain yang sama tidak dapat ditukar 1:1 untuk yang lain. Kita dapat menggunakan contoh lain dari dua pengguna yang mencoba menukar token yang dijembatani melalui rute yang berbeda untuk menggambarkan aspek masalah yang terkait dengan memindahkan token melintasi chain:

• Alice menjembatani USDC dari Ethereum ke Arbitrum melalui jembatan Arbitrum kanonik dan menerima 200 USDC.e di Arbitrum, sementara Bob menjembatani USDC ke Arbitrum melalui Axelar dan menerima 200 axlUSDC di Arbitrum. Alice dan Bob menandatangani perjanjian untuk Alice untuk mengirim 200 USDC ke Bob (dengan imbalan 200 USDT) sehingga Bob dapat menarik 400 USDC ke Ethereum.
• Bob mencoba menarik 400 USDC melalui axlUSDC dan hanya menerima 200 USDC, bersama dengan pesan yang menjelaskan bahwa jembatan hanya memiliki 200 USDC yang dapat diberikan kepada Bob. Bob bingung karena token ERC-20 yang dibungkus seharusnya "sepadan" dan tidak boleh menunjukkan perbedaan yang mencegah siapa pun menukar token ERC-20 1: 1 pada aplikasi apa pun.
• Bob belajar pelajaran berat tentang penghubung cross-chain: "fungible ERC-20 token" tidak selalu berarti "Anda dapat menukar token ini 1:1 dengan token ERC-20 lainnya di berbagai aplikasi". Upaya Bob untuk berbisnis berisiko dengan Alice - berisiko karena Alice mungkin tidak mengembalikan token - berjalan sangat salah.

Bob setelah terjebak dalam swap

Mengapa Bob tidak dapat menarik 400 USDC jika dia dan Alice menerima versi terbungkus dari aset yang sama di rantai tujuan? Anda akan ingat kami menyebutkan bahwa token yang diterbitkan di rantai yang berbeda tidak kompatibel, sehingga representasi dari token asli yang diterbitkan di rantai non-asli adalah IOU dari jembatan yang menjanjikan untuk membayar kembali sejumlah token asli (tergantung pada berapa banyak yang tersisa) ketika pengguna ingin kembali ke rantai asli token tersebut.

Nilai setiap token yang dibuat jembatan terkait dengan penyedia jembatan yang bertanggung jawab untuk menyimpan deposit di chain asal dan mencetak representasi di chain tujuan; Penyedia jembatan Bob hanya dapat membayar Bob 200 USDC karena itu adalah jumlah yang dapat dicover dari depositnya; 200 USDC milik Alice tidak dapat ditarik melalui penyedia jembatan Bob karena tidak pernah menerima deposit atau mengeluarkan IOU kepada Alice. Alice harus menarik USDC terkuncinya dari Arbitrum di Ethereum dan melalui penyedia jembatan Bob sebelum Bob dapat mengakses token yang tersisa.

Dilema Bob dan Alice menunjukkan masalah dalam menghubungkan antara domain di mana beberapa representasi non-fungible dari aset yang mendasar dibuat oleh penyedia jembatan yang bersaing. Masalah lainnya dengan representasi ERC-20 yang berbeda dari aset yang sama adalah bahwa mereka tidak dapat diperdagangkan dalam satu kolam likuiditas tunggal.

Dengan menggunakan contoh sebelumnya, jika kita memiliki axlUSDC dan USDC.e pada rantai dan ingin menukarnya menjadi ETH dan sebaliknya, kita harus menerapkan dua kumpulan likuiditas — ETH / axlUSDC dan ETH / USDC.e. Hal ini mengarah pada apa yang disebut probem "fragmentasi likuiditas" — situasi di mana kumpulan perdagangan memiliki likuiditas yang lebih kecil daripada yang seharusnya mereka miliki karena ada beberapa kumpulan yang pada dasarnya sesuai dengan pasangan perdagangan yang sama.

Solusinya adalah memiliki versi "canonical" tunggal dari token yang beredar di chain tujuan sehingga Bob dan Alice dapat menukar token tanpa harus menarik dari jembatan di chain sumber. Memiliki token canonical per chain juga menguntungkan pengembang, karena pengguna dapat dengan cepat beralih antara ekosistem tanpa harus menghadapi masalah likuiditas token.

Jadi, bagaimana kita melaksanakan versi kanonik dari token pada setiap blockchain yang diharapkan digunakan dan ditransfer antara keduanya? Bagian berikutnya menjelaskan beberapa pendekatan populer untuk membuat token kanonik pada beberapa blockchain.

Melaksanakan token kanonik di berbagai jaringan

Membuat token kanonik per rantai tidak mudah, dan ada beberapa opsi dengan tradeoff dan keuntungan yang berbeda. Ketika membuat token kanonik per rantai, kita biasanya perlu memikirkan siapa yang bisa dipercaya mengenai adanya IOU yang mendukung nilai token tertentu. Anggap Anda adalah pencipta token dan ingin token tersebut dapat digunakan dan ditransfer di berbagai rantai tanpa masalah seputar fungibilitas; Anda memiliki empat opsi:

1. Mencetak token kanonik melalui jembatan rollup / sidechain kanonik
2. Mint token canonical melalui penyedia jembatan pihak ketiga
3. Mencetak token kanonik melalui jembatan penerbit token
4. Penerbitan multi-rantai langsung dengan pertukaran atomik

Tiga pilihan pertama bergantung pada mekanisme penghubung yang berbeda untuk memfasilitasi pergerakan token cross-chain. Namun, sebagai pencipta token, Anda juga dapat memilih untuk menghindari penghubungan sepenuhnya dengan menerbitkan token secara asli di setiap rantai yang didukung. Dalam pendekatan ini, daripada mengandalkan token terbungkus atau infrastruktur jembatan, Anda mempertahankan penyebaran token terpisah tetapi terkoordinasi di semua rantai - dengan pertukaran atomik memungkinkan pertukaran tanpa kepercayaan antar rantai.

Namun, pendekatan ini membutuhkan infrastruktur yang canggih untuk menjaga likuiditas di seluruh rantai dan memfasilitasi pertukaran atomik. Namun, kompleksitas dalam mengelola berbagai implementasi asli telah secara historis membatasi pendekatan ini hanya pada protokol yang lebih besar dengan sumber daya teknis yang substansial.

1. Mencetak token kanonikal melalui jembatan rollup/sidechain kanonikal

Jika sebuah rantai memiliki jembatan kanonikal (tersemat), Anda dapat memberikan hak untuk mencetak representasi token protokol Anda bagi pengguna yang ingin menjembatani dari rantai asli. Transaksi yang dilewati melalui jembatan kanonikal rantai (deposit dan penarikan) biasanya divalidasi oleh himpunan validator rantai, yang memberikan jaminan yang lebih kuat bahwa deposit di rantai asal secara kredibel mendukung semua representasi yang dicetak.

Meskipun jembatan kanonis memperbanyak representasi kanonis dari sebuah token, representasi lainnya tetap akan ada. Ini terjadi karena jembatan kanonis sering memiliki batasan yang mencegah mereka menawarkan pengalaman terbaik kepada pengguna. Misalnya, memperbanyak dari Arbitrum/Optimism ke Ethereum melalui jembatan kanonis rollup mengakibatkan penundaan selama tujuh hari karena transaksi harus divalidasi oleh verifikator—dan mungkin dipersengketakan oleh ...bukti penipuan, jika tidak valid—sebelum lapisan penyelesaian rollup (Ethereum—menyelesaikan kumpulan transaksi.

Pengguna Rollup yang ingin keluar lebih cepat harus menggunakan penyedia jembatan lain yang dapat mengambil alih kepemilikan keluar Rollup yang tertunda dan menyediakan likuiditas awal di mata uang target yang diinginkan oleh pengguna. Ketika jembatan-jembatan tersebut menggunakan model pengunci-dan-cetak yang tradisional, kita akan mendapatkan beberapa representasi terbungkus dari token yang dikeluarkan oleh protokol yang berbeda dan menghadapi masalah yang sama seperti yang dijelaskan sebelumnya.

Sidechain dengan set validator independen memiliki laten yang lebih rendah karena penarikan dilakukan setelah protokol konsensus sidechain mengkonfirmasi blok yang berisi transaksi penarikan. Jembatan PoS Polygon adalah contoh jembatan kanonikal yang menghubungkan sidechain ke domain yang berbeda (termasuk Ethereum rollups dan Ethereum mainnet).

Catatan: Kami merujuk pada rantai Polygon PoS asli, bukan yang cross-chain.rencana jaringan validium yang direncanakanyang akan menggunakan Ethereum untuk penyelesaian. Polygon akan menjadi L2 setelah beralih dari sidechain yang dijamin oleh validator eksternal menjadi validium yang dijamin oleh konsensus Ethereum selesai.

Namun, jembatan sidechain juga memiliki kelemahan yang sama dengan jembatan kanonikal rollup: pengguna hanya dapat menghubungkan antara sepasang rantai yang terhubung. Mereka tidak dapat menghubungkan ke blockchain lain menggunakan jembatan kanonikal. Misalnya, Anda tidak dapat menghubungkan dari Arbitrum ke Optimism hari ini menggunakan Jembatan Arbitrum atau menghubungkan dari Polygon ke Avalanche melalui jembatan Polygon PoS.

1.1. Mencetak token kanonikal menggunakan jembatan likuiditas

Mengandalkan jembatan asli rollup untuk memindahkan token kanonik memiliki beberapa masalah, seperti likuiditas yang buruk dan keterlambatan dalam pergerakan aset. Protokol ini mengatasi masalah ini dengan bekerja dengan jembatan likuiditas untuk memfasilitasi penarikan yang cepat dan bridging dengan latensi rendah*.

Dalam pengaturan ini, jembatan likuiditas yang disetujui (a) mencetak representasi terbungkus dari token protokol di rantai sumber (b) menukar token terbungkus untuk representasi kanonikal di tujuan melalui kolam likuiditas yang dimiliki protokol.

Representasi kanonik token di rantai tujuan biasanya versi yang dicetak oleh jembatan sidechain/rollup kanonik, meskipun ada pengecualian (seperti yang akan kita lihat nanti). Sebagai contoh, versi kanonik USDT di Optimism adalah opUSDT yang dicetak oleh Optimism Bridge.

Setiap jembatan likuiditas berfungsi seperti DEX dengan Automated Market Maker (AMM) untuk mengeksekusi pertukaran antara pasangan aset yang disimpan dalam kolam likuiditas yang berbeda. Untuk mendorong penyediaan likuiditas, kolam AMM membagikan sebagian dari biaya pertukaran kepada pemegang yang mengunci token kanonik dalam kontrak kolam.

Ini mirip dengan model Uniswap; satu-satunya perbedaan yang terlihat adalah bahwa pasangan aset biasanya merupakan representasi jembatan likuiditas dari suatu token terhadap representasi kanonikalnya. Sebagai contoh, pengguna yang menjembatani USDT ke Optimism melalui Hop harus menukar hUSDT di Optimism melalui kolam huSDT:opUSDT.

Alur kerja untuk menghubungkan melalui jembatan likuiditas akan terlihat seperti ini:

• Kunci token asli pada rantai sumber
• Merepresentasikan jembatan mint dari token asli di rantai target
• Tukar representasi jembatan dengan representasi kanonik di rantai target melalui kolam AMM
• Kirimkan token kanonis ke pengguna

Proses ini mirip untuk semua jembatan likuiditas (Across, Celer, Hop, Stargate, dll.). Namun, biasanya diabstraksikan dari pengguna akhir—terutama oleh penyelesaian/pengisi—dan akan terasa seperti satu transaksi meskipun melibatkan banyak bagian yang bergerak.

Ketika kembali membangun ke rantai sumber, pengguna membakar representasi kanonikal atau menukar token kanonikal dengan representasi jembatan melalui AMM sebelum membakar representasi tersebut dan memberikan tanda terima bukti bakar. Begitu dikonfirmasi, pengguna dapat menarik token asli yang terkunci pada awalnya. (Sama seperti operasi sebelumnya, detail kotor memindahkan token kembali ke rantai asli disembunyikan dari pengguna dan dikelola oleh penyelesaian).

Jembatan likuiditas sangat baik, terutama karena memperbaiki masalah keterlambatan dalam jembatan rollup; misalnya, Hop memungkinkan pihak-pihak khusus yang dikenal sebagai "Bonders" untuk mengesahkan kevalidan transaksi penarikan pengguna di L2 dan membiayai biaya penarikan dari jembatan L1 rollup. Setiap Bonder menjalankan node penuh untuk chain L2 dan dapat menentukan apakah transaksi keluar pengguna akhirnya akan dikonfirmasi di L1, mengurangi risiko bahwa pengguna memulai penarikan yang curang dan menyebabkan kerugian bagi Bonder.

Jembatan likuiditas juga memungkinkan pengguna untuk beralih antar jaringan yang lebih banyak, tidak seperti jembatan kanonik; misalnya, Hop memungkinkan pengguna untuk menjembatani antara Arbitrum dan Optimism tanpa harus menarik dana ke Ethereum terlebih dahulu. Sama seperti pengembangan cepat L2→L1, pengembangan cepat L2→L2 memerlukan Bonders untuk menjalankan node penuh untuk jaringan sumber L2 untuk mengonfirmasi penarikan sebelum menanggung biaya pembuatan token untuk pengguna pada jaringan tujuan L2. Ini memungkinkan lebih banyak komposabilitas antara rollups dan secara drastis meningkatkan pengalaman pengguna, karena pengguna dapat memindahkan token di seluruh rollups tanpa masalah.

Namun, jembatan likuiditas juga memiliki kekurangan yang memengaruhi kegunaan menggunakan jembatan terukir rantai untuk mencetak representasi kanonik dari token pada rantai L2/L1.

Kekurangan jembatan likuiditas

1. Selip

Slippage adalah perbedaan jumlah token yang diharapkan dan diterima saat berinteraksi dengan AMM. Slippage terjadi karena AMM membanderol swap sesuai dengan likuiditas saat ini di dalam pool — penentuan harga ini bertujuan untuk menjaga keseimbangan antara saldo aset dalam pasangan setelah swap selesai, yang dapat berubah antara saat pengguna memulai perdagangan dan saat pertukaran dieksekusi.

Likuiditas rendah untuk aset yang dijembatani juga dapat meningkatkan slippage; jika kolam tidak memiliki cukup likuiditas untuk menyeimbangkan satu sisi kolam, perdagangan besar dapat menggeser harga dengan selisih yang besar dan mengakibatkan pengguna melakukan swap pada harga yang lebih tinggi. Arbitrer diharapkan dapat membantu mengoreksi disparitas antara kolam yang melakukan perdagangan aset yang sama tetapi mungkin tidak tertarik untuk melakukan perdagangan arbitrase yang melibatkan token dengan aktivitas/perdagangan atau nilai rendah.

Ini juga berdampak pada pengembang yang membangun aplikasi cross-chain karena mereka harus memperhitungkan kasus-kasus terjebak di mana terjadi selip; pengguna tidak dapat menyelesaikan operasi cross-chain karena menerima jumlah token yang lebih rendah di satu atau lebih rantai tujuan.

Aplikasi seperti agregator jembatan (yang tidak dapat mengetahui apakah jembatan likuiditas akan memiliki likuiditas yang cukup untuk menutup swap di rantai tujuan tanpa slippage) mengatasi masalah ini dengan menentukan toleransi slippage maksimum dan menggunakan informasi tersebut untuk memberikan kutipan kepada pengguna. Meskipun ini mencegah pembatalan transaksi, pengguna selalu kehilangan sebagian persentase token yang dijembatani — terlepas dari likuiditas dalam pool AMM jembatan.

2. Kendala Likuiditas

Tantangan mendasar dengan jembatan likuiditas adalah persyaratan mutlak untuk likuiditas yang cukup pada rantai tujuan. Tidak seperti jembatan kunci dan cetak tradisional di mana pencetakan token didukung langsung oleh aset terkunci, jembatan likuiditas bergantung pada token yang tersedia di kolam AMM untuk menyelesaikan transfer antar-rantai. Ketika likuiditas turun di bawah ambang batas kritis, mekanisme penghubung seluruhnya dapat berhenti berfungsi secara efektif.

• Operasi jembatan dapat berhenti sepenuhnya jika likuiditas turun terlalu rendah, mencegah pengguna menyelesaikan transfer yang dimaksud;
• Pengguna mungkin terpaksa membagi transfer besar menjadi transaksi kecil-kecil untuk menghindari habisnya likuiditas kolam;
• Selama periode volatilitas tinggi atau tekanan pasar, penyedia likuiditas mungkin menarik diri dari kolam, tepat ketika fungsionalitas jembatan paling dibutuhkan;
• Pembuatan pasangan token baru menjadi sangat menantang, karena diperlukan likuiditas awal yang signifikan untuk menjadikan jembatan ini beroperasi.

Persyaratan likuiditas menciptakan ketergantungan yang berputar: jembatan membutuhkan likuiditas yang substansial untuk berfungsi dengan baik, tetapi menarik penyedia likuiditas membutuhkan bukti penggunaan jembatan yang konsisten dan peningkatan biaya. Masalah ayam dan telur ini terutama terasa bagi token baru atau token yang jarang diperdagangkan, yang mungkin kesulitan mempertahankan likuiditas yang cukup di berbagai jaringan.

3. Insentif yang Tidak Sejalan

Jembatan likuiditas bermanfaat sejauh ia dapat mencakup pertukaran dari representasi yang terhubung ke token kanonik pada rantai tujuan tanpa pengguna mengalami slippage berlebihan; biaya gas berinteraksi dengan jembatan juga menentukan nilai jembatan likuiditas dari perspektif pengguna. Oleh karena itu, agregator jembatan dan tim proyek, yang menerbitkan token, memprioritaskan jembatan berdasarkan jumlah likuiditas dan biaya transaksi.

Meskipun ini memastikan pengguna menjembatani token proyek atau menggunakan agregator jembatan untuk mengirim token lintas rantai memiliki UX yang lebih baik, memilih jembatan berdasarkan likuiditas menempatkan jembatan yang tidak dapat dibelanjakan untuk insentif penyedia likuiditas (LP) pada posisi yang kurang menguntungkan. Selain itu, memilih jembatan berdasarkan biaya transaksi murni bias persaingan yang mendukung jembatan yang mengadopsi pendekatan terpusat untuk mengurangi biaya operasional dan dapat membebankan biaya yang lebih rendah pada transaksi jembatan. Dalam kedua kasus, jembatan tidak bersaing pada metrik yang paling penting: keamanan.

Jembatan berbasis likuiditas juga kurang mendukung aset ekor panjang dengan aktivitas perdagangan yang lebih rendah (sehingga lebih sedikit menarik LPs). Penerbit token ekor panjang (atau token baru dengan volume bridging rendah) harus menyiapkan kolam AMM dan memulai likuiditas untuk menutupi pertukaran token asli (yang diberi jembatan melalui jembatan likuiditas) terhadap representasi kanonik token penerbit atau bekerja dengan operator jembatan untuk meningkatkan insentif keuangan bagi LP untuk menyediakan likuiditas untuk aset tersebut.

4. Antarmuka penghubung yang buruk

Jembatan likuiditas merupakan perbaikan dari jembatan biasa namun juga memiliki masalah pengalaman pengguna (UX) yang tidak dapat dihindari. Selain mengalami slippage pada pertukaran lintas-rantai, pengguna mungkin tidak dapat menyelesaikan transaksi penyeberangan secara langsung pada rantai tujuan karena jembatan tidak memiliki likuiditas di pool yang cukup untuk menutupi perdagangan dengan token biasa pada rantai tujuan. Jembatan tidak dapat mengetahui berapa likuiditas yang akan ada pada pasangan aset ketika pesan pengguna untuk menukar token mencapai rantai tujuan, oleh karena itu kasus ini kebanyakan tidak dapat dihindari.

Pengguna memiliki dua pilihan dalam situasi ini (keduanya tidak optimal):

• Tunggu hingga jembatan memiliki likuiditas yang cukup untuk menyelesaikan swap dan menarik token kanonik. Ini suboptimal karena penundaan yang ditanggung dalam transaksi bridging dan karena pengguna tidak dapat mengetahui apakah mereka akan menerima jumlah token yang sama seperti yang dikutip awalnya karena likuiditas kolam dapat berubah sewenang-wenang dalam periode sangat singkat.
• Menerima representasi token khusus jembatan (misalnya, hUSDT untuk Hop Bridge). Ini suboptimal karena sebagian besar aplikasi akan lebih memilih untuk mengintegrasikan representasi resmi dari token asli (misalnya, opUSDT yang dicetak oleh Optimism Bridge) dan mungkin tidak menerima aset terbungkus pengguna.

2. Mencetak token kanonik melalui jembatan pihak ketiga yang kanonik

Sebuah dapp multi-chain dapat mengatasi masalah token jembatan non-fungible dengan memilih satu jembatan untuk mencetak representasi kanonik dari token dapp di setiap rantai tempat dapp diterapkan. Sama seperti jembatan kanonik yang mencetak representasi yang disetujui dari token proyek, pendekatan ini memerlukan pemetaan token yang dicetak di rantai remote ke kontrak token yang diterapkan pada rantai asal proyek - memastikan pasokan token tetap sama secara global. Penyedia jembatan harus melacak pencetakan dan pembakaran token serta memastikan operasi pencetakan dan pembakaran tetap selaras dengan pasokan token pada rantai asal.

Menggunakan satu penyedia jembatan tunggal memberikan lebih banyak fleksibilitas untuk tim proyek, terutama karena jembatan pihak ketiga memberikan insentif untuk mendukung penghubung antara berbagai ekosistem dibandingkan dengan jembatan kanonik yang hanya terhubung dengan paling banyak satu rantai. Jika jembatan ada di semua rantai di mana aplikasi diterapkan, pengguna dapat dengan cepat berpindah cross-chain tanpa perlu menarik kembali ke rantai asal; penyedia jembatan hanya perlu memastikan bahwa token yang dicetak di arus tujuan A dibakar sebelum pengguna mencetak token di arus tujuan B dan token kanonik on-chain B dipetakan kembali ke token di rumah rantai.

Masalah token terjembatani yang tidak dapat ditukar juga dihilangkan; asalkan pengguna menjembatani melalui penyedia jembatan yang disetujui, mereka selalu dapat menukarkannya 1:1 dengan token terjembatani lainnya. Pendekatan ini lebih memperbaiki masalah penghubungan likuiditas dalam model jembatan kanonikal:

• Pengguna tidak mengalami slippage pada transaksi jembatan karena penyedia jembatan tidak perlu mengkonversi representasinya terhadap representasi kanonikal melalui AMM - token penyedia jembatan adalah representasi kanonikal dari token yang dijembatani di setiap domain. Nilai dari representasi ini diikat pada nilai token yang terkunci oleh penyedia jembatan pada rantai asli token tersebut.
• Pengguna mengalami sedikit atau tanpa penundaan dalam bridging karena penyedia jembatan dapat mencetak representasi dibungkus di rantai tujuan segera setelah pesan mint() tiba di tujuan.
• Pengembang dapat melakukan outsourcing pengelolaan penyebaran token multi-rantai untuk menjembatani operator tanpa khawatir tentang bootstrap likuiditas AMM atau program insentif penyediaan likuiditas.

Beberapa contoh token penyedia jembatan tunggal di alam liar termasuk Token Fungible Omnichain (OFT) dari LayerZero, Layanan Token Antar Rantai (ITS) dari Axelar, xAsset dari Celer, dan anyAsset dari Multichain. Semua contoh sebenarnya adalah token propietari dan tidak kompatibel dengan representasi dari token yang sama yang dikirim melalui penyedia jembatan yang berbeda. Detail halus ini menyoroti beberapa masalah dengan pendekatan ini dalam menangani token yang memiliki jembatan. Yaitu sebagai berikut:

• Vendor lock-in
• Kehilangan kedaulatan
• Paparan yang tinggi terhadap kegagalan jembatan
• Kehilangan fitur-fitur khusus token di rantai target
• Terbatas pada rantai yang didukung vendor
• Ketidakmampuan untuk menjaga alamat token yang sama di semua rantai yang diinginkan, yang mungkin merugikan keamanan pengguna atau membuat mereka rentan terhadap phishing

Kekurangan menggunakan jembatan pihak ketiga kanonikal

1. Vendor lock-in

Memilih satu penyedia jembatan tunggal untuk mencetak representasi kanonik di satu atau lebih rantai mengekspos pengembang pada risiko ketergantungan pada vendor. Karena setiap penyedia jembatan mencetak representasi propietari yang kompatibel hanya dengan infrastruktur (dan proyek ekosistem terintegrasi) miliknya, model penyedia jembatan tunggal efektif mengunci penerbit token pada layanan bridging tertentu tanpa opsi untuk beralih ke jembatan lain di masa depan.

Memungkinkan untuk beralih penyedia jembatan, tetapi biaya beralihnya cukup tinggi sehingga membuat kebanyakan proyek enggan menggunakan rute ini. Untuk memberikan gambaran kasar, misalkan seorang pengembang (yang kita sebut Bob) telah mengeluarkan token (BobToken) di Ethereum dan memilih LayerZero OFT untuk mencetak versi kanonik BobToken di Optimism, Arbitrum, dan Base. BobToken memiliki pasokan tetap sebanyak 1.000.000 token, dan token yang dijembatani yang dicetak melalui LayerZero menyumbang 50% dari total pasokan BobToken yang beredar.

Kesepakatan bisnis berjalan lancar hingga Bob memutuskan pengguna lebih baik mempertemukan BobToken melalui layanan bridge pesaing (misalnya, Axelar). Namun, Bob tidak bisa tiba-tiba berkata, "Saya beralih ke Axelar ITS untuk mencetak representasi canonical BobToken di Optimism, Base, dan Arbitrum"; karena token OFT dan token ITS tidak kompatibel, Bob berisiko menciptakan masalah bagi pengguna lama maupun pengguna baru karena dua BobToken mungkin tidak dapat dipertukarkan (memperkenalkan masalah yang kami sebutkan sebelumnya). Selain itu, aplikasi yang terintegrasi dengan versi BobToken dari LayerZero tidak bisa menerima versi BobToken dari Axelar sebagai pengganti - yang memfragmentasi likuiditas untuk BobToken di berbagai rantai di mana representasi BobToken yang bersaing ada bersama.

Untuk membuat transisi tersebut menjadi mungkin, Bob perlu meyakinkan pengguna untuk membuka representasi BobToken yang dibungkus yang dicetak melalui LayerZero dengan mengirim transaksi yang membakar token OFT yang dijembatani dan membuka kunci BobToken di Ethereum. Pengguna sekarang dapat beralih ke representasi kanonikal baru BobToken dengan mengunci token dengan Axelar di Ethereum dan menerima BobToken kanonikal (dipetakan ke pasokan kontrak token di Ethereum) di rantai tujuan. Ini memerlukan biaya yang besar dan menimbulkan beban koordinasi dan operasional yang besar bagi tim manajemen proyek DAO, sehingga tetap menggunakan penyedia yang dipilih biasanya merupakan opsi yang paling aman.

Namun, ini membuat para pengembang seperti Bob dalam posisi sulit karena vendor lock-in membuatnya tidak mungkin beralih jika penyedia jembatan gagal mematuhi persyaratan perjanjian, memiliki fitur terbatas, kurangnya integrasi ekosistem yang luas, menyediakan pengalaman pengguna yang buruk, dll. Ini juga memberikan jembatan dengan leverage yang hampir tak terbatas: penyedia jembatan dapat melakukan hal-hal sembarangan seperti membatasi pengguna yang memindahkan BobTokens tanpa alasan yang jelas, menaikkan biaya pemindahan, atau bahkan menyensor operasi pemindahan. Tangan Bob terikat dalam hal ini, karena memutuskan hubungan bisnis dengan jembatan pihak ketiga yang cacat sama rumitnya dengan tetap berada dalam hubungan bisnis.

2. Kehilangan kedaulatan untuk protokol

Bagian penutup dari bagian sebelumnya tentang kunci vendor menyoroti masalah lain dalam menggunakan jembatan pihak ketiga khas: penerbit token mengorbankan kontrol atas token jembatan khas sebagai pertukaran untuk kenyamanan yang lebih besar dan peningkatan UX. Untuk menggunakan contoh sebelumnya: BobToken di Ethereum sepenuhnya dalam kendali Bob karena dia mengendalikan kontrak token ERC-20 yang mendasarinya, tetapi BobToken di Optimism, Arbitrum, dan Base dikendalikan oleh LayerZero, yang memiliki kontrak OFT yang menerbitkan representasi khas BobToken di blockchain tersebut.

Meskipun Bob mungkin mengharapkan LayerZero untuk menyelaraskan representasi kanonik dengan desain asli token asli, hal ini mungkin tidak selalu terjadi. Dalam skenario terburuk, perilaku BobToken di Ethereum bisa sangat berbeda dari BobToken di Optimism karena penyedia jembatan menerapkan versi kontrak token yang radikal berbeda - menciptakan masalah bagi pengguna protokol. Masalah ini juga dapat diperparah oleh dinamika prinsipal-agen di mana tujuan dan kepentingan protokol dan penyedia jembatan berbeda.

3. Paparan tinggi terhadap kegagalan jembatan

Pada pendekatan pertama, di mana token diterjang cross-chain melalui jembatan canonical setiap chain, risiko bagi penerbit token dari eksploitasi yang mempengaruhi satu jembatan terbatas pada jembatan tersebut. Misalnya, misalkan seorang peretas berhasil mengompromikan satu jembatan likuiditas dan mencetak jumlah tak terbatas dari token terbungkus tanpa menyetor jaminan. Dalam kasus tersebut, ia hanya dapat menarik hingga likuiditas maksimum yang tersedia untuk aset terbungkus di kolam likuiditas (misalnya, mencetak cUSDT di Optimism → tukar cUSDT dengan opUSDT canonical → tarik opUSDT ke Ethereum melalui jembatan cepat → tukar dengan USDT asli di Ethereum).

Dalam model jembatan kanonik pihak ketiga, risiko bagi penerbit token dari eksploitasi yang memengaruhi jembatan mitra setara dengan jumlah total token yang dimintakan oleh penyerang di rantai-rantai jarak jauh di mana jembatan yang terkena dampak telah dipasang. Hal ini memungkinkan karena setiap representasi kanonik di semua rantai dapat ditukar 1:1 dengan token kanonik yang diterbitkan di rantai-rantai lain:

Misalkan seorang penyerang berhasil mengambil alih jembatan pihak ketiga pada rantai B dan mencetak 1000 token (di mana token awalnya diterbitkan pada rantai A) tanpa menyetor jaminan. Token penyerang di rantai B tidak dipetakan ke kontrak rantai asal, sehingga tidak dapat menarik dari rantai A. Namun, dapat dilakukan pemetaan ke rantai C dan menukarkan 1000 token rantai B untuk 1000 token rantai C - ingat, setiap token lintas-rantai kompatibel dan dapat dipertukarkan karena berasal dari layanan jembatan yang sama. Token rantai C dipetakan ke kontrak rantai asal karena sah dicetak oleh pengguna yang mengunci token pada rantai A (rantai asal token), memungkinkan penyerang untuk membakar token pada rantai C dan menarik token asli pada rantai A dan kemungkinan menyelesaikan perjalanan dengan menukar token melalui CEX atau fiat offramp.

(Sumber)

Hilangnya fitur token khusus

Ketika menggunakan jembatan pihak ketiga yang sah, penerbit token sering kehilangan kemampuan untuk mengimplementasikan fitur khusus atau perilaku token yang ada dalam implementasi asli mereka. Hal ini terjadi karena penyedia jembatan cenderung menggunakan kontrak implementasi ERC-20 standar yang mungkin tidak mendukung fungsionalitas khusus yang ada dalam implementasi token asli.

Fitur token umum seperti delegasi voting (ZK), mekanisme rebasing (stETH, USDM), kemampuan fee-on-transfer (memecoins), fungsi blacklisting dan whitelisting (USDT, USDC), transfer yang dapat dijeda, dan aturan minting khusus atau izin sering dihilangkan ketika token dihubungkan melalui penyedia pihak ketiga, karena versi yang dihubungkan biasanya menggunakan implementasi ERC-20 dasar. Kehilangan fungsi ini menciptakan inkonsistensi dalam operasi token di berbagai chain dan dapat memecahkan integrasi yang bergantung pada fitur kustom ini.

Standardisasi token yang disilangkan, meskipun lebih sederhana dari perspektif penyedia jembatan, secara efektif mengurangi kemampuan token dan dapat menghambat kemampuan penerbit untuk menjaga perilaku token yang konsisten di seluruh ekosistem multi-chain dari aplikasi mereka. Masalah seperti ini dapat membuat ekspansi lintas-rantai menjadi mimpi buruk bagi para pengembang dan merupakan rintangan untuk mewujudkan impian aplikasi yang beroperasi di berbagai rantai.

Rantai yang didukung terbatas

Penerbit token menjadi bergantung pada jangkauan jaringan dan rencana ekspansi penyedia jembatan yang dipilihnya. Jika penyedia jembatan tidak mendukung jaringan blockchain tertentu yang ingin diperluas oleh penerbit token, mereka menghadapi dua pilihan suboptimal:

• Tunggu penyedia jembatan menambahkan dukungan untuk rantai yang diinginkan, yang mungkin memakan waktu lama atau tidak pernah terjadi karena tingginya biaya integrasi (misalnya ketidaksetaraan EVM ZKsync Era yang telah menyebabkan banyak dapp tidak pernah menggunakannya)
• Gunakan penyedia jembatan yang berbeda untuk rantai tersebut, yang memperkenalkan kembali masalah token non-fungibel dan fragmentasi likuiditas

Pembatasan ini dapat secara signifikan memengaruhi strategi pertumbuhan protokol dan kemampuan untuk menjangkau pengguna baru di rantai yang sedang muncul. Penyedia jembatan mungkin memprioritaskan mendukung rantai-rantai populer sementara mengabaikan jaringan-jaringan yang lebih kecil atau lebih baru yang bisa menjadi penting secara strategis bagi penerbit token.

Alamat token cross-chain yang tidak konsisten

Penyedia jembatan pihak ketiga mungkin menggunakan token terhubung dengan alamat yang berbeda di setiap rantai karena kekhasan tumpukan teknologi mereka - misalnya, tidak ada dukungan untukCREATE2. Kurangnya konsistensi alamat, pada gilirannya, menciptakan banyak masalah UX:

• Risiko keamanan: Pengguna harus memverifikasi alamat token yang berbeda di setiap rantai, meningkatkan risiko berinteraksi dengan token palsu;
• Kompleksitas integrasi: Pengembang harus mempertahankan daftar alamat token yang valid untuk setiap jaringan;
• Risiko phishing yang meningkat: Para pelaku jahat dapat dengan lebih mudah memperdaya pengguna dengan token palsu karena tidak ada alamat yang konsisten untuk diperiksa.

Kelemahan-kelemahan ini, dikombinasikan dengan masalah-masalah yang telah dibahas sebelumnya tentang terkunci pada vendor, kehilangan kedaulatan, dan paparan tinggi terhadap kegagalan jembatan, menyoroti keterbatasan signifikan dari mengandalkan jembatan pihak ketiga kanonikal untuk penyebaran token cross-chain. Pemahaman ini membantu menyiapkan panggung untuk mengapa solusi alternatif seperti ERC-7281 diperlukan untuk mengatasi tantangan ini dengan cara yang lebih komprehensif.

3. Mint token kanonikal melalui jembatan penerbit token

Jika seorang pengembang ingin mempertahankan kontrol maksimum dari implementasi cross-chain dari token proyek, ia dapat mengelola penerbitan representasi kanonik dari token di rantai terpencil. Ini digambarkan sebagai “percayai penerbit token,” karena nilai setiap representasi jembatan dari token terikat pada token yang terkunci di rantai asal oleh protokol yang bertanggung jawab atas penerbitan versi asli token di rantai sumber.

Untuk pendekatan itu berhasil, penerbit token harus menyiapkan infrastruktur untuk mengelola pencetakan dan pembakaran token jembatan cross-chain (sementara memastikan pasokan global tetap sejalan melalui pemetaan kanonikal).

Contoh-contoh menonjol dari representasi kanonik dari token yang dikeluarkan oleh pencipta token adalahTeleport MakerDAOdan Circle'sProtokol Transfer Cross-Chain (CCTP). Teleport memungkinkan pengguna untuk memindahkan DAI kanonikal antara Ethereum dan berbagai rollups Ethereum melalui operasi jalur cepat dan jalur lambat. DAI dibakar di satu rantai dan dicetak ulang di rantai target. CCTP berfungsi dengan cara yang sama dan memungkinkan transfer lintas rantai USDC asli (diterbitkan oleh Circle) melalui mekanisme pembakaran-dan-pencetakan ulang. Dalam kedua kasus, penerbit token mengendalikan pencetakan ulang dan pembakaran representasi kanonikal dari sebuah token.

Pendekatan ini menawarkan kontrol lengkap dari token jembatan untuk protokol. Dan itu memperbaiki masalah representasi non-fungible dari token yang sama dengan cara yang paling efektif yang mungkin - hanya ada satu versi kanonikal dari token (dicetak oleh penerbit di rantai tujuan), yang memastikan pengguna memiliki pengalaman yang sama menggunakan token di setiap ekosistem yang didukung oleh penerbit token.

Dengan pendekatan ini, aplikasi juga mendapatkan manfaat dari penghilangan fragmentasi likuiditas yang disebabkan oleh representasi tidak resmi, jembatan dari token protokol yang mengambang dalam ekosistem yang sama. Pengembang juga dapat membangun aplikasi cross-chain yang lebih kuat (misalnya, pertukaran cross-chain dan peminjaman cross-chain) karena jembatan penerbit token kanonikal memungkinkan perpindahan token yang efisien secara modal, mulus, dan aman antara rantai.

Namun, kelemahan dari jembatan pengeluarkan token kanonik adalah model ini hanya layak untuk proyek-proyek dengan modal yang cukup untuk menutup biaya overhead dalam menerapkan token cross-chain dan menjaga infrastruktur (orakel, penjaga, dll.) yang diperlukan untuk melakukan pencetakan dan pembakaran cross-chain. Ini juga memiliki efek yang kurang diinginkan yaitu mengikat keamanan aset yang terhubung dengan model keamanan protokol.

Hubungan ini (antara versi terhubung dari token suatu protokol dan keamanan protokol) bersifat bersahabat karena keamanan token asli yang mendukung representasi kanonik sudah bergantung pada keamanan protokol sehingga pengguna dan pengembang eksternal tidak mengambil asumsi kepercayaan baru. Ini terutama berlaku untukjembatan stablecoinDioperasikan oleh penerbit seperti Circle dan Maker (sekarang Sky) - pengguna sudah mempercayai penerbit stablecoin memiliki cukup aset untuk menutupi penebusan stablecoin untuk mata uang fiat, sehingga mempercayai keamanan jembatan stablecoin tidak sulit.

Namun ini juga mewakili titik kegagalan pusat—jika infrastruktur jembatan penerbit token terancam, nilai dari semua representasi kanonikal yang beredar di ekosistem multi-chain menjadi terancam. Ini juga berarti bahwa hanya penjaga terpusat (misalnya, Circle dalam kasus USDC) yang dapat menerapkan model penerbitan token jembatan kanonikal ini.

Pikiran akhir

Seperti yang ditunjukkan dalam laporan ini, fungibilitas aset cross-chain adalah bagian penting dari interoperabilitas rollup dengan implikasi bagi pengalaman berpindah antar rantai yang berbeda. Kemampuan token untuk tetap fungibel saat dihubungkan dengan rantai jarak jauh juga mempengaruhi pengalaman pengembang karena beberapa kasus penggunaan bergantung pada fitur ini.

Berbagai solusi telah diusulkan untuk menyelesaikan masalah token lintas-rantai yang tidak dapat dipindahtangankan–banyak di antaranya yang sudah kami bahas dalam laporan ini. Ini termasuk pencetakan token kanonikal melalui jembatan asli (dipatenkan), menggunakan jembatan pihak ketiga khusus untuk mencetak token kanonikal di beberapa rantai, dan menggunakan jembatan yang dimiliki protokol untuk memfasilitasi pergerakan token dan mempertahankan keluwesan.

Sementara pendekatan-pendekatan ini menyelesaikan masalah-masalah tertentu, namun gagal menangani semua isu dan menggunakan mereka untuk memungkinkan perwujudan aset lintas-rantai memerlukan beberapa kompromi yang tidak diinginkan. Bisakah kita menemukan pendekatan yang lebih baik? Jawabannya adalah ya.

ERC-7281 adalah pendekatan baru terhadap fungibilitas aset lintas-rantai yang mengurangi kompromi yang terkait dengan pendekatan yang ada. Juga dikenal sebagai xERC-20, ERC-7281 memungkinkan protokol untuk dengan efisien mendeploy token kanonikal pada berbagai rantai tanpa mengorbankan keamanan, kedaulatan, atau pengalaman pengguna.

Desain unik ERC-7281 memungkinkan beberapa jembatan (yang terdaftar dalam daftar putih) untuk mencetak versi kanonik dari token protokol pada setiap rantai yang didukung sambil memungkinkan pengembang protokol untuk menyesuaikan batas pencetakan secara dinamis berdasarkan jembatan. Fitur ini memecahkan banyak masalah yang terkait dengan proposal historis untuk token kanonik multichain, termasuk fragmentasi likuiditas, keselarasan insentif, kekhawatiran UX, risiko keamanan jembatan, kemampuan kustomisasi (token cross-chain), dan lain-lain.

Bagian berikutnya—dan terakhir—dari laporan kami yang terdiri dari dua bagian tentang ketergantungan aset cross-chain akan membahas ERC-7281 secara detail dan mengeksplorasi bagaimana standar token xERC-20 dapat memberi manfaat bagi pengembang dan pengguna. Kami akan membandingkan ERC-7281 dengan desain lain untuk token multichain yang khas, mengeksplorasi pendekatan xERC-20 terhadap token multichain yang khas, dan menyoroti pertimbangan bagi protokol dan pengembang yang ingin membangun berdasarkan standar tersebut.

Tetaplah bersemangat!

Penyangkalan:

1. Artikel ini dicetak ulang dari [2077 Penelitian]. Semua hak cipta adalah milik penulis asli [Alex HookdanEmmanuel Awosika]. Jika ada keberatan terhadap pencetakan ulang ini, silakan hubungi Belajar Gatetim, dan mereka akan menanganinya dengan cepat.
2. Penyangkalan Tanggung Jawab: Pandangan dan pendapat yang tertera dalam artikel ini semata-mata merupakan pendapat penulis dan tidak merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke bahasa lain dilakukan oleh tim Pembelajaran Gate. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.