Kata pengantar

Menerbitkan aset berdasarkan BTC selalu menjadi topik hangat. Dari Koin Berwarna paling awal di tahun 2011 hingga protokol Ordinal yang baru-baru ini populer, komunitas BTC secara konsisten mampu menghasilkan pemain dan konsensus baru, namun hanya sedikit yang bertahan. Namun, Lightning Labs telah meluncurkan rencana ambisius untuk mengembangkan stablecoin berdasarkan Aset Akar Tunggang. Tether juga mengumumkan bahwa mereka akan menggunakan protokol RGB untuk mencetak USDT pada lapisan 1 Bitcoin.

Ini berarti OmniLayer (sebelumnya Mastercoin) yang dulu terkenal tidak lagi menjadi pemain terbesar di ekosistem BTC. Dan protokol aset validasi sisi klien (CSV) mulai memasuki visi semua orang. Protokol-protokol ini tidak hanya menjaga integritas protokol aset Bitcoin tradisional tetapi juga meningkatkan skalabilitas. Namun, serangkaian protokol aset dalam ekosistem Bitcoin, menimbulkan pertanyaan terkait: Apa perbedaannya satu sama lain, dan bagaimana seseorang harus menavigasi dan memanfaatkan peluang dalam lanskap ini?

Artikel ini bertujuan untuk memandu pembaca melalui tinjauan komprehensif terhadap berbagai protokol aset yang muncul dalam sejarah Bitcoin. Selain itu, penelitian ini berupaya untuk menyelidiki potensi lintasan evolusi protokol aset berbasis Bitcoin di masa mendatang.

Koin Berwarna

Konsep Koin Berwarna pertama kali diartikulasikan oleh Yoni Assia, sekarang CEO eToro, dalam artikel penting “bitcoin 2.X (alias Bitcoin berwarna)“ pada tanggal 27 Maret 2012. Artikel tersebut mengemukakan bahwa teknologi yang mendasari Bitcoin sama mendasar dan sempurnanya dengan HTTP untuk internet. Oleh karena itu, protokol token Koin Berwarna dirancang di atas BTC.

Yoni Assia membayangkan terciptanya ekonomi BTC 2.0 melalui inovasi ini, yang memungkinkan komunitas mana pun menghasilkan banyak mata uang dengan cara ini. Memanfaatkan teknologi dasar Bitcoin untuk penyelesaian transaksi dan pencegahan pembelanjaan ganda, pada saat itu, merupakan ide perintis.

Koin Berwarna adalah protokol yang dirancang untuk menerbitkan aset di blockchain Bitcoin. Ini beroperasi dengan “mewarnai” sebagian kecil bitcoin untuk menandakan aset lainnya. Bitcoin yang ditandai ini masih mempertahankan fungsi aslinya, namun juga mewakili aset atau nilai lain. Namun, pertanyaan mendesaknya adalah bagaimana ide ini bisa terwujud di jaringan Bitcoin.

Pada tanggal 3 Juli 2014, ChromaWay membuat langkah signifikan dengan mengembangkan Enhanced Colored Coins Order-based Protocol (EPOBC), yang sangat menyederhanakan proses pembuatan koin berwarna untuk pengembang. Ini adalah protokol perdana yang menggunakan fungsi OP_RETURN dari Bitcoin Script.

Hasilnya tampak seperti ini:

Implementasi seperti ini sangat singkat, namun juga membawa banyak masalah:

1. Masalah kesepadanan dan nilai pengikatan minimum Dengan mengikat 1000 sat dalam transaksi genesis untuk koin berwarna, unit minimum koin berwarna tersebut menjadi 1 sat. Artinya aset atau token secara teoritis dapat dibagi menjadi maksimal 1000 unit (namun dalam praktiknya lebih rendah untuk mencegah serangan debu. Misalnya, nilai satoshi minimum pernah ditetapkan pada 546 SAT, dan untuk Ordinal, bahkan lebih tinggi).
2. Tantangan validasi Untuk menentukan keaslian dan kepemilikan koin berwarna, riwayat transaksinya perlu ditelusuri kembali dan divalidasi dari transaksi asal hingga UTXO saat ini. Oleh karena itu, dompet khusus, node penuh, dan bahkan pemindai perlu dikembangkan.
3. Potensi risiko sensor penambang ColoredTransaction memiliki karakteristik yang berbeda, seperti penulisan metadata pada output, hal ini membawa kemungkinan sensor penambang.

Koin Berwarna pada dasarnya adalah sistem pelacakan aset yang menggunakan aturan validasi Bitcoin untuk melacak transfer aset. Namun, untuk membuktikan output tertentu (txout) mewakili aset tertentu, Anda perlu menyediakan seluruh rantai transfer dari asal aset tersebut. Ini berarti memvalidasi validitas suatu transaksi mungkin memerlukan rantai bukti yang panjang. Untuk mengatasi hal ini, proposal seperti OP_CHECKCOLORVERIFY dibuat untuk membantu memvalidasi transaksi Koin Berwarna secara langsung di BTC, namun proposal tersebut tidak diadopsi.

