Pada artikel ini, kami mencoba memeriksa secara rinci perubahan dalam protokol Bitcoin yang terjadi sebagai akibat dari pembaruan softfork Saksi Segregated. Kami menyentuh masalah yang terkait dengan kelenturan transaksi, menjaga kompatibilitas, meningkatkan throughput, format serialisasi transaksi baru, opsi skrip baru, format alamat Bech32 dan kelebihannya, konsep bobot, ukuran, dan ukuran virtual. Selain itu, berikut ini adalah statistik paling penting tentang adaptasi pembaruan dan jawaban atas pertanyaan umum tentang topik pembaruan ini disajikan.
Sebelum melanjutkan ke uraian terperinci tentang semua perubahan dalam pembaruan ini, kami sarankan agar Anda berkenalan dengan gagasan utama Saksi Terpisah. Secara harfiah, Saksi Terpisah diterjemahkan dari bahasa Inggris sebagai "saksi terpisah." Kontes Bitcoin menyiratkan bahwa bukti kepemilikan koin akan disimpan secara terpisah dari data master transaksi, sebagaimana ditunjukkan dalam diagram.
Jika kami mempertimbangkan seluruh pembaruan protokol, maka itu mencakup banyak perbaikan lainnya. SegWit memungkinkan Anda untuk meningkatkan bandwidth jaringan, memisahkan bukti kepemilikan koin dari sisa data transaksi, memperbaiki kekurangan format transaksi yang terkait dengan kemampuan untuk mengubah data dalam transaksi yang ditandatangani (kelenturan transaksi), sambil mempertahankan kompatibilitas ke belakang dengan versi protokol sebelumnya. Dan nilai terbesar dari pembaruan ini adalah memungkinkan Anda untuk mengimplementasikan banyak solusi off-chain yang sangat penting di atas protokol Bitcoin.
Masalah dan solusi kelenturan transaksi
Intinya adalah bahwa ketika bekerja di Bitcoin ada peluang untuk mengubah transaksi sehingga tetap benar selama verifikasi. Perubahan ini sangat kecil, mereka tidak mempengaruhi alamat pengirim dan penerima, tetapi mereka cukup untuk mengubah hasil hash. Dengan kata lain, transaksi akan mentransfer koin ke alamat mereka sebelumnya, tetapi nilai hash yang diubah tidak akan lagi cocok dengan transaksi yang dimodifikasi dengan yang asli.
Jelas, situasi yang dijelaskan di atas hanya dapat terjadi dengan transaksi yang belum menerima konfirmasi. Tanpa solusinya, mustahil untuk mencapai operasi protokol off-chain yang andal, yang mencakup pembangunan rantai transaksi yang belum dikonfirmasi. Sejak saat menyusun transaksi, tidak semua data ditandatangani (misalnya, Anda tidak dapat menandatangani scriptSig), ada kemungkinan beberapa jenis serangan:
- Ubah format tanda tangan . Dalam protokol Bitcoin, format tanda tangan tidak sepenuhnya disetujui dan tergantung pada implementasi perpustakaan OpenSSL, di mana format ketat juga tidak ditentukan untuk tanda tangan. Pihak ketiga dapat memodifikasi transaksi yang dicegat, yang akan memerlukan perubahan dalam nilai hash.
- Dampak langsung pada scriptSig . Seperti disebutkan sebelumnya, scriptSig berisi serangkaian operasi untuk memverifikasi bukti bahwa pengguna tertentu adalah pemilik koin. Namun selain operasi ini, Anda dapat menambahkan orang lain ke dalamnya. Beberapa operasi tidak berbahaya yang tidak memengaruhi apa pun akan menyebabkan perubahan nilai hash transaksi.
Dengan demikian, Anda dapat mengubah nilai hash transaksi tanpa memiliki akses ke kunci pribadi. Mengapa mengubah nilai hash sangat tidak diinginkan?
Pertama-tama, harus dicatat bahwa dimungkinkan untuk membuat salinan transaksi asli, menambahkan perubahan padanya yang tidak akan memengaruhi kebenarannya selama verifikasi, dan mengirimkannya ke jaringan. Salinan yang dimodifikasi dengan nilai hash yang berbeda menghabiskan koin yang sama dengan aslinya, sehingga dapat bersaing dengan transaksi asli untuk konfirmasi.
Protokol off-chain telah disebutkan di atas. Untuk implementasi mereka, solusi untuk masalah kelenturan transaksi diperlukan. Inti dari pekerjaan mereka adalah membangun rantai transaksi yang belum dikonfirmasi. Mengubah nilai hash dari transaksi pertama akan memerlukan ketidakabsahan dari seluruh rantai yang belum dikonfirmasi.
Pembaruan SegWit menetapkan aturan ketat untuk mengisi bidang, sehingga masalah yang terkait dengan kelenturan transaksi untuk transaksi dalam format baru dapat dianggap diselesaikan. Ini memungkinkan kami untuk menentukan data dan membuat serialisasi secara jelas, menghilangkan dualitas.
Kompatibilitas mundur ketika mendistribusikan blok melalui jaringan
Menurut aturan lama, ukuran blok maksimum adalah 1 MB dan berisi transaksi dengan bukti bawaan. Sementara aturan baru mengasumsikan bahwa ukuran blok dasar maksimum adalah 1 MB, tetapi juga ada struktur data dengan bukti. Dengan demikian, ukuran total blok baru melebihi 1 MB.
Untuk kompatibilitas mundur, aturan protokol memungkinkan node lama bekerja dengan blok baru, tetapi mereka hanya akan menerima blok dalam konfigurasi dasar dengan ukuran maksimum 1 MB. Struktur saksi tidak tersedia bagi mereka. Node baru mendapatkan blok penuh dengan transaksi dan bukti. Gambar berikut akan membantu Anda membiasakan diri dengan pertanyaan ini.
Di sebelah kiri adalah diagram operasi protokol Bitcoin sebelum aktivasi Saksi Terpisah. Blok memiliki ukuran maksimum 1 MB, dan didistribusikan antara node jaringan yang berbeda dalam satu bentuk.
Karena ukuran blok terbatas, jumlah transaksi yang dapat ditempatkan di dalamnya juga terbatas, dan kapasitas sistem tergantung pada ini. Tentu saja, ketika muncul pertanyaan tentang peningkatan throughput, hal pertama yang mereka mulai cari adalah cara untuk meningkatkan ukuran blok maksimum.
Cara untuk Meningkatkan Throughput
Pertimbangkan dua cara utama untuk menyelesaikan masalah peningkatan throughput sistem. Setiap tawaran diperiksa dan diuji dengan cermat oleh tim pengembangan protokol Bitcoin. Jika komunitas telah mencapai kesepakatan dan memutuskan untuk mengimplementasikan proposal dalam protokol, pembaruan dikeluarkan.
Pembaruan hardfork. Pembaruan yang paling umum adalah meningkatkan ukuran blok. Diasumsikan bahwa satu unit akan mengakomodasi lebih banyak transaksi, meningkatkan throughput. Namun, unit tersebut tidak akan diterima oleh node yang beroperasi sesuai dengan protokol lama, aturan yang menyatakan bahwa ukuran blok maksimum tidak boleh melebihi 1 MV. Perubahan seperti itu membutuhkan hardfork, yang secara organisasi lebih kompleks daripada softfork.
Pembaruan SoftFork. Saksi Terpisah memungkinkan kita untuk menyelesaikan masalah ini dengan softfork. Bagaimana tepatnya? Ini memungkinkan kita untuk membagi blok menjadi dua bagian, yang pertama menyimpan transaksi, dan yang kedua berisi bukti. Pada saat yang sama, node jaringan baru menerima kedua bagian, sedangkan yang lama hanya menerima blok transaksi 1 MB. Node lama tidak dapat menerima blok dengan bukti dan, karenanya, tidak dapat memvalidasi transaksi yang mereka terima, tetapi ini memungkinkan mereka untuk berpartisipasi dalam membangun konsensus dan tidak menggunakan hardfork, tetapi secara bertahap beralih ke perangkat lunak baru.
Inovasi, Saksi Terpisah
Pertimbangkan apa yang termasuk dalam pembaruan Saksi Segregasi. Inovasi pertama dan terpenting dari Segregated Witness adalah format serialisasi transaksi baru. Selain bidang yang sudah diketahui, ada tiga bidang baru dalam transaksi baru: penanda, bendera, yang digunakan untuk versi dan dalam kasus ini mereka diatur secara ketat, tetapi dalam protokol berikut mereka dapat berubah, serta bidang saksi. Saksi (data saksi) sebenarnya adalah seperangkat bukti kepemilikan koin yang dikeluarkan dari bagian utama transaksi. Secara struktural, sepertinya satu set input, dengan setiap elemen data saksi sesuai dengan input dengan nomor tertentu, yang memungkinkan Anda untuk membandingkan bukti dengan koin tertentu yang dikeluarkan.
ID transaksi saksi
Untuk mendapatkan pengidentifikasi transaksi (id transaksi, txid), Anda perlu membawa transaksi itu sendiri ke satu urutan data dalam format serialisasi khusus, dan kemudian mendapatkan nilai hash dari urutan data ini. Dengan diperkenalkannya Segregated Witness, pengidentifikasi baru, id transaksi saksi (wtxid), dan format serialisasi baru, masing-masing, telah muncul. Untuk transaksi lama yang menghabiskan uang tanpa menggunakan Segregated Witness, wtxid akan sama dengan txid karena tidak akan ada bidang baru yang ditambahkan ke Segregated Witness.
Wtxid diperlukan untuk membangun pohon Merkle alternatif sebagai bukti. Itu dibangun dengan cara yang sama seperti untuk transaksi biasa, hanya wtxid yang digunakan sebagai ganti hash transaksi. Dengan demikian, wtxid di-hash berpasangan dan menghasilkan akar Merkle.
Penting untuk dicatat bahwa akar Merkle dimasukkan ke dalam transaksi coinbase, dan bukan ke header blok. Jika root berada di header blok, struktur blok akan berubah. Node yang mendukung protokol lama tidak dapat berfungsi dengan blok seperti itu. Dan semua upaya untuk mempertahankan kompatibilitas mundur akan bertumpu pada ketidakkonsistenan ini. Oleh karena itu, root dimasukkan ke dalam salah satu output dari transaksi coinbase. Ketika semua node beralih ke Saksi Terpisah, situasi ini dapat berubah dan pendekatan baru akan dipertimbangkan.
Saksikan program-program untuk menetapkan kondisi pengeluaran koin
Mari kita lihat bagaimana skrip transaksi Saksi Segregated dibangun dan bagaimana skrip jaringan yang lebih lama memahami bahwa transaksi Segregated Witness benar, meskipun faktanya mereka tidak menerima bukti kepemilikan koin.
Script yang menggambarkan aturan untuk membelanjakan koin dari transaksi format baru terdiri dari dua bagian. Bagian pertama adalah byte versi saksi (byte yang menentukan versi program saksi). Ia dapat mengambil nilai dari 0 hingga 16 (OP0-OP16), sekarang menggunakan OP0. Di masa depan, versi baru protokol dapat muncul dengan dukungan untuk versi lain dari program saksi. Bagian kedua adalah program saksi. Bagian ini dapat memiliki ukuran 2 hingga 40 byte.
Program Saksi adalah hasil dari hashing naskah saksi. Script saksi itu sendiri berisi deskripsi lengkap tentang kondisi untuk menghabiskan koin. Data saksi berisi bukti kepemilikan koin yang harus memenuhi persyaratan dalam naskah saksi. Dengan demikian, data saksi selalu terdiri dari dua bagian: naskah saksi dan bukti kepemilikan koin.
Perlu dicatat bahwa program saksi tidak mengandung operasi apa pun (pencocokan nilai hash, verifikasi tanda tangan elektronik), dan skrip itu sendiri dimulai dengan kode OP0, oleh karena itu, valid untuk semua node lama. Selain itu, node yang belum diperbarui ke SegWit tidak memeriksa bukti kepemilikan koin untuk output format baru, mereka menganggap pemborosan seperti itu benar dalam hal apa pun. Tegasnya, node lama akan menerima transaksi format baru bahkan jika pengirimnya sebenarnya tidak memiliki koin yang sesuai. Itulah sebabnya SegWit mengharuskan pemilik sebagian besar kekuatan penambangan Bitcoin menerima pembaruan ini. Fitur lain adalah scriptSig dari transaksi yang menghabiskan koin dari output format baru akan kosong.
Opsi baru untuk mengatur kondisi pengeluaran koin
Dengan diperkenalkannya SegWit, dua format standar untuk scriptPubKey diusulkan, yang menjadi alternatif dari dua format paling umum untuk menetapkan aturan pengeluaran koin sebelum pembaruan ini muncul. Mari kita pertimbangkan mereka secara berurutan.
Bayar untuk menyaksikan hash kunci publik (P2WPKH) adalah analog dari pembayaran standar untuk hash kunci publik. Apa bedanya? Seperti disebutkan sebelumnya, scriptSig tidak diisi dan tetap kosong. Semua bukti kepemilikan koin ditransfer ke struktur data saksi.
Dalam hal ini, skrip yang dianggap sebelumnya, versi dan hash dari kunci publik, yang merupakan program saksi, dimasukkan ke dalam scriptPubKey. Sebuah node di jaringan membedakan skrip pengeluaran dari yang lain karena fakta bahwa ia memiliki versi satu dan ukuran data sebesar 20 byte. Versi lain dan ukuran yang berbeda membawa aturan pengeluaran yang berbeda.
Dalam hal ini, scriptPubKey berisi dua bagian: nomor versi saksi adalah nol dan nilai hash dari kunci publik penerima. ScriptSig akan kosong, dan data saksi akan berisi tanda tangan elektronik dan kunci publik untuk memverifikasinya.
Hash skrip bayar untuk menyaksikan (P2WSH) adalah analog dari standar bayar untuk skrip Dalam hal ini, skrip khusus dapat digunakan untuk menetapkan aturan pengeluaran koin. Bagaimana sebuah host membedakan skrip seperti itu dari yang sebelumnya? Dalam hal ini, versi masih memiliki nilai satu, dan program saksi mengambil 32 byte dan merupakan nilai hash dari skrip saksi. Jika suatu transaksi datang ke host yang berisi skrip yang akan memiliki versi pertama, tetapi ukurannya akan berbeda dari nilai 20 atau 32 byte, maka tuan rumah akan menolak transaksi ini karena tidak akan tahu cara bekerja dengannya.
Data saksi di sini dibagi menjadi dua bagian. Yang pertama berisi set bukti kepemilikan koin, yaitu, set tanda tangan. Pada bagian kedua, skrip saksi ditempatkan, konten yang hanya menetapkan aturan untuk pengeluaran koin, tetapi dalam kasus ini ditunjukkan pada saat pengeluaran, dan pada saat mengirim koin, nilai hashnya ditunjukkan.
Dalam hal ini, scriptPubKey berisi dua bagian: nomor saksi versi adalah nol dan nilai hash dari skrip saksi untuk kasus multi-signature 1-of-2. ScriptSig akan kosong, dan data saksi akan berisi tanda tangan elektronik dan naskah saksi asli dalam teks yang jelas.
Bungkus P2SH
Format skrip baru berbeda dari yang lama. Karenanya, layanan dan dompet lama tidak akan tahu cara bekerja dengan format skrip ini dan cara membuatnya. Untuk kompatibilitas, transaksi Segregated Witness menggunakan P2SH menggunakan "pembungkus" khusus yang memungkinkan Anda untuk membuat transaksi yang memiliki sifat-sifat transaksi Segregated Witness, tetapi tidak berbeda dari P2SH biasa untuk dunia luar.
P2SH digunakan untuk menyederhanakan pekerjaan pengirim dan tidak membebani dia dengan detail implementasi Naskah Penebus penerima. Dalam hal ini, penerima hanya memberikan nilai hash Redeem Script kepada pengirim, dan skrip itu sendiri diteruskan ke scriptSig beserta bukti.
Dalam hal ini, scriptPubKey berisi operasi hash, nilai tebusan scrip redeem, dan operasi perbandingan (seperti untuk versi P2SH lama). ScriptSig di sini akan berisi nilai hash dari kunci publik, dan data saksi akan berisi tanda tangan elektronik dan kunci publik.
Pendekatan ini memungkinkan dompet digital yang tidak diperbarui untuk mengirim transaksi ke alamat Saksi Terpisah, tanpa mengetahui apa-apa tentang cara-cara baru untuk mengatur kondisi pengeluaran koin.
Format Alamat Bech32 Baru
Perlu menyebutkan alamat Bech32 secara terpisah yang dianggap sebagai alamat SegWit asli. Untuk sebagian besar sejarahnya, Bitcoin telah menggunakan pengkodean Base58 untuk alamat dengan tambahan checksum, yang merupakan hasil pemotongan hashing ganda menggunakan fungsi hash SHA-256. Mereka adalah bagian dari perangkat lunak asli dan ruang lingkup mereka diperluas di BIP13 untuk P2SH. Tetapi kedua set karakter dan algoritma checksum memiliki keterbatasan:
- alamat dalam Base58 membutuhkan lebih banyak memori dalam kode QR, karena tidak dapat menggunakan mode representasi alfanumerik;
- base58 sangat merepotkan untuk penulisan yang dapat diandalkan ke kertas, mengetik dari keyboard ponsel, atau membaca dengan keras;
- hashing checksum ganda lambat;
- decoding base58 rumit dan relatif lambat.
Pembaruan SegWit mencakup kelas keluar baru (program saksi) dan dua kasusnya: P2WPKH dan P2WSH. Fungsi mereka secara tidak langsung tersedia untuk node lama melalui penggunaan P2SH, tetapi akan lebih optimal dan lebih aman untuk menggunakannya secara langsung, untuk ini perlu untuk memperkenalkan format alamat baru.
Spesifikasi Alamat Bech32
Alamat Bech32 memiliki panjang tidak lebih dari 90 karakter dan berisi:
- Bagian yang bisa dibaca manusia. Ini termasuk data yang mungkin perlu ditransmisikan atau yang ada hubungannya dengan pemilik alamat, setidaknya sepanjang 1 karakter. Misalnya, secara default untuk alamat mainnet karakternya adalah "bc", dan untuk testnet karakternya adalah "tb".
- Pembatas yang selalu 1. Jika "1" diizinkan di dalam bagian yang dapat dibaca manusia, maka pemisah adalah yang terakhir dari karakter "1".
- Bagian data memiliki panjang setidaknya 6 karakter dan hanya terdiri dari karakter alfanumerik, tidak termasuk "1", "b", "i", dan "o". Di sini versi program saksi dan data program saksi itu sendiri (dari 2 hingga 40 byte) digunakan di sini sebagai data utama.
Mengapa menyertakan pemisah di alamat? Ini memungkinkan Anda untuk secara jelas memisahkan bagian yang dapat dibaca manusia dari bagian yang dapat dibaca data, menghindari kemungkinan tabrakan dengan bagian yang dapat dibaca manusia lainnya yang menggunakan awalan. Itu juga menghindari pembatasan set karakter untuk bagian yang bisa dibaca manusia. Pemisah adalah 1 karena menggunakan karakter non-alfanumerik membuatnya sulit untuk menyalin alamat (tanpa mengklik dua kali dalam banyak aplikasi). Oleh karena itu, karakter alfanumerik dipilih di luar rangkaian karakter utama. Juga, penggunaan sistem angka 32 basis disertai dengan peningkatan panjang alamat sebesar 15% dibandingkan dengan sistem angka 58 basis, tetapi ini tidak masalah ketika menyalin alamat.
Alamat Checksum Bech32
6 karakter terakhir dari alamat adalah sebuah checksum. Checksum dibuat berdasarkan kode BCH, yang menjamin deteksi kesalahan yang memengaruhi tidak lebih dari 4 karakter, dan kemungkinan checksum akan menyatu ketika lebih dari 4 kesalahan dibuat adalah salah satu dari 109.
Salah satu keuntungan menggunakan kode BCH adalah mereka dapat digunakan untuk memperbaiki kesalahan. Jika hingga 4 kesalahan dibuat di alamat, mereka akan diperbaiki secara otomatis. Dan jika lebih banyak kesalahan dibuat, maka mereka akan dideteksi dengan probabilitas tinggi, tetapi tanpa kemungkinan koreksi otomatisnya.
Huruf besar dan kecil di alamat
Huruf kecil digunakan ketika nilai karakter diperlukan untuk sebuah checksum.
Perangkat lunak selalu menampilkan seluruh string alamat Bech32 dalam huruf kecil. (, QR-), . , , , . , QR- , - , 45% , .
, Segregated Witness, , . Segregated Witness . 1 MB. . , .
(weight units). 3, witness data 1. , , witness data 3 , . . .
block weight = base size * 3 + total sizeblock weight – ( )
base size – ( )
total size – ( )
, , . .
, , , , 4 . Segregated Witness , .
, . (virtual size) , , , spb (satoshi per byte).
virtual size = weight units / 4Segregated Witness 4 , , . , . , . , , . , witness data (base size) 1 MB, 4 MB.
: « witness data?». . , 1 MB 4 MB. . 1.8 MB. ? 60% . 1 MB, 40% , .
400000 * 4 = 1600000600000 * 1 = 6000001600000 + 600000 = 22000004000000 / 2200000 = 1.81 MB, , 1.8 MB. , .
2018 SegWit 35% . Segregated Witness (, Electrum Bitxfy).
BitMex Research. 1 MB, 2 MB. , , SegWit .
BitMex Research, .
, Segregated Witness off-chain Bitcoin. , lightning network – SegWit, , .
Pertanyaan yang Sering Diajukan
— , Segregated Witness RBF (replace-by-fee)?, replace by fee Segregated Witness , , , , sequence number . , , , , .
— ?- , . ScriptSig, , , . , , - . , , , - .
— witness data?, Segregated Witness . , , , . , . : , , ( ), , Witness data, . .
— , RFC3548 z-base-32 Bech32 ?Set karakter dipilih untuk meminimalkan ambiguitas yang terkait dengan kesamaan visual mereka. Urutan dipilih untuk meminimalkan jumlah pasangan karakter yang berbeda dalam kurang dari satu bit data. Checksum dipilih untuk memaksimalkan probabilitas mendeteksi sejumlah kecil kesalahan, yang meningkatkan efisiensinya untuk kesalahan tipikal.