Partnered With:

Bitcoin, dört yılın ardından ilk kez "kullanıcı liderliğinde yumuşak çatallanma" yaşayabilir mi?

Bu makaleyi okumak için 21 Dakika

BIP-119 (CTV) ve BIP-348 (CSFS), Bitcoin'in "sözleşme" işlevini yerine getirmesini sağlayacak Bitcoin betiklerinin yazılması için yeni yollar öneriyor.

Orijinal başlık: "Bitcoin, dört yılın ardından ilk kez 'kullanıcı liderliğinde yumuşak çatallanma'ya öncülük edebilir mi?" 》

Orijinal yazar: GaryMa, Wu Blockchain diyor

Blockspace'e göre, Bitcoin'in taban topluluğu, Bitcoin'in temel yazılımında değişiklikleri teşvik etmeye başlıyor; bu, dört yıldan uzun bir süredir nadir görülen bir olay (daha önce, temeldeki büyük değişiklikler çekirdek geliştirici grubu tarafından yönlendiriliyordu).

Bu sefer, iki Bitcoin Geliştirme Teklifi (BIP) için tabandan destek ortaya çıkıyor: BIP-119 (CTV) ve BIP-348 (CSFS). Bu iki öneri, Bitcoin'in "Antlaşmalar" işlevini yerine getirmesini sağlayacak Bitcoin betiklerinin yazılması için yeni yollar öneriyor. Her iki öneri de bir sonraki Bitcoin soft fork'unda uygulanabilir.

Bazı okuyucuların Bitcoin'in Covenants'ı ile bu özel BIP çözümleri arasındaki ilişkiyi geçici olarak anlayamamasını önlemek için, bunu burada açıklığa kavuşturalım:

Basitçe ifade etmek gerekirse, Covenants, Bitcoin ağındaki işlevsel bir kavramdır ve makalede belirtilen iki BIP, bu işlevsel kavramı gerçekleştirmek için farklı uygulama çözümleridir.

Bitcoin Sözleşmeleri Nelerdir?

Tanım:

Sözleşmeler, Bitcoin protokolünde önerilen, Bitcoin'in nasıl harcanabileceğini veya transfer edilebileceğini belirleyen, işlemlerde koşul veya kısıtlamaların belirlenmesine izin veren bir mekanizmadır. Bu koşullar birden fazla işlemi kapsayabilir, gelecekteki harcamaların nasıl gerçekleşebileceğini kısıtlayabilir ve böylece Bitcoin'in komut dosyası oluşturma yeteneklerini artırabilir.

İşlev:

· Bitcoin'in akıllı sözleşme yeteneklerini geliştirin ve daha karmaşık uygulamaları (krediler, merkezi olmayan ticaret platformları ve kasalar gibi) destekleyin.

· Fonların çalınmasını veya kötüye kullanılmasını önlemek için geliştirilmiş güvenlik.

· İşlem ücretlerini azaltmak veya gizliliği artırmak gibi ağ performansını optimize edin.

Burada Covenants'ın bir kavram olduğunu ve bu makalede bahsedilen BIP-119 (CTV) ve BIP-348'in (CSFS) Covenants'ın işlevsel kavramının özel uygulamaları olduğunu kabaca anlayabiliriz.

Mevcut Durum:

Bitcoin ana ağına şu anda resmi olarak Covenants ile ilgili hiçbir özellik entegre edilmedi, ancak ilgili tartışmalar ve öneriler (BIP-119 gibi) yıllardır devam ediyor.

BIP 119: OP_CHECKTEMPLATEVERIFY (CTV)

İşlem çıktılarının, sonraki harcama işlemlerinin çıktısının şablonla eşleşmesini gerektiren bir "şablon" belirtmesine izin veren önerilen bir Bitcoin işlem kodu.

Eski Bitcoin Core katılımcısı Jeremy Rubin tarafından önerilen bu proje beş yıldan uzun süredir varlığını sürdürüyor. Fonların sadece önceden belirlenmiş şekillerde harcanmasını kısıtlayarak "devlet taşıyıcılığı" işlevini yerine getirir.

Uygulama senaryoları şunları içerir:

· İşlem ücretlerini azaltmak için toplu ödemeler oluşturun. Merkezi olmayan bir borsa (DEX) veya borç verme protokolü oluşturun.

· Paranızı hırsızlıktan korumak için Kasaları uygulayın.

· CTV, karmaşık mantığı içermeyen çıktı formatı kısıtlamalarına odaklanan Covenants'ın hafif bir uygulamasıdır.

BIP 348: OP_CHECKSIGFROMSTACK (CSFS)

