BTC'ye Yaklaşmak: BitVM İçin Gerekli Arka Plan Bilgisi Detaylı Anlatımı

Yazar: Nickqiao & Faust & Shew Wang, geek web3

Danışman: Bitlayer araştırma ekibi

Özet:

Son zamanlarda Delphi Digital, Rollup için yol açan The Dawn of Bitcoin Programmability: Paving the Way for Rollups adlı Bitcoin ikinci katmanıyla ilgili bir teknik araştırma raporu yayınladı. Rapor, BitVM ekosistemi, OP_CAT ve Covenant sınırlamaları, Bitcoin ekosistemi DA katmanı, köprü ve Bitlayer, Citrea, Yona, Bob gibi BitVM kullanan dört büyük Bitcoin ikinci katmanı gibi temel kavramlarla ilgili ayrıntılı bir inceleme sunmaktadır.

Bu rapor, Bitcoin’in ikinci katman teknolojisinin genel bir resmini sunsa da, genel olarak yetersiz ayrıntı içeren ve anlaşılması zor bir şekilde sunulmuştur. Geek web3, Delphi raporuna dayanarak BitVM ve diğer teknolojileri daha sistematik bir şekilde anlamayı denemektedir.

Bitlayer research team and BitVM Chinese community will jointly carry out a series of columns called “Approaching BTC”, focusing on BitVM, OP_CAT, Bitcoin cross-chain bridges and other key topics for popular science, and dedicated to demystifying Bitcoin layer 2 related technologies and paving the way for more enthusiasts.

Metin:

Birkaç ay önce, ZeroSync lideri Robin Linus, “BitVM: Bitcoin Üzerinde Herhangi Bir Şey Hesaplamak” adlı bir makale yayınladı ve BitVM kavramını resmen ortaya attı, Bitcoin’in ikinci katman teknolojisinin ilerlemesini destekledi. Bu, Bitcoin ekosisteminin en devrimci yeniliklerinden biri olarak kabul edilebilir ve Bitcoin’in ikinci katman ekosistemini ateşledi, Bitlayer, Citrea, BOB gibi ünlü projelerin katılımını çekti ve tüm piyasaya canlılık getirdi.

Daha sonra, daha fazla araştırmacı BitVM’yi iyileştirmek için katıldı ve sırasıyla BitVM1, BitVM2, BitVMX, BitSNARK gibi farklı iterasyon sürümlerini piyasaya sürdü. Genel durumu aşağıdaki gibi:

Robin Linus’un geçen yıl önerdiği BitVM uygulama beyaz kağıdının ilk versiyonu, sanal mantık kapı devreleri temel alınarak tasarlanan BitVM uygulama çözümü olan BitVM0 olarak adlandırıldı. 2. Robin Linus, sonraki konuşmalarında ve röportajlarında, resmi olmayan bir şekilde sahte bir CPU tabanlı BitVM1 çözümünü (BitVM1 olarak adlandırılan) tanıttı, Optimism’in off-chain dolandırıcılık kanıtı sistemi Cannon’a benzer şekilde, Bitcoin betiği kullanarak genel bir CPU’nun etkisini simulasyonlayabilir. 3. Robin Linus ayrıca BitVM2’yi de önerdi, bir İzin Verilmeyen tek adımlı etkileşimsiz dolandırıcılık kanıtı protokolü. 4. Rootstock Labs ve Fairgate Labs üyeleri, BitVMX White Paper’ı yayınladılar. BitVM1’e benzer şekilde, Bitcoin script’in genel CPU etkisini (off-chain) simüle etmeyi umuyorlar.

Şu anda BitVM ile ilgili geliştirici ekosistemi inşa ediliyor ve çevre araçların iyileştirilmesi de açıkça görülebiliyor. Geçen yıla kıyasla, şu anda BitVM ekosistemi ilk baştaki ‘havada bir kale’ durumundan ‘belirsiz bir şekilde görülebilir’ hale gelmiştir ve bu da daha fazla geliştirici ve VC’nin Bitcoin ekosistine akın etmesine neden olmuştur.

