Lightning Network para açısından risk altında mı? Bu makale prensiplerini ve tedavi yöntemlerini açıklamaktadır

Orijinal | Odaily Gezegen Günlük

Yazar | Nan Feng

! [Lightning Network fonlar için risk altında mı?] Prensibini ve tedavi yöntemini açıklar] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-43da3a01e5-dd1a6f-69ad2a.webp)

Giriş

20 Ekim'de Bitcoin Core çekirdek geliştiricisi /dev/fd0, X platformunda, protokol düzeyinde güvenlik sorunlarının ele alınmasını koordine etmek de dahil olmak üzere Lightning Network'ün geliştirilmesine ve uygulanmasına katılmayı bırakacağını duyurdu.

/dev/fd0, her Bitcoin düğümünün kendi bellek havuzuna sahip olduğu anlamına gelir. İşlemler eşler tarafından iletilir. Lightning Network düğümleri, kanalları açmak ve HTLC yönlendirmesini kabul etmek için kullanılıyorsa, Yedek Döngü Saldırılarına karşı savunmasızdırlar.

Geliştiricinin "alternatif döngü saldırısı" olarak adlandırdığı şey ve bunun nasıl uygulanabileceği bu makalede açıklanacaktır.

Yıldırım Ağı

Bitcoin ağının yalnızca yaklaşık 7'lik bir TPS'si ve yüksek ücretleri vardır ve Lightning Network, mikro ödemelerin ihtiyaçlarını çözmek için oluşturulmuştur.

Lightning Network, kripto para ağlarının ölçeklenebilirliğini ve işlem hızını ele almak için tasarlanmış Bitcoin ve diğer kripto para birimleri için bir katman-2 ölçeklendirme çözümüdür.

Uygulama prensibi şu şekilde basitleştirilebilir:

1. İşlem tarafları A ve B bir "işlem kanalı" (aslında bir multisig cüzdan) oluşturur
2. A ve B, sırasıyla A1 ve B1'i tamamlar (bu adım zincir üzerindedir)
3. A ve B'nin zincir dışı herhangi bir işlemi vardır ve A'nın net X transferi vardır (örneğin, A 1 yuan'ı B'ye 100 kez transfer eder, B 1 yuan'a 99 kez A'ya 1 yuan transfer eder ve son olarak A'nın 1 yuan'lık net çıkışı vardır)
4. Zincirdeki A1-X ve B1+X işlemlerini güncelleyin

Yukarıdaki süreç boyunca, A ve B zincir dışı ne kadar işlem yaparsa yapsın, yalnızca iki zincir üstü ücret ödemeleri ve çok zaman kazanmaları gerekir.

Hash Zaman Kilidi Sözleşmesi (HTLC)

Yukarıda açıklanan form, A ve B arasındaki doğrudan bir işlem kanalıyla sınırlıdır ve kanallar arası ödemeler için röle düğümleri görünür, kanallar arasında ödeme yapmak için röle düğümleri ikisi arasında geçiş işlemleri yapar ve röle düğümleri bahşiş toplayabilir.

Ancak bu bir sorunla karşı karşıyadır: **Her kanaldaki her katılımcının dürüst ve güvenilir olduğundan ** ve çok kanallı bağlantılar aracılığıyla güvenli olduğundan emin olunması gerekir.

Bu nedenle, HTLC'nin (Hash Zaman Kilitleme Sözleşmesi) ortaya çıkması, HTLC ile bir ödeme işlemi şu şekilde basitleştirilebilir:

1. A gizli bir R hazırlar ve hash değeri H'yi hesaplar
2. A, T zaman sınırı belirler
3. A, HTLC ile B'ye bir ödeme işlemi gönderir ve işlem yalnızca aşağıdaki iki koşul yerine getirildiğinde sonuçlandırılır

• B, R kodunu yanıtlar (H tarafından doğrulanır)
• B cevapları T içinde (örneğin, 10 blok içinde cevap)

