Orijinal başlık: Dört Uygulamada BIP-327 MuSig2: Yazıt, Bitcoin Yeniden Alma, BitVM Ortak İmza ve Dijital Varlık Saklama

Orijinal bağlantı: https://blog.bitlayer.org/BIP-327_MuSig2_in_Four_Applications/

Yazar: Qin Wang (CSIRO), Cynic (Chakra), mutourend (Bitlayer), lynndell (Bitlayer)

Bu makale, BIP-327 MuSig2 çoklu imza protokolünün en popüler dört alanda (Yazdırma, Yeniden Alma, BitVM ortak imzalama, Gözetim) uygulamasını tanıtmaktadır.

1. Giriş

Mevcut Bitcoin işlemleri, n sayıda çoklu imzayı doğrulamak için CheckMultiSig'i kullanıyor; bu da, işlemdeki imzalayanların sayısıyla orantılı olarak Bitcoin blok zincirinde imzaların ve genel anahtarların yayınlanması ihtiyacını doğuruyor. Bu yöntem yalnızca işlem katılımcılarının toplam sayısını ortaya çıkarmakla kalmıyor, aynı zamanda imzalayan sayısıyla birlikte işlem ücretlerinin de arttığını gösteriyor. Bu sorunu çözmek için 2018'de araştırmacılar Schnorr çoklu imza protokolünü önerdi: Musig. Ancak bu protokol, imzalayanlar arasında üç turluk iletişim gerektirir ve kullanıcı deneyimi nispeten zayıftır, bu da bu protokolün yaygın bir ilgi ve uygulama çekmemesine neden olur.

2020 yılında MuSig2'nin piyasaya sürülmesiyle etkileşimli imzalarda önemli ilerleme kaydedildi: Üç turlu iletişim iki turda azaltılarak kullanıcılara daha iyi bir deneyim sunuldu. Buna ek olarak MuSig2, bir grup kullanıcının işlemleri doğrulamak için ortaklaşa tek bir imza ve genel anahtar oluşturmasına olanak tanır, gizliliği artırır ve işlem ücretlerini önemli ölçüde azaltır. Üç yıldan fazla süren sürekli iyileştirmenin ardından, Schnorr çoklu imzası (MuSig2) cüzdanlara ve cihazlara uygulandı.

MuSig2 ile ilgili öneriler aşağıdaki gibidir:

● 2022'de Bitcoin BIP-327: BIP340 uyumlu Çoklu İmzalar için MuSig2

● Son zamanlarda https://github.com/achow101/bips/commits/musig2/ , Bitcoin BIP kitaplığıyla birleştirildi.

Bitlayer ve Chakra araştırma grupları, yazıtların, Bitcoin taahhütlerinin, BitVM'nin ve dijital varlık saklamanın zenginliğiyle, BIP-327 MuSig2'nin teorik olarak işlemlere katılması için sınırsız sayıda imzalayıcıyı desteklediğini ve bunun da tasarruf sağlayabileceğini buldu. -zincir alanı ve maliyetlerin azaltılması, gelişmiş güvenlik, gizlilik ve çalışabilirlik vb.

Yazıt: Yazıt, yazıt için Bitcoin'e özelleştirilmiş içerik yazan satoshidir. Bu konsept, doğrudan blockchain üzerinde değişmez ve doğrulanabilir bilgi kayıtları oluşturma yeteneği nedeniyle yaygın ilgi gördü. Yazıtlar, basit metinlerden karmaşık veri yapılarına kadar çeşitlilik gösterebilir ve dijital varlıkların orijinalliğini ve kaynağını doğrulamak için güvenilir bir yol sağlar. Blockchain yazıtlarının kalıcılığı ve güvenliği, onu dijital kimlik doğrulama, sahiplik kanıtı ve kritik bilgilerin zaman damgası gibi uygulamalarda oldukça değerli kılmaktadır. Yazıtlar için MuSig2, imza ve doğrulama hızını artırabilir, döküm sürecinde gereken işlem ücretlerini azaltabilir ve zincir dışı indeksleyiciler için gerekli güvenliği sağlayabilir, böylece genel yazıt ekolojisinin güvenilirliğini artırabilir.

