Meneruskan Judul Asli 'RGB++与同构绑定：CKB、Cardano与Fuel如何赋能比特币生态'

Ringkasan:· Protokol aset RGB++ yang diusulkan oleh tim CKB mengusulkanInti dari gagasan "pengikatan isomorfik" adalah menggunakan CKB, Cardano, Bahan Bakar, dan blockchain lainnya berdasarkan model pemrograman UTXO sebagai lapisan ekspansi fungsional yang membawa "wadah" aset RGB. Pengikatan isomorfik ini juga berlaku untuk protokol aset ekologi Bitcoin dengan karakteristik UTXO seperti Atomical dan Runes, sehingga mudah untuk membangun lapisan kontrak pintar off-chain untuk Bitcoin.

· Dalam protokol RGB++, pengguna tidak perlu menjalankan klien untuk memverifikasi data transaksi secara pribadi, dan dapat menyerahkan tugas-tugas seperti verifikasi validitas aset dan penyimpanan data ke rantai UTXO seperti CKB dan Cardanao. Selama Anda “optimis” dan percaya bahwa keamanan dari rantai publik di atas relatif dapat diandalkan, maka tidak perlu untuk memverifikasinya sendiri;

Protokol RGB++ mendukung pengguna untuk beralih kembali ke mode verifikasi klien. Pada saat ini, Anda masih dapat menggunakan CKB sebagai penyimpanan data/lapisan DA tanpa harus menyimpan data sendiri. Protokol RGB++ tidak memerlukan aset lintas rantai, dan dapat mengoperasikan aset di rantai CKB melalui akun Bitcoin, dan dapat mengurangi frekuensi penerbitan Komitmen ke rantai Bitcoin, yang juga mendukung skenario Defi.

· Jika berada di bawah sistem kontrak EVM, banyak fitur RGB++ tidak mudah didukung. Secara keseluruhan, sebuah lapisan ekspansi fungsi rantai/publik yang cocok untuk merealisasikan ikatan isomorfik seharusnya memiliki karakteristik berikut:

1. Gunakan model UTXO atau skema penyimpanan state serupa;

2. Memiliki pemrograman UTXO yang signifikan, memungkinkan pengembang menulis skrip pembukaan;

3. Ada ruang negara terkait UTXO yang dapat menyimpan status aset;

4. Ini dapat mendukung operasi node ringan Bitcoin melalui kontrak pintar atau cara lain;

Selain CKB, Cardano dan Fuel juga dapat mendukung pengikatan isomorfis. Namun, dua yang terakhir mungkin memiliki beberapa masalah dalam hal bahasa kontrak pintar dan rincian desain kontrak. Saat ini, sepertinya CKB lebih cocok daripada dua yang terakhir sebagai lapisan perluasan fungsi untuk protokol aset Bitcoin yang terikat secara isomorfis.

Pada 2017, Cipher, salah satu pendiri Nervos CKB, pertama kali mengusulkan ide produk penerapan isomorfik. Dibandingkan dengan solusi Bitcoin Layer 2 lainnya, penerapan isomorfik dapat lebih kompatibel dengan protokol aset seperti RGB, Runes, dan Atomical, dan dapat menghindari faktor-faktor seperti aset lintas-rantai yang membawa beban keamanan tambahan.

Secara sederhana, ikatan isomorfis menggunakan UTXO pada rantai CKB dan Cardano sebagai “kontainer” untuk mengekspresikan aset UTXO seperti RGB, sehingga menambahkan pemrograman dan skenario yang lebih kompleks. Sebelumnya, Geek web3 muncul di “Dari BTC ke Sui, ADA, dan Nervos: model UTXO dan ekstensi terkaitSetelah merangkum serangkaian blockchain yang mendukung UTXO yang dapat diprogram, artikel ini akan lebih jauh menjelajahi apakah blockchain-blockchain ini dapat beradaptasi dengan skema pengikatan isomorfis.

