özet

1. Giriş

Bitcoin protokolünde yapılacak değişiklikler, protokol geliştiricileri, tam düğümler, son kullanıcılar ve madenciler dahil ancak bunlarla sınırlı olmamak üzere çok sayıda paydaş arasında tartışma ve iş birliği gerektirir. Protokol yükseltmelerini elde etmek için mutabakat süreci karmaşık ve tartışmalıdır. Örneğin, 2015-2017 yıllarında yaşanan "blok boyutu savaşı" Bitcoin topluluğunu böldü; bir taraf blok boyutunu ayarlamak isterken, diğeri buna karşı çıktı. Yıllar süren tartışmalar, blok zincirinde kalıcı bir bölünmeye ve Bitcoin'in çatallanmış bir versiyonu olan Bitcoin Cash adlı yeni bir kripto paranın yaratılmasına yol açtı.

Protokol değişiklikleri konusunda fikir birliğine varmanın zorluğu göz önüne alındığında, Bitcoin'de büyük çaplı güncellemeler nadirdir. Bitcoin protokol geliştiricilerinin, tartışmalı güncellemeleri reddetme ve daha geniş Bitcoin topluluğunun desteğini alan güncellemeleri uygulamaya koyma konusunda uzun bir geçmişi var. Bu, geliştiricilerin öngörülebilirliği, ağ sadakatini ve geriye dönük uyumluluğu teşvik etmek amacıyla Bitcoin geliştirmeye yönelik muhafazakar bir yaklaşım benimseme konusundaki kararlılıklarını vurgulamaktadır.

Bitcoin'de fikir birliği değişiklikleri nispeten nadir olmasına rağmen, Bitcoin geliştiricileri Bitcoin Script ve ağ parametrelerini optimize etmeye açık olduklarını gösterdiler. Blok boyutu tartışmalarından ortaya çıkan Segregated Witness (SegWit) yükseltmesi aslında blok boyutu sınırını artırarak bir bloğa daha fazla işlemin dahil edilmesine olanak sağladı. SegWit ayrıca işlem verilerinin ölçü birimini bayttan sanal bayta (vbytes) değiştirerek işlem verilerinin formatını da optimize eder. İmza verilerinin tanık alanına taşınmasıyla birleştirilen bu değişim, bir Bitcoin bloğunun 4 milyona kadar ağırlık biriminde işlem verisi (yaklaşık 4 MB) içermesine olanak tanır. Bitcoin'in son soft forku, Tapscript adı verilen güncellenmiş bir betik dilinin tanıtıldığı 2021 Taproot yükseltmesiydi. Bitcoin Script'in bu yeni sürümü, yeni bir imza şeması (Schnorr imzaları) ve birden fazla açık anahtar ve imzayı tek bir imzalama anahtarında birleştiren geliştirilmiş anahtar toplama özelliğini içeriyor. Schnorr imzaları için anahtar toplama, birden fazla imza gerektiren işlem verilerinin miktarını azaltırken, Lightning Network'teki (Bitcoin'in temel katmanının üzerine inşa edilen Bitcoin'in en büyük P2P ödeme katmanı) işlemlerin gizliliğini artırır. SegWit ve Taproot'a dair bu kısa genel bakış, Bitcoin geliştiricilerinin Bitcoin'in konsensüsünde yapılacak değişiklikler konusunda temkinli olsalar da, bunun Bitcoin'in teknik özelliklerinin değişmeyeceği anlamına gelmediğini gösteriyor.

SegWit ve Taproot'tan sonra, Bitcoin geliştiricileri artık işlemlere ek akıllı sözleşme mantığı eklemek için Bitcoin'in işlem programlanabilirliğini artırmayı araştırıyor. Bitcoin akıllı sözleşmeleri, harcanmamış işlem çıktılarının (UTXO'lar) gelecekte nasıl harcanabileceğini sınırlama ve kontrol etme yeteneği olan harcama koşullarının kullanımını içerir. Daha karmaşık ve katı harcama kısıtlamalarına "sözleşmeler" ("kısıtlamalar" veya "sözleşmeler") denir. Bu makalede öncelikle Bitcoin Script'i inceleyeceğiz ve Bitcoin'in UTXO muhasebe modeliyle nasıl çalıştığını göreceğiz. Daha sonra, Bitcoin Script'i verimli işlem programlanabilirliğini sağlayan güçlü özellikler içerecek şekilde geliştirme potansiyeline sahip olan OP_CTV ve OP_CAT adlı iki bekleyen işlem kodunu analiz edeceğiz. Son olarak, makalede Bitcoin altyapısında (köprüler ve emanetler gibi) işlem programlanabilirliğinin önemi vurgulanmakta ve OP_CAT ve OP_CTV konusunda fikir birliğine varılması olasılığı ile bu işlem kodlarının bir sonraki yumuşak çatallanma yükseltmesine uygulanmasının yolu ele alınmaktadır.

2. Bitcoin betiği ve UTXO modeli

Bitcoin, işlemleri oluşturmak için "Bitcoin Script" adı verilen yerel bir betik dili kullanır. Bir komut dosyası, bir işlemin alıcısının gönderilen bitcoinleri nasıl harcayabileceğini tanımlayan bir dizi talimattan oluşur; buna "harcama koşulları" da denir. Bitcoin Script, komut fonksiyonları olarak çalışan 186 opkoddan oluşur. Bu işlem kodları, Bitcoin varlıklarının ağ üzerinde nasıl harcanabileceği ve transfer edilebileceğine ilişkin resmi kurallar oluşturmak için kullanılır. Örneğin, bir Pay-to-PubKey Hash işlemi, Bitcoin işlemlerinde harcama koşullarını uygulayan 4 işlem kodu içerir; burada Bitcoin'ler karma bir genel anahtara harcanır ve yalnızca harcayanla ilişkili doğru genel ve özel anahtarlar kullanılarak harcanabilir.

Bitcoin Script, girdi ve çıktıları kullanan Bitcoin'in Harcanmamış İşlem Çıktıları (UTXO modeli) için tasarlanmıştır. Her Bitcoin işlemi en az 1 girdi ve 1 çıktıdan oluşur, ancak çoğu basit işlem en az 1 girdi ve 2 çıktıdan oluşur (girdi tarafındaki BTC'nin bir kısmı işlemi finanse etmek için kullanılır, bir kısmı alıcıya gönderilir ve geri kalanı çıktı tarafında harcayana geri gönderilir). UTXO'lar henüz harcanmamış ve gelecekteki işlemlerde gönderilebilecek Bitcoin parçalarıdır. UTXO'lar bir işlemin girdisi olarak kullanıldığında artık çıktı olmaktan çıkarlar. Dolayısıyla kullanıcılar Bitcoin harcadıkça sürekli olarak UTXO'lar yaratılıp yok ediliyor. İşte UTXO modelinin basitleştirilmiş bir örneği:

