Blockchain/Tahap IV · Kedalaman protokol/4.1 Script/Pelajaran 2
Skrip standard: P2PKH dan P2SH
Mengunci syiling pada kunci, kemudian pada hash sebarang skrip
BahanAntaramuka peneroka blok (contohnya, Blockstream.info atau mempool.space)Alat pengiraan hash SHA-256 dan RIPEMD-160Jadual rujukan heksadesimalPeneroka blok yang boleh memaparkan heks transaksi mentah
Ingin tahu
- Mengapa Bitcoin mengunci syiling pada hash dan bukannya kunci itu sendiri?
- Bagaimanakah skrip empat baris mengesahkan pemilikan dan kebenaran dalam satu pelaksanaan?
- Apa yang menjadikan P2PKH sebagai format alamat lalai selama lebih lapan tahun dalam sejarah rangkaian ini?
Teroka
- Blok genesis hanya mengandungi output Pay-to-Public-Key (P2PK). Skrip ini meletakkan kunci awam penuh (pada tahun 2009, kunci tidak termampat sepanjang 65 bait) terus di dalam output, kelihatan sebelum sebarang perbelanjaan, dan menjadikan output bersaiz besar. P2PKH, yang juga terdapat dalam perisian asal 2009 dan digunakan untuk pembayaran ke alamat biasa, sebaliknya menyimpan hash sepanjang 20 bait, lalu menyembunyikan kunci sehingga syiling itu dibelanjakan.
- Skrip penguncian ialah `OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG`. Pelaksanaan bermula dengan data pihak yang membelanjakan di atas tindanan: tandatangan, kemudian kunci awam di bahagian atas. Enjin menyalin kunci itu, membuat hash daripadanya menggunakan RIPEMD-160(SHA256(key)), dan membandingkan hasilnya dengan hash yang disimpan. Jika sepadan, `OP_EQUALVERIFY` lulus; jika tidak, pelaksanaan dihentikan serta-merta.
- Setelah semakan hash berjaya, `OP_CHECKSIG` mengesahkan tandatangan ECDSA berbanding kunci awam yang didedahkan dan data transaksi. Mekanisme dua lapis ini memastikan hanya pemegang kunci persendirian yang sepadan boleh membuka dana tersebut. Skrip output berjumlah 25 bait, struktur padat yang menjadi asas bagi alamat legacy yang bermula dengan '1'.
- P2PKH merupakan jenis output paling biasa bagi pembayaran biasa sepanjang sebahagian besar sejarah bitcoin, dan kekal begitu selama bertahun-tahun selepas SegWit diaktifkan pada Ogos 2017 di blok 481,824, kerana penerimaan native SegWit berlaku secara beransur-ansur. Kejayaannya terletak pada kesederhanaan dan keserasian; ia tidak memerlukan sebarang naik taraf konsensus selain peraturan protokol asal. Setiap nod boleh mengesahkan skrip ini secara bebas tanpa penjejakan keadaan yang rumit, menjadikannya jenis output paling teguh untuk pemindahan umum semasa pertumbuhan awal Bitcoin.
- Format alamat ini menggunakan pengekodan Base58Check, yang merangkumi checksum empat bait untuk mengesan kesilapan taip. Satu aksara yang salah ditaip hampir pasti akan menyebabkan checksum gagal, lalu dompet menolak alamat tersebut. Lewahan ini menjadikan P2PKH mesra pengguna walaupun kerumitan teknikalnya yang mentah, sekali gus merapatkan jurang antara keselamatan kriptografi dan kebolehgunaan manusia.
- Buka peneroka blok dan cari mana-mana transaksi yang mempunyai input yang merujuk kepada alamat '1'. Periksa medan `scriptSig`: ia mengandungi tandatangan diikuti rentetan heks kunci awam. Bandingkan kunci awam ini dengan hash 20 bait dalam `scriptPubKey` output yang dirujuk. Menjalankan SHA-256 kemudian RIPEMD-160 pada kunci tersebut akan menghasilkan semula hash yang disimpan, sekali gus mengesahkan pautannya.
- Sebelum tahun 2012, penggunaan skrip yang kompleks seperti multisignature lima-daripada-lima memerlukan keseluruhan kod penguncian diletakkan terus di dalam output. Ini menjadikan output bersaiz besar, dan penghantar yang membayar yurannya. Ia juga mendedahkan kunci awam setiap peserta serta keperluan penandatanganan tertentu kepada sesiapa sahaja yang memerhati rantaian. Penghantar perlu mengetahui struktur tepat destinasi sebelum menghantar, sekali gus menyukarkan perbendaharaan korporat atau bursa yang memerlukan konfigurasi keselamatan yang fleksibel.
- Gavin Andresen mencadangkan BIP16 pada awal tahun 2012 untuk menyelesaikan masalah ini. Ia membenarkan output mengandungi hanya digest HASH160 bagi sesuatu skrip, bukannya skrip itu sendiri. Skrip output mengecil kepada 23 bait, sedikit lebih kecil daripada 25 bait bagi P2PKH. Penghantar tidak lagi perlu mengetahui syarat perbelanjaan; mereka hanya membayar kepada hash. Kerumitan dialihkan sepenuhnya kepada pihak yang membelanjakan syiling tersebut.
- Pengaktifan BIP16 pada April 2012 penuh kontroversi. Luke Dashjr mencadangkan alternatif, BIP17, yang menggunakan opcode dan skema pengekodan yang berbeza. Perdebatan tentang cadangan mana yang patut diterima pakai semakin hangat dalam komuniti pembangun. BIP16 diaktifkan pada April 2012 selepas pelombong memberi isyarat sokongan, dan menjadi cara standard untuk membalut skrip yang kompleks.
- Membelanjakan output pay-to-script-hash ialah proses dua peringkat. Pertama, pihak yang membelanjakan menolak redeem script penuh mereka ke atas tindanan. Nod menyemak sama ada HASH160 skrip itu sepadan dengan hash dalam output. Jika tidak sepadan, pelaksanaan gagal serta-merta. Jika sepadan, nod kemudian melaksanakan redeem script yang didedahkan itu bersama data selebihnya di atas tindanan untuk mengesahkan syarat perbelanjaan sebenar.
- Reka bentuk ini ada sisi tajamnya: tiada sesiapa boleh menyemak redeem script sebelum pembayaran, kerana hanya hash-nya yang berada on-chain. Jika perisian penerima membina skrip yang rosak, atau skrip itu hilang, syiling yang dibayar ke alamat tersebut boleh menjadi tidak boleh dibelanjakan selama-lamanya.
- Apabila SegWit diaktifkan pada Ogos 2017, P2SH berfungsi sebagai jambatan keserasian. Pengguna boleh membalut skrip witness baharu di dalam sampul P2SH, menghasilkan alamat 'nested' yang masih bermula dengan '3'. Dompet lama yang tidak dapat mengendalikan alamat bech32 yang lebih baharu masih boleh menghantar kepada pengguna SegWit, manakala penerima yang menyokong SegWit mendapat diskaun yuran ketika membelanjakan. Kini, walaupun native SegWit lebih diutamakan kerana kecekapannya, P2SH kekal sebagai mekanisme penting untuk kontrak yang kompleks dan keserasian legacy.
Bahagian IBayar kepada hash kunci awam (P2PKH)
Bahagian IIBayar kepada hash skrip (P2SH)
Fakta utama
- Output P2PKH menyimpan HASH160 sepanjang 20 bait bagi kunci awam, bukannya kunci penuh.
- Skrip penguncian `OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG` panjangnya tepat 25 bait.
- Perbelanjaan memerlukan pendedahan kedua-dua tandatangan ECDSA yang sah dan kunci awam yang sepadan dengan hash yang disimpan.
- Alamat P2PKH legacy bermula dengan '1' dan menggunakan pengekodan Base58Check dengan checksum.
- P2PKH merupakan jenis output yang dominan untuk pembayaran biasa selama bertahun-tahun, sebelum dan selepas SegWit.
- Pelaksanaan gagal serta-merta jika `OP_EQUALVERIFY` mengesan ketidakpadanan antara hash kunci dan hash yang disimpan.
- BIP16 dicadangkan oleh Gavin Andresen dan diaktifkan pada bulan April 2012.
- Skrip output P2SH hanya menyimpan HASH160 bagi redeem script dan panjangnya 23 bait.
- BIP17 milik Luke Dashjr bersaing dengan BIP16 semasa perdebatan sengit dari Januari hingga Mac 2012.
- Mengikut konsensus, redeem script dihadkan kepada 520 bait, iaitu saiz maksimum bagi satu elemen yang ditolak ke tindanan.
- Alamat P2SH menggunakan pengekodan Base58Check dan sentiasa bermula dengan angka ‘3’.
- Nested SegWit (biasanya P2SH-P2WPKH) membolehkan dompet lama membayar pengguna SegWit selepas tahun 2017.
Latihan sembilan, enam, tiga, satu
9KumpulKenal pasti 9 input transaksi sebenar pada blockchain Bitcoin yang membelanjakan daripada alamat P2PKH. Catatkan ketinggian bloknya, kunci awam yang didedahkan dalam scriptSig, dan hash yang sepadan dalam output.
6KelompokkanKumpulkan 9 input tersebut kepada 6 kumpulan mengikut era: 2009-2011, 2012-2013, 2014-2015, 2016-2017, 2018-2021, 2022 dan seterusnya. Perhatikan kunci termampat berbanding kunci tidak termampat.
3SaringKurangkan kumpulan ini kepada 3 sebab yang berbeza mengapa P2PKH kekal dominan walaupun terdapat jenis output yang lebih cekap selepas tahun 2017.
1KristalkanTulis satu ayat yang menerangkan bagaimana `OP_EQUALVERIFY` mengubah kunci awam menjadi komitmen yang mengikat sebelum pengesahan tandatangan berlaku.
Semakan fakta
Tarikh, angka dan dakwaan telah disemak berbanding dengan sumber yang diterbitkan yang disenaraikan di bawah.
- A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 7
- Bitcoin Developer Guide, 'Transactions' documentation (bitcoin.org)
- Satoshi Nakamoto, original Bitcoin client source code (2009-2010 commits)
- Gavin Andresen, BIP16: Pay to Script Hash (2012)
- Luke Dashjr, BIP17: OP_CHECKHASHVERIFY (CHV) (2012)
- Bitcoin Developer Guide: Transactions and Scripts