Antoine Riard'ın Lightning Network Önerisi Kanal Karıştırma Saldırılarını Azaltabilir mi?

Bu, Bitcoin alanında kendi kendini yetiştirmiş bir eğitimci ve teknoloji odaklı Bitcoin podcast sunucusu olan Shinobi'nin bir fikir editörüdür.

Kanal sıkışması, Lightning Network ile ilgili en tehditkar sorunlardan biridir. Ağdaki hizmet reddi saldırı düğümlerine yönlendirme yapmalarını, likiditeleri kilitliyken para kaybetmelerini ve kendilerine ücret kazandıracak ödemeleri iletememelerini önlemek için açık bir mekanizma sunar. Saldırgan, ödemeyi diğer düğümler aracılığıyla kendilerinden kendilerine yönlendirebilir ve ödemeyi tamamlamayı reddedebilir. Bu, likiditeyi, karma zaman kilidi sözleşmesi (HTLC) zaman kilidinin süresi dolana ve ödeme geri ödenene kadar diğer ödemeleri iletmek için kullanışsız hale getirir.

Geçen ay, Lightning geliştiricisi Antoine Riard bu soruna bir çözüm için resmi bir şartname önerdi. Ağustos ayında, Riard ve Gleb Naumenko yayınladı araştırma genel sorunun kendisine ve onu hafifletmek veya çözmek için kullanılabilecek bir dizi farklı çözüme bakmak. Önerilen çözümlerden biri, düğümlerin, bu itibarı insanların mahremiyetini olumsuz yönde etkileyecek statik bir tanımlayıcıyla doğrulamak veya ilişkilendirmek zorunda kalmadan ödemeleri onlar aracılığıyla yönlendiren kullanıcılar için bir tür itibar puanlama sistemi oluşturmak için kullanabilecekleri bir tür anonimleştirilmiş kimlik bilgileriydi. Bu çözüm artık resmi protokol önerisi Riard tarafından geçen ay yapıldı.

Kanal İçinde Karışmayı Azaltma Önerisi

Fikrin özü, bir Chaumian ecash jetonudur. Bunlar, bir jetonun verilmesinin daha sonra bir jetonun itfa edilmesiyle ilişkilendirilmesini önleyecek şekilde bir darphane otoritesi tarafından verilen merkezi jetonlardır. Bu, bir belirteci kör bir şekilde imzalayarak yapılır ve belirtecin alıcısının imzayı geçersiz kılmadan onun körlüğünü kaldırmasına izin verir. Yayıncı daha sonra, bu belirteci verildiği zamana bağlayamadan meşru bir belirteç olduğunu doğrulayabilir.

Teklif, ağdaki her yönlendirme düğümü tarafından verilen bu Chaumian belirteçlerinin bir itibar kanıtı biçimi olarak kullanılmasını önerir. Bir ödemeyi yönlendirirken, ödeme atlama noktasındaki her düğüm tarafından verilen bir Chaumian ecash belirteci, ödeme boyunca o düğüm için soğan paketine sarılır. Belirteç birimleri, hem izin verilen HTLC'nin değerini hem de geri ödeme zaman kilidi süresini temsil eder. HTLC'yi iletmeden önce, her bir düğüm, soğan bloblarına dahil edilen belirtecin geçerli olduğunu ve daha önce hiç kullanılmadığını doğrular, yalnızca bu koşulların her ikisi de doğruysa HTLC'yi iletir.

HTLC, ön görüntünün ortaya çıkmasıyla başarılı bir şekilde yerleşirse, ödeme yolu üzerindeki her düğüm, HTLC ön görüntüsüyle birlikte gönderene geri gönderilmek üzere yeni verilmiş bir Chaumian jetonunu imzalar ve içerir. HTLC başarılı bir şekilde yerleşmezse, yönlendirme düğümleri belirteci harcanan belirteç tablosuna dahil ederek "yakar" ve yeni bir belirteç vermez. Bu, göndereni, ödemeleri yeniden yönlendirmek için bu düğümlerden yeni belirteçler almaya zorlar. Tüm kavram, karıştırma saldırılarının her zaman başarısız olmasıdır, bu nedenle, bu şemada, yönlendirdiğiniz her düğüm tarafından verilen bu belirteçler, bir karıştırma saldırısı gerçekleştirirseniz ve bunu tekrar yapmak için daha fazla edinme maliyeti yaratırsanız yakılır. Şu anda, parazit saldırıları zamandan başka bir şeye mal olmuyor, dolayısıyla bu onlara ekonomik bir maliyet katıyor.

O halde, odadaki fili tartışmanın zamanı geldi: Bu belirteçlerin ağ genelinde yayınlanmasını ve dolaşımını nasıl önyüklersiniz? Yönlendirmek istediğiniz her düğüm, kendileri tarafından verilen bir belirteç gerektirir. Çözüm: onlar için ödeme yapın. Kanal sıkışması sorununa önerilen başka bir çözüm, peşin ücretler, yani başarılı olsun ya da olmasın, bir ödemeyi yönlendirmeye çalışmak için bile bir ücret alınmasıdır. Bu nedenle, başarısız ödemeler bile gönderen için bir ücrete tabi olacaktır.