RGB++ dan pengikatan isomorfik

Sebelum menganalisis kompatibilitas rantai UTXO yang berbeda dengan ikatan isomorfik, kita harus terlebih dahulu memperkenalkan prinsip ikatan isomorfik. Ikatan isomorfik adalah konsep yang diusulkan oleh tim CKB dalam protokol RGB++, jadi di sini kita menggunakan alur kerja RGB++ untuk memperkenalkan apa itu ikatan isomorfik berbasis CKB.

Sebelum memperkenalkan protokol RGB++, mari kita memahami secara singkat protokol RGB. RGB adalah protokol aset/jaringan P2P yang berjalan di bawah rantai Bitcoin, agak mirip dengan Jaringan Lightning. Selain itu, RGB juga merupakan protokol aset parasit berbasis Bitcoin UTXO. Yang disebut parasitisme berarti bahwa klien RGB akan menyatakan di bawah rantai Bitcoin UTXO mana aset RGB tertentu terikat pada rantai Bitcoin. Begitu Anda memiliki UTXO ini, aset RGB yang terikat padanya juga tersedia untuk Anda.

Protokol aset seperti protokol RGB dan ERC-20 beroperasi dengan cara yang sangat berbeda. Kontrak ERC-20 di Ethereum mencatat status aset semua pengguna, dan klien node Ethereum akan menyinkronkan dan memverifikasi semua informasi transfer, dan mencatat pembaruan status setelah transfer di kontrak aset. Ini sebenarnya sudah diketahui oleh orang-orang sejak lama, dan tidak lebih dari mengandalkan proses konsensus Ethereum untuk memastikan bahwa perubahan status aset lancar. Karena konsensus node Ethereum sangat dapat diandalkan, pengguna dapat berasumsi bahwa platform aset aman berdasarkan kontrak ERC-20 sebagai 'tidak ada masalah' bahkan jika mereka tidak menjalankan klien.

Protokol RGB sangat aneh. Untuk meningkatkan privasi, ia hanya menghapus konsensus node/klien, yang merupakan hal konvensional dalam dunia blockchain. Pengguna harus menjalankan klien RGB sendiri dan hanya menerima serta menyimpan "data aset yang terkait dengan mereka sendiri". Mereka tidak dapat melihat apa yang dilakukan orang lain. Berbeda dengan Ethereum dan ERC-20, semua catatan transfer terlihat di rantai.

Dalam hal ini, jika seseorang mentransfer beberapa aset RGB kepada Anda, Anda tidak tahu sebelumnya bagaimana uang itu diciptakan dan dari siapa tangan-tangan itu berpindah. Jika orang di sisi lain menyatakan aset dari udara dan kemudian mentransfer sebagian ke Anda, bagaimana Anda menangani skenario jahat pemalsuan mata uang ini?

Protokol RGB mengadopsi ide ini: Sebelum setiap transfer berlaku, penerima pertama-tama meminta pengirim untuk menyajikan seluruh sejarah aset. Misalnya, dari tahap penciptaan hingga saat ini, siapa yang mengeluarkan aset tersebut, siapa yang melewatinya, dan apakah setiap transfer aset yang terjadi antara orang-orang ini tidak melanggar standar akuntansi (satu orang menambah, satu orang mengurangi).

Dengan cara ini, Anda dapat mengetahui apakah uang yang diberikan kepada Anda oleh pihak lain adalah "uang yang meragukan", jadi inti dari RGB adalah membiarkan pihak-pihak yang melakukan transaksi menjalankan klien untuk verifikasi. Berdasarkan mode verifikasi klien, sesuai dengan asumsi permainan orang rasional, selama pihak yang terlibat rasional dan perangkat lunak klien berfungsi dengan baik, dapat dijamin bahwa transfer aset bermasalah tidak akan berlaku atau diakui oleh orang lain.

