Abstrak

Artikel ini membahas metode praktis untuk mengaktifkan verifikasi ZK dalam Bitcoin, mencakup topik seperti model UTXO Bitcoin, batasan scripting, Taproot, OP_CAT, BitVM, dan Bukti Status Rantai. Ini menyajikan argumen yang jelas bahwa integrasi ZK ke dalam protokol Bitcoin tidak terhindarkan. Dua rute potensial dijelaskan: yang pertama adalah memperkenalkan opcode OP_CAT untuk mendukung verifikasi SNARK secara langsung dalam skrip Bitcoin - perubahan yang memiliki kemungkinan persetujuan di masa depan yang tinggi. Pendekatan kedua berkaitan dengan BitVM, yang mencakup bukti penipuan. Selain itu, proposal tim ZeroSync untuk Bukti Status Rantai bertujuan untuk mengurangi biaya verifikasi data historis untuk klien node.

Teks Utama: Untuk benar-benar memahami Bitcoin, bermanfaat untuk melihatnya sebagai sistem sosial. Pada awalnya, para pencipta Bitcoin mendefinisikan perangkat lunak yang harus dijalankan oleh node, mirip dengan menetapkan aturan yang mengatur suatu masyarakat. Stabilitas Bitcoin bergantung pada konsensus luas tentang sifat mendasarnya, yang mengarah pada pertanyaan seperti "Apa inti Bitcoin?" dan "Apa yang seharusnya menjadi evolusi Bitcoin?" Namun, mencapai konsensus tentang pertanyaan-pertanyaan ini sangat sulit, karena pendapat bervariasi luas dan terus berkembang.

Hal ini kembali ke asal usul historis Bitcoin. Ketika Satoshi Nakamoto merilis white paper Bitcoin, beliau mengatakan: “Saya sedang mengerjakan sistem pembayaran elektronik yang benar-benar baru. Sistem ini benar-benar P2P dan tidak perlu bergantung pada pihak ketiga mana pun.” Passsage ini dipublikasikan di daftar milis Cypherpunks (sebuah grup diskusi melalui email yang didirikan pada tahun 1992, terdiri dari sekelompok kriptografer dan penggemar teknologi yang peduli tentang perlindungan privasi dan teknologi kriptografi).

Namun, Bitcoin membatasi throughput data pada tingkat desain produk. Jumlah transaksi yang dapat diproses per unit waktu terbatas. Jika jumlah transaksi yang akan diproses meningkat dengan cepat, pengguna akan memulai perang harga untuk berhasil menyelesaikan transaksi dengan cepat, yang akan meningkatkan biaya penanganan yang dibayarkan dengan cepat. Transaksi tunggal dengan biaya penanganan tertinggi di jaringan Bitcoin terjadi setelah hadiah blok dibagi dua pada tahun 2024, dan biaya penanganan untuk transaksi dengan prioritas sedang di rantai mencapai $150. Dapat dikatakan bahwa biaya transaksi mahal jaringan Bitcoin telah menjadi masalah.

Untuk mengatasi masalah biaya transaksi, orang telah menginvestasikan banyak sumber daya ke pengembangan Jaringan Petir. Tetapi menurut sebuah makalah yang diterbitkan pada tahun 2016, Jaringan Petir hanya dapat mendukung puluhan juta pengguna dalam praktek dan tidak dapat mewujudkan visinya sebagai sistem pembayaran global. Selain biaya transaksi yang terlalu mahal, ada masalah lain, yaitu Bitcoin tidak pernah berhasil mencapai anonimitas yang diinginkannya.

