Blok başlığının konsept analizi
Blok başlıkları 80 bayt formatında serileştirilir ve daha sonra Bitcoin iş yükü doğrulama algoritmasının bir parçası olarak karma hale getirilerek serileştirilmiş başlık formatını konsensüs kurallarının bir parçası haline getirir.
Karma, dahili bayt sırasına göre düzenlenmiştir; diğer değerler küçük endian düzenindedir.
Blok başlığı mesajlarının örnekleri aşağıdaki gibidir:
02000000 ........................... Blok sürümü: 2 b6ff0b1b1680a2862a30ca44d346d9e8910d334beb48ca0c0000000000000000 ... Önceki bloğun başlığının hashı 9d10aa52ee949386ca9385695f04ede270dda20810decd12bc9b048aaab31471 ... Merkle kökü 24d95a54 ........................... Unix süresi: 141523997230c31b18 ..................... Hedef: 0x1bc330 * 256 ** (0x18-3) fe9f0864 ........................... NonceSürümleri Engelle
-Versiyon 1: Genesis bloğunda sunulmuştur (Ocak 2009)
-Version 2: Bitcoin Core 0.7.0'da (Eylül 2012) bir soft fork aracılığıyla tanıtıldı. BIP34'te belirtildiği gibi, geçerli bir sürüm2 bloğu, jeton tabanındaki blok yüksekliği parametresini gerektirir. Bazı blokları reddetme kuralları da BIP34'te açıklanmıştır; bu kurallara göre, Bitcoin Core 0.7.0 ve sonraki sürümler, coinbase'de blok yüksekliği 224.412 olan ve sürüm 2 olmayan blok yüksekliklerini ve blok yüksekliği 227.930 olan blok yüksekliklerini reddetmeye başlar. Üç hafta sonra, yeni oluşturulan sürüm1 blokları reddedildi.
-version3: Bitcoin Core 0.10.0'da (Şubat 2015) bir soft fork aracılığıyla tanıtıldı. Çatal tam uygulamaya ulaştığında (Temmuz 2015), BIP66'da açıklandığı gibi yeni bloktaki tüm ECDSA imzalarını kesinlikle DER kodlaması gerekir. Bitcoin Core 0.8.0'dan (Şubat 2012) bu yana, katı DER kodlaması kullanmayan işlemler standart değildir.
-version4: BIP65'te belirtilen ve Bitcoin Core 0.11.2'de (Kasım 2015) tanıtılan blok bir soft fork (Aralık 2015) aracılığıyla başlatıldı. Bu bloklar artık bu BIP'de açıklanan yeni OP_CHECKLOCKTIMEVERIFY işlem kodunu desteklemektedir.
Sürüm 2, 3 ve 4 yükseltmeleri için kullanılan mekanizma genellikle IsSuperMajority olarak adlandırılır ve bu özellik, bu yumuşak dal değişikliklerini yönetmek için Bitcoin Core'a eklenir. Bu yöntemin tam açıklaması için, BIP34'e bakın.
Merkle Ağaçları
Merkle kökü, bu bloktaki tüm işlemlerin TXID'leri kullanılarak oluşturulur, ancak önce TXID'lerin mutabakat kurallarına göre düzenlenmesi gerekir:
Coinbase işlemlerinin TXID'si her zaman ilk sırada yer alır.
-Bu bloktaki herhangi bir girdi, bu blokta aynı anda görünen çıktıları kullanabilir (maliyetin geçerli olduğu varsayılarak). Ancak, çıkışa karşılık gelen TXID, girişe karşılık gelen TXID'den önce bir noktaya yerleştirilmelidir. Bu, tüm blok zinciri işleminin, girilmeden önce karşılık gelen bir çıktıya sahip olmasını sağlar.
Bir blokta yalnızca bir coinbase işlemi varsa, coinbase TXID merkle kökünün hash'i olarak kullanılacaktır.
Bir blokta yalnızca bir coinbase işlemi ve bir başka işlem varsa, bu iki işlemin TXID'leri sırayla düzenlenir, 64 orijinal bayta birleştirilir ve sonra SHA256 (SHA256) hash'i merkle kökünü oluşturmak için birlikte birleştirilir.
Bir blokta üç veya daha fazla işlem varsa, orta Merkle ağaç sırası oluşturulacaktır. TXID'ler, coinbase işleminin TXID'sinden başlayarak sırayla düzenlenir ve eşleştirilir. Her çift, ikinci karma satırını oluşturmak için 64 ham bayt ve SHA256 (SHA256) karması olarak birleştirilir. Tek (çift olmayan) bir TXID varsa, son TXID'yi kendi kopyasına ve karmasına bağlayın. İkinci satırda ikiden fazla karma varsa, üçüncü satırı oluşturmak için işlemi tekrarlayın (ve gerekirse ek satırlar oluşturmak için daha fazla tekrarlayın). Bir satır yalnızca iki hash değerine sahip olduğunda, bu hash değerleri birleştirilir ve bir merkle kökü oluşturmak için hashing uygulanır.
Yukarıdaki mantık biraz karmaşık, hadi bunu bir resim aracılığıyla sezgisel olarak hissedelim:
Birleştirildiğinde, TXID ve ara karma her zaman dahili bayt sırasına göre düzenlenir ve blok başlığına yerleştirildiğinde, üretilen merkle kökü de dahili bayt sırasına göre düzenlenir.
Hedef nBits
Hedef eşik, 256 bitlik işaretsiz bir tamsayıdır ve başlık karması, blok zincirinin geçerli bir parçası olmak için başlığa eşit veya bundan düşük olmalıdır. Bununla birlikte, başlık alanı nBits yalnızca 32 bitlik alan sağlar, bu nedenle hedef numara, bilimsel gösterimin temel 256 sürümü gibi çalışan "kompakt" adı verilen bir kesin biçim kullanır:
Temel 256 sayı olarak nBits, bayt kadar hızlı ayrıştırılabilir; bu, ondalık sayıları ondalık bilimsel gösterimde ayrıştırmakla aynıdır:
Hedef eşiğin işaretsiz bir tamsayı olması gerekmesine rağmen, orijinal nBits uygulaması, işaretli veri sınıfının özniteliklerini miras alır.Etkili sayının yüksek biti ayarlanırsa, hedef eşiği negatiftir. Bu işe yaramaz - üstbilgi hash'i işaretsiz bir sayı olarak değerlendirilir, bu nedenle hiçbir zaman negatif hedef eşiğine eşit veya bundan düşük olmayacaktır. Bitcoin bu sorunu iki şekilde ele alır:
Zorluk 1, ana ağdaki ve mevcut test ağındaki nBits değeri 0x1d00ffff ile temsil edilen minimum izin verilen zorluktur. Yeniden test modu, uint32_max'ın altında kodlanabilen en yüksek değer olan 1-0x207fffff farklı zorluk değerlerini kullanır; bu, blokların neredeyse anında yeniden test modunda oluşturulmasını sağlar.
Serileştirilmiş Bloklar
Mevcut fikir birliği kurallarına göre, serileştirme boyutu 1 MB'den küçük veya ona eşit olmadıkça, blok geçersizdir. Aşağıda açıklanan tüm alanlar serileştirilmiş boyuta göre hesaplanır
Bir bloktaki ilk işlem, bu bloktaki işlemlerle ödenen işlem ücretlerini toplaması ve tüketmesi gereken bir para bazlı işlem olmalıdır.
6,930.000'den daha düşük blok yüksekliğine sahip tüm bloklar, yeni oluşturulan Bitcoin değerinin bir blok sübvansiyonu alma hakkına sahiptir ve bu, aynı zamanda madeni para işlemleri için de kullanılması gerekir. (Blok sübvansiyonu 50 bitcoinden başlar ve her 210.000 blokta bir yarıya düşer - kabaca dört yılda bir ve Kasım 2017 itibariyle 12,5 bitcoin'dir.)
İşlem ücretleri ve blok sübvansiyonları birlikte blok ödülleri olarak adlandırılır. Mevcut blok ödülünden daha fazla değer harcamaya çalışırsa, coinbase işlemi geçersizdir.