Perlu dicatat bahwa protokol RGB akan mengompres data transaksi di bawah rantai Bitcoin menjadi Commitment (pada dasarnya merkle root) dan mengunggahnya ke rantai Bitcoin. Hal ini akan memungkinkan catatan transfer di bawah rantai terhubung langsung ke jaringan utama Bitcoin. Buat koneksi.

(Diagram alur interaksi protokol RGB)

Karena tidak ada kesepakatan di antara klien RGB, rilis kontrak aset RGB tidak dapat tersebar ke semua node “dengan sangat dapat diandalkan”. Penerbit kontrak dan pengguna hanya belajar detail kontrak aset RGB secara spontan melalui email atau Twitter, dan bentuknya sangat santai.

Gambar di bawah ini menunjukkan skenario transfer aset RGB jahat. Sebagai pengguna RGB, kita perlu menyimpan kontrak pintar yang sesuai dengan aset RGB secara lokal pada klien kita. Ketika orang lain mentransfer uang kepada kita, kita dapat mengetahui apakah transfer saat ini melanggar aturan yang ditentukan dalam kontrak berdasarkan konten kontrak aset yang disimpan secara lokal. Berdasarkan informasi sumber aset (catatan historis) yang disediakan di sisi seberang, Anda dapat mengonfirmasi apakah ada masalah dengan sumber aset pihak lain (apakah itu dinyatakan dari udara).

Mengkaji proses di atas, tidak sulit untuk melihat bahwa data yang diterima dan disimpan oleh klien RGB yang berbeda seringkali independen, dan seringkali Anda tidak tahu aset apa yang dimiliki orang lain dan seberapa banyak mereka. Sebaliknya, orang lain pada dasarnya tidak tahu status aset Anda.

Ini adalah pulau data khas, yaitu, data yang disimpan oleh semua orang tidak konsisten. Meskipun secara teoritis dapat meningkatkan privasi, ini juga membawa banyak masalah. Anda harus menjaga data aset RGB secara lokal di klien Anda. Begitu data ini hilang, akan menyebabkan konsekuensi serius (aset akan tidak tersedia). Namun, sebenarnya, selama Anda menjaga data lokal dengan baik, protokol RGB dapat memberi Anda keamanan yang pada dasarnya setara dengan jaringan utama Bitcoin.

Selain itu, protokol Bifrost yang digunakan untuk komunikasi antara klien RGB akan membantu pengguna dalam komunikasi p2p dengan klien lain. Mereka dapat mengenkripsi data aset mereka dan menyebarkannya ke node lain, dan meminta bantuan untuk menyimpannya. (Perhatikan bahwa ini adalah data terenkripsi, pihak lain tidak mengetahui teks biasa). Selama Anda tidak kehilangan kunci, ketika data lokal hilang, Anda dapat memulihkan data aset yang awalnya Anda miliki melalui node lain dalam jaringan.

Namun kekurangan dari protokol RGB asli masih jelas. Pertama, setiap transaksi memerlukan komunikasi ganda antara kedua pihak. Pihak penerima harus terlebih dahulu memverifikasi sumber aset pengirim, dan kemudian mengirimkan tanda terima untuk menyetujui permintaan transfer pengirim. Selama proses ini, setidaknya tiga pesan harus disampaikan antara kedua pihak. Jenis 'transfer interaktif' ini sangat tidak konsisten dengan 'transfer non-interaktif' yang biasa orang gunakan. Bisakah Anda membayangkan bahwa ketika seseorang ingin mentransfer uang kepada Anda, mereka harus mengirimkan data transaksi kepada Anda untuk diperiksa. Bisakah mereka menyelesaikan proses transfer hanya setelah mendapatkan pesan tanda terima Anda? (Diagram alur dapat dilihat di artikel sebelumnya)

