PENULIS ASLI: SHINOBI

Kompilasi asli: Blok unicorn

Terlepas dari ruang lingkup proposal, apa alasan mengapa "pemulihan skrip hebat" Rusty Russell bisa menjadi jalan ke depan untuk pengembangan Bitcoin?

Blok unicorn Catatan: Rusty Russell adalah pengembang aktif di komunitas Bitcoin dan sangat dihormati di komunitas. Dia telah bekerja secara ekstensif pada pengembangan kernel Linux dan telah terlibat dalam banyak proyek pengembangan inti long Bitcoin.

Bitcoin awalnya dirancang untuk memiliki bahasa scripting lengkap yang dirancang untuk mencakup dan dukungan setiap kasus penggunaan keamanan potensial yang mungkin muncul dengan pengguna di masa depan. Seperti yang Satoshi Nakamoto katakan sebelum dia menghilang:

"Inti dari Bitcoin adalah bahwa setelah versi 0.1 dirilis, desain inti ditentukan untuk sisa siklus hidup. Oleh karena itu, saya ingin merancangnya untuk dukungan setiap jenis perdagangan yang mungkin dapat saya pikirkan. Masalahnya adalah semuanya membutuhkan kode dukungan khusus dan bidang data, baik digunakan atau tidak, yang mengarah ke kasus khusus terpanjang. Solusinya adalah skrip yang menggeneralisasi masalah sehingga kedua belah pihak dapat menggambarkan transaksi mereka dengan kondisi spesifik yang dievaluasi atau divalidasi oleh jaringan Node berdasarkan kondisi tersebut. " - Satoshi Nakamoto, 17 Juni 2010

Seluruh tujuannya adalah untuk memberi pengguna bahasa yang cukup umum bagi mereka untuk mengatur jenis transaksi mereka sesuai keinginan. Artinya, celana pendek bagi pengguna untuk merancang dan bereksperimen dengan cara menulis koin mereka sendiri.

Sebelum dia menghilang, Satoshi Nakamoto menghapus 15 Kode Operasi ini, menonaktifkannya seluruhnya, dan menambahkan batas keras pada tumpukan mesin scripting yang membatasi ukuran blok data yang dapat dimanipulasi (520 byte). Ini karena dia benar-benar mengacaukan, meninggalkan banyak cara agar skrip kompleks dapat digunakan untuk melakukan serangan DOS di seluruh jaringan (mengirim sejumlah besar permintaan spam, menyebabkan jaringan turun), menciptakan transaksi besar dan mahal yang akan menabrak Node.

Kode Operasi ini tidak dihapus karena Satoshi Nakamoto pikir fitur-fiturnya berbahaya atau bahwa orang tidak boleh menggunakannya untuk membangun sesuatu yang dapat dicapai, tetapi hanya (setidaknya di permukaan) karena risiko yang mereka timbulkan ke seluruh jaringan tanpa kendala sumber daya, seperti biaya validasi terburuk yang dapat mereka kenakan pada jaringan tanpa batasan.

Sejak itu, setiap peningkatan Bitcoin akhirnya menjadi optimalisasi fungsional dari fitur yang tersisa, memperbaiki kekurangan lain yang kurang serius yang Satoshi Nakamoto tinggalkan bagi kami, dan memperluas fungsionalitas subset skrip kami yang tersisa.

Pemulihan skrip yang bagus

Pada konferensi Austin Bitcoin++ pada awal Mei, pengembang Jaringan Lighting inti Rusty Russell membuat proposal yang sangat radikal dalam pidato pertamanya di konferensi, di mana ia pada dasarnya datang dengan gagasan untuk mengaktifkan kembali Kode Operasi kerinduan besar yang telah dinonaktifkan Satoshi Nakamoto sebelum menghilang pada tahun 2010.

Pada tahun-tahun sejak aktivasi Taproot pada tahun 2021 (Taproot adalah peningkatan besar ke Bitcoin yang bertujuan untuk meningkatkan privasi, keamanan, dan skalabilitas), ruang pengembangan sebenarnya agak tanpa tujuan. Kita semua tahu bahwa Bitcoin tidak cukup terukur untuk benar-benar menyediakan layanan berdaulat sendiri untuk ukuran populasi dunia yang cukup besar, dan bahkan mungkin tidak dapat memberikan skalabilitas kepada penyedia layanan yang dapat melampaui kustodian dan penyedia layanan yang sangat besar, dan tidak dapat benar-benar membebaskan diri dari kendala long lengan pemerintah, dengan cara yang meminimalkan kepercayaan atau hak asuh.