Bitcoin Staking: Bitcoin sahiplerinin taahhüt edilen varlıklarını çeşitli blockchain protokollerini veya merkezi olmayan finans (DeFi) uygulamalarını desteklemek için yeniden tahsis etmelerine yönelik bir mekanizma. Bu süreç, Bitcoin'in blockchain ekosisteminde birden fazla rol oynamasına, faydasını ve kazanç potansiyelini artırmasına olanak tanır. Kullanıcılar yoğun stake etme faaliyetlerine katılarak Bitcoin varlıklarını korurken diğer ağların güvenliğine ve işlevselliğine katkıda bulunabilirler. Bu yenilikçi yaklaşım, daha entegre ve verimli bir blockchain ekonomisini desteklemek için Bitcoin'in likiditesinden ve güvenliğinden yararlanıyor. Çünkü Bitcoin, likidite stakingini gerçekleştirmek için gereken sözleşme yeteneklerinden yoksundur ve UTXO yapısı, taahhüt edilen tokenin herhangi bir değerinin geri çekilme işleviyle pek uyumlu değildir. Bu nedenle, Bitcoin'in likidite stakingini uygulamak için MuSig2'ye ihtiyaç vardır.

BitVM: Bitcoin ağında akıllı sözleşme işlevselliğini uygulamaya yönelik bir çerçeve. Karmaşık akıllı sözleşmeleri doğal olarak destekleyen Ethereum Sanal Makinesi'nin (EVM) aksine BitVM, Bitcoin'in komut dosyası oluşturma yeteneklerini daha karmaşık programlanabilir işlemlere izin verecek şekilde genişletmek üzere tasarlanmıştır. Bu gelişme, Bitcoin'in merkezi olmayan uygulamaları (dApp'ler) ve karmaşık finansal uygulamalar için yeni yollar açarak, basit kodlama dilinin sınırlamalarını ortadan kaldırıyor. BitVM'nin piyasaya sürülmesi, Bitcoin'in kullanımında önemli bir evrime işaret ediyor ve Bitcoin ile diğer daha esnek akıllı sözleşme platformları arasında bir köprü oluşturuyor. Soft fork'a ihtiyaç duymayan BitVM, önceden imzalamayı gerektirir, n'den 1'i güven varsayımlarını ve izinsiz sorgulama işlevselliğini etkinleştirir. Güven varsayımının mümkün olduğu kadar küçük olabilmesi için n değerinin mümkün olduğu kadar büyük olması gerekmektedir. Ancak, büyük ölçekli çoklu imzaları doğrulamak için kullanılan mevcut CheckMultiSig betiği, son derece yüksek işlem ücretleri gerektiriyor ve bu da bunu mümkün kılmıyor. MuSig2, n'nin değerini mümkün olduğu kadar büyük yapabilir, böylece n'nin değeri Bitcoin blokları ve yığın boyutuyla sınırlı kalmaz, koordine edilebilecek gerçek ortak imzalayıcı sayısına bağlıdır ve maliyeti düşüktür.