Kedua, Sebagian besar skenario Defi memerlukan kontrak pintar dengan data transparan dan status yang dapat diverifikasi, tetapi protokol RGB tidak secara inheren mendukung skenario tersebut, sehingga sangat tidak ramah terhadap Defi; selain itu, dalam protokol RGB, pengguna harus menjalankan klien mereka sendiri untuk melakukan verifikasi tugas mereka. Jika Anda secara tidak sengaja menerima aset yang telah berpindah tangan puluhan ribu orang, Anda bahkan harus memverifikasi puluhan ribu kali aset tersebut telah berpindah tangan. Jelas, membiarkan pengguna menyelesaikan semuanya sendiri, yang tidak mendukung promosi dan adopsi produk itu sendiri.

Mengenai masalah di atas, solusi RGB++ adalah memungkinkan pengguna untuk secara bebas beralih antara mode verifikasi mandiri klien dan mode hosting pihak ketiga. Pengguna dapat meninggalkan beban verifikasi dan penyimpanan data, hosting kontrak pintar, dsb. kepada CKB. Tentu saja, pengguna harus optimis dan percaya bahwa CKB, rantai publik POW, dapat diandalkan; jika ada yang memiliki keinginan yang lebih tinggi terhadap keamanan dan privasi, misalnya, investor besar dengan jumlah aset yang besar juga dapat kembali ke mode RGB asli. Yang perlu ditekankan di sini adalah bahwa RGB++ dan protokol RGB asli secara teoritis kompatibel satu sama lain.

(Diagram alur interaksi protokol RGB++ [versi singkat])

di artikel sebelumnya“Dari RGB ke RGB++: Bagaimana CKB memberdayakan protokol aset ekologis Bitcoin”, kami telah secara singkat mempopulerkan "pengikatan isomorfik" RGB ++. Di sini kami akan meninjau dengan cepat:

CKB memiliki UTXO sendiri yang disebut Cell, yang lebih dapat diprogram daripada UTXO pada rantai BTC. "Pengikatan isomorfik" adalah menggunakan Sel pada rantai CKB sebagai "wadah" untuk data aset RGB, dan menulis parameter kunci aset RGB ke dalam Sel.

Karena ada hubungan ikatan antara aset RGB dan Bitcoin UTXO, bentuk logis dari aset memiliki karakteristik UTXO. danCell, yang juga memiliki karakteristik UTXO, secara alami cocok sebagai "wadah" untuk aset RGB. Setiap kali transaksi aset RGB terjadi, wadah sel yang sesuai juga dapat menunjukkan karakteristik serupa, sama seperti hubungan antara entitas dan bayangan. Ini adalah inti dari "pengikatan isomorfis".

Sebagai contoh, jika Alice memiliki 100 token RGB dan UTXO A di rantai Bitcoin, dan memiliki Sel di rantai CKB, Sel ini ditandai dengan 'Saldo Token RGB: 100', dan kondisi penguncian terkait dengan UTXO A.

Jika Alice ingin mengirimkan 30 koin ke Bob, dia dapat pertama-tama menghasilkan Komitmen. Pernyataan yang sesuai adalah: mentransfer 30 koin RGB yang terkait dengan UTXO A ke Bob, dan mentransfer 70 ke UTXO lain yang dia kendalikan.

Setelah itu, Alice menghabiskan UTXO A pada rantai Bitcoin, mempublikasikan pernyataan di atas, dan kemudian menginisiasi transaksi pada rantai CKB untuk mengonsumsi kontainer Sel yang membawa 100 token RGB dan menghasilkan dua kontainer baru, satu memegang 30 token (ke Bob), satu memegang 70 token (dikendalikan oleh Alice). Dalam proses ini, tugas memverifikasi kevalidan aset Alice dan kevalidan pernyataan transaksi diselesaikan oleh node jaringan CKB melalui konsensus, tanpa intervensi Bob. CKB kini berperan sebagai lapisan verifikasi dan lapisan DA di bawah rantai Bitcoin.

