Bitcoin awalnya dirancang dengan bahasa scripting yang sepenuhnya disempurnakan, dimaksudkan untuk mencakup dan dukungan kasus penggunaan aman potensial yang dapat dibuat oleh pengguna di masa mendatang. Seperti yang Satoshi sendiri katakan sebelum dia menghilang:

"Sifat Bitcoin sedemikian rupa sehingga setelah versi 0.1 dirilis, desain inti ditetapkan untuk sisa masa pakainya. Karena itu, saya ingin merancangnya untuk dukungan setiap jenis transaksi yang mungkin dapat saya pikirkan. Masalahnya adalah, setiap hal memerlukan kode dukungan khusus dan bidang data apakah itu digunakan atau tidak, dan hanya mencakup satu kasus khusus pada satu waktu. Itu akan menjadi ledakan kasus-kasus khusus. Solusinya adalah script, yang menggeneralisasi masalah sehingga pihak yang bertransaksi dapat menggambarkan transaksi mereka sebagai predikat yang dievaluasi oleh jaringan node." - Satoshi, 17 Juni 2010.

Seluruh tujuannya adalah untuk memberi pengguna bahasa yang cukup umum sehingga mereka dapat menyusun jenis transaksi mereka sendiri sesuai keinginan mereka. Yaitu Beri pengguna ruang untuk merancang dan bereksperimen dengan bagaimana mereka memprogram uang mereka sendiri.

Sebelum dia menghilang, Satoshi merobek 15 opcode ini, menonaktifkannya seluruhnya, dan menambahkan batas keras seberapa besar sepotong data dapat dimanipulasi pada tumpukan mesin scripting (520 byte). Ini dilakukan karena dia terus terang mengacaukan, dan membiarkan sejumlah besar cara skrip rumit dapat digunakan untuk penolakan layanan menyerang seluruh jaringan, menciptakan besar dan mahal untuk memvalidasi transaksi yang akan merusak node.

Opcode ini tidak dihapus karena Satoshi pikir fungsinya berbahaya, atau orang seharusnya tidak dapat membangun hal-hal yang mereka bisa dengan mereka, tetapi semata-mata (setidaknya tampaknya) karena risiko terhadap jaringan pada umumnya digunakan tanpa kendala sumber daya untuk membatasi biaya validasi kasus terburuk yang dapat mereka kenakan pada jaringan.

Setiap peningkatan ke Bitcoin sejak saat itu pada akhirnya telah merampingkan fungsionalitas yang tersisa, memperbaiki kekurangan lain yang kurang serius yang Satoshi tinggalkan bagi kami, dan memperluas fungsionalitas subset skrip yang tersisa bagi kami.

THE GREAT SCRIPT RESTORATION

Pada Bitcoin++ di Austin pada awal Mei, pengembang Core Lightning Rusty Russell membuat proposal yang cukup radikal selama presentasi pertama konferensi. Dia pada dasarnya mengajukan gagasan menghidupkan kembali sebagian besar opcode yang Satoshi nonaktifkan pada tahun 2010 sebelum dia menghilang.

Selama beberapa tahun terakhir sejak Taproot diaktifkan pada tahun 2021, ruang pengembangan terus terang agak tanpa tujuan. Kita semua tahu bahwa Bitcoin tidak cukup terukur untuk benar-benar melayani sebagian besar populasi dunia dengan cara yang berdaulat sendiri, dan kemungkinan bahkan tidak dengan cara kepercayaan yang diminimalkan atau kustodian yang dapat melampaui kustodian dan penyedia layanan yang sangat besar yang tidak mampu benar-benar melarikan diri dari lengan long pemerintah.

Siapa pun yang memahami Bitcoin pada tingkat teknologi memahami hal ini, ini bukan masalah perdebatan. Apa yang menjadi bahan perdebatan, dan yang sangat kontroversial, adalah bagaimana cara mengatasi kekurangan ini. Sejak Taproot, semua orang telah mengajukan proposal yang sangat sempit yang dimaksudkan untuk mengatasi hanya kasus penggunaan yang sangat khusus yang dapat diaktifkan.

