2009'da BTC'nin ortaya çıkışından bu yana, Bitcoin üç teknik yinelemeden geçti ve basit bir dijital yerel varlık kavramından karmaşık işlevlere ve uygulamalara sahip merkezi olmayan bir finansal sisteme dönüştü.
Bu makale, BTC teknolojisinin evrimi hakkındaki görüşlerini paylaşan BEVM'nin** kurucusu tarafından yazılmıştır ve ayrıca BTC Katman 2 teknolojisinin geliştirilmesinde önemli bir kilometre taşı olan BEVM'nin BTC'nin merkezi olmayan ekosisteminin gelecekteki refahını teknik düzeyde nasıl gerçekleştirebileceğini ayrıntılı olarak yanıtlamaktadır. **
Bu makalede aşağıdakiler hakkında daha fazla bilgi edineceksiniz:
BTC Katman 2'nin gerekliliği
BTC Katman 2'ye nasıl ulaşılır?
Tamamen merkezi olmayan BEVM çözümü
BTC'nin doğuşundan bu yana devrim niteliğindeki 3 büyük teknolojik yinelemesine övgü:
2009: Merkezi olmayan para uygulamalarını açmak için blok zincirinin yapısını ilk kez kullanan BTC doğdu.
2017: BTC Segregated Witness, 4 MB'a kadar depolamayı destekleyecek şekilde yükseltildi ve BTC'nin zincir üstü depolama sorunu çözüldü. Bu aynı zamanda şu anda patlayıcı olan Ordinals protokolünün (varlıkların ihracı) temelini oluşturur.
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.
İlk olarak, neden BTC Layer2 yapmak istiyorsunuz?**
1. Talep var: Bitcoin ağı, varlık kaydı ihtiyaçlarını karşılıyor, ancak hala zincir üzerinde ödenmesi gereken çok sayıda varlık var (Katman 2)
Şu anda, ETH'nin Katman 2'si, ETH Katman 1'in yalnızca bir kopyasıdır ve Katman 1'in çözemeyeceği hiçbir şey yoktur, ancak Katman 2'nin çözmesi gereken gerçek iş sorunları vardır.
ETH Katman 2'nin ETH Katman 1 sorununu çözdüğü söylenmelidir: Katman 2, pahalı Katman 1 gazı sorununu çözer. Tam da bu talep sayesinde ETH'nin GMX gibi Layer2 Arbitrum'daki ilk türev uygulaması gerçekleştirilmiştir.
Ve BTC'nin Katman 2'si, ETH Katman 2 kadar alakasız değil.
BTC Turing-complete olmayan zincir üstü sanal makine yalnızca varlıkları kaydedebildiğinden, ancak ödeme yapamadığından, BTC Katman 1, BTC Katman 1 tarafından verilen varlıkları kapatmak için Turing-complete BTC Layer2'ye ihtiyaç duymalıdır.
2.Yetenek: BTC tamamen merkezi olmayan bir Katman 2'ye dönüştürülebilir
2021'deki BTC Taproot yükseltmesinden önce, tamamen merkezi olmayan bir BTC Katman 2 elde etmek imkansızdı. Bununla birlikte, bu yükseltmeden sonra, BTC eşik imza algoritması, BTC'nin tamamen merkezi olmayan bir Katman2 bilgi işlem katmanını desteklemesine izin verir.
II.Merkeziyetsiz BTC L2'ye nasıl ulaşılır?
Bitcoin İyileştirme Önerileri (BIP'ler), Bitcoin'e yeni özellikler ve bilgiler getiren tasarım belgeleridir, taproot yükseltmeleri ise topluca BIP Taproot olarak bilinen Schnorr Signature (BIP 340), Taproot (BIP 341) ve Tap (BIP 342) olmak üzere üç BIP'nin bir derlemesidir.
Schnorr imzaları ve Merkel soyut sözdizimi ağaçları kullanarak Bitcoin transferi için daha verimli, esnek ve özel bir yol getirecek.
Schnorr imzaları, basitlikleri ve güvenlikleri ile bilinen bir dijital imza şemasıdır. Schnoor imzaları, hesaplama verimliliği, depolama ve gizlilik açısından çeşitli avantajlar sunar.
! [BEVM Kurucusu: BTC Layer2 Neden ve Nasıl Yapılır?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/f2c90430573edf17b34bc2b81d6fba2e.)
Kullanıcı, dijital sözleşmenin geçerliliğini doğrulamak için imzalayanın kimliğini açık anahtar aracılığıyla ve sözleşmenin içeriğini veriler aracılığıyla doğrular.
Schnorr Toplu İmzalar, birden fazla imza verisini sıkıştırabilir ve tek bir toplu imzada birleştirebilir.
Doğrulayıcı, tüm imzalarla ilişkili verilerin ve ortak anahtarların bir listesiyle tek bir toplu imzayı doğrular ve bu, ilgili tüm imzaların bağımsız olarak doğrulanmasına eşdeğerdir.
! [BEVM Kurucusu: BTC Layer2 Neden ve Nasıl Yapılır?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/c7ed182df952263f95cd6b5da86e5aa3.)
Şu anda çoğu blok zinciri, her düğümün blok verileri için kendi özel anahtarıyla bağımsız bir dijital imza oluşturduğu ve bunu diğer düğümlere yayınladığı ECDSA multisig algoritmasını kullanmaktadır. Diğer düğüm imzayı doğrular ve bir sonraki veri yığınına yazar.
Bu şekilde, konsensüs düğümlerinin sayısı büyük olduğunda, konsensüs bloklarının her turunda depolanan imza verileri artmaya devam edecek ve depolama alanını işgal edecektir.
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 için 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 toplar ve ardından Şekil 2'de gösterildiği gibi imza parçası toplamını kaydeder.**
Bu şekilde, yeni bir düğüm katıldığında, senkronizasyon geçmişi bloğunun yalnızca toplu imza verilerini indirmesi gerekir, bu da ağ bant genişliğinin işgalini büyük ölçüde azaltır ve işlem ücretlerinin harcanmasını azaltır.
Ek olarak, anahtar toplama, tüm Taproot çıkışlarının benzer görünmesini sağlar. İster çoklu imza çıktısı, ister tek imzalı çıktı veya diğer karmaşık akıllı sözleşmeler olsun, hepsi blok zincirinde aynı görünür, bu nedenle birçok blok zinciri analitiği kullanılamayacak ve tüm Taproot kullanıcıları için gizliliği koruyacaktır. **
! [BEVM Kurucusu: BTC Layer2 Neden ve Nasıl Yapılır?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/187dbc4fe20ec85e558eb12132a2a850.)
MAST (Merkle Soyut Sözdizimi Ağacı), karmaşık kilitleme komut dosyalarını şifrelemek için bir Merkle ağacı kullanan, örtüşmeyen bir dizi komut dosyasıdır (örneğin, multisig veya zaman kilidi).
Harcama yaparken, yalnızca söz konusu komut dosyasının ve bu komut dosyasından Merck ağacının köküne giden yolun açıklanması gerekir. Şekil 3'te gösterildiği gibi, 1'i kullanmak için yalnızca 1, 2 ve hash3'ü açıklamanız gerekir.
MAST'ın başlıca faydaları şunlardır:
1) Karmaşık harcama koşulları için destek
2) Yürütülmemiş komut dosyalarını veya tetiklenmemiş harcama koşullarını ifşa etmeye gerek yoktur, bu da daha iyi gizlilik koruması sağlar
**3) İşlem Boyutunu Sıkıştır: Komut dosyası sayısı arttıkça, MAST olmayan işlem boyutu doğrusal olarak artarken, MAST işlem boyutu logaritmik olarak artar. **
Bununla birlikte, Taproot yükseltmesinde bir sorun var, yani P2SH, ortak Pay-to-Public-Key-Hash (P2PKH) ile aynı değil ve hala gizlilik koruma sorunları var.
P2SH ve P2PKH'nin zincir üzerinde aynı görünmesini sağlamak mümkün mü?
Bu amaçla Taproot, sınırlı sayıda imzalayana sahip bir komut dosyası için iki parçaya bölünebilecek bir çözüm önermektedir:
İlk bölüm, tüm imzacıların "işbirlikçi harcama" olarak bilinen belirli bir harcama sonucu üzerinde anlaştıkları multisig'dir.
İkinci kısım "işbirlikçi olmayan harcama" olarak adlandırılır ve çok karmaşık komut dosyası yapılarına sahip olabilir.
Bu iki kısım "veya" ilişkisidir.
Şekil 3 ve 3'te gösterildiği gibi, 2'nin 2'si çoklu imza, hem Alice hem de Bob'un geçerli olmasını gerektirir, bu da "işbirlikçi harcama" ve 1 ve 2'nin "işbirlikçi olmayan harcama"dır.
Hem "işbirlikçi harcama" hem de "işbirlikçi olmayan harcamalar" bu çıktıyı şu durumlarda harcayabilir:
"İşbirlikçi olmayan harcama" komut dosyası için, yukarıda açıklanan MAST yaklaşımını benimseyin ve Merck ağaç kökünü temsil etmek için MerkleRoot'u kullanın.
"İşbirlikçi harcama" komut dosyası için, Schnoor imzalarına dayalı bir multisig algoritması benimsenmiştir. Pa ve Pb, sırasıyla Alice ve Bob'un açık anahtarlarını temsil etmek için kullanılır ve Da ve Db, sırasıyla Alice ve Bob'un özel anahtarlarını temsil etmek için kullanılır.
Bu nedenle, toplam ortak anahtar P=Pa+Pb'dir ve karşılık gelen özel anahtar Da+Db'dir.
"İşbirlikçi harcama" ve "işbirlikçi olmayan harcamaları" P2PKH biçiminde birleştirin ve açık anahtarı: PP+H(P||MerkleRoot)G; karşılık gelen özel anahtar Da+Db+H(P||MerkleRoot)。
Alice ve Bob "işbirlikçi harcamayı" kabul ettiklerinde, Da+Db+H(P||MerkleRoot), yalnızca birinin özel anahtarına H(P||) eklemesini gerektirirMerkleRoot) kullanın.
Zincir üzerinde bu, altta yatan MAST'ı ifşa etmeye gerek kalmadan bir genel anahtar ve karşılık gelen bir özel anahtarla bir P2PKH işlemi gibi davranır.
III. Tamamen merkeziyetsiz BTC layer2 çözümümüz:
3.1 BTC hafif düğüm + dağıtılmış eşik imzalama sözleşmesi
! [BEVM Kurucusu: BTC Layer2 Neden ve Nasıl Yapılır?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/d6ddaf08422a0b02bc25e45cd2f5d947.)
Bu şemada, dağıtılmış eşik imzalama ile BTC zincir üstü toplam saklama sözleşmesini tamamlamak için n (n BEVM'deki tüm doğrulayıcılar olabilir) sabit doğrulayıcılar seçilir.
BEVM katman2'deki her doğrulayıcının özel anahtarı, BTC'nin eşik imzasının toplam özel anahtarının bir kısmından türetilir ve n doğrulayıcının eşik özel anahtarı, BTC'nin toplu imza fotoğraflı adresinde birleştirilir. **n en fazla 1000 veya daha fazla olabilir. **
A kullanıcısı BTC'yi BEVM'ye çapraz zincirlemek istediğinde, yalnızca Bitcoin toplama saklama sözleşmesine BTC göndermesi gerekir ve kullanıcı BEVM katmanında2 BTC alabilir.
Buna bağlı olarak, A kullanıcısı bir para çekme işlemi gerçekleştirdiğinde, yalnızca n doğrulayıcı arasındaki toplu imzada m otomatik tamamlama dağıtılmış eşik imza sözleşmeleriyle birlikte çalışması gerekir ve emanet sözleşmesinden A kullanıcısına aktarım Bitcoin'de tamamlanabilir ve BTC, aktarım tamamlanırken aynı anda BEVM'de yakılır.
3.2 BTC'yi yerel gaz ücreti ve EVM uyumlu Katman 2 olarak uygulayın
1) EVM İlkesi
Ethereum Sanal Makinesi, Ethereum akıllı sözleşmeleri için çalışma zamanı ortamıdır. Sadece korumalı alanla değil, aynı zamanda tamamen izole edilmiştir.
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ındaki erişim bile kısıtlanmıştır.
Ethereum'un temel katmanı, EVM modülü aracılığıyla sözleşmenin yürütülmesini ve çağrılmasını destekler ve çağrıldığında sözleşme adresine göre sözleşme kodu alınır ve işlem için EVM'ye yüklenir. Tipik olarak, akıllı sözleşme geliştirme süreci, solidlity içinde mantıksal kod yazmak, bir derleyici aracılığıyla bayt koduna derlemek ve son olarak Ethereum'da yayınlamaktır.
! [BEVM Kurucusu: BTC Layer2 Neden ve Nasıl Yapılır?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/2d2d923b8ae9ff718bac8dedbf6a9314.)
2) EVM Ana Parçaları
! [BEVM Kurucusu: BTC Layer2 Neden ve Nasıl Yapılır?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/67f265774f666ae9ab031a29230b5b8d.)
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 okuma/yazma, depolama ve mesaj gönderme yeteneğine sahiptir.
4)Çin Devleti
Mchine State, program sayaçlarını, yığınları ve belleği içeren EVM kodunun yürütüldüğü yerdir.
5)Depolama
Depolama, okunabilen, yazılabilen ve değiştirilebilen kalıcı bir depolama alanıdır ve aynı zamanda her sözleşmenin verileri kalıcı olarak depoladığı yerdir. Depolama, her biri 32 bayt olan toplam 2256 yuvaya sahip devasa bir haritadır.
6) Gaz Ücreti Olarak BTC
Bitcoin ağından aktarılan BTC'nin, EVM'deki işlemlerin yürütülmesi için gaz ücreti hesaplama para birimi olarak kullanılmasına izin verin.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
BEVM Kurucusu: BTC Katman 2 Neden ve Nasıl Yapılır?
Yazar: Peter
Önsöz
2009'da BTC'nin ortaya çıkışından bu yana, Bitcoin üç teknik yinelemeden geçti ve basit bir dijital yerel varlık kavramından karmaşık işlevlere ve uygulamalara sahip merkezi olmayan bir finansal sisteme dönüştü.
Bu makale, BTC teknolojisinin evrimi hakkındaki görüşlerini paylaşan BEVM'nin** kurucusu tarafından yazılmıştır ve ayrıca BTC Katman 2 teknolojisinin geliştirilmesinde önemli bir kilometre taşı olan BEVM'nin BTC'nin merkezi olmayan ekosisteminin gelecekteki refahını teknik düzeyde nasıl gerçekleştirebileceğini ayrıntılı olarak yanıtlamaktadır. **
Bu makalede aşağıdakiler hakkında daha fazla bilgi edineceksiniz:
BTC Katman 2'nin gerekliliği
BTC Katman 2'ye nasıl ulaşılır?
Tamamen merkezi olmayan BEVM çözümü
BTC'nin doğuşundan bu yana devrim niteliğindeki 3 büyük teknolojik yinelemesine övgü:
2009: Merkezi olmayan para uygulamalarını açmak için blok zincirinin yapısını ilk kez kullanan BTC doğdu.
2017: BTC Segregated Witness, 4 MB'a kadar depolamayı destekleyecek şekilde yükseltildi ve BTC'nin zincir üstü depolama sorunu çözüldü. Bu aynı zamanda şu anda patlayıcı olan Ordinals protokolünün (varlıkların ihracı) temelini oluşturur.
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.
İlk olarak, neden BTC Layer2 yapmak istiyorsunuz?**
1. Talep var: Bitcoin ağı, varlık kaydı ihtiyaçlarını karşılıyor, ancak hala zincir üzerinde ödenmesi gereken çok sayıda varlık var (Katman 2)
Şu anda, ETH'nin Katman 2'si, ETH Katman 1'in yalnızca bir kopyasıdır ve Katman 1'in çözemeyeceği hiçbir şey yoktur, ancak Katman 2'nin çözmesi gereken gerçek iş sorunları vardır.
ETH Katman 2'nin ETH Katman 1 sorununu çözdüğü söylenmelidir: Katman 2, pahalı Katman 1 gazı sorununu çözer. Tam da bu talep sayesinde ETH'nin GMX gibi Layer2 Arbitrum'daki ilk türev uygulaması gerçekleştirilmiştir.
Ve BTC'nin Katman 2'si, ETH Katman 2 kadar alakasız değil.
BTC Turing-complete olmayan zincir üstü sanal makine yalnızca varlıkları kaydedebildiğinden, ancak ödeme yapamadığından, BTC Katman 1, BTC Katman 1 tarafından verilen varlıkları kapatmak için Turing-complete BTC Layer2'ye ihtiyaç duymalıdır.
2.Yetenek: BTC tamamen merkezi olmayan bir Katman 2'ye dönüştürülebilir
2021'deki BTC Taproot yükseltmesinden önce, tamamen merkezi olmayan bir BTC Katman 2 elde etmek imkansızdı. Bununla birlikte, bu yükseltmeden sonra, BTC eşik imza algoritması, BTC'nin tamamen merkezi olmayan bir Katman2 bilgi işlem katmanını desteklemesine izin verir.
II.Merkeziyetsiz BTC L2'ye nasıl ulaşılır?
Bitcoin İyileştirme Önerileri (BIP'ler), Bitcoin'e yeni özellikler ve bilgiler getiren tasarım belgeleridir, taproot yükseltmeleri ise topluca BIP Taproot olarak bilinen Schnorr Signature (BIP 340), Taproot (BIP 341) ve Tap (BIP 342) olmak üzere üç BIP'nin bir derlemesidir.
Schnorr imzaları ve Merkel soyut sözdizimi ağaçları kullanarak Bitcoin transferi için daha verimli, esnek ve özel bir yol getirecek.
Schnorr imzaları, basitlikleri ve güvenlikleri ile bilinen bir dijital imza şemasıdır. Schnoor imzaları, hesaplama verimliliği, depolama ve gizlilik açısından çeşitli avantajlar sunar.
! [BEVM Kurucusu: BTC Layer2 Neden ve Nasıl Yapılır?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/f2c90430573edf17b34bc2b81d6fba2e.)
Kullanıcı, dijital sözleşmenin geçerliliğini doğrulamak için imzalayanın kimliğini açık anahtar aracılığıyla ve sözleşmenin içeriğini veriler aracılığıyla doğrular.
Schnorr Toplu İmzalar, birden fazla imza verisini sıkıştırabilir ve tek bir toplu imzada birleştirebilir.
Doğrulayıcı, tüm imzalarla ilişkili verilerin ve ortak anahtarların bir listesiyle tek bir toplu imzayı doğrular ve bu, ilgili tüm imzaların bağımsız olarak doğrulanmasına eşdeğerdir.
! [BEVM Kurucusu: BTC Layer2 Neden ve Nasıl Yapılır?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/c7ed182df952263f95cd6b5da86e5aa3.)
Şu anda çoğu blok zinciri, her düğümün blok verileri için kendi özel anahtarıyla bağımsız bir dijital imza oluşturduğu ve bunu diğer düğümlere yayınladığı ECDSA multisig algoritmasını kullanmaktadır. Diğer düğüm imzayı doğrular ve bir sonraki veri yığınına yazar.
Bu şekilde, konsensüs düğümlerinin sayısı büyük olduğunda, konsensüs bloklarının her turunda depolanan imza verileri artmaya devam edecek ve depolama alanını işgal edecektir.
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 için 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 toplar ve ardından Şekil 2'de gösterildiği gibi imza parçası toplamını kaydeder.**
Bu şekilde, yeni bir düğüm katıldığında, senkronizasyon geçmişi bloğunun yalnızca toplu imza verilerini indirmesi gerekir, bu da ağ bant genişliğinin işgalini büyük ölçüde azaltır ve işlem ücretlerinin harcanmasını azaltır.
Ek olarak, anahtar toplama, tüm Taproot çıkışlarının benzer görünmesini sağlar. İster çoklu imza çıktısı, ister tek imzalı çıktı veya diğer karmaşık akıllı sözleşmeler olsun, hepsi blok zincirinde aynı görünür, bu nedenle birçok blok zinciri analitiği kullanılamayacak ve tüm Taproot kullanıcıları için gizliliği koruyacaktır. **
! [BEVM Kurucusu: BTC Layer2 Neden ve Nasıl Yapılır?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/187dbc4fe20ec85e558eb12132a2a850.)
MAST (Merkle Soyut Sözdizimi Ağacı), karmaşık kilitleme komut dosyalarını şifrelemek için bir Merkle ağacı kullanan, örtüşmeyen bir dizi komut dosyasıdır (örneğin, multisig veya zaman kilidi).
Harcama yaparken, yalnızca söz konusu komut dosyasının ve bu komut dosyasından Merck ağacının köküne giden yolun açıklanması gerekir. Şekil 3'te gösterildiği gibi, 1'i kullanmak için yalnızca 1, 2 ve hash3'ü açıklamanız gerekir.
MAST'ın başlıca faydaları şunlardır:
1) Karmaşık harcama koşulları için destek
2) Yürütülmemiş komut dosyalarını veya tetiklenmemiş harcama koşullarını ifşa etmeye gerek yoktur, bu da daha iyi gizlilik koruması sağlar
**3) İşlem Boyutunu Sıkıştır: Komut dosyası sayısı arttıkça, MAST olmayan işlem boyutu doğrusal olarak artarken, MAST işlem boyutu logaritmik olarak artar. **
Bununla birlikte, Taproot yükseltmesinde bir sorun var, yani P2SH, ortak Pay-to-Public-Key-Hash (P2PKH) ile aynı değil ve hala gizlilik koruma sorunları var.
P2SH ve P2PKH'nin zincir üzerinde aynı görünmesini sağlamak mümkün mü?
Bu amaçla Taproot, sınırlı sayıda imzalayana sahip bir komut dosyası için iki parçaya bölünebilecek bir çözüm önermektedir:
İlk bölüm, tüm imzacıların "işbirlikçi harcama" olarak bilinen belirli bir harcama sonucu üzerinde anlaştıkları multisig'dir.
İkinci kısım "işbirlikçi olmayan harcama" olarak adlandırılır ve çok karmaşık komut dosyası yapılarına sahip olabilir.
Bu iki kısım "veya" ilişkisidir.
Şekil 3 ve 3'te gösterildiği gibi, 2'nin 2'si çoklu imza, hem Alice hem de Bob'un geçerli olmasını gerektirir, bu da "işbirlikçi harcama" ve 1 ve 2'nin "işbirlikçi olmayan harcama"dır.
Hem "işbirlikçi harcama" hem de "işbirlikçi olmayan harcamalar" bu çıktıyı şu durumlarda harcayabilir:
"İşbirlikçi olmayan harcama" komut dosyası için, yukarıda açıklanan MAST yaklaşımını benimseyin ve Merck ağaç kökünü temsil etmek için MerkleRoot'u kullanın.
"İşbirlikçi harcama" komut dosyası için, Schnoor imzalarına dayalı bir multisig algoritması benimsenmiştir. Pa ve Pb, sırasıyla Alice ve Bob'un açık anahtarlarını temsil etmek için kullanılır ve Da ve Db, sırasıyla Alice ve Bob'un özel anahtarlarını temsil etmek için kullanılır.
Bu nedenle, toplam ortak anahtar P=Pa+Pb'dir ve karşılık gelen özel anahtar Da+Db'dir.
"İşbirlikçi harcama" ve "işbirlikçi olmayan harcamaları" P2PKH biçiminde birleştirin ve açık anahtarı: PP+H(P||MerkleRoot)G; karşılık gelen özel anahtar Da+Db+H(P||MerkleRoot)。
Alice ve Bob "işbirlikçi harcamayı" kabul ettiklerinde, Da+Db+H(P||MerkleRoot), yalnızca birinin özel anahtarına H(P||) eklemesini gerektirirMerkleRoot) kullanın.
Zincir üzerinde bu, altta yatan MAST'ı ifşa etmeye gerek kalmadan bir genel anahtar ve karşılık gelen bir özel anahtarla bir P2PKH işlemi gibi davranır.
III. Tamamen merkeziyetsiz BTC layer2 çözümümüz:
3.1 BTC hafif düğüm + dağıtılmış eşik imzalama sözleşmesi
! [BEVM Kurucusu: BTC Layer2 Neden ve Nasıl Yapılır?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/d6ddaf08422a0b02bc25e45cd2f5d947.)
Bu şemada, dağıtılmış eşik imzalama ile BTC zincir üstü toplam saklama sözleşmesini tamamlamak için n (n BEVM'deki tüm doğrulayıcılar olabilir) sabit doğrulayıcılar seçilir.
BEVM katman2'deki her doğrulayıcının özel anahtarı, BTC'nin eşik imzasının toplam özel anahtarının bir kısmından türetilir ve n doğrulayıcının eşik özel anahtarı, BTC'nin toplu imza fotoğraflı adresinde birleştirilir. **n en fazla 1000 veya daha fazla olabilir. **
A kullanıcısı BTC'yi BEVM'ye çapraz zincirlemek istediğinde, yalnızca Bitcoin toplama saklama sözleşmesine BTC göndermesi gerekir ve kullanıcı BEVM katmanında2 BTC alabilir.
Buna bağlı olarak, A kullanıcısı bir para çekme işlemi gerçekleştirdiğinde, yalnızca n doğrulayıcı arasındaki toplu imzada m otomatik tamamlama dağıtılmış eşik imza sözleşmeleriyle birlikte çalışması gerekir ve emanet sözleşmesinden A kullanıcısına aktarım Bitcoin'de tamamlanabilir ve BTC, aktarım tamamlanırken aynı anda BEVM'de yakılır.
3.2 BTC'yi yerel gaz ücreti ve EVM uyumlu Katman 2 olarak uygulayın
1) EVM İlkesi
Ethereum Sanal Makinesi, Ethereum akıllı sözleşmeleri için çalışma zamanı ortamıdır. Sadece korumalı alanla değil, aynı zamanda tamamen izole edilmiştir.
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ındaki erişim bile kısıtlanmıştır.
Ethereum'un temel katmanı, EVM modülü aracılığıyla sözleşmenin yürütülmesini ve çağrılmasını destekler ve çağrıldığında sözleşme adresine göre sözleşme kodu alınır ve işlem için EVM'ye yüklenir. Tipik olarak, akıllı sözleşme geliştirme süreci, solidlity içinde mantıksal kod yazmak, bir derleyici aracılığıyla bayt koduna derlemek ve son olarak Ethereum'da yayınlamaktır.
! [BEVM Kurucusu: BTC Layer2 Neden ve Nasıl Yapılır?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/2d2d923b8ae9ff718bac8dedbf6a9314.)
2) EVM Ana Parçaları
! [BEVM Kurucusu: BTC Layer2 Neden ve Nasıl Yapılır?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/67f265774f666ae9ab031a29230b5b8d.)
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 okuma/yazma, depolama ve mesaj gönderme yeteneğine sahiptir.
4)Çin Devleti
Mchine State, program sayaçlarını, yığınları ve belleği içeren EVM kodunun yürütüldüğü yerdir.
5)Depolama
Depolama, okunabilen, yazılabilen ve değiştirilebilen kalıcı bir depolama alanıdır ve aynı zamanda her sözleşmenin verileri kalıcı olarak depoladığı yerdir. Depolama, her biri 32 bayt olan toplam 2256 yuvaya sahip devasa bir haritadır.
6) Gaz Ücreti Olarak BTC
Bitcoin ağından aktarılan BTC'nin, EVM'deki işlemlerin yürütülmesi için gaz ücreti hesaplama para birimi olarak kullanılmasına izin verin.