Bitcoin 1.01 Protokolü: Bitcoin 1.01'e bağlı, hisse kanıtlı, sütunlara bölünmüş ve saniyeler içinde kesinleşen bir katman

Sürüm 1 · 2026-10-30 · Program: protokol101 · Bu belge Bitcoin 1.01 whitepaper'ının (WHITEPAPER.md) eşidir.

Özet

Bitcoin 1.01 Protokolü (P101), Bitcoin 1.01'in yanında çalışan ikinci bir zincirdir. Bitcoin 1.01 iş kanıtıyla en ağır zinciri seçer ve 15 dakikada bir blok üretir; P101 ise hisse kanıtı ve iki turlu bir oylama ile 4 saniyelik slotlarda blok üretir ve bir bloğu ~8 saniye sonra geri dönülmez biçimde kesinleştirir. Durum 16 paralel Dor Sütununa bölünür; her hesap tek kullanımlık, yalnızca hash'e dayanan bir anahtarla imzalar ve her işlemde bir sonraki anahtarının özetini zincire bağlar.

P101'de ön kazım yoktur. P101 coin'i yalnızca bir yolla oluşur: Bitcoin 1.01'de yakılan coin, P101'de 1:1 basılır. P101 bu yüzden Bitcoin 1.01'in başlık zincirini kendi durumunun parçası olarak, Bitcoin 1.01'in kendi kurallarıyla doğrular. İki zincir aynı cüzdanı ve aynı kâğıt yedeği kullanır; kullanıcı ikisini birlikte ya da herhangi birini tek başına kullanabilir.

Mimarinin adları biyolojiden gelir (polimeraz, makbuz, kromozom, bağışıklık). Her adın altında standart ve denetlenebilir bir yapı vardır; aşağıdaki tablo bu eşlemeyi verir. Belgenin sonunda bu sürümde olmayanlar ayrıca listelenir.

1. Neden ikinci bir katman

Bitcoin 1.01'in tasarımı bilerek muhafazakârdır: SLH-DSA imzaları 29.792 bayttır, 4 MB'lık bir blok ~133 işlem taşır, yani saniyede ~0,15 işlem. İş kanıtının kesinliği olasılıksaldır. Bu, değer saklamak için doğru bir dengedir ama günlük ödemeler, hızlı kesinlik ve ölçek için yetmez. P101 bu üç ihtiyacı karşılar ve Bitcoin 1.01'in güvenlik modeline dokunmaz: Bitcoin 1.01'in uzlaşı kuralları P101'den bağımsızdır; P101 durursa Bitcoin 1.01 etkilenmez.

2. Mimari: biyolojik ad, teknik karşılık

3. Parametreler

4. Biçim

4.1 Nükleaz-384 ve alan ayrımı

Her hash Nükleaz-384(alan, veri) = ORION-1024("protokol101/" + alan + "/v1", veri)'nin ilk 48 baytıdır. ORION, Bitcoin 1.01'in hash ailesidir (Keccak-f[1600], kapasite 1024 bit). 384 bit çıktı, teorik kuantum çarpışma saldırısına (Brassard-Høyer-Tapp) karşı bile ~2^128 güvenlik bırakır. Alan etiketleri bir bağlamda üretilen hash'in başka bir bağlamda geçerli sayılmasını engeller: hesap, anahtar-taahhut, islem, islem-imza, oy, baslik, govde, dor-basi, smt-yaprak, smt-dugum, makbuz-koku, kalp-atisi, randao, oneren, genom, yakma-kimligi ve diğerleri.

4.2 Hesap ve kovalent bağ

Bir hesabın kimliği, ilk anahtarının taahhüdünden türer:

taahhüt(şema, açık_anahtar) = Nükleaz("anahtar-taahhut", şema ‖ açık_anahtar)
hesap                       = Nükleaz("hesap", taahhüt_0)[0..32)
adres                       = "p101" + Base58(hesap ‖ 4 bayt kontrol)

