Sözlük / Lightning ve katman 2
CLTV son kullanma deltası
- CLTV son kullanma deltası nedir?
- CLTV son kullanma deltası, bir Lightning düğümünün gelen bir ödemenin zaman kilidinden, ödemeyi iletmeden önce çıkardığı blok sayısıdır ve kanal yönü başına gossip içinde duyurulur.
Bir Lightning rotasındaki her iletim düğümü iki bedel alır: milisatoshi cinsinden bir ücret ve blok cinsinden bir gecikme. CLTV son kullanma deltası bu gecikmedir. BOLT 7 bunu, fee_base_msat ile birlikte channel_update mesajında 16 bitlik bir alan olarak taşır ve bir kanalın her iki tarafı kendi değerini bağımsız olarak yayımlar. Bir ödeme sıkışırsa, parasınızın donmuş kaldığı süre bu blok yığını kadardır.
Nasıl çalışır
CLTV son kullanma deltasını, iletimi yapacak düğüm seçer ve bu değer yalnızca o düğümün giden yönünü yönetir.
Şartnamedeki ifade kesindir: bir düğüm, alanı gelen bir HTLC'nin cltv_expiry değerinden çıkaracağı blok sayısına ayarlamalıdır. Yani delta bir son tarih değil, bir aralıktır. Düğüm, belirli bir mutlak blok yüksekliğine kadar kilitli bir ödemeyi kabul eder, deltayı kendine ayırır ve bir sonraki durağa, o yükseklik eksi delta değerine kadar kilitli bir ödeme sunar. Bu aralık düğümün güvenlik payıdır: aşağı yöndeki durak son olası anda uzlaşırsa, yukarı yönde talepte bulunmak için o kadar blok kalır.
Her genel kanal bu sayılardan ikisini taşır, her yön için bir tane ve her biri onu belirleyen düğüm tarafından imzalanır. Bunlar, htlc_minimum_msat ve iki ücret alanının yanında channel_update, yani 258 mesaj türü içinde yer alır. Yalnızca iletim yapacak düğümlerin duyurduğu güncellemeler önemlidir: A'dan B'ye, B'den C'ye, C'den D'ye giden bir rotada ödeyen taraf, B'den C'ye geçiş için B'nin güncellemesini, C'den D'ye geçiş için C'nin güncellemesini kullanır, kendininkini değil.
Bu nedenle rotalar geriye doğru kurulur. Ödeyen taraf, faturanın istediği asgari nihai son kullanma süresiyle varış noktasında başlar, her durağın duyurulan deltasını ekleyerek geriye doğru yürür ve ortaya çıkan toplam, ilk eşine teslim ettiği HTLC'nin zaman kilidi olur. Bir düğüm fiyatlarını değiştirdiğinde BOLT 7, önceki parametreleri 10 dakika daha kabul etmeye devam etmesini ister, çünkü gossip her ödeyene aynı anda ulaşmaz.
Nerede görülür
CLTV son kullanma deltaları, sıkışan bir Lightning ödemesinin bakiyenizi ne kadar süre bağlı tutacağını belirler ve BOLT 7'nin kendi yönlendirme örneği, bunun dışında aynı olan iki rotaya rakamlar koyar.
Dört düğüm bir elmas oluşturur: 10, 20, 30 ve 40 blok duyuran A, B, C ve D; C ise şartnamenin varsayılan olarak adlandırdığı 18 değerinde bir nihai son kullanma deltası ister. A, C'ye 4.999.999 milisatoshi gönderir. B üzerinden yönlendirildiğinde A, eşine 5.010.198 milisatoshi teslim eder, bunun 10.199 kadarı B'nin ücretidir ve ilk HTLC mevcut blok yüksekliği artı 80 değerinde sona erer: B'nin durağı için 20 blok, C için 18 blok ve 42 blok daha dolgu. D üzerinden yönlendirildiğinde aynı ödeme 5.020.398 milisatoshi tutar ve mevcut yükseklik artı 100 değerinde sona erer. Aynı gönderen, aynı alıcı, aynı tutar ve 20 blok daha fazla maruz kalma.
Bu 42 keyfi bir fazlalık değildir. BOLT 7, deltaları dürüstçe toplayarak kurulan bir rotanın, ara bir düğümün kendi konumunu hesaplamasına ve oradan kimin ödendiğini tahmin etmesine olanak tanıdığı konusunda uyarır; bu yüzden ödeyene, alıcıdan dışa doğru grafiği yürüyerek ve karşılaştığı deltaları toplayarak bulunan rastgele bir sapma eklemesi önerilir. Şartname bu sonuca gölge rota uzantısı (shadow route extension) der.
İletimi yapan düğümü siz işletmiyorsanız bunların hiçbirini siz belirlemezsiniz. İncelememizin telefonda gerçek, kendi kendine yeten bir Lightning düğümü olarak adlandırdığı Phoenix, gönderme fiyatını %0,4 artı 4 sat olarak yayımlar ve bu tablo paraya fiyat koyar, bloklara değil.
CLTV son kullanma deltası vs OP_CHECKLOCKTIMEVERIFY
CLTV son kullanma deltası, gossip içinde yayımlanan bir yönlendirme politikası değeridir; OP_CHECKLOCKTIMEVERIFY ise zincir üstünde mutlak bir son tarihi uygulayan Bitcoin script işlem kodudur.
Üç harfi paylaşırlar ve pek az başka şeyi. Delta görecelidir ve tamamen zincir dışında yaşar: hiçbir script içinde görünmez, hiçbir tam düğüm onu doğrulamaz ve onu belirleyen düğüm onu yeni bir channel_update ile değiştirir. OP_CHECKLOCKTIMEVERIFY ise paraya yazılır, her tam düğüm tarafından kontrol edilir ve para var olduktan sonra değiştirilemez.