Satoshi Nakamoto menunjukkan dalam kelompok diskusi email cypherpunk bahwa Bitcoin memiliki fungsi perlindungan privasi dan inisiator transaksi dapat benar-benar anonim. Namun, meskipun inisiator transaksi tidak memerlukan KYC, data transaksi pada rantai Bitcoin bocor banyak informasi, mengekspos privasi pengguna secara besar-besaran. Meskipun ada beberapa klien dompet dengan fungsi privasi yang menyelesaikan masalah di atas sebagian, pengembang klien dompet ini menghadapi ancaman berbagai ukuran. Misalnya, pengembang dompet Samourai CoinJoin ditangkap oleh FBI pada April 2024, dan seminggu kemudian, pengembang dompet Wasabi menutup komponen koordinasi CoinJoin mereka. Jelas, dompet privasi yang disebut-sebut ini tidak sepenuhnya layak dipercayai oleh pengguna.

Singkatnya, banyak konsep Bitcoin masih jauh dari terwujud hingga saat ini, dan teknologi terkait masih terus berkembang. Meskipun begitu, banyak orang dalam komunitas Bitcoin percaya bahwa desain protokol Bitcoin seharusnya tetap tidak berubah, namun juga banyak orang, seperti saya, yang antusias melakukan perbaikan pada Bitcoin. Jadi, ke arah mana seharusnya Bitcoin melakukan perbaikan?

Menanggapi masalah di atas, ada banyak proposal di komunitas Bitcoin, dan yang memiliki hasil teori terbaik harus terkait dengan ZK dan SNARKs. Dengan ZK dan SNARKs, fitur-fitur berikut dapat dicapai:

1. Peningkatan privasi yang signifikan: menggunakan komitmen Peterson homomorfik untuk jumlah transaksi dan Range Proof untuk secara signifikan meningkatkan privasi pengguna (seperti yang dilakukan di side chain Element Blockstream); menggunakan tanda tangan yang dapat dihubungkan (seperti Monero) untuk menyembunyikan jejak transaksi; mencapai transaksi yang benar-benar pribadi (seperti Zcash).

2. Meningkatkan throughput transaksi

Banyak solusi teknis yang dapat mengatasi masalah-masalah yang ada pada Bitcoin, tetapi mengapa teknologi-teknologi ini belum diintegrasikan ke dalam protokol Bitcoin? Jawabannya terletak pada kesulitan dalam memodifikasi protokol. Tidak seperti Ethereum, Bitcoin tidak memiliki organisasi terpusat seperti Yayasan Ethereum. Setiap perubahan protokol memerlukan tingkat konsensus komunitas yang tinggi, melibatkan negosiasi yang luas dan keseimbangan kepentingan. Akibatnya, sementara Ethereum secara teratur memperbarui opcode EVM-nya, protokol Bitcoin hanya mengalami sedikit perubahan sejak awal mula.

Dalam beberapa hal, kesulitan dalam memodifikasi protokol ini bermanfaat. Jika perubahan mudah untuk diimplementasikan, modifikasi jahat atau serangan akan lebih mungkin terjadi. Ini menimbulkan pertanyaan: Bagaimana kinerja Bitcoin dapat ditingkatkan tanpa mengubah protokol?

Untuk menjawab ini, kita perlu mengulang beberapa dasar-dasar Bitcoin. Ketika Anda mentransfer Bitcoin ke orang lain, Anda membuat transaksi dan menyiarkannya ke jaringan Bitcoin. Data output transaksi menentukan jumlah BTC yang ditransfer. Penerima kemudian dapat membuat transaksi baru untuk menghabiskan BTC yang diterima, menghasilkan data output baru dalam prosesnya.

Penting untuk dicatat bahwa Bitcoin tidak memiliki keadaan global seperti Ethereum, terutama kekurangan keadaan akun; hanya memiliki data output transaksi. Setiap output transaksi memiliki dua keadaan: baik telah dihabiskan oleh penerima atau tetap tidak terpakai. Output transaksi yang tidak terpakai (UTXO) adalah yang kita kenal. Selain jumlah BTC yang terkait, setiap output transaksi juga memiliki skrip terlampir yang ditulis dalam Bitcoin Script. Siapa pun yang dapat memberikan bukti yang benar (Saksi) untuk skrip ini dapat menghabiskan UTXO.