Sadece geçerli işlemin karması için değil, herhangi bir mesaj için bir imzanın geçerli olduğunu doğrulamaya izin veren önerilen bir Bitcoin işlem kodu. Veri yığınından imzayı, açık anahtarı ve mesajı alır ve imzanın eşleşip eşleşmediğini kontrol eder.

Jeremy Rubin ve Brandon Black tarafından Kasım 2024'te resmen önerildi.

OP_CSFS, işlem girdilerinin "içe dönük incelenmesine", yani imzalanmış bir işlemin tüm içeriğinin veya durumunun incelenmesine olanak tanıdığı için daha esnek Sözleşmelerin uygulanması için güçlü bir araçtır.

Belirli uygulamalar:

· Covenants uygulaması: OP_CSFS, fonların yalnızca belirli kurallara göre harcanabilmesini sağlamak için karmaşık koşullu mantık oluşturmak amacıyla kullanılabilir. Örneğin, doğrulayıcılar işlem girdilerinin önceden belirlenmiş şablonlara veya kısıtlamalara uygun olup olmadığını kontrol edebilir.

· Güvenlik geliştirmeleri: İmza doğrulaması yoluyla hırsızlığı veya yetkisiz harcamaları önlemek için Kasalar ve merkezi olmayan protokoller için destek.

· Genişletilebilirlik: Diğer işlem kodlarıyla (OP_CAT gibi) birleştirildiğinde, daha karmaşık akıllı sözleşmeler oluşturulabilir.

Bitcoin'in Sözleşmeleri ve BIP-119 (CTV) BIP-348 (CSFS) tekliflerinden bahsedildiğinde OP_CAT kesinlikle vazgeçilmezdir.

BIP 347: OP_CAT

Tarihçe:

Erken Varoluş: OP_CAT, Bitcoin'in orijinal betik dilinin bir parçasıydı ve Satoshi Nakamoto tarafından Bitcoin 2009'da piyasaya sürüldüğünde dahil edildi. Başlangıçta betiklerin esnekliğini artırmak ve daha karmaşık mantığı desteklemek için tasarlanmıştı.

Kaldırma nedeni (2010):

· OP_CAT, olası güvenlik açıklarını ve kaynak kötüye kullanımını önlemek amacıyla 2010 yılında kaldırıldı (devre dışı bırakıldı).

· Belirli bir sorun: Eğer bir sınır yoksa, kötü niyetli kullanıcılar OP_CAT'ı sonsuz uzunlukta veri üretmek için kullanabilir (tekrarlayan çağrılar yoluyla) ve bu da Bitcoin düğümlerinin bu verileri işlemesi gerektiğinden bir "hizmet reddi saldırısına" (DoS Saldırısı) neden olabilir ve bu da hesaplama ve depolama yükünü artırır.

· O dönemde Bitcoin betik dili basitleştirilmiş, protokolün hafifliğini, güvenliğini ve merkeziyetsizliğini sağlamak için en temel işlevler korunmuştur.

Tanım ve işlev:

OP_CAT, Bitcoin Script'in bir opcode'udur. Doğrudan bir Covenant uygulaması değildir, ancak karmaşık Covenant mantığı oluşturmak için potansiyel bir araçtır. Yukarıdaki iki opkodla karşılaştırıldığında OP_CAT daha geneldir ve veri işlemleri için daha uygundur, ancak karmaşık işlevler elde etmek için diğer opkodlarla birleştirilmesi gerekir.

Mevcut durum:

Bitcoin topluluğu son yıllarda OP_CAT'ın dönüşünü yeniden tartıştı. Daha önce daha topluluk dostu bir sembolle BIP-420 önerisi biçiminde ortaya çıktı, ancak şimdi resmi olarak BIP-347 numarasıyla bitcoin/bips deposuna birleştirildi.

İlerleme ne durumda?

Coindesk'e göre, son birkaç haftada birçok Batılı Bitcoin geliştiricisi Twitter'da CTV ve CSFS'ye desteklerini dile getirdi; bu, en azından sosyal medya çevresinde, Bitcoin topluluğunun bir kısmının bu değişiklikleri kabul etmeye doğru ilerlediğinin şüphesiz güçlü bir işareti.

Ayrıca geliştiriciler genellikle bu iki önerinin tanımlarının nispeten "dar" olduğuna inanmaktadır. Basitçe açıklamak gerekirse, bu, bir kez etkinleştirildiğinde, kullanıcının yanlışlıkla kötüye kullanma olasılığının daha düşük olduğu anlamına gelir. Bitcoin geliştirici topluluğu tarihsel olarak Bitcoin'deki değişikliklere karşı temkinli davrandı. Örneğin, BIP 119 yaklaşık beş yıldır uykuda olmasına rağmen, CTV'nin aktif hale getirilmesi için çok radikal olduğu düşünülüyordu.