ICO Pertama di Kripto: Mastercoin

Konsep Mastercoin awalnya dikemukakan oleh JR Willett. Pada tahun 2012, ia menerbitkan whitepaper berjudul “The Second Bitcoin Whitepaper,” yang menguraikan gagasan untuk menciptakan aset atau token baru di atas blockchain Bitcoin yang ada. Konsep ini akhirnya dikenal sebagai “MasterCoin,” yang kemudian berganti nama menjadi Omni Layer.

Pada tahun 2013, proyek Mastercoin melakukan versi awal dari apa yang sekarang kita sebut sebagai ICO (Initial Coin Offering), dan berhasil mengumpulkan jutaan dolar. Ini dianggap sebagai ICO pertama dalam sejarah. Salah satu aplikasi Mastercoin yang paling menonjol adalah Tether (USDT), stablecoin dengan jaminan fiat yang terkenal, yang awalnya diterbitkan di Omni Layer.

Faktanya, ide Mastercoin sudah ada sebelum Koin Berwarna. Alasan kami membahasnya kedua adalah, dibandingkan dengan Koin Berwarna, MasterCoin adalah solusi yang relatif lebih komprehensif. MasterCoin membuat lapisan node penuh, menawarkan fungsionalitas yang lebih kompleks seperti kontrak pintar. Sebaliknya, Koin Berwarna lebih sederhana dan langsung, terutama berfokus pada “mewarnai” atau menandai Bitcoin UTXO untuk mewakili aset lainnya.

Perbedaan utama antara keduanya adalah pada blockchain, Mastercoin hanya mencatat berbagai jenis perilaku transaksi dan tidak menyimpan informasi aset terkait. Di node untuk Mastercoin, database model negara dikelola dengan memindai blok Bitcoin, dan database ini berada di node di luar blockchain.

Dibandingkan dengan Koin Berwarna, Mastercoin dapat menjalankan logika yang lebih kompleks. Selain itu, karena ia tidak mencatat atau memverifikasi status pada blockchain, transaksinya tidak perlu berurutan (berwarna terus menerus).

Namun, untuk mengimplementasikan logika kompleks Mastercoin, pengguna perlu memercayai status yang disimpan dalam database off-chain di dalam node atau menjalankan node Omni Layer mereka sendiri untuk melakukan verifikasi.

Kesimpulan:

Perbedaan utama antara Mastercoin dan Koin Berwarna adalah Mastercoin tidak menyimpan semua data yang diperlukan untuk protokol di blockchain. Sebaliknya, ia mendukung sistem konsensus Bitcoin untuk mengelola penerbitan dan pemesanan transaksinya sendiri, dan kemudian mempertahankan statusnya dalam database off-chain.

Menurut informasi yang diberikan oleh OmniBolt: Omni Layer mengusulkan protokol aset UBA (UTXO Based Asset) baru ke Tether, yang akan memanfaatkan peningkatan Taproot. Protokol ini akan menyematkan informasi aset ke dalam tapleaf, memungkinkan fungsi seperti pembayaran bersyarat. Pada saat yang sama, OmniBolt berupaya mengintegrasikan Stark ke dalam infrastruktur Jaringan Lightning Omni Layer.

Konsep Validasi Sisi Klien

Jika kita ingin memahami konsep Client Side Validation (CSV), kita perlu kembali ke tahun setelah munculnya Colored Coins dan Mastercoin, yaitu tahun 2013. Pada tahun itu, Peter Todd, seorang peneliti Bitcoin dan kriptografi awal, merilis sebuah artikel berjudul “Menguraikan Penambangan Kripto-Koin: Stempel Waktu, Bukti Publikasi, dan Validasi.“ Meskipun judulnya tidak secara eksplisit menyebutkan Validasi Sisi Klien, pembacaan yang cermat mengungkapkan bahwa ini adalah salah satu tulisan paling awal yang memperkenalkan konsep tersebut.

Peter Todd telah mencari cara untuk membuat operasi Bitcoin lebih efisien. Dia mengembangkan konsep validasi sisi klien yang lebih kompleks berdasarkan gagasan stempel waktu. Selain itu, ia memperkenalkan konsep “segel sekali pakai”, yang akan dibahas nanti.

Untuk mengikuti pemikiran Peter Todd, pertama-tama kita perlu memahami masalah apa yang sebenarnya dipecahkan oleh Bitcoin. Menurut Peter Todd, Bitcoin mengatasi tiga masalah:

1. Bukti publikasi: Inti dari bukti publikasi adalah untuk memecahkan masalah pembelanjaan ganda. Misalnya, jika Alice ingin mentransfer sejumlah bitcoin ke Bob, meskipun dia telah menandatangani transaksi untuk mentransfer ke Bob, Bob mungkin tidak secara fisik mengetahui bahwa transaksi tersebut ada. Oleh karena itu, kami memerlukan tempat umum untuk mempublikasikan transaksi, dan semua orang dapat menanyakan transaksi tersebut dari sana.
2. Konsensus tatanan: Dalam sistem komputer, waktu fisik yang biasanya kita alami tidak ada. Dalam sistem terdistribusi, waktu sering kali merupakan stempel waktu Lamport, yang tidak memberikan ukuran waktu fisik kita tetapi mengatur transaksi kita.
3. Validasi (Opsional): Validasi pada Bitcoin melibatkan verifikasi tanda tangan dan jumlah yang ditransfer dalam transaksi BTC. Namun, Peter Todd percaya bahwa validasi ini tidak diperlukan untuk membangun sistem token di atas Bitcoin; itu hanya opsi pengoptimalan.

Pada titik ini, Anda mungkin ingat OmniLayer, yang telah kita bahas sebelumnya. OmniLayer sendiri tidak mendelegasikan penghitungan dan validasi negara ke Bitcoin, namun menggunakan kembali keamanan Bitcoin. Koin Berwarna, di sisi lain, mempercayakan pelacakan negara ke Bitcoin. Keberadaan kedua sistem ini telah menunjukkan bahwa validasi tidak harus dilakukan di blockchain.

Jadi bagaimana validasi sisi klien memverifikasi transaksi secara efektif?

Pertama, mari kita lihat apa yang perlu diverifikasi:

1. Status (verifikasi logika transaksi)
2. Verifikasi bahwa input (TxIn) valid untuk mencegah pembelanjaan ganda.

Sangat mudah untuk melihat bahwa untuk aset yang diterbitkan dalam Bitcoin, setiap transaksi memerlukan verifikasi seluruh riwayat transaksi yang relevan untuk memastikan input yang direferensikan belum dibelanjakan dan statusnya benar. Hal ini sangat tidak praktis. Jadi, bagaimana kita bisa memperbaikinya?

Peter Todd menyarankan agar kita dapat menyederhanakan proses ini dengan mengubah fokus verifikasi. Daripada memastikan bahwa keluaran belum dibelanjakan ganda, metode ini berfokus pada memastikan bahwa masukan dari suatu transaksi telah dipublikasikan dan tidak bertentangan dengan masukan lainnya. Dengan mengurutkan masukan di setiap blok dan menggunakan pohon Merkle, verifikasi jenis ini dapat dilakukan dengan lebih efisien karena hanya memerlukan sebagian kecil data setiap kali, bukan seluruh riwayat rantai masukan.

Struktur pohon komitmen yang dikemukakan oleh Peter Todd adalah sebagai berikut:

CTxIn -> CTxOut -> <merkle path> -> CTransaksi -> <merkle path> -> CTxIn

Tapi bagaimana kita bisa menyimpan pohon komitmen seperti itu di blockchain? Di sinilah kami dapat memperkenalkan konsep “segel sekali pakai.”

Segel Sekali Pakai

Segel Sekali Pakai adalah salah satu konsep inti untuk memahami CSV. Ini mirip dengan segel fisik sekali pakai yang digunakan untuk melindungi kontainer kargo. Segel sekali pakai adalah benda unik yang dapat ditutup tepat satu kali pada sebuah pesan. Secara sederhana, segel sekali pakai adalah mekanisme abstrak yang digunakan untuk mencegah pembelanjaan ganda.

Untuk SealProtocol, ada tiga elemen dan dua tindakan.

Elemen dasar:

1. aku: segel
2. m: pesan, yaitu informasi atau transaksi
3. w : saksi, seseorang atau sesuatu yang dapat membuktikan segelnya

Operasi dasar: Ada dua tindakan dasar:

1. Close(l, m) → w: Tutup segel l pada pesan m, menghasilkan saksi w.
2. Verify(l, w, m) → bool: Verifikasi apakah segel l telah ditutup pada pesan m.

Keamanan implementasi segel sekali pakai berarti bahwa penyerang tidak dapat menemukan dua pesan berbeda m1 dan m2 sehingga fungsi Verifikasi mengembalikan nilai true untuk segel yang sama.

Secara sederhana, Segel Sekali Pakai memastikan bahwa aset atau bagian data tertentu hanya digunakan atau dikunci satu kali. Dalam konteks Bitcoin, ini biasanya berarti UTXO hanya dapat dibelanjakan satu kali. Jadi, keluaran transaksi Bitcoin dapat dilihat sebagai segel sekali pakai, dan ketika keluaran digunakan sebagai masukan dalam transaksi lain, segel tersebut “rusak” atau “digunakan.”