Artikel ini menunjuk ke tingkat teknis Bitcoin, yang bukan masalah untuk diperdebatkan. Pertanyaan yang patut diperdebatkan adalah bagaimana memperbaiki kekurangan ini, yang merupakan topik yang sangat kontroversial. Sejak Taproot diperkenalkan, semua orang telah mengajukan proposal yang sangat sempit yang bertujuan untuk memecahkan masalah yang hanya dapat dicapai untuk kasus penggunaan tertentu.

Misalnya, ANYPREVOUT (APO) adalah proposal yang memungkinkan tanda tangan digunakan kembali dalam transaksi yang berbeda, long skrip dan jumlah yang dimasukkan sama, dan proposal ini dirancang khusus untuk mengoptimalkan Jaringan Lighting dan versi lebih lama-nya. CHECKTEMPLATEVERIFY (CTV) adalah proposal yang mengharuskan koin keras hanya dibelanjakan oleh transaksi yang sama persis dengan transaksi yang telah ditentukan sebelumnya, dan proposal ini dirancang untuk memperluas fungsionalitas rantai transaksi yang telah ditandatangani sebelumnya dengan membuatnya benar-benar tidak dapat dipercaya. OP_VAULT dirancang khusus untuk mengatur "batas waktu" untuk solusi penyimpanan dingin, sehingga pengguna dapat "mengambil" dari penyimpanan dingin dengan mengirimkannya ke pengaturan long yang lebih dingin untuk mencegah Kunci Rahasia mereka disusupi.

Ada proposal lain terpanjang, tapi saya pikir Anda sudah mendapatkan intinya. Selama beberapa tahun terakhir, setiap proposal telah dirancang untuk sedikit meningkatkan skalabilitas atau meningkatkan satu fitur kecil, karena ini dianggap diinginkan. Itulah akar penyebab mengapa diskusi ini tidak membuat kemajuan. Tidak ada yang senang dengan proposal lain karena mereka tidak memenuhi kasus penggunaan yang ingin mereka lihat.

Tidak ada orang lain selain sponsor proposal yang percaya bahwa proposal apa pun cukup komprehensif untuk dianggap sebagai langkah berikutnya yang masuk akal.

Ini adalah logika di balik "Great Script Recovery". Dengan mendorong dan menganalisis pemulihan penuh skrip, seperti yang awalnya dirancang Satoshi Nakamoto, kita benar-benar dapat mencoba menjelajahi seluruh celana pendek fitur yang kita butuhkan, daripada berdebat dan bertengkar tentang ekstensi fitur kecil mana yang cukup baik saat ini.

OPCODE (Kode Operasi)

• OP_CAT: Mengambil dua potong data dari tumpukan dan menambahkannya bersama-sama untuk membentuk satu data.
• OP_SUBSTR: Terima parameter panjang (dalam byte), dapatkan sepotong data dari tumpukan, hapus byte dengan panjang itu dan letakkan kembali di tumpukan.
• OP_LEFT dan OP_RIGHT: Menerima parameter panjang yang mengambil sepotong data dari tumpukan dan menghapus byte dari panjang yang ditentukan dari satu sisi atau yang lain.
• OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_UPSHIFT, dan OP_DOWNSHIFT: Menerima elemen data dan melakukan operasi bit yang sesuai di atasnya.
• OP_ 2 MUL, OP_2D IV, OP_MUL, OP_DIV, dan OP_MOD: Operator matematika untuk operasi perkalian, pembagian, dan modulo (mengembalikan sisa divisi).

Selain list Kode Operasi di atas untuk dipulihkan, Rusty Russell mengusulkan tiga Kode Operasi lagi yang dirancang untuk menyederhanakan kombinasi Kode Operasi yang berbeda:

OP_CTV (atau TXHASH/ setara Kode Operasi): Memungkinkan penegakan halus bagian-bagian tertentu dari transaksi yang harus persis seperti yang telah ditentukan sebelumnya.

CSFS: Memungkinkan tanda tangan untuk diverifikasi, tidak hanya untuk seluruh transaksi, yang mengharuskan bagian-bagian tertentu dari skrip atau data yang digunakan harus masuk pesanan untuk dieksekusi.