Skrip Bitcoin adalah bahasa pemrograman berbasis tumpukan dengan serangkaian opcode. Program-program yang terlampir pada UTXO sering terdiri dari beberapa opcode, melakukan perhitungan berdasarkan tumpukan dan mengembalikan hasil kepadanya. Banyak skrip Bitcoin umum telah ada sejak awal Bitcoin. Sebagai contoh, skrip paling umum terdiri dari kunci publik dan sebuah opcode yang memeriksa tanda tangan digital. Opcode ini mensyaratkan bahwa untuk menghabiskan atau membuka kunci UTXO, seseorang harus memberikan tanda tangan digital yang sesuai dengan kunci publik.

Bacaan yang Direkomendasikan: [ Mendekati BTC: Pengetahuan Latar Belakang untuk Memahami BitVM (1)]

Kemampuan Skrip Bitcoin

Apa yang dapat dilakukan oleh Bitcoin Script:

• Susun ulang tumpukan dan lakukan pemeriksaan kesetaraan (untuk memverifikasi kondisi-kondisi tertentu dan memastikan keamanan dan validitas transaksi).
• Melakukan operasi bersyarat yang mirip dengan pernyataan if-else.
• Melakukan operasi aritmatika terbatas pada angka 32-bit, seperti penjumlahan dan pengurangan.
• Data hash dan verifikasi tanda tangan ECDSA dan Schnorr.

Apa yang Bitcoin Script Tidak Dapat Lakukan:

• Tidak ada pengulangan, lompatan, atau rekursi; ini tidak lengkap dalam Turing, dengan kemampuan pemrograman yang sangat terbatas.
• Tidak dapat melakukan operasi bitwise.
• Kurang opcode untuk perkalian dan pembagian.
• Tidak dapat menggabungkan elemen pada tumpukan.
• Memiliki kemampuan yang sangat terbatas untuk membaca dan memverifikasi data transaksi on-chain. Skrip Bitcoin tidak dapat langsung mengakses jumlah setiap transaksi dan tidak dapat melewati status (UTXO hanya dapat digunakan sekali, dan setiap transfer membakar yang lama dan menghasilkan yang baru).

Pada versi awal Bitcoin, beberapa fungsi 'tidak dapat dilakukan' yang disebutkan di atas memang mungkin dilakukan, tetapi beberapa opcode kemudian dinonaktifkan oleh Satoshi Nakamoto karena adanya kerentanan keamanan. Sebagai contoh, opcode OP_CAT, yang dapat menggabungkan dua elemen stack, digunakan untuk menyerang node Bitcoin dari jarak jauh dan menyebabkan kegagalan. Satoshi menonaktifkan OP_CAT dan opcode lainnya karena alasan keamanan.

Jadi, apakah Bitcoin Script dapat memverifikasi SNARKs? Secara teori, meskipun Bitcoin Script tidak lengkap dalam hal Turing, operasi dasarnya sudah cukup untuk memverifikasi komputasi apa pun. Namun, dalam praktiknya, verifikasi SNARK tidak layak dilakukan karena ukuran program yang diperlukan untuk langkah-langkah verifikasi melebihi batas blok maksimum Bitcoin sebesar 4MB. Meskipun kita dapat mencoba operasi aritmatika dalam bidang terbatas yang besar, biayanya akan sangat tinggi. Misalnya, dalam BitVM, perkalian dua bilangan bulat 254-bit menghasilkan ukuran skrip Bitcoin hampir 8KB. Selain itu, tanpa OP_CAT, biaya verifikasi bukti Merkle juga tinggi, karena ini memerlukan operasi yang mirip dengan perulangan.

Lalu, mengapa tidak hanya memodifikasi protokol Bitcoin untuk menambahkan opcode yang lebih kuat? Seperti yang telah disebutkan sebelumnya, mencapai konsensus mayoritas tentang aturan protokol baru sangat sulit. Bitcoin tidak memiliki pembuat keputusan terpusat, dan setiap proposal untuk meningkatkan Bitcoin Script menghadapi oposisi yang signifikan dari pemangku kepentingan dengan perspektif yang berbeda. Tidak ada cara yang efektif untuk mengukur konsensus komunitas di jaringan Bitcoin, dan memaksa pembaruan tanpanya bisa menyebabkan terjadinya pemisahan rantai. Tentu saja, Bitcoin tidak sepenuhnya tidak dapat diubah. Pembaruan terbaru adalah SegWit pada tahun 2017 dan Taproot pada tahun 2021.

