Teklifin kapsamına rağmen, Rusty Russell'ın "harika senaryo kurtarmasının" Bitcoin'ın gelişimi için ileriye giden yol olmasının nedeni nedir?
Blok tek boynuzlu at Not: Rusty Russell, Bitcoin topluluğunda aktif bir geliştiricidir ve toplulukta çok saygı görmektedir. Linux çekirdeği geliştirme üzerinde yoğun bir şekilde çalıştı ve birçok long Bitcoin çekirdek geliştirme projesinde yer aldı.
Bitcoin başlangıçta, kullanıcıların gelecekte karşılaşabilecekleri olası güvenlik kullanım durumlarını kapsayacak ve destek için tasarlanmış eksiksiz bir betik diline sahip olacak şekilde tasarlanmıştır. Satoshi Nakamoto'in ortadan kaybolmadan önce söylediği gibi:
"Bitcoin özü, sürüm 0.1 yayınlandıktan sonra, yaşam döngüsünün geri kalanı için çekirdek tasarımın belirlenmesidir. Bu nedenle, aklıma gelen her olası ticaret türünü destek için tasarlamak istedim. Sorun şu ki, kullanılsın ya da kullanılmasın her şey özel destek kodları ve veri alanları gerektiriyor ve bu da en uzun özel durumlara yol açıyor. Çözüm, sorunu genelleştiren bir komut dosyasıdır, böylece her iki taraf da işlemlerini, Düğüm ağının bu koşullara göre değerlendirdiği veya doğruladığı belirli koşullarla tanımlayabilir." - Satoshi Nakamoto, 17 Haziran 2010
Tüm amacı, kullanıcılara işlem türlerini istedikleri gibi organize edebilecekleri kadar yaygın bir dil vermektir. Yani, kullanıcıların kendi madeni paralarını nasıl yazacaklarını tasarlamaları ve denemeleri için şortlar.
Ortadan kaybolmadan önce, Satoshi Nakamoto bu İşlem Kodlarından 15 tanesini kaldırdı, tamamen devre dışı bıraktı ve komut dosyası altyapısı yığınına, manipüle edilebilecek veri bloklarının boyutunu (520 bayt) sınırlayan katı bir sınır ekledi. Bunun nedeni, karmaşık komut dosyalarının tüm ağda DOS saldırıları gerçekleştirmek için kullanılabileceği birçok yolu geride bırakarak (çok sayıda spam isteği göndermek, ağın çökmesine neden olmak), Düğümleri çökertecek büyük ve maliyetli işlemler yaratmaktır.
Bu İşlem Kodları, özelliklerin tehlikeli Satoshi Nakamoto olduğunu veya insanların bunları elde edilebilecek bir şey oluşturmak için kullanmamaları gerektiğini düşündükleri için değil, sadece (en azından yüzeyde) kaynak kısıtlamaları olmadan tüm ağ için oluşturdukları risk nedeniyle kaldırıldı.
O zamandan beri, her Bitcoin yükseltmesi, kalan özelliklerin işlevsel bir optimizasyonu oldu, Satoshi Nakamoto bize bıraktığı diğer daha az ciddi kusurları düzeltti ve kalan komut dosyası alt kümemizin işlevselliğini genişletti.
Harika komut dosyası kurtarma
Mayıs ayı başlarında Austin Bitcoin++ konferansında, çekirdek Lighting Ağı geliştiricisi Rusty Russell, konferanstaki ilk konuşmasında çok radikal bir öneride bulundu ve burada temel olarak Satoshi Nakamoto'in 2010'da ortadan kaybolmadan önce devre dışı bıraktığı büyük özlem Operasyon Kodu yeniden etkinleştirme fikrini ortaya attı.
Taproot'nin 2021'de etkinleştirilmesinden bu yana geçen yıllarda (Taproot, gizliliği, güvenliği ve ölçeklenebilirliği iyileştirmeyi amaçlayan Bitcoin için büyük bir yükseltmedir), geliştirme alanı aslında biraz amaçsızdı. Hepimiz biliyoruz ki, Bitcoin dünya nüfusunun herhangi bir büyüklüğüne gerçekten kendi kendine egemen hizmetler sunacak kadar ölçeklenebilir değildir ve hatta çok büyük emanetçileri ve hizmet sağlayıcıları aşabilen hizmet sağlayıcılara ölçeklenebilirlik sağlayamayabilir ve güveni veya velayeti en aza indirecek şekilde hükümetlerin long kol kısıtlamalarından gerçekten kurtulamayabilir.
Bu makale, tartışılacak bir konu olmayan Bitcoin teknik düzeyine işaret etmektedir. Tartışmaya değer soru, çok tartışmalı bir konu olan bu kusurun nasıl düzeltileceğidir. Taproot piyasaya sürüldüğünden beri, herkes yalnızca belirli kullanım durumları için elde edilebilecek sorunları çözmeyi amaçlayan çok dar önerilerle geliyor.
Örneğin, ANYPREVOUT (APO), girilen kod ve tutar aynı olduğu long imzaların farklı işlemlerde yeniden kullanılmasına izin veren bir tekliftir ve bu teklif, Lighting Ağı ve long'cu sürümlerini optimize etmek için özel olarak tasarlanmıştır. CHECKTEMPLATEVERIFY (CTV), sabit paraların yalnızca önceden tanımlanmış işlemlerle tam olarak eşleşen işlemler tarafından harcanmasını gerektiren bir tekliftir ve bu teklif, önceden imzalanmış işlem zincirlerini tamamen güvenilmez hale getirerek işlevselliğini genişletmek için tasarlanmıştır. OP_VAULT, bir soğuk depolama çözümü için bir "zaman aşımı" ayarlamak üzere özel olarak tasarlanmıştır, böylece kullanıcılar, Gizli Anahtar tehlikeye girmesini önlemek için daha soğuk bir long ayarlarına göndererek soğuk depolamadan "geri alabilir".
Uzun başka teklifler var, ama sanırım zaten ana fikri anladınız. Son birkaç yılda, her teklif, ölçeklenebilirliği biraz artırmak veya tek bir küçük özelliği iyileştirmek için tasarlandı, çünkü bu arzu edilir olarak kabul edildi. Bu tartışmaların ilerleme kaydetmemesinin temel nedeni budur. Görmek istedikleri kullanım durumlarını karşılamadıkları için kimse diğer tekliflerden memnun değildi.
Teklifin sponsoru dışında hiç kimse, herhangi bir teklifin makul bir sonraki adım olarak kabul edilecek kadar kapsamlı olduğuna inanmıyor.
"Great Script Recovery"nin arkasındaki mantık budur. Başlangıçta tasarlandığı gibi, komut dosyalarının tam olarak kurtarılmasını zorlayarak ve analiz Satoshi Nakamoto ederek, şu anda hangi küçük özellik uzantılarının yeterince iyi olduğu konusunda tartışmak ve kavga etmek yerine, ihtiyacımız olan tüm özellik şortlarını keşfetmeye çalışabiliriz.
OPCODES (Operasyon Kodu)
OP_CAT: Yığından iki parça veri alır ve bunları bir araya getirerek tek bir veri oluşturur.
OP_SUBSTR: Bir uzunluk parametresini (bayt cinsinden) kabul edin, yığından bir parça veri alın, bu uzunluğun baytlarını kaldırın ve yığına geri koyun.
OP_LEFT ve OP_RIGHT: Yığından bir parça veri alan ve belirtilen uzunluktaki baytları bir taraftan veya diğer taraftan kaldıran bir uzunluk parametresini kabul eder.
OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_UPSHIFT ve OP_DOWNSHIFT: Bir veri öğesini kabul eder ve üzerinde ilgili bit işlemlerini gerçekleştirir.
OP_ 2 MUL, OP_2D IV, OP_MUL, OP_DIV ve OP_MOD: Çarpma, bölme ve modulo işlemleri için matematik operatörleri (bölmenin geri kalanını döndürür).
Rusty Russell, kurtarılacak yukarıdaki İşlem Kodları Liste ek olarak, farklı İşlem Kodlarının kombinasyonunu basitleştirmek için tasarlanmış üç İşlem Kodu daha önermektedir:
OP_CTV (veya TXHASH/ eşdeğeri Operasyon Kodu): Bir işlemin tam olarak önceden tanımlandığı gibi olması gereken belirli bölümlerinin ayrıntılı olarak uygulanmasına izin verir.
CSFS: Kodun belirli bölümlerinin veya kullanılan verilerin yürütülmesi için emir imzalanmasını gerektiren yalnızca tüm işlem için değil, imzaların doğrulanmasına izin verir.
OP_TWEAKVERIFY: Toplu Açık Anahtar tek tek Açık Anahtar ekleme veya çıkarma gibi Açık Anahtar içeren Schnorr tabanlı işlemleri doğrular. Bu, bir taraf tek taraflı olarak paylaşılan bir kullanılmayan işlem çıktısını (UTXO) bıraktığında, diğer tüm katılımcıların fonlarının, ortak harcama yapmak için ayrılan tarafın imzasını gerektirmeyen toplu bir ortak anahtara gönderilmesini sağlamak için kullanılabilir.
Bunu neden yapıyoruz
Katman 2 ağlar esasen Bitcoin'in temel katmanının uzantılarıdır ve temel katmanın işlevleri tarafından işlevsel olarak kısıtlanırlar. Lighting Ağı uygulanmadan önce üç ayrı Soft Fork gerekir: CHECKLOCKTIMEVERIFY (CLTV), checksequenceverify (csv) ve SegWit (Segregated Witness).
Daha esnek bir temel katman olmadan, daha esnek bir katman 2 ağı oluşturamazsınız. Tek kestirme yol, çok basit ve anlaşılır olan üçüncü taraflara güvenmektir ve umarım hepimiz güvenilir üçüncü tarafları Bitcoin ile etkileşimin her yönünden mümkün olduğunca geniş ölçekte kaldırmayı arzularız.
İkiden fazla kişiyi tek bir kullanılmayan işlem çıktısında (UTXO) güvenli bir şekilde birleştirmek ve temel katmanda güvenilir bir şekilde performans gösterebilmek emir şu anda mümkün olmayan bir şeyi yapabilmemiz gerekiyor. Bitcoin Script'in mevcut esnekliği yeterli değil. En temel düzeyde, sözleşmelere ihtiyacımız var ve bir kullanıcının kendi UTXO güvenli bir şekilde çıkmasının diğer kullanıcıların fonlarını riske atmamasını sağlamak için işlemlerin yürütülmesiyle ilgili daha ince ayrıntıları gerçekten uygulayabilecek komut dosyalarına ihtiyacımız var.
Daha yüksek bir perspektifte, ihtiyacımız olan şey bu:
İç gözlem: Harcama işleminin kendisiyle ilgili yığındaki belirli ayrıntıları gerçekten kontrol edebilmemiz gerekir, örneğin "bu miktarda para bir çıktının bu açık anahtarına gidecek". Bu, kendi özel Taproot şubemi kullanarak paramı kendi başıma çekmeme izin verirken, başka kimsenin parasını çekemememi sağlıyor. Yürütülen komut dosyası, diğer katılımcıların fon kaybına neden olması durumunda, diğer sahiplerin fonlarının diğer kullanıcıların Açık Anahtar oluşan Adres geri gönderilmesini sağlayacaktır.
İleri Veri Taşıma: Diyelim ki, örneğin çok sayıda insanla, herkesin istediği gibi gelip gidebileceği tek bir UTXO kavramını ele alıyoruz. Bu durumda, genellikle Merkle Ağacı ve köklerini kullanarak, kimin en uzun veya daha az parası olduğunu izlemenin bir yoluna ihtiyacımız var. Bu, birisi ayrıldığında, diğer herkesin fonları için UTXO değişikliğin bir parçası olarak kimin neye hakkı olduğunu "kaydettiğimizden" emin olmamız gerektiği anlamına gelir. Bu temelde iç gözlemin özel bir kullanımıdır.
Açık Anahtar Değişiklik: Toplu Açık Anahtar yapılan değişikliklerin yığın üzerinde doğrulanabilmesini sağlamamız gerekir. Kullanılmayan İşlem Çıktısı (UTXO) paylaşım planında amacımız, tüm katılımcıları içeren toplu bir Açık Anahtar aracılığıyla işbirliğini ve verimli fon akışını kolaylaştırmaktır. Birisi paylaşılan bir UTXO tek taraflı olarak ayrıldığında, kişisel Açık Anahtar toplu Açık Anahtar çıkarmamız gerekir. Tüm olası kombinasyonlar önceden hesaplanmamışsa, tek seçenek, toplam ortak anahtardan bir ortak anahtarın çıkarılmasının, kalan tek tek ortak anahtarlardan oluşan geçerli bir ortak anahtar üreteceğini doğrulamaktır.
Nasıl güvende olunur: VAROPS Yukarıda söylediğim gibi, tüm bu İşlem Kodlarını devre dışı bırakmanın nedeni, ağı oluşturan Düğümlerin çökmesine neden olabilecek DOS saldırıları (çok sayıda spam isteği göndererek ağın çökmesine neden olan) ele almaktır. Bu sorunu çözmenin bir yolu, bu İşlem Kodlarından herhangi biri tarafından kullanılabilecek kaynak miktarını sınırlamaktır.
Bitcoin komut dosyasının en pahalı kısmı olan imza doğrulama söz konusu olduğunda, imza işlemi (sigops) bütçesi adı verilen böyle bir çözümümüz zaten var. İmza kontrolünün Operasyon Kodu her kullanımı, belirli bir "bütçeyi", yani blok başına izin verilen imza işlemlerinin sayısını tüketir ve bu da bir işlemin bir bloğu doğrulamak için oluşturabileceği maliyete katı bir sınır koyar.
Taproot bu çalışma şeklini değiştirir, tek bir global Blok limiti kullanmaya long'cu etmez, bunun yerine her işlemin, işlemin boyutuyla orantılı olarak kendi sigops (imza işlemi) limiti vardır. Bu temelde aynı küresel limite eşittir, ancak her işlemin long daha az sigop'a sahip olduğunu anlamak daha kolaydır.
Her bir işlemi işlemek için Taproot'in sigops (imza işlemi) limitindeki değişiklik, Rusty Russell'ın varops limitleri açısından önerdiği bir genelleme yaklaşımı olasılığını açar. Buradaki fikir, her bir Operasyon Kodu oluşturabileceği en kötü durum senaryosuna, yani doğrulama sırasında ortaya çıkan en pahalı hesaplama maliyetine hesap için yeniden etkinleştirilen her Operasyon Kodu bir maliyet atamaktır. Bu şekilde, her Operasyon Kodu doğrulama işlemi sırasında tüketebileceği kaynak miktarını sınırlayan kendi "sigops" limiti olacaktır. Bu aynı zamanda bu Operasyon Kodu kullanan tüm işlemlerin boyutuna da bağlı olacaktır, bu nedenle Blok başına örtük genel sınıra kadar birikmeye devam ederken çıkarım kolaylaştırılabilir.
Bu, bu spam işlemleri nedeniyle DOS saldırısını (çok sayıda spam isteği göndererek, ağın çökmesine neden olarak) ve Satoshi Nakamoto başlangıçta tüm bu İşlem Kodlarını devre dışı bırakmasına neden olan şeyi çözecektir.
İlerlemek için momentum
Eminim çoğunuz "Bu çok fazla değişiklik" diye düşüneceksiniz. Bunu anlayabiliyorum, ancak bir teklif olarak anlaşılması gereken önemli bir husus, hepsini yapmak zorunda olmadığımızı düşünüyorum. Bu teklifin değeri, tüm bu özelliklerin tamamen geri yüklenmesi değil, geniş bir temel bileşen paketine bütünsel bir bakış atacağımız ve kendimize işlevsellik açısından gerçekten ne istediğimizi soracağımız yönündedir.
Son üç yıldaki çekişme ve tartışmalardan sonra, yalnızca belirli işlevleri olan küçük dar değişiklikler hakkında tartışıyor olmamız tam bir değişim olacaktır. Herkesin bir araya gelip geleceğin yönüne bakabileceği bir meydan gibi. Belki sonunda tüm bu özellikleri geri yükleyeceğiz ya da belki de sadece birkaçını etkinleştireceğiz, çünkü Konsensüs şu ki, bunlar hepimizin açık olması gerektiği konusunda hemfikiriz.
Sonuç ne olursa olsun, bu, gelecekteki yönümüzle ilgili tüm konuşmayı olumlu yönde etkileyen bir değişiklik olabilir. Bir sonraki adımda hangi karanlık rotayı izleyeceğimizi tartışmak yerine, durumun tam bir resmini çizebilir ve tam bir resmini elde edebiliriz.
Bu kesinlikle gitmemiz gereken yol değil, ama hangi rotayı izlemek istediğimize karar vermemiz için en iyi şans olduğunu düşünüyorum. Pratik ve üretken bir şekilde tekrar birlikte çalışmaya başlamanın zamanı geldi.
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.
Harika Komut Dosyası Kurtarma: Bitcoin'ın İleriye Giden Yolu
ORIJINAL YAZAR: SHINOBI
Orijinal derleme: Blok tek boynuzlu at
Teklifin kapsamına rağmen, Rusty Russell'ın "harika senaryo kurtarmasının" Bitcoin'ın gelişimi için ileriye giden yol olmasının nedeni nedir?
Blok tek boynuzlu at Not: Rusty Russell, Bitcoin topluluğunda aktif bir geliştiricidir ve toplulukta çok saygı görmektedir. Linux çekirdeği geliştirme üzerinde yoğun bir şekilde çalıştı ve birçok long Bitcoin çekirdek geliştirme projesinde yer aldı.
Bitcoin başlangıçta, kullanıcıların gelecekte karşılaşabilecekleri olası güvenlik kullanım durumlarını kapsayacak ve destek için tasarlanmış eksiksiz bir betik diline sahip olacak şekilde tasarlanmıştır. Satoshi Nakamoto'in ortadan kaybolmadan önce söylediği gibi:
"Bitcoin özü, sürüm 0.1 yayınlandıktan sonra, yaşam döngüsünün geri kalanı için çekirdek tasarımın belirlenmesidir. Bu nedenle, aklıma gelen her olası ticaret türünü destek için tasarlamak istedim. Sorun şu ki, kullanılsın ya da kullanılmasın her şey özel destek kodları ve veri alanları gerektiriyor ve bu da en uzun özel durumlara yol açıyor. Çözüm, sorunu genelleştiren bir komut dosyasıdır, böylece her iki taraf da işlemlerini, Düğüm ağının bu koşullara göre değerlendirdiği veya doğruladığı belirli koşullarla tanımlayabilir." - Satoshi Nakamoto, 17 Haziran 2010
Tüm amacı, kullanıcılara işlem türlerini istedikleri gibi organize edebilecekleri kadar yaygın bir dil vermektir. Yani, kullanıcıların kendi madeni paralarını nasıl yazacaklarını tasarlamaları ve denemeleri için şortlar.
Ortadan kaybolmadan önce, Satoshi Nakamoto bu İşlem Kodlarından 15 tanesini kaldırdı, tamamen devre dışı bıraktı ve komut dosyası altyapısı yığınına, manipüle edilebilecek veri bloklarının boyutunu (520 bayt) sınırlayan katı bir sınır ekledi. Bunun nedeni, karmaşık komut dosyalarının tüm ağda DOS saldırıları gerçekleştirmek için kullanılabileceği birçok yolu geride bırakarak (çok sayıda spam isteği göndermek, ağın çökmesine neden olmak), Düğümleri çökertecek büyük ve maliyetli işlemler yaratmaktır.
Bu İşlem Kodları, özelliklerin tehlikeli Satoshi Nakamoto olduğunu veya insanların bunları elde edilebilecek bir şey oluşturmak için kullanmamaları gerektiğini düşündükleri için değil, sadece (en azından yüzeyde) kaynak kısıtlamaları olmadan tüm ağ için oluşturdukları risk nedeniyle kaldırıldı.
O zamandan beri, her Bitcoin yükseltmesi, kalan özelliklerin işlevsel bir optimizasyonu oldu, Satoshi Nakamoto bize bıraktığı diğer daha az ciddi kusurları düzeltti ve kalan komut dosyası alt kümemizin işlevselliğini genişletti.
Harika komut dosyası kurtarma
Mayıs ayı başlarında Austin Bitcoin++ konferansında, çekirdek Lighting Ağı geliştiricisi Rusty Russell, konferanstaki ilk konuşmasında çok radikal bir öneride bulundu ve burada temel olarak Satoshi Nakamoto'in 2010'da ortadan kaybolmadan önce devre dışı bıraktığı büyük özlem Operasyon Kodu yeniden etkinleştirme fikrini ortaya attı.
Taproot'nin 2021'de etkinleştirilmesinden bu yana geçen yıllarda (Taproot, gizliliği, güvenliği ve ölçeklenebilirliği iyileştirmeyi amaçlayan Bitcoin için büyük bir yükseltmedir), geliştirme alanı aslında biraz amaçsızdı. Hepimiz biliyoruz ki, Bitcoin dünya nüfusunun herhangi bir büyüklüğüne gerçekten kendi kendine egemen hizmetler sunacak kadar ölçeklenebilir değildir ve hatta çok büyük emanetçileri ve hizmet sağlayıcıları aşabilen hizmet sağlayıcılara ölçeklenebilirlik sağlayamayabilir ve güveni veya velayeti en aza indirecek şekilde hükümetlerin long kol kısıtlamalarından gerçekten kurtulamayabilir.
Bu makale, tartışılacak bir konu olmayan Bitcoin teknik düzeyine işaret etmektedir. Tartışmaya değer soru, çok tartışmalı bir konu olan bu kusurun nasıl düzeltileceğidir. Taproot piyasaya sürüldüğünden beri, herkes yalnızca belirli kullanım durumları için elde edilebilecek sorunları çözmeyi amaçlayan çok dar önerilerle geliyor.
Örneğin, ANYPREVOUT (APO), girilen kod ve tutar aynı olduğu long imzaların farklı işlemlerde yeniden kullanılmasına izin veren bir tekliftir ve bu teklif, Lighting Ağı ve long'cu sürümlerini optimize etmek için özel olarak tasarlanmıştır. CHECKTEMPLATEVERIFY (CTV), sabit paraların yalnızca önceden tanımlanmış işlemlerle tam olarak eşleşen işlemler tarafından harcanmasını gerektiren bir tekliftir ve bu teklif, önceden imzalanmış işlem zincirlerini tamamen güvenilmez hale getirerek işlevselliğini genişletmek için tasarlanmıştır. OP_VAULT, bir soğuk depolama çözümü için bir "zaman aşımı" ayarlamak üzere özel olarak tasarlanmıştır, böylece kullanıcılar, Gizli Anahtar tehlikeye girmesini önlemek için daha soğuk bir long ayarlarına göndererek soğuk depolamadan "geri alabilir".
Uzun başka teklifler var, ama sanırım zaten ana fikri anladınız. Son birkaç yılda, her teklif, ölçeklenebilirliği biraz artırmak veya tek bir küçük özelliği iyileştirmek için tasarlandı, çünkü bu arzu edilir olarak kabul edildi. Bu tartışmaların ilerleme kaydetmemesinin temel nedeni budur. Görmek istedikleri kullanım durumlarını karşılamadıkları için kimse diğer tekliflerden memnun değildi.
Teklifin sponsoru dışında hiç kimse, herhangi bir teklifin makul bir sonraki adım olarak kabul edilecek kadar kapsamlı olduğuna inanmıyor.
"Great Script Recovery"nin arkasındaki mantık budur. Başlangıçta tasarlandığı gibi, komut dosyalarının tam olarak kurtarılmasını zorlayarak ve analiz Satoshi Nakamoto ederek, şu anda hangi küçük özellik uzantılarının yeterince iyi olduğu konusunda tartışmak ve kavga etmek yerine, ihtiyacımız olan tüm özellik şortlarını keşfetmeye çalışabiliriz.
OPCODES (Operasyon Kodu)
Rusty Russell, kurtarılacak yukarıdaki İşlem Kodları Liste ek olarak, farklı İşlem Kodlarının kombinasyonunu basitleştirmek için tasarlanmış üç İşlem Kodu daha önermektedir:
OP_CTV (veya TXHASH/ eşdeğeri Operasyon Kodu): Bir işlemin tam olarak önceden tanımlandığı gibi olması gereken belirli bölümlerinin ayrıntılı olarak uygulanmasına izin verir.
CSFS: Kodun belirli bölümlerinin veya kullanılan verilerin yürütülmesi için emir imzalanmasını gerektiren yalnızca tüm işlem için değil, imzaların doğrulanmasına izin verir.
OP_TWEAKVERIFY: Toplu Açık Anahtar tek tek Açık Anahtar ekleme veya çıkarma gibi Açık Anahtar içeren Schnorr tabanlı işlemleri doğrular. Bu, bir taraf tek taraflı olarak paylaşılan bir kullanılmayan işlem çıktısını (UTXO) bıraktığında, diğer tüm katılımcıların fonlarının, ortak harcama yapmak için ayrılan tarafın imzasını gerektirmeyen toplu bir ortak anahtara gönderilmesini sağlamak için kullanılabilir.
Bunu neden yapıyoruz
Katman 2 ağlar esasen Bitcoin'in temel katmanının uzantılarıdır ve temel katmanın işlevleri tarafından işlevsel olarak kısıtlanırlar. Lighting Ağı uygulanmadan önce üç ayrı Soft Fork gerekir: CHECKLOCKTIMEVERIFY (CLTV), checksequenceverify (csv) ve SegWit (Segregated Witness).
Daha esnek bir temel katman olmadan, daha esnek bir katman 2 ağı oluşturamazsınız. Tek kestirme yol, çok basit ve anlaşılır olan üçüncü taraflara güvenmektir ve umarım hepimiz güvenilir üçüncü tarafları Bitcoin ile etkileşimin her yönünden mümkün olduğunca geniş ölçekte kaldırmayı arzularız.
İkiden fazla kişiyi tek bir kullanılmayan işlem çıktısında (UTXO) güvenli bir şekilde birleştirmek ve temel katmanda güvenilir bir şekilde performans gösterebilmek emir şu anda mümkün olmayan bir şeyi yapabilmemiz gerekiyor. Bitcoin Script'in mevcut esnekliği yeterli değil. En temel düzeyde, sözleşmelere ihtiyacımız var ve bir kullanıcının kendi UTXO güvenli bir şekilde çıkmasının diğer kullanıcıların fonlarını riske atmamasını sağlamak için işlemlerin yürütülmesiyle ilgili daha ince ayrıntıları gerçekten uygulayabilecek komut dosyalarına ihtiyacımız var.
Daha yüksek bir perspektifte, ihtiyacımız olan şey bu:
İç gözlem: Harcama işleminin kendisiyle ilgili yığındaki belirli ayrıntıları gerçekten kontrol edebilmemiz gerekir, örneğin "bu miktarda para bir çıktının bu açık anahtarına gidecek". Bu, kendi özel Taproot şubemi kullanarak paramı kendi başıma çekmeme izin verirken, başka kimsenin parasını çekemememi sağlıyor. Yürütülen komut dosyası, diğer katılımcıların fon kaybına neden olması durumunda, diğer sahiplerin fonlarının diğer kullanıcıların Açık Anahtar oluşan Adres geri gönderilmesini sağlayacaktır.
İleri Veri Taşıma: Diyelim ki, örneğin çok sayıda insanla, herkesin istediği gibi gelip gidebileceği tek bir UTXO kavramını ele alıyoruz. Bu durumda, genellikle Merkle Ağacı ve köklerini kullanarak, kimin en uzun veya daha az parası olduğunu izlemenin bir yoluna ihtiyacımız var. Bu, birisi ayrıldığında, diğer herkesin fonları için UTXO değişikliğin bir parçası olarak kimin neye hakkı olduğunu "kaydettiğimizden" emin olmamız gerektiği anlamına gelir. Bu temelde iç gözlemin özel bir kullanımıdır.
Açık Anahtar Değişiklik: Toplu Açık Anahtar yapılan değişikliklerin yığın üzerinde doğrulanabilmesini sağlamamız gerekir. Kullanılmayan İşlem Çıktısı (UTXO) paylaşım planında amacımız, tüm katılımcıları içeren toplu bir Açık Anahtar aracılığıyla işbirliğini ve verimli fon akışını kolaylaştırmaktır. Birisi paylaşılan bir UTXO tek taraflı olarak ayrıldığında, kişisel Açık Anahtar toplu Açık Anahtar çıkarmamız gerekir. Tüm olası kombinasyonlar önceden hesaplanmamışsa, tek seçenek, toplam ortak anahtardan bir ortak anahtarın çıkarılmasının, kalan tek tek ortak anahtarlardan oluşan geçerli bir ortak anahtar üreteceğini doğrulamaktır.
Nasıl güvende olunur: VAROPS Yukarıda söylediğim gibi, tüm bu İşlem Kodlarını devre dışı bırakmanın nedeni, ağı oluşturan Düğümlerin çökmesine neden olabilecek DOS saldırıları (çok sayıda spam isteği göndererek ağın çökmesine neden olan) ele almaktır. Bu sorunu çözmenin bir yolu, bu İşlem Kodlarından herhangi biri tarafından kullanılabilecek kaynak miktarını sınırlamaktır.
Bitcoin komut dosyasının en pahalı kısmı olan imza doğrulama söz konusu olduğunda, imza işlemi (sigops) bütçesi adı verilen böyle bir çözümümüz zaten var. İmza kontrolünün Operasyon Kodu her kullanımı, belirli bir "bütçeyi", yani blok başına izin verilen imza işlemlerinin sayısını tüketir ve bu da bir işlemin bir bloğu doğrulamak için oluşturabileceği maliyete katı bir sınır koyar.
Taproot bu çalışma şeklini değiştirir, tek bir global Blok limiti kullanmaya long'cu etmez, bunun yerine her işlemin, işlemin boyutuyla orantılı olarak kendi sigops (imza işlemi) limiti vardır. Bu temelde aynı küresel limite eşittir, ancak her işlemin long daha az sigop'a sahip olduğunu anlamak daha kolaydır.
Her bir işlemi işlemek için Taproot'in sigops (imza işlemi) limitindeki değişiklik, Rusty Russell'ın varops limitleri açısından önerdiği bir genelleme yaklaşımı olasılığını açar. Buradaki fikir, her bir Operasyon Kodu oluşturabileceği en kötü durum senaryosuna, yani doğrulama sırasında ortaya çıkan en pahalı hesaplama maliyetine hesap için yeniden etkinleştirilen her Operasyon Kodu bir maliyet atamaktır. Bu şekilde, her Operasyon Kodu doğrulama işlemi sırasında tüketebileceği kaynak miktarını sınırlayan kendi "sigops" limiti olacaktır. Bu aynı zamanda bu Operasyon Kodu kullanan tüm işlemlerin boyutuna da bağlı olacaktır, bu nedenle Blok başına örtük genel sınıra kadar birikmeye devam ederken çıkarım kolaylaştırılabilir.
Bu, bu spam işlemleri nedeniyle DOS saldırısını (çok sayıda spam isteği göndererek, ağın çökmesine neden olarak) ve Satoshi Nakamoto başlangıçta tüm bu İşlem Kodlarını devre dışı bırakmasına neden olan şeyi çözecektir.
İlerlemek için momentum
Eminim çoğunuz "Bu çok fazla değişiklik" diye düşüneceksiniz. Bunu anlayabiliyorum, ancak bir teklif olarak anlaşılması gereken önemli bir husus, hepsini yapmak zorunda olmadığımızı düşünüyorum. Bu teklifin değeri, tüm bu özelliklerin tamamen geri yüklenmesi değil, geniş bir temel bileşen paketine bütünsel bir bakış atacağımız ve kendimize işlevsellik açısından gerçekten ne istediğimizi soracağımız yönündedir.
Son üç yıldaki çekişme ve tartışmalardan sonra, yalnızca belirli işlevleri olan küçük dar değişiklikler hakkında tartışıyor olmamız tam bir değişim olacaktır. Herkesin bir araya gelip geleceğin yönüne bakabileceği bir meydan gibi. Belki sonunda tüm bu özellikleri geri yükleyeceğiz ya da belki de sadece birkaçını etkinleştireceğiz, çünkü Konsensüs şu ki, bunlar hepimizin açık olması gerektiği konusunda hemfikiriz.
Sonuç ne olursa olsun, bu, gelecekteki yönümüzle ilgili tüm konuşmayı olumlu yönde etkileyen bir değişiklik olabilir. Bir sonraki adımda hangi karanlık rotayı izleyeceğimizi tartışmak yerine, durumun tam bir resmini çizebilir ve tam bir resmini elde edebiliriz.
Bu kesinlikle gitmemiz gereken yol değil, ama hangi rotayı izlemek istediğimize karar vermemiz için en iyi şans olduğunu düşünüyorum. Pratik ve üretken bir şekilde tekrar birlikte çalışmaya başlamanın zamanı geldi.