Özet

Bu makale, Bitcoin'de ZK doğrulamasını etkinleştirmek için pratik yöntemlere inmektedir. Bitcoin'in UTXO modeli, komut dosyası sınırlamaları, Taproot, OP_CAT, BitVM ve Zincir Durumu Kanıtları gibi konuları ele almaktadır. Bitcoin protokolüne ZK'yi entegre etmenin kaçınılmaz olduğu net bir şekilde ortaya konmaktadır. İki potansiyel yol vurgulanmaktadır: biri OP_CAT komutunu yeniden tanıtarak SNARK doğrulamasını doğrudan Bitcoin komut dosyalarını desteklemek - bu değişikliğin sonunda onay olasılığı yüksek olan bir değişikliktir. İkinci yaklaşım, sahtekarlık kanıtlarını içeren BitVM etrafında dönüyor. Ayrıca, ZeroSync ekibinin Zincir Durumu Kanıtları için önerisi, düğüm istemcileri için tarihsel verilerin doğrulama maliyetini azaltmayı amaçlamaktadır.

Ana Metin: Bitcoin'i tam anlamak için onu bir sosyal sistem olarak görmenin faydalı olduğu söylenebilir. Bitcoin'in erken günlerinde, Bitcoin'in yaratıcıları düğümlerin çalıştırması gereken yazılımı belirlediler, toplumu yöneten kuralları belirlemek gibi. Bitcoin'in istikrarı, temel doğası hakkında geniş bir uzlaşmaya dayanmaktadır, bu da Bitcoin'in özünde ne olduğu gibi sorulara yol açar ve Bitcoin'in neye evrileceği konusunda tartışmaları beraberinde getirir. Bununla birlikte, bu sorular üzerinde uzlaşmaya varmak son derece zordur, çünkü görüşler geniş ölçüde farklılık gösterir ve sürekli olarak evrim geçirir.

Bu, Bitcoin'in tarihsel kökenine geri döner. Satoshi Nakamoto Bitcoin beyaz kağıdını yayımladığında, şunları söyledi: “Yepyeni bir elektronik ödeme sistemi üzerinde çalışıyorum. Bu sistem tamamen P2P tabanlıdır ve herhangi bir üçüncü tarafa bağımlı olmayı gerektirmez.” Bu bölüm, Cypherpunks posta listesinde (1992 yılında kurulan, gizlilik koruması ve şifreleme teknolojisiyle ilgilenen bir grup kriptograf ve teknoloji tutkunu tarafından oluşturulan bir e-posta tartışma grubu) yayımlandı.

Ancak, Bitcoin ürün tasarım seviyesinde veri iletimini sınırlar. Birim zamanda işleyebileceği işlem sayısı sınırlıdır. İşlenecek işlem sayısı hızla artarsa, kullanıcılar işlemi hızlı bir şekilde tamamlamak için bir fiyat savaşı başlatacak ve hızlı bir şekilde artan işlem ücretleri ödeyecektir. Bitcoin ağındaki en yüksek işlem ücretine sahip tek işlem, 2024 yılında blok ödülünün yarıya indirildikten sonra gerçekleşti ve zincirde orta öncelikli bir işlem için işlem ücreti 150 doları buldu. Bitcoin ağındaki pahalı işlem ücretleri bir sorun haline gelmiştir.

İşlem ücreti sorununu çözmek için, insanlar Lightning Network'ün geliştirilmesine çok fazla kaynak yatırdı. Ancak 2016 yılında yayınlanan bir makaleye göre, Lightning Network uygulamada sadece on milyonlarca kullanıcıyı destekleyebiliyor ve küresel bir ödeme sistemi vizyonunu gerçekleştiremiyor. Aşırı pahalı işlem ücretlerinin yanı sıra, Bitcoin'in hayal ettiği anonimliği asla başaramadığı başka bir sorun var.