Ini mirip dengan kenyataan bahwa setiap kali status kontrak Ethereum ERC-20 berubah, pengguna tidak perlu menjalankan verifikasi klien. Prinsipnya mirip. Protokol konsensus dan jaringan node menggantikan verifikasi klien. Selain itu, data aset RGB semua orang disimpan di rantai CKB, yang dapat diverifikasi secara global, yang bermanfaat untuk implementasi skenario Defi, seperti kolam likuiditas dan protokol gadai aset.

Ini sebenarnya memperkenalkan asumsi kepercayaan yang penting: Pengguna cenderung optimis bahwa rantai CKB, atau platform jaringan yang terdiri dari sejumlah besar node yang mengandalkan protokol konsensus, dapat diandalkan dan bebas dari kesalahan.Jika Anda tidak percaya CKB, Anda juga dapat mengikuti proses komunikasi interaktif dan verifikasi dalam protokol RGB asli dan menjalankan klien sendiri.

Tentu saja, jika seseorang ingin menjalankan klien RGB++ sendiri dan memverifikasi sumber historis aset orang lain, dia dapat langsung memverifikasi sejarah yang terkait dengan Kontainer Aset RGB di rantai CKB. Selama Anda menjalankan node ringan CKB dan menerima Bukti Merkle dan header blok CKB, Anda dapat yakin bahwa data historis yang Anda terima tidak telah dimanipulasi oleh penyerang jahat dalam jaringan. Bisa dikatakan, CKB bertindak sebagai lapisan penyimpanan data historis di sini.

Secara sederhana, Binding Isomorfik tidak hanya berlaku untuk RGB, tetapi juga untuk berbagai protokol aset dengan karakteristik UTXO seperti Runes dan Atomic., mengalihkan semua status aset, data historis, dan kontrak pintar yang sesuai yang disimpan secara lokal di klien pengguna ke rantai publik UTXO seperti CKB atau Cardano untuk penyimpanan dan hosting. Protokol aset UTXO yang disebutkan di atas dapat menggunakan model UTXO dari CKB atau Cardano sebagai “kontainer” untuk menunjukkan bentuk dan status aset. Ini memudahkan untuk berkolaborasi dengan skenario seperti kontrak pintar.

Di bawah protokol pengikatan isomorfik, pengguna dapat langsung menggunakan akun Bitcoin mereka untuk mengoperasikan kontainer aset RGB mereka pada rantai UTXO seperti CKB tanpa melintasi rantai. Anda hanya perlu menggunakan fitur UTXO dari Sel untuk mengatur kondisi membuka kontainer Sel agar terkait dengan alamat Bitcoin tertentu/UTXO Bitcoin. Karena kami sudah menjelaskan karakteristik Sel dalam artikel popular sains RGB++ sebelumnya di Geekweb3, kami tidak akan membahas detailnya di sini.

Jika kedua belah pihak yang terlibat dalam transaksi aset RGB dapat mempercayai keamanan CKB, mereka bahkan tidak perlu sering mengeluarkan Komitmen di rantai Bitcoin. Setelah banyak transfer RGB dilakukan, sebuah Komitmen dapat dikirim ke rantai Bitcoin. Ini disebut fungsi "lipatan transaksi". Dapat mengurangi biaya penggunaan.

Namun, perlu dicatat bahwa 'kontainer' yang digunakan dalam ikatan isomorfik sering kali memerlukan rantai publik yang mendukung model UTXO, atau infra dengan karakteristik serupa dalam penyimpanan status, dan rantai EVM jelas tidak cocok, dan akan muncul masalah implementasi teknis. Banyak jebakan. Pertama-tama, seperti yang disebutkan sebelumnya, RGB++ 'dapat mengoperasikan kontainer aset pada rantai CKB tanpa lintas rantai', yang pada dasarnya tidak mungkin diimplementasikan pada rantai EVM; bahkan jika diimplementasikan secara paksa, biayanya mungkin sangat tinggi.

