MATT Önerisi OP_CCV ile Bitcoin (BTC) Durumlu Sözleşmeleri Hedefliyor

Durum Taşıyan Bir İşlem Kodu: Bitcoin Script'e Hafıza

Bitcoin (BTC) Core deposunda açıkta bekleyen bir öneri, ağın betik diline şimdiye kadar hiç sahip olmadığı bir şey kazandırmayı amaçlıyor: bir hafıza. MATT (Merkleize All The Things) çerçevesi, temel katmanda durumlu sözleşmeleri ve ölçeklenebilir sahtekârlık kanıtlarını mümkün kılıyor; bu yolun en doğrudan uygulaması da OP_CHECKCONTRACTVERIFY, kısaca OP_CCV işlem kodu (opcode) üzerinden geçiyor. Öneri, depoda pull request 32080 numarasıyla açık duruyor. Kovenant (covenant), madenlerin gelecekteki işlemlerde nereye harcanabileceğini kısıtlayan betik kuralları anlamına geliyor. Standart Bitcoin betikleri her işlemi birbirinden bağımsız değerlendirir; önceki harcamaların ne yaptığına dair hiçbir kayıt tutmaz. Bu yüzden bir sözleşme bilgiyi ileriye taşıyamaz ve sözleşme geliştikçe onu güncelleyemez. Aslında her kovenant önerisi bir ölçüde durum taşıyan UTXO'lara izin verir. OP_CTV üzerine kurulan Sapio gibi betik dilleri bunu, adresleri sonlu durum otomatı olarak ele alarak başarır; her işlem bir durum geçişine denk gelir. Kovenantlar yıllardır aktif Bitcoin protokol önerileri arasında bekliyor, çünkü sade Script bu güvencenin tam önünde duruyor. Sorun şu: otomatı paradigması sayısal mantığı ifade etmenin temiz bir yolunu sunmuyor ve MATT tam bu boşluğu dolduruyor. MATT, taahhüt edilen verinin harcama anında hesaplanıp bir sonraki çıktıya yeniden gömülmesine izin verdiği için her harcama, önceden belirlenmiş bir durum listesinden seçim yapmak yerine yeni bir durumu dinamik olarak türetebiliyor. İşlem kodu Taproot çıktıları için tasarlandı; taahhütler ek betik verisi üzerinde değil, açık anahtarın kendisinde taşınıyor. Bu fark, bir sözleşmenin değişen bakiyelere uyum sağlayıp sağlayamayacağını ya da yalnızca önceden kararlaştırılmış sonuçlardan oluşan sabit bir ağaca bağlanıp kalamayacağını belirliyor. Öneri, grafiklerde görünen hiçbir şeye değil, Bitcoin (BTC) fiyatının altındaki betik katmanına dokunuyor; yine de varlığın basit ödeme aracılığı ötesinde ne yapabileceğini tanımlıyor: harcama anında çekim koşullarını yeniden hesaplayan kasalardan (vault), yalnızca tek bir itirazlı hesaplama adımını doğrulayan sahtekârlık kanıtı sistemlerine kadar.

Ayarlanmış Anahtarlar ve Üç Kontrol Modu