5. B kodu bilmiyorsa veya cevap zaman aşımına uğramışsa, fonlar A'ya iade edilir

Normal işlem süreci

Yukarıda açıklanan HTLC ile, bir röle düğümünü içeren bir ödeme aşağıdaki gibidir:

1. Nihai alıcı C, kodu gönderen A'ya verir
2. A, HTLC ödemesini hash H ile başlatır (Fonların şu anda B'nin elinde olmadığını unutmayın)
3. B, ödeme bilgilerini alır ve hash değeri H ile C'ye bir HTLC ödemesi başlatır
4. C Para almak için kodu yanıtlayın, para alın. B de şu anda kodu biliyor
5. B, A tarafından başlatılan ödemeyi almak için kodu kullanır, parayı alır ve işlem tamamlanır

! [Lightning Network fonlar için risk altında mı?] Prensiplerini ve tedavi yöntemlerini açıklayan bir makale] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-db7ebe3106-dd1a6f-69ad2a.webp)

Üçünü içeren süreç yukarıdaki gibidir ve ödeme modu değişmeden kalırken, ödemeyi zincir aracılığıyla son alıcıya gönderirken ve ardından işlemi tamamlamak için kodu ilk röle düğümüne geri yayarken, ortasına birkaç röle düğümü daha eklenebilir.

Röle düğümü R ** kodunu almazsa (bir sonraki ev cevap vermezse, zaman sınırı röle düğümünün kendisi tarafından değerlendirilir)**, röle düğümü kanalı kapatmayı seçebilir, ** zincir başarılı olursa, ** B tarafından başlatılan ödeme "geçersiz" olur ve fon kaybı olmaz. **

Döngüsel alternatif saldırılar

HTLC'nin temel ilkesine dönersek, kodu yanıtlamanın yanı sıra, röle düğümünün "röle düğümü T içinde yanıt veriyor" başka bir koşulu karşılaması gerekir ve kötü niyetli saldırgan saldırmak için bu noktayı hedefler:

1. A ve C kötü niyetli bir şekilde çarpıştırılır ve kurban B röle düğümüdür (B, 3 blok içinde cevap vermesini ister)
2. A, B'ye bir ödeme başlatır (şu anda blok yüksekliğinin 1000 olduğunu varsayarsak) ve blok 1020'den önce bir cevap ister
3. B, C'ye bir ödeme başlatır (blok yüksekliği 1005)
4. Blok yüksekliği 1008 olduğunda B, C'nin cevap vermediğini görür ve 1009. blokta yürürlüğe girecek olan kanalı kapatmaya karar verir.
5. C, yüksek gaz (1) (blok 1008) ile bir işlem başlatır ve B tarafından başlatılan bir işlemin mempool'a girmesini imkansız hale getirir
6. C, yüksek gaz (2) (blok 1009) ile bir işlem başlatır ve B yine de mempool'a giremez
7. C, blok 1020'ye kadar sonsuz bir döngüde çalışır, R gizli işaretini verir ve para çeker

B'nin A tarafından başlatılan ödemeye cevap verecek zamanı yoktur, fonlar A'ya iade edilir ve C'ye ödeme yapılır ve son olarak "döngüsel ikame saldırısı" uygulanır. Buna ek olarak, A ve C, B'nin kapanış işlemine döngü saldırısı yapmak için gizli anlaşma yaparak çifte harcama elde edebilir.

Sonuç

Yukarıdaki saldırı vektörleri mevcut olsa da, bu, saldırganların Lightning Network'te istediklerini yapabilecekleri ve fon çalabilecekleri anlamına gelmez ve yazar ayrıca bununla başa çıkmak için yerel bellek havuzu ve işlem aktarma trafiği izleme, madenci bellek havuzu izleme vb. gibi beş yol önermektedir.

Gelecek parlak, yol dolambaçlı ve bu yıl Bitcoin ağında Ordinals, BRC-20, Taproot Asset ve benzeri bir dizi yeni şey doğdu.

Referanslar