Meskipun cakupan proposal sangat luas, apa yang mungkin menjadi alasan mengapa "Great Script Recovery" milik Rusty Russell dianggap sebagai jalur maju pengembangan Bitcoin?

Catatan unicorn blok: Rusty Russell adalah pengembang aktif dalam komunitas Bitcoin dan sangat dihormati di dalamnya. Dia telah membuat kontribusi luar biasa untuk pengembangan kernel Linux dan telah terlibat dalam berbagai proyek pengembangan inti Bitcoin.

Ketika Bitcoin dirancang awalnya, itu termasuk bahasa scripting lengkap yang dimaksudkan untuk mencakup dan mendukung setiap kasus penggunaan keamanan potensial yang mungkin diajukan pengguna di masa depan. Seperti yang dinyatakan Satoshi Nakamoto sebelum menghilang:

"Sifat Bitcoin sedemikian rupa sehingga begitu versi 0.1 dirilis, desain intinya ditetapkan selama sisa masa pakainya. Karena itu, saya ingin merancangnya untuk mendukung setiap jenis transaksi yang dapat saya pikirkan, tetapi di versi yang lebih baru, kami menghapus kemampuan untuk menjalankan skrip arbitrer. Masalahnya adalah bahwa setiap fitur memerlukan kode dukungan khusus dan bidang data, apakah mereka digunakan atau tidak, yang menyebabkan terlalu banyak kasus khusus. Solusinya adalah skrip, yang menggeneralisasi masalah sehingga transaksi dapat menggambarkan kondisi mereka dengan cara yang spesifik untuk mereka, dan node jaringan dapat mengevaluasi dan memvalidasi kondisi ini. "- Satoshi Nakamoto, 17 Juni 2010

Tujuan utamanya adalah memberikan pengguna bahasa yang cukup umum untuk memungkinkan mereka mengatur jenis transaksi mereka sesuai dengan keinginan mereka. Dengan kata lain, memberikan pengguna ruang untuk merancang dan bereksperimen dengan cara mereka menulis uang mereka sendiri.

Sebelum menghilang, Satoshi Nakamoto menghapus 15 opcode, menonaktifkannya sepenuhnya, dan menambahkan batas keras pada ukuran blok data yang dapat beroperasi pada tumpukan mesin skrip (520 byte). Hal ini karena dia secara efektif melakukan kesalahan, meninggalkan banyak cara skrip kompleks yang berpotensi digunakan untuk melakukan serangan DOS pada seluruh jaringan (mengirim jumlah permintaan sampah yang besar, menyebabkan paralisis jaringan), menciptakan transaksi yang besar dan mahal yang dapat membuat node crash.

Opcodes ini tidak dihapus karena Satoshi Nakamoto menganggap fungsionalitas ini berbahaya, atau bahwa orang tidak boleh mengeksploitasi mereka untuk membangun apa yang mereka bisa, tetapi hanya (setidaknya pada permukaan) karena mereka menimbulkan risiko bagi seluruh jaringan tanpa batasan sumber daya, dan oleh karena itu mungkin memberlakukan biaya verifikasi terburuk pada jaringan tanpa batasan.

Sejak saat itu, setiap upgrade Bitcoin pada akhirnya menjadi optimalisasi fitur yang tersisa, memperbaiki kelemahan yang kurang parah yang ditinggalkan kepada kita oleh Satoshi Nakamoto, dan memperluas fungsionalitas subset skrip yang kita miliki.

Pemulihan skrip yang hebat

Pada konferensi Bitcoin++ di Austin pada awal Mei, pengembang inti Lightning Network Rusty Russell membuat proposal yang sangat radikal dalam pidatonya pertama di konferensi tersebut, di mana ia pada dasarnya mengusulkan untuk mengaktifkan kembali sebagian besar opcode yang dinonaktifkan oleh Satoshi Nakamoto sebelum menghilang pada tahun 2010.

Sejak aktivasi Taproot pada tahun 2021 (Taproot adalah peningkatan signifikan untuk Bitcoin yang bertujuan untuk meningkatkan privasi, keamanan, dan skalabilitas), bidang pengembangan agak tidak berarah. Dipahami dengan baik bahwa Bitcoin kurang memiliki skalabilitas yang cukup untuk benar-benar menyediakan layanan kedaulatan kepada populasi signifikan di dunia, atau bahkan untuk menyediakan skalabilitas dengan cara yang paling sedikit dipercayai atau berpengelola yang dapat melampaui lembaga-lembaga penitipan besar dan penyedia layanan, dan tidak dapat benar-benar lepas dari kendali pengawasan pemerintah.

