Dört yıldır ilk kez Bitcoin "kullanıcı liderliğinde bir Soft Fork" ile karşılaşabilir mi?

Bitcoin temel topluluğu, Bitcoin altyapı yazılımındaki değişiklikleri teşvik etmeye başladı, bu dört yıldan fazla bir süredir nadir bir durum.

Yazar: GaryMa Wu, blok zincirini söylüyor

Blockspace’a göre, Bitcoin taban topluluğu, Bitcoin’in temel yazılımında değişiklikler yapmaya başlamıştır, bu, dört yıldan fazla bir süredir nadir görülen bir durumdur (önceki önemli temel değişiklikler genellikle çekirdek geliştirici grubu tarafından yönlendirilmiştir).

Bu sefer tabanda destek bulan iki Bitcoin İyileştirme Önerisi (BIP) var, yani BIP-119 (CTV) ve BIP-348 (CSFS). Bu iki öneri, Bitcoin’in “sözleşmeler” (Covenants) işlevini gerçekleştirmesini sağlayacak yeni bir Bitcoin script yazım yöntemi öneriyor. Bu iki öneri, Bitcoin’in bir sonraki yumuşak çatalında uygulanabilir.

Bazı okuyucuların Bitcoin’in Covenants’ını ve bu özel BIP planlarıyla olan ilişkisini geçici olarak anlayamaması için, burada durumu netleştirelim:

Kısacası, Covenants Bitcoin ağı içerisindeki bir işlev kavramıdır ve metinde bahsedilen iki BIP, bu işlev kavramını gerçekleştirmek için farklı uygulama çözümleridir.

Bitcoin’in Covenants’ı nedir?

Tanım:

Covenants, Bitcoin protokolünde önerilen bir mekanizmadır ve işlemlerde koşullar veya sınırlamalar belirlemeye izin verir. Bu, Bitcoin’in nasıl harcanacağı veya transfer edileceğini tanımlar. Bu koşullar, birden fazla işlem üzerinden geçebilir ve gelecekteki harcama yöntemlerini kısıtlayarak Bitcoin’in script yeteneklerini artırır.

Amaç:

• Bitcoin’in akıllı sözleşme yeteneklerini artırarak daha karmaşık uygulamaları desteklemek (örneğin, krediler, merkeziyetsiz borsa, sigorta havuzları).
• Güvenliği artırmak, fonların çalınmasını veya yanlış kullanılmasını önlemek.
• Ağ performansını optimize etme, örneğin işlem ücretlerini azaltma veya gizliliği artırma.

Burada, Covenants’ın bir kavram olduğunu net bir şekilde anlayabiliyoruz. Bu yazıda bahsedilen BIP-119 (CTV) ve BIP-348 (CSFS), Covenants’ın bu işlev kavramının somut gerçekleştirimleridir.

Mevcut Durum:

Bitcoin ana ağı şu anda herhangi bir Covenants ile ilgili işlevi resmi olarak entegre etmiş değildir, ancak ilgili tartışmalar ve öneriler (örneğin BIP-119) yıllardır ilerlemektedir.

BIP 119：OP_CHECKTEMPLATEVERIFY (CTV)

Bir önerilen Bitcoin opcode’u, işlem çıktılarının bir “şablon” (Template) belirtmesine izin verir, bununla birlikte sonraki harcama işlemlerinin çıktılarının bu şablona uyması gerekir.

Önceki Bitcoin çekirdek katkıcısı Jeremy Rubin tarafından önerilen, beş yıldan fazla bir süredir var. Fonların yalnızca önceden tanımlanmış bir şekilde harcanmasını sınırlayarak “durum taşıma” işlevini gerçekleştirdi.

Uygulama senaryoları şunlardır:

• Toplu Ödemeler (Batch Payments) oluşturun, işlem ücretlerini azaltın. Merkeziyetsiz borsa (DEX) veya kredi protokolü inşa edin.
• Vaults (kasalar) oluşturun, fonları çalınmalardan koruyun.
• CTV, Covenants’ın hafif bir uygulamasıdır ve karmaşık mantıkla ilgilenmeden çıktı formatı kısıtlamalarına odaklanır.

BIP 348：OP_CHECKSIGFROMSTACK (CSFS)

Bir önerilen Bitcoin işlem kodu, bir imzanın herhangi bir mesaja (Message) geçerli olup olmadığını doğrulamasına izin verir, yalnızca mevcut işlemin hash’ine değil. Veri yığınından imza, kamu anahtarı ve mesaj alır, imzanın eşleşip eşleşmediğini kontrol eder.