Durumda hesabın yanında bir sonraki anahtarın taahhüdü durur. Her işlem şunları taşır: sıra numarası (nonce), o anki açık anahtar, imza ve sonraki_taahhüt. Doğrulama: taahhüt(şema, açık) == durumdaki taahhüt ve imza geçerli; sonra durumdaki taahhüt sonraki_taahhüt olur. Hesap ilk kez harcanırken durumda taahhüt yoktur; işlem ilk_taahhüt'ü açar ve Nükleaz("hesap", ilk) == gönderen denetlenir.

Kazanım: açık anahtar zincirde yalnızca harcama anında görünür ve hemen geçersizleşir. Kuantum bir saldırgan eski bir anahtarı kırsa bile işe yaramaz; hesap artık başka bir anahtara bağlıdır.

4.3 Şemalar

WOTS+, Bitcoin 1.01'in ACVP vektörleriyle doğrulanmış SLH-DSA kodundaki bileşenin kendisidir (slhdsa::wots); yeni bir imza uygulaması yazılmadı. Tek kullanımlık bir anahtar aynı mesaj için iki kez imzalanırsa sızar; bu yüzden (a) WOTS+ hesabında sonraki_taahhüt o anki taahhütle aynı olamaz, (b) cüzdan bir nonce için ikinci imzayı reddeder (imzalanan_nonce.txt), (c) ücret imzadan önce hesaplanır (işlem boyu imzanın içeriğine bağlı değildir).

Cüzdan anahtarları Bitcoin 1.01 cüzdanının ana sırrından türer: tohum = Nükleaz("cuzdan-tohumu", ana_sır)[0..32); k. anahtarın tohumları Nükleaz("wots-sk" / "wots-pk", tohum ‖ hesap_no ‖ k). Aynı kâğıt yedek iki zinciri de kurtarır.

4.4 İşlem türleri

İşlem kimliği Nükleaz("islem", gövde); imzalanan mesaj Nükleaz("islem-imza", gövde). Tanık (şema, açık anahtar, imza) gövdeden ayrıdır. Asgari ücret: taban_ücret × ⌈boy / 1000⌉; ücret bloğu önerene gider.

4.5 Blok

Başlık: sürüm | slot | önceki (48) | öneren | zaman | Dor Başları (N × 48)
        | doğrulayıcı kökü | Bitcoin 1.01 kökü | gövde kökü | tanık kökü | tohum