Artikel ini menyoroti pemahaman pada tingkat teknis Bitcoin, yang bukanlah masalah yang diperdebatkan. Masalah yang dapat diperdebatkan adalah bagaimana mengatasi kekurangan ini, yang merupakan topik yang sangat kontroversial. Sejak proposisi Taproot, semua orang telah mengusulkan proposal yang sangat sempit yang bertujuan untuk memecahkan masalah yang hanya dapat dicapai dengan kasus penggunaan tertentu.

Sebagai contoh, ANYPREVOUT (APO) adalah proposal yang memungkinkan tanda tangan digunakan kembali di berbagai transaksi selama skrip input dan jumlahnya sama. Proposal ini dirancang khusus untuk mengoptimalkan Jaringan Lightning dan versi multi-party-nya. CHECKTEMPLATEVERIFY (CTV) adalah proposal yang mengharuskan koin dihabiskan hanya oleh transaksi yang persis sama dengan transaksi yang telah ditentukan sebelumnya. Proposal ini dirancang untuk memperluas fungsionalitas rantai transaksi yang telah ditandatangani sebelumnya dengan membuatnya sepenuhnya tanpa kepercayaan. OP_VAULT dirancang khusus untuk menetapkan "waktu habis" untuk solusi penyimpanan dingin sehingga pengguna dapat "membatalkan" penarikan dari penyimpanan dingin dengan mengirimkannya ke setup multi-signature yang lebih dingin untuk mencegah kunci mereka bocor.

Ada banyak usulan lain, tetapi saya pikir Anda telah memahami poin-poin kunci. Selama beberapa tahun terakhir, setiap usulan ditujukan untuk sedikit meningkatkan skalabilitas atau meningkatkan fitur kecil tunggal, karena hal ini dianggap diinginkan. Itulah mengapa diskusi ini tidak berkembang. Tidak ada yang puas dengan usulan lain karena mereka belum memenuhi kasus penggunaan yang ingin mereka lihat.

Selain dari para pengusul, tidak ada yang percaya bahwa proposal mana pun cukup komprehensif untuk dianggap langkah berikutnya yang wajar.

Ini adalah logika di balik "Pemulihan Skrip Hebat." Dengan memperjuangkan dan menganalisis restorasi komprehensif dari skrip, sebagaimana yang awalnya dirancang oleh Satoshi Nakamoto, kita sebenarnya dapat mencoba untuk menjelajahi seluruh ruang fungsional yang kita butuhkan, daripada memperdebatkan dan bertengkar tentang fitur kecil mana yang cukup baik untuk saat ini.

OPCODES (Kode Operasi)

• OP_CAT: Dapatkan dua data dari tumpukan dan tambahkan untuk membentuk satu data.
• OP_SUBSTR: Menerima parameter panjang (dalam byte), mendapatkan potongan data dari tumpukan, menghapus byte dari panjang tersebut dan meletakkannya kembali di tumpukan.
• OP_LEFT dan OP_RIGHT: Menerima parameter panjang, mengambil potongan data dari tumpukan dan menghapus byte dengan panjang tertentu dari salah satu sisi atau sisi lainnya.
• OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_UPSHIFT dan OP_DOWNSHIFT: Terima elemen data dan lakukan operasi bit yang sesuai pada elemen tersebut.
• OP_2MUL, OP_2DIV, OP_MUL, OP_DIV, dan OP_MOD: Operator matematika untuk perkalian, pembagian, dan operasi modulo (mengembalikan sisa dari pembagian).

Selain opcode yang tercantum di atas untuk dipulihkan, Rusty Russell mengusulkan tiga opcode tambahan yang dirancang untuk menyederhanakan kombinasi opcode yang berbeda:

OP_CTV (atau opcode TXHASH/equivalent): Memungkinkan penegakan halus dari bagian-bagian tertentu dari transaksi, meminta bagian-bagian tersebut untuk tepat konsisten dengan konten yang telah ditentukan sebelumnya.

CSFS: Memungkinkan verifikasi tanda tangan, bukan hanya seluruh transaksi, sehingga bagian-bagian tertentu dari skrip atau data yang digunakan harus ditandatangani sebelum dapat dieksekusi.

OP_TWEAKVERIFY: Validasi operasi berbasis Schnorr, melibatkan kunci publik, seperti menambahkan atau mengurangi kunci publik individu dari kunci publik yang teragregasi. Ini dapat digunakan untuk memastikan bahwa ketika satu pihak menghabiskan uang dari output transaksi yang tidak terpakai bersama (UTXO), dana dari semua pihak lain dikirim ke kunci publik agregat yang memungkinkan pengeluaran secara kooperatif tanpa memerlukan tanda tangan dari pihak yang meninggalkan UTXO bersama.