*Eğer Alice'in cüzdanında 1 BTC değerinde bir UTXO varsa ve Bob'a 0,5 BTC gönderirse Alice'in girdisi 1 BTC olacaktır. *Çıktıları 0,49 BTC (Alice'e iade edilir) ve 0,5 BTC (Bob'a gönderilir) olacaktır. 0,01 BTC'lik fark, işlem ücreti olarak ödenen BTC'yi temsil eder (bu işlem ücreti ağ yoğunluğuna bağlı olarak değişecektir). *Bu işlemin sonunda Alice, kalan 0,49 BTC'sini temsil eden yeni bir UTXO setine sahip olacak. 1. adımda Alice, işlemin ilk girdisi olarak 1 BTC değerindeki UTXO'sunu kullanır ve UTXO'yu yok eder. 2. adımda Alice, 0,5 BTC ve 0,49 BTC değerinde iki yeni UTXO oluşturur, bunlardan biri kendisine para üstü olarak iade edilir ve diğeri de Bob'a ödenir. 3. adımda Alice'in artık 0,49 BTC değerinde yeni bir UTXO'su var. Alice'in Bob'a 0,5 BTC ödemesi gerekiyorsa, Alice 1. adımda toplam 0,5 BTC tutarında birden fazla UTXO kullanabilir; eğer girdi UTXO'larından hiçbiri alıcıya tam olarak verilmemişse, Alice artık 1 yerine 2 yeni UTXO alabilir. UTXO modeli, Bitcoin ağının temel bir özelliğidir ve işlem işleme ve doğrulamada hayati bir rol oynar.

Yukarıdaki UTXO örneği tamamen Bitcoin Script kullanılarak oluşturulmuştur. Her UTXO, UTXO'nun harcanabileceği bir dizi koşulu içeren bir kilitleme betiği içerir. Bir kullanıcı, ilgili genel anahtarla ilişkili doğru özel anahtar imzasını sağlayarak bir girdinin (harcanan UTXO) sahipliğini kanıtladığında, UTXO'nun kilitleme betiğinin kilidi açılır. Bu bilgiye "script imzası" adı verilir ve girdiye doğru script imzası eklendiğinde harcama koşulları sağlanır ve bitcoin harcanabilir. Alice ve Bob'un UTXO örneğine geri dönersek, 1. adımda Alice, UTXO'sunu harcamak için girdisinde özel anahtar imzasını sağlamalıdır. Daha sonra Bob'un yeni aldığı 0,5 BTC'yi harcamadan önce aynı bilgileri sağlaması gerekiyor.

Bitcoin'in betik dili, birden fazla imza gerektirme veya bitcoin'lerin belirli bir blok yüksekliğinde kilidini açma gibi daha karmaşık harcama koşullarını içerebilir. Ancak Bitcoin Script genel amaçlı değildir ve Ethereum'un yerel programlama dili Solidity'nin ifade gücünden yoksundur. Bu nedenle Bitcoin Script kullanarak köprü ve saklama çözümleri için akıllı sözleşme mantığını programlamak son derece zordur.

3. Bitcoin Script'in 2025'e Kadar Karşılaşacağı Engeller

Bitcoin Script, son 16 yıldır kullanıcılar için kullanışlılığını ve çift harcama saldırılarına karşı dayanıklılığını kanıtlamış olsa da, betik dili, ifade gücü ve küresel durumu saklama yeteneği gibi genel amaçlı özelliklerden yoksundur. Bitcoin Script, büyük sayılar üzerinde çarpma ve aritmetik işlemleri yapamayan yığın tabanlı bir programlama dili olduğu için ifade edici değildir. Bitcoin Script yalnızca 32 bit boyutundaki değerler üzerinde önemsiz olmayan hesaplamalar gerçekleştirebilir. Bu nedenle Bitcoin Script, 32 bitten büyük yığın elemanlarını birbirinden izole eder. Bu 32 bitlik sınırlama, mevcut işlem kodu kümesinin işleyebileceğinden daha büyük betik boyutları gerektiren şifreleme işlevleri, çarpma ve bölme işlemlerini kullanan, hesaplama açısından yoğun komutları izole eder. Aritmetik ve çarpmayı birden fazla işlem kodu kullanarak taklit etmek mümkün olsa da, bunun için çok sayıda yığın elemanına ihtiyaç vardır ve Bitcoin Script'in yığın boyutu sınırı 1000 elemandır. Bu nedenle, mevcut operasyonların ötesine geçen işlem çıktıları üzerinde karmaşık harcama koşulları yaratmak zordur.

Bitcoin Script'in en büyük kısıtlaması, dilin yalnızca harcayan tarafından sağlanan girdileri okuyabilmesi nedeniyle işlem verilerini okuyup yazamaması ve depolayamamasıdır. Programlama dili genel bir durumu depolayamıyorsa, betikler uygulamalardaki veya köprülerdeki hesap bakiyelerini bağımsız olarak doğrulayamaz. Bitcoin betik mantığı genel duruma erişemez, çünkü her durum verisi tek bir işleme sığdırılmak zorundadır. Dolayısıyla L2 ağları ile Bitcoin taban katmanı arasında genel fonksiyonlar geliştirmek veya güvene dayalı olmayan bir köprü kurmak neredeyse imkansızdır.

Bitcoin Script sınırlamalarını aşmaya yönelik girişimler 2020 yılından bu yana devam ediyor. Yıllardır geliştiriciler arasında, Bitcoin Script'in ifade gücünü artırmanın tek yolunun, sözleşmeleri etkinleştirmek için yeni işlem kodları uygulayan yumuşak bir çatallanma yükseltmesi yapmak olduğu konusunda bir fikir birliği var gibi görünüyordu. Bitcoin topluluğunun bir kısmı bu güncellemelerin Bitcoin ağı için bir risk oluşturduğuna inanırken, diğer bir kısmı ise Bitcoin'in kullanım alanlarını genişletebilmek için daha fazla programlanabilirlik özelliğine ihtiyaç duyduğuna inanıyor. Bitcoin'in işlem programlanabilirliğini geliştirmek için hangi işlem kodunun en uygun olduğu konusunda gerçek bir ilerleme kaydedilememiş olsa da, sözleşme savunucuları artık çoğunlukla OP_CTV ve OP_CAT'ın Bitcoin'in işlem programlanabilirliğini geliştirmek için birincil Bitcoin Geliştirme Teklifleri (BIP'ler) olduğu konusunda hemfikir. Bitcoin'de sözleşmeleri uygulamaya yönelik ikiden fazla çözüm olduğunu biliyoruz, ancak bu makalede yalnızca en önemli iki teklif olan OP_CTV ve OP_CAT açıklanacaktır.

4. BIP119 (OP_CTV)

Bitcoin İyileştirme Teklifi 119 (BIP 119), CHECK-TEMPLATE-VERIFY (CTV) olarak da bilinen, Bitcoin Core geliştiricisi Jeremy Rubin tarafından Ocak 2020'de önerilen bir tekliftir. Öneri, Bitcoin işlemlerinin çıktılarına sözleşmeler olarak bilinen genel harcama koşullarını uygulayabilen OP_CTV adlı yeni bir işlem kodunu tanıtıyor. İşte kısa bir arka plan tanıtımı. “CHECK_TEMPLATE_VERIFY” içerisindeki şablon kısmı, Bitcoin scriptleri yazılırken uyulması gereken işlem formatını ifade eder. CHECK-TEMPLATE-VERIFY, bir işlem çıktısının kilitleme betiğinin, kilitleme betiğinde saklanan harcama koşullarına bir karma (taahhüt karması olarak da bilinir) olarak taahhüt etmesini sağlayan yeni bir özelliktir. Bu nedenle, işlem çıktısı yalnızca taahhüt karmasında ayrıntılı olarak belirtilen koşullar karşılandığında açılabilir. Zincir üzerinde yayınlandığında, bir işlemle ilişkili taahhüt karması değiştirilemez hale gelir. OP_CTV'nin avantajı, bir işlemin göndericisinin alıcıya harcama koşulları koyabilmesidir; bu, yalnızca gönderici için harcama koşulları oluşturabilen Bitcoin Script'in mevcut kurallarına göre önemli bir değişikliktir.

