Kanal eklemenin basit açıklaması

"Birleştirme" özünde basit bir kavramdır: yıldırım kanallarını yeniden boyutlandırma yeteneği. Ancak zaman geçtikçe, Lightning kanallarını yeniden boyutlandırma yeteneğinin bize genellikle beklenmedik birçok ek fayda sağlayacağı ve Lightning Network'ün performansını temelden artıracağı giderek daha açık hale geldi.

Kanal birleştirme iki açıdan iyileştirme sağlar:

Kullanıcı odaklı iyileştirmeler

İlk hususu açıklamak nispeten kolaydır: Piyasada pek çok Bitcoin cüzdan uygulaması mevcut ve bu kesinlikle iyi bir şey. Ancak bu geliştiriciler kendi uygulamalarını geliştirdiklerinde bir sorunla karşılaşacaklar: Bu uygulama Bitcoin cüzdanına mı yoksa Lightning cüzdanına mı dönüştürülmeli?

Çoğu cüzdan birini veya diğerini seçecektir, ancak bazı daha iddialı cüzdanlar her ikisini de yapmayı seçecektir! Daha temel bir perspektiften bakıldığında elbette her ikisini de yapmak en iyi çözümdür.

Ancak bu bir sorunu da beraberinde getiriyor. Bu cüzdanlarda "iki grup bakiye" bulunacak; biri ("zincir içi") Bitcoin bakiyesi, diğeri ise Lightning kanalındaki Bitcoin bakiyesi. Hiç Bitcoin'e yeni giren biriyle tanıştınız mı bilmiyorum ama size şunu söyleyebilirim: iki bakiye setine sahip olmak yeni kullanıcılar için kafa karıştırıcı olabilir. Deneyimli Bitcoinciler için bu bir sorun değil ancak herkesin Bitcoin kullanabilmesini istiyoruz.

Bu "iki denge seti" sorunu bir tasarım sorunu değildir ve iki model (zincir içi fonlar ve yıldırım kanalları) temelde farklı olduğundan "tek sete" dönüştürülemezler, aksi takdirde yeni kullanıcı sorunları yaratacaktır. : Güncelleme Uzun ödeme gecikmeleri ve/veya engelleyici ücretler.

Ve eğer ağda uygulanabilirse kanal birleştirme gizli bir silah haline gelecek ve "denge seti" cüzdanını mümkün kılacak. Çünkü kanal birleştirme, bu iki dengenin düşük maliyetle birlikte çalışabilmesine (birbirine dönüştürülebilmesine) olanak sağlar.

Geliştirilmiş arka uç likidite

İkinci husus olan arka uçtaki likidite artışını anlamak daha zor olabilir, ancak Lightning Network üzerinde ("dengeler seti" uygulamasıyla karşılaştırıldığında) daha önemli bir etkiye sahip olacaktır.

Lightning Network, ağa dağılmış birçok "mikro" bankada çalışır. Bu bankalar yalnızca tek bir hizmet sağlıyor: parayı belirli bir yöne taşımak.

Geleneksel bankacılık, az sayıda "gerçek" bankayı güvenilir bir ağa onaylayan dev bir "merkez" banka gerektirir. Ancak Lightning Network tam tersini yapıyor: Neden herkesin kendi bankasını açmasına izin vermiyoruz? Birbirleriyle iletişim kurabilen birçok küçük banka "merkezi olmayan bir banka" haline gelebilir mi? Yeterli sayıda insan bunu yaparsa, sonunda merkez bankası kadar güvenilir, hatta daha güvenilir bir şey yaratabiliriz!

Bu aslında oldu. Lightning Network'teki "mikrobankaların" sayısı her geçen gün artıyor ve yakında 100.000 mikrobankaya sahip olacağız - Amerika Birleşik Devletleri'ndeki 5.000'den çok daha fazla.

Bu mikrobankalar işlemlerinizi yönlendirmek için birbirleriyle yarışacak ve dolayısıyla en ucuz hizmeti sunacaktır. Böyle bir bankanın ödeme yönlendirebilmesi için, Bitcoin'in "Yıldırım Hesaplarından" birinde depolanmış bir miktar fonun olması gerekir.

Bu mikrobankalar işlemlerinizi yönlendirmek için birbirleriyle rekabet edecek ve dolayısıyla en ucuz hizmeti sunacaktır. Böyle bir bankanın ödeme yönlendirebilmesi için, Bitcoin'in "Yıldırım Hesaplarından" birinde depolanmış bir miktar fonun olması gerekir.

Size bazı spesifik rakamlar vereyim: Başarılı bir Lightning bankasının genellikle 100 Lightning hesabı vardır; TA'nın sürekli olarak bu hesaplar arasında fon taşıması ve bir sonraki kullanıcının ödemeyi hangi yönde başlatması gerektiğini tahmin etmesi gerekir. Eğer hesap bakiyesi 100.000 satoshi olan "Sally's Sandwich Shop" yolundaysalar, Sally'den sandviç satın almak istediğinizde, ödemenizi yönlendirmek için sizin tarafınızdan seçilebilirler.