Ancak çoğu insan için, BitVM ve Bitcoin ikinci katmanla ilgili teknik terimleri anlamak kolay değildir, çünkü önce etrafındaki temel bilgilere sistematik bir şekilde aşina olmanız gerekmektedir, özellikle Bitcoin betiği ve Taproot gibi arka plan bilgisine. Şu anda çevrimiçi olarak mevcut olan referans materyalleri ya çok uzundur ya da anlaması zor bir şekilde açıklanmıştır. Yukarıdaki sorunu çözmeye adanmış olarak, Bitcoin ikinci katmanının çevresindeki bilgileri mümkün olduğunca net bir şekilde anlamak için yardımcı olmak için çaba sarf ediyoruz ve BitVM sistemini sistemsel olarak anlamak için çaba sarf ediyoruz.

MATT ve Vaatleri: BitVM Temel Düşüncesi

Öncelikle belirtmek gerekir ki, BitVM’in temel fikri MATT’tir, yani Merkleize All The Things’tir. Bu, karmaşık program yürütme sürecini göstermek için Merkle Ağacı adı verilen bir ağaç benzeri veri depolama yapısını kullanmayı ve Bitcoin’in doğrulama dolandırıcılığını başarmayı amaçlamaktadır.

MATT, karmaşık bir program ve veri işleme izlerini ifade edebilir, ancak bu verileri doğrudan BTC zinciri üzerinde yayınlamaz, çünkü bu verilerin genel boyutu çok büyüktür. MATT’ın yaklaşımı, verileri sadece zincir dışındaki Merkle ağacında depolamak ve sadece Merkle ağacının en üstündeki özetini (Merkle Root) zincir üzerinde yayınlamaktır. Bu Merkle ağacı genellikle üç temel içerik içerir:

• Akıllı sözleşme betik kodu
• Sözleşme için gerekli veriler
• Akıllı sözleşme, EVM ve diğer sanal makinelerde çalıştırıldığında bellek, CPU kaydedici vb. üzerinde bıraktığı izler

MATT planı altında, yalnızca boyutu son derece küçük olan Merkle Root zincir üstünde depolanır, Merkle Tree’nin içerdiği tam veri kümesi ise zincir dışında depolanır, bu durum “taahhüt” olarak adlandırılan bir yaklaşımı kullanır. Burada “taahhüt” (Commitment) nedir, açıklayalım.

Söz verme, verilerin büyük bir kısmının sıkıştırılmasıyla elde edilen bir ‘parmak izi’ olarak düşünülebilecek basitleştirilmiş bir beyandır. Genellikle, 'söz verme’yi yayınlayan kişi, off-chain’de bulunan bazı verilerin doğru ve hatasız olduğunu iddia eder ve bu off-chain verilerin basitleştirilmiş bir beyanla eşleşmesi gerekmektedir.

Bazı durumlarda, verilerin hash’i verinin kendisi için bir ‘söz’ olarak kullanılabilir. Diğer sözleşme yöntemleri arasında KZG sözü veya Merkle Ağacı bulunur. Layer2’de yaygın olarak kullanılan dolandırıcılık kanıtı protokolünde, veri yayımcısı çıplak veri kümesini zincir dışında yayınlar ve veri kümesinin taahhüdünü zincir üzerinde yayınlar. Birisi zincir dışındaki veri kümesinde geçersiz veri bulursa, zincir üzerindeki veri taahhüdüne meydan okur.

Vaadi kullanarak, ikinci katman büyük miktarda veriyi sıkıştırabilir ve sadece Bitcoin zinciri üzerinde ‘vaat’ olarak yayınlayabilir. Tabii ki, zincir dışında yayınlanan tam veri setinin dış dünyada gözlemlenebilir olması da sağlanmalıdır.

Şu anda birkaç büyük BitVM çözümü olan BitVM0, BitVM1, BitVM2 ve BitVMX gibi benzer soyut yapıları kullanıyorlar.

1. Program dekompozisyonu ve taahhüt: İlk olarak karmaşık programı birçok temel işlem koduna (derleme) ayırın, ardından bu işlem kodlarının gerçekleştirilirken oluşturduğu izleri (bir programın CPU ve bellekte çalıştığı sırada tüm durum değişikliklerini kaydetmek olarak da adlandırılır, Trace) kaydedin. Daha sonra, Trace ve işlem kodlarını içeren tüm verileri düzenleyerek bir veri kümesi oluşturur ve bu veri kümesinin taahhüdünü oluştururuz.