ANYPREVOUT (APO), sebuah proposal untuk memungkinkan tanda tangan dapat digunakan kembali pada transaksi yang berbeda long skrip dan jumlah inputnya sama dirancang khusus untuk mengoptimalkan Lightning dan versi multipartainya. CHECKTEMPLATEVERIFY (CTV), proposal untuk menegakkan koin hanya dapat dibelanjakan oleh transaksi yang sama persis dengan transaksi yang telah ditentukan, dirancang khusus untuk memperluas fungsionalitas rantai transaksi yang telah ditandatangani sebelumnya dengan membuatnya benar-benar tidak dapat dipercaya. OP_VAULT dirancang khusus untuk mengaktifkan "periode batas waktu" untuk skema penyimpanan dingin, sehingga pengguna dapat "membatalkan" penarikan dari penyimpanan dingin dengan mengirimkannya ke pengaturan multisig yang lebih dingin jika kunci mereka disusupi.

Ada banyak proposal lain, tapi saya pikir Anda mengerti maksudnya. Alih-alih mencoba untuk secara komprehensif mengatasi ekspresivitas dan programabilitas yang diperlukan untuk skala Bitcoin secara mendasar, masing-masing proposal selama beberapa tahun terakhir dirancang untuk memberikan peningkatan skalabilitas kecil atau meningkatkan fungsionalitas sempit tunggal yang dianggap diinginkan. Ini saya pikir adalah sumber mengapa tidak satu pun dari percakapan ini ke mana-mana. Tidak ada yang senang dengan proposal lain karena tidak memenuhi kasus penggunaan yang ingin mereka lihat dibangun.

Tidak ada yang cukup komprehensif bagi siapa pun untuk berpikir, di luar pencetus proposal, bahwa itu adalah langkah selanjutnya yang masuk akal.

Itulah logika di balik Great Script Restoration. Dengan mendorong dan menganalisis pemulihan skrip yang komprehensif seperti Satoshi awalnya merancangnya, kita benar-benar dapat mencoba menjelajahi seluruh ruang fungsi apa yang kita butuhkan, daripada bertengkar dan bertengkar tentang ekstensi fungsi kecil apa yang cukup baik untuk saat ini.

OPCODE

• OP_CAT: Mengambil dua bagian data pada tumpukan dan menambahkannya bersama-sama untuk membentuk satu.
• OP_SUBSTR: Mengambil argumen panjang dalam byte, dan mengambil sepotong data dari tumpukan menghapus byte sebanyak itu dan mengembalikannya.
• OP_LEFT &; OP_RIGHT: Mengambil argumen panjang dan menghapus byte sebanyak itu dari satu sisi atau sisi lain dari sepotong data pada tumpukan.
• OP_INVERT & OP_AND & OP_OR & OP_XOR & OP_UPSHIFT & OP_DOWNSHIFT: Mengambil elemen data dari tumpukan dan melakukan operasi bit yang sesuai di atasnya.
• OP_2MUL & OP_2DIV & OP_MUL & OP_DIV & OP_MOD: Operator matematika untuk operasi perkalian, pembagian, dan modulo (mengembalikan sisa pembagian).

Yang di atas adalah opcode yang dimaksudkan untuk dipulihkan. Selain itu, Rusty mengusulkan tiga lagi untuk menyederhanakan komposisi opcode yang berbeda.

• OP_CTV (ATAU TXHASH/setara): Sesuatu untuk memungkinkan penegakan granular yang mengharuskan bagian-bagian tertentu dari transaksi persis seperti yang didefinisikan sebelumnya.
• CSFS: Memungkinkan verifikasi tanda tangan terhadap data arbitrer, bukan hanya seluruh transaksi. Ini memungkinkan Anda untuk meminta bagian dari skrip, atau data yang mereka gunakan, untuk masuk pesanan untuk dieksekusi.
• OP_TWEAKVERIFY: Memverifikasi operasi berbasis Schnorr yang melibatkan kunci publik, seperti menambahkan atau mengurangi kunci publik individual dari kunci agregat. Ini dapat digunakan untuk memastikan bahwa jika satu pihak meninggalkan UTXO bersama secara sepihak, dana orang lain dikirim ke kunci publik agregat yang tidak mengharuskan pihak yang pergi untuk masuk pesanan untuk membelanjakan secara kooperatif.

WHY WE WANT TO DO THIS