Şimdi, bu mikro bankalardan birinin 100 hesabı yönettiğini, tüketici davranışını tahmin etmek için sürekli olarak hesaplar arasında para aktardığını hayal edin. Bu oldukça zor! Çünkü gerçek şu ki, insanların davranışları çok öngörülemez ve sizinle aynı şeyi yapmak isteyen birçok rakibiniz var.

Peki kanal birleştirmenin bununla ne alakası var? Bu hesaplar arasında fon taşımak pahalıdır; gerçekte, bu yıldırım bankaları hesapların sürekli kapatılmasını ve açılmasını gerektirir. Ayrıca beklenmedik bir talebin ortaya çıkması durumunda Lightning Network'e dağıtılabilecek bir "rezerv" olarak fon tutmaları gerekiyor.

Kanal birleştirme, hem masraflı hesap kapatma ve açma ihtiyacını, hem de atıl "rezerv" fonu tutma ihtiyacını ortadan kaldırır. Bu, bu mikro bankaların işletme maliyetlerini, karmaşıklığını ve atıl sermaye zorluklarını önemli ölçüde azaltacaktır. Kanal Ekleme tüm bunları, fonların doğrudan "Yıldırım Hesapları" arasında aktarılmasına izin vererek (mümkün olduğunca uygun maliyetli olarak) yapar. Daha da iyisi, kanal birleştirme aynı zamanda bu mikro bankaların bağımsız kalmasına ve artık sözde "merkezi likidite sağlayıcılarına" bağımlı olmamasına izin vererek tüm ağın daha güçlü olmasını sağlar.

Bu, Lightning mikro bankalarını çalıştıran insanlar için çok heyecan verici ve elbette sizin gibi Lightning Network kullanıcıları için de aynısı olmalı. Eğer bu mikrobankalar daha verimli çalışabilirse, maliyet tasarrufları doğal olarak kullanıcılara daha ucuz ücretler ve daha güvenilir ödemeler şeklinde yansıyacaktır.

Kanal Ekleme Teknolojisine Genel Bakış

Kanal ekleme, bir yıldırım kanalındaki (kanalın finansmanı UTXO) fonların yeni bir "eklenmiş" UTXO'ya taşınması anlamına gelir. Spesifik işlem çok basittir; fonları yeni bir konuma taşımak için 2/2 çoklu imza işlemini imzalayın. Ancak bu süreci güvene dayalı bir şekilde sürdürmek o kadar da kolay değil.

Orijinal olarak finanse edilen UTXO ve herhangi bir alt HTLC işleminin gerçekten taşınabilmesi için, taahhüt işleminin yeni "eklenmiş" UTXO için yeniden yapılandırılması gerekir.

Ancak yeni kanal için kopyalanmış bir söz durumunu yeniden oluşturmadan önce mevcut kanaldaki durumun anında değiştirilmeyeceğinden emin olmamız gerekir. Bu nedenle, "STFU" olarak kısaltılan "SomeThing Fundamental is Underway" adlı yeni bir yıldırım durumunu tanıttık.

STFU, mevcut kanalın taahhüt durumunda değişiklik yapılmasını bir süreliğine yasaklayacaktır.

Kanala katılan iki düğüm daha sonra interaktif-tx protokolünü kullanarak işlem müzakeresine başlar: her bir taraf sırası geldiğinde hem girdileri hem de çıktıları ekleyebilir. Mevcut kanalın finansmanı UTXO, müzakere edilen işleme girdi olarak eklenecektir.

Her iki taraf da, başka bir kanalın açılması veya hatta başka bir kanalın eklenmesinin işlenmesi gibi ilgisiz faaliyetler için ek girdiler ve çıktılar eklemekte özgürdür. Tüm bu faaliyetler tek bir işlemde birleştirilir.

İşlem müzakeresi ve inşaatı tamamlandıktan sonra her iki taraf da nihai işlemi doğrular, işlem bakiyesinin beklentilere uygun olduğunu teyit eder ve madencilere makul miktarda ücret öder. Daha sonra işlemi imzalarlar ve imzalarını karşı tarafa verirler.

İşlem müzakeresi ve inşaatı tamamlandıktan sonra her iki taraf da nihai işlemi doğrular, işlem bakiyesinin beklentilere uygun olduğunu teyit eder ve madencilere makul miktarda ücret öder. Daha sonra işlemi imzalarlar ve imzalarını karşı tarafa verirler.

İşlem yayınlandıktan sonra her iki taraf da işlemin 6 blok onayı almasını bekler ve ardından birleştirme "tamamlandı" olarak kabul edilir. Şu anda orijinal kanalın durumunu silebilir ve yalnızca eklenmiş kanalın durumuyla ilgilenebilirler. Bu, çok fazla veritabanı alanı tasarrufu sağlayabilir.

