Dengan popularitas yang semakin meningkat dari RGB++ dan penerbitan aset terkait, diskusi mengenai prinsip protokol RGB dan RGB++ secara bertahap menjadi topik yang menarik bagi lebih banyak orang. Namun, disadari bahwa untuk memahami RGB++, seseorang harus terlebih dahulu memahami protokol RGB. Protokol RGB asli agak teknis dalam strukturnya, dengan bahan referensi yang tersebar, dan belum ada materi referensi yang sistematis dan mudah dipahami hingga saat ini. Geek Web3 sebelumnya telah menerbitkan dua interpretasi sistematis tentang RGB dan RGB++ (tersedia dalam riwayat akun publik kami), namun menurut umpan balik komunitas, artikel-artikel ini terlalu panjang dan terlalu kompleks. Untuk memungkinkan lebih banyak orang memahami dengan cepat protokol RGB dan RGB++, penulis artikel ini dengan tergesa-gesa menyelesaikan interpretasi sederhana tentang RGB dan RGB++ selama acara di Hong Kong. Ini dapat dibaca dalam beberapa menit, bertujuan untuk membantu lebih banyak penggemar komunitas memahami RGB dan RGB++ dengan lebih baik dan lebih intuitif.

Protokol RGB: Pengguna Perlu Memverifikasi Data Secara Pribadi

Protokol RGB adalah jenis khusus dari protokol aset P2P, yang beroperasi di bawah sistem komputasi rantai Bitcoin. Dalam beberapa hal, ini mirip dengan saluran pembayaran: Pengguna perlu menjalankan klien mereka secara pribadi dan memverifikasi tindakan transfer yang terkait dengan diri mereka sendiri ("Verifikasi sendiri"). Meskipun Anda hanya penerima aset, Anda harus terlebih dahulu mengonfirmasi bahwa laporan mutasi transfer dari pengirim sudah benar sebelum transfer dapat diterapkan. Pendekatan ini, yang dikenal sebagai "transfer interaktif," sangat berbeda dari metode transfer dan penerimaan aset tradisional. Mengapa ini perlu? Alasannya adalah bahwa protokol RGB, untuk menjaga privasi, tidak menggunakan "protokol konsensus" yang ditemukan di blockchain tradisional seperti Bitcoin dan Ethereum (di mana data, sekali dalam protokol konsensus, diamati oleh hampir semua node dalam jaringan, membuat privasi sulit dilindungi). Tanpa proses konsensus yang melibatkan sejumlah besar node, bagaimana perubahan aset dapat dipastikan aman? Di sinilah ide "verifikasi klien" ("Verifikasi sendiri") masuk. Anda harus menjalankan klien Anda dan secara pribadi memverifikasi perubahan aset yang terkait dengan Anda.

Sebagai contoh, mari kita pertimbangkan pengguna RGB bernama Bob yang mengenal Alice. Alice ingin mentransfer 100 token TEST ke Bob. Setelah menghasilkan informasi transfer “Alice ke Bob”, Alice mengirimkan informasi transfer dan data aset terkait ke Bob untuk diperiksanya sendiri. Hanya ketika Bob mengonfirmasi bahwa semuanya benar, transfer tersebut menjadi transfer RGB yang sah. Jadi, protokol RGB membutuhkan pengguna untuk memverifikasi keabsahan data sendiri, menggantikan algoritma konsensus tradisional. Namun, tanpa konsensus, data yang diterima dan disimpan oleh klien RGB yang berbeda tidak konsisten. Setiap orang hanya menyimpan data aset yang relevan dengan mereka sendiri secara lokal dan tidak tahu tentang status aset orang lain. Meskipun ini melindungi privasi, hal ini juga menciptakan “pulau data.” Jika seseorang mengklaim memiliki 1 juta token TEST dan ingin mentransfer 100.000 ke Anda, bagaimana Anda bisa mempercayainya? Dalam jaringan RGB, jika seseorang ingin mentransfer aset kepada Anda, mereka harus pertama-tama memberikan bukti aset, melacak sejarah aset dari penerbitan awal hingga transfer ganda, memastikan bahwa token yang ingin mereka transfer kepada Anda adalah sah. Sama seperti ketika Anda menerima uang kertas yang tidak dapat dijelaskan, Anda meminta pengirim untuk menjelaskan sejarah uang kertas tersebut, apakah mereka diterbitkan oleh penerbit yang ditunjuk, untuk menghindari uang palsu.