OP_TWEAKVERIFY: Memvalidasi operasi berbasis Schnorr yang melibatkan Kunci Publik, seperti menambah atau mengurangi Kunci Publik individu dari Kunci Publik agregat. Ini dapat digunakan untuk memastikan bahwa ketika satu pihak secara sepihak meninggalkan output transaksi bersama yang tidak digunakan (UTXO), semua dana peserta lain dikirim ke kunci publik agregat yang tidak memerlukan penandatanganan pihak yang berangkat untuk melakukan pengeluaran kooperatif.

Mengapa kami melakukan ini

Layer 2 jaringan pada dasarnya adalah ekstensi dari lapisan dasar Bitcoin, dan mereka secara fungsional dibatasi oleh fungsi lapisan dasar. Jaringan Lighting memerlukan tiga Soft Fork terpisah sebelum benar-benar dapat diimplementasikan: CHECKLOCKTIMEVERIFY (CLTV), checksequenceverify (csv), dan SegWit (Segregated Witness).

Tanpa lapisan dasar yang lebih fleksibel, Anda tidak dapat membangun jaringan lapisan 2 yang lebih fleksibel. Satu-satunya jalan pintas adalah mempercayai pihak ketiga, yang sangat sederhana dan mudah, dan saya harap kita semua bercita-cita untuk menghapus pihak ketiga tepercaya dari setiap aspek interaksi dengan Bitcoin dalam skala sebanyak mungkin.

Kita harus dapat melakukan sesuatu yang saat ini tidak mungkin di pesanan untuk menggabungkan lebih dari dua orang dengan aman menjadi satu output transaksi yang tidak digunakan (UTXO) dan dapat melakukan tanpa kepercayaan pada lapisan dasar. Fleksibilitas Bitcoin Script saat ini tidak cukup. Pada tingkat yang paling dasar, kami membutuhkan kontrak, dan kami membutuhkan skrip yang benar-benar dapat menegakkan detail yang lebih baik tentang pelaksanaan transaksi untuk memastikan bahwa pengguna dengan aman keluar dari UTXO mereka sendiri tidak membahayakan dana pengguna lain.

Pada perspektif yang lebih tinggi, inilah yang kita butuhkan:

Introspeksi: Kita harus dapat benar-benar memeriksa rincian spesifik pada tumpukan tentang transaksi pengeluaran itu sendiri, seperti "jumlah uang ini akan masuk ke kunci publik dari beberapa output". Ini memungkinkan saya untuk menarik dana saya sendiri menggunakan cabang Taproot khusus saya sendiri, sambil memastikan bahwa saya tidak dapat menarik dana orang lain. Skrip yang dieksekusi akan memastikan bahwa dana pemilik lain dikirim kembali ke Alamat yang terdiri dari Kunci Publik pengguna lain, jika peserta lain menyebabkan hilangnya dana.

Forward Data Carrying: Katakanlah kita mengambil konsep satu UTXO, misalnya, dengan sejumlah besar orang, bahwa siapa pun dapat datang dan pergi sesuka mereka. Dalam hal ini, kita perlu cara untuk melacak siapa yang memiliki uang terpanjang atau kurang, biasanya menggunakan Merkle Tree dan akarnya. Ini berarti bahwa ketika seseorang pergi, kita harus memastikan untuk "mencatat" siapa yang berhak atas apa sebagai bagian dari perubahan yang UTXO untuk dana orang lain. Ini pada dasarnya adalah penggunaan introspeksi khusus.

Kunci Publik Modifikasi: Kita perlu memastikan bahwa modifikasi pada Kunci Publik agregat dapat diverifikasi pada tumpukan. Dalam skema pembagian Output Transaksi (UTXO) yang Tidak Digunakan, tujuan kami adalah untuk memfasilitasi kerja sama dan aliran dana yang efisien melalui Kunci Publik agregat yang mencakup semua peserta. Ketika seseorang secara sepihak meninggalkan UTXO bersama, kami perlu menghapus Kunci Publik pribadinya dari Kunci Publik agregat. Jika semua kemungkinan kombinasi tidak dihitung sebelumnya, satu-satunya pilihan adalah memverifikasi bahwa mengurangi satu kunci publik dari kunci publik agregat akan menghasilkan kunci publik yang valid yang terdiri dari kunci publik individu yang tersisa.