Mengapa Kita Melakukannya?

Jaringan Layer2 pada dasarnya merupakan perluasan dari lapisan dasar Bitcoin, dan mereka terbatas oleh fungsionalitas lapisan dasar. Sebelum Jaringan Lightning dapat diimplementasikan, diperlukan tiga soft fork terpisah: CHECKLOCKTIMEVERIFY (CLTV), CHECKSEQUENCEVERIFY (CSV), dan Segregated Witness (SegWit).

Tanpa lapisan dasar yang lebih fleksibel, tidak mungkin untuk membangun jaringan Layer2 yang lebih fleksibel. Satu-satunya pintas adalah mempercayai pihak ketiga, yang sangat langsung, tetapi saya harap kita semua bercita-cita untuk menghilangkan kepercayaan pada pihak ketiga sebanyak mungkin dari setiap aspek berinteraksi dengan skalabilitas Bitcoin.

Kita perlu dapat melakukan hal-hal yang saat ini tidak mungkin dilakukan, seperti menggabungkan dua orang atau lebih ke dalam satu output transaksi yang tidak terpakai (UTXO) dengan aman dan bisa dieksekusi tanpa kepercayaan pada lapisan dasar. Fleksibilitas skrip Bitcoin saat ini tidak mencukupi. Pada tingkat paling dasar, kita memerlukan kontrak, dan kita membutuhkan skrip untuk benar-benar menegakkan detail-detail lebih lanjut tentang mengeksekusi transaksi untuk memastikan bahwa pengguna yang keluar dari UTXO sendiri dengan aman tidak menempatkan dana pengguna lain dalam risiko.

Dari perspektif yang lebih tinggi, ini adalah fungsionalitas yang kita butuhkan:

Introspeksi: Kita perlu dapat benar-benar memeriksa detail spesifik tentang transaksi pengeluaran itu sendiri di dalam tumpukan, seperti “sebagian uang ini akan mengalir ke kunci publik tertentu dari suatu output.” Ini memungkinkan saya untuk menggunakan cabang Taproot spesifik saya sendiri untuk mengekstrak dana saya secara independen sambil memastikan bahwa saya tidak dapat mengambil dana orang lain. Skrip yang dieksekusi akan memastikan bahwa dana pemilik lain dikirim kembali ke alamat yang terdiri dari kunci publik pengguna lain untuk mencegah kehilangan dana yang disebabkan oleh peserta lain.

Meneruskan Pengangkutan Data: Mengasumsikan kita lebih mengembangkan konsep dari satu UTXO dengan sejumlah besar orang, di mana siapa pun dapat masuk dan keluar dengan bebas. Dalam hal ini, kita perlu cara untuk melacak siapa yang memiliki berapa banyak uang, biasanya menggunakan pohon Merkle dan akar mereka. Ini berarti bahwa ketika seseorang keluar, kita harus memastikan bahwa 'catatan' siapa yang berhak menerima apa sebagai bagian dari perubahan UTXO dari dana orang lain. Ini pada dasarnya merupakan penggunaan khusus dari introspeksi.

Memodifikasi Kunci Publik: Kami perlu memastikan bahwa modifikasi terhadap kunci publik yang teragregasi dapat diverifikasi di dalam stack. Dalam skema output transaksi yang belum dihabiskan (UTXO) yang dibagikan, tujuan kami adalah untuk memfasilitasi kerjasama dan aliran dana yang efisien melalui kunci publik teragregasi yang berisi semua peserta. Ketika seseorang keluar secara sepihak dari UTXO yang dibagikan, kami perlu menghapus kunci publik individu mereka dari kunci publik yang teragregasi. Jika semua kombinasi yang mungkin tidak dihitung sebelumnya, maka satu-satunya pilihan adalah untuk memverifikasi apakah pengurangan kunci publik dari kunci publik yang teragregasi akan menghasilkan kunci publik yang valid yang terdiri dari kunci publik individu yang tersisa.

Memastikan Keamanan: Seperti yang saya sebutkan di atas, alasan menonaktifkan semua opcode ini adalah untuk mengatasi serangan DOS (menyebabkan keruntuhan jaringan dengan mengirimkan sejumlah besar permintaan sampah), yang dapat menyebabkan keruntuhan simpul yang membentuk jaringan. Salah satu cara untuk mengatasi masalah ini adalah dengan membatasi jumlah sumber daya yang dapat digunakan oleh opcode tersebut.