(Sumber gambar: Coinex)

Proses di atas terjadi di bawah rantai Bitcoin, dan langkah-langkah ini sendiri tidak menetapkan hubungan langsung antara RGB dan jaringan Bitcoin. Untuk mengatasi hal ini, protokol RGB menggunakan konsep "seal pengguna tunggal," yang mengikat aset RGB ke UTXO (Output Transaksi yang Belum Dibelanjakan) pada rantai Bitcoin. Selama UTXO Bitcoin tidak dibelanjakan ganda, aset RGB yang terikat tidak akan menjadi subjek pembayaran ganda, sehingga memanfaatkan jaringan Bitcoin untuk mencegah "Re-organisasi" aset RGB. Tentu saja, ini memerlukan publikasi Commitments pada rantai Bitcoin dan penggunaan opcode OP_Return.

Mari kita garis bawahi alur kerja protokol RGB:

1. Aset RGB terikat pada Bitcoin UTXO, dan Bob memiliki beberapa Bitcoin UTXO tertentu. Alice ingin mentransfer 100 token ke Bob. Sebelum menerima aset tersebut, Bob memberitahu Alice UTXO Bitcoin miliknya yang harus digunakan untuk mengikat aset RGB tersebut.

(Sumber gambar: Geekweb3/GeekWeb3)

1. Alice membuat data transaksi untuk transfer aset RGB “Alice ke Bob”, bersama dengan sejarah aset tersebut, dan memberikannya kepada Bob untuk verifikasi.
2. Setelah Bob mengonfirmasi bahwa data tersebut benar secara lokal, dia mengirimkan tanda terima kepada Alice, memberitahunya bahwa transaksi dapat dilanjutkan.
3. Alice membangun data transfer RGB "Alice ke Bob" ke dalam Pohon Merkle dan mempublikasikan Akar Merkle ke rantai Bitcoin sebagai Komitmen. Kita dapat dengan mudah memahami Komitmen sebagai hash dari data transfer.
4. Jika seseorang di masa depan ingin mengonfirmasi bahwa transfer 'Alice ke Bob' benar-benar terjadi, mereka perlu melakukan dua hal: memperoleh informasi transfer lengkap 'Alice ke Bob' di bawah rantai Bitcoin dan kemudian memverifikasi apakah Komitmen yang sesuai (hash data transfer) ada di rantai Bitcoin.

Bitcoin berfungsi sebagai catatan historis untuk jaringan RGB, namun catatan hanya mencatat hash/Merkle root dari data transaksi, bukan data transaksi itu sendiri. Karena adopsi verifikasi sisi klien dan segel penggunaan tunggal, protokol RGB menawarkan keamanan yang sangat tinggi. Karena jaringan RGB terdiri dari klien pengguna dinamis dalam suatu cara P2P, tanpa konsensus, Anda dapat mengubah pihak-pihak transaksi kapan saja tanpa perlu mengirim permintaan transaksi ke sejumlah node terbatas. Oleh karena itu, jaringan RGB menunjukkan ketahanan sensor yang kuat. Struktur organisasi ini membuatnya lebih tahan terhadap sensor dibandingkan dengan rantai publik berskala besar seperti Ethereum.

(Sumber gambar: BTCEden.org)

Tentu, keamanan tinggi, ketahanan sensor, dan perlindungan privasi yang dibawa oleh protokol RGB juga datang dengan biaya yang signifikan. Pengguna perlu menjalankan klien mereka untuk memverifikasi data. Jika seseorang mengirimkan aset kepada Anda dengan riwayat transaksi panjang yang melibatkan ribuan transfer, Anda perlu memverifikasinya semua, yang bisa menjadi sangat membebani.