İki ana türde Ahit vardır. Genel bir sözleşme kopyalanabilir ve birden fazla UTXO'ya uygulanabilir. UTXO harcandıktan sonra sözleşmeler sona ermez. Öte yandan, önceden hesaplanmış sözleşmeler de çoğaltılabilir, ancak yalnızca sınırlı ve önceden tanımlanmış bir sayıda. Önceden hesaplanmış bir sözleşmenin mantığı, gönderici tarafından önceden belirlenmelidir ve harcama koşullarının sonsuza kadar tekrarlanamaması bakımından genel bir sözleşmeden farklıdır. Genel sözleşmeler, yinelemeli sözleşmeler olarak da bilinirler ve UTXO değiştirilebilirliği açısından risk oluşturabilirler; bu nedenle BIP 119 savunucuları genellikle yalnızca önceden hesaplanmış sözleşmeleri kullanan OP_CTV kullanım durumuna odaklanırlar ve BIP 119 genel sözleşmeleri desteklemez. Örneğin, genel sözleşmeler etkinleştirilirse, bir saklama kuruluşu veya bitcoin borsası, söz konusu bitcoinlerin bir hükümet veya başka bir otorite tarafından sansürlenme olasılığından asla kaçamayacağı kalıcı harcama koşullarıyla çekimleri işleyebilir.

5. BIP 119'u kullanarak Sözleşmeleri dağıtın

Kasa çözümünü örnek olarak ele alırsak, OP_CTV fonksiyonunun sözleşmeleri nasıl uyguladığını görelim:

Alice, 1 BTC'lik UTXO'sunun 0,8 BTC'sini önümüzdeki 10 yıl içerisinde Bob ve Charlie'ye (her biri 0,4 BTC) harcamak istiyor. Alice ayrıca yaklaşık 0,2 BTC tutarındaki para üstünü, BTC'yi 10 yıl daha kilit altında tutan yeni bir kasaya göndermek istiyor.

Adım 1: Alice, 1 BTC değerindeki UTXO'sunu Bob ve Charlie'ye harcıyor ve kilitleme betiğinde Bob ve Charlie'nin BTC'yi 525k bloktan sonra, yani yaklaşık 10 yıl sonra harcayabileceği belirtiliyor. Alice ayrıca, yaklaşık 0,2 BTC'lik değişim çıktısının kendisine ait bir kasa adresine gönderileceğini ve bu adresin UTXO 525k bloklarını, yani yaklaşık 10 yıl sonrasını kilitleyeceğini belirten talimatları da içeriyor.

Adım 2: Bob ve Charlie, 525k bloktan sonra kendi UTXO'larını 0,4 BTC değerinde harcarlar. Alice tarafından ayarlanan kilitleme betiği, taahhüt karma değerini mevcut blok yüksekliğine göre kontrol edecek ve koşullar karşılanırsa Bob ve Charlie yeni UTXO'larını harcayabilecekler.

2. adımda, Bob ve Charlie UTXO'larını harcadıktan sonra, "kilitleme betiği" olarak da bilinen Bitcoin betiğinin bir kısmı, harcama koşullarının yerine getirildiğini kontrol edecek ve BTC'yi serbest bırakmadan önce tüm koşulların karşılandığından emin olacaktır. Bu işlem genellikle doğru betik imzasını kullanarak bir Bitcoin çıktısının "kilidini açmak" olarak adlandırılır. Koşullar sağlanmadığı takdirde kilitleme betiği BTC transferini başlatmayacaktır.

2. adımda, Bob ve Charlie UTXO'larını harcadıktan sonra, "kilitleme betiği" olarak da bilinen Bitcoin betiğinin bir kısmı, harcama koşullarının yerine getirildiğini kontrol edecek ve BTC'yi serbest bırakmadan önce tüm koşulların karşılandığından emin olacaktır. Bu işlem genellikle doğru betik imzasını kullanarak bir Bitcoin çıktısının "kilidini açmak" olarak adlandırılır. Koşullar sağlanmadığı takdirde kilitleme betiği BTC transferini başlatmayacaktır.

Adım 3: Charlie ve Bob kilitleme betiğinde taahhüt karmasını sağladıktan sonra, UTXO Alice'e geri döner ve değişiklik (yaklaşık 0,2 BTC) belirtilen kasa betiği genel anahtarına sahip adrese giriş olarak kullanılır. Kasa betiğinin genel anahtarı, Alice'in 525 bin bloktan sonra kasayı açmasına ve yaklaşık 0,2 BTC değerindeki UTXO'sunu harcamasına olanak tanıyan bir karma içeriyor. Bir kasa şeması kullanmanın faydası, Alice'in, birisi özel anahtarını çalıp 525k blok zaman kilidi öncesinde UTXO'yu açmaya çalışması durumunda, gizli bir kurtarma adresi gibi, karmaya ayrıntılı güvenlik önlemleri ekleyebilmesidir.

Önceki örnekte sözleşmeler olmadan Alice'in, Bob ve Charlie'ye harcadığı BTC için gelecekteki harcama koşullarını zorunlu kılmak amacıyla önceden imzalanmış bir işlem oluşturması gerekirdi. Önceden imzalanmış bir işlem, gönderenin özel anahtarıyla önceden imzalanmış ancak onay ve yürütme için ağa yayınlanmayan tek veya birden fazla işlem olabilir. Önceden imzalanmış işlemler ölçeklenebilir değildir çünkü kullanıcıların zincir üzerinde yürütülene kadar birden fazla işlem için veri depolamasını gerektirir. Ayrıca, önceden imzalanmış işlemlerde, fonların harcanabilmesi için tüm imzalayan taraflar arasında etkileşimin olması gerekir. Ancak, OP_CTV aracılığıyla taahhüt karmalarını kullanarak sözleşmelerin uygulanması, kullanıcıların önceden imzalanmış işlem verilerini depolaması ve işlemde yer alan tüm taraflar arasındaki etkileşime güvenmesi ihtiyacını ortadan kaldırır.

Geniş anlamda, bu işlevsellik, çeşitli gelişmiş, son derece güvenli ve dayanıklı barındırma ve güvenlik tasarımları oluşturmak, kendi kendine barındırılan veya yönetilen kurulumları iyileştirmeye yardımcı olmak, yenilikçi yeni çoğunluk veya işletme hesabı kurulumları oluşturmak veya daha fazla şeffaflık ve güvenilirliğe sahip daha özerk yürütme şemaları oluşturmak için kullanılabilir.

6. BIP347 (OP_CAT)

BIP 347, Ekim 2023'te Ethan Heilman ve Armin Sabouri tarafından kaleme alınan ve Bitcoin işlemlerinin çıktılarına önceden hesaplanmış harcama koşullarının eklenmesini sağlayacak olan bir diğer Bitcoin İyileştirme Önerisidir. Öneri, Bitcoin geliştiricilerinin yığındaki iki veri noktasını "birleştirmesine" ve bu değerleri yığının en üstüne yerleştirmesine olanak tanıyacak bir özellik olan OP_CAT opcode'unun Bitcoin'in betik diline eklenmesini öneriyor. Kısa bir arka plan tanıtımına göz atalım. "Birleştirme", iki veya daha fazla kod dizesini daha büyük bir bayt veya veri dizesine birleştirme işlemidir. Bitcoin Script, her kod dizisini sırayla değerlendiren yığın tabanlı bir programlama dilidir. 5 satır koddan oluşan bir yığın için Bitcoin Script önce 1. satırı, en son da 5. satırı değerlendirecektir. Ne yazık ki Bitcoin'in betik dili, geliştiricilerin yığın boyunca birden fazla kod dizesini birleştirmesine olanak verecek işlem kodlarını içermiyor. Bitcoin Script'te şu anda aritmetik ve çarpma işlevleri eksik olduğundan, Bitcoin Script'in sıkıştırılabilmesi mümkün olmuyor ve bu da büyük betiklerin (32 bit'ten büyük) ve küçük betiklerin (32 bit'ten küçük) tek bir yığında etkileşimini sınırlandırıyor. "Birleştirme" yoluyla komut dosyalarını sıkıştırma ve büyük komut dosyalarının küçük komut dosyalarıyla iletişim kurmasına izin verme yeteneği olmadan, işlem çıktılarında karmaşık harcama koşullarının uygulanması mümkün değildir.