Belirli taahhüt programları, Merkle ağacı, PIOPs (çeşitli ZK algoritmaları), karma işlevi gibi çeşitli biçimlerde olabilir.

2. Varlık teminatı ve ön imza: Veri yayıncıları ve doğrulayıcılar, belirli bir miktar varlığı on-chain’de kilitliyor ve kısıtlamaları olan bir ön imza sürecinden geçmek zorundadır. Bu koşullar, olası gelecekteki durumları hedef alarak tetiklenecektir. Veri yayıncısı kötü niyetli davranırsa, doğrulayıcılar, kanıt sunarak veri yayıncısının varlıklarını alabilir.

3. Veri ve taahhüt yayını: Veri yayıncıları zincir üzerinde taahhütlerini yayınlar, tam veri kümesini zincir dışında yayınlar, doğrulayıcılar veri kümesini arar ve herhangi bir hatanın olup olmadığını kontrol eder. Zincir dışı veri kümesindeki her parça, zincir üstündeki taahhütlerle ilgilidir.

4. Meydan okuma ve ceza: Doğrulayıcı, veri sağlayıcının sağladığı verilerde hata olduğunu tespit ettiğinde, bu verileri doğrudan zincir üzerinde doğrular (bu verileri önceden çok ince bir şekilde kesmek gerekiyor), bu dolandırıcılık kanıtının mantığı budur. Doğrulama sonucu, veri sağlayıcının gerçekten zincir dışında geçersiz veriler sağladığı görüntülenirse, varlıkları doğrulayıcısının elinden alınır.

Özetle, veri yayıncısı Alice, off-chain olarak ikinci katman işlemi sırasında oluşan tüm izleri on-chain’e taşıyarak ilgili taahhütleri yayınlıyor. Bir kısmı hatalı olduğunu kanıtlamak istiyorsanız öncelikle Bitcoin düğümüne bu verilerin ve on-chain taahhütlerin ilişkili olduğunu kanıtlamanız gerekmektedir, yani bu verilerin Alice’in kendisi tarafından açıklandığını kanıtlamanız gerekmektedir, ardından Bitcoin düğümüne bu verilerin hatalı olduğunu belirlemesi için izin vermelisiniz.

Şimdi BitVM’nin genel fikrini neredeyse anladık, tüm BitVM varyantları temelde yukarıda belirtilen kalıptan ayrılamaz. Öyleyse bir sonraki adım, yukarıdaki süreçte kullanılan bazı önemli teknikleri öğrenmeye ve anlamaya başlamaktır, öncelikle en temel Bitcoin betiği ve Taproot ile önceden imzaya başlayın.

Bitcoin Script nedir

Bitcoin ile ilgili bilgiler Ethereum’dan daha zor anlaşılır, hatta en temel transfer işlemi bile UTXO (Harcanmamış İşlem Çıktısı), kilitleme betiği (aynı zamanda PubKey olarak da bilinir) ve kilidi açma betiği (aynı zamanda Sig olarak da bilinir) gibi bir dizi kavramı içerir. Öncelikle bu ana kavramları açıklayalım.

（Bir Bitcoin betik kodu örneği, daha üst düzey bir dil olan daha alt düzey işlem kodlarından oluşur）

Ethereum’un varlık ifadesi, Alipay veya WeChat gibi daha çok benzerdir, her transfer sadece farklı hesapların bakiyelerini artırıp azaltmaktır, bu yöntem hesapları merkezi olarak alırken, varlık bakiyesi sadece hesap altında bir sayıdır; Bitcoin’in varlık ifadesi daha çok altın gibi, her bir altın bloğu (UTXO) sahibini işaretler, transfer aslında eski UTXO’yu yok eder, yeni UTXO’yu oluşturur (sahibin değişebilir).

Bitcoin UTXO iki anahtar alan içerir:

Miktar, bir BTC’nin yüz milyonu olan bir ‘Satoshi’ birimiyle ölçülür.

Kilitli komut dosyası, aynı zamanda ‘komut dosyası açık anahtar (PubKey)’ olarak da adlandırılır ve UTXO’nun kilidini açma koşullarını tanımlar.

