By Bitcoin Dergi - 6 ay önce - Okuma Süresi: 6 dakika
Zaman Aşımı Ağaçları: Lightning Network LSP'lerini Ölçeklendirmeye Yönelik Bir Çözüm
Lightning Network'ün en büyük sınırlamalarından biri, blok boyutu sınırı göz önüne alındığında blok başına açılabilen veya kapatılabilen kanalların sınırlı sayıda olmasıdır. Zincir dışında ne kadar çok işlemin ne kadar ucuza gerçekleşebileceğine bakılmaksızın, bu, kaç kişinin Lightning Network'ü gerçekçi bir şekilde kullanabileceğini kısıtlayan temel bir darboğazdır. Lightning Network teknik incelemesi bile, 7 milyarlık tüm dünya nüfusunun Lightning'i kullandığı ve kişi başına yılda yalnızca iki zincir içi işlemin gerçekleştiği bir senaryoda, Bitcoin Lightning'in çalışması için 133 MB blok gerekir. Bu, bir alan dışı sorun ya da öngörülemeyen bir sorun değil, ilk günden itibaren tamamen anlaşılan protokol tasarımının bir sınırlamasıydı.
Bu sorunu çözmeye yönelik planın bir parçası her zaman kanal fabrikaları, yani ikiden fazla kullanıcının katıldığı bir kanal türü fikri olmuştur. Lightning ve Network'ü ölçeklendirmek için işlerin her zaman gitmesi gereken yön buydu. Bitcoin Blok boyutunda bir artış olmadan, ancak sorun şu ki, zincirdeki ayak izleri sorununu çözmek, bir dizi başka sorunu da beraberinde getiriyor. Her şeyden önce, karşı tarafın yanıt vermemesi durumunda ara devletlerin uygulanması gerekliliği konusunda temel hiçbir değişiklik olmayacak. Bunun katma değere etkisi var. Bir kanal fabrikasının tüm amacı, örneğin yirmi kişinin bir UTXO'yu paylaşabilmesi ve içerideki likiditeyi diğer yirmi kişiyle istedikleri gibi yeniden düzenleyebilmesidir. Birisi zinciri işbirlikçi olmayan bir şekilde kapattığında, bu, o hedefe müdahale etmeye başlar.
Eğer kanalımı bir kanal fabrikasında kapatırsam, bir grup insanı da benimle birlikte fabrikanın dışına sürüklemiş olurum. Bir merkle ağacı gibi bir fabrika düşünün, tepede bir UTXO var ve bu, zincir dışı olarak yarıya bölünüyor ve bunlar da yarıya bölünüyor, ta ki herkesin bireysel kanallarına ulaşana kadar. Kanalımı fabrikadan çıkardığımda, zincire bağlanan her bölünmede benim tarafımda olan herkesin fabrikadaki diğer herkesle bağlantısı kesilmiş olacak. Herkes işbirliği yaparsa artık likiditelerini grubun o kısmına yeniden düzenleyemezler.
Bir başka büyük sorun da, bir işlemi başlatırken bile, tüm işlemlerin önceden imzalanması için herkesin çevrimiçi olmasını gerektirmesidir. Bir fabrikada yirmi kişinin olmasını istiyorsanız, herkesin çevrimiçi olması gerekir. Bin kişi istiyorsanız bin kişinin çevrimiçi olması gerekir vs.
Bu, kanal fabrikalarını çözülmesi gereken birçok sorunla dolu büyük bir tasarım alanı haline getirir. Yani Lightning için mevcut bir sorunu çözüyoruz ama bir sürü yeni sorun yaratıyoruz. Bana mühendislik gibi geliyor.
Zaman Aşımı Ağaçları
John Law'ın son teklifi, Zaman Aşımı Ağaçları, kanal fabrikalarının temel sorununa bir çözüm sunmaya çalışıyor. Zaman aşımı ağacını tam olarak bir kanal fabrikası olarak adlandıramam, daha ziyade bir "proto-fabrika" olarak adlandırabilirim, ancak bu, işbirlikçi olmayan kapanışlar sorununu ortaya çıkarmadan, büyük miktarda kanalın açılıp kapanması sorununa potansiyel bir çözüm sunar. Fabrikanın diğer kullanıcılar için kullanılması. İşlevsel olarak çalışabilmesi için CHECKTEMPLATEVERIFY (CTV) ve bir Aydınlatma Servis Sağlayıcısı (LSP) gerektirir.
Bir Zaman Aşımı Ağacı, esas olarak, özel bir kaçış hükmü ile likiditenin zincir dışında yeniden düzenlenme şeklini değiştirme yeteneği olmayan, sözleşmelerle garanti edilen bir kanal fabrikasıdır. Onlara Bob adını vereceğimiz bir LSP, sıradan kullanıcıları daha geniş Lightning Network'e bağlama rolünü oynar. Bob, kontrol ettiği paraları alabilir ve LSP hizmetinin herhangi bir sayıdaki kullanıcısına kanal açmak için tek bir UTXO açan bir CTV ağacı oluşturabilir. CTV'nin güzel yanı, bunun herkes aynı anda çevrimiçi olmadan yapılabilmesine olanak sağlamasıdır. Bob, herkesin ilk kanal durumlarını teker teker imzalamasını sağlayabilir ve herkes kanalı kurana kadar bu bilgileri elinde tutabilir ve her kullanıcı için kanal kurduğunda parayı CTV ağacına harcayabilir.
Bu, "fabrikayı" kurup Lightning'i kullanmaya başlamak için herkesin aynı anda çevrimiçi olması sorununu çözüyor. CTV nedeniyle Bob, herkesin Lightning kanallarını kurmak için ağaca para harcadığında, onun geri adım atıp paraları alması (henüz) mümkün değildir. CTV'deki ilk UTXO'nun zincir üzerinde onaylanmasıyla, herkes kanallarını açık olarak değerlendirebilir ve bunların iki kez harcanması riski ortadan kalkar.
Şimdi son kısım kanalları kapatmak. Her ne kadar bunları açmak CTV nedeniyle zincir üzerinde yalnızca tek bir UTXO gerektirse de, bunları kapatmak yine de herkesin kanal durumlarını gönderebilmesi için tüm CTV ağacının zincir üzerinde açılmasını gerektirecektir, değil mi? Yanlış. Bu, Zaman Aşımı Ağaçlarının Zaman Aşımı kısmıdır. Zaman Aşımı Ağacındaki her dalın, Bob'un bir zaman aşımından sonra tüm fonları süpürebileceği bir komut dosyası dalı vardır.
Zaman Aşımı Ağacının diyagramı.Şimdi "ne!?" diye düşündüğünüze eminim. Bu teklifin işleyişinin gerçek dehası budur. Bob, zincir üzerindeki UTXO'ları zaman kilidinden sonra başkası olmadan kendisi tarayabildiğinden, kullanıcılar gerçekten tüm ağacı açıp zincirdeki gerçek kanal finansmanını onaylamadıkça bu kanalların hepsinin bir son kullanma tarihi vardır. Bu, Bob'un düzgün bir şey yapmasına olanak tanır: Zaman aşımı yaklaştığında, mevcut olanın tüm kullanıcılarıyla yepyeni bir Zaman Aşımı Ağacı açabilir ve onların tüm fonlarını süresi dolan ağaçtan yenisine tamamen taşımalarını sağlayabilir. - Lightning'i zincirleyin ve ardından son ağacın zincir üzerindeki tek UTXO'sunu süpürün.
Bu, zincirdeki tüm bu kanalların verimli bir şekilde kapatılmasına olanak tanır. Artık geriye kalan tek sorun, diğer tarafın işbirliğini bırakması durumunda zincir üzerinde HTLC'yi zorunlu kılmaktır. Peki… bu durumda bu gerçekten bir sorun değil, daha doğrusu ya hep ya hiç meselesi. Bir HTLC'yi uygulamak için kanalların kapatılmasının nedeni, kanalın diğer tarafının onu yönlendirmenin ortasında yanıt vermeyi bırakmasıdır. Zaman Aşımı Ağacında her kullanıcının karşılığı Bob'dur. Yani eğer Bob, dürüst olduğu sürece, bir kullanıcı için başarısız veya başarılı bir HTLC'nin güncellenmesine yanıt vermiyorsa, başka hiçbir kullanıcı için de yanıt vermiyordur. Bu durumda herkes zaman aşımından önce zincirdeki kanallarını kapatabilir ve Bob'un LSP'sini kullanmayı bırakabilir.
Yukarı tamamlayan
Kullanıcılar yine de zincir içi etkileşimler için ücret ödemek zorunda kalacaklar, bunun çaresi yok ve tüm Zaman Aşımı Ağacının zincir üzerinde işbirlikçi olmayan bir şekilde kapanması zincir üzerinde büyük ve pahalı bir ayak izi olacaktır, ancak bu sonuçta bir sorundur herhangi bir çok partili kanal sisteminin ele alması gerekecektir. Ancak Zaman Aşımı Ağaçları, sistemin güven modelini saklamaya yönelik bir şeye indirgemeden, devasa çok partili bir kanalın hem açılması hem de kapatılması şeklindeki işbirlikçi duruma yönelik ilgi çekici çözümlere sahiptir.
John, makalenin en son versiyonunda, Bob'un zaman aşımından sonra bir grup parçalanmış ağaç UTXO'sunu süpürme maliyetini karşılamaya yetecek kadar işbirlikçi olmayan kapatmalar nedeniyle kullanıcıların cezalandırılabileceği bir plan önerdi. Bob'un eylemsizliği veya sahtekârlığı, kullanıcıların ağacın kendi kısımlarını işbirlikçi olmayan bir şekilde kapatmak zorunda kalmasına neden oluyorsa, potansiyel olarak bunun tersini yapmanın yolları vardır.
Ancak günün sonunda bu, yarı tanımlanmış ve belirsiz bir kavram yerine gerçek kullanım ve uygulama sorunlarını ele almaya çalışan bir kanal fabrikası tasarımı için çok somut ve spesifik bir öneridir. Bu, Lightning'in uzun vadeli ölçeklendirme sınırlamalarının ele alınması açısından büyük bir ilerlemedir.
Orjinal kaynak: Bitcoin Wos Magazine