Ketika datang ke verifikasi tanda tangan, bagian paling mahal dari skrip Bitcoin, kami sudah memiliki solusi untuk ini yang disebut anggaran Operasi Tanda Tangan (sigops). Setiap penggunaan opcode pengecekan tanda tangan menghabiskan "anggaran" tertentu, yaitu, jumlah operasi tanda tangan yang diizinkan per blok, menetapkan batas keras pada biaya yang diperlukan untuk memvalidasi blok untuk transaksi kepada pengguna. Taproot mengubah cara kerjanya dengan tidak lagi menggunakan batas blok global tunggal, tetapi memiliki setiap transaksi memiliki batas sigops (operasi tanda tangan) sendiri, sebanding dengan ukuran transaksi. Ini pada dasarnya sama dengan batas global yang sama tetapi membuatnya lebih mudah untuk memahami berapa banyak sigop setiap transaksi yang tersedia.

Perubahan Taproot mengenai batas sigops (operasi tanda tangan) untuk setiap transaksi menawarkan kemungkinan pendekatan umum, yang juga merupakan saran yang diusulkan Rusty Russell mengenai batasan varops. Idenya adalah untuk mengalokasikan biaya untuk setiap opcode yang diaktifkan kembali untuk memperhitungkan skenario terburuk yang dapat dibuat oleh setiap opcode dalam hal biaya komputasi paling mahal selama verifikasi. Dengan demikian, setiap opcode akan memiliki batas "sigops" sendiri, membatasi jumlah sumber daya yang dapat dikonsumsi selama verifikasi. Ini juga akan didasarkan pada ukuran transaksi apa pun yang menggunakan opcode ini, sehingga nyaman untuk inferensi sambil tetap terakumulasi ke batas global implisit dari setiap blok. Ini akan mengatasi serangan DOS (menyebabkan crash jaringan dengan mengirimkan sejumlah besar permintaan sampah), yang juga merupakan alasan Satoshi Nakamoto awalnya menonaktifkan semua opcode ini.

Tenaga Penggerak Ke Depan

Saya percaya banyak dari Anda mungkin berpikir, “Itu adalah perubahan besar.” Saya memahami sudut pandang ini, tetapi saya pikir aspek penting yang perlu dipahami tentang sebuah proposal adalah bahwa kita tidak harus melakukannya sekaligus. Nilai dari proposal ini mungkin tidak selalu terletak pada pengembalian penuh semua fungsionalitas tersebut, tetapi lebih pada kita secara menyeluruh memeriksa berbagai komponen dasar yang luas dan bertanya pada diri kita sendiri fungsi-fungsi apa yang benar-benar kita inginkan.

Ini akan menandai perubahan lengkap dari tiga tahun terakhir berdebat dan mendebat, di mana kita hanya mendebat perubahan kecil dan sempit, perubahan yang hanya mempengaruhi beberapa fungsionalitas tertentu. Ini seperti sebuah lapangan di mana semua orang dapat berkumpul dan bersama-sama merenungkan arah masa depan. Mungkin, pada akhirnya, kita akan mengembalikan semua fungsionalitas ini, atau mungkin kita hanya akan mengaktifkan beberapa, karena konsensus adalah tentang setuju pada fungsionalitas mana yang kita semua percaya perlu diaktifkan.

Terlepas dari hasil akhirnya, ini bisa menjadi perubahan yang berdampak positif pada seluruh dialog tentang arah masa depan kita. Kita sebenarnya dapat memetakan dan memahami situasi dengan baik, daripada meraba-raba saat membahas langkah berikutnya di jalan yang samar.

Ini bukan satu-satunya cara yang harus kita ambil, tetapi saya percaya ini memberikan kesempatan terbaik bagi kita untuk memutuskan jalan mana yang harus diambil. Sudah waktunya untuk mulai bekerja bersama lagi dengan cara yang praktis dan efektif.

Pernyataan:

1. Artikel ini awalnya berjudul 'The Great Script Recovery: The Way Forward for Bitcoin' direproduksi dari [Blok unicorn]. Semua hak cipta milik penulis asli [SHINOBI]. Jika Anda memiliki keberatan terhadap tayangan ulang, harap hubungi Gate Belajartim, tim akan menanganinya secepat mungkin.

2. Penafian: Pandangan dan pendapat yang terdapat dalam artikel ini hanya mewakili pandangan pribadi 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.