Selain itu, dalam protokol RGB++, banyak orang tidak perlu menjalankan klien atau menyimpan data aset secara lokal. Jika metode ERC-20 digunakan untuk mencatat saldo aset semua orang dalam kontrak ini, jika seseorang ingin kembali ke mode verifikasi diri klien dan mengusulkan untuk memeriksa sumber aset seseorang, pada saat ini dia mungkin harus Memindai semua catatan transaksi yang berinteraksi dengan kontrak aset akan memberikan tekanan besar.

Untuk mengatakannya secara lugas, kontrak aset seperti ERC-20 memasangkan dan menyimpan status aset semua orang. Jika Anda ingin memeriksa histori perubahan aset masing-masing secara individual, hal itu akan menjadi sulit. Sama seperti di ruang obrolan publik, jika Anda ingin tahu siapa yang telah mengirim pesan kepada Wang Gang, Anda harus melihat catatan pesan di seluruh ruang obrolan. UTXO seperti saluran obrolan pribadi satu lawan satu, dan mudah untuk memeriksa historinya.

Secara ringkas, Sebuah rantai publik/lapisan ekspansi fungsi yang cocok untuk mewujudkan ikatan isomorfik harus memiliki karakteristik berikut:

1. Gunakan model UTXO atau skema penyimpanan status serupa;
2. Memiliki pemrograman UTXO yang signifikan, memungkinkan pengembang untuk menulis skrip penguncian;
3. Ada ruang keadaan terkait UTXO yang dapat menyimpan status aset;
4. Ada jembatan atau node ringan terkait Bitcoin;

Tentu saja, kami juga berharap bahwa rantai publik yang digunakan untuk ikatan isomorfik memiliki keamanan yang kuat. Di sisi lain, kami juga berharap bahwa kondisi penguncian UTXO pada rantai publik harus dapat diprogram, sehingga pengguna dapat langsung menggunakan skema tanda tangan BTC untuk membuka kunci UTXO Anda secara isomorfik di rantai publik lain tanpa mengubah algoritma tanda tangan.

Saat ini, skrip penguncian UTXO pada CKB dapat diprogram, dan resmi juga kompatibel dengan skema tanda tangan dari berbagai rantai publik yang berbeda. Untuk ikatan isomorfik, jaringan CKB pada dasarnya memenuhi karakteristik di atas. Bagaimana dengan rantai publik berbasis UTXO lainnya? Kami telah melakukan pemeriksaan awal terhadap Fuel dan Cardano dan percaya bahwa mereka secara teoritis dapat mendukung ikatan isomorfik.

Bahan Bakar: Ethereum OP Rollup berdasarkan UTXO

Fuel adalah Ethereum OP Rollup berbasis UTXO, dan merupakan pelopor dalam memperkenalkan konsep bukti penipuan ke dalam ekosistem Layer 2 Ethereum. Untuk mendukung fungsi UTXO normal, Fuel pada dasarnya konsisten dengan BTC.

Fuel membagi UTXO internalnya ke dalam tiga kategori berikut:

Input Coin: Standar UTXO, digunakan untuk mewakili aset pengguna, memiliki kunci waktu asli, dan memungkinkan pengguna menulis predikat skrip penguncian;

Kontrak Input: UTXO yang digunakan untuk panggilan kontrak berisi data seperti state root dari kontrak dan aset kontrak;

Pesan Masukan: UTXO digunakan untuk mengirim informasi terutama berisi bidang seperti penerima informasi;

Ketika seorang pengguna menghabiskan UTXO, output berikut dihasilkan:

Output Koin：Untuk transfer aset standar;

Kontrak Output : Output yang dihasilkan oleh interaksi kontrak secara internal mengandung state root setelah interaksi kontrak;

