Jika Anda belum membaca Bagian I dari seri How To Make Cross-Chain Tokens Fungible Again, Anda mungkin ingin periksa itu Pertama—ini menguraikan mengapa token yang dijembatani kehilangan fungibilitas dan tantangan yang ditimbulkannya. Di Bagian II, kami mengeksplorasi ERC-7281, standar baru yang merampingkan transfer token lintas rantai, meningkatkan keandalan, dan memberikan kontrol yang lebih besar kepada penerbit.

Perlunya Pendekatan yang Lebih Baik

Sejauh ini, kami telah mengeksplorasi berbagai solusi untuk masalah membuat token jembatan dapat dipertukarkan dan menyelesaikan masalah seputar fragmentasi likuiditas dan pengalaman pengguna yang buruk dari representasi non-kanonikal dari token asli yang beredar di blockchain non-asli:

• Menghasilkan representasi kanonikal dari token pada rantai remote melalui jembatan rollup/sidechain kanonikal
• Membuat representasi kanonik dari token di rantai jauh melalui layanan jembatan pihak ketiga
• Membuat representasi kanonik dari sebuah token pada rantai-rantai jarak jauh melalui layanan jembatan kanonik yang dioperasikan oleh penerbit token

Setiap pendekatan ini menunjukkan kompromi, sehingga wajar jika proposal ERC-7281 untuk membuat token jembatan yang dapat dipertukarkan berusaha mengambil yang terbaik dari setiap pendekatan untuk menciptakan solusi yang lebih holistik, efisien, dan mudah diakses untuk protokol yang ingin mendeploy token cross-chain tanpa mengorbankan keamanan, kedaulatan, atau pengalaman pengguna.

ERC-7281: Token Jembatan Berdaulat adalah proposal untuk memungkinkan pembuatan representasi kanonik dari token yang kompatibel dan dapat dipertukarkan dengan representasi yang dicetak oleh banyak jembatan yang berbeda. ERC-7281 bekerja dengan memperluas antarmuka ERC-20 untuk menyertakan:

• Fungsionalitas untuk mencetak dan membakar token ERC-20 kanonik;
• Kemampuan pemilik token untuk

1) menetapkan operator jembatan untuk mencetak dan membakar token saat dijembatani antara rantai;

2) Batasi laju pencetakan dan pembakaran token untuk setiap operator jembatan yang disetujui—misalnya, menetapkan batasan kecil untuk jembatan terpusat dan batasan yang lebih tinggi untuk protokol yang lebih aman.

Mengingat sedikit perbedaan antara token ERC-7281 dan ERC-20, penulis EIP telah menggambarkan yang pertama sebagai "xERC-20". Untuk pembaca yang membutuhkan gambaran umum tentang token ERC-20, OpenZeppelin memiliki panduan tentang topik.

Pada intinya, setiap kontrak token ERC-20 mengimplementasikan antarmuka ERC-20 yang mendefinisikan pasokan token global dan menyimpan informasi tentang alamat mana yang memiliki token dan seberapa banyak yang mereka miliki. ERC-20 juga mencakup fungsi-fungsi yang berguna untuk mengelola akses ke token pengguna (melalui persetujuan) dan mendapatkan informasi tentang sebuah token—seperti total pasokan beredar dan saldo dari suatu alamat tertentu.

Salah satu fitur tambahan yang ditambahkan oleh ERC-7281 ke spesifikasi ERC-20 adalah Lockbox opsional yang berfungsi sebagai kontrak pembungkus (mirip dengan kontrak WETH (Wrapped Ether)). Kontrak Lockbox membungkus token ERC-20 menjadi token xERC-20 melalui mekanisme mint-and-burn yang akrab dan membuat ERC-7281 kompatibel dengan kontrak token ERC-20 yang ada yang tidak memiliki antarmuka burn/mint dan tidak dapat diupgrade.

Dengan kerangka yang diperkenalkan dalam artikel sebelumnya, kita dapat mengategorikan ERC-7281 sebagai pendekatan "percayai penerbit token + percayai penyedia jembatan (disetujui)" untuk mencetak token multichain. Token ERC-7281 yang diterapkan di beberapa rantai dikendalikan oleh penerbitnya (berbeda dengan desain alternatif token lintas rantai yang biasanya membutuhkan melepaskan kedaulatan). Meskipun penerbit masih terpapar risiko insiden keamanan penyedia jembatan yang disetujui, penerbit mengelola risiko ini dengan memilih secara manual dan membatasi tingkat otoritas penyedia jembatan yang diizinkan.

Perbedaan besar, yang akan kita jelajahi dalam laporan ini, adalah bahwa penerbit token dapat mengkalibrasi eksposur terhadap peretasan dan eksploitasi jembatan dengan memberlakukan batasan dinamis pada berapa banyak token yang dapat dicetak/dibakar oleh operator jembatan tertentu. ERC-7281 juga memungkinkan penerbit token untuk memasukkan beberapa penyedia jembatan ke daftar putih untuk mencetak token kanonik yang sama di seluruh rantai, mengurangi ketergantungan pada satu penyedia untuk memproses operasi jembatan lintas rantai.

Kedua fitur tersebut menjadikan ERC-7281 peningkatan yang signifikan dibandingkan pendekatan tradisional untuk memfasilitasi penjembatanan lintas rantai token protokol dan memiliki efek orde kedua yang positif bagi pengguna, penyedia infrastruktur interoperabilitas (terutama agregator), dan pengembang aplikasi. Setelah membahas spesifikasi di bagian berikutnya, kita akan meninjau keuntungan—dan kerugian—penerapan ERC-7281.

Ikhtisar ERC-7281: Token jembatan berdaulat

Membakar dan mencetak token untuk pengguna

Dalam spesifikasi, sebuah proyek mendeploy kontrak token baru yang kompatibel dengan ERC20 yang mengimplementasikan antarmuka IXERC20. Operator jembatan mencetak token untuk pengguna di rantai tujuan setelah membakar deposit di rantai sumber. Proses pencetakan memeriksa bahwa jumlah token tidak melebihi batas jembatan dan memperbarui pasokan total token dan batas pencetakan jembatan jika berhasil.

Untuk token ERC-20 yang sudah ada, logika 'kotak kunci' diterapkan: penyedia jembatan membungkus token ERC-20 yang didepositkan oleh pengguna ke dalam token xERC-20 dengan mentransfernya ke kontrak Lockbox. Lockbox kemudian menyetujui jembatan untuk mencetak jumlah token xERC-20 yang setara.