Untuk aset di Bitcoin, Bitcoin sendiri bertindak sebagai “saksi” (w) untuk segel sekali pakai. Hal ini karena untuk memverifikasi transaksi Bitcoin, node harus memeriksa bahwa setiap input transaksi merujuk pada UTXO yang valid dan tidak terpakai. Jika suatu transaksi mencoba membelanjakan dua kali lipat UTXO yang telah digunakan, aturan konsensus Bitcoin dan jaringan node yang jujur akan menolak transaksi tersebut.

Sederhananya:

Segel sekali pakai memperlakukan setiap blockchain seperti database, tempat kami menyimpan komitmen terhadap pesan tertentu dan mempertahankan statusnya sebagai sudah digunakan atau tidak.

Meringkas hal di atas, aset yang menggunakan validasi sisi klien memiliki karakteristik sebagai berikut:

1. Penyimpanan Data di Luar Rantai: Riwayat transaksi, kepemilikan, dan data aset relevan lainnya yang menggunakan validasi sisi klien sebagian besar disimpan di luar rantai. Hal ini sangat mengurangi kebutuhan penyimpanan data on-chain dan membantu meningkatkan privasi.
2. Mekanisme Komitmen: Meskipun data aset disimpan secara off-chain, perubahan atau transfer data ini dicatat secara on-chain melalui komitmen. Komitmen ini memungkinkan transaksi on-chain untuk merujuk pada status off-chain, memastikan integritas dan kekekalan data off-chain.
3. Saksi On-chain (Tidak Harus BTC): Meskipun sebagian besar data dan validasi terjadi di luar rantai, aset yang menggunakan validasi sisi klien masih dapat memanfaatkan keamanan blockchain yang mendasarinya (bukti publikasi, pemesanan transaksi) melalui komitmen yang tertanam pada -rantai.
4. Pekerjaan Validasi Dilakukan di Sisi Klien: Sebagian besar pekerjaan validasi dilakukan di perangkat pengguna. Artinya tidak setiap node di jaringan perlu berpartisipasi dalam memvalidasi setiap transaksi; hanya pihak-pihak yang terlibat yang perlu memverifikasi keabsahan transaksi.

Bagi mereka yang menggunakan aset dengan validasi sisi klien, ada hal tambahan yang perlu diperhatikan:

Saat bertransaksi dan memvalidasi aset dengan validasi sisi klien secara off-chain, penting untuk tidak hanya menyajikan kunci pribadi yang menyimpan aset tetapi juga memberikan bukti jalur Merkle yang lengkap untuk aset terkait.

RGB, pelopor CSV

Konsep RGB dikemukakan oleh Giacomo Zucco, salah satu tokoh terkenal di masyarakat, setelah tahun 2015. Ini adalah periode ketika Ethereum sedang naik daun, ICO (Initial Coin Offerings) berkembang biak, dan banyak upaya dilakukan untuk menciptakan proyek di luar Bitcoin, seperti Mastercoin dan Colored Coins.

Giacomo Zucco kecewa dengan perkembangan tersebut. Dia percaya bahwa tidak satu pun dari proyek ini yang sesuai dengan potensi Bitcoin dan upaya sebelumnya untuk menerapkan token pada Bitcoin tidak memadai. Selama waktu ini, dia bertemu Peter Todd dan menjadi terpesona dengan ide Todd tentang Validasi Sisi Klien (CSV). Hal ini mendorongnya untuk mengajukan ide RGB.

Terlepas dari karakteristik aset yang disebutkan sebelumnya yang menggunakan validasi sisi klien, perbedaan utama dengan RGB dan protokol aset sebelumnya adalah penambahan VM eksekusi (Mesin Virtual) untuk eksekusi kontrak lengkap Turing. Untuk menjamin keamanan data kontrak, Skema dan Antarmuka dirancang. Skema, mirip dengan Ethereum, mendeklarasikan konten dan fungsi kontrak, sedangkan Antarmuka bertanggung jawab atas implementasi fungsi tertentu, mirip dengan antarmuka dalam bahasa pemrograman.

Skema kontrak ini bertanggung jawab untuk membatasi perilaku yang melebihi ekspektasi selama eksekusi VM. Misalnya, RGB20 dan RGB21 masing-masing bertanggung jawab untuk menerapkan batasan tertentu pada token yang dapat dipertukarkan dan tidak dapat dipertukarkan selama transaksi.

Mekanisme komitmen yang digunakan dalam RGB, Pedersen Hash

Keuntungannya terletak pada kemampuannya untuk berkomitmen terhadap suatu nilai tanpa mengungkapkannya. Menggunakan Pedersen Hash untuk membangun pohon Merkle berarti Anda dapat membuat pohon Merkle yang melindungi privasi dan dapat menyembunyikan nilainya. Struktur ini berguna dalam protokol pelestarian privasi tertentu, seperti beberapa proyek mata uang kripto anonim. Namun, ini mungkin tidak cocok untuk aset CSV, yang akan disebutkan nanti dibandingkan dengan Aset Akar Tunggang.

Desain Mesin Virtual untuk Kesederhanaan RGB → AluVM