Riard'ın önerisi, bu belirteçleri doğrudan her düğümden tek seferlik satın almalar olarak satın almaktır. Bu noktadan itibaren, her ödeme için peşin ücret ödemek yerine, önceki ödeme başarılı bir şekilde kapatıldığı sürece, önerilen bir sonraki ödemenizin ücretsiz olarak yönlendirilmesini sağlayacak "yönlendirme belirteçleri" size yeniden verilecektir. Bu şekilde, başarılı ödemeler yalnızca gerçek yönlendirme ücretini öder ve başarısız ödemeler yalnızca peşin ücreti ödeyerek başarılı ödemeler için bir tür "çifte ücret" oluşmasını önler. En azından ekonomik olarak, bunu, başarısız ödemelerin hiçbir maliyeti olmadığı ve yalnızca başarılı ödemelerin bir ücret ödediği mevcut durum ile tüm ödemelerin peşin bir ücret ödediği tam peşin ücret modeli arasında bir tür orta yol olarak düşünün. başarılı olanlar da bir yönlendirme ücreti öderler.

Tekliften Çıkarımlar

Şahsen, belirteçler için önceden yapılan bu tür doğrudan ödemelerin, Lightning Network'ü kullanma sürecinde büyük ölçüde UX sürtüşmesine neden olabileceğini düşünüyorum. Ancak, teklifi biraz değiştirerek bu sürtüşme için oldukça basit bir çözüm olduğunu düşünüyorum.

Her bir düğüme özel olarak Chaumian belirteçleri için önceden doğrudan ödeme yapmak zorunda kalmak yerine, teklif ön ücret teklifiyle daha doğrudan hibritleştirilebilir. Bir düğüm için belirteçleriniz varsa, bunları soğan damlasına dahil edin, doğrudan HTLC teklifinde doğrudan bir ön ücret ödemezseniz ve ödeme başarılı bir şekilde yapılırsa, size ne kadar orantılı olarak Chaumian belirteçleri verilecektir. -ön ücret oldu. Bu şekilde, önceden birçok farklı düğümden jeton toplamak zorunda kalmak yerine, sık kullandığınız ve çok nadiren maliyete katlanmak zorunda kaldığınız farklı düğümlerden iyi bir koleksiyon elde edene kadar ilk ödemeleri yapma sürecinde bunları edinirsiniz. bunları elde etmek için peşin ücretler.

Bir başka potansiyel sürtüşme kaynağı, düğüm operatörleri içindir ve Chaumian ekaşın kendisinin temel sorunlarına iner. Bir jetonun yalnızca bir kez harcandığından emin olmak için, ihraççının harcanan tüm jetonların bir veritabanını tutması gerekir. Bu sonsuza kadar büyür, belirteç geçerliliğini kontrol etmek için yapılan aramalar veritabanı büyüdükçe giderek daha pahalı ve zaman alıcı hale gelir. Bu nedenle Riard, bu Chaumian belirteçlerinin, düğüm başına dedikodu protokolünde ilan edilen bir blok yüksekliğinde periyodik olarak sona ermesini önerir. Bu, göndericilerin bu belirteçleri periyodik olarak yeniden satın almaları gerektiği veya uygulama bunu destekleyecekse, öncekinin süresi dolduktan sonra yeni imzalama anahtarı tarafından imzalanan yeni belirteçler için kullanmaları gerektiği anlamına gelir.

Bu, ya ödeme gönderenlere düzenli bir ekonomik maliyet getirir ya da eski belirteçlerin süresi dolduğunda yeniden düzenlemeyi sağlamak için periyodik olarak kontrol etmelerini gerektirir. Uygulamada, bu, kendi Lightning düğümlerini çalıştıran kişiler için otomatikleştirilebilir ve bir Lightning servis sağlayıcısı (LSP) modeli etrafında oluşturulan herhangi bir cüzdan için, LSP'nin kendisi, kullanıcıları adına tokenlerin alınmasını ve bakımını gerçekleştirebilir. kullanıcılarının ödemeleri için belirteç provizyonu. Bununla birlikte, uç noktalarda, tam bir Lightning düğümü veya LSP olmadan, bu, hafif cüzdan kullanıcıları için biraz can sıkıcı olabilir.

Bence bu teklif, özellikle temel ön ödeme planıyla biraz daha sıkı bir şekilde hibritleştirilirse ve kullanıcı deneyimi sürtüşmelerinin çoğu LSP kullanıcıları için çok kolay bir şekilde halledilebilirse, bir saldırı vektörü olarak kanal sıkışmasını azaltmada uzun bir yol kat edebilir. kendi Lightning düğümlerini işleten insanlar. Ve peşin ücretler yüksek derecede sürtüşme arz etse bile, sadece bir Bitcoin UTXO'nun kontrolünü kanıtlamak belirteçleri elde etmek için fiilen ücret ödemek yerine kullanılabilir.

Bu Shinobi'nin konuk yazısıdır. İfade edilen görüşler tamamen kendilerine aittir ve BTC Inc veya Bitcoin Magazine'in görüşlerini yansıtmayabilir.