Cara aman: VAROPS Seperti yang saya katakan di atas, alasan untuk menonaktifkan semua Kode Operasi ini adalah untuk mengatasi serangan DOS (yang menyebabkan jaringan mogok dengan mengirimkan sejumlah besar permintaan spam), yang dapat menyebabkan Node yang membentuk jaringan mogok. Salah satu cara untuk mengatasi masalah ini adalah dengan membatasi jumlah sumber daya yang dapat digunakan oleh salah satu Kode Operasi ini.

Ketika datang ke verifikasi tanda tangan, bagian paling mahal dari skrip Bitcoin, kami sudah memiliki solusi seperti itu, yang disebut anggaran operasi tanda tangan (sigops). Setiap penggunaan cek tanda tangan Kode Operasi menghabiskan "anggaran" tertentu, yaitu jumlah operasi tanda tangan yang diizinkan per blok, yang menetapkan batas keras pada biaya yang dapat dihasilkan transaksi untuk memvalidasi blok.

Taproot mengubah cara kerja ini, tidak ada lebih lama menggunakan batas Blok global tunggal, tetapi sebaliknya setiap transaksi memiliki batas sigops (operasi tanda tangan) sendiri, sebanding dengan ukuran transaksi. Ini pada dasarnya sama dengan batas global yang sama, tetapi lebih mudah untuk memahami bahwa setiap transaksi memiliki long lebih sedikit sigop yang tersedia.

Perubahan batas sigops (operasi tanda tangan) Taproot untuk memproses setiap transaksi membuka kemungkinan pendekatan generalisasi, yang disarankan Rusty Russell dalam hal batas varops. Idenya adalah untuk menetapkan biaya untuk setiap Kode Operasi yang diaktifkan kembali untuk akun skenario terburuk yang dapat dibuat oleh setiap Kode Operasi, yaitu, biaya komputasi paling mahal yang dikeluarkan pada saat validasi. Dengan cara ini, setiap Kode Operasi akan memiliki batas "sigops" sendiri, membatasi jumlah sumber daya yang dapat dikonsumsi selama proses validasi. Ini juga akan didasarkan pada ukuran transaksi apa pun yang menggunakan Kode Operasi ini, sehingga inferensi dapat difasilitasi sambil tetap terakumulasi ke batas global implisit per Blok.

Ini akan menyelesaikan serangan DOS (dengan mengirimkan banyak permintaan spam, menyebabkan jaringan mogok) karena transaksi spam ini, dan apa yang menyebabkan Satoshi Nakamoto awalnya menonaktifkan semua Kode Operasi tersebut.

Momentum untuk bergerak maju

Saya yakin terlama dari Anda akan berpikir, "Ini terlalu banyak perubahan." Saya bisa mengerti itu, tapi saya pikir aspek penting untuk dipahami sebagai proposal adalah bahwa kita tidak harus melakukan semuanya. Nilai dari proposal ini belum tentu bahwa semua fitur ini sepenuhnya dipulihkan, tetapi bahwa kita akan melihat secara holistik pada rangkaian komponen dasar yang luas dan bertanya pada diri sendiri apa yang sebenarnya kita inginkan dalam hal fungsionalitas.

Ini akan menjadi perubahan total dari tiga tahun terakhir pertengkaran dan perdebatan bahwa kita hanya berdebat tentang perubahan sempit kecil yang hanya memiliki fungsi tertentu. Ini seperti alun-alun di mana semua orang bisa berkumpul dan melihat arah masa depan. Mungkin kita akhirnya akan mengembalikan semua fitur ini, atau mungkin kita akhirnya akan mengaktifkan hanya beberapa dari mereka, karena Konsensus adalah bahwa ini adalah orang-orang yang kita semua setuju perlu dihidupkan.

Terlepas dari hasil akhirnya, ini bisa menjadi perubahan yang berdampak positif pada seluruh percakapan tentang arah masa depan kita. Kita benar-benar dapat memetakan dan mendapatkan gambaran lengkap tentang situasinya, daripada meraba-raba jalan kita untuk memperdebatkan rute keruh mana yang harus diambil selanjutnya.

Ini sama sekali bukan jalan yang harus kita ambil, tapi saya pikir ini adalah kesempatan terbaik bagi kita untuk memutuskan rute mana yang ingin kita ambil. Sudah waktunya untuk mulai bekerja sama lagi dengan cara yang praktis dan produktif.