Layer 2s secara inheren merupakan perpanjangan dari lapisan dasar Bitcoin, mereka pada dasarnya dibatasi dalam hal fungsionalitas oleh fungsionalitas lapisan dasar. Lightning membutuhkan tiga softfork terpisah, CHECKLOCKTIMEVERIFY (CLTV), CHECKSEQUENCEVERIFY (CSV), dan Segregated Witness sebelum memungkinkan untuk benar-benar menerapkannya.

Anda tidak bisa membangun Layer 2 yang lebih fleksibel tanpa lapisan dasar yang lebih fleksibel. Satu-satunya jalan pintas di sekitar yang dipercaya pihak ketiga, murni dan sederhana. Itu adalah sesuatu yang saya harap kita semua bercita-cita untuk menghapus dari setiap aspek berinteraksi dengan Bitcoin pada skala yang mungkin kita bisa.

Ada hal-hal yang perlu kita lakukan yang tidak dapat kita lakukan sekarang pesanan mengemas lebih dari dua orang dengan aman ke dalam satu UTXO dengan cara yang dapat ditegakkan tanpa kepercayaan pada lapisan dasar, skrip Bitcoin tidak cukup fleksibel. Pada tingkat yang paling dasar kita membutuhkan perjanjian, kita membutuhkan kemampuan skrip untuk benar-benar menegakkan detail yang lebih terperinci tentang transaksi yang melaksanakannya untuk memastikan hal-hal seperti pengguna dengan aman keluar dari UTXO sendiri tidak membahayakan dana pengguna lain.

Pada tampilan tinggi ini adalah jenis fungsi yang kita butuhkan:

Introspeksi: Kita harus dapat benar-benar memeriksa detail spesifik tentang transaksi pengeluaran itu sendiri di tumpukan, seperti "jumlah uang ini masuk ke kunci publik ini dalam beberapa output." Itu memungkinkan saya untuk menarik uang saya sendiri menggunakan cabang Taproot tertentu saya sendiri, sambil memastikan bahwa saya tidak dapat mengambil uang orang lain. Skrip yang dijalankan akan ditegakkan dengan konsensus bahwa jumlah yang benar yang dimiliki orang lain dikirim kembali ke alamat yang terdiri dari kunci publik pengguna lain jika saya pergi.

Forward Data Carrying: Katakanlah kita melangkah lebih jauh dari gagasan saluran Lightning dengan lebih dari dua orang di dalamnya, kita membangun satu UTXO dengan sejumlah besar orang di dalamnya di mana siapa pun dapat datang dan pergi sesuka mereka. Entah bagaimana, hampir selalu dengan pohon merkle dan akarnya, kita perlu beberapa cara untuk melacak siapa yang memiliki berapa banyak uang. Itu berarti ketika seseorang pergi, kita harus dapat memastikan bahwa "catatan" tentang siapa yang berhak atas apa yang merupakan bagian dari perubahan UTXO uang orang lain. Ini pada dasarnya adalah penggunaan khusus untuk introspeksi.

Kunci Publik Modifikasi: Kami membutuhkan kemampuan untuk memastikan bahwa modifikasi pada kunci publik agregat dapat diverifikasi pada tumpukan. Tujuan untuk menembak dalam skema berbagi UTXO adalah bahwa ada kunci agregat dengan semua orang yang terlibat memungkinkan pergerakan dana yang kooperatif dan lebih efisien. Setiap kali seseorang meninggalkan UTXO bersama secara sepihak, kita perlu menghapus kunci masing-masing dari kunci agregat. Tanpa melakukan prakomputasi semua kemungkinan kombinasi sebelumnya, satu-satunya pilihan adalah dapat memverifikasi bahwa mengurangi satu kunci dari agregat menciptakan kunci yang valid yang terdiri dari sisa kunci individual.

CARA MEMBUAT INI AMAN: VAROPS

Seperti yang saya katakan di atas, alasan semua opcode ini dinonaktifkan adalah untuk menghilangkan risiko penolakan serangan layanan yang secara harfiah dapat merusak node yang terdiri dari jaringan. Ada cara untuk mengatasi ini, membatasi jumlah sumber daya yang dapat digunakan oleh opcode ini.