Selain itu, setiap transaksi memerlukan komunikasi yang melibatkan beberapa pihak. Penerima perlu memverifikasi sumber aset pengirim dan kemudian mengirimkan tanda terima untuk menyetujui permintaan transfer pengirim. Proses ini melibatkan setidaknya tiga pertukaran pesan antara pihak-pihak. Transfer yang 'interaktif' ini sangat berbeda dengan transfer yang 'non-interaktif' yang kebanyakan orang biasa. Bayangkan seseorang perlu mengirim uang kepada Anda dan harus mengirimkan data transaksi untuk Anda periksa, menunggu pesan tanda terima Anda sebelum menyelesaikan proses transfer.

Selain itu, seperti yang kami sebutkan sebelumnya, jaringan RGB kekurangan konsensus, dan setiap klien beroperasi secara terisolasi, sehingga sulit untuk bermigrasi dari skenario kontrak pintar yang kompleks dari rantai publik tradisional ke jaringan RGB. Hal ini karena protokol DeFi di Ethereum atau Solana bergantung pada buku besar yang terlihat secara global dan transparan. Bagaimana cara mengoptimalkan protokol RGB, meningkatkan pengalaman pengguna, dan mengatasi tantangan-tantangan ini menjadi masalah yang tidak terhindarkan bagi protokol RGB.

RGB++ Memperkenalkan Pendekatan Penitipan Optimis, Menggantikan Verifikasi di Sisi Klien.

Protokol yang disebut RGB++ memperkenalkan pendekatan baru dengan menggabungkan protokol RGB dengan rantai publik yang didukung UTXO seperti CKB, Cardano, dan Fuel. Dalam pengaturan ini, yang terakhir berfungsi sebagai lapisan validasi dan penyimpanan data untuk aset RGB, mentransfer tugas verifikasi data yang awalnya dilakukan oleh pengguna ke platform/rantai pihak ketiga seperti CKB. Ini efektif menggantikan verifikasi sisi klien dengan 'verifikasi platform terdesentralisasi pihak ketiga.' Selama Anda mempercayai platform/rantai seperti CKB, Cardano, atau Fuel, Anda siap untuk melangkah. Jika Anda tidak percaya pada mereka, Anda selalu dapat beralih kembali ke mode RGB tradisional.

RGB++ dan protokol RGB asli secara teoritis kompatibel satu sama lain; ini bukan kasus salah satu atau yang lain, melainkan mereka dapat hidup berdampingan.

Untuk mencapai efek yang disebutkan, kita perlu memanfaatkan konsep yang disebut “homomorphic bindings.” Rantai publik seperti CKB dan Cardano memiliki model UTXO yang diperluas, yang menawarkan lebih banyak pemrograman dibandingkan dengan UTXO pada rantai Bitcoin. “Homomorphic binding” adalah gagasan menggunakan UTXO yang diperluas pada rantai seperti CKB, Cardano, dan Fuel sebagai “kontainer” untuk data aset RGB. Parameter-parameter aset RGB ditulis ke dalam kontainer-kontainer ini dan langsung ditampilkan di blockchain. Setiap kali terjadi transaksi aset RGB, kontainer aset yang sesuai juga dapat menunjukkan karakteristik yang serupa, mirip dengan hubungan antara entitas dan bayangan. Inilah inti dari “homomorphic binding.”

(Sumber gambar: RGB++ LightPaper)

Sebagai contoh, jika Alice memiliki 100 token RGB dan sebuah UTXO (mari kita sebut UTXO A) di rantai Bitcoin, serta sebuah UTXO di rantai CKB yang ditandai dengan "Saldo Token RGB: 100" dan kondisi terkunci yang terkait dengan UTXO A:

Jika Alice ingin mengirim 30 token ke Bob, dia dapat pertama-tama menghasilkan Komitmen dengan pernyataan yang sesuai: transfer 30 token RGB yang terkait dengan UTXO A ke Bob dan mentransfer 70 token ke UTXO lain yang dikontrol oleh dirinya sendiri.

