Opcode

Anna ingin membayar Peter. Dompet menyiapkan transaksi dan tanda tangan yang diperlukan, lalu node memeriksa apakah ia berhak membelanjakan koin yang dipilih. Dompet adalah aplikasi atau perangkat untuk menerima dan mengirim bitcoin. Node adalah perangkat lunak yang memeriksa transaksi dan blok serta berkomunikasi dengan peserta jaringan lainnya. Bitcoin Script adalah bahasa untuk sebagian pemeriksaan itu. Opcode merupakan satu langkah, seperti memeriksa tanda tangan. Anna tidak menulis instruksi secara manual untuk pembayaran biasa. Namun, node tidak bisa percaya begitu saja pada nama pemilik atau label “ditandatangani”: syaratnya harus diperiksa. Skrip yang sah hanyalah bagian dari validasi seluruh transaksi. [1] [4]

Tampilan yang mudah dibaca dapat menunjukkan OP_DUP atau OP_CHECKSIG. Itu nama instruksi untuk manusia; dalam skrip, instruksi diwakili kode satu byte. Byte adalah satuan umum untuk ukuran data. Bagian lain berisi data, misalnya kunci publik. Kunci publik digunakan untuk memeriksa tanda tangan dan tidak perlu dirahasiakan. Instruksi keluarga OP_PUSHDATA menentukan berapa byte berikutnya yang dimasukkan sebagai data. Byte di dalam data tersebut tidak dijalankan lagi sebagai instruksi. Bayangkan perbedaan antara “tambahkan garam” dalam resep dan bahan yang dimasukkan ke mangkuk. [1] [2]

Bayangkan tumpukan catatan yang diambil dari paling atas. Begitulah stack kerja dasar skrip. OP_DUP menyalin butir teratas; OP_DROP menghapusnya. Menjalankan OP_DUP lalu OP_DROP pada stack yang tidak kosong mengembalikan isi semula. Anda tidak menggandakan koin, hanya data kerja. Evaluasi bisa gagal jika butir yang dibutuhkan tidak ada. Urutan dan pengodean yang tepat juga penting. [1]

OP_EQUAL mengambil dua butir teratas, membandingkan byte-nya, lalu menggantinya dengan hasil perbandingan. OP_EQUALVERIFY langsung gagal jika berbeda; jika sama, ia melanjutkan tanpa meninggalkan hasil itu pada stack. Keduanya tidak memeriksa tanda tangan dengan sendirinya. Siapa pun dapat menyediakan dua salinan identik dari kunci publik. Pemeriksaan tanda tangan yang sesuai diperlukan untuk membuktikan bahwa seseorang mampu menandatangani pesan yang diwajibkan. [1] [4]

OP_CHECKSIG memeriksa tanda tangan menggunakan kunci publik dan pesan yang disusun dari transaksi, tanpa mengungkap kunci privat. Kunci privat adalah nilai angka rahasia yang digunakan untuk membuat tanda tangan tersebut. Pengaturan sighash menentukan bagian transaksi yang dicakup; tidak semua mode menandatangani semuanya. Skrip lama dan SegWit versi 0 menggunakan ECDSA, sebuah algoritma tanda tangan. Tapscript, aturan skrip Taproot, memakai algoritma lain bernama Schnorr untuk kunci biasa sepanjang 32 byte. Nama instruksi saja tidak cukup tanpa konteks ini. [1] [3]

Syarat dapat mengizinkan pembelanjaan normal atau jalur pemulihan alternatif. OP_IF dan OP_ELSE memilih cabang berdasarkan nilai pada stack; OP_ENDIF menutup bagian bersyarat. Bitcoin Script tidak memiliki perulangan pemrograman umum yang bisa diulang sembarangan. Namun, bukan berarti semua isi cabang yang tidak dijalankan dapat diabaikan. Beberapa instruksi diperiksa saat skrip dibaca; jenis instruksi dan versi aturannya penting. [1] [3]

CLTV, instruksi OP_CHECKLOCKTIMEVERIFY, dapat menetapkan batas absolut, misalnya ketinggian blok tertentu, yaitu posisi blok dalam rantai. CSV, OP_CHECKSEQUENCEVERIFY, bersama aturan usia transaksi menetapkan jeda relatif sejak konfirmasi output yang dibelanjakan. Output adalah jumlah yang diterima sebelumnya beserta syarat pembelanjaannya. Instruksi ini memeriksa kolom transaksi; tidak menyalakan penghitung waktu, mengirim uang, atau menggantikan tanda tangan. Setiap penerapan harus menggabungkan penguncian waktu yang tepat dengan syarat lainnya. [7] [8] [9]

Sebelum membaca contoh teknis, pastikan apakah contoh itu memakai skrip lama, SegWit, atau Tapscript. Tapscript menambahkan OP_CHECKSIGADD untuk menggabungkan pemeriksaan tanda tangan. Sebaliknya, OP_CHECKMULTISIG gagal saat dijalankan; aturan ini mengabaikannya pada cabang yang tidak dijalankan. Bukan namanya yang bertentangan, melainkan lingkungan verifikasinya berbeda. Daftar opcode bukan kumpulan komponen universal yang bisa dipindahkan begitu saja antarformat. [1] [3] [6]

BIP 342 mencadangkan keluarga OP_SUCCESSx untuk perluasan Tapscript mendatang. Setelah pemeriksaan sebelumnya lolos, menemukan instruksi ini saat dekode melewati pemeriksaan skrip berikutnya dengan hasil berhasil, termasuk jika berada pada cabang yang tidak dijalankan. Byte yang kebetulan sama di dalam data yang dimasukkan tidak dihitung. Ini ruang untuk perubahan aturan, bukan perlindungan baru yang sudah aktif. Syarat yang mengandalkan makna masa depan yang belum ditentukan mungkin tidak melindungi dana seperti harapan pembuatnya. [1] [3]

Full Node memeriksa aturan keabsahan secara mandiri, tetapi dapat menerapkan aturan lebih ketat untuk menerima dan membagikan transaksi belum terkonfirmasi. Bitcoin Core v29.0, misalnya, secara bawaan menolak meneruskan transaksi yang memakai instruksi OP_SUCCESSx dalam Tapscript, meskipun konsensus mungkin mengizinkannya dalam blok. Saat membaca contoh, tentukan versi, data awal, cakupan tanda tangan, dan penyebab kegagalan. Sintaks yang terbaca bukan bukti dompet aman; dalam penggunaan biasa, Anda menyerahkan pekerjaan ini kepada perangkat lunak yang telah ditinjau. [1] [5]