Kami sudah memiliki solusi seperti itu dalam hal verifikasi tanda tangan, bagian paling mahal dari memverifikasi skrip Bitcoin. Ini disebut anggaran sigops. Setiap penggunaan opcode pemeriksaan tanda tangan mengkonsumsi 'anggaran' tertentu dari operasi tanda tangan yang diizinkan per blok. Ini menempatkan batas keras pada biaya yang dapat dikenakan transaksi pada pengguna untuk memverifikasi blok individu.

Taproot menggeser cara kerjanya, alih-alih menggunakan batas blok global tunggal, setiap transaksi memiliki batas sigops sendiri yang sebanding dengan ukuran transaksi. Ini bekerja pada dasarnya untuk batas global yang sama, tetapi membuatnya lebih mudah untuk bernalar dalam hal berapa banyak sigop transaksi individu yang tersedia.

Pergeseran dalam cara Taproot menangani batas sigops relatif terhadap setiap transaksi menawarkan cara untuk menggeneralisasi ini, yang diusulkan Rusty dengan batas varops. Idenya adalah untuk menetapkan biaya untuk masing-masing opcode yang diaktifkan kembali untuk akun kasus terburuk, yaitu biaya komputasi paling mahal untuk divalidasi, yang dapat dibuat oleh setiap opcode. Dengan ini, setiap opcode ini akan memiliki batas "sigops" sendiri untuk menahan berapa banyak sumber daya yang dapat dikonsumsi dalam verifikasi. Ini juga akan didasarkan pada ukuran transaksi apa pun yang menggunakannya, jadi pertahankan kemudahan penalaran tentang hal itu, sambil tetap menambahkan hingga batas global implisit per blok.

Ini akan menyelesaikan penolakan risiko layanan yang menyebabkan Satoshi menonaktifkan semua opcode ini sejak awal.

MOMENTUM MAJU

Saya yakin banyak dari Anda berpikir "itu adalah perubahan yang terlalu besar." Saya dapat berempati dengan itu, tetapi saya pikir aspek penting dari proyek ini sebagai proposal untuk dipahami adalah kita tidak harus melakukan semuanya. Nilai dari proposal ini tidak selalu benar-benar mengubah semua ini kembali secara keseluruhan, itu adalah fakta bahwa kita benar-benar akan secara komprehensif melihat serangkaian besar primitif dan bertanya pada diri sendiri apa yang sebenarnya kita inginkan dari ini dalam hal fungsionalitas.

Ini akan menjadi wajah lengkap dari tiga tahun terakhir pertengkaran dan perdebatan tentang perubahan sempit kecil yang hanya membantu fungsi tertentu. Ini adalah tenda yang bisa menyatukan semua orang di bawah satu atap untuk benar-benar menilai secara komprehensif ke mana harus pergi dari sini. Mungkin kita akhirnya menghidupkan kembali semua ini, mungkin kita akhirnya hanya mengaktifkan beberapa hal karena konsensusnya adalah hanya itu yang kita butuhkan untuk mengaktifkan fungsionalitas yang disetujui semua orang yang kita butuhkan.

Terlepas dari apa hasil akhirnya sebenarnya, itu bisa menjadi perubahan produktif dalam seluruh percakapan di sekitar tempat kita pergi dari sini. Kita benar-benar dapat memetakan dan mendapatkan tata letak tanah yang komprehensif, daripada kikuk berdebat tentang jalan keruh dan setengah terang apa yang harus dilalui selanjutnya.

Ini tidak berarti harus menjadi jalan ke depan yang kita ambil, tapi saya pikir ini adalah kesempatan terbaik kita untuk memutuskan mana yang kita lakukan. Sudah waktunya untuk mulai benar-benar bekerja sama dengan cara yang produktif lagi.

Penafian:

1. Artikel ini dicetak ulang dari [bitcoinmagazine], Semua hak cipta adalah milik penulis asli [SHINOBI]. Jika ada keberatan dengan cetak ulang ini, silakan hubungi tim Gate Learn, dan mereka akan segera menanganinya.
2. Penafian Kewajiban: Pandangan dan pendapat yang diungkapkan dalam artikel ini semata-mata milik penulis dan bukan merupakan saran investasi.
3. Penerjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.