Yazan: Peter
Önsöz
BTC'nin 2009 yılında ortaya çıkışından bu yana, üç teknolojik yinelemeden geçen Bitcoin, basit bir dijital yerel varlık konseptinden, karmaşık işlevlere ve uygulamalara sahip merkezi olmayan bir finansal sisteme dönüştü.
BTC teknolojisinin evrimine ilişkin görüşlerini paylaşan BEVM'nin kurucusu tarafından yazılan bu makale, aynı zamanda BTC Layer2 teknolojisinin geliştirilmesinde önemli bir kilometre taşı olan BEVM'nin, BTC'nin geleceğini teknik düzeyde nasıl gerçekleştirdiğini ayrıntılı olarak açıklıyor. Merkezi olmayan ekolojik refah.
Bu makale sayesinde aşağıdakiler hakkında daha fazla bilgi edineceksiniz:
- BTC Layer2'nin gerekliliği
- BTC Layer2 nasıl uygulanır?
- Tamamen merkezi olmayan BEVM çözümü
BTC'nin doğuşundan bu yana gerçekleştirdiği üç büyük devrim niteliğindeki teknoloji yinelemesini saygıyla anıyoruz:
- 2009: BTC, merkezi olmayan para birimi uygulamalarını açmak için ilk kez blockchain yapısını kullanarak doğdu.
- 2017: BTC Segregated Witness, maksimum 4 MB depolamayı destekleyecek şekilde yükseltildi ve BTC'nin zincir içi depolama sorunu çözüldü. Bu aynı zamanda şu anda popüler olan Ordinals protokolünün (varlık ihraç etme) temelini de sağlar.
- 2021: BTC Taproot, tamamen merkezi olmayan BTC Layer2 teknolojisi için temel destek sağlayan BTC eşik imza algoritmasını destekleyecek şekilde yükseltildi.
1. Neden BTC Layer2'yi oluşturmak istiyorsunuz?
1. Talep var: Bitcoin ağı varlık kaydı talebini karşılıyor ancak hala zincir üzerinde uzlaşma gerektiren çok sayıda varlık var (Katman 2)
ETH'nin mevcut Layer2'si, ETH Layer1'in sadece bir kopyasıdır. Layer1 tarafından çözülemeyen ve Layer2 tarafından çözülmesi gereken pratik iş sorunlarını çözmez.
ETH Layer2'nin ETH Layer1 sorununu çözdüğünü söylemek gerekir: Layer2, Layer1'in yüksek gas maliyeti sorununu çözer. ETH'nin en büyük Katman 2 Arbitrumu üzerindeki GMX gibi türev uygulamaları tam da bu talep nedeniyle oluşturuldu.
BTC'nin Layer2'si, ETH'nin Layer2'si kadar alakasız değildir.
BTC'nin Turing-tamamlanmamış zincir üstü sanal makinesi yalnızca varlıkları kaydedebildiğinden ancak mutabakat yapamadığından, BTC Katman1'in, BTC Katman1 tarafından verilen varlıkların takası için Turing-tamamlanmış BTC Katman2'ye ihtiyaç duyması gerekir.
2. Yetenekli: BTC tamamen merkezi olmayan bir Katman 2 haline gelebilir
2021'deki BTC Taproot yükseltmesinden önce tamamen merkezi olmayan bir BTC Katmanı2 elde etmek imkansız olacak. Ancak bu yükseltmeden sonra BTC eşik imza algoritması, BTC'nin tamamen merkezi olmayan bir Katman 2 bilgi işlem katmanını desteklemesine olanak tanır.
İkincisi, merkezi olmayan BTC L2'ye nasıl ulaşılır?
Bitcoin İyileştirme Teklifleri (BIP'ler), Bitcoin'e yeni özellikler ve bilgiler tanıtan tasarım belgeleridir; taproot yükseltmesi ise Schnorr İmzası (BIP 340), Taproot (BIP 341) ve Tapscript (BIP 342) olmak üzere üç BIP'in bir derlemesidir. üç yükseltmeye topluca BIP Taproot adı verilir.
Bitcoin'e daha verimli, esnek ve özel bir aktarım yöntemi getirecek ve bunun temelinde Schnorr imzalarının ve Merkel soyut sözdizimi ağaçlarının kullanılması yatıyor.
Bitcoin'e daha verimli, esnek ve özel bir aktarım yöntemi getirecek ve bunun temelinde Schnorr imzalarının ve Merkel soyut sözdizimi ağaçlarının kullanılması yatıyor.
Schnorr imzası, basitliği ve güvenliğiyle bilinen bir dijital imza şemasıdır. Schnoor imzaları hesaplama verimliliği, depolama ve gizlilik açısından çeşitli avantajlar sunar.
Kullanıcı, imzalayanın kimliğini açık anahtar aracılığıyla doğrular ve sözleşme içeriğini veriler aracılığıyla onaylayarak dijital sözleşmenin geçerliliğini doğrular.
Schnorr toplu imzası, birden fazla imza verisini sıkıştırıp tek bir toplu imzada birleştirebilir.
Doğrulayıcı, imzayla ilgili tüm veriler ve genel anahtarlardan oluşan bir liste aracılığıyla tek bir toplu imzayı doğrular. Doğrulama başarılı olursa, etki, ilgili tüm imzaların ve tüm geçişlerin bağımsız olarak doğrulanmasına eşdeğerdir.
Mevcut blok zincirlerinin çoğu ECDSA çoklu imza algoritmasını kullanır. Blok verileri için her düğüm, bağımsız bir dijital imza oluşturmak ve bunu diğer düğümlere yayınlamak için kendi özel anahtarını kullanır. Diğer düğümler imzayı doğrulayacak ve onu bir sonraki veri bloğuna yazacaktır.
Bu yöntemi kullanarak, fikir birliği düğümlerinin sayısı fazla olduğunda, her bir fikir birliği bloğu turunda depolanan imza verileri artmaya devam edecek ve depolama alanı kaplayacaktır.
Ağa yeni bir düğüm katıldığında ve geçmiş blokları senkronize etmesi gerektiğinde, büyük miktarda imza verisi ağ bant genişliği açısından büyük bir zorluk oluşturacaktır.
Toplu imza teknolojisini kullandıktan sonra, her düğüm, diğer düğümler tarafından yayınlanan toplu imza kartvizitlerini toplayacak ve ardından imzaları Şekil 2'de gösterildiği gibi parçalar halinde toplayacak ve kaydedecektir.
Bu şekilde, yeni bir düğüm katıldığında, geçmiş blokların senkronize edilmesi yalnızca toplu imza verilerinin indirilmesini gerektirir; bu da ağ bant genişliği kullanımını büyük ölçüde azaltır ve işlem ücretlerini azaltır.
Ek olarak, anahtar birleştirme tüm Taproot çıktılarının benzer görünmesini sağlar. Çoklu imza çıktıları, tek imzalı çıktılar veya diğer karmaşık akıllı sözleşmelerin tümü blockchain üzerinde aynı görünse de, pek çok blockchain analizi kullanılamayacak ve tüm Taproot kullanıcıları için gizlilik korunacaktır.
MAST (Merkle Soyut Sözdizimi Ağacı), yaprakları Schiller'in örtüşmeyen komut dosyaları olan (örneğin, çoklu imzalar veya zaman kilitleri) karmaşık kilitleme komut dosyalarını şifrelemek için bir Merkle ağacı kullanır.
MAST (Merkle Soyut Sözdizimi Ağacı), yaprakları Schiller'in örtüşmeyen komut dosyaları olan (örneğin, çoklu imzalar veya zaman kilitleri) karmaşık kilitleme komut dosyalarını şifrelemek için bir Merkle ağacı kullanır.
Ödeme yaparken yalnızca ilgili komut dosyası ve bu komut dosyasından Merck ağacının köküne giden yol açıklanır. Şekil 3'te gösterildiği gibi, script1'i kullanmak için yalnızca script1, script2 ve hash3'ü açıklamanız gerekir.
MAST'ın temel faydaları şunları içerir:
- Karmaşık ödeme koşullarını destekler
- Yürütülmemiş komut dosyalarını veya tetiklenmemiş ödeme koşullarını açıklamaya gerek yoktur, bu da daha iyi gizlilik koruması sağlar
- Sıkıştırılmış işlem boyutu: Komut dosyası sayısı arttıkça MAST olmayan işlem boyutu doğrusal olarak büyürken, MAST işlem boyutu logaritmik olarak büyür.
Ancak Taproot yükseltmesinde bir sorun var; yani P2SH, yaygın olarak kullanılan Herkese Açık Anahtar Hash'inden (P2PKH) farklı davranıyor ve hâlâ gizlilik koruma sorunları var.
P2SH ve P2PKH'nin zincir üzerinde aynı görünmesini sağlamak mümkün müdür?
Bu amaçla Taproot, sınırlı sayıda imzalayana sahip komut dosyaları için iki bölüme ayrılabilecek bir çözüm önerdi:
İlk bölüm, tüm imzalayanların "işbirlikçi harcama" adı verilen belirli bir harcama sonucu üzerinde anlaştıkları çoklu imzadır.
İkinci kısım "işbirliğine dayalı olmayan harcamalar" olarak adlandırılır ve çok karmaşık bir senaryo yapısına sahip olabilir.
Bu iki parça bir "veya" ilişkisi içindedir.
Şekil 3'te gösterildiği gibi, Script3, geçerli olması için hem Alice hem de Bob'un imzalamasını gerektiren 2/2 çoklu imzadır. Bu bir "işbirliğine dayalı harcamadır", Script1 ve 2 ise "işbirliğine dayalı olmayan harcamalardır".
Hem "işbirlikçi harcamalar" hem de "işbirlikçi olmayan harcamalar" bu çıktıyı harcayabilir; bunlar arasında:
- "İşbirliğine dayalı olmayan harcama" komut dosyası için yukarıdaki MAST yöntemini benimseyin ve Merkle ağaç kökünü temsil etmek için MerkleRoot'u kullanın.
- "İşbirlikçi harcama" senaryosu için Schnoor imzasını temel alan çoklu imza algoritması benimsenmiştir. Pa ve Pb sırasıyla Alice ve Bob'un genel anahtarlarını temsil etsin ve Da ve Db sırasıyla Alice ve Bob'un özel anahtarlarını temsil etsin. Bu nedenle, toplam genel anahtar P=Pa+Pb'dir ve karşılık gelen özel anahtar Da+Db'dir.
- "İşbirliğine dayalı harcamalar" ve "işbirliğine dayalı olmayan harcamalar" P2PKH biçiminde birleştirilir. Genel anahtar: PP+H(P||MerkleRoot)G; karşılık gelen özel anahtar Da+Db+H(P| |MerkleRoot)'tur ).
- Alice ve Bob "ortak harcama" konusunda anlaştıklarında, içlerinden biri kendi özel anahtarına H(P||MerkleRoot) eklediği sürece Da+Db+H(P||MerkleRoot) kullanırlar.
Zincir üzerinde bu, temel MAST'ı açıklamaya gerek kalmadan, genel anahtar ve buna karşılık gelen özel anahtarla bir P2PKH işlemi gibi davranır.
3. Tamamen merkezi olmayan BTC katman2 çözümümüz:
3.1 BTC hafif düğüm + dağıtılmış eşik imza sözleşmesi
Bu çözümde, BTC zincirindeki dağıtılmış eşik imza toplama saklama sözleşmesini tamamlamak için n (n tanesi BEVM'deki tüm doğrulayıcılar olabilir) sabit doğrulayıcılar seçilir.
Bu çözümde, BTC zincirindeki dağıtılmış eşik imza toplama saklama sözleşmesini tamamlamak için n (n tanesi BEVM'deki tüm doğrulayıcılar olabilir) sabit doğrulayıcılar seçilir.
BEVM katman 2'deki her doğrulayıcının blok oluşturan özel anahtarı, aynı zamanda BTC'nin eşik imzasının toplam özel anahtarının bir kısmını da türetir.n doğrulayıcının eşik özel anahtarları, BTC'nin toplu imza fotoğraf adresinde birleştirilir. N'nin maksimum değer aralığı 1000 veya daha fazla olabilir.
- A kullanıcısı BTC'yi BEVM'ye çapraz zincirlemek istediğinde, kullanıcının yalnızca BTC'yi Bitcoin toplama saklama sözleşmesine göndermesi gerekir ve kullanıcı, BTC'yi BEVM katman 2'de alabilir.
- Buna bağlı olarak, A kullanıcısı bir para çekme işlemi gerçekleştirdiğinde, toplu imzaları oluşturan n doğrulama düğümünden yalnızca m tanesi dağıtılmış eşik imza sözleşmesi birlikte çalışmasını otomatik olarak tamamlar ve saklama sözleşmesinden A kullanıcısına aktarım Bitcoin üzerinde tamamlanabilir. , BTC BEVM'de yok edilecek.
3.2 BTC'yi yerel Gaz ücreti ve EVM uyumlu Katman 2 olarak uygulayın
1) EVM prensibi
Ethereum Sanal Makinesi, Ethereum akıllı sözleşmelerinin çalışma zamanı ortamıdır. Sadece sandbox'a alınmış olmakla kalmıyor, aynı zamanda tamamen izole edilmiş durumda.
Bu, EVM'de çalışan kodun ağa, dosya sistemine ve diğer işlemlere erişemeyeceği anlamına gelir. Akıllı sözleşmeler arasında erişim bile sınırlıdır.
Ethereum'un alt katmanı, sözleşmelerin EVM modülü aracılığıyla yürütülmesini ve çağrılmasını destekler.Çağrı sırasında, sözleşme adresine göre sözleşme kodu alınır ve çalıştırılmak üzere EVM'ye yüklenir. Genellikle akıllı sözleşmelerin geliştirme süreci, mantık kodunu yazmak için katılığı kullanmak, ardından bunu bir derleyici aracılığıyla bayt koduna derlemek ve son olarak Ethereum'da yayınlamaktır.
2) EVM'nin ana kısmı
3) EVM Kodu
EVM kodu, Ethereum'un içerebileceği programlama dilinin kodunu ifade eden Ethereum Sanal Makine kodudur. Bir hesapla ilişkili EVM kodu, hesaba her mesaj gönderildiğinde yürütülür ve depolamayı okuma/yazma ve mesajları kendisi gönderme yeteneğine sahiptir.
4)Makine Durumu
Mchine State, program sayacı, yığın ve bellek dahil olmak üzere evm kodunun yürütüldüğü yerdir.
5)Depolama
Depolama, okunabilir, yazılabilir ve değiştirilebilir kalıcı depolama alanıdır ve aynı zamanda her sözleşmenin verileri kalıcı olarak sakladığı yerdir. Depolama, toplam 2256 yuvaya sahip devasa bir haritadır, her yuvada 32 bayt bulunur.
6) BTC'yi Gaz ücreti olarak kullanın
Depolama, okunabilir, yazılabilir ve değiştirilebilir kalıcı depolama alanıdır ve aynı zamanda her sözleşmenin verileri kalıcı olarak sakladığı yerdir. Depolama, toplam 2256 yuvaya sahip devasa bir haritadır, her yuvada 32 bayt bulunur.
6) BTC'yi Gaz ücreti olarak kullanın
Bitcoin ağından aktarılan BTC'nin, EVM'de işlem yürütmek için gas ücreti hesaplama para birimi olarak kullanılmasına izin verin.
Tüm Yorumlar