2010'daki uygulayıcılar, on yıl sonra BTC inşaatına giden yolu nasıl görüyorlar?

Yazar: BTC Podcast Block Digest'in kurucu ortağı Shinobi; çeviri: Wuzhu, Jīnsè Cáijīng

Bu makale Shinobi tarafından on yıl önce yazılmış olup, 2020'de BTC'nin nasıl olduğunu tartışmaktadır.

Bu seri makalenin ilk bölümüne buradan ulaşabilirsiniz: "2010 yılında uygulayıcılar on yıl sonra BTC ekosistemine nasıl bakıyor?"

İkinci katmanın potansiyelinin ilk on yılın temel protokolünden gelişmeye başlayan tohumlarını görmeye başladık. Lightning Network, oldukça büyük bazı kısıtlamalara rağmen gerçekten gelişmeye başladı. Bu şu anda belirlenen ve dağıtılan sınırlı ilk sürüm. Liquid, RSK gibi çeşitli yan zincir türleri dağıtıldı: Ve hatta BTC ile ilişkilendirilen Commerceblock tarafından geliştirilen token zinciri. Bu sadece bir başlangıç.

###SCHNORR ve TAPROT

Kısa bir süre sonra, Schnorr ve Taproot'un kombinasyonuna sahip olduk. Schnorr'un bakış açısından, bu, maliyeti daha düşük olan bir toplu doğrulama imza şemasıdır ve BTC'nin çoklu imza betik yapılandırmasını optimize etmek için bir sonraki büyük sıçramadır. Çoklu imza başlangıçta tüm açık anahtarları ve çoklu imza betiklerini bir işlem çıktısına doldurarak göndermekti ve bunları kullanabilmek için tüm bunları girdiye dahil etmek zorundaydınız. P2SH, çoklu imzanın açık anahtarını ve betiğini içeren sabit uzunluklu bir karma değeriyle çıktıyı optimize etti ve çoklu imza adresine gönderen herkesin maliyetten tasarruf etmesini sağladı, yalnızca gönderene maliyet ekledi. SegWit, çoklu imza UTXO'larını daha ucuz hale getirerek harcamayı sağlayan bir tanıklık indirimi yoluyla daha da 'optimize' edebilir. Schnorr, tüm bu artımlı iyileştirmeleri en üst düzeye çıkarır. Herkesin bir imza oluşturması için bir anahtar olarak tüm açık anahtarları birleştirir, ardından herkesin bunu yapması için işbirliği yapmasına ve kontrol etmesine olanak tanır. Bu, tüm çoklu imza teknolojileri için (ikinci katmanlar arasında Lightning ve yan zincirler gibi Lightning ve yan zincirler gibi Lightning ve yan zincirler gibi (Lightning)) önemli miktarda maliyet tasarrufu sağlar ve tüm bu çoklu imza UTXO'ları ile tek imzalı UTXO'ları ayırt edilemez hale getirerek gizlilik avantajı sağlar.

Şu anda, bu her şeyin tamamen gizli olmasını sağlamaz. Lightning ağı durumu (işlemler) hala ayrı anahtar yolları gerektirir, böylece cezai işlemler eski duruma yanıt verebilir. Bu, bu çıktı betiğinde parmak izi oluştururken yapılmalıdır. Taproot, bu sorunu şifreleme sihrini kullanarak çözer, farklı harcama koşullarına sahip bir merkle ağacını sunabilir, sadece koşulların ve merkle ispatının merkle köküne kadar harcanabilir olmasını sağlayabilir, görünüşte normal Schnorr anahtarları kullanılabilir. Artık, bu cezai betik yolunu taproot ile gizleyebilirsiniz. Herhangi bir koşullu betik yolunu gizleyebilir, görünüşte normal Schnorr anahtarlarının altında gizlenebilir, bu anahtar tüm katılımcıların bir şey üzerinde anlaşması ve görünüşte normal işlemler yapması için izin verir.

###SIGHASH_ANYPREVOUTPUT

SIGHASH_ANYPREVOUTPUT (önceki olarak SIGHASH_NOINPUT olarak bilinir) gelecekte yeni bir temel dil olabilir. Bu, yeni bir genel anahtar biçimi/sighash bayrağı güncellemesidir. Sighash bayrağı, hangi bölümlere imzanın gönderileceğini belirler. Bu özelliğin varlığı, yalnızca kendi girdilerinizi ve çıktılarınızı imzalamanıza izin verirken, başkalarının girdi ve çıktılarını işleme eklemelerine ve geçersiz kılınmamalarına olanak tanımak içindir. Ancak şu anda, imzanın kesin işlem ve kesin UTXO'dan gelmesi gerekmektedir. Diğer şeylerin yanı sıra, SIGHASH_ANYPREVOUT imzayı UTXO betiğine sunabilir, özel bir UTXO değil. Bu, bir hileli durumu ele almadan veya eski durumlarla uğraşmadan bir blitz kanal durumu oluşturmanın yeni bir yolunu (eltoo) sağlar, bu da aldatılan tarafın tüm fonlarına el koymasına izin verir. Aksine, mevcut kanal durumu bir çift ödeme yarışmasında başarısız olduğunda, sadece eski kanal durumunu tekrar kullanabilir ve böylece herkesin zincirde mevcut kanal bakiyelerine, önceki süresi dolmuş bakiyelerine değil, erişmesini garanti eder. Bu yapılabilmesi için aynı betiği doğru konumda tekrar kullanmanız ve SIGHASH_ANYPREVOUT'u kullanmanız yeterlidir.