2024 yılının Kasım ayında Jeremy Rubin ve Brandon Black tarafından resmi olarak önerilmiştir.

OP_CSFS, daha esnek Covenants’lar gerçekleştirmek için güçlü bir araçtır, çünkü işlem girdilerini “öz değerlendirme” (Introspection) yapma, yani imzalı işlemin tam içeriğini veya durumunu kontrol etme imkanı tanır.

Spesifik Uygulamalar:

• Covenants gerçekleştirme: OP_CSFS, fonların yalnızca belirli kurallara göre harcanmasını sağlamak için karmaşık koşul mantıkları oluşturmak üzere kullanılabilir. Örneğin, doğrulayıcılar, işlem girdilerinin önceden belirlenmiş şablonlara veya sınırlara uyup uymadığını kontrol edebilir.
• Güvenlik artırımı: Vaults ve merkeziyetsiz protokolleri destekleyerek, imza doğrulaması ile hırsızlık veya yetkisiz harcamaları önler.
• Ölçeklenebilirlik: Diğer işlem kodları (örneğin OP_CAT) ile birleştirilerek daha karmaşık akıllı sözleşmeler oluşturulabilir.

Ve Bitcoin’in Covenants’larından ve BIP-119 (CTV) ile BIP-348 (CSFS) adlı iki öneriden bahsedildiğinde, kesinlikle OP_CAT’tan bahsetmemek olmaz.

BIP 347：OP_CAT

Tarih:

Erken dönem varlığı: OP_CAT, Bitcoin’in orijinal script dilinin bir parçasıdır ve Satoshi Nakamoto tarafından 2009 yılında Bitcoin’in lansmanı sırasında dahil edilmiştir. Başlangıçta script’in esnekliğini artırmak ve daha karmaşık mantığı desteklemek için tasarlanmıştır.

Kaldırma Nedeni (2010):

• OP_CAT 2010 yılında kaldırıldı (devre dışı bırakıldı), nedeni potansiyel güvenlik açıklarını ve kaynak kötüye kullanımını önlemektir.
• Spesifik sorun: Sınırlama olmadan, OP_CAT kötü niyetli kullanıcılar tarafından sonsuz uzunlukta veriler oluşturmak için kullanılabilir (özyinelemeli çağrılar aracılığıyla), bu da "Hizmet Reddi Saldırısı"na (DoS Attack) yol açar, çünkü Bitcoin düğümleri bu verileri işlemek zorundadır, bu da hesaplama ve depolama maliyetlerini artırır.
• O zaman Bitcoin betik dili basitleştirildi, en temel işlevleri korundu, protokolün hafifliği, güvenliği ve merkeziyetsizliği sağlandı.

Tanım ve İşlev:

OP_CAT, bir Bitcoin script dili (Script) işlem kodudur (Opcode). Bu, doğrudan bir Covenant uygulaması değildir, ancak karmaşık Covenant mantığını inşa etmek için potansiyel bir araçtır. Yukarıda bahsedilen iki işlem koduna kıyasla, OP_CAT daha genel bir kullanım sunar ve veri işlemleri için uygundur, ancak karmaşık işlevler gerçekleştirmek için diğer işlem kodlarıyla bir araya getirilmesi gerekir.

Durum:

Bitcoin topluluğu son yıllarda OP_CAT’ın geri dönüşünü yeniden tartışıyor, daha önce topluluk odaklı bir sembol olarak BIP-420 önerisi şeklinde ortaya çıkmıştı, ancak şu anda BIP-347 numarasıyla bitcoin/bips deposuna resmi olarak dahil edildi.

Gelişmeler nasıl

Coindesk’in haberine göre, son birkaç hafta içinde birçok Batılı Bitcoin geliştiricisi Twitter’da CTV ve CSFS’ye desteklerini ifade etti - bu, şüphesiz ki sosyal medya çevresinde, bazı Bitcoin topluluklarının bu değişiklikleri kabul etme yönünde ilerlediğini gösteren güçlü bir sinyal.

Ayrıca, geliştiriciler genel olarak bu iki teklifin tanımının “dar” olduğunu düşünüyor. Sade bir dille ifade etmek gerekirse, bu, etkinleştirildiğinde kullanıcılar tarafından yanlışlıkla kötüye kullanılma olasılığının düşük olduğu anlamına geliyor. Bitcoin geliştirici topluluğu, Bitcoin üzerindeki değişikliklere her zaman temkinli bir yaklaşım sergilemiştir. Örneğin, BIP 119 neredeyse beş yıldır askıya alınmış olmasına rağmen, kısa bir süre önce CTV, aşırı radikal olarak değerlendirilmiş ve etkinleştirilmesi uygun görülmemiştir.