Satoshi Nakamoto, bir kripto tartışma grubunda, Bitcoin'in gizlilik koruma fonksiyonuna ve işlem başlatıcısının tamamen anonim olabileceğine dikkat çekti. Ancak, işlem başlatıcısının KYC'ye ihtiyacı olmasa da, Bitcoin zincirindeki işlem verileri birçok bilgi sızdırır ve kullanıcı gizliliğini büyük ölçüde ortaya çıkarır. Yukarıdaki sorunları belirli bir ölçüde çözen bazı gizlilik fonksiyonlarına sahip cüzdan istemcileri olsa da, bu cüzdan istemcilerinin geliştiricileri çeşitli tehditlerle karşı karşıya kalmaktadır. Örneğin, Samourai CoinJoin cüzdanının geliştiricisi FBI tarafından Nisan 2024'te tutuklandı ve bir hafta sonra Wasabi cüzdanının geliştiricisi CoinJoin koordinasyon bileşenini kapattı. Açıkça, bu sözde gizlilik cüzdanları tamamen kullanıcıların güvenine değer değildir.

Özetle, Bitcoin'in birçok kavramı bugüne kadar gerçekleşmekten uzak, ilgili teknolojiler hala sürekli geliştirilmektedir. Yine de, Bitcoin topluluğundaki birçok kişi, Bitcoin'in protokol tasarımının değişmeden kalması gerektiğine inanıyor, ancak benim gibi birçok kişi de Bitcoin'e iyileştirmeler yapmaktan tutkulu. Peki, Bitcoin hangi yönde gelişmeli?

Yukarıdaki sorunlara yanıt olarak, Bitcoin topluluğunda birçok öneri bulunmaktadır ve en iyi teorik sonuçları olanlar ZK ve SNARK'larla ilgili olmalıdır. ZK ve SNARK'lar ile aşağıdaki özellikler elde edilebilir:

1. Önemli ölçüde geliştirilmiş gizlilik: işlem tutarını homomorfik Peterson taahhüdü ve Aralık Kanıtı kullanarak geliştirilmiş gizlilik sağlamak (örneğin, Blockstream'in Element yan zincirinde olduğu gibi); işlem izlerini gizlemek için bağlantılı imzalar kullanmak (örneğin, Monero); gerçekten özel işlemler yapmak (örneğin, Zcash).

2. İşlem geçirgenliğini artır

Bitcoin'in mevcut sorunlarını çözebilecek birçok teknik çözüm bulunmasına rağmen, neden bu teknolojiler Bitcoin protokolüne entegre edilmedi? Cevap, protokolün değiştirilmesinin zorluğunda yatıyor. Ethereum gibi, Bitcoin'in Ethereum Vakfı gibi merkezi bir organizasyonu yok. Herhangi bir protokol değişikliği, geniş çaplı müzakere ve çıkarların dengelemesini gerektiren yüksek düzeyde topluluk uzlaşısı gerektirir. Sonuç olarak, Ethereum'un EVM işlem kodlarını düzenli olarak güncellerken, Bitcoin'in protokolü, başlangıcından bu yana çok az değişiklik görmüştür.

Protokolün değiştirilmesindeki zorluklar bazı açılardan faydalıdır. Değişiklikler kolayca uygulanabilseydi, kötü niyetli değişiklikler veya saldırılar daha olası olurdu. Bu, şu soruyu ortaya çıkarıyor: Bitcoin'in performansı protokolü değiştirmeden nasıl iyileştirilebilir?

Bunu yanıtlamak için Bitcoin'in bazı temellerini tekrar ziyaret etmemiz gerekiyor. Birine Bitcoin transfer ettiğinizde bir işlem oluşturursunuz ve bunu Bitcoin ağına yayınlarsınız. İşlemin çıktı verileri transfer edilen BTC miktarını belirtir. Alıcı daha sonra aldığı BTC'yi harcamak için yeni bir işlem oluşturabilir ve bu süreçte yeni çıktı verileri oluşturur.

Bitcoin'in Ethereum gibi küresel bir durumu olmadığını, özellikle hesap durumunun eksik olduğunu unutmamak önemlidir; sadece işlem çıktı verilerine sahiptir. Her işlem çıktısının iki durumu vardır: ya alıcı tarafından harcanmış ya da harcanmamıştır. Harcanmamış işlem çıktıları (UTXO'lar) ile tanışık olduğumuz şeydir. İlgili BTC miktarının yanı sıra, her işlem çıktısının Bitcoin Script tarafından yazılan bir ekli betiği vardır. Bu betiğe doğru kanıtı (Tanık) sağlayabilen herhangi bir kişi UTXO'yu harcayabilir.