Kontrak Output Dibuat: Sebuah UTXO khusus adalah output yang dihasilkan saat membuat kontrak, yang berisi ID dan root state dari kontrak;

Berbeda dengan Sel CKB, yang mengandung semua status kontrak secara internal, UTXO Fuel sebenarnya tidak membawa semua status kontrak terkait transaksi. Fuel hanya membawa akar status kontrak Stateroot dalam UTXO, yang merupakan akar dari pohon status. Status lengkap kontrak disimpan di dalam perpustakaan status Fuel dan dimiliki oleh kontrak cerdas.

Perlu dicatat bahwa, Mengenai pemrosesan status kontrak pintar, kontrak Fuel dan kontrak solidity secara ideologis konsisten dan bahkan relatif dekat dalam bentuk pemrograman. Gambar di bawah menunjukkan kontrak counter yang ditulis dalam bahasa Sway Fuel. Kontrak tersebut berisi penghitung. Ketika pengguna memanggil fungsi increment_counter, penghitung yang disimpan dalam kontrak tersebut akan ditambahkan sebanyak 1.

Kita dapat melihat bahwa logika penulisan kontrak Sway mirip dengan kontrak Solidity umum. Pertama, kita memberikan ABI dari kontrak, kemudian variabel-variabel keadaan kontrak, dan kemudian implementasi spesifik dari kontrak tersebut. Semua proses penulisan kode tidak melibatkan sistem UTXO Fuel.

Oleh karena itu, pengalaman pemrograman kontrak Fuel berbeda dari bahasa pemrograman UTXO seperti CKB dan Cardano. Fuel menyediakan pengalaman yang lebih dekat dengan pemrograman dan pengembangan kontrak pintar EVM. Pengembang juga dapat menggunakan bahasa Sway untuk membangun skrip penguncian untuk menerapkan logika verifikasi algoritma tanda tangan khusus atau logika penguncian multi-tanda tangan yang kompleks.

Pada dasarnya memungkinkan untuk menerapkan ikatan isomorfik dalam Fuel, tetapi masih ada masalah-masalah berikut:

Bahasa ayunan yang digunakan oleh Fuel lebih dekat dengan rantai EVM dalam hal desain kontrak pintar daripada BTC atau CKB dan Cardano. Penerbit aset UTXO seperti RGB dan Atomics perlu secara khusus membangun kontrak pintar di Fuel. CKB dan rantai lain menggunakan yang lain, yang cukup rumit.

Cardano: rantai publik eUTXO berbasis POS

Cardano adalah blockchain lain yang menggunakan model UTXO, tetapi tidak seperti Fuel, itu adalah chain publik Layer 1. Cardano menggunakan eUTXO (UTXO yang diperluas) untuk merujuk pada model pemrograman UTXO dalam sistemnya. Dibandingkan dengan CKB, eUTXO di Cardano berisi struktur berikut:

Skrip: Kontrak pintar digunakan untuk memverifikasi apakah UTXO dapat dibuka kunci dan melakukan transisi keadaan;

Penebus: Data yang diberikan oleh pengguna untuk membuka UTXO umumnya adalah data tanda tangan, mirip dengan Witness Bitcoin;

Datum: Ruang keadaan kontrak pintar dapat menyimpan data seperti status aset;

Konteks Transaksi: Data kontekstual untuk transaksi UTXO, seperti parameter input dan hasil transaksi (Proses perhitungan transaksi rantai UTXO dilakukan langsung di luar rantai, dan hasil perhitungan diserahkan ke rantai untuk diverifikasi. Jika lolos verifikasi, hasil transaksi diunggah ke rantai)

Pengembang dapat menggunakan bahasa PlutusCore untuk memprogram UTXO di rantai Cardano. Mirip dengan CKB, pengembang dapat menulis skrip unlocking dan beberapa fungsi untuk pembaruan status.

