Orphan Block

Blok sebelumnya kadang disebut induk. Untuk Orphan Block yang sebenarnya, node Jana tidak mengenal induknya sehingga belum bisa menuntaskan pemeriksaan sambungan. Stale Block dapat memiliki induk yang dikenal dan sepenuhnya valid; node hanya mengikuti cabang lain sebagai riwayat aktif. Bitcoin Developer Guide secara jelas membedakan kedua makna tersebut. Ketika Jana melihat orphan di penjelajah blok, ia lebih dulu bertanya apakah pendahulunya hilang atau blok itu sekadar tidak bertahan di rantai utama. [1]

Perbedaan itu juga terlihat dalam Bitcoin Core, perangkat lunak untuk menjalankan node yang memeriksa blok dan transaksi berdasarkan aturan Bitcoin. Pada Bitcoin Core 29, AcceptBlockHeader mencari pendahulu melalui hashPrevBlock, rujukan ke sidik jari pengenalnya. Jika indeks tidak memiliki catatan, hasilnya prev-blk-not-found. Jika induknya dikenal dan ditandai tidak valid, hasilnya bad-prevblk. Yang pertama berarti “konteksnya belum ada”; yang kedua berarti “Anda melanjutkan blok yang tidak valid”. Mendapatkan pendahulu yang hilang memungkinkan pemeriksaan berikutnya, tetapi belum menjamin penerimaan seluruh blok. [2]

Blok memiliki header, kumpulan informasi ringkas untuk identitas dan sambungan, serta badan berisi transaksi. Bitcoin Core 0.10.0 memperkenalkan sinkronisasi headers-first: header didapatkan dan diperiksa lebih dulu, kemudian blok dapat diunduh secara paralel. Karena itu, node Jana dapat mengenal header pendahulunya meski seluruh blok belum tersimpan di disk. Badan blok yang belum ada tidak sama dengan pendahulu yang tidak dikenal. Jika keduanya tertukar, pengunduhan biasa bisa tampak seperti persoalan misterius. [3]

Perintah getchaintips pada Bitcoin Core 29 menunjukkan ujung cabang mana yang dikenal node Jana. active menandai rantai aktif; valid-fork berarti cabang tidak aktif yang sudah divalidasi sepenuhnya. valid-headers berarti semua blok tersedia tetapi belum diperiksa sepenuhnya; headers-only berarti sebagian blok belum tersedia. invalid menunjukkan cabang yang mengandung blok tidak valid. Jadi, ini bukan daftar masalah yang semuanya sama. Bahkan ungkapan orphaned branches dalam bantuan tidak menghapus perbedaan itu. [4]

Bayangkan dua blok berbeda, A dan B, pada ketinggian 900000. Ini contoh buatan kami, bukan laporan kejadian tertentu. Ketinggian adalah posisi dalam rantai, sehingga blok yang bersaing dapat memiliki ketinggian yang sama. Jana membedakannya melalui hash, sidik jari pengenal blok, dan previousblockhash, rujukan ke pendahulunya. Pilihan di antara cabang valid ditentukan oleh kerja kumulatif, bukan hanya ketinggian. Antarmuka RPC untuk memberi perintah kepada program menyebutnya chainwork: akumulasi kerja yang diharapkan sesuai tingkat kesulitan blok-blok tersebut. [1] [5]

Ketika Jana menanyakan blok di luar rantai utama melalui getblock, Bitcoin Core 29 dapat menampilkan confirmations = -1. Ini penanda status khusus, bukan jumlah konfirmasi biasa. Bukan hitung mundur, bukan pula kedalaman reorganisasi rantai yang negatif. Nilai itu juga tidak membuktikan pendahulu yang hilang. Jana harus membacanya bersama identitas blok dan status cabang; node-nya pun belum tentu menyimpan semua blok yang pernah dilihat peserta lain. [5]

Imbalan blok dibuat oleh transaksi awal khusus bernama coinbase, yang tidak berkaitan dengan bursa bernama sama. Output transaksi mencatat sejumlah bitcoin beserta syarat yang harus dipenuhi untuk membelanjakannya. Pada Bitcoin Core 29, COINBASE_MATURITY bernilai 100: output yang dibuat pada ketinggian H pertama kali dapat dibelanjakan dalam blok valid pada H+100. Yang dihitung adalah selisih ketinggian, bukan menit berlalu. Namun, syarat menunggu ini tidak menggantikan keanggotaan dalam rantai aktif. Selama blok imbalan berada di cabang tidak aktif, output-nya tidak ada dalam himpunan UTXO aktif, catatan output yang belum dibelanjakan. Bertambahnya blok di tempat lain tidak otomatis mengembalikan uang tersebut. [6] [7] [1] [8]

Jana menyimpan hash blok, pendahulunya, status cabang, dan versi program. Ia menambahkan respons getchaintips dan getblock serta waktu saat memperolehnya. Waktu itu dipisahkan dari field time dalam header: cap waktu blok bukan saat komputernya mengamati blok tersebut. Catatan ini membantu membandingkan pengamatan selanjutnya, tetapi tidak sendiri membuktikan serangan, gangguan jaringan tertentu, atau tingkat orphan global. Pertama-tama, catatan itu menggambarkan keadaan satu node pada saat tertentu. [4] [5]