Dikkat etmeniz gereken bir şey, Bitcoin UTXO’nun sahipliği kilitli script’ler aracılığıyla ifade edilir, bu da kendi UTXO’nuzu Sam’e devretmek isterseniz, bir işlem başlatarak kendi UTXO’nuzu imha edebilir ve yeni oluşturulan UTXO’nun kilidini sadece Sam’in açabileceği şekilde yazabilirsiniz.

Sonra, Sam bu Bitcoinleri kullanmak istiyorsa, bir kilidi açma betiği (Sig) sunmalıdır. Bu kilidi açma betiğinde Sam, kendisinin Sam olduğunu kanıtlayan dijital imzasını sunmalıdır. Eğer kilidi açma betiği ve yukarıda belirtilen kilitlenme betiği eşleşirse, Sam başkalarına Bitcoinleri açabilir ve transfer edebilir.

(Kilitli komut dosyasıyla eşleşmesi gereken bir kilidin komut dosyasını açma)

Görünüm açısından, her bir Bitcoin işlemi için birden çok Giriş ve Çıkıştan oluşan birçok 01928374656574839201 bulunmaktadır; her bir Giriş, kilidini açmak istediği belirli bir UTXO’yu belirtmeli ve kilidini açma komut dosyasını sunmalı, ardından UTXO’yu kilitlemeli ve yok etmelidir; Çıkış bölümünde, yeni oluşturulan UTXO bilgileri gösterilir ve kilitleme komut dosyasının içeriği dışarıya açıklanır.

Örneğin, bir işlemin Girişinde, kendinizin Sam olduğunu kanıtlarsınız, başkalarının size verdiği birden çok UTXO’yu kilidini açarsınız, birleştirir ve yok edersiniz, daha sonra birçok yeni UTXO oluşturursunuz ve gelecekte xxx’in kilidini açmasına izin verirsiniz.

Belirli olarak, Input verilerinde, hangi UTXO’ların kilidini açmak istediğinizi beyan etmeli ve bu UTXO verilerinin “depolanma konumunu” belirtmelisiniz. Burada dikkat etmeniz gereken bir şey var, Bitcoin ve Ethereum tamamen farklıdır, Ethereum, veri depolamak için sözleşme hesapları ve EOA hesapları olmak üzere iki tür hesap sunar, varlık bakiyesi olarak, sözleşme hesabına veya EOA hesabına kaydedilir, “dünya durumu” adlı veritabanında birleştirilir ve transfer sırasında belirli bir hesaba doğrudan "dünya durumu"ndan değişiklik yapılır, verinin depolama konumuna kolayca ulaşılabilir.

Bitcoin’in dünya durumuna sahip olmayan bir tasarımı yoktur, varlık verileri önceki bloklarda dağıtılmış olarak depolanır (yani çözülmemiş UTXO verileri, her işlemin Çıkışında ayrı ayrı saklanır).

Eğer belirli bir UTXO’yu kilidini açmak istiyorsanız, bu UTXO’nun bilgisinin hangi geçmiş işlemin Output’unda olduğunu belirtmeniz gerekir, bu işlemin ID’sini (yani hash’ini) göstererek, Bitcoin düğümünün geçmiş kayıtlarda aramasını sağlayın. Belirli bir adresin Bitcoin bakiyesini sorgulamak istiyorsanız, tüm blokları baştan sona tarayarak, xx adresi ile ilişkili kilitli olmayan UTXO’ları bulun.

Bitcoin cüzdanı kullanırken, belirli bir adreste bulunan Bitcoin bakiyesini hızlı bir şekilde kontrol edebiliriz. Bu genellikle cüzdan hizmetinin, tüm adresleri tarayarak endekslendiği için, kendi kendine yapılan bir işlemdir ve bize hızlı bir şekilde sorgulama imkanı sağlar.

（Kendinizin UTxo’sunu başkasına gönderdiğinizde, bu UTxo’nun Bitcoin geçmişindeki konumunu işaretlemek için bu UTxo’nun ait olduğu işlem hash/ID’sine göre işlem beyanı oluşturmanız gerekmektedir）