Kami memperkenalkan model pemrograman UTXO Cardano dengan proses lelang berbasis UTXO. Misalkan kita perlu mengimplementasikan DAPP lelang aset yang membutuhkan pengguna untuk memberikan penawaran sebelum lelang berakhir. Secara khusus, pengguna menghabiskan UTXO miliknya sendiri, mengontrak UTXO dengan lelang ini, dan kemudian menghasilkan UTXO baru. Ketika seseorang memberikan penawaran yang lebih tinggi, selain menghasilkan UTXO kontrak lelang baru, UTXO pengembalian untuk orang sebelumnya juga akan dihasilkan. Proses spesifiknya adalah sebagai berikut:

Untuk melaksanakan proses lelang di atas, beberapa status perlu disimpan di UTXO dari kontrak pintar lelang, seperti harga tertinggi dari lelang saat ini dan orang yang membuat penawaran. Gambar di bawah menunjukkan pernyataan status di dalam PlutusCore. Kita dapat melihat bahwa bBidder dan bAmount menampilkan penawaran lelang dan alamat dompet yang memberikan penawaran. Parameter Lelang berisi informasi dasar lelang.

Ketika seorang pengguna menghabiskan UTXO ini, kita dapat memperbarui status dalam kontrak. Gambar di bawah ini menunjukkan beberapa pembaruan status tertentu dan logika bisnis dalam kontrak lelang. Misalnya, logika memverifikasi penawaran pengguna dan memverifikasi apakah lelang saat ini masih berlangsung. Tentu saja, Karena PlutusCore adalah bahasa pemrograman Haskell, yang merupakan bahasa pemrograman fungsional murni, kebanyakan pengembang mungkin tidak dapat langsung memahami maknanya.

Memungkinkan untuk membuat ikatan isomorfis pada Cardano, Kita dapat menggunakan Datum untuk menyimpan status aset dan menulis skrip tertentu agar kompatibel dengan algoritma tanda tangan yang terkait dengan Bitcoin. Namun, masalah seriusnya adalah bahwa kebanyakan programmer mungkin tidak bisa beradaptasi untuk menggunakan PlutusCore untuk pemrograman kontrak. Selain itu, lingkungan pemrogramannya sulit untuk disiapkan dan tidak ramah bagi para pengembang.

Ringkasan

Pengikatan isomorfis memerlukan rantai memiliki properti berikut:

1. Gunakan model UTXO
2. Memiliki kemampuan pemrograman UTXO yang cukup besar, memungkinkan pengembang untuk menulis skrip pembuka kunci
3. Ada ruang keadaan terkait UTXO yang dapat menyimpan status aset
4. Ini dapat mendukung menjalankan node ringan Bitcoin melalui kontrak pintar atau cara lainnya.

Karena kekhasan ide pemrograman kontrak pintarnya, Bahan Bakar kompatibel dengan pengikatan isomorfik, tetapi masih membawa beberapa bagasi; sementara Cardaon menggunakan bahasa pemrograman Haskell untuk pemrograman kontrak, yang menyulitkan sebagian besar pengembang untuk memulai dengan cepat. Berdasarkan alasan di atas, CKB, yang mengadopsi set instruksi RISC-V dan lebih seimbang dalam karakteristik pemrograman UTXO, mungkin merupakan lapisan ekspansi fungsi yang lebih cocok untuk pengikatan isomorfik.

Penafian:

1. Artikel ini dicetak ulang dari [Geek Web3]. Teruskan Judul Asli 'RGB++与同构绑定：CKB、Cardano与Fuel如何赋能比特币生态'. Seluruh hak cipta milik penulis asli [Shew]. Jika ada keberatan terhadap cetakan ulang ini, silakan hubungi Gerbang Belajartim, dan mereka akan menanganinya dengan cepat.
2. Penafian Tanggung Jawab: Pandangan dan opini yang tertera dalam artikel ini semata-mata milik penulis dan tidak merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang telah diterjemahkan dilarang.