Bitcoin Script, bir dizi opcode ile bir yığın tabanlı programlama dilidir. UTXO'lara bağlı programlar genellikle yığın üzerinde hesaplamalar gerçekleştiren ve sonuçları ona döndüren birden fazla opcode içerir. Bitcoin'in ortaya çıkmasından bu yana birçok yaygın Bitcoin betiği mevcuttur. Örneğin, en yaygın betik, bir genel anahtar ve dijital imzayı kontrol eden bir opcode'dan oluşur. Bu opcode, bir UTXO harcamak veya kilidini açmak için, bir kişinin genel anahtara karşılık gelen bir dijital imza sağlaması gerektiğini gerektirir.

Önerilen Okuma: [BTC'ye Yaklaşmak: BitVM'yi Anlamak İçin Arka Plan Bilgisi (1)]

Bitcoin Script'in Yetenekleri

Bitcoin Script Ne Yapabilir:

• Yığını yeniden düzenleyin ve eşitlik kontrolü yapın (belirli koşulları doğrulamak ve işlem güvenliğini ve geçerliliğini sağlamak için).
• If-else ifadelerine benzer koşullu işlemler gerçekleştirin.
• 32 bit sayılar üzerinde toplama ve çıkarma gibi sınırlı aritmetik işlemleri gerçekleştirin.
• Hash verileri ve ECDSA ve Schnorr imzalarını doğrula.

Bitcoin Script Ne Yapamaz:

