Yumuşak çatallanma

Bitcoin'in bugüne kadar gerçekten devreye aldığı her yükseltme bu şekilde çalışır. Kuralları daha sıkı hale getirmek, eski bir düğümün yeni blokları hâlâ kabul etmesi anlamına gelir, çünkü bu bloklar düğümün bildiği kuralların hiçbirini ihlal etmez. Nisan 2012 ile Kasım 2021 arasındaki soft fork'lar Bitcoin'e script hash adreslerini, zaman kilitlerini, SegWit'i ve Taproot'u kazandırdı ve bunlardan hiçbiri tek bir cüzdanı bile ortada bırakmadı.

Nasıl çalışır

Bir soft fork geçerli bloklar kümesini daraltır, böylece yükseltilmiş ağın ürettiği her şey önceki kural kitabına göre zaten geçerliydi.

Bunu mümkün kılan hile, Bitcoin'in script dilinin kasıtlı olarak kapılar açık bırakmış olmasıdır. On opcode, hiçbir şey yapmadan başarılı olan işlevsiz komutlar (no-op) olarak tanımlandı ve kimsenin henüz tanımlamadığı bir türdeki çıktılar, onları karşılayabilen herkes tarafından harcanabilir sayıldı. Bir soft fork bu kapılardan birinden geçer: eski düğümlerin hiçbir itiraz etmeden geçirdiği bir şeyi alır ve ona gerçek bir koşul bağlar. OP_NOP2 Aralık 2015'te OP_CHECKLOCKTIMEVERIFY oldu ve OP_NOP3 Temmuz 2016'da OP_CHECKSEQUENCEVERIFY oldu; 2014'ten kalan bir düğüm için ikisi de hâlâ geçen bir script içinde işlevsiz komuttur.

Bunun sonucu, kimin ne yaptığının bölünmesidir. Yükseltilmemiş düğümler bildikleri her kuralı doğrulamaya devam eder ve herkesle aynı zincirde kalır. Yükseltilmiş düğümler daha fazlasını doğrular. Gerçekten harekete geçmesi gereken grup madencilerdir, çünkü yükseltme yapmamış bir madenci, yükseltilmiş düğümlerin reddedeceği bir blok inşa edebilir, blok ödülünü kaybedebilir ve kendisini izleyen herkesi mahkûm bir dala sürükleyebilir.

Bu yüzden zor kısım kod değil, etkinleştirmedir. Hash gücünün çoğunluğu yeni kuralı uygularsa, kuralı ihlal eden bloklar yetim kalır ve sıkılaştırma kalıcı olur. Uygulamazsa, ağ soft fork'ın önlemek için tasarlandığı bir fay hattı boyunca bölünür. Bitcoin bu çoğunluğu sağlamanın birkaç yolunu denedi: blok sürümlerinin süper çoğunluk sayımı, BIP-9'un sürüm bitleri şeması, BIP-8'in zaman aşımı seçenekleri ve Taproot için kullanılan üç aylık Speedy Trial penceresi.

Bir soft fork, hard fork'un yapamadığı bir şekilde geri de alınabilir. Yeni kural, eski yazılımın hiçbir zaman talep etmediği bir kısıtlama olduğundan, ondan vazgeçmek herkesi tüm sürümlerin hâlâ geçerli saydığı bir zincire geri döndürür.

Bitcoin satın alırken bu neden önemli

Dürüst başlık şudur: Bitcoin yükseltmelerinin sıradan sahiplere hiçbir zaman hiçbir maliyet çıkarmamış olmasının nedeni soft fork'lardır.

Geçiş yok, son tarih yok, kaçırabileceğiniz bir duyuru yok. 2013'te oluşturulmuş bir P2PKH adresinde duran bitcoinler bugün aynı anahtarla ve aynı yazılımla harcanabilir ve o tarihten bu yana her soft fork bunu böyle tutmaya özen gösterdi. Bunu kullandığınız herhangi bir finansal platformla karşılaştırın: sistemin en az değer verilen özelliği budur.