RGB bertujuan tidak hanya untuk mengimplementasikan protokol aset yang divalidasi sisi klien tetapi juga untuk memperluas eksekusi mesin virtual lengkap Turing dan pemrograman kontrak. Awalnya, RGB mengaku menggunakan bahasa pemrograman yang disebut Simplicity, yang menghasilkan bukti eksekusi dan memungkinkan verifikasi formal (untuk menghindari bug) dari kontrak yang tertulis di dalamnya. Namun, pengembangan bahasa ini tidak berjalan sesuai rencana, sehingga menimbulkan komplikasi yang pada akhirnya menghambat keseluruhan protokol RGB. Akhirnya, RGB mulai menggunakan VM bernama AluVM, yang dikembangkan oleh Maxim, dengan tujuan menghindari perilaku tidak terdefinisi, mirip dengan Simplicity asli. AluVM baru dikatakan akan digantikan di masa depan dengan bahasa pemrograman yang disebut Contractum, beralih dari penggunaan Rust saat ini.

Arah penskalaan layer2 RGB: Jaringan Lightning atau Sidechain?

Aset yang divalidasi sisi klien tidak dapat terus diperdagangkan secara off-chain dengan aman karena masih mengandalkan L1 untuk publikasi dan pemesanan transaksi. Artinya, tanpa solusi penskalaan lapisan 2, kecepatan transaksi mereka masih dibatasi oleh kecepatan produksi blok saksi L1 mereka. Hal ini menyiratkan bahwa jika transaksi RGB dilakukan secara langsung pada Bitcoin, dengan persyaratan keamanan yang ketat, waktu antara dua transaksi terkait harus berjarak setidaknya sepuluh menit (waktu blok BTC), yang seringkali sangat lambat.

RGB dan Jaringan Lightning

Secara sederhana, Lightning Network beroperasi dengan meminta para pihak dalam suatu transaksi menandatangani sejumlah kontrak (transaksi komitmen) secara off-chain. Kontrak ini memastikan bahwa jika ada pihak yang melanggar perjanjian, pihak yang dirugikan dapat menyerahkan kontrak (transaksi komitmen) ke BTC untuk diselesaikan, mengambil dana mereka, dan memberikan sanksi kepada pelanggar. Dengan kata lain, Lightning Network memastikan keamanan transaksi off-chain melalui protokol dan desain teori permainan.

RGB dapat membangun infrastruktur Lightning Network-nya sendiri dengan merancang detail kontrak saluran pembayaran yang sesuai untuk RGB itu sendiri. Namun, membangun infrastruktur seperti itu tidaklah mudah karena tingginya kompleksitas Jaringan Lightning, terutama mengingat pengalaman Lightning Labs selama bertahun-tahun di bidang ini dan pangsa pasar LND yang lebih dari 90%.

Sidechain Prime RGB

LNP-BP, pengelola protokol RGB saat ini, merilis proposal pada Juni 2023 oleh Maxim untuk solusi penskalaan aset tervalidasi sisi klien yang disebut Prime. Di dalamnya, Maxim mengkritik solusi penskalaan sidechain dan Lightning Network yang ada karena terlalu rumit dalam pengembangan. Dia menyatakan keyakinannya bahwa, selain Prime, metode ekspansi lainnya, termasuk saluran Lightning multi-node NUCLEUS dan pabrik saluran Ark/Enigma, akan memerlukan pengembangan lebih dari dua tahun. Namun, Prime bisa selesai hanya dalam waktu satu tahun.

Prime tidak dirancang sebagai blockchain tradisional. Sebaliknya, ini adalah lapisan penerbitan bukti modular yang dibuat khusus untuk validasi sisi klien. Ini terdiri dari empat komponen utama:

1. Layanan Timestamping: Layanan ini dapat menyelesaikan serangkaian transaksi hanya dalam 10 detik.
2. Bukti: Ini disimpan dalam bentuk Partial Merkle Trees (PMTs) dan diproduksi serta diterbitkan bersama header blok.
3. Segel Sekali Pakai: Ini adalah protokol segel sekali pakai abstrak yang dirancang untuk mencegah pembelanjaan ganda. Ketika diterapkan pada Bitcoin, ini dapat diikat ke UTXO, mirip dengan desain RGB saat ini.
4. Protokol Kontrak Cerdas: Kontrak pecahan untuk RGB (yang dapat diganti)

Dari sini, kita dapat melihat bahwa untuk mengatasi masalah waktu konfirmasi transaksi di RGB, Prime menggunakan layanan stempel waktu untuk mengonfirmasi transaksi off-chain dengan cepat dan mengemasnya dengan ID ke dalam blok. Pada saat yang sama, bukti transaksi di Prime dapat dikonsolidasikan lebih lanjut melalui PMT dan kemudian ditautkan ke BTC dengan cara seperti pos pemeriksaan.

Protokol Aset CSV berbasis akar tunggang: Aset Akar Tunggang