En önemlisi, Bitcoin Script'in yığınının en üstündeki bağlı elemanlar, aritmetik ve çarpma işlevlerini taklit edebilir ve bu sayede hatalara daha yatkın, uzun ve veri yoğun betikler yazmaya gerek kalmadan karmaşık betiklerin oluşturulmasına olanak tanır. Ayrıca OP_CAT'ın bağlantı yetenekleri, geliştiricilerin Tapscript'te Merkle ağaçları ve diğer karma veri yapılarını kullanarak harcama koşulları oluşturmasına olanak tanır. Tapscript, Kasım 2021'de etkinleştirilmesi planlanan Taproot yükseltmesinin bir parçası olarak yeni işlem türlerini etkinleştirmek için kullanılan yerel betik dilidir.

Satoshi'nin, Bitcoin betiklerinin doğrudan betik içerisinde karmaşık matematiksel işlemler gerçekleştirmesini sağlayan OP_CAT ve diğer işlem kodlarını devre dışı bıraktığı dikkat çekicidir. Satoshi Nakamoto, OP_CAT kodunu, Bitcoin betik sınırının o dönemde 2000 bayt olduğu bir dönemde veri yoğun betikler oluşturmak için OP_DUP ile birleştirilebileceği için kendisi sildi. Bu boyuttaki betikler Bitcoin düğümlerinin hesaplama kaynaklarını zorlayabilir ve aşırı yükleyebilir. Ancak Taproot yükseltmesi, 2021'de Taproot betikleri için 520 baytlık bir boyut sınırı getirdi, bu nedenle OP_CAT artık düğüm operatörleri için aşırı hesaplama yükü getirmiyor.

7. BIP 347 (OP_CAT) kullanarak Sözleşmeleri dağıtın

2021 Taproot yükseltmesi, Bitcoin Script diline Schnorr imzalarını ekleyecek. Schnorr imzaları, açık ve özel anahtarların bir araya getirilmesini destekleyerek birden fazla tarafın tek bir imza ile bir işlemi birlikte imzalamasına olanak tanır. Schnorr imzalarında yer alan doğrulama opkodlarının OP_CAT ile birleştirilmesi, işlem karma değerleri üreten yinelemeli olmayan bir sözleşme oluşturur. OP_CAT aracılığıyla kullanıcılar, gönderme adresi veya gönderme tutarı gibi işlemin belirli kısımlarını, kilidi açma betiği için gereklilikler olarak kısıtlayabilir ve işlem karması, kilidi açmanın anahtarı olarak işlev görür.

Kasa çözümünü örnek alarak, OP_CAT fonksiyonunun Covenants'ı nasıl uyguladığına dair genel bir bakış aşağıda verilmiştir. Bu örneğin teknik detayları bu makalenin kapsamı dışındadır.

Alice, 100 blok sonra UTXO'sunu açan bir kasa yaratmak istiyor:

*Adım 1: Alice, UTXO'sunu bir kasa adresine harcar ve tanık alanına, blok yüksekliği de dahil olmak üzere, kasa kilidini açma betiğinin harcama koşullarının ayrıntılarını ekler.

Alice, 100 blok sonra UTXO'sunu açan bir kasa yaratmak istiyor:

*Adım 1: Alice, UTXO'sunu bir kasa adresine harcar ve tanık alanına, blok yüksekliği de dahil olmak üzere, kasa kilidini açma betiğinin harcama koşullarının ayrıntılarını ekler.

*Adım 2: Alice’in işleminde, OP_CAT tanık alanındaki kasa kilidini açma talimatlarını birleştirir ve bunları iki kez karıştırarak sighash/txhash elde eder.

*Adım 3: 100 blok onayından sonra Alice, kasadaki UTXO için bir harcama işlemi yayınlayarak kasadaki bitcoinlerini harcama sürecini başlatır. Alice'in tüm harcama koşullarını karşıladığını doğrulamak için cüzdanı arka planda CheckSig işlem kodunu yürütür. Bu işlem iki temel doğrulama gerçekleştirir: ilk kurulum işleminden gelen işlem karmasının doğrulanması (adım 1) ve mevcut harcama işlemiyle karşılaştırılması (adım 3). CheckSig işlevi kurulum işleminin bileşenlerini yeniden oluşturur ve tüm kasa harcama koşullarının karşılandığından emin olmak için geçerli işlemin açık anahtar imzasını doğrular.

*Adım 4: Alice'in işleminin genel anahtarı CheckSig tarafından doğrulandıktan sonra (CheckSig, tanık alanında saklanan harcama koşullarını yeniden oluşturur), Alice UTXO'sunu harcamakta özgürdür.

Yukarıdaki örnekler OP_CAT'in tek başına işlemlerde harcama koşullarını zorlayamayacağını, ancak OP_CAT'in Bitcoin betiğindeki diğer işlem kodlarıyla birleştirildiğinde sözleşmeleri uygulamak için betik yazımını basitleştirebileceğini göstermektedir. OP_CAT'in tek işlevi yığının en üstteki iki elemanını birleştirmektir.

OP_CAT, CheckSig ile birlikte sözleşmeler oluşturmak için kullanılabilmesine rağmen, OP_CAT'ı tek başına eklemek Bitcoin Script'e Solidity benzeri bir işlevsellik kazandırmaz. Bu sınırlama yalnızca OP_CTV'nin eklenmesi durumunda da geçerlidir. OP_CAT ile bile Bitcoin işlemleri yalnızca asgari düzeyde iç gözlem yeteneğine sahiptir, bu da işlemlerin önceki işlemlerin öğelerine veya durumuna tam erişime sahip olmadığı anlamına gelir. Bu nedenle OP_CAT, yalnızca Taproot işlem çıktıları için ayrıntılı sözleşmeleri destekleyebilir. OP_CAT, Taproot çıktısının yaprak düğümlerini onaramaz veya kullanılan dahili anahtarları doğrulayamaz. Taproot yaprağı, Taproot çıktısına gönderilen tek bir harcama koşulu veya betiğidir. Bunları bitcoinlerinizi harcamanın farklı "yolları" veya yolları olarak düşünün; her yaprak düğümü onu harcamanın olası bir yolunu temsil eder. Bitcoin Taproot işlemindeki iç anahtar, en verimli harcama yolu için kullanılan ana genel anahtardır. Dahili bir anahtar kullanarak UTXO harcarken, herhangi bir betiği veya Merkle yolunu ortaya çıkarmadan yalnızca zincir üzerinde bir imza sağlamanız gerekir.

Bu sınırlamaların OP_TWEAK_VERIFY ve OP_INTERNALKEY gibi diğer opcode önerileriyle ele alınabileceğini belirtmek önemlidir. Genel olarak OP_CAT, işlem çıktıları üzerinde karmaşık harcama koşulları oluşturmak için ana yapı taşı olarak görülebilir, ancak CheckSig de dahil olmak üzere diğer yapı taşları, Bitcoin işlem programlanabilirliğinin geliştirilmesini ilerletmek için kritik öneme sahiptir.

8. Covenant'ların Bitcoin'e getirebileceği temel özellikler