Gerçekten fark ettiğiniz şey gecikmedir ve gecikme kenarlarda ortaya çıkar. Protokol yeni bir çıktı türünü etkinleştirir; cüzdanların onu varsayılan yapması bir yıl alır; borsaların bu tür adreslere para çekmenize izin vermesi daha da uzun sürer; bazıları hiç izin vermez. Bu sitenin incelediği borsalar arasında bech32 adreslerine gönderme desteği artık olağan, bech32m Taproot hedeflerine destek ise hâlâ düzensiz; bu, ilk günden itibaren konsensüs kuralı olan bir değişiklikte dört yıllık bir gecikme demek. Yeni bir özelliği gerçekten kullanıp kullanamayacağınıza karar veren şey protokol değil, bu boşluktur.

Bundan çıkan pratik kural basittir. Henüz yetişmemiş platformlar için daha eski bir türden bir adresi hazır bulundurun ve bir biçimin çalıştığını varsaymadan önce para çekme ekranını kontrol edin. Reddedilen bir para çekme adresi can sıkıcıdır; kabul edilip sonra başarısız olan bir adres için açılan destek talebi daha kötüdür.

Pay to script hash, multisig'i kullanılabilir kılan soft fork

P2SH, üzerinde çalışmaya değer en eski soft fork'tur, çünkü kalıbı küçük ölçekte gösterir.

Nisan 2012 öncesinde bir multisig düzenlemesine ödeme yapmak, ödeyenin script'in tamamını finanse ettiği çıktıya koyması gerektiği anlamına geliyordu. Bu, göndereni başkasının güvenlik politikasından sorumlu hale getiriyor, devasa çıktılar üretiyor ve basılı ya da sözlü bir adresi imkansız kılıyordu. BIP-16 tüm bunları script'in 20 baytlık bir hash'iyle değiştirdi ve bunu 3 rakamıyla başlayan bir adrese sardı.

Eski kuralları çalıştıran bir düğüm için çıktı script'i, harcayan kişi eşleşen veriyi yığına koyduğunda başarılı olan bir hash karşılaştırmasıdır. Yeni kuralları çalıştıran bir düğüm için yığına konan bu veri ardından bir script olarak yürütülür ve kendisinin de karşılanması gerekir. Yeni kural kesinlikle daha güçlüdür, dolayısıyla eski düğümler geçerli her yeni harcamayı kabul eder; soft fork'un tanımı budur.

Etkinleştirme, o günden beri tekrarlanan bir şekilde dağınıktı. Rakip bir öneri olan BIP-17 geliştirici görüşlerini böldü; son tarih 1 Şubat'tan 1 Nisan 2012'ye kaydı; madenciler de çıkardıkları bloklara "/P2SH/" dizesini yazarak desteklerini bildirdi. Var olan 3 rakamıyla başlayan neredeyse her adres, borsaların para yatırma için verdiği adresler dahil, o tartışmadan türer.

Soft fork vs BIP

Bir BIP bir belgedir; bir soft fork düğümlerin uyguladığı bir kuraldır. BIP-341, herkesin yazabileceği, GitHub'da bir depodaki metin dosyasıdır; Taproot ise 14 Kasım 2021'de 709.632 numaralı blokta konsensüs kuralı haline gelen şeydir. Bu ayrım önemlidir, çünkü BIP'lerin çoğu hiç etkinleşmez, aralarında BIP-17 ve covenant önerileri de vardır, ve tek bir soft fork sıklıkla aynı anda birkaç belgeyi kapsar, SegWit'in BIP-141, BIP-143, BIP-144 ve BIP-147 boyunca yaptığı gibi. Etkinleşmiş bir kuralı kastederken bir BIP numarası söylemek sohbette zararsızdır, düğümünüzün gerçekte neyi uyguladığını anlamaya çalışırken ise yanıltıcıdır.