İlginç olan, Bitcoin işleminin sonucunun zincir dışında hesaplandığıdır. Kullanıcılar yerel cihazda işlem oluşturduklarında, Giriş ve Çıkış’ı tamamen oluşturmalıdır, bu işlem çıktı sonucunu hesaplamakla eşdeğerdir. İşlem Bitcoin ağına yayınlandıktan sonra, düğümler tarafından doğrulandıktan sonra zincire eklenir. Bu ‘zincir dışı hesaplama - zincir üzerinde doğrulama’ modeli Ethereum’dan tamamen farklıdır, Ethereum’da yalnızca işlem giriş parametrelerini sağlamanız gerekmektedir, işlem sonucu Ethereum düğümleri tarafından hesaplanır ve çıktı olarak verilir.

Ayrıca, UTXO’nun kilitlenme betiği (Kilitleme) özelleştirilebilir ve UTXO’yu ‘belirli bir Bitcoin adresinin sahibi tarafından açılabilir’ olarak ayarlayabilirsiniz. Adresin sahibi, dijital imza ve açık anahtar (P2PKH) sağlamalıdır. Pay-to-Hash (P2SH) işlem türünde, UTXO kilitlenme betiğine bir Hash ekleyebilirsiniz. Bu Hash’e karşılık gelen betik örneğini gönderebilen ve önceden belirlenmiş koşulları karşılayabilen herkes UTXO’yu açabilir. BitVM’in Taproot betiği, P2SH’ye benzer özellikleri kullanır.

Bitcoin script nasıl tetiklenir

Burada ilk olarak Bitcoin komut dosyasının tetikleme yöntemini tanıtmak için örnek olarak P2PKH’yi kullanıyoruz, ancak tetikleme yöntemini anlayarak daha karmaşık Taproot ve BitVM’yi anlayabiliriz. P2PKH, “Açık Anahtar Hash’e Öde” anlamına gelir, bu şemada, UTXO kilit komut dosyasında bir Açık Anahtar hash ayarlanır ve kilit açılırken hash karşılık gelen Açık Anahtar gönderilmesi gerekir, bu da temelde normal Bitcoin aktarımı fikriyle aynıdır.

Bu noktada, Bitcoin düğümlerinin kilidini açmak için kullanılan açık anahtarı ve kilitlenmiş betiğin belirtilen açık anahtar karmasını doğrulaması gerekmektedir, yani kilidin açılması için sunulan "anahtar"nın ve UTXO’nun önceden belirlenmiş “kilit” ile eşleşmesi gerekmektedir.

Daha ileriye gidersek, P2PKH düğümü, Bitcoin işlemi aldıktan sonra, kullanıcının sağladığı kilidin çözme betiği Sig’inin, kilidini açmak istediği UTXO’nun kilit betiği Pubkey ile birleştirilip BTC betiği yürütme ortamında gerçekleştirilir. Aşağıdaki resim, birleştirme sonucunu göstermeden önceki yürütme işlemine bir örnek olarak verilmiştir:

Muhtemelen okuyucular BTC’nin komut dosyası yürütme ortamını anlamıyor, burada kısa bir tanıtım yapacağız. İlk olarak, BTC komut dosyası iki eleman içerir:

Veri ve İşlem Kodları. Bu veriler ve İşlem Kodları, soldan sağa emir olarak yığına basılacak ve belirtilen mantığa göre yürütülecek ve nihai sonuç elde edilecektir (burada bir yığının ne olduğu hakkında ayrıntılı bilgi verilmemiştir, okuyucular kendi başlarına Chatgpt yapabilirler).

Yukarıdaki resimde, sol tarafta bir kişinin yüklediği Sig açma betiği ve onun dijital imzası ve açık anahtarını içerirken, sağ taraftaki Pubkey kilitleme betiği, UTXO oluşturucusunun bu UTXO’yu oluştururken belirlediği bir dizi işlem kodunu ve veriyi içerir (burada her işlem kodunun anlamını anlamamız gerekmiyor, genel bir anlayış yeterlidir).

Resimde sağ tarafta bulunan kilitli betikteki DUP, HASH160, EQUALVERIFY vb. işlem kodları, sol taraftaki kilidin açma betiğinde taşınan Genel anahtarı alıp hash alır ve kilitli betikte önceden belirlenmiş Genel anahtar hash’ı ile karşılaştırır; eğer ikisi eşitse, açma betiğinde sunulan genel anahtarın, kilit betiğinde önceden belirlenmiş genel anahtar hash’ı ile eşleştiği anlamına gelir, bu da ilk doğrulamayı geçti demektir.