(Çevirmenin Notu: Buradaki açıklama çok kaba. Her iki tarafın da mevcut UTXO kanalının UTXO A olduğunu ve oluşturmak istedikleri eklenmiş kanal UTXO'nun UTXO B olduğunu varsayalım. Öncelikle her iki tarafın da UTXO için bir UTXO kanalı oluşturması gerekir. B. Yeni kanalda ilk durum olarak taahhüt edilen bir işlem kullanılır ve bu aynı zamanda güven gerektirmeyen bir garantidir; daha sonra her iki taraf da bir UTXO B işlemi oluşturmak ve bunu yayınlamak için imza atar. UTXO B yeterli blok onayı almadan önce, orijinal kanal çalışmaya devam eder ve her bir taraf Orijinal kanaldaki durumu güncellerseniz, yeni kanaldaki durumu da güncellemeniz gerekir.UTXO B yeterli blok onayı aldığında, artık orijinal kanalın durumunu güncelleyemezsiniz veya orijinal kanalla ilgili verileri silin. Bu, kanalın normal çalışmasını etkilemeden kanal boyutunun değiştirilmesine olanak tanır.)

Kanal ekleme nasıl uygulanır?

Bir Lightning uygulamasının, birleştirmeyi desteklememekten, birleştirmeyi desteklemeye kadar pek çok adımı vardır.

Öncelikle kanal durumunuzun finansman ayrıntılarının üzerine yazılmasına izin verip vermeyeceğine veya birleştirilmiş kanal durumunun tamamen yeni bir durum olarak değerlendirilip değerlendirilmeyeceğine karar vermelisiniz. Her iki yaklaşım da işe yarayabilir ve hangisinin daha ideal olduğu uygulamanızın kanal durumunu nasıl oluşturduğuna bağlıdır.

İki grup çoğaltılmış kanal durumunun avantajları:

İki grup çoğaltılmış kanal durumunun dezavantajları:

Yalnızca bir kanal durumuna sahip olmanın avantajları:

Yalnızca bir kanal durumuna sahip olmanın dezavantajları:

Hangi yaklaşım benimsenirse benimsensin, kanal kimliklerini ve kısa kanal kimliklerini yönetmek için, özellikle de tüm kod bazında işlenmesi gereken anahtarlar olarak kullanıldığında, ek çalışma yapılması gerekir.

Belirli bir kod tabanı için, her yaklaşımın avantajlarını ve dezavantajlarını (hem yeniden düzenlemenin zorluğunu hem de hata oluşturma riskini) göz önünde bulundurmalısınız.

Daha sonra, yeniden kullanılabilir bir etkileşimli işlem yapı taşına ihtiyacınız olacak. Bu modül tüm TX_ADD_INPUT/TX_ADD_OUTPUT tipi mesajları yönetir. Ayrıca ikili finansmanı desteklemek için bu modüle ihtiyacınız vardır, bu nedenle birçok uygulama ikili finansman için bu tür modüller geliştirmektedir.

Bu modül aynı zamanda gelecekteki "kapatmak için ekleme" ve muhtemelen diğer Lightning Network spesifikasyon eklemelerinde de faydalı olacaktır.

Etkileşimli ticaret protokolü, iki yönlü finansman varyantına çok benzer, ancak bazı farklılıklar vardır. Böyle bir modülün farklı senaryolarda çalışabilmesi için geliştirme yaparken lütfen bu farklılıkları aklınızda bulundurun.

Bir sonraki doğal adım "STFU" mantığını uygulamaktır. Birçok kişi STFU protokolünün sanıldığından daha karmaşık olduğunu düşünüyor. Bunun nedeni STFU mesajının aslında STFU modu için bir istek olmasıdır. Bir "STFU" geri alınmadığı sürece etkinleşmeyecektir.

Bir sonraki doğal adım "STFU" mantığını uygulamaktır. Birçok kişi STFU protokolünün sanıldığından daha karmaşık olduğunu düşünüyor. Bunun nedeni STFU mesajının aslında STFU modu için bir istek olmasıdır. Bir "STFU" geri alınmadığı sürece etkinleşmeyecektir.

Karşı taraf, HTLC eklemek ve taahhüt edilen işlemi güncellemek gibi başka şeylerle meşgulse, eldeki işlemi tamamlayana kadar STFU'ya yanıt vermeyecektir.

Bu yazının yazıldığı an itibarıyla yalnızca kanal birleştirme STFU modunu kullanıyor ancak bu durumun gelecekte değişmesi muhtemel. Bu nedenle STFU modülünüzü geliştirirken gelecekteki kullanımlarını düşünmekte fayda var.

STFU moduna ilişkin bazı özel hususlar vardır. Her iki tarafın da aynı anda kanal eklemeyi başlatmak istediği nadir bir durumdur. Bu düğümlü durumları doğru bir şekilde ele almayı unutmayın.

Genel olarak başlatma sırasında, giriş ve çıkışlardan oluşan bir PSBT'yi (Kısmen İmzalı Bitcoin İşlemi) işlemeniz gerekir. Kullanıcılarınız bu işleme girdi ve çıktıların yanı sıra göreceli kanal boyutu değişiklik miktarını da eklemek isteyebilir. Splice ve splice_ack'i göndermek için göreceli miktar değişikliklerini göndermeniz gerekecektir. Her iki tarafın da varyasyon miktarları sağlayabileceğini unutmayın; bu nedenle, alıcı tarafı PSBT varyasyonları konusunda uyaracak bir eklenti geliştirdiğinizden emin olun.