Her iki teklifin de eş sponsoru olan Jeremy Rubin'in CTV'yi tanıtmak için yürüttüğü önceki kampanyalar, özellikle Adam Back ve Jimmy Song gibi büyük takipçi kitlesine sahip bazı Bitcoin etkili isimlerinin muhalefetiyle karşı karşıya kalmıştı. Eleştiriler sonunda Bitcoin topluluğunda yaygın bir hoşnutsuzluğa dönüştü ve Rubin'in sonunda Bitcoin alanından çekilmesine neden oldu.

Peki, bu değişikliğe tam olarak ne sebep oldu? OP_CAT opcode'unun son zamanlardaki savunuculuğu, CTV ve CSFS'yi nispeten "muhafazakar" seçenekler olarak çerçeveleyerek "kabul edilebilir" kabul edilen Bitcoin önerilerinin yelpazesini genişletmiş gibi görünüyor. OP_CAT'ı destekleyen insanların çoğunun aynı zamanda BIP 119 ve BIP 348'i (ve diğer birçok öneriyi) de desteklediğini belirtmekte fayda var.

Bundan sonra ne bekleyebiliriz? Öncelikle tartışmaya devam edelim. Geliştiricilerin, Nisan ayında düzenlenmesi planlanan OPNEXT, Temmuz ayında BTC++ ve Ekim ayında TABConf gibi çeşitli teknik konferanslarda önerileri daha ayrıntılı incelemeleri bekleniyor. Geliştiriciler ön bir fikir birliğine vardıklarında, yumuşak çatallanmanın gerçek aktivasyonu nihai onay için madencilere, topluluğa ve yatırımcılara devredilecek.

Topluluk/yumuşak çatallanma sürecinde BIP'lerin tartışma ilerleyişi nasıl takip edilir?

Cevap çok zor!

Bitcoin teknik topluluğu genellikle bu öneriler üzerinde derinlemesine tartışmalar yapar. Fakat bu, görünüşte belirsiz ve kısır bir tartışma sürecidir.

Kısacası, Bitcoin yumuşak çatallanması süreci, geliştiriciler, saklayıcılar, yatırımcılar ve madenciler dahil olmak üzere çeşitli Bitcoin paydaşlarının destek seviyesinin kabaca tahmin edilmesini gerektirir. Desteğin en doğrudan göstergeleri genellikle madencilerden gelir; çünkü madencilerin madencilik yaptıkları bloklarda gönderdikleri sinyallerle kod tabanındaki değişiklikleri onayladıklarını gösterebilirler. Bitcoin Core'un, bir güncellemeyi etkinleştirmek için kilitlemesinden önce, blokların %95'inin belirli bir süre boyunca destek sinyali vermesi gerekir.

Ancak, "geniş destek"in nasıl tanımlanacağı konusunda bir fikir birliği yoktur ve Bitcoin fikir birliği sürekli olarak gelişmektedir. Madenciler, Bitcoin ağında "sayılabilir" bir varlık olmaları nedeniyle önemli sinyal sağlayıcılardır. Başka bir deyişle, Bitcoin'in merkezi olmayan yapısı nedeniyle genel mutabakatı "görünür" bir bakış açısıyla ölçmek zordur.

Ancak, Bitcoin NFT'siyle ünlü bir geliştirme şirketi olan Taproot Wizards, Bitcoin yumuşak çatallanmasının uzun ve karmaşık sürecini bir akış şeması biçiminde ortaya koymak için OP_CAT'ı bir örnek olarak kullanır. İlgilenen okuyucular bunu https://www.quantumcats.xyz/bip-land adresinden kendileri inceleyebilirler. Burada özetlemeye çalışıyoruz:

BIP Teklif Yaşam Döngüsü | Bitcoin yumuşak çatallanmasının uzun ve karmaşık süreci

1. Teklif ilk olarak Bitcoin geliştirici posta listesinde önerildi ve tartışıldı.

2. Daha geniş bir topluluk çapında tartışmaya girerek, önerilen işlevin artıları ve eksileri hakkında uzun vadeli bir tartışma ikilemine girdi. Daha fazla ilerletilemezse, burada duracaktır.

3. Taban topluluğu, Github'da teklif için bir BIP taslağı yazar.

4. Geliştiriciler ilgili kodları uygulamaya başlar ve ancak uzun vadeli denetim hataları yoksa ilerleyebilirler.

5. Bitcoin Deposu BIP editörü tarafından incelendikten ve topluluk tarafından ilk onay alındıktan sonra resmi bir BIP numarası atanır.