Peningkatan Taproot, yang mengubah banyak aturan, memerlukan waktu tiga setengah tahun untuk beralih dari rilis teoritis ke aktivasi aktual. Faktor kunci dalam memungkinkan Taproot adalah bahwa itu tidak mengubah asumsi keamanan yang ada dan membuat perbaikan yang jelas pada protokol Bitcoin. Misalnya, itu memungkinkan penggunaan tanda tangan Schnorr daripada ECDSA. Kedua-duanya didasarkan pada asumsi logaritma diskret dan menggunakan kurva eliptis yang sama, tetapi yang pertama lebih efisien dan membutuhkan perhitungan yang lebih sedikit.

Selain itu, peningkatan Taproot pada Bitcoin dapat dikategorikan ke dalam tiga aspek berikut:

Pertama, Taproot mengurangi biaya verifikasi skrip dengan banyak cabang kondisional, memungkinkan Bitcoin untuk mendukung program yang lebih kompleks.

Kedua, Taproot mengurangi jumlah data skrip yang harus dinyatakan di rantai, dan Anda dapat menggabungkan beberapa program skrip ke dalam pohon Merkle, dengan setiap skrip terletak di daun yang berbeda. Jika Anda ingin memicu skrip tertentu, Anda hanya perlu mengungkapkan daun tempat skrip tersebut berada dan bukti Merkle;

Ketiga, Taproot juga menambahkan desain mekanisme lainnya.

Mengingat preseden Bitcoin dengan Taproot untuk mengintegrasikan fitur lebih canggih, seseorang mungkin bertanya-tanya mengapa opcode khusus untuk verifikasi SNARK belum diperkenalkan. Perbedaan kunci terletak pada kompleksitas dan konsensus yang diperlukan untuk OP_SNARK. Tidak seperti Taproot, yang memiliki desain yang jelas dan mudah dipahami yang mendapatkan dukungan luas, proposal OP_SNARK bervariasi secara luas, sehingga sulit untuk mempersatukan komunitas di sekitar satu pendekatan. Jika diimplementasikan, setiap node Bitcoin harus mendukung metode verifikasi SNARK tertentu ini, yang akan signifikan meningkatkan tuntutan teknis. Selain itu, kompleksitas inheren OP_SNARK adalah hambatan utama - Taproot menambahkan sekitar 1.600 baris kode, yang dapat dikelola oleh standar komunitas, sedangkan OP_SNARK akan melibatkan pemrograman yang jauh lebih rumit. Selain itu, menentukan siapa yang akan menilai aktivasi OP_SNARK dan mencapai konsensus ketika sedikit yang sepenuhnya memahami kompleksitasnya menambahkan lapisan kesulitan. Mengingat tantangan-tantangan ini, peningkatan OP_SNARK tidak mungkin terwujud dalam waktu dekat.

Namun, ada cara lain untuk memverifikasi SNARKs dalam Bitcoin Script. Kita dapat membuat skrip Bitcoin lebih fungsional dengan menambahkan opcode yang lebih sederhana, memungkinkan orang untuk mengimplementasikan program SNARK validator dalam skrip. Tetapi sebenarnya, sangat sulit untuk menulis program verifikasi SNARK dalam bahasa skrip Bitcoin. Oleh karena itu, tim penelitian Blockstream sedang mengembangkan Simplicity, bahasa pemrograman yang dirancang untuk menggantikan Bitcoin Script. Simplicity dirancang khusus untuk sistem konsensus blockchain dan sengaja tidak Turing-lengkap, sehingga mudah untuk analisis statis dan verifikasi formal.