İki teklifin ortak sponsorları Jeremy Rubin, CTV’yi tanıtmak için daha önce yürüttükleri kampanyalardan, özellikle de Adam Back ve Jimmy Song gibi büyük takipçi kitlesine sahip Bitcoin influencer’larından gelen tepkilerle karşı karşıya kaldı. Eleştiriler sonunda Bitcoin topluluğu içinde yaygın bir hoşnutsuzluğa dönüştü ve Rubin’i sonunda Bitcoin alanından çekilmeye zorladı.

Peki, bu değişimi ne tetikledi? Son zamanlarda OP_CAT opcode’unun desteklenmesi, Bitcoin önerilerinin “kabul edilebilir” olarak düşünülen kapsamını genişletmiş gibi görünüyor ve CTV ile CSFS’i nispeten “korumacı” seçenekler olarak çerçevelemiştir. Dikkate değer bir şekilde, OP_CAT’ı destekleyen çoğu kişi aynı zamanda BIP 119 ve BIP 348’i (ve diğer çoğu öneriyi) de destekliyor.

Sonrasında ne bekleyebiliriz? Öncelikle, tartışmalar devam edecektir. Geliştiricilerin bu önerileri, Nisan ayında yapılması planlanan OPNEXT, Temmuz’daki BTC++ ve Ekim’deki TABConf gibi birkaç teknik toplantıda daha fazla tartışması bekleniyor. Geliştiriciler ön anlaşmaya vardığında, yazılım çatallamasının gerçek aktivasyonu madencilere, topluluğa ve yatırımcılara nihai onay için devredilecektir.

BIP’lerin toplulukta tartışma ilerlemesini / yumuşak hard fork sürecini nasıl takip edebilirim?

Cevap çok zor!

Bitcoin’in teknik topluluğu genellikle bu öneriler üzerinde derinlemesine tartışmalar yapar. Ancak bu, görünüşte karmaşık ve döngüsel bir tartışma sürecidir.

Basitçe söylemek gerekirse, Bitcoin soft fork süreci, geliştiriciler, emanetçiler, yatırımcılar ve madenciler dahil olmak üzere Bitcoin’e dahil olan tüm paydaşların destek seviyesinin kabaca bir tahminini gerektirir. En sezgisel destek göstergeleri genellikle madencilerden gelir, çünkü madenciliği yapılan bloklarda sinyal vererek kod tabanındaki değişiklikleri onayladıklarını bildirebilirler. Tipik olarak, Bitcoin Core, güncelleme aktivasyon için kilitlenmeden önce belirli bir süre boyunca destek sinyali vermek için blokların %95’ine ihtiyaç duyar.

Ancak, “kapsamlı destek” ifadesinin nasıl tanımlanması gerektiği konusunda kesin bir görüş birliği yok; Bitcoin konsensüsü sürekli evrim halindedir. Madencilerin önemli sinyal sağlayıcıları olmasının nedeni, Bitcoin ağı içinde “sayılabilir” bir varlık olmalarıdır. Diğer bir deyişle, Bitcoin’in merkeziyetsiz yapısı nedeniyle genel konsensüsü “gözle görülebilir” bir açıdan ölçmek zordur.

Ancak, Bitcoin NFT’leri ile tanınan bir geliştirici şirket olan Taproot Wizards, OP_CAT örneği üzerinden bir akış diyagramı ile Bitcoin’in sert çatallaşma sürecinin uzun ve karmaşık sürecini ortaya koyuyor. İlgilenen okuyucular kendileri inceleyebilir, burada biz kısaca özetlemeye çalışalım:

BIP’lerin Teklif Yaşam Döngüsü | Bitcoin Yumuşak Çatallanmasının Uzun ve Karmaşık Süreci

1. Teklif başlangıçta Bitcoin geliştiricilerinin e-posta listesinde önerildi ve tartışıldı.

2. Daha büyük bir topluluk kapsamına tartışmaya girildi, öneri işlevinin avantajları ve dezavantajları üzerine uzun süreli bir tartışma çıkmazına girildi, eğer daha fazla ilerleme kaydedilemezse, burada durulacaktır.

3. Temel topluluklar, Github’da öneriler için BIP taslağı yazmaktadır.

4. Geliştiriciler ilgili kodu uygulamaya koyar, uzun süreli denetim hataları olmadan devam edemezler.

5. Bitcoin deposu BIP editörleri tarafından incelendikten ve topluluk tarafından ön onay aldıktan sonra, resmi BIP numarası tahsis edilir.