Taproot Assets adalah protokol aset CSV berdasarkan Taproot, yang dirancang untuk menerbitkan aset pada blockchain Bitcoin. Aset ini dapat diperdagangkan secara instan, dalam volume besar, dan dengan biaya rendah melalui Lightning Network. Inti dari Aset Taproot adalah pemanfaatan keamanan dan stabilitas Bitcoin serta kecepatan, skalabilitas, dan biaya rendah dari Lightning Network. Protokol ini dirancang dan dikembangkan oleh roasbeef, CTO Lightning Labs. Roasbeef kemungkinan adalah satu-satunya orang di planet ini yang secara pribadi memimpin pengembangan klien Bitcoin (BTCD) dan klien Lightning Network (LND), yang menunjukkan pemahaman mendalam tentang BTC.

Transaksi akar tunggang hanya membawa hash akar dari skrip aset, sehingga menyulitkan pengamat eksternal untuk mengidentifikasi apakah transaksi tersebut melibatkan Aset Akar Tunggang, karena hash itu sendiri bersifat umum dan dapat mewakili data apa pun. Dengan peningkatan Taproot, Bitcoin memperoleh kemampuan untuk mengeksekusi kontrak pintar (TapScript). Berdasarkan hal ini, pengkodean aset Aset Taproot pada dasarnya menciptakan definisi token yang mirip dengan ERC20 atau ERC721. Dengan demikian, Bitcoin tidak hanya memperoleh kemampuan untuk menentukan aset tetapi juga memperoleh kemampuan untuk menulis kontrak pintar, yang meletakkan dasar bagi infrastruktur kontrak pintar token untuk Bitcoin.

Struktur pengkodean Aset Akar Tunggang adalah sebagai berikut:

oleh roasbeef, CTO Lighting Labs

Juga sebagai protokol aset CSV, Taproot Assets memiliki desain yang lebih ringkas dibandingkan RGB. Perbedaan terbesar antara Taproot Assets dan RGB dalam hal skalabilitas aplikasi terletak pada eksekusi VM, Taproot Assets menggunakan TaprootScript VM yang sama dengan default asli BTC. Dalam beberapa tahun terakhir, banyak penelitian untuk BTC Dalam beberapa tahun terakhir, banyak penelitian infrastruktur untuk BTC didasarkan pada TapScript, namun karena lambatnya peningkatan BTC, hal ini tidak dapat diterapkan dalam waktu singkat, sehingga Dapat diprediksi bahwa Aset Akar Tunggang akan menjadi ajang uji coba ide-ide segar tersebut di masa depan.

Perbedaan Aset Akar Tunggang dan RGB

1. Validasi Transaksi dan Keramahan Light Node

Aset Akar Tunggang, karena penerapan pohon penjumlahan, memiliki efisiensi dan keamanan verifikasi yang tinggi. Hal ini memungkinkan verifikasi negara dan transaksi dilakukan hanya dengan memiliki bukti, tanpa perlu menelusuri seluruh riwayat transaksi. Sebaliknya, penggunaan komitmen Pedersen oleh RGB mempersulit verifikasi validitas masukan secara efektif. Akibatnya, RGB memerlukan penelusuran kembali riwayat transaksi input, yang dapat menjadi beban signifikan karena transaksi terakumulasi seiring berjalannya waktu. Desain pohon penjumlahan Merkel juga memungkinkan Aset Taproot memfasilitasi verifikasi node ringan dengan mudah, sebuah fitur yang sebelumnya tidak tersedia dalam protokol aset yang dibangun di atas Bitcoin.

2. Eksekusi VM

Aset Akar Tunggang dikembangkan sebagai respons terhadap peningkatan Akar Tunggang pada jaringan Bitcoin. Ini menggunakan TaprootScriptVM, yang merupakan mesin eksekusi skrip yang disertakan dengan Bitcoin setelah peningkatan Taproot. Selain itu, ia menggunakan vPSBT, varian dari PSBT Bitcoin, yang menunjukkan bahwa setelah mekanisme saluran petir Aset Taproot dikembangkan, ia dapat segera menggunakan kembali semua infrastruktur LND (Lightning Network Daemon) saat ini, serta produk-produk sebelumnya dari Lightning Labs (LND). saat ini memegang lebih dari 90% pangsa pasar di jaringan Lightning). Selain itu, proposal BitVM yang populer baru-baru ini didasarkan pada TaprootScript, yang secara teoritis berarti semua peningkatan ini pada akhirnya dapat bermanfaat bagi Aset Taproot.

Namun, RGB beroperasi agak berbeda. Mesin virtual dan aturan validasinya (SCHEMA) adalah bagian dari sistem mandiri, membentuk ekosistem yang agak tertutup. RGB beroperasi dalam ekosistemnya sendiri, dan hubungannya dengan ekosistem Bitcoin yang lebih luas tidak sedekat yang diperkirakan beberapa orang. Misalnya, sehubungan dengan peningkatan Taproot, satu-satunya interaksi nyata RGB adalah pengkodean data komitmen ke dalam blockchain di Witness TapLeaf. Hal ini menggambarkan bahwa RGB dan upgrade Taproot hanya terhubung secara minimal.