Mari kita arahkan perhatian kita pada proposal yang tampaknya sederhana tetapi sangat berdampak yang dapat secara signifikan meningkatkan kemampuan scripting Bitcoin: reaktivasi opcode OP_CAT. OP_CAT awalnya termasuk dalam kode awal Bitcoin tetapi kemudian dinonaktifkan oleh Satoshi Nakamoto karena potensinya untuk memungkinkan serangan DoS dalam kondisi tertentu. Namun, saat ini ada minat yang semakin meningkat di kalangan komunitas Bitcoin untuk mengaktifkannya kembali.

Fungsi OP_CAT sangat mudah - ia mengambil dua elemen teratas dari stack, menggabungkannya, dan kemudian mendorong hasil kembali ke stack. Meskipun ini mungkin terlihat dasar, ia memiliki potensi untuk membuka peningkatan substansial dalam bahasa scripting Bitcoin. Misalnya, skrip Bitcoin saat ini tidak dapat mengakses beberapa data transaksi di rantai, seperti jumlah yang terlibat, tetapi dengan OP_CAT, kemampuan ini dapat diperkenalkan. Selain itu, OP_CAT dapat menjadi instrumen dalam memverifikasi bukti Merkle.

Pada dasarnya, OP_CAT adalah peningkatan opcode tingkat rendah yang dapat menghasilkan berbagai macam fungsionalitas baru. Banyak yang menunjukkan bahwa OP_CAT dapat menjadi krusial dalam mencapai berbagai tujuan. Pertanyaan kunci adalah apakah OP_CAT dapat membantu dalam verifikasi SNARK dalam skrip. Jawabannya adalah ya. Karena verifikasi bukti Merkle adalah langkah menuju validasi SNARK berbasis FRI, OP_CAT akan menjadi tambahan yang berharga. Di masa lalu, skrip yang dirancang untuk verifikasi SNARK mungkin terlalu besar untuk muat dalam batasan ukuran blok Bitcoin, tetapi OP_CAT dapat membantu menyederhanakan skrip ini, sehingga lebih kompak.

OP_CAT telah didiskusikan selama bertahun-tahun, dengan kesadaran akan peran potensialnya dalam introspeksi transaksi semakin meningkat. Salah satu keuntungan utamanya dibanding proposal lain adalah bahwa OP_CAT pernah menjadi bagian integral dari Bitcoin Script, yang dapat membuatnya lebih mudah dicapai konsensus komunitas. Namun, kelemahannya adalah mengaktifkan OP_CAT dapat secara negatif memengaruhi keuntungan MEV (Miner Extractable Value) bagi beberapa orang, yang telah menyebabkan debat yang berkelanjutan di dalam komunitas tentang reaktivasi OP_CAT.

Secara ringkas, Bitcoin bisa melangkah menuju memungkinkan verifikasi SNARK dalam skrip dengan memperkenalkan kembali opcode yang mudah seperti OP_CAT. Selain itu, layak disebutkan sebuah proposal terbaru yang disebut "Great Script Restoration," yang memperkenalkan kembali opcode perkalian dan memungkinkan semua operasi aritmatika dilakukan dengan presisi sembarang.

Selain itu, ketika mengevaluasi dampak OP_CAT pada jaringan Bitcoin, penting untuk mempertimbangkan efeknya terhadap operator node Bitcoin. Untuk memastikan Bitcoin tetap tahan sensor dan terdesentralisasi, komunitas berusaha memiliki sebanyak mungkin orang yang menjalankan node untuk memvalidasi transaksi. Jika Bitcoin mengimplementasikan verifikasi SNARK, hal ini tidak akan signifikan meningkatkan biaya pengoperasian sebuah node, yang tidak akan sangat mempengaruhi keamanan atau ketahanan sensor Bitcoin.