(1) Güvensiz köprüleme ve tek taraflı çıkış

Starkware (Ethereum'daki Starknet zk-rollup'ın yaratıcısı), OP_CAT'in güvene dayalı olmayan bir Bitcoin köprüsü için STARK doğrulayıcıları ve Merkle doğrulayıcılarının oluşturulmasını nasıl destekleyebileceğini vurgulayan bir rapor yayınladı. Güvene dayalı olmayan köprü, Merkle ağacında kaydedilen bir işlem zinciri aracılığıyla köprü durumunu koruyan yinelemeli bir sözleşme sistemi aracılığıyla oluşturulur. Bu mekanizmanın çekirdeği, hesap bakiyesini temsil eden bir Merkle ağacının kök karmasını içeren harcanamaz bir OP_RETURN çıktısında depolanan köprü kalıcı durumudur. OP_CAT sözleşmesi, her yeni para yatırma veya çekme işleminin mevcut köprü durumunu yansıtan geçerli bir durum geçişi içermesini gerektirir. Kullanıcılar, Merkle ağaçlarını kullanarak birden fazla işlemi verimli doğrulama için gruplara ayıran özel para yatırma ve çekme sözleşmeleri aracılığıyla köprüyle etkileşime girer. Bu Merkle ağacının kökü daha sonra ana köprü sözleşmesine birleştirilir ve her para yatırma ve çekme işlemini doğrular ve işler. Bir çekim sırasında sözleşme, çekim adresinin yaprak işlemindeki ilk girdinin adresiyle eşleştiğinden emin olarak mülkiyeti doğrular. Tasarım, Bitcoin Script'te verimli durum güncellemeleri için Merkle kanıtlarından yararlanarak, OP_CAT tarafından oluşturulan zincir üstü sözleşme mantığı aracılığıyla köprünün durumunun ve kurallarının tam olarak uygulandığı, güvenilir üçüncü taraflara ihtiyaç duyulmayan güvensiz bir sistem oluşturur. En önemlisi, Bitcoin Script'in uç sistem durum geçişlerini doğrulayacak güvene dayalı olmayan bir Bitcoin köprüsü için doğrulama kanıtlarına ihtiyacı vardır. OP_CAT, karma verileri bir araya getirerek STARK doğrulayıcılarının yeteneğini Bitcoin betiklerine entegre eder ve UTXO kilitleme betiklerinin son sistem durum geçişlerinin zk kanıtlarını (sıfır bilgi kanıtları) doğrulamasını sağlar.

Taproot Wizard ekibi, OP_CAT'ı BitVM ile birleştiren yeni bir güvensiz köprüleme çerçevesi geliştirdi. BitVM, Bitcoin üzerinde keyfi hesaplamaların bölünüp yürütülmesine olanak sağlayarak Turing-tam ifade gücüne ulaşır. BitVM, Bitcoin Script'i kullanarak rastgele hesaplamaların çalışma zamanını Bitcoin üzerindeki birden fazla işleme böler. Sözleşmeler olmadan, Bitcoin'i kilitleyen BitVM köprüsünün kurulması için önceden imzalanmış bir işlem gerekiyor. OP_CAT’ın önceki işlemlerden veri taşıma yeteneği, BitVM köprüsünün önceden imzalanmış işlemler olmadan bitcoinleri kilitlemesini ve kilidini açmasını sağlar. OP_CAT, “yığındaki CAT” adı verilen bir hileyle önceki işlemlerden veri taşıyabilir. İşin püf noktası, OP_CAT'in doğrulayabileceği bir Merkle ağacı kökü oluşturmak için yığındaki karma verileri birleştirmeyi içeriyor. Bu nedenle CatVM köprüsü, başarılı bir çekimden sonra Merkle kökünün devam etmesini garantilemek için önceki işlemlerden, para yatırma ve çekme işlemlerinden belirli işlem verilerinin bir sonraki işleme dahil edilmesini sağlar. Yığın üzerindeki CAT hilesi ayrıca bir kullanıcı çekildikten sonra kalan köprülenmiş bitcoinlerin uygun herhangi bir kullanıcı tarafından çekilebilmesini sağlar.

(2) Gelişmiş kasa muhafazası

Bitcoin Vault, kullanıcıların özel anahtarlarının tehlikeye girmesi durumunda Bitcoin'lerini gizli bir adrese çekmelerine olanak tanıyan kurtarma yolları gibi güvenlik özelliklerini de içeren yeni bir saklama çözümüdür. Daha önce OP_VAULT olarak bilinen BIP 345, Bitcoin saklama hizmetinin güvenlik parametrelerini geliştirmek için OP_CTV'den yararlanan bekleyen bir Bitcoin İyileştirme Teklifidir. OP_CAT'ın önceden imzalanmış bir işlem gerektirmeden Bitcoin kasaları için harcama koşulları oluşturmak amacıyla da kullanılabileceğini belirtmek önemlidir. Bitcoin Core geliştiricisi James O'Beirne, OP_CTV'nin kullanım durumlarını daraltmak için Ocak 2023'te OP_VAULT'u önerdi. OP_VAULT, mevduat sahiplerinin birden fazla işlemi önceden imzalamasını gerektirmeden, kasadaki Bitcoin için harcama koşulları oluşturmak amacıyla OP_CTV'ye güvenir. Sözleşmeler, kasaların, orijinal zaman kilidi öncesinde kasadaki Bitcoin'leri harcamaya çalışan biri olduğunda tetiklenecek bir zaman gecikmesine sahip olmasına izin verir; genellikle bu, fonları çalmaya çalışan bir saldırgandır.

(3) Tereddüt Etmeme Sözleşmesi

Kesintisiz Sözleşme, Bitcoin ağına 2015 yılında tanıtıldı. İmzalayanın iki kez harcaması durumunda imzalama anahtarını sızdıracak bir Bitcoin işlem çıktısıdır. Uygulamada kullanıcılar yerel Bitcoin'lerini kesilebilir bir güvenlik teminatı olarak kilitlerler. Bu mevduat, kullanıcıların daha sonra bir blokta madencilik yoluyla çıkarılacak olan temel katmanda 0 onaylı işlemler gerçekleştirmesine olanak tanır. 0 onaylı işlemler, Bitcoin konsensüs kuralları tarafından doğrulanan ve güvence altına alınan anında Bitcoin işlemleridir. 0 onaylı bir işlemin göndereni, işlem gerçekleştirilmeden önce girdiyi harcarsa, karşı taraf tehlikeye atılan imzalama anahtarından kaynaklanan Bitcoin güvenlik depozitosunu kaybedebilir.

(4) Lightning Network'te İyileştirmeler

OP_CAT, kullanıcıların Bitcoin temel katmanında bir kanal açma işlemini yayınlamadan Lightning kanalları açmalarına olanak tanıyan Kanal Fabrikalarını etkinleştirir. Örneğin, Alice 2 lightning kanalı oluşturmak isterse (biri Bob ile, diğeri Charlie ile), Alice hem Bob ile hem de Charlie ile bir kanal açılış işlemi yayınlayacaktır (2 işlem). Kanal açma işlemi, her iki tarafın da Bitcoin'i 2/2 çoklu imzalı bir adrese yatırmasını gerektirir. Kanal fabrikası sayesinde Bob ve Charlie, yeni bir kanal açma işlemi yayınlamadan birbirleriyle ayrı kanallar açabiliyorlar. Dolayısıyla orijinal kanal açılış işlemindeki tüm katılımcılar birbirleriyle bağımsız kanallar oluşturabilirler.