Gövde : yeni Bitcoin 1.01 başlıkları (en fazla 100) | oylar (en fazla 2.000) | işlemler (en fazla 2.000, sütun sırasıyla)
İmza  : önerenin XMSS imzası (başlık hash'i üzerine)

• zaman = genesis_zamanı + slot × slot_süresi (kesin; düğüm gelecekteki slotun bloğunu kabul etmez).
• Dor Başı_c = Nükleaz("dor-basi", c ‖ SMT kökü_c ‖ makbuz kökü_c ‖ işlem kökü_c).
• Sparse Merkle ağacı: 384 seviye; anahtar Nükleaz("smt-anahtar", hesap), yaprak Nükleaz("smt-yaprak", anahtar ‖ hesap_durumu). Ekleme sırası kökü değiştirmez; üyelik ve yokluk kanıtı boş alt ağaçları bir bit maskesiyle sıkıştırır. Hafif bir istemci bakiyesini Dor Başı'na karşı kanıtla doğrular.
• Tanık kökü (Kromozom): bloktaki bütün imzalar ve açık anahtarlar Reed-Solomon ile 8 veri + 8 parite parçasına bölünür (GF(2^8)); parçaların Merkle kökü başlıktadır. Herhangi 8 parça tanığı geri kurar.

5. Uzlaşı: Polimeraz ve PCR döngüsü

Öneren seçimi. Her slotun önereni, epoch başında dondurulmuş ağırlıklarla, Nükleaz("oneren", tohum ‖ slot)'tan türetilen bir sayıyla seçilir. Öneren o slotta blok üretmezse slot boş geçer.

Oylar. Her etkin doğrulayıcı, gördüğü ve geçerli bulduğu bloğa bir oy verir: `(slot, blok hash'i, doğrulayıcı no, anahtar no, yaprak no, [RANDAO açılımı], [anahtar yenileme])`, XMSS ile imzalı (yaprak başına bir imza; yaprak numarası her doğrulayıcı için kesinlikle artar). Oylar dedikodu ile yayılır ve sonraki bloklara girer.

Onaylılık ve kesinlik (2 zincir kuralı). Bir bloğa, o zincirde dahil edilmiş oyların ağırlığı toplam etkin ağırlığın 2/3'ünü geçince blok onaylı olur. Onaylı bir blok ve onun doğrudan çocuğu onaylıysa, ilk blok KESİNdir. Kesinlik durumun parçasıdır (zincirdeki oylardan hesaplanır), bu yüzden her düğüm aynı sonucu bulur.

Çatal seçimi. Önce en yüksek kesin slot, sonra en yüksek onaylı slot, sonra en yüksek slot, eşitlikte küçük hash. Kesinleşmiş bloğu içermeyen bir dal ya da kesin slotun gerisindeki bir blok hiçbir zaman kabul edilmez.

Doğrulayıcı anahtarlarının ön-rotasyonu. XMSS ağacının yaprakları bitmeden (son 4 yaprak) doğrulayıcı, bir oyuna kayıtta taahhüt ettiği bir sonraki anahtarı (Nükleaz("xmss-taahhut", pk_seed ‖ kök)) ve ondan sonrakinin taahhüdünü ekler. Geçmiş anahtarlar ceza kanıtlarını doğrulamak için durumda kalır. Benzetimde 150 slotta üç doğrulayıcının hepsi anahtarını yeniledi ve kesinlik kesilmedi.

Doğrulayıcı yeni anahtara ancak yenileme kaydı zincire girdikten sonra geçer: düğüm her imzadan önce kendi anahtar durumunu zincirdeki kaydıyla eşitler (zincirdeki anahtar no'su bir sonrakiyse geçer). Yenileme önerenin kendi bloğundaki bir oyda olabilir; o blokta yaprak sırası, oylar uygulanmadan önceki anahtara göre denetlenir. Yaprakları biten anahtar imza atmaz (düğüm uyarı yazar, düşmez). Regresyon testi: tek doğrulayıcı, 300 blok, en az 5 anahtar (bölüm 5c); gerçek düğümde deneme ağında 375 blok (~6 yenileme) kesintisiz.

6. Genom Güncellemesi (epoch) ve Kalp Atışı

Her epoch başında, sırayla:

1. Katılım: oylarının yarısından azını veren doğrulayıcının stake'inden 1/64 yakılır (uyuyan hücre). Dört epoch üst üste katılmayan çıkarılır; stake'i karantinaya girer. Epoch'ta hiç oy yoksa (ağ tamamen durmuşsa) kimse cezalandırılmaz.
2. Karantina: süresi dolan çekimler bakiyeye geçer.
3. Kalp Atışı: tohum ← Nükleaz("kalp-atisi", tohum ‖ RANDAO karışımı ‖ Bitcoin 1.01 uç hash'i ‖ epoch). RANDAO karışımı, doğrulayıcıların bu epoch'taki hash zinciri açılımlarından oluşur (her açılım, kayıtlı bir öncekinin ön görüntüsüdür; kimse değeri önceden seçemez). Bitcoin 1.01'in iş kanıtlı uç hash'i ucuz manipülasyonu pahalılaştırır.
4. Ağırlıklar: yeni epoch'un ağırlıkları dondurulur: stake (asgariyi geçiyorsa) + fide ağırlığı (doğrusal azalan).

Düğüm her 256 epoch'ta bir Genom Arşivi kaydı yazar: epoch, kesin slot, Genom kökü ve durum özeti.

7. Dor Sütunları ve mRNA makbuzları

Hesabın sütunu (hesap[0] · 256 + hesap[1]) mod N'dir (hesap kimliği bir hash olduğu için dağılım tekdüzedir). Bir işlem göndericinin sütununa aittir; blok içinde işlemler sütun sırasıyla dizilir ve her sütunun Dor Başı ayrı hesaplanır. Alıcı başka bir sütundaysa gönderici sütunu bir makbuz üretir (alıcı ‖ miktar ‖ işlem kimliği, makbuz kökünde) ve tutar bir sonraki slotun başında hedef sütuna işlenir. Bu sürümde bütün tam düğümler bütün sütunları doğrular; sütunlar durumun, işlemlerin ve kanıtların bölünmesini sağlar. Doğrulayıcıların sütunlara ayrı komitelere bölünmesi, imzaların STARK ile toplulaştırılmasını gerektirir (bölüm 13).

8. Bitcoin 1.01 ile bağ: başlık zinciri ve yakma köprüsü

Başlık zinciri durumun parçasıdır. Genesis, Bitcoin 1.01'in genesis başlığını içerir. Öneren, yerel Bitcoin 1.01 düğümünün bloklar.dat dosyasından yeni başlıkları okuyup bloğa koyar (en fazla 100). Durum her başlığı Bitcoin 1.01'in kendi kurallarıyla doğrular: ebeveyn ve yükseklik, beklenen_hedef (göreli ASERT ve lansman rampası dahil), iş kanıtı, kanonik hedef, 3x+1 alanı, MTP ve zaman. En çok işi taşıyan dal seçilir. Böylece yakma talebinin geçerliliği her düğümde aynıdır ve dış bir sunucuya bağlı değildir.

Yakma. Bitcoin 1.01'de bitcoin101 protokole-yak <p101 hesabı> <miktar> coin'i şu adrese gönderir: ORION-1024("adres", "bitcoin101-protokol101-yakma-adresi-v1"). Bitcoin 1.01 adresi bir SLH-DSA açık anahtarının (64 bayt) hash'idir; bu adres 38 baytlık bir metnin hash'i olduğu için hiçbir gizli anahtar onu harcayamaz. Not: P101:<hesap>. Talep (protokol101 yak-talep <işlem kimliği>): tam Bitcoin 1.01 işlemi, blok yüksekliği ve Merkle dalı. Durum denetler: başlık en iyi dalda ve en az 100 onaylı (deneme ağında 3), işlem tam_kimlik ile Merkle kökü altında, not bir P101 hesabı, yakma adresine giden toplam > 0, aynı yakma daha önce talep edilmemiş. P101'in arzı her an Bitcoin 1.01'den yakılan toplamdan küçük ya da eşittir (cezalarda yakılan stake arzı ayrıca azaltır).

Köprü tek yönlüdür. P101'den Bitcoin 1.01'e dönüş, iki zinciri birbirine kilitleyen bir mekanizma (iki yönlü bağ) gerektirir ve bilerek yapılmadı; iki taraf arasında takas, aracısız HTLC ile yapılabilir (sonraki adımlar).

9. Bağışıklık sistemi

İhbarcı (kanıtı bloğa koyan öneren) kesintinin 1/16'sını alır; geri kalanı yakılır. Fide doğrulayıcının stake'i yoktur; cezası oy ağırlığının sıfırlanması ve kara listedir. Benzetimde: çift oy veren doğrulayıcı aynı blokta cezalandırıldı; 1/4'ü çevrimdışıyken kesinlik sürdü; yarısı çevrimdışıyken (2/3'ün altı) hiçbir blok kesinleşmedi: güvenlik canlılıktan önce gelir.

10. Fide doğrulayıcıları: ön kazımsız başlangıç

P101 Bitcoin 1.01 ile aynı anda açılır; o anda yakılmış coin, dolayısıyla stake yoktur. Ağı başlatmak için genesis bir fide doğrulayıcı kümesi içerir (protokol101 fide-kaydi her kurucu doğrulayıcının satırını üretir, genesis-olustur birleştirir). Fide ağırlığı para değildir: devredilemez, ödül almaz, harcanamaz ve ~90 günde doğrusal olarak sıfıra iner. Bu sürede yakma köprüsüyle gelen stake ağırlığı devralır. Fide doğrulayıcıları bu dönemde ağın güvenini taşır; sayıları ve kimlikleri lansmandan önce açıkça duyurulmalıdır. Deneme ağının dört fide doğrulayıcısının tohumları herkesçe bilinir ve yalnızca denemeler içindir.

11. Ağ

Bitcoin 1.01'in Faz 6 şifreli kanalı (X25519 + ML-KEM-1024, ChaCha20-Poly1305) aynen kullanılır; ağ işareti P101 / PLAB. Mesajlar: SELAM, BLOK_ISTE → BLOKLAR (ana daldan slot sırasıyla, 64'lük partiler), BLOK, OY, ISLEM. Tohumlar tohumlar_protokol.txt'de, parmak iziyle sabitlenebilir. Doğrulayıcı düğüm her imzadan önce yaprak sayacını diske yazar ve yeniden açılışta bir yaprak atlar (çökme sonrası yaprak tekrar kullanılmaz).

12. Dürüst sınırlar

• Kesinlik kuralının (onaylı blok + onaylı doğrudan çocuk, kilit kuralı) güvenlik kanıtı biçimsel olarak yazılmadı. Benzer kurallar (Casper FFG, iki zincirli HotStuff) literatürde vardır, ama bu uygulama bağımsız bir denetimden ve biçimsel doğrulamadan geçmeden ana ağda değer taşımamalıdır.
• Bütün doğrulayıcılar her slotta oy verir; oy imzaları toplulaştırılmaz. Doğrulayıcı sayısı yüzleri geçtiğinde blok boyu ve bant genişliği büyür (oy başına ~2,5 KB).
• Hesap durumu ve blok ağacı bellekte tutulur; her açılışta zincir baştan doğrulanır.
• Öneren seçimi epoch tohumuna bağlıdır; son açılımı yapan doğrulayıcı (RANDAO) tohumu sınırlı biçimde etkileyebilir. VDF bu sürümde yoktur.
• Lansmanın ilk ~90 gününde güven fide doğrulayıcılarındadır.
• WOTS+ anahtarı aynı nonce için iki kez imzalanırsa sızar; cüzdan bunu engeller, ama aynı cüzdan iki bilgisayarda aynı anda kullanılmamalıdır.
• Bitcoin 1.01 başlık zincirinin 100 bloktan derin bir yeniden düzenlenmesi (reorg) yakma taleplerini geçersiz kılmaz.

13. Sonraki adımlar

1. STARK ile imza toplulaştırma: bir bloktaki bütün WOTS+/XMSS imzalarının doğru olduğunu tek bir kanıtla göstermek (hash tabanlı, kuantuma dayanıklı). Bu, sütun başına ayrı komiteleri ve büyük doğrulayıcı kümelerini mümkün kılar.
2. Telomer kanıtı: her yeni bloğun, önceki kanıtı ve kendi geçişini doğrulayan özyinelemeli kanıtı; zincirin tamamı uçtan doğrulanır.
3. Kromozom parça hizmeti: tanıkların saklama süresinden sonra yalnızca düğüme düşen parçaların saklanması, erişilebilirlik meydan okumaları ve ödülleri (Bitcoin 1.01 arşiv ödüllerinin yeri de burası).
4. Genom Arşivi'nden anlık görüntüyle hızlı eşitleme; ML-DSA-65 şeması; P101 ↔ Bitcoin 1.01 HTLC takası; VDF.

14. Doğrulama

protokol101 test (43 kontrol): Nükleaz ve adresler; WOTS+ ve XMSS; Sparse Merkle (sıra bağımsızlığı, üyelik ve yokluk kanıtı, silme); Reed-Solomon (rastgele 8 parçadan geri kurma); 4 doğrulayıcıyla 40 slot (her slotta blok, kesinlik 2 slot geride); XMSS ön-rotasyonu (150 slot); Bitcoin 1.01 başlıklarının durumda doğrulanması ve yakma talebi; sütunlar arası makbuz; kovalent bağ ve eski anahtarın reddi; stake ile yeni doğrulayıcı; çift oy cezası; çevrimdışı sızıntısı ve çıkarılma; 2/3'ün altında kesinliğin durması; çatal ve kesinlik koruması. Ağ: dört doğrulayıcı düğüm şifreli kanalda her saniye blok üretti, kesinlik ucun iki slot gerisinden izledi; deneme ağında Bitcoin 1.01'de yakılan 10 coin protokolde talep edildi, 10 P101 basıldı ve iki WOTS+ transferi (anahtar #0 ve #1) işlendi. protokol101 simule farklı senaryoları (--kotu, --cevrimdisi) tek süreçte çalıştırır.