Selanjutnya, Alice menghabiskan UTXO A pada rantai Bitcoin, mempublikasikan pernyataan di atas, dan kemudian menginisiasi transaksi pada rantai CKB. Transaksi ini mengonsumsi kontainer UTXO yang memegang 100 token RGB, menciptakan dua kontainer baru: satu memegang 30 token (untuk Bob) dan yang lain memegang 70 token (dikendalikan oleh Alice). Selama proses ini, tugas memverifikasi validitas aset dan pernyataan transaksi Alice diselesaikan oleh konsensus di antara node-node pada jaringan seperti CKB atau Cardano, tanpa keterlibatan Bob. Pada titik ini, CKB dan Cardano bertindak sebagai lapisan validasi dan lapisan DA (Data Availability), masing-masing, di bawah rantai Bitcoin.

(Sumber gambar: RGB++ LightPaper)

Data aset RGB individu disimpan pada rantai CKB atau Cardano, memberikan karakteristik yang dapat diverifikasi secara global yang memfasilitasi implementasi skenario DeFi seperti kolam likuiditas dan protokol staking aset. Tentu saja, pendekatan di atas juga mengorbankan privasi. Ini pada dasarnya melibatkan kompromi antara privasi dan kegunaan produk. Jika Anda memprioritaskan keamanan dan privasi yang sangat, Anda dapat beralih kembali ke mode RGB tradisional. Jika Anda tidak keberatan dengan kompromi-kompromi ini, Anda dapat dengan percaya mengadopsi mode RGB++, bergantung sepenuhnya pada kebutuhan pribadi Anda. (Sebenarnya, dengan memanfaatkan fungsionalitas yang kuat dari rantai publik seperti CKB dan Cardano, transaksi privasi dapat dicapai melalui penggunaan ZK.)

Penting untuk menekankan bahwa RGB++ memperkenalkan asumsi kepercayaan yang signifikan: pengguna perlu percaya bahwa rantai CKB/Cardano atau platform jaringan yang terdiri dari sejumlah besar node melalui protokol konsensus adalah andal dan bebas dari kesalahan secara optimis. Jika Anda tidak mempercayai CKB, Anda dapat mengikuti proses komunikasi interaktif dan verifikasi dalam protokol RGB asli dengan menjalankan klien Anda sendiri.

Di bawah protokol RGB++, pengguna dapat langsung menggunakan akun Bitcoin mereka untuk mengoperasikan kontainer aset RGB mereka di chain CKB/Cardano UTXO tanpa perlu transaksi lintas chain. Mereka hanya perlu memanfaatkan karakteristik UTXO dalam rantai publik yang disebutkan di atas dan mengatur kondisi buka kunci wadah Sel untuk dikaitkan dengan alamat Bitcoin / UTXO tertentu. Jika pihak-pihak yang terlibat dalam transaksi aset RGB mempercayai keamanan CKB, mereka bahkan mungkin tidak perlu sering mempublikasikan Komitmen pada rantai Bitcoin. Sebagai gantinya, mereka dapat menggabungkan dan mengirim Komitmen ke rantai Bitcoin setelah beberapa transfer RGB terjadi. Ini dikenal sebagai fitur "lipat transaksi", yang dapat mengurangi biaya transaksi.

Penting untuk dicatat bahwa "wadah" yang digunakan dalam pengikatan homomorfik perlu didukung oleh rantai publik yang menggunakan model UTXO atau memiliki fitur serupa dalam infrastruktur penyimpanan negara mereka. Rantai berbasis EVM sangat tidak cocok untuk tujuan ini dan mungkin menghadapi banyak tantangan. (Topik ini dapat dibahas dalam artikel terpisah, karena melibatkan banyak konten. Pembaca yang tertarik dapat merujuk ke artikel sebelumnya oleh Geek Web3 berjudul "RGB++ dan Homomorphic Bindings: Bagaimana CKB, Cardano, dan Fuel Menguatkan Ekosistem Bitcoin.“)

Secara ringkas, rantai publik atau lapisan perluasan fungsionalitas yang cocok untuk mengimplementasikan pengikatan homomorfik harus memiliki karakteristik berikut:

1. Memanfaatkan model UTXO atau skema penyimpanan status serupa.
2. Menawarkan pemrograman UTXO yang mencukupi, memungkinkan pengembang untuk menulis skrip pembuka kunci.
3. Memiliki ruang keadaan terkait dengan UTXO yang dapat menyimpan keadaan aset.
4. Tersedia jembatan atau node ringan terkait Bitcoin.

Disclaimer：

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