6. Signet test ağına girin. Signet, geliştiricilerin ana ağı etkilemeden yeni özellikler veya kod değişiklikleri denemelerine olanak tanıyan bir Bitcoin test ağıdır. (Belki de yeni özelliklerin çoğu bu aşamada kalıcı olarak rafa kaldırılacak)

7. Deneyler için Sıvı yan zincirine girmek mümkündür.

8. Bitcoin Core'a PR gönderin.

9. Son derece belirsiz olan Bitcoin çekirdek kod inceleme ve teklif birleştirme sürecine giriliyor. Bir teklif ancak çoğu itirazı ortadan kaldırdığında ve teknik gereksinimleri karşıladığında (ciddi bir hata olmadığında) birleştirme aşamasına girme fırsatına sahip olur; kilit geliştiricilerin (Pieter Wuille gibi) görüşleri çoğu zaman kritik öneme sahiptir ve bunların onaylanması veya reddedilmesi teklifin kaderini büyük ölçüde etkiler.

10. Kod incelemesi tamam ise, Bitcoin deposu bakıcısının PR'yi ana projeye birleştirmesini bekleyin. Şu anda beş bakıcı var: Michael Ford (fanquake), Hennadii Stepanov (hebasto), Andrew Chow (achow 101), Gloria Zhao (glozow), Ryan Ofsky (ryanofsky).

11. Bitcoin geliştiricileri ve madenciler gibi farklı gruplar arasında potansiyel anlaşmazlıklar ve tartışmalar olmaya devam ediyor.

12. Bir aktivasyon mekanizması seçin:

a. Madenci liderliğindeki Yumuşak Çatal (MASF): Yeni kurallar, madenciler tarafından BIP-9 veya BIP-8'in varsayılan modu gibi sinyaller (genellikle %95 eşik) aracılığıyla etkinleştirilir. Nispeten istikrarlıdır, ancak geniş bir fikir birliğinin ve testlerin koordinasyonunu gerektirir, bu nedenle daha uzun sürecektir;

b. Kullanıcı tarafından başlatılan yumuşak çatallanma (UASF): Düğüm operatörleri (kullanıcılar) madenci direncini aşmak için yeni kuralları (örneğin BIP-8'in "Lockinontimeout: True") zorla etkinleştirir; bu da potansiyel zincir çatallanması riskleri ve topluluk anlaşmazlıkları anlamına gelir.

Sonuç

Wu, daha önce Bitcoin.org alan adının bakıcısı olan Cobra'nın, Bitcoin ağının 2025 yılında Bitcoin çekirdeğinin dışındaki anonim geliştiriciler tarafından başlatılan kullanıcı odaklı yumuşak çatallanmaya (UASF) ev sahipliği yapabileceği konusunda uyardığının bildirildiğini ve bunun aslında bu makalede bahsedilen BIP 119'daki potansiyel değişiklikler olduğunu söyledi. Cobra, bu iyileştirmelerin tabandan gelen topluluk tarafından yönlendirilen ve Bitcoin dışındaki çekirdek geliştiriciler tarafından yönlendirilen "sabit görüşlüler" ve "iyileştiriciler" arasında bir ayrılığa yol açabileceğine inanıyor.

UASF'nin (Kullanıcı Tarafından Etkinleştirilen Yumuşak Çatallanma), Bitcoin kullanıcıları tarafından başlatılan, madenciler veya diğer taraflar desteklemese bile düğüm yazılımlarını yükselterek protokol güncellemelerini zorlayan bir protokol yükseltme yöntemi olduğu ve bu nedenle de zincir çatallanması riski taşıdığı anlaşılmaktadır. Elbette şu an çok fazla telaşlanmaya gerek yok, sonuçta hâlâ çözülmemiş çok şey var. Örneğin, gelecekteki bir soft fork yalnızca CTV ve CSFS'yi mi içerecek? Bu opkod kümesiyle birlikte sıkça tartışılan OP_CAT dikkate alınacak mı? Yumuşak çatallanmanın gerçek aktivasyon süreci nasıl işleyecek? Diğer paydaşlar (örneğin Bitcoin madencileri) bunu yeterince ciddiye alacak mı?

Sonuç olarak, BIP'lerin fikir birliği yeterince büyük olduğu sürece, tabandan gelen topluluk tarafından yönlendirilen öneriler, madenci liderliğindeki yumuşak çatallanmalar (MASF) biçiminde de gerçekleştirilebilir. Ve hatta UASF'nin tarihinde başarı hikayeleri de var. UASF, 2017'deki SegWit güncellemesinde önemli bir rol oynadı ve kullanıcılar yumuşak çatallanmayı başarıyla destekledi, sert çatallanmadan kaçındı ve Bitcoin genişlemesini teşvik etti.