• Döngüler, atlama veya tekrarlama yok; Turing tamamlanmaz, çok sınırlı programlama yetenekleri vardır.
• Bit düzeyinde işlemler yapılamaz.
• Çarpma ve bölme için opcode eksikliği var.
• Yığın üzerinde öğeler birleştirilemiyor.
• On-zincir işlem verilerini okuma ve doğrulama yeteneği çok sınırlıdır. Bitcoin Script, her işlemin miktarına doğrudan erişim sağlayamaz ve durum geçemez (UTXO'lar tek kullanımlıktır ve her transfer eski olanı yakar ve yeni bir tane oluşturur).

Bitcoin'in erken sürümlerinde, yukarıda bahsedilen bazı 'yapamaz' işlevleri mümkündü, ancak belirli opkodlar daha sonra Satoshi Nakamoto tarafından güvenlik zafiyetleri nedeniyle devre dışı bırakıldı. Örneğin, iki yığın elemanını birleştirebilen OP_CAT opcode'u, Bitcoin düğümlerine uzaktan saldırı yapmak ve çökmelere neden olmak için kullanıldı. Satoshi güvenlik nedenleriyle OP_CAT ve diğer opkodları devre dışı bıraktı.

Bitcoin Script SNARK'ları doğrulayabilir mi? Teorik olarak, Bitcoin Script Turing tamamlanmamış olmasına rağmen, temel işlemleri herhangi bir hesaplama doğrulamak için yeterlidir. Ancak, pratikte, SNARK doğrulaması Bitcoin'in maksimum blok limiti olan 4 MB'yi aşan program boyutu nedeniyle mümkün değildir. Büyük sonlu alanlarda aritmetik işlemler denememize rağmen, maliyet engelleyici olacaktır. Örneğin, BitVM'de, iki 254-bit tamsayının çarpımı neredeyse 8 KB'lık bir Bitcoin script boyutuna neden olmuştur. Dahası, OP_CAT olmadan, Merkle kanıtlarının doğrulanması maliyetli olacaktır, çünkü bu döngülere benzer işlemler gerektirir.

Peki, neden sadece Bitcoin protokolünü daha güçlü opcode'lar ekleyecek şekilde değiştirmiyoruz? Daha önce de belirtildiği gibi, yeni protokol kuralları konusunda çoğunluk fikrine ulaşmak son derece zordur. Bitcoin merkezi bir karar vericiye sahip değildir ve Bitcoin Script'i geliştirmek için yapılan herhangi bir öneri, farklı perspektiflere sahip paydaşlardan önemli bir muhalefetle karşılaşır. Bitcoin ağındaki topluluk fikrine dair etkili bir yol yoktur ve bu fikir olmaksızın bir güncelleme yapmak, zincir bölünmelerine yol açabilir. Tabii ki, Bitcoin tamamen değişmez değildir. En son güncellemeler 2017'de SegWit ve 2021'de Taproot oldu.

Taproot yükseltmesi, birçok kuralı değiştirdi ve teorik sürümden gerçek aktivasyona geçmek üzere üç buçuk yıl sürdü. Taproot'u mümkün kılan ana faktör, mevcut güvenlik varsayımlarını değiştirmediği ve Bitcoin protokolüne açık bir şekilde iyileştirmeler getirdiğiydi. Örneğin, ECDSA yerine Schnorr imzalarının kullanımına izin verir. Her ikisi de ayrık logaritma varsayımına dayanır ve aynı eliptik eğriyi kullanır, ancak eski daha verimlidir ve daha az hesaplama gerektirir.

Dahası, Taproot'un Bitcoin'e olan iyileştirmeleri aşağıdaki üç açıdan kategorize edilebilir:

İlk olarak, Taproot, çoklu şartlı dallara sahip komut dosyalarının doğrulama maliyetlerini azaltır ve Bitcoin'in daha karmaşık programları desteklemesini sağlar.

İkinci olarak, Taproot zincir üzerinde açıklanacak komut verisi miktarını azaltır ve birden fazla komut programını ayrı ayrı yapraklarda bulunan bir Merkle ağacına monte edebilirsiniz. Belirli bir komutu tetiklemek isterseniz, yalnızca bulunduğu yaprağı ve Merkle kanıtını açıklamanız yeterlidir;

Üçüncü olarak, Taproot diğer mekanizma tasarımları da ekledi.

Bitcoin'in daha gelişmiş özellikleri entegre etmek için Taproot ile emsali göz önüne alındığında, SNARK doğrulaması için özel bir işlem kodunun neden tanıtılmadığı merak edilebilir. Temel fark, OP_SNARK için gereken karmaşıklık ve fikir birliğinde yatmaktadır. Geniş destek alan açık ve anlaşılır bir tasarıma sahip olan Taproot'un aksine, OP_SNARK teklifler büyük farklılıklar gösteriyor ve bu da topluluğu tek bir yaklaşım etrafında toplamayı zorlaştırıyor. Uygulanırsa, her Bitcoin düğümünün bu özel SNARK doğrulama yöntemini desteklemesi gerekecek ve bu da teknik talepleri önemli ölçüde artıracaktır. Dahası, OP_SNARK'nin doğasında var olan karmaşıklık büyük bir engeldir - Taproot, topluluk standartlarına göre yönetilebilen yaklaşık 1.600 satır kod eklerken, OP_SNARK çok daha karmaşık kodlamayı gerektirecektir. Ayrıca, OP_SNARK aktivasyonunu kimin değerlendireceğini belirlemek ve çok az kişi karmaşıklıklarını tam olarak kavradığında fikir birliğine varmak, zorluk katmanları ekler. Bu zorluklar göz önüne alındığında, yakın gelecekte bir OP_SNARK yükseltmesinin gerçekleşmesi pek olası değildir.

Ancak, Bitcoin Script'te SNARK'ları doğrulamanın diğer yolları vardır. Bitcoin komut dosyalarını daha işlevsel hale getirebiliriz, daha basit opcode'lar ekleyerek insanların scriptlerde SNARK doğrulayıcı programlarını uygulamalarına izin vererek. Ancak aslında, Bitcoin script diliyle bir SNARK doğrulama programı yazmak çok zordur. Bu nedenle, Blockstream araştırma ekibi, Bitcoin Script'in yerine geçmesi için tasarlanmış bir programlama dili olan Simplicity'i geliştirmektedir. Simplicity, blockchain uzlaşma sistemleri için özel olarak tasarlanmış ve kasıtlı olarak Turing tamamlanabilir olmayan, bu da statik analiz ve biçimsel doğrulama için kolay hale getirir.

Dikkatimizi Bitcoin'in komut dosyası yeteneklerini önemli ölçüde artırabilecek gibi görünen, görünüşte basit ancak son derece etkili bir öneriye çevirelim: OP_CAT opcode'inin yeniden etkinleştirilmesi. OP_CAT başlangıçta Bitcoin'in erken koduna dahil edildi, ancak Satoshi Nakamoto tarafından belirli koşullar altında DoS saldırılarına izin verme potansiyeli nedeniyle devre dışı bırakıldı. Bununla birlikte, Bitcoin topluluğunda şimdi onu geri getirme konusunda artan bir ilgi var.

OP_CAT'ın işlevi basittir - yığının en üstündeki iki öğeyi alır, birleştirir ve ardından sonucu tekrar yığına iter. Bu temel görünse de, Bitcoin'in komut dosyası dilinde önemli iyileştirmelerin kilidini açma potansiyeline sahiptir. Örneğin, mevcut Bitcoin komut dosyaları, miktarlar gibi belirli on-zincir işlem verilerine erişemez, ancak OP_CAT ile bu yetenek tanıtılabilir. Ayrıca, OP_CAT, Merkle kanıtlarını doğrulamada önemli olabilir.

Temelde, OP_CAT, geniş bir yelpazede yeni işlevselliklere yol açabilecek düşük seviyeli bir işlem kodu güncellemesidir. Birçok kişi, OP_CAT'in çeşitli hedeflere ulaşmada kritik olabileceğini belirtmiştir. Temel bir soru, OP_CAT'in betikler içinde SNARK doğrulamasına yardımcı olup olamayacağıdır. Cevap evet. Çünkü Merkle kanıtı doğrulaması, FRI tabanlı SNARK'ların doğrulanmasına doğru bir adımdır, OP_CAT değerli bir ek olacaktır. Geçmişte, SNARK doğrulaması için tasarlanmış betikler, Bitcoin'ın blok boyutu sınırları içinde sığacak kadar büyük olabilir, ancak OP_CAT, bu betikleri daha kompakt hale getirerek bunları daha kompakt hale getirebilir.

OP_CAT yıllardır tartışılıyor ve işlem içgörüsündeki potansiyel rolüne ilişkin farkındalık artıyor. Diğer önerilere kıyasla başlıca avantajlarından biri, Bitcoin Script'in ayrılmaz bir parçası olmasıdır, bu da topluluk fikir birliği sağlamayı kolaylaştırabilir. Bununla birlikte, dezavantajı, OP_CAT'in bazıları için MEV (Madenci Çıkarılabilir Değer) karını olumsuz etkileyebileceğidir, bu da topluluk içinde yeniden etkin hale getirilmesi konusunda süregelen tartışmalara yol açmıştır.

Özetle Bitcoin, OP_CAT gibi basit işlem kodlarını yeniden tanıtarak komut dosyalarında SNARK doğrulamasını etkinleştirmeye yönelik bir adım atabilir. Ek olarak, bir çarpma işlem kodunu yeniden tanıtan ve tüm aritmetik işlemlerin keyfi bir hassasiyetle gerçekleştirilmesini sağlayan "Büyük Komut Dosyası Restorasyonu" adlı yeni bir tekliften bahsetmeye değer.

Ayrıca, Bitcoin ağı üzerinde OP_CAT'in etkisini değerlendirirken, Bitcoin düğüm operatörlerinin üzerindeki etkilerini düşünmek önemlidir. Bitcoin'in sansür direncinin ve merkezi olmayan yapısının korunmasını sağlamak için topluluk, mümkün olduğunca çok kişinin işlemleri doğrulamak için düğüm çalıştırmasını amaçlar. Bitcoin SNARK doğrulamasını uygulasaydı, bir düğümün işletme maliyetini önemli ölçüde artırmayacaktı, bu da Bitcoin'in güvenliğini veya sansür direncini büyük ölçüde etkilemeyecekti.

Şu anda, bir Bitcoin bloğu yaklaşık 10 dakikada bir madenlenir ve 4MB'a kadar veri barındırabilir. Çoğu blok, Bitcoin betikleri ve Tanık verileri (diğer bir deyişle dijital imzalar) ile doludur. Ortalama olarak, her blok 7.000 ila 10.000 imza doğrulaması arasında yer alabilir ve her blok için maksimum 80.000 doğrulama yapılabilir. 2020 Intel CPU'm, bir Bitcoin bloğunu doğrulamak için yaklaşık 3,2 saniye alır. Doğal olarak, blok doğrulama hızı, sadece imza doğrulama süresi gibi faktörlerden etkilenir.

Ayrıca, eğer Bitcoin işlemleri sonunda sıfır bilgi (ZK) kanıtlarını desteklerse, işlem oluşturma süresindeki herhangi bir artış büyük bir endişe kaynağı olmayabilir. Uzun vadeli varlık depolama için kullanılan donanım cüzdanlar genellikle ekranlara ve anahtar depolama ve imza oluşturmaya odaklanan kompakt tasarımlara sahiptir. Bu cüzdanlar genellikle 240MHz çift çekirdekli bir işlemci gibi görece düşük güçlü CPU'larla donatılmıştır, ancak Bitcoin işlemlerini verimli bir şekilde yönetirler.

Kullanıcılara bir anket yaparak, bir imzalama cihazının bir kanıt oluşturmak için kabul edilebilecek maksimum gecikmeyi sordum ve birçok kişi daha uzun bir bekleme süresine razı oldu, özellikle önemli kazançlar elde edilecekse. Bu nedenle, Bitcoin işlemlerine ZK tanıtırsak, pek fazla sorun olmaz gibi görünüyor. Bitcoin'in temel tasarımında potansiyel değişiklikleri tartışmak için çok zaman harcadık, ancak Bitcoin'i değiştirmeden geliştirilebilecek birçok uygulama mevcut. Bahsetmeye değer olanlardan biri BitVM ile ilgili olan Zincir Durumu Kanıtlarıdır. Bu yaklaşım, blok karma değerlerinin doğruluğunu doğrulamak için sıfır bilgi kanıtlarını kullanır.

Bu teknolojinin Bitcoin üzerinde ne gibi etkileri var? İlk olarak, Zincir Durumu Kanıtları, Bitcoin'in tarihçesini senkronize etme ve doğrulama sürecindeki çalışma yükünü büyük ölçüde azaltabilir, bu da bir düğümü çalıştırmanın maliyetini düşürür. Şu anda, genesis bloktan en son bloğa kadar olan verileri senkronize etme ve doğrulama süreci, yüksek kaliteli bir cihazda yaklaşık 5 saat 30 dakika, Raspberry Pi düzeyinde bir cihazda ise birkaç gün sürmektedir. Zincir Durumu Kanıtları bu süreyi önemli ölçüde kısaltabilir.

İkinci olarak, Zincir Durum Kanıtları, BitVM'nin geliştirilmesinde çok önemli bir rol oynamaktadır. ZeroSync ekibi, Zincir Durum Kanıtlarını kapsamlı bir şekilde araştırdı ve "başlık zinciri Kanıtları" adı verilen modern bir sürüm geliştirdi. Bu yaklaşım, Bitcoin blok başlıklarını doğrulamak için sıfır bilgi kanıtları kullanır ve Bitcoin tarihindeki 850.000 blok başlığının tamamını kapsayan bir "başlık zinciri" oluşturur. Her blok başlığı, 80 baytlık bir kanıt oluşturmak için hash edilir. Bu yöntem, ilişkili iş kanıtını doğrulamak için her başlık için çift SHA-256 hesaplaması gerektirir. ZeroSync, bu başlık zinciri provalarını oluşturmak için STARK'ları kullanır ve üretilmesi yaklaşık 4.000 ABD dolarına mal olurken, doğrulama tarayıcımda yalnızca 3 saniye sürer.

Ancak, başlık zinciri kanıtları bloklar içindeki işlemleri doğrulamadığından, sadece en fazla proof-of-work (PoW) kanıtına sahip blockchain'in geçerli olduğunu varsayabilirler ve Bitcoin istemcilerinin bu zincirden en son blokları senkronize etmelerine güvenebilirler. Bu kurulumda, bir saldırgan teorik olarak geçersiz işlemler içeren bloklar oluşturabilir, üzerlerine daha fazla blok ekleyebilir ve istemcilerin tarihsel verileri senkronize etmelerini yanıltmak için bir başlık zinciri kanıtı oluşturabilir. Ancak, böyle bir saldırının maliyeti engelleyici derecede yüksek olurdu ve muhtemelen mevcut Bitcoin tam düğüm istemcileri tarafından tespit edilirdi.

Ancak, böyle bir saldırının başarılı olma olasılığı düşük olsa da, saldırganların önemli miktarda BTC çalmalarına izin verebilirse, başlık zinciri kanıtları tamamen güvenli bir çözüm olarak kabul edilmez. Zincirin tam durumunu doğrulamak için, secp256k1 eliptik eğrisine dayalı ECDSA ve Schnorr imza doğrulamaları da dahil olmak üzere, tüm Bitcoin blok içeriklerinin geçerli olduğundan emin olmamız gerekiyor. Bitcoin'in tarihsel blokları her ay yaklaşık 30 milyon imza ve çok sayıda SHA-256 hesaplaması içerir. Sonuç olarak, Bitcoin ağı aylık yaklaşık 7GB blok verisi üretir ve tarihsel veriler 650GB'ı aşar - pratikte bu rakam 2 ila 3 kat daha yüksek olabilir.

Şimdi, BitVM'ye bir göz atalım. BitVM, Bitcoin'in herhangi bir hesaplama görevini doğrulamasına izin vererek, protokolü değiştirmeden SNARK doğrulamasını gerçekleştirmenin en uygun yolunu sağlar. BitVM, Bitcoin'in script boyutu sınırlamalarını iki yöntem kullanarak aşar. İlk olarak, Taproot MerkleTree script yapısını kullanır. İkinci olarak, bireysel scriptler arasında erişilebilen bir KV depolama şeması kullanır, bu da birçok script programına bağlantı kurmayı kolaylaştırır. Ancak, Bitcoin protokolü bu KV depolama şemasının bütünlüğünü zorunlu kılmaz. BitVM, hileli Prover'ları tespit etmek için sahtekarlık kanıtlarını kullanarak bunun üstesinden gelir. Bir Prover geçersiz iddialarda bulunursa veya hatalı KV depolama kullanırsa, diğerleri Prover'ın kötü davranışlarını bildirmek ve Prover'ın bahis koyduğu varlıkları ele geçirmek için Bitcoin blokzincirinde bir işlem başlatabilir.

Özetle, Bitcoin önemli zorluklarla boğuşuyor ve bunları ele almak için çeşitli öneriler öne sürülmüş olsa da, Bitcoin topluluğundan hızlı bir şekilde kabul görmesi pek olası değil. Protokol değişiklikleri, Bitcoin'in ademi merkeziyetçiliğinin ve güvenliğinin hem güçlü yönlerini hem de kısıtlamalarını yansıtan kısa vadede gerçekleştirilemez. SNARK'ların ve STARK'ların potansiyeli, topluluk içinde önemli bir heyecan yaratıyor. BitVM, SNARK doğrulamasını orta ve uzun vadede entegre etmek için en umut verici yöntem gibi görünüyor, ancak tamamen pratik olması için daha fazla araştırma ve geliştirme gerektiriyor. OP_CAT işlem kodunu yeniden etkinleştirmek, keşfedilmesi gereken başka bir yoldur, ancak yeniden etkinleştirmenin faydalarının risklerden daha ağır bastığını göstermesi ve hangi basit işlem kodlarının SNARK doğrulamasını veya Bitcoin komut dosyalarındaki benzer işlevleri kolaylaştırabileceğini belirlemesi gerekir. Sonuç olarak, Bitcoin topluluğu teknolojinin pratikliğini artırmayı ve daha eyleme geçirilebilir kullanım durumlarını desteklemeyi amaçlıyor.

Orijinal içeriği buradan okuyun: https://www.youtube.com/watch?v=GrSCZmFuy7U

Açıklama:

1. Bu makale [den alıntıdırGeek Web3], Tüm telif hakları orijinal yazarına aittir [Geek Web3]. If there are objections to this reprint, please contact the Gate Öğrenekip, ve bunu hızlı bir şekilde ele alacaklar.
2. Sorumluluk Feragati: Bu makalede ifade edilen görüşler yalnızca yazarın görüşleridir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalelerin diğer dillere çevirileri, Gate Learn ekibi tarafından yapılır. Belirtilmedikçe, çevrilen makalelerin kopyalanması, dağıtılması veya çalınması yasaktır.