6. Signet test ağına giriş. Signet, geliştiricilerin ana ağı etkilemeden yeni özellikler veya kod değişikliklerini denemelerine olanak tanıyan bir Bitcoin test ağıdır. (Muhtemelen çoğu yeni özellik bu aşamada kalıcı olarak askıya alınmıştır.)

7. Liquid yan zincirine deney yapmak için girebilir.

8. Bitcoin Core’a PR gönderin.

9. Bitcoin çekirdek kod incelemesi ve öneri birleştirme sürecine girmek, yüksek derecede belirsizdir. Önerinin birleştirme aşamasına geçme şansı, çoğu karşıt görüşten kaçınıldığında ve teknik gereksinimler (ciddi hata yok) karşılandığında vardır; ana geliştiricilerin (örneğin Pieter Wuille) görüşleri genellikle son derece önemlidir, kabul edilmesi veya reddedilmesi önerinin kaderini büyük ölçüde etkileyebilir.

10. Eğer kod incelemesi sorun yoksa, Bitcoin deposu yöneticisinin PR’yi ana projeye birleştirmesini bekleyin. Şu anda beş yönetici var: Michael Ford (fanquake), Hennadii Stepanov (hebasto), Andrew Chow (achow101), Gloria Zhao (glozow), Ryan Ofsky (ryanofsky).

11. Devam eden potansiyel tartışmalar ve anlaşmazlıklar, Bitcoin geliştiricileri ve madenciler gibi farklı gruplar arasında.

12. Aktivasyon mekanizmasını seçin:

a. Madenci Liderliğindeki Yumuşak Çatallanma (MASF): Madenciler tarafından sinyal (genellikle %95 eşik) ile yeni kuralların aktif hale getirilmesi, örneğin BIP-9 veya BIP-8’in varsayılan modu. Daha istikrarlı, ancak geniş bir konsensüs ve testlerin koordinasyonunu gerektirir, bu nedenle daha uzun zaman alır;

b. Kullanıcı liderliğinde yazılım çatallanması (UASF): Düğüm işletmecileri (kullanıcılar) tarafından yeni kuralların (örneğin BIP-8’in “Lockinontimeout: True” olması) zorla etkinleştirilmesi, madenci direncinin aşılması, potansiyel zincir çatallanma riski ve topluluk bölünmesi ile sonuçlanabilir.

Sonuç

Wu daha önce Bitcoin.org alan adı yöneticisi Cobra’nın, 2025 yılında Bitcoin ağına, Bitcoin Core dışındaki anonim geliştiriciler tarafından başlatılabilecek bir kullanıcı odaklı yumuşak çatallanma (UASF) konusunda uyardığını bildirdi; aslında bu, makalede bahsedilen BIP 119’un potansiyel değişikliklerini ifade ediyor. Cobra, bu iyileştirmelerin, taban topluluğu tarafından yönlendirilen ve Bitcoin Core olmayan geliştiriciler tarafından desteklenen “sabit görüşlü” ve “iyileştirme yanlısı” arasında bir ayrılık yaratabileceğini düşünüyor.

Bilgiye göre, UASF (Kullanıcı Yönetimli Yumuşak Çatallama), Bitcoin kullanıcıları tarafından başlatılan bir protokol güncelleme yöntemidir. Protokol güncellemelerini zorunlu kılmak için düğüm yazılımını güncelleyerek, madenciler veya diğer taraflar desteklemediğinde bile uygulanır, bu da zincir çatallama riski anlamına gelir. Elbette şu anda endişelenmeye gerek yok, çünkü hâlâ pek çok belirsizlik var. Örneğin, gelecekteki yumuşak çatallama yalnızca CTV ve CSFS’yi mi içerecek? Bu işlem kodlarıyla sıkça tartışılan OP_CAT da dikkate alınacak mı? Yumuşak çatallamanın gerçek etkinleştirme süreci nasıl işleyecek? Diğer paydaşlar (örneğin Bitcoin madencileri) buna yeterince önem verecek mi?

Sonuçta, BIP’lerin konsensüsü yeterince büyük olduğu sürece, taban toplulukları tarafından desteklenen öneriler, madenci liderliğindeki yumuşak çatallama (MASF) biçiminde gerçekleştirilebilir. Ayrıca, UASF için tarihsel olarak başarılı örnekler de bulunmaktadır. UASF, 2017’deki SegWit yükseltmesinde kritik bir rol oynadı; kullanıcılar yumuşak çatallamayı başarıyla destekledi, sert çatallanmayı önledi ve Bitcoin’in ölçeklenmesini teşvik etti.

Bağlantı referansı: