Orijinal Başlığı '系统解读Fiber：把闪电网络嫁接到CKB上的宏大实验' İleri

23 Ağustos'ta CKB, CKB tabanlı bir Lightning Network çözümü olan Fiber Network'ü resmi olarak piyasaya sürdü. Bu haber, toplulukta hızla yoğun tartışmalara yol açtı ve CKB'nin fiyatında tek bir gün içinde yaklaşık %30'luk bir artışa yol açtı. Güçlü tepki, Lightning Network'ün ilgi çekici anlatısına ve Fiber'in çok sayıda iyileştirme ile geleneksel Lightning Network'e göre yükseltilmiş bir çözüm sunmasına bağlanabilir. Örneğin Fiber, CKB, BTC ve stablecoin'ler dahil olmak üzere birden fazla varlık türünü yerel olarak destekler ve CKB'nin önemli UX ilerlemeleri sağlayan daha düşük işlem ücretlerinden ve daha hızlı yanıt sürelerinden yararlanır. Ayrıca Fiber, gizlilik ve güvenlik açısından çeşitli optimizasyonlar yaptı. Ayrıca, Fiber ve BTC Lightning Network birbirine bağlanarak daha büyük bir P2P ağı oluşturabilir. CKB yetkilileri, P2P ödeme ağını geliştirmek ve ilerletmek için çevrimdışı etkinlikler sırasında Fiber ve Lightning Network'te 100.000 fiziksel düğüm kurmayı planladıklarını bile belirtti. Bu şüphesiz büyük ve benzeri görülmemiş bir hikayeyi temsil ediyor

Eğer CKB'nin resmi vizyonu gelecekte gerçekleştirilirse, Lightning Network, CKB ve geniş Bitcoin ekosistemi için önemli bir artı olacaktır. Mempool verilerine göre, BTC Lightning Network şu anda yaklaşık 12.000 düğüm ve aralarında neredeyse 50.000 ödeme kanalı bulunan 300 milyondan fazla fon tutuyor.

Spendmybtc.com'da, giderek artan sayıda tüccarın Lightning Network ödemelerini desteklediğini gözlemleyebiliriz. BTC'nin tanınırlığı arttıkça, Lightning Network ve Fiber gibi off-chain ödeme çözümlerinin yükselmesi muhtemeldir. Fiber'ın teknik çözümünü sistemli bir şekilde analiz etmek için "Geek Web3", genel Fiber çözümü üzerine bu araştırma raporunu üretmiştir. CKB'ye dayalı Lightning Network uygulaması olarak, Fiber'ın prensipleri genellikle Bitcoin Lightning Network ile tutarlı olsa da birçok ayrıntıda optimizasyonlar içermektedir. Fiber'ın genel mimarisi dört temel bileşenden oluşmaktadır: ödeme kanalları, WatchTower, çoklu-hop yönlendirme ve çapraz alan ödemeleri. En önemli bileşen olan ödeme kanallarını açıklamakla başlayalım.

The Foundation of the Lightning Network and Fiber: Ödeme Kanalları

Ödeme kanalları esasen işlemleri zincir dışına taşır ve nihai durum bir süre sonra zincir üzerinde yerleşir. İşlemler zincir dışında tamamlandığından, genellikle BTC gibi ana zincirin performans sınırlamalarını atlarlar. Örneğin, Alice ve Bob birlikte bir kanal açarlarsa, önce zincir üzerinde çok imzalı bir hesap oluştururlar ve zincir dışı kanaldaki bakiyeleri olarak her biri 100 birim gibi bir miktar para yatırırlar. Daha sonra kanal içinde birden fazla işlem gerçekleştirebilirler ve kanalı kapattıklarında, her iki tarafa da ödeme yapan çoklu imza hesabıyla zincir üzerindeki son bakiyeleri senkronize ederler - bu "uzlaşma"dır.

Örneğin, her iki taraf da 100 birimle başlarsa ve Alice 50 birimi Bob'a aktarırsa, ardından 10 birimlik başka bir transfer yaparsa ve ardından Bob 30 birimi Alice'e geri aktarırsa, nihai bakiyeleri şöyle olur: Alice — 70 birim, Bob — 130 birim. Abaküs boncukları örneğinde gösterildiği gibi toplam bakiye değişmeden kalır. Taraflardan biri kanaldan çıkarsa, nihai bakiyeler (Alice: 70, Bob: 130) zincir üzerinde senkronize edilir ve çoklu imza hesabının 200 birimi, ödemeyi tamamlamak için bu son bakiyelere göre dağıtılır.

Bu süreç basit görünse de, pratikte karmaşık hususlar içerir. Karşı tarafın kanaldan ne zaman çıkmayı seçeceğini tahmin edemezsiniz. Örneğin, kanal katılımcıların serbestçe çıkmasına izin verdiği için Bob ikinci işlemden sonra veya hatta ilk işlemden sonra çıkabilir. Bunu ele almak için sistem, herhangi birinin herhangi bir zamanda çıkabileceğini ve her iki tarafın da nihai bakiyeyi uzlaşma için zincire gönderebileceğini varsayar. Bu, kanaldaki en son bakiyeleri kaydeden "taahhüt işlemleri" aracılığıyla yönetilir. Her işlem, karşılık gelen bir taahhüt işlemi oluşturur. Kanaldan çıkmak için, çoklu imza hesabından payınızı çekmek için en son taahhüt işlemini zincire gönderirsiniz.

Taahhüt işlemlerinin kanalda her iki tarafın da bakiyelerini on-chain olarak uzlaştırmak için kullanıldığı sonucuna varabiliriz, her iki taraf da kanaldan çıkmak için en son taahhüt işlemini gönderebilir. Ancak, önemli bir kötü niyetli senaryo var: Bob, örneğin, Taahhüt Tx3 üretildikten sonra bakiyesinin 130 birim olduğunu gösterir. Ancak avantajına, Bob, 160 birimlik bir bakiyeyi gösteren eski Taahhüt Tx2'yi gönderebilir. Bu eski bakiye, klasik bir "çift harcama" saldırısını temsil eder.

Bu tür çifte harcama senaryolarını önlemek için uygun ceza önlemleri alınmalıdır. Bu cezai önlemlerin tasarımı, bire bir ödeme kanalı sisteminin merkezinde yer alır ve bunu anlamak, ödeme kanallarının nasıl çalıştığını anlamak için çok önemlidir. Kanal tasarımında, taraflardan biri zincire güncel olmayan bir durum ve taahhüt işlemi gönderirse, fayda sağlamak yerine, diğer tarafın tüm fonları çekebileceğini göreceklerdir. Bu, çok önemli olan "asimetrik taahhüt işlemleri" ve "iptal anahtarları" kavramlarını kullanır. Önce Commit Tx3'ü örnek alarak "asimetrik taahhüt işlemlerini" açıklayalım.

Bu senaryoda, Bob bir taahhüt hareketi oluşturur ve bunu işlemesi için Alice'e gönderir. Gösterildiği gibi, bu işlem, çoklu imza hesabından 70 birimin Alice'e ve 130 birimin Bob'a tahsis edildiğini beyan eden bir Bitcoin transferini içerir. Bununla birlikte, kilit açma koşulları "asimetriktir" ve Alice'e daha sert kısıtlamalar getirir ve Bob'a fayda sağlar.

Bob'tan taahhüt işlemi aldığında, Alice 2/2 çok imza gereksinimini karşılamak için imzasını ekleyebilir. Alice, kanaldan çıkmak için bu taahhüt işlemini zincir üzerinde gönderebilir. Bunun yerine, göndermezse kanal içinde işlem yapmaya devam edebilir.

Bu taahhüt işleminin Bob tarafından oluşturulduğunu ve Alice için elverişsiz koşullara sahip olduğunu unutmamak çok önemlidir. Alice'in bunu kabul etme ya da reddetme seçeneği var, ancak onun bir miktar özerkliğini koruduğundan emin olmalıyız. Ödeme kanallarının tasarımında, taahhüt işlemleri 2/2 çoklu imza gerektirdiğinden, "elverişsiz" taahhüt işlemini zincire yalnızca Alice gönderebilir. Bob işlemi yerel olarak oluşturduktan sonra, yalnızca kendi imzası vardır ve Alice'in imzası yoktur.

Alice, "Bob'un imzasını kabul edebilir ama kendi imzasını saklayabilir." Bu, çift imza gerektiren bir sözleşmeye benzer. Bob önce imzalar ve sözleşmeyi Alice'e gönderirse, imzasını vermemeyi seçebilir. Sözleşmenin geçerli olması için Alice'in imzalaması ve ardından göndermesi gerekir; aksi takdirde, imzalamaktan veya göndermekten kaçınabilir. Dolayısıyla, bu durumda Alice, Bob'un eylemlerini sınırlama araçlarına sahiptir.

İşte anahtar nokta: Kanal içinde her bir işlem gerçekleştiğinde, aynı şekilde iki yansıma versiyonu ile çift bir taahhüt işlemi oluşturulur. Alice ve Bob, kendi lehlerine olan taahhüt işlemleri oluşturabilir ve bu işlemlerde çıkışta alacakları miktarları belirtip, ardından bu işlemleri birbirlerine yönlendirebilirler.

İlginçtir, iki taahhüt işlemi aynı "çıkışta alınacak tutar" beyan ederken, çekilme koşulları farklıdır. Bu, daha önce bahsedilen "asimetrik taahhüt işlemleri" kavramını açıklar.

Daha önce açıklandığı gibi, her taahhüt işlemi için geçerli olması için 2/2 çoklu imza gereklidir. Kendisini tercih eden Bob tarafından oluşturulan taahhüt işlemi, 2/2 çoklu imza gereksinimini karşılamamaktadır, bu gereksinimi karşılayan taahhüt işlemi ise Alice tarafından tutulur ve yalnızca onun tarafından gönderilebilir, böylece bir dengeleme mekanizması oluşturulur. Aynı mantık tersine de uygulanır.

Bu nedenle, Alice ve Bob sadece kendileri için dezavantajlı olan taahhüt işlemlerini gönderebilirler. Herhangi bir taraf taahhüt işlemini zincire gönderirse ve etkili hale gelirse, kanal kapanır.

Daha önce tartışılan 'çift harcama' senaryosuyla ilgili olarak, biri eski bir taahhüt işlemi sunarsa, 'iptal anahtarları' kavramı devreye girer. Örneğin, Bob eski Tx2'yi zincire sunarsa, Alice, Bob'un alması gereken fonları çekmek için Tx2 ile ilişkili iptal anahtarını kullanabilir.

Örnek diyagramda, en son taahhüt işleminin Commit Tx3 olduğunu varsayarsak ve Tx2 eskiyse, Bob eski Tx2'yi gönderirse, Alice, Tx2'nin iptal anahtarını kullanarak Bob'un fonlarını çekmek için zaman kilidi süresi içinde hareket edebilir.

En son Tx3 ile ilgili olarak, Alice gelecekte oluşturulan Tx4'ten sonra iptal anahtarını elde eder. Bu, genel/özel anahtar şifrelemesi ve UTXO özelliklerinin doğasından kaynaklanmaktadır. Kısaca, iptal anahtarlarının uygulama ayrıntıları burada tartışılmamıştır.

Anahtar nokta, Bob'un eski bir taahhüt işlemini zincire göndermeye cesaret ederse, Alice'in iptal anahtarını ceza olarak Bob'un fonlarını çekebileceğidir. Benzer şekilde, eğer Alice kötü niyetli davranırsa, Bob da aynı cezayı ona karşı uygulayabilir. Bu mekanizma, bire bir ödeme kanallarının çift harcama etkili bir şekilde önlemesini sağlar, çünkü rasyonel katılımcılar kötü niyetli eylemlerden kaçınacaklardır.

Bu bağlamda, CKB tabanlı Fiber, Bitcoin Lightning Network üzerinde önemli iyileştirmeler sunar. Doğal olarak, CKB, BTC ve RGB++ stabilcoin dahil olmak üzere çeşitli varlık türlerinin işlemlerini ve transferlerini desteklerken, Lightning Network sadece Bitcoin'i doğal olarak destekler. Hatta Taproot Varlık yükseltmesi ile bile, Bitcoin Lightning Network hala doğal olarak BTC dışı varlıkları destekleyemez ve sadece dolaylı olarak stabilcoin'leri destekleyebilir.

(Görseller kaynak: Dapangdun) Ayrıca, Fiber'ın CKB'ye dayanması nedeniyle, kanalların açılması ve kapanması için olan ücretler BTC Lightning Network'e kıyasla önemli ölçüde daha düşüktür. Bu, kullanıcıların işlem maliyetlerini azaltır ve kullanıcı deneyimi (UX) açısından net bir avantajı temsil eder.

24/7 güvenlik: WatchTower

İptal anahtarlarıyla ilgili bir zorluk, kanal katılımcılarının eski taahhüt işlemlerinin sunulmasını önlemek için sürekli olarak birbirlerini izlemesi gerektiğidir. Ancak, kimse 24/7 çevrimiçi olamaz, bu yüzden bir taraf kötü niyetli davranışta bulunursa diğer taraf çevrimdışıyken ne olur? Fiber ve Bitcoin Lightning Ağı, WatchTowers tasarımıyla bu sorunu ele almaktadır.

WatchTowers, gece gündüz zincirdeki faaliyetleri izlemek için tasarlanmıştır. Birisi eski bir taahhüt işlemi gönderirse, WatchTower kanalı ve fonları korumak için zamanında harekete geçecektir. İşleyişi şöyle:

Ted taahhüt işlemi, Alice veya Bob, önceden karşılık gelen bir ceza işlemi hazırlayabilir (eski taahhüt işlemini yönetmek için iptal anahtarını kullanarak, yararlanıcının kendileri olarak bildirilir). Daha sonra bu ceza işleminin düz metnini Gözetleme Kulesine sağlarlar.

WatchTower, ağa gönderilen eski bir taahhüt işleminin tespit ettiğinde, hazırlanan ceza işlemini de gönderecek ve bu sayede cezayı uygulayacak ve kanalın bütünlüğünü koruyacaktır.

Fiber, kullanıcıların yalnızca "eski taahhüt işleminin karma değeri + ceza işleminin düz metni"ni WatchTower'a göndermelerini gerektirerek katılımcıların gizliliğini korur. Bu sayede, WatchTower başlangıçta yalnızca taahhüt işleminin karma değerini, düz metnini değil, bilecektir. WatchTower, ancak birisi gerçekten eski taahhüt işlemini zincir üzerinde gönderirse, o zaman da ceza işlemini gönderecektir. Bu, WatchTower'ın yalnızca gerçek bir yanlışlık durumunda bir katılımcının işlem kaydını göreceğini ve hatta o zaman bile yalnızca tek bir işlemi göreceğini sağlar.

Optimizasyon açısından, Fiber Bitcoin Lightning Network'ün ceza mekanizmalarına bir geliştirme sunar. Lightning Network'ün "LN-Penalty"sine dikkate değer bir dezavantajı vardır: WatchTower'lar tüm eski taahhüt işlem karma değerlerini ve ilgili iptal anahtarlarını depolamak zorunda kalır, bu da önemli bir depolama baskısı yaratır. 2018 yılında, Bitcoin topluluğu bu sorunu çözmek için "eltoo" adında bir çözüm önerdi. Eltoo, en son taahhüt işleminin eski olanları cezalandırmasına izin vererek, tüm önceki işlemleri depolama ihtiyacını azaltır. Ancak, bu çözüm henüz uygulanmamış olan SIGHASH_ANYPREVOUT opcode'inin etkinleştirilmesini gerektirir.

Öte yandan Fiber, tek bir iptal anahtarını birden çok eski taahhüt işlemine uygulanabilir hale getirmek için iptal anahtarı tasarımını değiştiren Daric protokolünü kullanır. Bu yaklaşım, Gözetleme Kuleleri ve kullanıcı istemcileri için depolama taleplerini büyük ölçüde azaltır.

Ağ trafik sistemleriyle ilgili olarak: Ödeme kanalları bire bir işlemler için uygundur, ancak Lightning Network çok sekmeli ödemeleri destekler ve aracı düğümler üzerinden yönlendirme yaparak doğrudan kanalı olmayan taraflar arasında işlemlere izin verir. Örneğin, Alice ve Ken'in doğrudan bir kanalı yoksa ancak Ken ve Bob'un varsa ve Bob ve Alice'in varsa, Bob, Alice ve Ken arasındaki işlemleri kolaylaştırmak için bir aracı olarak hareket edebilir.

"Çoklu atlama yönlendirmesi", ağın esnekliğini ve kapsamını artırır. Ancak gönderenlerin tüm genel düğüm ve kanalların durumunu bilmeleri gerekir. Fiber'de, tüm genel kanalları da içeren tüm ağ yapısı tamamen şeffaftır, bu sayede herhangi bir düğüm diğer düğümlerden ağ bilgilerine erişebilir. Lightning Network'teki ağ durumu sürekli değiştiğinden, Fiber, en kısa yönlendirme yolunu bulmak için Dijkstra algoritmasını kullanır, aracıların sayısını en aza indirir ve iki taraf arasında bir işlem yolunu oluşturur.

Aracılarla ilgili güven sorununu çözmek için: Dürüst olduklarından nasıl emin olabilirsiniz? Örneğin, Alice'in Ken'e 100 birimlik bir ödeme yapması gerekiyorsa, ancak aralarında aracı olan Bob fonları alıkoyabilir. HTLC ve PTLC, bu tür kötü niyetli davranışları önlemek için kullanılır. Alice'in Daniel'e 100 birim ödemek istediğini, ancak doğrudan bir kanalları olmadığını varsayalım. Alice, ödemeyi aracılar Bob ve Carol aracılığıyla yönlendirebileceğini fark eder. HTLC ödeme kanalı olarak tanıtıldı: Alice önce Daniel'e isteği başlatır, o da Alice'e bir hash r sağlar, ancak Alice r'ye karşılık gelen R öngörüntüsünü bilmez.

Ardından, Alice HTLC aracılığıyla Bob ile ödeme koşullarını oluşturur: Alice, Bob'a 102 birim ödemeyi kabul eder, ancak Bob'un 30 dakika içinde anahtarı R ortaya çıkarması gerekir; aksi takdirde Alice para çekecektir. Benzer şekilde, Bob, Carol ile HTLC oluşturur: Bob, Carol'a 101 birim ödeyecek, ancak Carol'un 25 dakika içinde anahtarı R ortaya çıkarması gerekir; aksi takdirde Bob para çekecektir. Carol, aynısını Daniel ile yapar: Carol, Daniel'e 100 birim ödemeyi kabul eder, ancak Daniel'in 20 dakika içinde anahtarı R ortaya çıkarması gerekir; aksi takdirde Carol para çekecektir.

Daniel, Carol'ın istediği R anahtarının aslında Alice'ın istediği şey olduğunu anlar, çünkü sadece Alice R'nin değerine ilgi duyar. Bu nedenle Daniel, Carol ile işbirliği yapar, R anahtarını sağlar ve Carol'dan 100 birim alır. Bu şekilde Alice, Daniel'a 100 birim ödeme yapma hedefine ulaşır.

Daha sonra, Carol anahtarı R'yi Bob'a sağlar ve 101 birim alır. Bob daha sonra anahtarı R'yi Alice'e sağlar ve 102 birim alır. Herkesin kazanç ve kayıplarını gözlemleyerek, Alice 102 birim kaybeder, Bob ve Carol her biri net 1 birim kazanır ve Daniel 100 birim alır. Bob ve Carol'ın kazandığı 1 birim, Alice'den alınan ücretleridir.

Ödeme yolunda yer alan birisi, örneğin Carol, aşağı akış Bob'a anahtarı R sağlayamazsa bile Bob için bir kayıp oluşmaz: süre dolduktan sonra, Bob oluşturduğu HTLC'yi çekebilir. Aynı durum Alice için de geçerlidir. Bununla birlikte, Lightning Ağı'nın kendi sorunları vardır: yol çok uzun olmamalıdır. Yol çok uzun ve çok fazla aracı ile birlikteyse, ödeme güvenilirliğini azaltabilir. Bazı aracılar çevrimdışı olabilir veya belirli bir HTLC oluşturmak için yeterli bakiyesi olmayabilir (örneğin, önceki örnekteki her aracının 100 birimden fazla tutması gerekmektedir). Bu nedenle, daha fazla aracı eklemek hataların olasılığını artırır.

Ayrıca, HTLC'ler gizlilik sızdırabilir. Soğan yönlendirme her adımda yönlendirme bilgisini şifreleyerek biraz gizlilik koruması sağlayabilir, böylece her katılımcı yalnızca doğrudan komşularını ve tam yolun tamamını değil bilir, ancak HTLC'ler hala ilişkilere ilişkin çıkarımlara açıktır. Daha yüksek bir perspektiften, tam yönlendirme yolu hala çıkarılabilir.

Bob ve Daniel'in aynı varlık tarafından kontrol edildiğini ve her gün birçok HTLC aldıklarını varsayalım. Alice ve Carol tarafından istenen anahtar R'nin her zaman aynı olduğunu ve Daniel'e bağlı olan aşağı akış düğümü Eve'nin her zaman anahtar R'nin içeriğini bildiğini fark ederler. Bu nedenle Daniel ve Bob, her zaman aynı anahtarla uğraştıkları ve ilişkilerini izleyebildikleri için Alice ve Eve arasında bir ödeme yolu olduğunu çıkarabilirler. Bunu ele almak için Fiber, ödeme yolu üzerinde her PTLC'yi açmak için farklı anahtarlar kullanarak HTLC'ler üzerinde gizliliği artıran PTLC'leri kullanır. Yalnızca PTLC'leri gözlemlemek düğümler arasındaki ilişkileri belirleyemez. PTLC'leri soğan yönlendirmesi ile birleştirerek, Fiber gizliliği koruyan ödemeler için ideal bir çözüm haline gelir.

Ayrıca, geleneksel Lightning Network, ödeme yolundaki aracılardan varlıkların çalınmasına neden olabilecek bir 'değiştirme döngüsü saldırısı'na karşı savunmasızdır. Bu sorun, geliştirici Antoine Riard'ın Lightning Network geliştirilmesinden geri çekilmesine yol açtı. Şu anda, Bitcoin Lightning Network'ün bu soruna temel bir çözümü olmadığı için, bu bir acı noktası haline geldi. Şu anda, CKB, işlem havuzu seviyesindeki geliştirmelerle bu saldırı senaryosuyla başa çıkıyor ve Fiber, sorunu hafifletiyor. Değiştirme döngüsü saldırısı ve çözümleri oldukça karmaşık olduğundan, bu makale daha fazla ayrıntıya girmeyecektir. İlgilenen okuyucular, BTCStudy ve resmi CKB kaynaklarındaki ilgili makalelere daha fazla bilgi için başvurabilirler.

Genel olarak, Fiber gizlilik ve güvenlik yönleri açısından geleneksel Lightning Network'e göre önemli bir iyileştirme sağlar. Fiber, kendisiyle ve Bitcoin Lightning Network arasında çapraz etki atomik ödemelerini artırır.

Fiber, HTLC ve PTLC'yi kullanarak Bitcoin Lightning Network ile etki alanları arası ödemeler gerçekleştirebilir ve "etki alanları arası eylemlerin atomikliğini" sağlar, yani etki alanları arası işlemin tüm adımları, kısmi bir başarı veya başarısızlık olmaksızın ya tamamen başarılı ya da tamamen başarısız olur. Etki alanları arası atomiklik sağlandığında, varlık kaybı riski azaltılır. Bu, Fiber'in Bitcoin Lightning Network ile ara bağlantı kurmasına izin vererek, Fiber'den BTC Lightning Network'teki kullanıcılara (alıcı BTC ile sınırlı) doğrudan ödeme yapılmasını sağlar ve CK dönüşümlerine izin verir

B ve RGB++ varlıklarını BTC Lightning Network içinde eşdeğer Bitcoin'e dönüştürmek.

İşlem sürecinin basit bir açıklaması şöyledir: Diyelim ki Alice Fiber ağında bir düğüm çalıştırıyor ve Bob Bitcoin Lightning Network'te bir düğüm çalıştırıyor. Alice, Bob'a biraz para transfer etmek istiyorsa, bunu çapraz etki alan aracısı olan Ingrid aracılığıyla yapabilir. Ingrid, Fiber ve BTC Lightning ağlarında düğümler çalıştıracak ve ödeme yolunda aracı olarak hareket edecektir.

Eğer Bob 1 BTC almak istiyorsa, Alice, 1 CKB'nin 1 BTC'ye eşit olduğu bir döviz kuruyla Ingrid ile pazarlık yapabilir. Alice daha sonra Fiber ağı içinde 1.1 CKB'yi Ingrid'e gönderir ve Ingrid, Bitcoin Lightning Network'te 1 BTC'yi Bob'a gönderir, 0.1 CKB'yi ücret olarak alarak.

Süreç, HTLC kullanarak Alice, Ingrid ve Bob arasında bir ödeme yolu kurmayı içerir. Bob, fonları almak için Ingrid'e anahtarı R sağlamalıdır. Ingrid, anahtar R'ye sahip olduğunda, Alice'ın HTLC'de kilitlediği fonları açabilir.

BTC Lightning Network ve Fiber arasındaki çapraz domain işlemleri atomiktir, yani hem HTLC'lerin ikisi de kilidi açılır ve çapraz domain ödemesi başarıyla gerçekleştirilir, ya da ikisi de kilidi açılmaz ve ödeme başarısız olur. Bu, Bob ödeme almadığında Alice'ın para kaybetmemesini sağlar.

Ingrid, anahtarı R'yi bildikten sonra Alice'in HTLC'sini potansiyel olarak açamayabilir, ancak bu Ingrid'e zarar verir, Alice'e değil. Bu nedenle, Fiber'in tasarımı, kullanıcılar için güvenliği sağlar ve üçüncü taraflara güven gerektirmez, böylece farklı P2P ağları arasında minimal değişikliklerle transferlerin yapılmasını sağlar.

BTC Lightning Network'e kıyasla Fiber'ın diğer avantajları

Daha önce, Fiber'ın yerel CKB varlıklarını ve RGB ++ varlıklarını (özellikle istikrarlı paraları) desteklediğini belirtmiştik, bu da gerçek zamanlı ödemeler için önemli bir potansiyele sahip olmasını ve günlük küçük işlemler için uygun olmasını sağlıyor.

Buna karşılık, Bitcoin Lightning Ağı'nın temel bir sorunu likidite yönetimidir. Başlangıçta tartıştığımız gibi, bir ödeme kanalındaki toplam bakiye sabittir. Bir tarafın bakiyesi tükenirse, diğer tarafa para transfer edemezler, ancak diğer taraf önce para gönderirse. Bu, fonları yeniden yüklemeyi veya yeni bir kanal açmayı gerektirir.

Ayrıca, karmaşık bir çoklu atlama ağı durumunda, bazı ara düğümlerin yetersiz bakiyeye sahip olması ve ödemeleri iletememeleri, tüm ödeme yolunun başarısız olmasına neden olabilir. Bu, Lightning Network'ün acı noktalarından biridir. Tipik çözüm, çoğu düğmelerin gerektiğinde fon enjekte edebilmelerini sağlamak için verimli likidite enjeksiyon mekanizmaları sağlamayı içerir.

Ancak, Bitcoin Lightning Network'te likidite enjeksiyonu ve kanal açma veya kapama işlemleri, tamamı Bitcoin blok zincirinde gerçekleşir. Eğer Bitcoin ağ ücretleri çok yüksekse, ödeme kanallarının kullanıcı deneyimini olumsuz etkiler. Örneğin, 100 dolarlık bir kapasiteye sahip bir kanal açmak istiyorsanız ve kurulum ücreti 10 dolar ise, bu demektir ki fonlarınızın %10'u sadece kanalı kurmak için harcanmaktadır ve bu, çoğu kullanıcı için kabul edilemezdir. Likidite enjeksiyonu için de aynı sorun geçerlidir.

Buna karşın, Fiber önemli avantajlar sunar. İlk olarak, CKB'nin TPS (saniyede işlem) miktarı Bitcoin'inkinden çok daha yüksektir ve ücretler sent düzeyinde maliyetlere ulaşır. İkinci olarak, likidite sıkıntısı sorununu ele almak ve sorunsuz işlemleri sağlamak için Fiber, likidite enjeksiyonu için zincir dışı işlemlere ihtiyaç duyulmaksızın yeni çözümler sunmak için Mercury Layer ile işbirliği yapmayı planlamaktadır, böylece UX ve maliyet sorunlarını çözer.

Fiber'in genel teknik mimarisini şimdi sistemli bir şekilde Bitcoin Lightning Ağı ile karşılaştıran bir özetini yukarıdaki resimde gösterildiği gibi şimdi sistemli olarak açıkladık. Hem Fiber hem de Lightning Ağı tarafından kapsanan konuların karmaşıklığı ve genişliği göz önüne alındığında, tek bir makale her yönü ele alamayabilir. Gelecekte Lightning Ağı ve Fiber'in çeşitli yönlerine odaklanan bir dizi makale yayınlayacağız. Daha fazla güncelleme için takipte kalın.

Dikkat:

1. Bu makale [ başlığından alınmıştır.Geek web3]. ‘系统解读Fiber：把闪电网络嫁接到CKB上的宏大实验’ başlığını ileriye taşıyın. Tüm telif hakları orijinal yazara aittir [Faust & Nickqiao, geek web3]. Bu yeniden baskıya itirazlar varsa, lütfen Gate Öğrenekip, ve bunu hızlı bir şekilde ele alacaklar.
2. Sorumluluk Feragati: Bu makalede yer alan görüşler ve düşünceler yalnızca yazarına aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalelerin diğer dillere çevirileri, Gate Learn ekibi tarafından yapılır. Belirtilmedikçe, çevrilen makalelerin kopyalanması, dağıtılması veya kopya çekilmesi yasaktır.