Dijital varlık saklama: Kripto para birimleri, NFT'ler (değiştirilemez tokenler) ve diğer tokenleştirilmiş varlıklar gibi dijital varlıkları güvenli bir şekilde depolamak ve yönetmek için blockchain'in kullanılması. Bu, özel anahtarların korunmasını, erişim kontrolünün sağlanmasını ve siber tehditlere karşı koruma sağlanmasını içerir. Eşik imzası, dijital varlıkların güvenlik yönetiminde önemli bir rol oynar ve şifreleme anahtarlarını dağıtılmış bir şekilde yönetir. Bu teknik, özel anahtarı birden fazla paylaşıma bölerek farklı katılımcılara dağıtır. Bir işlemi imzalamak veya bir dijital varlığa erişmek için, önceden belirlenmiş bir eşik sayıda hissenin birleştirilmesi gerekir; böylece hiçbir tarafın varlığı tek taraflı olarak kontrol edememesi veya kötüye kullanamaması sağlanır. Bu, anahtar güvenliği ihlali, içeriden gelen tehditler ve tek hata noktaları riskini azaltarak güvenliği artırır. Ayrıca eşik imzaları, dijital varlık yönetimi için daha sağlam ve esnek bir yönetişim modeli sunarak merkezi olmayan kuruluşlarda ve çok partili sistemlerde güvenli işbirliğine ve karar almaya olanak tanır. Eşik imzalarını MuSig2 ile birleştirmek, yazıtların, Bitcoin taahhütlerinin, BitVM ortak imzalamanın, dijital varlık saklamanın vb. uygulama ihtiyaçlarını aynı anda karşılayabilir ve bir balıktan dört fayda elde edebilir.

2. MuSig2 ilkesi ve uygulama özellikleri

2.1 MuSig2 prensibi

2.2 MuSig2 uygulama özellikleri

Son zamanlarda Bitcoin Core'a katkıda bulunanlar Andy Chow birkaç BIP teklifi önerdi:

● BIP-328: MuSig2 Toplu Anahtarları için Türetme Şeması [Uygulama katmanı]: BIP 327 MuSig2 toplu genel anahtarını temel alan BIP 32 genişletilmiş genel anahtarlarının oluşturulmasını ve anahtar türetme için bu BIP 32 genişletilmiş genel anahtarlarının kullanılmasını açıklar.

● BIP-373: MuSig2 PSBT Alanları [Uygulama Katmanı]: BIP174 Kısmen İmzalı Bitcoin İşlemine (PSBT) rastgele sayılar, genel anahtarlar ve kısmi imzalar için alanlar eklendi.

● BIP-390: musig() Tanımlayıcı Anahtar İfadesi [Uygulama katmanı]: MuSig2 cüzdanı tarafından kontrol edilen bir işlem çıktısı yöntemi sağlar.