Token xERC-20 yang dicetak oleh jembatan pada rantai tujuan dibakar pada rantai sumber menggunakan fungsi burn(). Proses ini memastikan bahwa jumlah token tidak melebihi batas pembakaran jembatan, meningkatkannya, dan mengurangi total pasokan token xERC-20. Lapisan transportasi jembatan menyampaikan pesan pembakaran ke tujuan. Kontrak jembatan di sisi tujuan memverifikasi pesan dan mencetak token xERC-20 dalam jumlah yang sama ke alamat pengguna di rantai tersebut. Pencetakan ini mengurangi total pasokan token dan batas pencetakan jembatan.

Untuk menjembatani token kembali ke rantai asal, operator jembatan membakar token xERC-20 di rantai remote, menyediakan alamat pengguna dan jumlah token. Tanda bakar tersebut diteruskan ke rantai asal oleh lapisan transportasi. Jika pesan bakar diverifikasi, operator jembatan mencetak dan membakar token xERC-20 baru di rantai asal untuk pengguna. Setelah validasi tanda bakar oleh kontrak token, operator jembatan melepaskan token ERC-20 yang disetor ke pengguna. Pembakaran token xERC-20 di rantai asal mengurangi pasokan total token dan batas pembakaran jembatan.

Sebuah poin penting: kontrak xERC-20 secara teknis dapat mencetak token tanpa jembatan memverifikasi bukti. Kami telah menggambarkan pendekatan standar (baca: diharapkan), tetapi jembatan yang tidak menerapkan jenis verifikasi pesan apa pun—atau menerapkan mekanisme baru untuk memverifikasi pesan lintas-rantai—dapat dimasukkan ke dalam daftar putih untuk mencetak dan membakar token xERC-20. Semuanya bergantung pada apa yang bisa diterima oleh penerbit token.

Batasan tingkat untuk pembuatan dan pembakaran token

Fungsi setBridgeLimits adalah fungsi yang dilindungi yang hanya dapat dipanggil oleh pemilik kontrak token. Fungsi ini memungkinkan pengaturan alamat kontrak jembatan dan menentukan jumlah maksimum token yang dapat diciptakan oleh jembatan (mintingLimit) dan dibakar (burningLimit) untuk pengguna. Pemilik dapat memperbarui batasan ini, memungkinkan penyesuaian kemampuan jembatan sesuai kebutuhan. Sebagai contoh, jika ditemukan isu keamanan dalam infrastruktur penyedia jembatan, mintingLimit dapat dikurangi untuk meminimalkan risiko. Sebaliknya, peningkatan keamanan dapat mengakibatkan peningkatan batas pencetakan.

Spesifikasi xERC-20 juga mencakup fungsi untuk memeriksa batas pembakaran dan pencetakan untuk jembatan yang disetujui untuk menangani token tersebut. "mintingMaxLimitOf" mengembalikan jumlah maksimum token yang dapat dicetak oleh jembatan, dan masing-masing, "burningMaxLimit" mengembalikan jumlah maksimum token yang dapat dibakar oleh jembatan selama periode tertentu. Selain itu, fungsi-fungsi ini menunjukkan sisa token yang dapat dibakar dan dicetak oleh jembatan sebelum mencapai batas yang telah ditetapkan.

Fungsi peninjau ini berguna bagi pengumpul jembatan yang perlu mengetahui batas yang tersedia untuk penyedia jembatan yang berbeda sebelum merutekan transaksi. Jika sebuah jembatan mencapai batas bakar atau mentahnya pada rantai sumber atau tujuan, itu dapat memengaruhi transaksi yang sedang berlangsung dan pengalaman pengguna. Oleh karena itu, pengumpul lebih suka merutekan permintaan ke jembatan yang belum mencapai batas pencetakan dan pembakarannya dan dapat melakukan pertukaran jumlah tertentu.

Parameter batas tarif