Ancak, bir sorun var, UTXO kilitli betiğin içeriği aslında on-chain olarak herkese açık. İçinde bulunan açık anahtar hash’ini herkes gözlemleyebilir, herkes karşılık gelen açık anahtarı yükleyebilir ve kendisini ‘atanmış’ kişi olarak iddia edebilir. Bu nedenle, açık anahtar ve açık anahtar hash’inin doğrulanmasının ardından, işlemi başlatan kişinin gerçekten de bu açık anahtarın sahibi olup olmadığını doğrulamak gerekmektedir, bu da dijital imzanın doğrulanmasını gerektirir. Kilitli betikteki CHECKSIG işlem kodu, dijital imzanın doğrulanmasından sorumludur.

Özetlemek gerekirse, P2PKH yöntemiyle, işlem başlatan kişi tarafından sunulan kilidi açma betiğinde, açık anahtar ve dijital imza bulunur. Bu açık anahtar, kilitleme betiğinde belirtilen açık anahtar karmasıyla eşleşmeli ve işlemin dijital imzası doğru olmalıdır. Bu koşulları sağlayanlar yalnızca UTXO’yu başarıyla kilidini açabilir.

（Bu resim hareketlidir: P2PKH şemasına göre Bitcoin kilidini açma betiği kavramsal resmi

Kaynak: ** )

Tabii ki, Bitcoin ağı çeşitli işlem türlerini destekler, sadece Pay to public key/public key hash değil, aynı zamanda P2SH (Pay to hash) vb. UTXO oluşturulurken özel olarak belirlenen kilitlenme betiğine bağlıdır.

Burada dikkat edilmesi gereken şey, P2SH planında, kilitlenme komut dosyasında bir Hash önceden ayarlanabilirken, açma komut dosyasının, Hash’e karşılık gelen komut dosyasını tam olarak sunması gerektiğidir. Bitcoin düğümleri bu komut dosyasını çalıştırabilir ve bu komut dosyasında çoklu imza doğrulama mantığı tanımlanmışsa, Bitcoin zinciri üzerinde çoklu imza cüzdanının etkisini gerçekleştirebilir.

Tabii ki, P2SH planı altında, UTXO oluşturucusunun gelecekte UTXO’yu kilidini açacak kişinin Hash’e karşılık gelen betiği önceden bilmesi gerekiyor, her iki taraf da bu bölümün içeriğini bildiğinden, çoklu imzadan daha karmaşık iş mantığını gerçekleştirebiliriz.

Burada bir noktayı açıklamak gerekiyor, Bitcoin Blok zinciri doğrudan hangi UTXO’nun hangi adreslerle ilişkili olduğunu kaydetmez, yalnızca UTXO’nun hangi açık anahtarın/şifreleme fonksiyonunun hash koduyla kilidi açılabileceğini kaydeder, ancak açık anahtarın hash kodu/şifreleme fonksiyonunun hash kodu temelinde ilgili adresi (cüzdan arayüzünde bozuk gibi görünen o kısım) hızlıca hesaplayabiliriz.

Blok Gezgini ve Cüzdan arayüzünde xx adresinde ne kadar Bitcoin olduğunu görebilmemizin nedeni, Blok Gezgini ve Cüzdan proje tarafından bu verileri çözmenize yardımcı olur, tüm blokları tarar ve kilitli betikte belirtilen genel anahtar karma / betik karma bilgilerini hesaplar, ilgili “adresi” bulur ve ardından xx adresinin altında kaç Bitcoin olduğunu gösterir.

SegWit ve Tanık

P2SH’nin fikrini anladığımızda, BitVM’in bağımlı olduğu Taproot’a bir adım daha yaklaştık. Ancak bu noktadan önce, önemli bir kavramı anlamamız gerekiyor: Witness ve SegWit.