3. Kontrak Cerdas

Dalam implementasi RGB saat ini, kontrak dan VM sangat ditekankan. Namun, di Taproot Assets, tampaknya tidak ada fokus pada kontrak pintar, setidaknya belum ada. Implementasi RGB saat ini belum menjelaskan bagaimana modifikasi pada Status Global disinkronkan dengan pecahan kontrak individu (UTXO). Selain itu, meskipun komitmen Pedersen dapat memastikan jumlah total aset, masih belum jelas bagaimana negara-negara lain akan terlindungi dari gangguan, karena belum banyak penjelasan mengenai hal ini.

Di sisi lain, Taproot Assets memiliki desain yang lebih sederhana, namun saat ini hanya menyimpan saldo aset dan tidak menangani keadaan yang lebih kompleks, sehingga membuat diskusi kontrak pintar menjadi terlalu dini. Namun, menurut Lightning Labs, ada rencana untuk fokus pada desain kontrak pintar untuk Taproot Assets tahun depan.

4. Pusat Sinkronisasi

Prinsip dasar yang disebutkan sebelumnya mengenai aset yang diverifikasi di sisi klien menunjukkan bahwa memegang Bukti sama pentingnya dengan memegang kunci pribadi. Namun, ada risiko kehilangan Bukti karena disimpan di sisi klien. Bagaimana hal ini dapat diatasi? Di Aset Akar Tunggang, masalah ini dapat dihindari melalui penggunaan “alam semesta.” Alam semesta adalah pohon Merkle yang dapat diaudit secara publik dan mencakup satu atau lebih aset. Berbeda dengan pohon aset Akar Tunggang standar, alam semesta tidak digunakan untuk menyimpan aset Akar Tunggang. Sebaliknya, ia berkomitmen pada subkumpulan satu atau lebih riwayat aset.

Dalam sistem RGB, peran ini dipenuhi oleh Storm, yang menyinkronkan data bukti off-chain melalui jaringan peer-to-peer (p2p). Namun, karena alasan historis yang terkait dengan tim pengembangan RGB, tim tersebut saat ini menggunakan format bukti yang tidak kompatibel. Tim ekosistem RGB, DIBA, telah mengindikasikan bahwa mereka akan mengembangkan “carbonado” untuk mengatasi masalah ini, namun kemajuannya tidak jelas.

5. Rekayasa Implementasi

Semua perpustakaan yang digunakan oleh Taproot Assets telah teruji dengan baik, karena Lightning Labs memiliki klien Bitcoin (BTCD), klien Lightning Network (LND), dan beragam implementasi perpustakaan dompetnya sendiri. Sebaliknya, sebagian besar perpustakaan yang digunakan untuk implementasi RGB ditentukan sendiri. Dari perspektif standar industri, penerapan RGB masih dalam tahap percobaan.

Sekilas tentang masa depan penskalaan BTC

Melanjutkan diskusi, terlihat jelas bahwa protokol aset yang divalidasi klien telah melampaui cakupan protokol tradisional dan kini menuju penskalaan komputasi.

Banyak orang mengklaim bahwa di masa depan, Bitcoin akan hadir sebagai 'emas digital', sementara blockchain lainnya akan menciptakan ekosistem aplikasi. Namun, saya berpendapat berbeda. Seperti yang terlihat dalam banyak diskusi di forum Bitcoin, ada banyak pembicaraan tentang berbagai alt-coin dan masa pakainya yang singkat. Hilangnya alt-coin ini dengan cepat telah mengubah modal dan upaya yang mengelilinginya menjadi gelembung. Kami sudah memiliki Bitcoin sebagai landasan konsensus yang kuat; tidak perlu membangun solusi Layer 1 (L1) baru hanya untuk protokol aplikasi. Apa yang harus kita lakukan adalah memanfaatkan Bitcoin, infrastruktur yang kuat ini, untuk membangun dunia yang terdesentralisasi dalam jangka panjang.

Lebih sedikit komputasi on-chain, lebih banyak verifikasi on-chain

Dari perspektif desain aplikasi, Bitcoin sejak awal memilih filosofi yang tidak berpusat pada komputasi on-chain tetapi pada verifikasi (kelengkapan Turing dan status untuk kontrak pintar). Inti dari blockchain adalah mesin negara yang direplikasi. Jika konsensus blockchain berfokus pada komputasi on-chain, sulit untuk berargumentasi bahwa meminta setiap node di jaringan mengulangi komputasi ini adalah pendekatan yang masuk akal dan terukur. Jika fokusnya adalah pada verifikasi, maka memvalidasi transaksi off-chain mungkin merupakan pendekatan yang paling sesuai untuk skalabilitas Bitcoin.