Saat ini, sebuah blok Bitcoin dapat menampung hingga 4MB data, dengan blok baru ditambang sekitar setiap 10 menit. Sebagian besar blok diisi dengan skrip Bitcoin dan data Saksi (mirip dengan tanda tangan digital). Rata-rata, setiap blok dapat menampung antara 7.000 hingga 10.000 verifikasi tanda tangan, dengan maksimum sekitar 80.000 verifikasi per blok. Untuk konteks, CPU Intel saya tahun 2020 membutuhkan sekitar 3,2 detik untuk memverifikasi blok Bitcoin. Tentu saja, kecepatan verifikasi blok dipengaruhi oleh faktor-faktor selain waktu verifikasi tanda tangan.

Selain itu, jika transaksi Bitcoin akhirnya mendukung bukti zero-knowledge (ZK), peningkatan waktu generasi transaksi mungkin tidak menjadi perhatian utama. Dompet hardware, yang digunakan untuk penyimpanan aset jangka panjang, biasanya memiliki layar dan desain kompak yang difokuskan pada penyimpanan kunci dan pembuatan tanda tangan. Dompet ini biasanya memiliki CPU dengan daya rendah, seperti prosesor dual-core 240MHz, namun mereka mengelola transaksi Bitcoin dengan efisien.

Saya melakukan survei kecil yang bertanya kepada pengguna tentang keterlambatan maksimum yang mereka terima untuk perangkat penandatanganan menghasilkan bukti, dan banyak orang setuju dengan waktu tunggu yang lebih lama, terutama jika ada keuntungan signifikan yang dapat diperoleh. Jadi jika kita memperkenalkan ZK ke transaksi Bitcoin, sepertinya tidak ada masalah besar. Kami telah menghabiskan banyak waktu untuk mendiskusikan perubahan potensial pada desain dasar Bitcoin, tetapi ada banyak aplikasi yang dapat dikembangkan tanpa mengubah Bitcoin itu sendiri. Salah satu aplikasi yang layak disebutkan adalah Chain State Proofs, yang terkait dengan BitVM. Pendekatan ini menggunakan bukti zero-knowledge untuk memvalidasi kebenaran hash blok.

Apa dampak teknologi ini terhadap Bitcoin? Pertama, Bukti Keadaan Rantai dapat sangat mengurangi beban yang terlibat dalam sinkronisasi dan verifikasi data historis Bitcoin, yang pada gilirannya menurunkan biaya menjalankan node. Saat ini, sinkronisasi dan verifikasi data dari blok genesis hingga blok terbaru membutuhkan sekitar 5 jam 30 menit pada perangkat high-end, dan beberapa hari pada perangkat tingkat Raspberry Pi. Bukti Keadaan Rantai bisa secara signifikan mempersingkat proses ini.

Kedua, Bukti Keadaan Rantai memainkan peran penting dalam memajukan BitVM. Tim ZeroSync telah menyelidiki secara menyeluruh Bukti Keadaan Rantai dan mengembangkan versi yang disederhanakan yang disebut “bukti rantai header.” Pendekatan ini menggunakan bukti pengetahuan nol untuk memvalidasi header blok Bitcoin, menciptakan “rantai header” yang mencakup semua 850.000 header blok dalam sejarah Bitcoin. Setiap header blok di-hash untuk menghasilkan bukti 80-byte. Metode ini memerlukan perhitungan SHA-256 ganda untuk setiap header untuk memverifikasi bukti kerja yang terkait. ZeroSync memanfaatkan STARKs untuk menghasilkan bukti rantai header ini, dengan biaya sekitar $4.000 untuk diproduksi, sementara verifikasi hanya membutuhkan sekitar 3 detik di peramban saya.

Namun, karena bukti rantai header tidak memverifikasi transaksi di dalam blok, mereka hanya dapat berasumsi bahwa blockchain dengan bukti kerja (PoW) yang paling banyak adalah valid dan mengandalkan klien Bitcoin untuk menyinkronkan blok terbaru dari rantai ini. Dalam konfigurasi ini, seorang penyerang pada dasarnya dapat membuat blok dengan transaksi yang tidak valid, menambahkan lebih banyak blok setelahnya, dan menghasilkan bukti rantai header untuk memperdaya klien yang menyinkronkan data historis. Namun, biaya serangan seperti itu akan sangat tinggi, dan kemungkinan akan terdeteksi oleh klien node penuh Bitcoin yang sudah ada.