Bu, mevcut kanal durumunuzu kaybetmeniz gibi birçok riski ortadan kaldırır ve kasıtsız bir hata nedeniyle paranızı alıkoyan bir ceza işlemiyle sonuçlanır. Ayrıca çok daha fazlasını yapabilir. Artık 2'den fazla katılımcıya sahip yıldırım kanallarına sahip olabilir ve hatta bunların üzerine "alt kanallar" yığabiliriz. Buna ek olarak, SIGHASH_ANYPREVOUT ve eltoo, konsorsiyumun kimseyi dolandırmak için geçmiş katılımcılarla gizli anlaşma yapmayacağı varsayımıyla, yeni katılımcıların tamamen zincir dışına girip çıkmasına izin veren birleşik bir kanal yapısı olan Statechains'i oluşturabilir. Bu, her zaman "çok partili statik UTXO protokolü" olarak adlandırdığım şey için çok fazla potansiyel açar.

###OP_CHECKTEMPLATEVERIFY

OP_CTV, Jeremy Rubin'in önerdiği bir tekliftir ve BTC üzerinde çok temel bir 'sözleşme' oluşturmayı amaçlar. Sözleşme, bir BTC kullanımına daha karmaşık kısıtlamalar getirir, sadece belirli anahtarların imzalanması değil. Rubin'in önerdiği sözleşme türü 'şablon' dur. Temelde, bu, UTXO'nun skriptinin, belirli bir kesin çıktı oluşturulmasını talep etmesine izin verir. Bu nedenle, bir UTXO OP_CTV kullanılarak oluşturulduğunda, bu UTXO'nun belirli bir adrese harcanması gerektiği, miktarının bu UTXO'nun skriptinde tanımlandığı zorunlu olarak uygulanır. Onları hatta birbirine bağlayabilir ve bir UTXO'nun belirli sayıda daha oluşturulmasını zorunlu kılar, bu oluşturulan UTXO'lar da aynı şekilde zorunlu olarak diğerlerini oluşturur, ve bu böyle devam eder.

Herhangi bir yerde geniş bir genel uygunluk bulunmaktadır. Yüksek maliyetli ortamlarda, bir kusturucu varlık tek tek UTXO'lar oluşturabilir, bu varlık tüm müşterilerinin fonlarının sonunda müşteri tarafından kontrol edileceğini mutabakat kurallarına göre %100 garanti eder, hatta bu fonlara anında erişemiyor olabilirler. Bu, çoklu kanalın (kanal fabrikası gibi) büyük potansiyel işbirliği yapabileceği anlamına gelir, çünkü bu tür büyük ölçekli "para çekme" işlemleri aynı zamanda kanal fabrikası olarak oluşturulabilir ve kullanılabilir. OP_CTV, ödeme kanallarını en azından tek yönlü olarak çalıştırmak için kullanılabilir, alıcı tarafın ödeme almak için katılmasına veya çevrimiçi olarak anahtar bulundurmasına gerek yoktur (unutmayın, kanalları üst üste koyabilirsiniz). Ayrıca, tek bir kanalın daha fazla HTLC'yi aynı anda işlemesine izin vermek için bile kullanılabilir, bunları bir araya getirerek ve ilk kusturucu örneğinde kullanılan yöntemle. Yeni türlerde coinjoin için bazı potansiyel yaratabilir bile.

###Tüm unsurları entegre etmek

Yukarıdaki tüm önerilerin kabul edilip BTC'ye dahil edilmesi durumunda, bu ileri çalışmalarla uğraşan geliştiricilerden başka, insanların bu temel dillerin ne tür protokoller ve hizmetlerin inşa edilmesinde kullanılacağını bile bilmediğini düşünüyorum. Ya da hizmetlerle protokoller arasında net bir ayrım olmayan garip şeyler.

Onlar teorik olarak sınırsız katılımcı sayısına izin veren çok taraflı kanalları etkinleştirecekler, bu kanallar temel kanal katılımcılarının daha küçük alt grupları üzerine yığılabilecek. Bu 'kanal fabrikaları' üzerinde, insanların çevrimdışı anahtarlarına sahip olmadan ödeme alabilmelerine olanak tanımak için kanallar inşa edilebilir. Bu çok taraflı kanallar kendileri birleşik kanalların üzerine yığılabileceği (durum zinciri) ve katılımcıların zincirde etkinlik göstermeden giriş veya çıkış yapmalarına izin veren durumları sağlayabilir! Kanal 'eklemesi' yapısı, likiditenin farklı kanallar arasında nispeten sorunsuz bir şekilde hareket etmesine izin verecek, bu da insanların henüz gerçekten düşünmeye bile başlamadığı çeşitli şeyleri gerçekleştirmelerini sağlayacak.

Son cümlem şuydu: Bu sadece BTC protokol yığınının doğrudan bir parçası olarak düşündüğüm şeyleri düşünmekti. Merkezi depolama hizmetlerini araştırmaya başlarsanız ve bu hizmetlerin hangi alt kümeleri sunabileceğini, düzenlemelerden veya yasal engellerden etkilenmeden daha fazlasını yapabilirsiniz.