OP_CTV, bir UTXO'nun birden fazla kullanıcıyı temsil ettiği paylaşımlı UTXO'lar oluşturabilir. CTV'nin paylaşımlı UTXO'larını kullanmak, birden fazla kullanıcının tek bir zincir üstü işlemle birden fazla lightning kanalı açmasını sağlar. Genellikle her lightning kanalı bir zincir üstü işlem gerektirir. Dolayısıyla, çok sayıda kullanıcı lightning kanalları açarsa, bu durum mempool'u bekleyen işlemlerle doldurabilir ve işlem ücretlerini artırabilir. Bu şu anda bir sorun olmasa da, milyonlarca aktif kullanıcıyı çekmek için kanal açılışının Lightning Network'ü destekleyecek şekilde ölçeklenmesi gerekecek.

9. OP_CAT ve OP_CTV ile ilgili riskler

9. OP_CAT ve OP_CTV ile ilgili riskler

Tüm Bitcoin soft forkları, yeni işlem kodlarındaki hatalar veya öngörülemeyen kullanım durumları gibi teknik riskler içerir. Birincisi nadir görülürken, ikincisi yazıtların yaratılmasında ortaya çıkar. Yazıt, Bitcoin üzerinde yeni token ve NFT koleksiyonları oluşturmak için kullanılan bir işlemin tanık alanına keyfi verilerin girilmesini içerir. SegWit ve Taproot yükseltmesi birlikte kullanıcıların tanık alanına görüntü ve metin verilerini dize verisi olarak girmelerine olanak tanır. Dijital sanat ve değiştirilebilir token'ların oluşturulması SegWit veya Taproot'u etkinleştirmenin amacı olmasa da, yıllar sonra akıllı geliştiriciler bu yükseltmeleri başka amaçlar için nasıl kullanacaklarını keşfettiler. Galaxy Research, Ordinals raporumuzda bu düşünceyi destekledi ve SegWit ve Taproot aracılığıyla yanlışlıkla oluşturulan yazıtların gelecekteki Bitcoin yükseltmeleri üzerinde olumsuz bir etkiye sahip olabileceğini, çünkü topluluğun bu yeni kullanım örneklerine olan şaşkınlığının yeni yumuşak çatallanmaları destekleme konusunda daha tereddütlü olmasına yol açabileceğini belirtti.

Bitcoin'in yükselme kabiliyetine ilişkin düşüş eğilimine rağmen, OP_CAT ve OP_CTV kapsamlı bir şekilde test edildi ve araştırıldı. Sözleşmelere yönelik ilk eleştiri, hükümetlerin uygulamaları, yalnızca onaylı bir adres grubunun Bitcoin harcamasına izin veren harcama koşullarını uygulamaya zorlayabileceği yönündeydi. Bu eleştiri geçersizdir, çünkü harcamanın hangi koşullar altında gerçekleşebileceği, fonların sahibi olan kullanıcılar tarafından belirlenmektedir. Kullanıcılar, gelecekteki harcamaları belirli adreslerle sınırlayan işlemler oluşturabilirler; ancak bu kısıtlamalar üçüncü taraflarca harici olarak uygulanamaz ve kilitli fonlar harcandıktan sonra kalıcı olarak geçerliliğini yitirir. Bu nedenle hükümetler, kendi kendine barındırılan bir hazine uygulamasının veya köprüsünün fonları nasıl harcayacağını zorlayamaz. Emanetçiler ve bitcoin borsaları kullanıcıların fonları nasıl harcayacaklarını hâlâ kısıtlayabilirler; ancak OP_CTV'nin izin vermediği genel sözleşmeleri uygulama yetkisi olmadan fonların çekilmesine kalıcı harcama koşulları ekleyemezler.

Genel olarak OP_CAT ve OP_CTV, her biri bir işlevi çok iyi gerçekleştiren basit opkodlardır. OP_CAT, yığının en üstündeki iki öğeyi birleştirir, OP_CTV ise kilitleme betiğinde harcama koşullarını karıştırabilir. Bu işlem kodlarının bazı kullanım örnekleri, örneğin güvensiz köprülerin geliştirilmesi, köprülerin hatalara ve saldırılara karşı son derece hassas olması nedeniyle daha fazla araştırma ve saha testi gerektirmektedir.

10. Bir sonraki soft fork yükseltmesi için Covenants dağıtım yolu

Bitcoin paydaşlarının gelecekteki protokol yükseltmeleri konusunda fikir birliğine varması, bir teklifin yaşam döngüsü boyunca gelişen karmaşık bir süreçtir; bu süreç BIP (Bitcoin Geliştirme Teklifi) süreci olarak da bilinir. BCAP'nin Bitcoin yükseltmelerinin geçmişine ilişkin raporu, bu paydaşların rollerini şu şekilde detaylandırıyor:

* Ekonomik düğümler: borsalar, saklama kuruluşları, tüccarlar, ödeme sağlayıcıları

*Yatırımcılar: Whale, MicroStrategy, ETF sağlayıcıları, Galaxy

* Medya etkileyicileri: CoinDesk, Bitcoin Magazine, Celebrity X, podcaster'lar

* Madenciler: Bitmain, MicroBT, Riot, Marathon, büyük özel madenciler

* Protokol geliştiricileri: Bitcoin çekirdek geliştiricileri

*Uygulama geliştiricileri: L2 projesi

Bir Bitcoin Geliştirme Teklifi'nin (BIP) yaşam döngüsü boyunca, farklı paydaşlar farklı derecelerde etki kullanır ve bunların göreceli etkisi, yumuşak çatallanmayı uygulamak için fikir birliği oluşturma süreci boyunca değişir. Aşağıda her paydaşın etki düzeylerinin 1-10 arasında sıralanmış ayrıntılı bir dökümü yer almaktadır. Mart 2024 itibarıyla OP_CAT ve OP_CTV protokol tasarım aşamasındadır. Bu aşamada medya figürleri kamuoyunu etkileyebilecek ve hikayeler yaratabilecekleri için en fazla etkiye sahiptirler. Örneğin, Taproot Wizards, Bitcoin topluluğunu OP_CAT'ın faydaları konusunda eğitmek için geniş sosyal medya takipçi kitlesini kullanan tanınmış Bitcoin etkileyicilerinden oluşan bir ekiptir. Taproot Wizards ekibi, Bitcoin Script'in işlem programlanabilirliğini artırmak için yeni işlem kodlarına ihtiyaç duyduğu anlatısını ilerletmek amacıyla OP_CAT hakkında eğitim içeriği ve araştırmalar üretiyor. Sonuç olarak Taproot Wizards, OP_CAT için geniş bir destekçi grubu oluşturdu ve çekirdek geliştiricileri OP_CAT BIP taslağını incelemeye zorluyor.

Bitcoin Core geliştiricileri, protokol fikir aşamasında etki açısından ikinci sırada yer alırlar; çünkü BIP editörleri, bekleyen BIP'lerin taslaklarını incelemekten sorumludur ve en önemlisi, BIP'leri Bitcoin Core GitHub deposuna birleştirebilen tek kuruluştur. Bitcoin Core geliştiricilerinin desteği olmadan BIP kaçınılmaz olarak rafa kaldırılacak ve eninde sonunda reddedilecektir. Bitcoin Core geliştiricileri aynı zamanda Bitcoin kod tabanının bakımından ve herhangi bir hata içermediğinden emin olmaktan da sorumludur. Bitcoin çekirdek geliştiricileri arasında fikir birliğine varmak zorlu bir süreçtir çünkü çekirdek geliştiriciler arasında ideolojik görüşler farklılık gösterebilir ve her çekirdek geliştiricinin karar alma sürecindeki etkisi, katkılarına ve geçmişine bağlı olarak değişir.