Ön incelememizde bahsedilen kilitleme ve kilidin açılması betiklerine, ve UTXO’nun kilidini açma sürecine dikkat ederseniz, bir sorun fark edersiniz: işlemin dijital imzası, kilidin açılması betiğinde bulunur ve imza oluşturulurken kilidin açılması betiği üzerine yazılır (imzalama parametreleri imzanın kendisini içeremez), bu nedenle dijital imza yalnızca kilidin açılması betiği dışındaki kısımları kaplayabilir, yani yalnızca işlem verilerinin ana kısmıyla ilişkilendirilebilir ve işlem verilerinin tamamını kaplayamaz.

Bu durumda, işlemin kilidini açma betiği bir aracı tarafından hafifçe değiştirilse bile doğrulama sonucunu etkilemeyecektir. Örneğin, Bitcoin düğümü veya maden havuzu, işlemin kilidini açma betiği içine başka veriler yerleştirebilir, doğrulamayı ve işlem sonucunu etkilemeden işlem verilerinde hafif bir değişikliğe neden olabilir, sonuçta hesaplanan işlem karmaşıklığı/ID’si de değişebilir. Buna işlem genişletme sorunu denir.

Bu, ardışık olarak birden fazla işlem başlatmayı planlıyorsanız ve işlemler arasında bir sıralama bağımlılığı varsa (örneğin, işlem 3, işlem 2’nin çıktısına referans verir, işlem 2 ise işlem 1’in çıktısına referans verir), ardından gelen işlemler mutlaka önceki işlemlerin kimlik bilgilerine (hash) atıfta bulunmalıdır. Maden havuzu veya Bitcoin düğümü gibi herhangi bir aracı, kilidin çözme betiğindeki içeriği hafifçe değiştirebilir, böylece beklediğiniz gibi zincire bağlanan işlemin hash’i ile uyumlu olmayabilir ve bu nedenle önceden oluşturulan birden fazla sıralı ilişkili işlem geçersiz hale gelebilir.

Aslında, DLC köprüsü ve BitVM2 çözümünde, sıralı ilişkili işlemler toplu olarak oluşturulur, bu yüzden bahsedilen senaryo sıkça karşılaşılan bir durum değildir.

Basitçe söylemek gerekirse, işlem genişletilebilirlik sorunu, işlem kimliği / hash’in hesaplanması sırasında kilidini açma betiğinin verilerinin dahil edilmesi nedeniyle ortaya çıkar ve Bitcoin düğümleri ve diğer aracılar kilidini açma betiği içindeki içeriği ayarlayabilir, bu da işlem kimliğini kullanıcının beklentisiyle uyuşmayan bir hale getirir. Aslında bu, Bitcoin’in erken tasarımında yetersiz düşünülen bir tarihi mirastır.

Sonraki olarak piyasaya sürülen SegWit güncellemesi aslında işlem kimliği ve kilidini açma betiğini tamamen ayırma işlemidir, işlem hash’i hesaplanırken kilidini açma betiği verilerini içermesi gerekmez. SegWit güncellemesini takip eden UTXO kilit betiği, varsayılan olarak bir ‘OP_0’ işlem kodu adı verilen bir işareti işlev olarak belirler; ve karşılık gelen kilidini açma betiği, Sig’den Tanık (Witness) olarak adlandırılmıştır.

Segregated Witness kurallarına uyulduktan sonra, işlem genişletilebilirlik sorunu iyi bir şekilde çözülür, Bitcoin düğümüne gönderilen işlem verilerinin ayarlanmasından endişe etmenize gerek yoktur. Tabii ki, çok karmaşık düşünmemize gerek yok, P2WSH’nin işlevi ve önceki tartışılan P2SH arasında temel bir fark yoktur, UTXO kilitlenme betiğinde bir betik özeti önceden ayarlayabilir ve kilit açma betiğini sunan kişi, özetiyle eşleşen betik içeriğini zincire sunup yürütebilir.

Ancak, eğer uygulamak istediğiniz betik içeriği özellikle büyükse ve oldukça fazla kod içeriyorsa, tam betiği Bitcoin zincirine (her blok boyut sınırına sahiptir) normal yöntemlerle göndermek mümkün olmayabilir. Ne yapmalı? Bu, Taproot’un yardımına ihtiyaç duyar ve on-chain olan betik içeriği için basitleştirilmiş bir işlem yapar. BitVM, Taproot’a dayalı olarak oluşturulan karmaşık bir çözümdür.