Yazar: Viktor Bunin, Coinbase Bulut Protokolü Uzmanı Derleyici: Qianwen, ChainCatcher
Bir süredir Lightning'i (daha sonra "Yıldırım Ağı" olarak anılacaktır) kullanmadım.
Üzerinde çalışmaya en son 2019'da Elizabeth Stark ve diğer topluluk liderleriyle birlikte Berlin'de ilk Lightning Network Konferansını organize etmek için bir araya geldiğimde zaman harcadım. O zamandan beri, zamanımın çoğunu başka protokoller üzerinde çalışarak geçirdim ve Elizabeth gibi insanlarla hâlâ arkadaş olsam da Lightning Network'ün gerçekte nasıl çalıştığına dair anlayışım azaldı. Tekrar inceledikten sonra, sadece ben değil, çoğu arkadaşımın da olduğunu fark ettim.
Bu gönderi, Lightning Network'ü son zamanlarda kullanmamış olanlar içindir. Benim veya gördüğüm başkalarının yanlış anlamalarını tartışacak. Herhangi bir iyi noktayı kaçırdıysam, lütfen bana Twitter'da bir satır bırakın.
**Yanlış 1: Lightning Network'ü gözetimsiz olarak kullanmak için kendi düğümünüzü çalıştırmalısınız, bu da sıradan kullanıcıların mobil cihazları kullanmasını engeller. **
Bu birkaç yıl önce doğruydu, ancak artık kullanıcılar, yönetilmeyen hafif istemciler aracılığıyla Lightning Network'ü mobil cihazlarda kullanabilirler. Anahtarlarının kontrolü her zaman kullanıcılardadır ve Lightning Light Client ile cüzdan deneyimi, Ethereum kullanırken RPC aracılığıyla Alchemy veya Infura'yı aramakla aynıdır.
**2. Yanılgı: Lightning ödemelerinin başarılı olabilmesi için gönderen ve alıcının aynı anda çevrimiçi olması gerekir (çevrimdışı/eşzamanlı ödeme yapılmaz). **
Bu durum hala var, ancak bazı düzgün geçici çözümlerle. Gözetimsiz Lightning mobil cüzdanları, cüzdan ön planda çalışmıyorken bile arka plan görevleri veya telefon bildirimleri yoluyla ödeme alabilir. Ancak, bu yaklaşım mobil işletim sistemleri ile sınırlıdır. Modern işletim sistemleri, pilden tasarruf etmek için arka plan uygulamaları tarafından yapılan hesaplama miktarını sınırlar. Birkaç LN ödemesi almak iyidir, ancak kısa bir süre içinde çok fazla LN ödemesi alınırsa, hesaplama kısıtlamaları nedeniyle bunların süresi dolmaya başlar.
Uzun vadede, Lightning Network protokolü geliştiricileri, isteğe bağlı olarak uzun güven gerektirmeyen gecikmelere olanak sağlayacak Async Payments özelliği üzerinde çalışıyor. Temel olarak, ödeme göndericinin düğümünden alınır, ancak alıcının düğümü çevrimdışı olursa, alıcı tekrar çevrimiçi olana kadar ödeme gönderenin LSP'sinde (Lightning Network/Liquidity Service Provider, genellikle cüzdanın kendisi tarafından yürütülür) kalır. ** Bu yükseltmenin gelecek yıl gerçekleşmesi bekleniyor, ancak henüz resmi bir lansman tarihi yok. **Ancak bu, katılımcı cüzdanların ağ çapında bir çözüm olarak benimsenmesini engelleyebilecek LSP'yi içermesini gerektirir.
**Yanlış anlama 3: Lightning Network, kanalı açmak için her iki kullanıcının da kanala aynı miktarda BTC yatırmasını gerektirir. **
Bu doğru değil. Çoğu Lightning Network istemcisinde, kanal varsayılan olarak tek yönlü açıktır, bu nedenle yalnızca gönderenin kanala para yatırması gerekir ve alacaklı yepyeni bir boş adres olabilir. Bu yanlış anlama, örneklerin sürekli olarak iki yönlü finansman kanallarına atıfta bulunduğu Lightning Network tanıtım belgesinden kaynaklanmaktadır.
Aslında ilginç bir geçmişe dayanıyor. En eski ödeme kanalı (Spilman) yalnızca tek yönlü ödemelere izin veriyordu. Lightning Network'ün yeniliği, çift fon ve iki yönlü ödemenin gerçekleştirilmesinde yatmaktadır ve kanalın sona erme süresi yoktur. Lightning Network makalesinin buna bu kadar çok odaklanmasının nedeni belki de budur. Bu, o sırada bilinen protokol tasarımlarına göre önemli bir buluştu.
**4. Efsane: Lightning Network, kullanıcıların korkunç bir kullanıcı deneyimi olan belirli, tek amaçlı faturalar belirtmesini gerektirir. **
Bu aslında başlangıçta doğruydu. Ama şimdi Lightning Network adresiyle, temelde Lightning Network'ün ENS'si. Kullanıcıların, miktar ve süreden bağımsız olarak Lightning Network aracılığıyla viktor@example.com adresine BTC göndermelerine olanak tanıyan lnurl-pay tarafından etkinleştirilirler.
**Yanlış Anlama 5: Kullanıcıların BTC gönderirken Bitcoin ve Lightning Network'ü anlamaları ve seçmeleri gerekir. **
Daha önce de öyle olmalıydı. Ama şimdi farklı. Artık, gönderen cüzdanın doğru yolu seçebilmesi için zincir üstü adresi Lightning Network faturasıyla düzgün bir şekilde bir araya getiren birleşik bir QR koduna sahipler. CashApp'ı açın, Bitcoin sekmesine gidin. Cash App Lightning Network'ü desteklerken Lightning Network'ü seçme seçeneği olmadığını unutmayın. Bunun nedeni, birleşik QR kodunu kullanıyor olmalarıdır.
Ancak bu, tek bir bakiye sorununu çözmez - bir kullanıcının BTC bakiyesi yine de zincir üzerinde ve Lightning Network'e bölünebilir. Bu sorun, Submarineswap ve/veya Splicing yoluyla bir dereceye kadar çözülebilir, ancak benim uzun vadeli görüşüm, kullanıcıların bunun bir sorun olduğunun farkına bile varmayacakları ve cüzdan ve diğer satıcılar ele aldığı için Lightning Network'ün var olduğunun farkına varmayacaklarıdır. pürüzsüz bir kullanıcı deneyiminin altında gizlenecek temel karmaşıklıklar.
**Mit #6: Lightning Network sermaye açısından verimsizdir ve bu nedenle uygulanabilir değildir. **
Bu tartışma hassas bir tartışma ve mümkün olduğunca tarafsız olmaya çalışacağım.
Lightning Network, merkez ve bileşen modeli kullanır. Ağın merkezden merkeze kısmı, borsalar, saklama cüzdanları, LSP'ler ve optimal yönlendirme düğümleri arasındaki büyük kanalların yüksek "birim başına sermaye tahsisi" oranı nedeniyle sermaye açısından oldukça verimlidir.
Bununla birlikte, Lightning ağının sermaye verimsizliği uç noktalarda olduğunda - gözetim altında olmayan kullanıcılar. Koruma altındaki Lightning kullanıcıları için, cüzdanların yalnızca diğer merkezlerle büyük kanalları sürdürmesi ve kullanıcı bakiyelerinin dahili muhasebesini gerçekleştirmesi gerekir. Gözaltında olmayan kullanıcılar için, cüzdanın her kullanıcı için ayrı bir açık fonlama kanalı bulundurması gerekir. Zorluk, bu kanallar arasında sürekli likidite tahsisi ve yönetiminin nasıl sürdürüleceğidir.
Somut bir örnek vermek gerekirse: Saklama yetkisi olmayan bir cüzdan kullanıcısı, Lightning Network üzerinden bir arkadaşına 0.1 BTC göndermek istiyor. Cüzdan sağlayıcı ve yol boyunca her düğüm arasındaki kanalda yeterli likidite olduğunu varsayarsak, ödeme başarılı olacaktır. Ancak şimdi cüzdanın bir sorunu var - yanlarındaki kanalda 0,1 BTC var, eğer kullanıcı herhangi bir ödeme almazsa (böylece kanalı yeniden dengeler), bu 0,1 BTC orada boşta kalacak ve cüzdan sağlayıcının verimsizliğinin düşük olmasına neden olacak. Bu noktada, cüzdan sağlayıcıları, likiditeyi korumaya veya kanalları kapatarak (ki bu kötü bir kullanıcı deneyimi yaratır) veya kanalları birleştirerek (kullanıcılar tarafından görülemeyen) likiditeyi çekip çekmemeye karar vermelidir.
Gözaltında olmayan kullanıcılar için, bu marjinal sermaye verimsizliği sorunu, işlemin boyutu ne olursa olsun, hesap tabanlı modelden nesnel olarak daha kötü olan çok can sıkıcı bir optimizasyon sorunudur. Ancak bu çözülemeyecek bir sorun değildir. İmkansız olmadığı sürece başarılı olmalı ki bu Bitcoin geliştirici topluluğunun da sloganı.
Sermaye optimizasyonunun zorluğuna ek olarak, kanal ve likidite yönetimi ile ilgili maliyetlerden kaynaklanan başka bir zorluk da vardır, çünkü her birleştirme, kanal kapatma vb. bir zincir üstü işlem gerektirir. Bitcoin'in güvenlik bütçesi, işlem ücretlerinde büyük bir artışa dayanıyor, ancak işlem ücretleri 30-60 ABD Doları'na yükselirse, kanal yönetimi, ölçekte engelleyici bir şekilde maliyetli olacak ve gözetimsiz Lightning Network, dünya nüfusunun büyük bir kısmı tarafından kullanılamayabilir. Barındırılan Lightning cüzdanları şu anda yerleşik teşvikler nedeniyle bir avantaja sahip ve çok amaçlı hesap modelleri kanal yönetimini çok daha seyrek hale getirdiği için zincir içi ücretler arttıkça muhtemelen daha da artacak. Topluluk bunu düzeltmek ve gözetim dışı Lightning cüzdanlarının ağda birinci sınıf vatandaş olmaya devam etmesini sağlamak için çok çalışıyor ancak henüz net bir çözüm yok.
Lightning Network'ün basit, sorunsuz ve tamamen soyut olması için kat etmesi gereken daha çok yol var. Hâlâ birçok son durum var ve yönetilmeyen kullanıcılar henüz nihai kullanıcı deneyiminden yararlanmadı. Bununla birlikte, birçok sorun zaten çözüldü ve önümüzdeki birkaç yıl içinde çok daha fazlası çözülecek. Şimdi şimşek çaktığına göre, gök gürültüsü çok geride kalmış olabilir mi?
View Original
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.
Bitcoin'in Lightning Ağı Hakkındaki 6 Yanılgıyı Açıklığa kavuşturmak
Yazar: Viktor Bunin, Coinbase Bulut Protokolü Uzmanı Derleyici: Qianwen, ChainCatcher
Bir süredir Lightning'i (daha sonra "Yıldırım Ağı" olarak anılacaktır) kullanmadım.
Üzerinde çalışmaya en son 2019'da Elizabeth Stark ve diğer topluluk liderleriyle birlikte Berlin'de ilk Lightning Network Konferansını organize etmek için bir araya geldiğimde zaman harcadım. O zamandan beri, zamanımın çoğunu başka protokoller üzerinde çalışarak geçirdim ve Elizabeth gibi insanlarla hâlâ arkadaş olsam da Lightning Network'ün gerçekte nasıl çalıştığına dair anlayışım azaldı. Tekrar inceledikten sonra, sadece ben değil, çoğu arkadaşımın da olduğunu fark ettim.
Bu gönderi, Lightning Network'ü son zamanlarda kullanmamış olanlar içindir. Benim veya gördüğüm başkalarının yanlış anlamalarını tartışacak. Herhangi bir iyi noktayı kaçırdıysam, lütfen bana Twitter'da bir satır bırakın.
**Yanlış 1: Lightning Network'ü gözetimsiz olarak kullanmak için kendi düğümünüzü çalıştırmalısınız, bu da sıradan kullanıcıların mobil cihazları kullanmasını engeller. **
Bu birkaç yıl önce doğruydu, ancak artık kullanıcılar, yönetilmeyen hafif istemciler aracılığıyla Lightning Network'ü mobil cihazlarda kullanabilirler. Anahtarlarının kontrolü her zaman kullanıcılardadır ve Lightning Light Client ile cüzdan deneyimi, Ethereum kullanırken RPC aracılığıyla Alchemy veya Infura'yı aramakla aynıdır.
**2. Yanılgı: Lightning ödemelerinin başarılı olabilmesi için gönderen ve alıcının aynı anda çevrimiçi olması gerekir (çevrimdışı/eşzamanlı ödeme yapılmaz). **
Bu durum hala var, ancak bazı düzgün geçici çözümlerle. Gözetimsiz Lightning mobil cüzdanları, cüzdan ön planda çalışmıyorken bile arka plan görevleri veya telefon bildirimleri yoluyla ödeme alabilir. Ancak, bu yaklaşım mobil işletim sistemleri ile sınırlıdır. Modern işletim sistemleri, pilden tasarruf etmek için arka plan uygulamaları tarafından yapılan hesaplama miktarını sınırlar. Birkaç LN ödemesi almak iyidir, ancak kısa bir süre içinde çok fazla LN ödemesi alınırsa, hesaplama kısıtlamaları nedeniyle bunların süresi dolmaya başlar.
Uzun vadede, Lightning Network protokolü geliştiricileri, isteğe bağlı olarak uzun güven gerektirmeyen gecikmelere olanak sağlayacak Async Payments özelliği üzerinde çalışıyor. Temel olarak, ödeme göndericinin düğümünden alınır, ancak alıcının düğümü çevrimdışı olursa, alıcı tekrar çevrimiçi olana kadar ödeme gönderenin LSP'sinde (Lightning Network/Liquidity Service Provider, genellikle cüzdanın kendisi tarafından yürütülür) kalır. ** Bu yükseltmenin gelecek yıl gerçekleşmesi bekleniyor, ancak henüz resmi bir lansman tarihi yok. **Ancak bu, katılımcı cüzdanların ağ çapında bir çözüm olarak benimsenmesini engelleyebilecek LSP'yi içermesini gerektirir.
**Yanlış anlama 3: Lightning Network, kanalı açmak için her iki kullanıcının da kanala aynı miktarda BTC yatırmasını gerektirir. **
Bu doğru değil. Çoğu Lightning Network istemcisinde, kanal varsayılan olarak tek yönlü açıktır, bu nedenle yalnızca gönderenin kanala para yatırması gerekir ve alacaklı yepyeni bir boş adres olabilir. Bu yanlış anlama, örneklerin sürekli olarak iki yönlü finansman kanallarına atıfta bulunduğu Lightning Network tanıtım belgesinden kaynaklanmaktadır.
Aslında ilginç bir geçmişe dayanıyor. En eski ödeme kanalı (Spilman) yalnızca tek yönlü ödemelere izin veriyordu. Lightning Network'ün yeniliği, çift fon ve iki yönlü ödemenin gerçekleştirilmesinde yatmaktadır ve kanalın sona erme süresi yoktur. Lightning Network makalesinin buna bu kadar çok odaklanmasının nedeni belki de budur. Bu, o sırada bilinen protokol tasarımlarına göre önemli bir buluştu.
**4. Efsane: Lightning Network, kullanıcıların korkunç bir kullanıcı deneyimi olan belirli, tek amaçlı faturalar belirtmesini gerektirir. **
Bu aslında başlangıçta doğruydu. Ama şimdi Lightning Network adresiyle, temelde Lightning Network'ün ENS'si. Kullanıcıların, miktar ve süreden bağımsız olarak Lightning Network aracılığıyla viktor@example.com adresine BTC göndermelerine olanak tanıyan lnurl-pay tarafından etkinleştirilirler.
**Yanlış Anlama 5: Kullanıcıların BTC gönderirken Bitcoin ve Lightning Network'ü anlamaları ve seçmeleri gerekir. **
Daha önce de öyle olmalıydı. Ama şimdi farklı. Artık, gönderen cüzdanın doğru yolu seçebilmesi için zincir üstü adresi Lightning Network faturasıyla düzgün bir şekilde bir araya getiren birleşik bir QR koduna sahipler. CashApp'ı açın, Bitcoin sekmesine gidin. Cash App Lightning Network'ü desteklerken Lightning Network'ü seçme seçeneği olmadığını unutmayın. Bunun nedeni, birleşik QR kodunu kullanıyor olmalarıdır.
Ancak bu, tek bir bakiye sorununu çözmez - bir kullanıcının BTC bakiyesi yine de zincir üzerinde ve Lightning Network'e bölünebilir. Bu sorun, Submarineswap ve/veya Splicing yoluyla bir dereceye kadar çözülebilir, ancak benim uzun vadeli görüşüm, kullanıcıların bunun bir sorun olduğunun farkına bile varmayacakları ve cüzdan ve diğer satıcılar ele aldığı için Lightning Network'ün var olduğunun farkına varmayacaklarıdır. pürüzsüz bir kullanıcı deneyiminin altında gizlenecek temel karmaşıklıklar.
**Mit #6: Lightning Network sermaye açısından verimsizdir ve bu nedenle uygulanabilir değildir. **
Bu tartışma hassas bir tartışma ve mümkün olduğunca tarafsız olmaya çalışacağım.
Lightning Network, merkez ve bileşen modeli kullanır. Ağın merkezden merkeze kısmı, borsalar, saklama cüzdanları, LSP'ler ve optimal yönlendirme düğümleri arasındaki büyük kanalların yüksek "birim başına sermaye tahsisi" oranı nedeniyle sermaye açısından oldukça verimlidir.
Bununla birlikte, Lightning ağının sermaye verimsizliği uç noktalarda olduğunda - gözetim altında olmayan kullanıcılar. Koruma altındaki Lightning kullanıcıları için, cüzdanların yalnızca diğer merkezlerle büyük kanalları sürdürmesi ve kullanıcı bakiyelerinin dahili muhasebesini gerçekleştirmesi gerekir. Gözaltında olmayan kullanıcılar için, cüzdanın her kullanıcı için ayrı bir açık fonlama kanalı bulundurması gerekir. Zorluk, bu kanallar arasında sürekli likidite tahsisi ve yönetiminin nasıl sürdürüleceğidir.
Somut bir örnek vermek gerekirse: Saklama yetkisi olmayan bir cüzdan kullanıcısı, Lightning Network üzerinden bir arkadaşına 0.1 BTC göndermek istiyor. Cüzdan sağlayıcı ve yol boyunca her düğüm arasındaki kanalda yeterli likidite olduğunu varsayarsak, ödeme başarılı olacaktır. Ancak şimdi cüzdanın bir sorunu var - yanlarındaki kanalda 0,1 BTC var, eğer kullanıcı herhangi bir ödeme almazsa (böylece kanalı yeniden dengeler), bu 0,1 BTC orada boşta kalacak ve cüzdan sağlayıcının verimsizliğinin düşük olmasına neden olacak. Bu noktada, cüzdan sağlayıcıları, likiditeyi korumaya veya kanalları kapatarak (ki bu kötü bir kullanıcı deneyimi yaratır) veya kanalları birleştirerek (kullanıcılar tarafından görülemeyen) likiditeyi çekip çekmemeye karar vermelidir.
Gözaltında olmayan kullanıcılar için, bu marjinal sermaye verimsizliği sorunu, işlemin boyutu ne olursa olsun, hesap tabanlı modelden nesnel olarak daha kötü olan çok can sıkıcı bir optimizasyon sorunudur. Ancak bu çözülemeyecek bir sorun değildir. İmkansız olmadığı sürece başarılı olmalı ki bu Bitcoin geliştirici topluluğunun da sloganı.
Sermaye optimizasyonunun zorluğuna ek olarak, kanal ve likidite yönetimi ile ilgili maliyetlerden kaynaklanan başka bir zorluk da vardır, çünkü her birleştirme, kanal kapatma vb. bir zincir üstü işlem gerektirir. Bitcoin'in güvenlik bütçesi, işlem ücretlerinde büyük bir artışa dayanıyor, ancak işlem ücretleri 30-60 ABD Doları'na yükselirse, kanal yönetimi, ölçekte engelleyici bir şekilde maliyetli olacak ve gözetimsiz Lightning Network, dünya nüfusunun büyük bir kısmı tarafından kullanılamayabilir. Barındırılan Lightning cüzdanları şu anda yerleşik teşvikler nedeniyle bir avantaja sahip ve çok amaçlı hesap modelleri kanal yönetimini çok daha seyrek hale getirdiği için zincir içi ücretler arttıkça muhtemelen daha da artacak. Topluluk bunu düzeltmek ve gözetim dışı Lightning cüzdanlarının ağda birinci sınıf vatandaş olmaya devam etmesini sağlamak için çok çalışıyor ancak henüz net bir çözüm yok.
Lightning Network'ün basit, sorunsuz ve tamamen soyut olması için kat etmesi gereken daha çok yol var. Hâlâ birçok son durum var ve yönetilmeyen kullanıcılar henüz nihai kullanıcı deneyiminden yararlanmadı. Bununla birlikte, birçok sorun zaten çözüldü ve önümüzdeki birkaç yıl içinde çok daha fazlası çözülecek. Şimdi şimşek çaktığına göre, gök gürültüsü çok geride kalmış olabilir mi?