Namun, meskipun peluang serangan semacam itu berhasil sangat kecil, jika berhasil memungkinkan penyerang untuk mencuri jumlah BTC yang signifikan, bukti rantai header tidak akan dianggap sebagai solusi yang sepenuhnya aman. Untuk memverifikasi seluruh keadaan rantai, kita perlu memastikan bahwa semua konten blok Bitcoin valid, termasuk verifikasi tanda tangan ECDSA dan Schnorr berdasarkan kurva eliptik secp256k1. Blok historis Bitcoin mengandung sekitar 30 juta tanda tangan setiap bulannya, dengan total sekitar 2,5 miliar tanda tangan secara historis, bersamaan dengan banyak komputasi SHA-256. Akibatnya, jaringan Bitcoin menghasilkan sekitar 7GB data blok setiap bulannya, dengan data historis melampaui 650GB—dan dalam praktiknya, angka ini mungkin 2 hingga 3 kali lebih tinggi.

Sekarang, mari kita lihat BitVM. BitVM memungkinkan Bitcoin memverifikasi tugas komputasi apa pun, memberikan cara optimal untuk melakukan verifikasi SNARK tanpa mengubah protokol. BitVM mengatasi keterbatasan ukuran skrip Bitcoin menggunakan dua metode. Pertama, ia memanfaatkan struktur skrip Taproot MerkleTree. Kedua, itu menggunakan skema penyimpanan KV yang dapat diakses melalui skrip individu, memfasilitasi koneksi ke sejumlah besar program skrip. Namun, protokol Bitcoin tidak menegakkan integritas skema penyimpanan KV ini. BitVM menangani ini dengan menggunakan bukti kecurangan untuk mendeteksi Prover jahat. Jika Prover membuat klaim yang tidak valid atau menggunakan penyimpanan KV yang rusak, orang lain dapat memulai transaksi di blockchain Bitcoin untuk melaporkan perilaku Prover yang tidak benar dan menyita aset yang dipertaruhkan.

Secara ringkas, Bitcoin sedang berjuang dengan tantangan-tantangan signifikan, dan sementara berbagai proposal telah diajukan untuk mengatasi ini, mendapatkan penerimaan yang cepat dari komunitas Bitcoin tidak mungkin. Perubahan protocol tidak dapat dicapai dalam jangka pendek, yang mencerminkan kekuatan dan keterbatasan desentralisasi dan keamanan Bitcoin. Potensi SNARKs dan STARKs menimbulkan kegembiraan yang considerable dalam komunitas. BitVM tampaknya menjadi metode paling menjanjikan untuk mengintegrasikan verifikasi SNARK dalam jangka menengah hingga panjang, meskipun memerlukan penelitian dan pengembangan lebih lanjut untuk menjadi sepenuhnya praktis. Mengaktifkan kembali opcode OP_CAT adalah jalur lain yang perlu dieksplorasi, tetapi perlu menunjukkan bahwa manfaat dari reaktivasi lebih besar dari risikonya, dan mengidentifikasi opcode sederhana mana yang dapat memfasilitasi verifikasi SNARK atau fungsi serupa dalam skrip Bitcoin. Pada akhirnya, komunitas Bitcoin bertujuan untuk meningkatkan praktikabilitas teknologi dan mendukung lebih banyak kasus penggunaan yang dapat dijalankan.

Baca konten asli di sini: https://www.youtube.com/watch?v=GrSCZmFuy7U

Disclaimer：

1. Artikel ini dicetak ulang dari [Geek Web3], Semua hak cipta milik penulis asli [ Geek Web3]. Jika ada keberatan terhadap cetak ulang ini, silakan hubungi Gate Belajartim, dan mereka akan menanganinya dengan cepat.
2. Penafian Tanggung Jawab: Pandangan dan pendapat yang terdapat dalam artikel ini sepenuhnya merupakan milik penulis dan tidak merupakan nasihat investasi.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.