Her Taproot çıktısı, iç anahtar (internal key) adı verilen temel bir açık anahtar barındırır; bu anahtar, ek bilgiye taahhüt vermek için kriptografik olarak değiştirilebilir, yani ayarlanabilir (tweak). Ayarlanmış anahtar Q = P + t·G biçimini alır: P iç anahtar, G secp256k1 eliptik eğrisinin üreteci, t ise P ile taahhüt edilen veriden türetilen etiketli bir özettir. Sıradan bir Taproot çıktısında bu taahhüt genellikle, gizli harcama yollarını tutan taptree'nin Merkle kökünü kodlar. MATT aynı düzeneği kullanır ve sözleşme durumunu da anahtarın içine gömer; böylece blok zinciri yalnızca her durum geçişinin geçerli olduğunu doğrular, sözleşmenin kendi mantığını çalıştırmaz. İşlem kodu durum verisi, bir çıktı indeksi, bir açık anahtar, isteğe bağlı bir taptree ve bir mod alıyor. Üç mod çıktıyı, ayrı bir mod ise girdiyi kontrol ediyor. Varsayılan mod, girdi UTXO'nun tüm değerini belirtilen çıktıya aktarır. Düşme (deduct) modu yalnızca çıktının tutarına eşit bir kısmı ayırır ve kalanı sonraki çıktılar için serbest bırakır. Yok sayma (ignore) modu tutara dokunmadan betiği ve veri taahhüdünü doğrular. Varsayılan ve düşme modları değer kontrol edilen çıktılar içinde tuttuğu için işlem ücretleri ayrı ücret girdileriyle ödenmelidir; özel bir ücret girdisi ve para üstü çıktısı, kovenantın kısıtlarıyla çatışmadan işlemi eşlik edebilir. Bu, OP_CTV ya da SIGHASH_ANYPREVOUT gibi daha ilkel kovenant şemalarında mümkün olan yanlışlıkla fon yakılmasını önler ve tutarları önceden sabitleyip dinamik ücret ayarlamalarına veya kısmi kasa açmalarına izin vermeyen ön imzalı işlem kovenantlarının sınırlamasını giderir. OP_CCV, Script'te bayt birleştirmeyi mümkün kılan OP_CAT ile eşleşince ifade gücü yeniden büyür. İkili, zincir üstünde ikinci bir ağaca karşı Merkle kanıtları kurup doğrulayabilir, bu ağaç harcama betiklerini değil sözleşmenin verisini tutar, sonra bir sonraki çıktıyı güncellenmiş köke taahhüt etmeye zorlar. Sahtekârlık kanıtı sistemleri de buradan doğar: uzun bir hesaplama zincir dışında koşar, zincir üstüne yalnızca itiraz edilen adım ve ikili ağaçtaki yolu açılarak doğrulanır. Bu hesaplamanın önce adım adım ikili bir gösterime derlenmesi gerekir; elftrace ikili devre aracı tam bu sorun üzerinde çalışıyor. Kurulum, Ethereum iyimser rollup'ları yapısına aynadır ve aynı sahtekârlık kanıtı modeli pek çok zincirler arası köprüyü ayakta tutuyor. Bu tasarım ayrıca BitVM'nin durum tutarlılığını dayatmak için kullandığı Lamport tek kullanımlık imzalarını ve ön imzalı işlem grafiklerini ortadan kaldırır; OP_VAULT'un önerdiği kasa işlevini de yeniden üretebilir. OP_VAULT'un yazarı James O'Beirne, OP_CCV'yi kendi önceki önerisini fiilen aşan, daha genel ve sağlam bir tasarım olarak tanımladı.

Önümüzdeki İnceleme Yolu

OP_CCV'yi önceki kovenant taslaklarından ayıran şey ücret düzeni. Varsayılan ve düşme modları değerini kontrol edilen çıktıların içinde tutarken ücretler ayrı girdilerden gittiği için, durumlu tasarımlar ön imzalı akışların tıkandığı canlı bir ücret piyasasında da çalışabilir durumda kalıyor. Henüz hiçbir şey birleştirilmedi. Pull request bir aktivasyon takvimi taşımıyor; olası herhangi bir kullanım, düğüm operatörlerinin yeni konsensüs kurallarını uygulayan yazılımı çalıştırmasına bağlı ve bu, her Bitcoin (BTC) değişikliğinin izlediği yavaş yol. Kullanıcılar için daha yakın vadeli sonuç tasarım alanı: yerel kasalar, kendi kendini saklama güvencesi için wrapped Bitcoin bağımlılığını azaltabilir; durum ağaçları, güvenilir sakçılara ihtiyaç duymadan Bitcoin DeFi alanının neyi ödeştirebildiğini genişletebilir. Sıradaki adım Bitcoin Core inceleyicilerinde ve geniş geliştirici topluluğunda: işlem kodunun konsensüs davranışı ana ağa (mainnet) ulaşmadan önce denetlenmeli.