OP_CAT ve OP_CTV BIP'leri, medya etkileyicilerinin, kullanıcıların ve uygulama geliştiricilerinin, Bitcoin Core geliştiricilerini, bu fikir birliği değişikliklerinin Bitcoin işlemlerinin programlanabilirliğini artıracağına ikna etmek için etkilerini kullandıkları bir aşamadadır. Mutabakat yolculuğunun bir sonraki aşaması, OP_CAT ve OP_CTV'nin tüm potansiyel risklerini ayrıntılı olarak belirlemek için teknik uzmanlar, uygulama geliştiricileri ve temel geliştiriciler tarafından özel araştırmalar yapılmasını gerektirecektir. Belirli bir araştırma yapılmadan ve çekirdek geliştiricilerle açık bir diyalog kurulmadan, OP_CAT ve OP_CTV hakkında daha geniş çekirdek geliştirici topluluğundan kolektif bir görüş oluşmayacaktır.

Çekirdek geliştiriciler arasında fikir birliğine varıldığında, OP_CAT ve OP_CTV'nin BIP'yi Bitcoin Çekirdek deposuna uygulama son adımını kolaylaştırmak için bir baş bakımcı belirlemesi gerekecektir. OP_CAT ve OP_CTV için BIP'ler Bitcoin Core deposuna birleştirildikten sonra, aktivasyon yöntemine karar verilmesi gerekir. Bir aktivasyon yöntemi seçildikten sonra, madenciler, yatırımcılar ve ekonomik düğümlerin en fazla etkiye sahip olduğu sinyalleme süreci başlar. Mart 2024 itibariyle madenciler, Microstrategy gibi büyük yatırımcılar ve Coinbase gibi ekonomik düğümler OP_CAT ve OP_CTV hakkında kamuoyuna açık görüş belirtmediler. BIP'in uygulanabilmesi için bu paydaşların OP_CAT ve OP_CTV'nin risklerini ve faydalarını daha iyi anlamaları gerekiyor.

11. BIP Aktivasyon Yöntemi

Bitcoin Core geliştiricileri bir sonraki soft fork güncellemesine OP_CAT veya OP_CTV'yi dahil etmeyi kabul ederse, topluluğun BIP'yi etkinleştirmek için bir yöntem üzerinde anlaşması gerekecektir. Aktivasyon yöntemi, madencilerin yükseltmeye hazır olduklarını bildirmelerine olanak tanır.

Bitcoin'de kod değişikliği yapmanın genel olarak iki yolu vardır. Birincisi, kod değişiklikleri yumuşak çatallanmalar yoluyla uygulanabilir. Yumuşak çatallanmalar, Bitcoin düğüm operatörlerinin istemci yazılımlarını yükseltmeden bile Bitcoin ağında güvenli bir şekilde faaliyet göstermelerine olanak tanıyan geriye dönük uyumlu yükseltmelerdir. Yumuşak çatallanmaların geriye dönük uyumlu olmasının bir diğer faydası da, Bitcoin Core'un (ana Bitcoin istemcisi) gidişatına katılmayan herkesin, yeni BIP'in etkinleştirilmesini hariç tutan, ancak yine de kanonik Bitcoin blok zincirine bağlanabilen eski bir istemci yazılımı sürümünü çalıştırmayı seçebilmesidir. Yumuşak çatallanma, mevcut kural kümesinden daha sınırlı olan ve dolayısıyla mevcut kurallara uyan yeni koşullar yaratarak işlevsellik ekler.

Yumuşak çatallanma, madenciler yerine kullanıcılar tarafından etkinleştirildiğinde buna kullanıcı tarafından etkinleştirilen yumuşak çatallanma (UASF) adı verilir. Bitcoin'de UASF'nin en ünlü örneği, SegWit güncellemesinin benimsenmesini hızlandırmaya yardımcı olmak için 1 Ağustos 2017'deki "blok boyutu savaşı" sırasında neredeyse gerçekleşmişti. Blok boyutu anlaşmazlığı sırasında Bitcoin kullanıcıları, SegWit yükseltmesini desteklemek için düğümlerini yükselttiler ve daha sonra yükseltilmemiş düğümlerden gelen blokları reddetmekle tehdit ettiler. Böylelikle Bitcoin istemci yazılımlarını güncellememiş olan madencilerin, bloklarının daha geniş bir şekilde yayılmasını sağlamak ve blok ödülleri alma şanslarını artırmak için Segwit'i benimsemeleri teşvik ediliyor. Blok boyutu savaşı sırasında hiçbir zaman bir UASF meydana gelmemiş olsa da, potansiyel bir UASF tehdidi madencileri SegWit'i benimsemeye yöneltti.

Kod değişikliklerini uygulamanın ikinci yolu, yükseltilmiş ve yükseltilmemiş düğümler arasında fikir birliğini kalıcı olarak bölen, geriye dönük uyumsuz bir yükseltme olan sert çatallanmadır. Bitcoin Core geliştiricileri hiçbir zaman sert çatallanma uygulamadılar çünkü topluluk protokol kodunun sağlamlaştırılmasına ve geriye dönük uyumluluğa önem veriyor. Bitcoin, kullanıcıların azınlığının blok boyutunu değiştirmek gibi sert çatallanma yükseltmeleri yapması durumunda zincir bölünmesi yaşayabilir. Bitcoin Cash, 2017 yılında Bitcoin topluluğunun bir kısmının Segwit güncellemesine karşı çıkması ve bunun yerine blok boyutunu artırmak için geriye dönük uyumsuz bir kod değişikliğini etkinleştirerek Bitcoin protokolünden ayrılmak istemesiyle ortaya çıktı.

Sert ve yumuşak çatallanma aktivasyonları arasındaki ayrımın yanı sıra, çatallanma gerçekleşmeden önce topluluk duygusunu yükseltmeye yönelik ölçmenin de farklı yolları vardır. Bitcoin topluluğunun yumuşak çatallanma yükseltmelerinin aktivasyonunu daha iyi desteklemek için önerdiği çeşitli işlem tiplerine genel bir bakış aşağıdadır:

*BIP 9: BIP 9, madencilerin Bitcoin blok başlığındaki sürüm bit alanını değiştirerek yumuşak çatallanma yükseltmelerine olan desteklerini belirtmeleri için bir çerçeve sağlar. Sinyal süresi sona erdiğinde, Bitcoin topluluğu yükseltmeyi destekleyen madencilerin yüzdesini değerlendirebilir ve madenci hash oranına göre oy kullanabilir. Belirli bir destek eşiği aşılırsa, yükseltme, yükseltmenin etkinleştirilmesi için belirlenmiş bir blok yüksekliği olan "bayrak günü"nde etkinleştirilmeye devam edebilir.

*BIP 9: BIP 9, madencilerin Bitcoin blok başlığındaki sürüm bit alanını değiştirerek yumuşak çatallanma yükseltmelerine olan desteklerini belirtmeleri için bir çerçeve sağlar. Sinyal süresi sona erdiğinde, Bitcoin topluluğu yükseltmeyi destekleyen madencilerin yüzdesini değerlendirebilir ve madenci hash oranına göre oy kullanabilir. Belirli bir destek eşiği aşılırsa, yükseltme, yükseltmenin etkinleştirilmesi için belirlenmiş bir blok yüksekliği olan "bayrak günü"nde etkinleştirilmeye devam edebilir.