Bu, MuSig2'nin benimsenmesi ve cüzdan entegrasyonu için gerekli bir adımdır. Bu BIP'ler ve teknik özellikler, bir MuSig2 cüzdanını entegre etmek için ihtiyacınız olan tek şeydir. Ek olarak, birçok cüzdan geliştiricisi ve işbirlikçi barındırma çözümleri (bkz. Taproot'un çoklu imzaya hazır hale getirilmesi ) uzun süredir MuSig2 protokolünün standartlaştırılmasını talep ediyordu. Artık resmi bir BIP uygulandığında topluluk bunu kendisi inceleyebilir, geri bildirimde bulunabilir ve farkındalığın artmasına yardımcı olabilir.

3. MuSig2 dört balık yer.

3.1 Yazıt

Yazıtların en tipik uygulaması, Bitcoin üzerinde bir NFT tokenı olarak kabul edilebilecek BRC20'yi oluşturmaktır. Temel tasarımı, Ordinals protokolü aracılığıyla her satoshideki verileri yakmak ve basit işlemleri uygulamaktır. Genel olarak burada üç adım var.

İlk adım, her Satoshi'nin benzersizliğini takip etmektir. Satoshi, Bitcoin'in en küçük ve bölünmez birimi olduğundan ve toplam Bitcoin sayısı 21 milyon olduğundan kullanılabilir Satoshi'nin üst sınırı 2,1 katrilyondur. Bitcoin'deki her Satoshi benzersiz bir varlıktır ve benzersizdir. Bitcoin'de NFT kurmanın temelinde yatan mantık budur. Burada her satoshiye bir ileri sıra numarası atanacak (Ordinals protokolü aracılığıyla) ve doğru izleme ve düzenli işlemeyi sağlamak için ilk giren ilk çıkar esasına göre yönetilecek. Şekilde gösterildiği gibi, her Satoshi'nin örnekte Satoshi #1, #11 ve #31 olarak gösterilen tam bir sıralı dizinin parçası olduğunu görüyoruz.

İkinci adım, JSON formatını ve Taproot betiğini kullanarak mesajı mesaja gömmektir. Bu mesajlar SegWit alanlarında saklanarak süreci verimli ve güvenli hale getirir. Komut dosyası, JSON'u içeriğin içine, yani OP alanının içine yerleştirir. OP_IF koşullu yargılamayı başlatır ve gömülü içerik OP_FALSE alanından sonra düzenlenecektir. Bu koşul, sonraki içeriğin yürütülmemesini ve yalnızca saklanmasını sağlar. Bu nedenle yeni eklenen JSON tamamen bu satoshi'ye kaydedilir. Şekil 1'de gösterilen JSON yerleştirmesi, BRC20 belirtecinin dağıtımına yönelik temel parametreleri içerir. Protokolü "brc-20", operasyon tipini "konuşlandırma", token sembolünü "ordi", maksimum arzı 21 milyon olarak ve basım limitini 1.000 olarak belirtiyor. Burada, bu süreci destekleyen önemli BIP'ler arasında Schnorr İmzası (BIP340), Taproot (BIP314), Tapscript (BIP342) ve SegWit (BIP141) yer alır.

BRC20 tokenlarını tanımlayan üçüncü adım, indeksleyici tarafından yönetilen zincir dışı durumu içerir. Bu indeksleyiciler, geçmiş işlemlere dayanarak BRC20 tokenlerinin durumunu ayrıştırır ve yorumlar. Bilgilerin güncel olduğundan emin olmak için zincir içi verileri ayrıştırır, token durumunu kontrol eder ve bakiyeleri güncellerler. Ek olarak, hafif istemci, kullanıcıların BRC20 tokenlerini sorunsuz bir şekilde tanımlamalarına ve yönetmelerine olanak sağlamak için bu bilgileri entegre eder.

Şekil 1. BRC20 tokenlarına yönelik temel adımlar

Burada dağıtım ve basım işlemleri yalnızca bir işlem gerektirirken, BRC20 tokenlarının aktarılması (yani aktarım işlemi) iki işlem gerektirir. İlk işlemde, göndericiye, basım işlemine çok benzeyen temel bir zincir üstü yakma işlemi gerçekleştirilir. İkinci işlemde ise göndericiden alıcıya aktarım başka bir işlemle tamamlanır. Daha sonra zincir dışı indeksleyici durumu günceller. Koşullar karşılanırsa, indeksleyici ilgili tutarı gönderenin bakiyesinden düşer ve alıcının bakiyesine aktarır.

Bitcoin'in Taproot yükseltmesinde Schnorr imzalarının kullanıldığını, Bitcoin işlemlerinin gizliliğinin ve verimliliğinin arttığını gözlemleyebiliyoruz. Schnorr çoklu imzanın yükseltilmiş sürümü (MuSig2), Taproot'un yükseltilmiş kısmına son derece sezgisel ve doğal bir şekilde entegre edilebilir ve yazıt ve BRC20 gibi oluşturma süreciyle doğal olarak bağlantı kurar. Yeni yükseltilen yazı, imza ve doğrulama hızını mevcut temelde artırabilir ve döküm sürecinde gerekli olan işlem ücretlerini daha da azaltabilir.

Başka bir uygulama ise zincir dışı indeksleyici kısmından geliyor. Mevcut indeksleyici esas olarak zincir dışı bir doğrulayıcıdır ve farklı hizmet sağlayıcılar kendi indeksleyici güncelleme hizmetlerini sağlar. Burada ortaya çıkan risk, birçok yan zincir ve Rollup hizmet sağlayıcısı gibi, kullanıcılar da nispeten merkezi yönetime sahip hizmet sağlayıcılara güvenememektedir. Bu indeksleyiciler kullanıcıların doğal fonlarını saklamasa da hatalı kotasyonlar veya gecikmiş kotasyonlar kullanıcı işlemlerinin başarısız olmasına neden olacaktır. MuSig2 çoklu işaret fikri sunar. Kontrol noktası mekanizmasına benzer şekilde, aynı indeksleyiciyi ortaklaşa sürdürmek ve her seferinde belirli bir düğümde imzaları ortaklaşa doğrulamak ve imzalamak için nispeten merkezi olmayan ve çok sayıda doğrulayıcı tanıtılabilir. Kullanıcılar en azından endeksten önce indeksleyicinin zincir üzerindeki kaydı ve işlem akışını dürüst ve güvenilir bir şekilde sunduğuna güvenebilirler. Bu şekilde MuSig2, zincir dışı indeksleyiciler için gerekli güvenliği sağlar ve böylece genel yazıt ekolojisinin güvenilirliğini artırır.

3.2 Bitcoin taahhüdü

Yerel rehin mekanizmalarına sahip Ethereum gibi PoS zincirlerinden farklı olarak Bitcoin, PoW mutabakat mekanizması tarafından sürdürülen bir blok zinciridir ve rehin fonksiyonunun uygulanması için ek mekanizmalar gerektirir. Şu anda en bilineni Babylon'un önerdiği Bitcoin staking çözümüdür.

Babylon rehin mekanizmasında kullanıcılar rehin işlemini Babylon tarafından tanımlanan, rehin işlemi olarak adlandırılan ve rehin çıktısı üreten BTC rehin scripti üzerinden tamamlarlar. Staking çıkışı bir Taproot çıkışıdır, dahili anahtar NUMS noktasına ayarlanarak devre dışı bırakılır ve staking işlevini uygulamak için üç komut dosyası yolu mevcuttur. Bunlar:

● Zaman kilitleme yolu: rehin kilitleme işlevini gerçekleştirin;

● Taahhütten vazgeçme yolu: taahhüdü erken sonlandırma işlevinin farkına varın;

● Ceza yolu: Kötülük yaparken sistemin cezalandırma fonksiyonunu gerçekleştirir.

Bitcoin rehin mekanizması, Bitcoin sahiplerine daha güvenli bir faiz kazanma çözümü sağlar ve Bitcoin varlıklarının faydasını artırır. Ancak bu stake etme Bitcoin’in likiditesine bir ölçüde zarar veriyor. Bununla birlikte, Ethereum staking mekanizmasının yıllarca araştırılması, Bitcoin staking'in önünü açmıştır ve likidite staking bu sorunu çözmek için kullanılabilir.

Likidite stake etme, varlığın koruyucusu olarak yeni bir rol getirir. Kullanıcılar varlıklarını likit staking projesinin saklama adresine yatırır ve karşılık gelen oranda Liquid Staking Token (LST) alırlar. Likidite staking projesi, toplanan varlıkları yerel olarak rehin edecek ve LST sahipleri staking gelirini otomatik olarak paylaşacak. Ek olarak, LST sahipleri ikincil piyasada doğrudan LST ticareti yapabilir veya yerel rehinli varlıklar karşılığında LST yakabilir.

Ethereum'da likidite staking akıllı sözleşmeler yoluyla uygulanabilir. Ancak Bitcoin, likidite staking'i uygulamak için gereken sözleşme yeteneklerinden yoksundur ve UTXO mimarisi, LST'nin herhangi bir para birimindeki para çekme işleviyle pek uyumlu değildir. Şu anda OP_CAT gibi sözleşme işlem kodları çevrimiçi olmadığından, Bitcoin işlem çıktılarının gelecekte nasıl harcanabileceğine ilişkin kısıtlamaları etkili bir şekilde uygulamanın bir yolu yoktur. Bu nedenle Bitcoin likidite stakingini uygulamak için MuSig2'ye ihtiyaç vardır.

Şekil 2'de gösterildiği gibi Chakra likidite staking'inde kullanıcılar öncelikle Bitcoin'i MuSig2 tarafından desteklenen çoklu imzalı bir adrese aktarırlar. Olay, indeksleyici tarafından yakalanır ve kullanıcı için ccrBTC'yi basmak üzere zincir üstü sözleşme çağrılır. Çoklu imza adresindeki Bitcoin'ler Babil'e rehin edilecek. Kullanıcılar crrBTC'yi tutarken Babylon staking'den getiri almaya da devam edebilirler. Kullanıcı rehini sonlandırmak istediğinde crrBTC'yi imha edebilir. Indexer imha olayını tespit ettikten sonra rehin kaldırma işlemini gerçekleştirecek ve Bitcoin'i kullanıcıya iade edecektir. Ek olarak, kullanıcılar crrBTC'yi Bitcoin ile değiştirmek için doğrudan ikincil piyasada işlem yapabilirler.

Şekil 2. Çakra likidite staking süreci

Kendi kendine saklama stakingi ile karşılaştırıldığında, MuSig2 tarafından desteklenen likidite stakingi, dijital varlık saklamanın güvenliğini korumak için birden fazla tarafı devreye sokar ve aynı zamanda taahhüt edilen Bitcoin'in likiditesini serbest bırakarak LST'nin BTCFi'de daha büyük bir rol oynamasına olanak tanır. daha fazla fayda ile.

3.3 BitVM Cosign

Robin Linus, durum bilgisi olan Bitcoin komut dosyalarını uygulamak için Lamport'un tek seferlik imzasını kullanarak BitVM: Compute Everything on Bitcoin teknik incelemesini Ekim 2023'te yayınladı. Bu sistem, yeni işlem kodları gibi yumuşak çatalları tanıtmadan, iyimser bir meydan okuma mekanizması yoluyla Turing-tamamlanmış Bitcoin sözleşmelerini uygulayabilir. Bu sistem yalnızca OP_BOOLAND ve OP_NOT işlem kodlarıyla oluşturulmuş NAND kapısı ikili devrelerini kullanıyor; bu, Bitcoin üzerinde keyfi hesaplamaları doğrulamanın zorlu mekanizmasını gösteriyor, ancak program tarafından derlenen devrenin ölçeği büyük ve pratik uygulama için neredeyse pratik değil. Daha sonra BitVM1 , programları ifade etmek için RISC-V talimatlarını kullanır ve verimliliği artırmak için Bitcoin sistemindeki tüm işlem kodlarından tam olarak yararlanır.

BitVM2, BitVM1'i iki açıdan genişletir. (1) BitVM1'deki meydan okuyanlar, ilk kuruluma katılan ittifak üyeleridir; BitVM2'deki meydan okuyanlar ise herhangi bir katılımcıdır. Bu nedenle, BitVM1'deki ittifak üyeleri kötülük yapmak için gizli anlaşma yapma riskiyle karşı karşıyayken, BitVM2'deki rakipler izinsizdir ve ittifak üyeleri kötülük yapmak için komplo kuramaz. (2) BitVM1 birden fazla meydan okuma turu gerektirir ve uzun bir döngüye sahiptir; BitVM2 ise ZK Proof'un basitliğinden ve Taptree'nin komut dosyası ifade etme yeteneğinden tam olarak yararlanır. Mücadele döngüsü yalnızca 2 turdur ve önceden imzalanmış işlemlerin sayısıdır. Sabitleme için gereken yaklaşık 100 işlemden yaklaşık 10 işleme düşürülmüştür. Spesifik olarak, BitVM1'in birden fazla etkileşim turundan sonra programda yanlış yürütülen RISC-V talimatlarını bulmak için dikotomi yöntemini kullanması gerekir; BitVM2 ise artık programın kendisi olmadığını, programın doğru şekilde yürütüldüğünü doğrulayan ZK kanıtı olduğunu doğrular. BitVM2 doğrulama algoritması birden fazla alt fonksiyona bölünmüştür ve her bir alt fonksiyon bir Tapleaf'e karşılık gelir. Zorlandığında, Operatörün her bir alt fonksiyonun değerini açıklaması gerekir. Herhangi bir tutarsızlık varsa, herkes bunu cezalandırmak için bir Reddetme işlemi başlatabilir.

Şekil 3'te gösterildiği gibi, BitVM2 çok sayıda n-of-n ön işaret gerektirir. Kullanıcılar hangi Operatörün kendileri için ön ödeme yapacağını bilmediğinden, bir Sabitleme işlemi başlatmadan önce BitVM Alliance'ın Take1, Take2, Assert, Disprove ve Burn'ün n'den fazla işlemine önceden imza atması gerekir. Ancak kullanıcı her bir alt işlemin ön imzalamasının tamamlandığını onayladıktan sonra, fonlar aslında Peg-in işlemi yoluyla n'den n'ye kadar çoklu imza kontrol adresine yatırılacaktır. Kullanıcı para çekmek istediğinde Peg-out işlemini başlatabilir ve Operatörlerden biri ödemeyi peşin olarak yapar ve ardından para çekme işlemi tamamlanabilir.

Operatörün avans Bitcoin'i geri ödeyebilmesi için önce 2 BTC rehin vermesi gerekir. Kimse itiraz etmezse, Operatör Take1 işlemi yoluyla başarıyla geri ödeme yapabilir. Operatör kötülük yaparsa, herkes 1 BTC'lik kitle fonlaması yaptıktan sonra bir meydan okuma başlatabilir. Zorlukla karşılaşıldığında, Operatör yanıt vermezse Burn işlemi gerçekleştirilir, yani 1,9 BTC imha edilir ve Burn işleminde kalan 0,1 BTC, Operatör yanıt verirse alıcı adrese verilir, Assert işlemi yapılır; uygulanmış.

● Durum 1: Belirli bir alt fonksiyon değerinin tutarsız bir şekilde açığa çıkması durumunda herkes Disprove işlemi başlatabilir, yani Disprove işleminde 1 BTC imha edilir ve alıcı adrese 1 BTC verilir.

● Durum 2: Alt fonksiyon değerleri tutarlı bir şekilde ortaya çıkarsa, Operatöre 2 hafta sonra Take2 işlemi yoluyla başarıyla geri ödeme yapılabilir.

Şekil 3. BitVM 2 işlemi

BitVM2 sisteminde, BitVM Alliance'ın n sayıda işlemi önceden imzalaması gerekir: Take1, Take2, Assert, Disprove ve Burn. BitVM güven varsayımı 1/n'dir; burada n değeri ne kadar büyük olursa güven varsayımı da o kadar düşük olur. Ancak bu kadar büyük ölçekte çoklu imza, son derece yüksek işlem ücretleri gerektiriyor ve bu da onu Bitcoin'de neredeyse imkansız hale getiriyor. MuSig2, çok sayıda çoklu imzayı tek bir imzada toplayarak işlem ücretlerini en aza indirebilir ve teorik olarak koordine edilebilecek gerçek ortak imzacı sayısına bağlı olarak 1.000 veya daha büyük bir n değeri gibi sonsuz bir n değerini destekler.

BitVM dağıtıldığında, BitVM Alliance'ın n'den fazla çoklu imza harcaması yoluyla gizli anlaşma yapmasını önlemek için Peg-in kurulduktan sonra, n ortak imzacıdan en az birinin özel anahtarı silmesi gerekir. Bu, BitVM köprüsündeki fonların ancak Operatör tarafından dürüstçe aktarıldıktan sonra geri ödeme işlemleri kullanılarak harcanmasına olanak tanır. Bu nedenle BitVM köprüsünün güvenliği artırıldı.

3.4 Dijital varlık saklama

Toplu imzalar, birden fazla imzanın tek bir imzada birleştirilmesine olanak tanıyarak doğrulama sürecini basitleştirir ve verimliliği artırır. Şekil 4'te gösterildiği gibi, Alice, SigA imzasını oluşturmak için KeyA özel anahtarının tamamını kullanır ve Bob, SigB imzasının tamamını oluşturmak için KeyB özel anahtarının tamamını kullanır. Daha sonra SigA ve SigB, AggSig toplu imzasını oluşturmak için toplanır. Bu yaklaşım yalnızca her bir katılımcının bağımsızlığını ve sorumluluğunu sağlamakla kalmaz, aynı zamanda her iki tarafın katılımının yetkili herhangi bir işlemi gerçekleştirmek için gerekli olması nedeniyle genel sistemin güvenliğini de artırır. Bu işbirliği sayesinde Alice ve Bob, daha güvenli ve daha verimli bir dijital varlık yönetimi elde edebiliyor, tek nokta hatalarını ve kötü niyetli işlemleri önlüyor, aynı zamanda işlem karmaşıklığını ve doğrulama maliyetlerini basitleştiriyor.

Öte yandan Alice, dağıtılmış cihazları kullanarak dijital imzalar oluşturmak ve yönetmek için eşik imzalarını kullanır ve herhangi bir cihaz tek başına tam imza özelliklerine sahip olamaz. Spesifik olarak, eşik imza şeması, özel anahtarı birkaç parçaya böler ve her cihaz, özel anahtarın bir parçasını saklar. Geçerli bir imza, yalnızca belirli sayıda cihazın (yani bir eşiğe ulaşılması) işbirliği yapması durumunda oluşturulabilir. Bu mekanizma, dijital varlıkların güvenliğini büyük ölçüde artırır çünkü özel anahtar parçasının bir kısmı sızdırılsa bile saldırgan hâlâ geçerli bir imza oluşturamaz. Ayrıca eşik imzaları tek arıza noktalarını önleyebilir ve sistemin sağlamlığını ve sürekliliğini sağlayabilir. Bu nedenle eşik imzaları, dijital varlıkların dağıtılmış yönetimi için etkili ve güvenli bir çözüm sağlar.

Şekil 4. Toplu imza, eşik imza

Şekil 4. Toplu imza, eşik imza

Hem Alice hem de Bob, ilgili dijital varlıklarını kontrol etmek için eşik imzaları kullandıklarında ve yukarıda belirtilen yazıt, Bitcoin rehin, BitVM ortak imzalama ve diğer uygulamalar gibi bir işlemi çoklu imzalamak için toplu imzalar (MuSig2) kullanmaları gerektiğinde. Bu durumda birden fazla balık elde etmek için toplam imzayı eşik imzayla birleştirmek gerekir.

Şekil 5. Toplu imza ile eşik imzanın birleştirilmesi

Şekil 5'te gösterildiği gibi, Alice ve Bob, dijital varlık saklama için eşik imzalarını kullandıklarında, ne KeyA ne de KeyB özel anahtarlarının tamamı görünmez, yalnızca karşılık gelen özel anahtar parçaları görünür (ShareA1, ShareA2, ShareA3) ve ( ShareB1, PaylaşB2, PaylaşB3). Şu anda, eşik imzaları, sırasıyla imza SigA ve imza SigB'yi oluşturmak için özel anahtar parçalarına (ShareA1, ShareA2, ShareA3) ve (ShareB1, ShareB2, ShareB3) dayalı olarak çalıştırılır. Daha sonra SigA imzası ve SigB imzası, AggSig toplu imzasını oluşturmak için toplanır. Tüm süreç boyunca KeyA ve KeyB özel anahtarlarının tamamı görünmez. Bu nedenle, aynı anda birden fazla uygulama gereksinimini karşılamak için eşik imzaları ile toplu imzaların birleştirilmesi sağlanır.

Referanslar