Di mana verifikasi dilakukan? Ini sangat penting.

Bagi pengembang yang membuat protokol di atas Bitcoin, cara menggunakan Bitcoin untuk verifikasi penting, atau bahkan menempatkan verifikasi secara off-chain, dan cara merancang skema yang aman, adalah urusan perancang protokol itu sendiri. Mereka tidak boleh dan tidak perlu dikaitkan dengan rantai itu sendiri. Cara menerapkan verifikasi akan menghasilkan solusi penskalaan yang berbeda untuk BTC.

Dari perspektif penerapan berbasis verifikasi, kami memiliki tiga arah penskalaan:

1.Verifikasi on-chain (OP-ZKP)

Menerapkan OP-ZKP secara langsung di TaprootScriptVM akan memberi Bitcoin kemampuan untuk melakukan verifikasi ZKP. Hal ini, ditambah dengan beberapa protokol penyelesaian desain Kovenan, dapat menciptakan solusi penskalaan Zk-Rollup yang mewarisi keamanan Bitcoin. Namun, tidak seperti menerapkan kontrak verifikasi pada Ethereum, pemutakhiran Bitcoin pada dasarnya lambat, dan menambahkan op-code khusus yang berpotensi membutuhkan pemutakhiran pasti akan menjadi sebuah tantangan.

2.Verifikasi pada semi-on-chain (BitVM)

Desain BitVM memastikan bahwa ini tidak dimaksudkan untuk logika transaksi biasa. Robin Linus juga mengindikasikan bahwa masa depan BitVM terletak pada penciptaan pasar lintas rantai gratis untuk berbagai SideChain. Pendekatan BitVM dianggap semi-on-chain karena sebagian besar perhitungan verifikasi tidak akan dilakukan secara on-chain melainkan off-chain. Alasan penting untuk merancang Taproot Bitcoin adalah untuk memanfaatkan TapScriptVM untuk verifikasi komputasi bila diperlukan, yang secara teoritis mewarisi keamanan Bitcoin. Proses ini juga menghasilkan rantai kepercayaan verifikasi, seperti hanya memerlukan satu verifikator yang jujur di antara 'n' verifikator, yang dikenal sebagai Optimistic Rollup.

BitVM menimbulkan overhead on-chain yang signifikan, namun bisakah BitVM menggunakan bukti penipuan ZK untuk meningkatkan efisiensi? Jawabannya adalah tidak, karena penerapan bukti penipuan ZK bergantung pada kemampuan melakukan verifikasi ZKP secara on-chain, sehingga membawa kita kembali ke kesulitan pendekatan OP-ZKP.

3.Verifikasi off-chain (Validasi Sisi Klien, Lightning Network)

Verifikasi off-chain lengkap mengacu pada protokol aset CSV yang telah dibahas sebelumnya dan Lightning Network. Seperti yang terlihat pada diskusi sebelumnya, kita tidak dapat sepenuhnya mencegah kolusi dalam desain CSV. Apa yang dapat kita lakukan adalah menggunakan kriptografi dan desain protokol untuk menjaga kerusakan akibat kolusi jahat dalam batas yang dapat dikendalikan, sehingga tindakan tersebut tidak menguntungkan.

Keuntungan dan kerugian dari verifikasi off-chain juga jelas. Keuntungannya adalah ia menggunakan sumber daya on-chain yang minimal dan memiliki potensi skalabilitas yang besar. Kerugiannya adalah hampir tidak mungkin untuk sepenuhnya mewarisi keamanan Bitcoin, sehingga sangat membatasi jenis dan metode transaksi off-chain yang dapat dilakukan. Selain itu, verifikasi off-chain juga menyiratkan bahwa data disimpan di luar rantai, dikelola oleh pengguna sendiri, sehingga memberikan tuntutan lebih tinggi pada keamanan lingkungan eksekusi perangkat lunak dan stabilitas perangkat lunak.

Tren Evolusi Penskalaan

Saat ini, solusi Lapisan 2 yang populer di Ethereum, dalam istilah paradigma, memvalidasi penghitungan Lapisan 2 melalui Lapisan 1, artinya penghitungan status diturunkan ke Lapisan 2, namun verifikasi masih dipertahankan di Lapisan 1. Di masa depan, kami juga dapat mendorong komputasi verifikasi secara off-chain, sehingga semakin meningkatkan kinerja infrastruktur blockchain saat ini.

Penafian:

1. Artikel ini dicetak ulang dari [mirror]. Semua hak cipta milik penulis asli [Ben77]. Jika ada keberatan terhadap cetak ulang ini, silakan menghubungi tim Gate Learn , dan mereka akan segera menanganinya.
2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini adalah sepenuhnya milik penulis dan bukan merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, dilarang menyalin, mendistribusikan, atau menjiplak artikel terjemahan.