*BIP 8: Uzun süredir Bitcoin Core geliştiricisi olan Luke Dashjr (2011'den beri Bitcoin geliştirme üzerinde çalışıyor), Şubat 2017'de BIP 9'un halefi olarak BIP 8'i önerdi. BIP 8, bir teklifin onaylanması için sinyalleme süresinin belirlenmesinde karma oranı yerine blok yüksekliğinin kullanılmasını önermektedir. BIP 8 ayrıca “LOT” adı verilen zincir üzerinde etkinleştirilen yeni bir yumuşak çatal parametresini de tanıtıyor. Bu parametre "TRUE" olarak ayarlanırsa, yumuşak çatalın zaman aşımı yüksekliğinde kilitlendiğinden emin olmak için sonlandırma süresi boyunca bir sinyal gerekir. Bundan sonra, madencilerin sinyal verip vermemesine bakılmaksızın, yükseltme önceden tanımlanmış bir bayrak gününde düğümler tarafından etkinleştirilir. BIP 8, topluluk tarafından istenen teklif aktivasyonlarına yönelik madenci müdahalesini azaltmayı amaçlıyor ve madencileri, yükseltmenin LOT parametresi TRUE olarak ayarlandığında yükseltilen düğümlerden blok alamamaktan kaynaklanan gelir kaybının sonuçlarını değerlendirmeye zorluyor.

*Hızlı Deneme: Bitcoin Core geliştiricileri AJ Townes ve Andrew Chow, Nisan 2021'de "Hızlı Deneme" adı verilen bir BIP 8 versiyonu tanıttı. Hızlı Deneme, madencilerin aktivasyona hazır olduklarını bildirmelerinin zaman çizelgesini hızlandırmayı amaçlıyor. Bu yaklaşım, belirli bir süre içerisinde çıkarılan blokların çoğunluğunun hazır olduğunu işaret etmesiyle teklifin etkinleştirilmesi anlamına gelir. Speedy Trial, BIP 9 aktivasyon dağıtımına benzer şekilde çalışır, ancak daha kısa bir aktivasyon penceresine sahiptir. Son zamanlarda Bitcoin'de Speedy Trial aracılığıyla Taproot güncellemesi aktif edildi. Deneme, Taproot'un ağda etkinleştirilebilmesi için iki haftalık bir süre içerisinde madencilikle elde edilen blokların %90'ının hazır olduğunun sinyal vermesini gerektiriyor. Yargılama 12 Haziran 2021'de sona erdi. %90 madenci destek eşiğine ulaşıldıktan sonra ağ, madencilere ve düğümlere yazılımlarını yükseltmeleri için zaman tanımak amacıyla beş aylık bir bekleme sürecine girer. Taproot daha sonra 15 Kasım 2021'de Bitcoin'de resmi olarak etkinleştirildi.

*Modern Soft Fork Aktivasyonu: Bu, BIP 9 ve BIP 8'in farklı niteliklerini birleştiren bir yükseltme aktivasyon yöntemidir. Ocak 2020'de Bitcoin Core'un en üretken katkıda bulunanlarından biri olan Matt Corallo tarafından önerildi. Yöntem üç aşamadan oluşmaktadır. İlk adım, BIP 9'da özetlendiği gibi madenci tarafından etkinleştirilen yumuşak çatallanmadır. Madenciler yükseltmeyi etkinleştiremezse, Corallo tarafından özetlenen modern yumuşak çatallanma etkinleştirme süreci varsayılan olarak ikinci adıma, yani geliştiricilerin ve daha geniş bitcoin topluluğunun kod değişikliğini yeniden gözden geçirmesi için altı aylık bir bekleme süresine geçecek. Altı ay sonra, geliştiriciler ve kullanıcılar yükseltmeye devam etmek isterlerse, LOT parametresinin TRUE olarak ayarlandığı BIP 8'e eşdeğer olan üçüncü adımı başlatabilirler.

12. Sonuç

OP_CAT (BIP 347) ve OP_CTV (BIP 119) birçok önde gelen Bitcoin geliştiricisinin desteğini almış olsa da, tekliflerin uygulamaya konulmadan önce uzun bir inceleme sürecinden geçmesi gerekiyor. Bunun nedeni, OP_CAT ve OP_CTV'nin Bitcoin'in mutabakat katmanında değişiklikler gerektirmesi ve bu tür değişiklikler için BIP yönetişim sürecinin kapsamlı olmasıdır. BIP 119 ve BIP 347 için aktivasyon zaman çizelgesi belirsiz ve öngörülemez olsa da, uzun inceleme süreci, topluluğa OP_CTV ve OP_CAT'ın faydalarını ve etkilerini anlamaları için yeterli zaman sağladığı için öneriler açısından faydalı olabilir. Ayrıca, BIP katılımcılarının OP_CTV ve OP_CAT'ı stres testinden geçirmek ve bunların Bitcoin Script'teki gelecekteki hatalar üzerindeki potansiyel etkilerini incelemek için daha fazla zamanı olacak.

OP_CAT ve OP_CTV'nin tüm potansiyeli hala araştırılırken, bunların en acil etkisi Bitcoin L2'ye güvensiz köprüler ve gelişmiş güvenli Bitcoin kasalarını etkinleştirmesidir. EVM uyumlu Bitcoin L2 için güvene dayalı olmayan köprülemenin önemi, özellikle Bitcoin DeFi'nin sürekli gelişimi bağlamında, yeterince vurgulanamaz. Bu güvene dayalı olmayan çözümler, güvenilir aracılara dayanan ve blok zinciri teknolojisinin izinsiz yapısını zayıflatan WBTC ve cbBTC gibi mevcut alternatiflere kıyasla önemli bir ilerlemeyi temsil ediyor. Kendi kendine barındırılan Bitcoin kasaları, saklama çözümleri arasında en pratik değeri sunsa da, güvene dayalı olmayan L2 köprülerinin potansiyeli, gelişmiş işlem programlanabilirliğinin Bitcoin'e getirdiği daha geniş olanakları göstermektedir.

Geliştirici topluluğu bu önerileri 2024'te hayata geçirmede önemli ilerleme kaydetti ve bu ivmenin 2025'te de devam etmesi muhtemel. Bitcoin işlem aktivitesinin düşüş eğiliminde olması ve işlem ücretlerinin 1 sat/VB kadar düşük olmasıyla birlikte, odak noktası artık Bitcoin ağındaki işlem aktivitesinin nasıl eski haline getirileceğine çevrildi. Galaxy Research 2025 tahmin raporumuz Bitcoin Core geliştiricilerinin OP_CAT veya OP_CTV arasında bir fikir birliğine varacağını varsaysa da, nihai uygulama ve aktivasyon sürecinin 1-2 yıl daha sürmesi mümkün. Bununla birlikte, bu önerilerin nihai olarak kabul edilmesi, Bitcoin Script'in evriminde önemli bir dönüm noktası olacak ve gelecekte daha gelişmiş ve güvenli Bitcoin uygulamalarının temellerini atacaktır.

Bitcoin, işlem programlanabilirliğini geliştirerek, güvene dayalı olmayan zincirler arası köprüleme ve gelişmiş saklama çözümleri gibi daha yenilikçi kullanım durumlarını destekleyebilecek ve Bitcoin ekosisteminin gelişimini daha da ileriye taşıyacaktır. Bu teknolojilerin tanıtılması yalnızca Bitcoin'in işlevselliğini iyileştirmekle kalmayacak, aynı zamanda geliştiricilere ve kullanıcılara daha güvenli ve daha verimli merkezi olmayan uygulamalar oluşturmaları için daha fazla araç sağlayacaktır. Bu hedeflere ulaşmak zaman alacak ve topluluğun ortak çabalarını gerektirecek olsa da, bunların potansiyel etkisi şüphesiz Bitcoin'in geleceğine yeni bir canlılık katacaktır.