Spesifikasi antarmuka token xERC-20 mencakup struktur "Bridge" yang berisi "burningParams" dan "mintingParams" (parameter fungsi batas tarif token xERC-20 mengontrol berapa banyak token yang dapat dibakar dan dicetak oleh jembatan selama periode yang telah ditentukan). "maxLimit" mendefinisikan batas maksimum pencetakan dan pembakaran token dan meningkat setiap detik pada tingkat yang telah ditentukan ("ratePerSecond)."

Di sinilah kita mengatasi titik kebingungan yang mungkin terjadi: “maxLimit” (ditetapkan untuk batas pembakaran dan pencetakan) terdengar seperti batas pada operasi pencetakan dan pembakaran pada skala waktu tertentu—bukan batasan tingkat yang memperlambat pencetakan dan pembakaran sesuai dengan ambang batas yang telah ditentukan selama jendela waktu yang telah ditetapkan. “currentLimit” mendefinisikan seberapa banyak jembatan dapat mencetak atau membakar dan meningkat pada tingkat yang telah ditetapkan. Sebaliknya, “maxLimit” mendefinisikan seberapa banyak jembatan dapat mencetak atau membakar setiap hari.

Parameter pembakaran dan pencetakan sebagian besar terkait dengan pemilik token (dan operator jembatan secara kurang penting). Namun, batas maksimum dan batas saat ini adalah pertimbangan penting bagi pengguna dan operator jembatan. Misalnya, batas saat ini bisa memengaruhi seberapa banyak pengguna dapat dengan percaya diri menggunakan protokol cross-chain tanpa mengalami keterlambatan dalam menerima token xERC-20 di tujuan.

xERC-20 Lockbox

Token ERC-20 asli tidak menentukan fungsi untuk meningkatkan dan mengurangi pasokan token (waktu itu saat “tokenomics” berarti menghasilkan jumlah token tetap dan memberi tahu pengguna bahwa token memiliki nilai karena akan langka dalam beberapa tahun). Jadi, tidak setiap token ERC-20 memiliki fungsi pencetakan dan penghancuran. Karena ERC-7281 menggunakan mekanisme pencetakan dan penghancuran yang disukai oleh sebagian besar (jika tidak semua) jembatan saat ini, token ERC-20 warisan atau tidak dapat ditingkatkan tidak dapat bekerja secara langsung dengan ERC-7281.

Kontrak Lockbox memberikan solusi dan memungkinkan kompatibilitas mundur dengan token yang ada. Dalam spesifikasi asli (yaitu, sebuah proyek menyebarkan kontrak token baru yang mengimplementasikan antarmuka IXERC20), operator jembatan hanya perlu memanggil mint() untuk mencetak token bagi pengguna di rantai tujuan (setelah mengunci setoran pada rantai sumber).

Kontrak Lockbox banyak mengadopsi desain dari kontrak pembungkus WETH. Ini menerapkan fungsi deposit() untuk mendepositkan token ERC-20 yang sesuai di Lockbox dan fungsi withdraw() untuk operator jembatan membuka kunci token ERC-20 setelah membakar token yang dibungkus di domain remote.

Dua jenis kesalahan pertama yang ditonjolkan dalam spesifikasi ("IXERC-20Lockbox_NotNative" dan "IXERC-20Lockbox_Native") terjadi ketika pengguna mencoba mendepositokan token di kontrak Lockbox yang salah. Lockbox dapat menjadi asli atau non-asli, tergantung pada jenis token yang didukung.

Native Lockboxes menyimpan token asli—yaitu, token yang digunakan untuk membayar biaya gas kepada validator. Contoh token yang memiliki Lockbox asli untuk membungkusnya menjadi token xERC-20 adalah ETH: membungkus ETH ke dalam token xERC-20 akan membutuhkan panggilan fungsi depositNative() Lockbox dan menyetor ETH untuk menerima representasi ETH yang kompatibel dengan ERC7281.

Kotak penyimpanan Reguler (non-asli) menyimpan token ERC-20 seperti USDC, DAI, WETH, USDT, dll. Untuk mencetak USDC sebagai token xERC-20, misalnya, pengguna akan memanggil deposit() pada kontrak Lockbox setelah mengunci USDC.

Memanggil deposit() dengan ETH akan mengakibatkan dana tersebut terkunci selamanya karena kontrak Lockbox reguler hanya dapat membungkus dan membuka ERC-20 token. Memanggil depositNative() dengan token ERC-20 akan menghasilkan hasil yang serupa karena kontrak Lockbox asli dimaksudkan untuk bekerja dengan token asli, bukan token ERC-20.

Dengan cara ini, dengan membungkus token ERC-20 kanonik ke dalam token xERC-20 dengan dukungan mint/burn, Lockbox menyediakan lapisan kompatibilitas penting untuk standar. Namun, untuk beberapa kasus, seperti mengintegrasikan solusi bridging lainnya ke dalam xERC-20, hanya menggunakan kotak kunci, dan mengembalikan token yang dibungkus bukanlah pilihan. Untuk alasan ini, proyek dapat menerapkan kontrak adaptor.

Kontrak adapter

Dalam kasus di mana protokol bridging tidak dirancang untuk mengenali operasi yang melekat pada token xERC-20 (mint/burn, logging yang sesuai, dan semacamnya), aplikasi dapat membuat kontrak adaptor. Kontrak ini berfungsi sebagai pembungkus dan pembongkar otomatis—secara efektif menerjemahkan perilaku persetujuan + panggilan ERC-20 standar ke dalam skema mint/burn yang lebih bernuansa yang diperlukan oleh xERC-20.

Hal ini diperlukan karena banyak protokol bridge (misalnya, CCIP Chainlink) tetap dioptimalkan untuk perilaku ERC-20 konvensional. Kontrak adaptor dapat menjembatani (ba-dum-tss) kesenjangan kompatibilitas ini dengan mengabadikan logika seperti itu: ia menyetor token ke dalam Lockbox untuk menghasilkan representasi xERC-20 pada rantai sumber, dan kemudian, setelah menerima pesan pada rantai tujuan, itu memicu mekanisme penarikan untuk kembali ke aset kanonik.

Alur ini memastikan bahwa pengguna pada akhirnya menerima token kanonik yang konsisten—tidak terpengaruh oleh mekanisme pembungkusan yang didukung oleh xERC-20 di bawah tenda. Dengan cara ini, adaptor dapat memungkinkan protokol terintegrasi dengan mulus dengan jembatan yang tidak sesuai dengan xERC-20 dan meningkatkan spektrum solusi yang dapat dioperasikan yang mereka dukung.

Mengapa ERC-7281? Kasus untuk standar token jembatan berdaulat

Secara umum, ERC-7281 memiliki empat tujuan utama:

1. Fleksibilitas: Pengguna yang menjembatani token dari rantai asli token ke rantai lain (L1/L2) harus selalu menerima representasi kanonis dari token yang dijembatani di tujuan. Beberapa versi yang tidak dapat dipertukarkan dari token yang sama yang beredar dalam rantai non-native bermasalah karena alasan yang dijelaskan sebelumnya (misalnya, fragmentasi likuiditas dan komposisi token yang buruk).

Visi asli pembuatan spesifikasi ERC-20 adalah untuk memastikan fungibilitas dan interoperabilitas yang lancar antara token di Ethereum di berbagai aplikasi dan infrastruktur Ethereum. Namun, setelah mengadopsi peta jalan penskalaan yang berpusat pada rollup, muncul masalah kurangnya komposabilitas atomik, dan penciptaan banyak domain yang berbeda menurunkan properti fungibilitas tersebut. xERC-20 memungkinkan penggabungan likuiditas dari berbagai jembatan cross-rollup ke dalam token multi-rollup yang terpadu, mengembalikan visi awal Ethereum.

1. Keamanan: Untuk mengurangi risiko counterparty, penerbit token harus memiliki opsi untuk memilih dari penyedia jembatan yang bersaing sesuai dengan penilaian infrastruktur keamanan. Selain itu, penerbit token harus memiliki perlindungan yang berarti dari dampak insiden keamanan yang memengaruhi penyedia jembatan mitra—serangan terisolasi pada satu atau dua layanan jembatan tidak boleh menghapuskan seluruh TVL.

2. Bootstrapping bebas likuiditas untuk token lintas rantai: DAO protokol tidak boleh dipaksa untuk mengeluarkan sumber daya (keuangan) yang signifikan untuk bootstrapping likuiditas untuk token yang dijembatani sebagai bagian dari rencana ekspansi multi-rantai. Tidak hanya menjembatani berbasis likuiditas yang buruk untuk UX, tetapi pengeluaran untuk insentif penyediaan likuiditas mungkin menjadi tidak layak bagi tim proyek karena jumlah blockchain meningkat dalam waktu dekat.

3. Kedaulatan bagi penerbit token: Penerbit token harus tetap mengendalikan representasi kanonikal dari token protokol yang dicetak di rantai non-asli. Memecahkan masalah token jembatan yang tidak dapat dipertukarkan tidak boleh membutuhkan penyerahan kendali token jembatan proyek—terutama aspek administratif seperti mengendalikan pasokan total dan mengkonfigurasi mekanisme pencetakan dan pembakaran—ke jembatan pihak ketiga.

Kita dapat memperluas lagi tujuan-tujuan ini untuk melihat manfaat apa yang ERC-7281 berikan bagi protokol dan komunitas.

Menganalisis manfaat dari ERC-7281

Meningkatkan UX dan menghilangkan fragmentasi likuiditas

ERC-7281 memecahkan berbagai versi masalah ketergantungan jalur yang dijelaskan dalam pendahuluan.

Ketergantungan jalur bisa spesifik sesuai rantai (misalnya, ETH disilangkan dari Ethereum → Arbitrum → Optimism berbeda dari ETH disilangkan dari Ethereum → Optimism → Arbitrum) atau spesifik sesuai jembatan (misalnya, ETH disilangkan dari Ethereum ke Optimism melalui Celer berbeda dari ETH disilangkan dari Ethereum ke Optimism melalui Connext).

Ketergantungan jalur adalah fitur keamanan berharga, namun dapat juga merugikan dalam menghubungkan UX dan komposabilitas cross-chain. Sebagai contoh, seorang pengguna tidak dapat menyediakan likuiditas secara programatis ke DEX cross-chain yang beroperasi di Optimism dan Arbitrum karena aplikasi harus menerima opETH atau arbETH.

ERC-7281 mengatasi masalah tersebut dengan memperkenalkan token xERC-20 yang tetap dapat dipertukarkan tanpa peduli berapa kali seorang pengguna memindahkan lintas rantai atau penyedia jembatan apa yang digunakan untuk memindahkan token. Misalkan seorang pengguna ingin memindahkan USDT yang dibungkus dari Arbitrum ke Optimism tanpa menarik terlebih dahulu ke Ethereum; seorang penyedia jembatan dapat membakar token xERC-20 di Arbitrum dan mencetak ulang xERC-20 di Optimism — nilai token yang dicetak ulang di Optimism masih dipatok ke token yang disimpan di Lockbox dan dipetakan ulang untuk mempertahankan dukungan 1:1 mereka.

Yang penting, ERC-7281 memberikan manfaat penerapan token jembatan kanonik seperti CCTP (Cross-Chain Transfer Protocol) Circle tanpa mengharuskan protokol memiliki penyimpanan terpusat dari token yang dijembatani. Misalnya, likuiditas dikonsolidasikan di sekitar representasi kanonik token proyek, yang meningkatkan utilitas token untuk aplikasi DeFi dan mengurangi overhead untuk membuat pasar yang berbeda untuk versi yang berbeda dari aset yang sama.

Menguatkan kedaulatan bagi penerbit token

xERC-20 digambarkan sebagai "token jembatan berdaulat" karena penerbit token tidak terkunci untuk menggunakan opsi tertentu untuk mencetak representasi kanonik token dan mempertahankan kendali atas desain dan administrasi token yang dijembatani di seluruh penerapan. ERC-7281 adalah hibrida antara "mencetak token kanonik melalui jembatan pihak ketiga" dan "mencetak token kanonik melalui jembatan yang dikendalikan penerbit token" yang menggabungkan kedaulatan, pengalaman pengguna, dan desentralisasi dalam paket yang sama.

Proyek yang menyebarkan token lintas rantai dengan ERC-7281 dapat mencetak representasi kanonik token asli melalui beberapa jembatan tanpa mengalami masalah versi yang tidak dapat dipertukarkan dari aset asli yang sama, merusak UX bagi pengguna yang berharap dapat memanfaatkan komposabilitas dan fungibilitas token ERC-20. Proyek semacam itu juga mempertahankan tingkat kontrol yang sama atas penyebaran token lintas rantai sebagai penerbit token yang menjalankan infrastruktur internal untuk mengelola transfer token kanonik antar domain karena kontrak token xERC-20 dan Lockbox—yang digunakan jembatan untuk mengunci, mencetak, dan membakar token untuk pengguna—digunakan dan dikendalikan oleh proyek.

Fitur yang sederhana ini dapat berguna dalam kasus di mana proyek terkemuka memiliki token native yang diterbitkan pada chain asal. Pengguna dari ekosistem lain ingin terpapar pada token tanpa harus menyimpannya pada chain asalnya karena berbagai alasan.

Namun, proyek ini tidak memiliki kapasitas atau kemauan untuk menjalankan infrastruktur jembatan internal untuk setiap rantai untuk memastikan kompatibilitas 1:1 antara token yang dijembatani—juga tidak ingin mengalihkan kendali tokennya ke pihak ketiga yang belum tentu selaras dengan protokol dan komunitasnya. Kasus seperti itu menjadi pertimbangan ketika menerapkan tata kelola lintas rantai yang memungkinkan pemungutan suara dengan token yang dijembatani sementara suara dihitung pada rantai asli; Penyedia jembatan yang tidak selaras dengan kontrol token yang dijembatani menjadi titik tersedak untuk tata kelola protokol.

Beefy, protokol yield farming, juga telah mengadopsi xERC-20 untuk alasan ini. Seperti yang dijelaskan oleh dokumentasi jembatan proyek, ERC-7281 memberi proyek lebih banyak opsi untuk menjembatani token—yang menjadi diperlukan setelah mitra jembatan utama mengalami peretasan (tema yang dengan cepat menjadi akrab bagi penduduk asli kripto)—dan memberikan kontrol yang lebih halus dari desain mekanisme penghubung. Dalam kasus Beefy, fitur daftar yang diizinkan ERC-7281 memungkinkan protokol untuk memilih berbagai mitra penghubung dan menawarkan opsi berbeda kepada pengguna antara mengoptimalkan kecepatan, desentralisasi, biaya, dan keamanan saat menjembatani token mooBIFI.

Penataan ulang insentif meningkatkan persaingan terbuka dan keamanan

Bridging berbasis likuiditas sering kali mendukung proyek dengan kapasitas finansial untuk membelanjakan insentif likuiditas — karena penerbit token ingin menghabiskan sedikit untuk insentif LP dan menawarkan UX bridging yang unggul, likuiditas menjadi faktor paling penting untuk protokol yang menggunakan jembatan L1/L2 kanonik. Ini juga meluas ke pemilihan penyedia jembatan oleh agregator jembatan, yang bisa dibilang mempersulit layanan jembatan baru (bahkan yang memiliki infrastruktur yang aman) untuk bersaing dengan protokol jembatan yang lebih mapan.

ERC-7281 memperbaiki masalah dengan menghilangkan kebutuhan akan bridging berbasis likuiditas. Tanpa perlu mencetak dan menukar token non-kanonik dengan token kanonik, jembatan dalam ukuran apa pun dapat disetujui untuk mencetak token proyek di domain jarak jauh. Karena penerbit token ingin meminimalkan eksposur terhadap kegagalan jembatan, lebih banyak protokol kemungkinan akan mulai lebih memperhatikan desain keamanan jembatan lintas rantai daripada berfokus pada likuiditas terlebih dahulu.

Hal ini mendorong persaingan terbuka karena menjadi kasus dari "biarkan jembatan yang paling aman menang" dan bukan "biarkan jembatan yang paling likuid menang"; persaingan terbuka ini dapat berupa jembatan bersaing pada fitur-fitur lebih dari sekadar likuiditas/keamanan (misalnya, biaya, API/SDK, integrasi aplikasi, dll.). Fitur-fitur ini secara argumen lebih mudah diimplementasikan ke dalam aplikasi sejak awal karena terutama bergantung pada keahlian tim pengembangan; sebaliknya, likuiditas dan volume bridging lebih kompleks untuk diinisialisasi dan memerlukan campuran pengembangan bisnis, pendanaan, koneksi industri, pemasaran, dan lainnya.

Manajemen risiko yang lebih baik untuk penerbit token

ERC-7281 memperkenalkan batas tarif yang dapat dikonfigurasi pada pencetakan token dan pembakaran yang secara dramatis meningkatkan profil risiko untuk protokol yang bekerja dengan jembatan pihak ketiga untuk mencetak token kanonikal di rantai non-asli. Jika penyedia jembatan mitra diretas atau dikompromikan, kerusakan terbesar yang dapat disebabkan oleh penyerang sama dengan batas yang ditugaskan ke jembatan yang dikompromikan. Jika penerbit token memilih parameter pembatasan tarif dengan hati-hati, serangan terisolasi pada jembatan seharusnya memiliki dampak minimal pada kesolvenan protokol.

Mengonfigurasi batas kecepatan per jembatan juga dapat meningkatkan proses penilaian risiko untuk DAO protokol. Saat ini, penilaian risiko jembatan dapat memakan waktu berbulan-bulan untuk diselesaikan karena besarnya dampak dari jembatan pihak ketiga kanonis yang diretas; Protokol ingin memastikan untuk membuat keputusan yang dapat dipertahankan, di mana keamanan jembatan yang dipilih diteliti secara ekstensif untuk memberikan jaminan keselamatan yang lebih kuat kepada masyarakat. Selain membuang-buang tenaga dan waktu yang tidak perlu, analisis maraton keamanan jembatan masih tidak menjamin bahwa jembatan yang dipilih kebal terhadap eksploitasi zero-day.

Mengadopsi ERC-7281 membuat penilaian risiko menjadi lebih dinamis. Proyek masih harus melengkapi pemeriksaan yang jelas pada penyedia jembatan untuk memilih properti pembatasan tingkat yang sesuai; namun, jangka waktu evaluasi risiko dapat dikurangi untuk mencerminkan bahwa protokol tidak lagi berada dalam posisi all-or-nothing. Alih-alih menghabiskan berbulan-bulan menganalisis beberapa jembatan untuk memilih satu opsi, sebuah proyek dapat menghabiskan setengah waktu untuk memilih beberapa penyedia jembatan secara awal dan menetapkan batasan penerbitan yang bervariasi berdasarkan penilaian keamanan. Penerbit token kemudian dapat melakukan tinjauan keamanan untuk menentukan apakah akan meningkatkan atau mengurangi batasan penerbitan untuk mitra jembatan tertentu atau menarik hak penerbitan dari suatu jembatan (misalnya, sebagai respons terhadap peretasan atau pengungkapan kerentanan).

ERC-7281 juga mengurangi hambatan bagi proyek yang ingin memilih kemajuan mutakhir dalam keamanan jembatan tetapi ragu-ragu untuk mengadopsi teknologi tertentu secara keseluruhan sampai teknologi tersebut telah diuji dalam pertempuran dan diperiksa secara ketat oleh komunitas (yaitu, dilema inovator). Misalkan penyedia jembatan mengusulkan infrastruktur baru yang dilaporkan secara substansial meningkatkan jaminan keamanan. Dalam hal ini, protokol dapat "menguji perairan" dengan menetapkan hak pencetakan terbatas ke jembatan dan secara progresif meningkatkan batas pencetakan jembatan saat kepercayaan pada desain sistem yang diusulkan meningkat.

Sama seperti menghilangkan masalah terkait likuiditas, menghilangkan kebutuhan akan protokol untuk mempercayai tumpukan teknologi jembatan 100% sebelum memberikan hak pencetakan menciptakan persaingan yang setara antara pendatang baru dan pemain lama—pemain lama memiliki insentif untuk mengulangi pendekatan keamanan yang lebih baik karena penerbit token sekarang memiliki fleksibilitas untuk menarik hak pencetakan dan menetapkan kembali ke proyek yang lebih kecil hanya karena yang terakhir telah menunjukkan komitmen yang lebih tinggi terhadap keamanan dan desentralisasi. Ini juga menghilangkan faktor risiko lain untuk protokol yang bekerja dengan jembatan pihak ketiga: risiko bahwa penyedia jembatan yang dipilih berhenti berinovasi pada keamanan meskipun kecepatan cepat di mana kelemahan dan masalah dalam keamanan jembatan diungkapkan dan ditemukan karena mengetahui penerbit token tidak dapat menegakkan tindakan hukuman (misalnya, bermigrasi ke penyedia jembatan lain) karena kesulitan menjalankan aktivitas tersebut.

Meningkatkan komposabilitas antar ekosistem

Membangun alur kerja aplikasi yang rumit yang memerlukan routing token melalui sejumlah rantai menjadi sulit saat ini karena harga yang tidak terduga dari jembatan berbasis likuiditas. Sebagai contoh, aggregator jembatan yang menghubungkan dari Ethereum → Linea → Base memiliki dua opsi:

1. Atur parameter toleransi geseran dan eksekusi harga dari routing cross-chain berdasarkan jumlah minimum token yang akan diterima pengguna di setiap rantai (tergantung pada jumlah likuiditas yang tersedia ketika pesan bridging tiba di setiap lapisan).
2. Jangan atur parameter toleransi geseran; sebaliknya, buat logika untuk mengambil likuiditas on-chain (misalnya, melalui DEXes) jika jumlah token yang diterima di satu atau lebih rantai lebih rendah dari jumlah yang diharapkan.

Sebagai perbandingan, pengumpul jembatan dapat mengetahui di muka berapa banyak token yang seharusnya mereka harapkan di setiap domain yang terlibat dalam transaksi cross-chain dengan memeriksa mintingLimit dan burningLimit untuk jembatan yang diizinkan untuk mencetak token tertentu. Dapat diketahui, sebuah jembatan dapat mencapai batas maksimum antara waktu penyiaran transaksi dan transaksi mencapai domain—yang berarti pengguna tidak dapat menerima token kanonikal di tujuan.

Namun, ERC-7281 masih merupakan peningkatan dalam hal ini dengan alasan berikut:

1. Jika operator jembatan mencapai mintingLimit saat transaksi sedang berlangsung, transaksi jembatan ditahan dan dicoba lagi nanti ketika parameter batas tarif disesuaikan. Pengguna tidak menerima representasi terbungkus eksklusif dari token kanonik—tidak seperti jembatan likuiditas saat ini.
2. Agregator jembatan memiliki lebih banyak prediktabilitas tentang kapan transaksi bridging akan dieksekusi dan jumlah token yang diharapkan. Karena mintingLimit dan burningLimit dikonfigurasi untuk menggunakan blok sebagai ukuran waktu (seperti yang ditunjukkan pada bagian tentang parameter pembatasan laju), mudah untuk menghitung kapan jembatan akan mulai mencetak dan membakar token lagi; sebaliknya, memprediksi kapan likuiditas akan meningkat di jembatan setara dengan bermain roulette Rusia.

Pergeseran likuiditas yang tidak dapat diprediksi juga berarti ketidakpastian dalam penetapan harga transaksi bridging yang dicoba ulang. Misalkan agregator bridge (atau aplikasi lain) menempatkan penawaran untuk swap lintas rantai berdasarkan harga saat ini dari pasangan token di pool likuiditas bridge (harga ini didasarkan pada total likuiditas pool). Namun, transaksi tidak dapat dieksekusi karena penurunan tajam dalam likuiditas pool. Misalkan perdagangan diadakan dan dicoba lagi nanti. Dalam hal ini, pengembang aplikasi tidak dapat mengetahui apakah kutipan sebelumnya tetap akurat atau apakah likuiditas akan mencapai tingkat yang sama seperti saat pengguna pertama kali mengirimkan transaksi.

Karena menjembatani token xERC-20 tidak tunduk pada pergerakan likuiditas, pengguna dapat yakin bahwa transaksi cross-chain tidak akan menimbulkan slippage—bahkan jika tidak segera dieksekusi.

Bridging aggregator bukan satu-satunya yang mendapat manfaat dari peningkatan komposabilitas ini; aplikasi lintas rantai apa pun dapat memanfaatkan fungibilitas token xERC-20 untuk membuat aplikasi yang lebih menarik. Ini lebih sulit saat ini karena masalah seputar ketergantungan jalur: misalkan pengembang ingin menjembatani ETH dari Ethereum, membuka posisi pinjaman pada Arbitrum DEX, dan menggunakan keuntungannya untuk membeli NFT di Optimism sebelum menjembatani kembali ke Ethereum. Di sini, pengembang harus memastikan untuk berintegrasi dengan penyedia jembatan pada rantai tersebut—karena Anda tidak dapat dengan mudah menukar versi kepemilikan—yang tidak terjadi setelah token jembatan proyek dapat dipertukarkan setelah mengadopsi xERC-20.

Alur kerja ini mirip dengan jembatan penerbit token yang dijelaskan sebelumnya. Mari kita ambil Circle CCTP sebagai contoh:

Protokol Transfer Lintas Rantai Circle memungkinkan pengguna untuk memiliki versi kanonik terpadu dari token USDC-nya tanpa terjebak dalam ekosistem rantai mereka. Semua transfer lintas rantai diproses melalui protokolnya menggunakan skema burn-and-mint.

Namun, saat CCTP adalah protokol terpusat, karena operator Circle adalah satu-satunya entitas yang diotorisasi untuk membakar dan mencetak token USDC-nya, xERC-20 melikuidasi risiko kepercayaan dengan memungkinkan beberapa entitas dengan berbagai mekanisme keamanan untuk mengoperasikan transfer cross-chain.

Mendukung visi Ethereum tentang masa depan multichain yang berpusat pada rollup

ERC-7281 dapat mempercepat peta jalan rollup-centric Ethereum dengan memberikan kepercayaan kepada proyek untuk menyebarkan token pada EVM L2 baru yang mungkin tidak memiliki profil keamanan yang kuat dari rantai L2 yang sudah mapan. Misalnya, jembatan kanonik dari rollup tahap 0 kurang aman karena Ethereum L1 tidak menjamin keamanan jembatan. Sebuah proyek token secara perlahan dapat diluncurkan ke rantai seperti itu dengan memberikan hak pencetakan terbatas ke jembatan kanonik dan meningkatkan batas pencetakan setelah rollup maju ke tahap 1.

Proses ini dapat terus berlanjut hingga L2 mencapai tahap 2 (tahap tertinggi desentralisasi dan keamanan untuk rollup). Mekanisme di mana protokol dapat diterapkan pada rantai yang baru diluncurkan dengan cara yang meminimalkan risiko memberikan manfaat bagi ekosistem Ethereum dengan membuat lebih mudah bagi L2 baru untuk menggalang likuiditas token dan aplikasi sambil mendorong lebih banyak inovasi dalam ruang desain rollup.

Potensi kelemahan penerapan ERC-7281

Peningkatan overhead untuk tim manajemen proyek DAO

Meskipun ERC-7281 sangat menarik bagi protokol, DAO mungkin ragu untuk mengadopsi token xERC-20 karena beban operasional yang signifikan yang harus ditanggung tim proyek DAO untuk mengelola token xERC-20 pada berbagai implementasi.

Gerard Persoon’s Kelola token yang dijembatani pada sejumlah besar rantaitermasuk daftar yang tidak lengkap dari tugas-tugas satu kali maupun berkala yang harus dilaksanakan oleh protokol setelah bermigrasi dari ERC-20 ke xERC-20:

Itu adalah daftar tugas yang sangat panjang

Solusi yang diusulkan adalah bagi DAO untuk mengalihdayakan beberapa tugas administratif yang terkait dengan pengelolaan token xERC-20 lintas rantai ke layanan pihak ketiga, tetapi ini hanya menukar satu tradeoff (biaya sumber daya manusia) dengan yang lain (biaya perekrutan layanan).

Misalkan sebuah protokol sebelumnya mengelola token cross-chain dengan infrastruktur internal (misalnya, mendeploy kontrak token terpisah per rantai dan mengendalikan pencetakan dan pembakaran). Dalam hal ini, ERC-7281 tidak terlihat seperti perubahan radikal. Namun, proyek-proyek yang biasa mengontrak manajemen infrastruktur jembatan inti ke tim pengembangan jembatan akan menemukan beban kerja tambahan yang mengkhawatirkan.

Misalnya anggota tim inti Lido diuraikan(sebagai tanggapan terhadap proposal untuk Lido mendeploy wstETH sebagai token xERC-20 di semua implementasi) tanggung jawab saat ini dari tim PM yang berkaitan dengan infrastruktur interoperabilitas dan dibandingkan dengan kumpulan tanggung jawab yang sama dengan anggota tim harus mengasumsikan jika DAO Lido memutuskan untuk memiliki wstETH di semua domain bermigrasi ke versi xERC-20.

Seperti yang ditunjukkan oleh percakapan di atas, mengelola token xERC-20 menimbulkan peningkatan biaya administrasi yang tidak bisa diabaikan bagi protokol dan anggota komunitas. Sebagai contoh, batasan jembatan memerlukan pemantauan aktif dan evaluasi keamanan jembatan untuk memberi informasi penyesuaian batasan pencetakan, dan keputusan seputar batasan jembatan (atau penarikan/pemberian hak pencetakan) mungkin menjadi subjek pemungutan suara DAO (jika pilihan-pilihan tersebut perlu sering dibuat, anggota DAO mungkin mengalami kelelahan pemilih).

Namun, ini tidak boleh ditafsirkan sebagai penilaian nilai pada ERC-7281. Setiap proyek akan memiliki profil risiko, tujuan jangka panjang, dan sumber daya yang berbeda—dan faktor-faktor ini secara kolektif menentukan apakah manfaat jangka panjang dari mengadopsi ERC-7281 lebih besar daripada biaya jangka pendek dan berkelanjutan untuk melakukannya.

Misalnya, proyek yang lebih kecil mungkin merasa lebih sulit untuk mengelola overhead penerbitan token xERC-20 dan memilih untuk memilih layanan bridging token multichain terkelola seperti ITS (Interchain Token Service) Axelar atau NTT (Native Token Transfers) Wormhole. Proyek yang lebih mapan mungkin memiliki sumber daya untuk mengelola biaya administrasi dan operasional penerbitan token xERC-20 dan dapat mempertimbangkan kontrol yang diberikan oleh ERC-7281 sepadan dengan overhead ekstra untuk mengelola token lintas rantai.

Kesulitan seputar memigrasikan token yang sudah ada ke standar xERC-20

Untuk proyek-proyek yang tidak memiliki antarmuka mint/burn, atau tidak dapat meningkatkan kontrak token untuk menggunakan IERC20 melalui pewarisan, dan sudah memiliki representasi kanonik dari token asli yang beredar di rantai non-asli, bermigrasi ke token xERC-20 adalah proses yang memakan waktu yang membutuhkan koordinasi yang besar dan melibatkan jaringan peserta yang kompleks—mulai dari pemegang token, bursa (DEXes dan CEXes), jembatan mitra, dan aplikasi yang terintegrasi dengan token ERC-20 warisan. Bahkan setelah bagian ini ditangani, protokol masih menanggung biaya membuka ERC-20 menjadi xERC-20 untuk menyelesaikan proses migrasi.

Seperti yang dijelaskan dalam pembahasan spesifikasi ERC-7281, token yang ada perlu dikunci di Lockbox untuk mencetak xERC-20 yang dibungkus untuk pengguna. Penghentian ERC-20 warisan terjadi tak lama setelah itu dan melibatkan proses berbagi komunikasi yang berkepanjangan dengan komunitas seputar garis waktu untuk membekukan pencetakan token ERC-20 (warisan) baru. Sekali lagi, ini mungkin sepadan dengan biaya dari perspektif protokol—meskipun manfaatnya mungkin juga tidak cukup untuk membenarkan biaya mengoordinasikan migrasi seluruh ekosistem ke representasi token protokol yang kompatibel dengan xERC20.

Permukaan risiko yang lebih besar untuk tata kelola DAO

Mengelola token xERC-20 di beberapa domain dengan ERC-7281 membutuhkan tata kelola aktif dari DAO yang mengawasi protokol. Ini melibatkan pengaturan parameter seperti batas pencetakan, meningkatkan kontrak Lockbox, dan menjeda pencetakan atau pembakaran token. Keputusan ini sensitif terhadap keamanan dan harus diatur oleh DAO untuk menghindari tanggung jawab atas keputusan ruang rapat tertutup.

ERC-7281 bertujuan untuk memberikan kontrol protokol atas keputusan ini daripada jembatan pihak ketiga. Ini masuk akal, karena DAO sudah mengelola token di rantai asli mereka, jadi memperluas tata kelola mereka ke token di rantai lain masuk akal untuk protokol dan komunitas yang mencari kontrol ini. Namun, beberapa protokol mungkin tidak menginginkan kontrol DAO ekstra ini karena kekhawatiran tentang tata kelola dan stabilitas.

Misalnya, proyek profil tinggi seperti Lido menghadapi pengawasan atas masalah tata kelola. Menambahkan kontrol atas manajemen token meningkatkan risiko pengambilalihan tata kelola. Serangan tata kelola dapat memiliki efek luas jika sebuah proyek mengkonsolidasikan semua token ERC-20 ke dalam Lockbox dan DAO mengaturnya. Penyerang dapat memperoleh kendali atas Lockbox dan memperkenalkan penyedia jembatan berbahaya tanpa batas pencetakan, membuat token xERC-20 di rantai lain tidak berharga.

Skenario ini memiliki paralel dengan eksploitasi Multichain, di mana kerentanan dalam infrastruktur tanda tangan komputasi multipihak (MPC) memungkinkan peretas untuk mengompromi alamat Multichain utama yang mengawasi token asli di Ethereum dan Dogecoin—token-token ini mendukung token yang dicetak di rantai non-asli seperti Fantom dan Moonriver, yang menciptakan efek domino yang mengakibatkan proyek-proyek lain menderita kerugian akibat serangan terhadap kontrak pintar Multichain di Ethereum dan Dogecoin.

Tidak kompatibel dengan protokol yang maksimal terdesentralisasi

ERC-7281 sesuai dengan tujuan ketika token dikeluarkan oleh protokol dengan tata kelola token atau entitas terpusat (misalnya, USDC Circle atau Stablecoin CZKC). Namun, tidak seberharga jika protokolnya terdesentralisasi secara maksimal dan tidak memiliki tata kelola formal—stablecoin LUSD Liquity adalah contoh token yang sulit dibuat kompatibel dengan standar xERC-20.

Token xERC-20 memerlukan entitas untuk memutuskan parameter tertentu seperti batas penambangan dan pembakaran, serta membuat keputusan apakah akan memberikan daftar putih kepada penyedia jembatan tertentu atau tidak. Hal ini mengimplikasikan kebutuhan akan tata kelola yang berkelanjutan untuk keberadaan token xERC-20. Bagi proyek-proyek yang ingin mendekantralisasi komponen-komponen kritis dari protokol—seperti kontrak token DAO—seiring waktu, hal ini dapat menimbulkan masalah dan mempersulit rencana-rencana desentralisasi.

Risiko yang lebih besar dari eksploitasi yang memengaruhi komponen inti (kontrak Lockbox dan penyedia jembatan)

Kami sudah menyebutkan bagaimana ketergantungan jalur bekerja dan mengapa hal itu membantu memberikan jaminan bahwa eksploitasi yang memengaruhi rantai A tidak akan memengaruhi rantai B, atau bahwa eksploitasi yang melibatkan jembatan A di rantai A tidak akan mempengaruhi jembatan B di rantai B. ERC-7281 menghapus ketergantungan jalur, yang memiliki manfaat, tetapi juga memperkenalkan sebuah trade-off seputar keamanan:

Liquidity yang tersedia maksimum dalam sebuah jembatan tidak lagi mewakili batas atas potensi dampak dari eksploitasi jembatan terhadap penerbit token, karena token yang dicetak oleh penyedia jembatan yang berbeda dapat dipertukarkan di berbagai domain. Penulis ERC-7281 mengusulkan untuk memilih batas tarif bagi penyedia jembatan berdasarkan jumlah yang bisa dihabiskan oleh penerbit token untuk mengganti kerugian dari pencetakan palsu; meskipun demikian, batas tarif yang dipilih mungkin terlalu konservatif dalam retrospeksi.

Jika jembatan dengan batas yang tinggi dikompromikan, dampaknya dapat terasa bahkan bagi pengguna jembatan lain yang menghasilkan token yang sama. Protokol dapat mengurangi risiko dengan mendistribusikan hak penghasilan di sejumlah jembatan yang luas (sehingga satu penyedia jembatan tidak memiliki jumlah token yang terlalu besar dibandingkan dengan jembatan lain), namun upaya untuk mengantisipasi risiko ini dapat meningkatkan ketidakefisienan karena setiap jembatan akan memerlukan penilaian independen dari tim DAO dan berkoordinasi dengan lebih banyak jembatan akan meningkatkan beban administratif yang telah kita sebutkan sebelumnya.

Kontrak Lockbox yang diatur oleh DAO dapat menimbulkan efek penularan yang merugikan jika terjadi serangan tata kelola. Tetapi bahkan dengan tata kelola DAO yang aman, bug dalam kontrak Lockbox asli/non-asli pada rantai rumah token dapat menyebabkan banyak masalah (Sifu sekarang adalah pemilik kontrak Lockbox untuk sebuah proyek, dan dana bukan lagi SAFU). Sebagai perbandingan, masalah ini berkurang dalam status quo karena kontrak brankas (setara dengan kontrak Lockbox penyedia jembatan) hanya menyimpan token yang dijembatani melalui layanan jembatan yang sesuai. Jadi, bug dalam kontrak vault untuk satu penyedia hanya memengaruhi pengguna yang menyetor token dengan jembatan tersebut.

Biaya overhead untuk integrasi ekosistem

Pekerjaan administratif ekstra dengan ERC-7281 juga memengaruhi pengembang aplikasi dan penyedia layanan yang menggunakan token xERC-20 proyek. Agregator jembatan perlu melacak pemetaan antara token xERC-20 dan kontrak Lockbox yang sesuai untuk mencegah masalah seperti token spam dan serangan spoofing. Meskipun registri pemetaan ini dapat membantu, menyiapkan registri semacam itu menantang tanpa mempertaruhkan sentralisasi atau mengekspos pengadopsi xERC-20 terhadap ancaman.

Risiko berasal dari penyerang yang berpotensi menambahkan kontrak berbahaya ke registri token dan mengelabui pengguna dan pengembang untuk mengirim token ke alamat yang salah. Hal ini dapat menyebabkan pencurian token pada jaringan L2 dan L1. Bursa menghadapi tantangan serupa, karena token palsu dapat menyebabkan masalah serius, seperti perilaku token yang tidak terduga, yang berbeda dari token kanonik yang diperiksa.

Kesimpulan

ERC-7281 menghadirkan solusi yang menarik untuk masalah token jembatan yang tidak dapat dipertukarkan dan menawarkan fitur yang meningkatkan pengalaman pengguna, desentralisasi, keamanan, dan fleksibilitas dalam desain jembatan token. Beberapa masalah ini secara langsung memengaruhi kelangsungan hidup peta jalan rollup-centric, menjadikan infrastruktur penting standar xERC-20 untuk ekosistem Ethereum L2.

Beberapa pemain kunci dalam ruang jembatan, termasuk Hyperlane, Omni, Sygma, Router Protocol, dan Everclear, telah berkomitmen untuk mengadopsi ERC-7281, menunjukkan adopsi yang signifikan untuk proposal tersebut. Bahkan penerbit token yang sudah mapan (yang memiliki mekanisme kerja untuk menjembatani token)—seperti Circle—telah menunjukkan minat terhadap ERC-7281 untuk mengatasi tantangan yang ditimbulkan oleh token yang tidak disetujui yang memengaruhi pengguna dan pengembang.

ERC-7281 mengatasi masalah ini sambil memitigasi banyak kompromi yang terkait dengan pendekatan sebelumnya untuk mencetak token kanonik di domain remote. Ini menyediakan bootstrapping bebas likuiditas, tidak seperti jembatan yang diabadikan, tidak memerlukan infrastruktur khusus seperti jembatan penerbit token, dan menghindari keterikatan vendor dengan memungkinkan pencetakan token kanonik multi-jembatan oleh penyedia jembatan yang disetujui.

Bagi mereka yang tertarik untuk mengikuti diskusi seputar ERC-7281 atau pengembang yang ingin mengintegrasikan xERC-20, Persekutuan Pesulap Ethereumdansitus web xERC-20 adalah sumber daya yang sangat baik. Komunitas juga telah membangun peluncur xERC-20 untuk menggabungkan alat untuk membuat, memantau, dan mengelola token xERC-20—alat yang berharga bagi pembuat yang ingin menerapkan token xERC-20 untuk pertama kalinya atau memigrasikan token yang ada ke standar token xERC-20.

Disclaimer:

1. Artikel ini dicetak ulang dari [Penelitian 2077]. Semua hak cipta adalah milik penulis asli [Penelitian 2077]. Jika ada keberatan terhadap cetak ulang ini, silakan hubungi Gerbang Belajar tim, dan mereka akan segera menanganinya.
2. Penafian Kewajiban: Pandangan dan pendapat yang diungkapkan dalam artikel ini semata-mata milik penulis dan bukan merupakan saran investasi apa pun.
3. Tim Gate Learn melakukan terjemahan artikel ke dalam bahasa lain. Dilarang menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan kecuali disebutkan.