Yazarlar: Ellaine Xu, Hettie Jiang, June Wang, Walon Lin, Yiliu Lin
1. Ölçeklenmenin Gerekliliği
Blockchain'ın geleceği, merkeziyetsizlik, güvenlik ve ölçeklenebilirlikten oluşan büyük bir vizyondur; ancak genellikle blockchain yalnızca bunlardan ikisini gerçekleştirebilir, bu üç talebi karşılamak ise blockchain'ın imkansız üçgen problemi olarak adlandırılır. Yıllar boyunca, bu sorunu nasıl çözebileceğimiz, merkeziyetsizlik ve güvenliği garanti ederken blockchain'ın işlem hacmini ve işlem hızını artırmanın yollarını araştırdık, yani ölçeklenebilirlik sorununu çözmek, mevcut blockchain gelişim sürecinde tartışılan en sıcak konulardan biridir.
Öncelikle blok zincirinin merkeziyetsizliğini, güvenliğini ve ölçeklenebilirliğini genel hatlarıyla tanımlayalım:
Merkeziyetsiz: Herkes, blok zinciri sisteminin üretim ve doğrulamasına katılmak için bir düğüm olabilir, düğüm sayısı ne kadar fazla olursa, merkeziyetsizlik derecesi o kadar yüksek olur ve böylece ağın küçük bir grup büyük merkezi katılımcının kontrolüne girmesi sağlanır.
Güvenlik: Bir blockchain sisteminin kontrolünü elde etmek için harcanan maliyet ne kadar yüksekse, güvenlik o kadar yüksektir; bu nedenle, zincir, daha büyük bir katılımcı oranının saldırılarına karşı dayanıklı olabilir.
Ölçeklenebilirlik: Blok zincirinin büyük miktarda işlemi işleme yeteneği.
Bitcoin ağının ilk büyük hard fork'u, ölçeklenme sorunundan kaynaklanmaktadır. Bitcoin kullanıcı sayısı ve işlem hacmi arttıkça, her bloğun 1MB'lık üst sınırı olan Bitcoin ağı tıkanma sorunu ile karşılaşmaya başladı; 2015 yılından itibaren, Bitcoin topluluğunda ölçeklenme sorununda anlaşmazlıklar ortaya çıktı, bir tarafı Bitcoin ABC'yi temsil eden blok genişletmeyi destekleyen genişletme yanlıları, diğer tarafı ise Bitcoin Core'u temsil eden küçük blok yanlıları, ana zincir yapısını optimize etmek için Segwit çözümünü kullanmaları gerektiğini savundu. 1 Ağustos 2017'de, Bitcoin ABC, 8MB'lık bir istemci sistemi geliştirerek çalışmaya başladı, bu da Bitcoin tarihindeki ilk büyük hard fork'un ortaya çıkmasına neden oldu ve bu yeni bir kripto para birimi olan BCH'nin doğmasına yol açtı.
Aynı şekilde, Ethereum ağı da güvenliğini ve merkeziyetsizliğini sağlamak için bir miktar ölçeklenebilirlikten feragat etmeyi seçmiştir; Ethereum ağı, Bitcoin ağı gibi işlem hacmini sınırlamak için blok boyutunu kısıtlamamış, bunun yerine tek bir bloğun alabileceği yakıt ücretine bir üst sınır koymaya dönüşmüştür, ancak amaç her iki durumda da Trustless Consensus'u gerçekleştirmek ve düğümlerin geniş bir dağılımını sağlamaktır. ( Sınırın kaldırılması veya artırılması, birçok bant genişliği, depolama ve hesaplama kapasitesi yetersiz küçük düğümün elenmesine neden olacaktır. ).
2017 yılındaki CryptoKitties, DeFi yazı, ardından GameFi ve NFT gibi zincir üzerindeki uygulamaların yükselişi ile birlikte, pazarın işlem hacmi talebi sürekli artmaktadır, ancak Turing tamamlayıcı olan Ethereum bile saniyede yalnızca 15-45 işlem ( TPS ) gerçekleştirebiliyor. Bunun sonucu olarak, işlem maliyetleri sürekli artmakta, uzlaşma süreleri uzamakta, çoğu Dapp işletme maliyetlerini karşılamakta zorlanmakta, tüm ağ kullanıcılar için hem yavaş hem de pahalı hale gelmektedir, blok zinciri ölçeklendirme sorunu acilen çözülmelidir. İdeal ölçeklendirme çözümü, merkeziyetsizlik ve güvenlikten ödün vermeden, blok zinciri ağının işlem hızını mümkün olduğunca artırmak, ( daha kısa finalite süresi ) ve işlem hacmini ( daha yüksek TPS ) sağlamak olmalıdır.
2. Ölçekleme Çözümünün Kategorileri
"Ana ağda bir katman değişip değişmeyeceği" standardına göre, genişleme planlarını on-chain genişleme ve off-chain genişleme olmak üzere iki ana kategoriye ayırıyoruz.
2.1 Zincir Üzerinde Ölçekleme
Kilit kavram: Bir ana ağ protokolünü değiştirerek ölçeklenme etkisi elde etme çözümü, mevcut ana çözüm parçalama (sharding) olarak bilinmektedir.
Zincir üzerinde ölçeklendirme için çeşitli çözümler bulunmaktadır, bu makalede bunlar üzerinde durulmayacak, aşağıda iki çözüm kısaca sıralanmıştır:
Plan bir, blok alanını genişletmek, yani her blokta paketlenecek işlem sayısını artırmaktır, ancak bu, yüksek performanslı düğüm cihazları için gereksinimleri artıracak, düğümlerin katılım eşiğini yükseltecek ve "merkeziyetsizlik" derecesini azaltacaktır.
İkinci seçenek parçalama, blok zinciri defterini birkaç bölüme ayırmak, artık her düğümün tüm muhasebe işlemlerine katılmaması, farklı parçaların yani farklı düğümlerin farklı muhasebe işlemlerinden sorumlu olmasıdır; paralel hesaplama birden fazla işlemi aynı anda işleyebilir; bu, düğümlerin hesaplama yükünü ve katılım eşiğini düşürebilir, işlem işleme hızını ve merkeziyetsizlik derecesini artırabilir; ancak bu, tüm ağın hesaplama gücünün dağıtılacağı anlamına gelir ve bu da genel ağın "güvenliğini" azaltabilir.
Ana ağ protokolünün kodunu değiştirmek, alt yapıda herhangi bir küçük güvenlik açığının tüm ağın güvenliğini ciddi şekilde tehdit edebileceği için öngörülemeyen olumsuz etkilere yol açabilir. Ağ, bir çatallaşmaya veya kesintili düzeltme güncellemesine zorlanabilir. Örneğin, 2018'deki Zcash enflasyon açığı olayı: Zcash'in kodu, Bitcoin 0.11.2 sürüm kodu üzerinde yapılan değişikliklere dayanıyordu. 2018 yılında bir mühendis, alt yapıda yüksek riskli bir açık buldu; yani tokenler sınırsız bir şekilde basılabiliyordu. Takım, açık kapatıldıktan sonra bu olayı kamuya açıklamadan önce 8 ay boyunca gizli bir şekilde onarım yaptı.
2.2 off-chain genişleme
Temel Kavram: Mevcut birinci katman ana ağ protokolünü değiştirmeden ölçeklenme çözümü.
off-chain ölçeklendirme çözümleri ayrıca Layer2 ve diğer çözümler olarak ayrılabilir:
3. Off-chain ölçeklendirme çözümleri
3.1 Eyalet Kanalları
3.1.1 Özet
Durum kanalları, yalnızca kanal açıldığında, kapandığında veya anlaşmazlık çözüldüğünde kullanıcıların ana ağ ile etkileşimde bulunması gerektiğini belirler ve kullanıcılar arasındaki etkileşimleri off-chain gerçekleştirerek, kullanıcı işlemlerinin zaman ve maliyet yükünü azaltır ve işlem sayısında sınırlama getirmeden işlemlerin gerçekleştirilmesini sağlar.
Durum kanalları, iki kişilik satranç oyunu gibi "tur bazlı uygulamalar" için uygun olan basit bir P2P protokolüdür. Her kanal, ana ağda çalışan çok imzalı akıllı sözleşmeler tarafından yönetilir; bu sözleşme, kanala yatırılan varlıkları kontrol eder, durum güncellemelerini doğrular ve katılımcılar arasındaki anlaşmazlıkları (, imza ve zaman damgası ile birlikte sahtecilik kanıtına dayanarak ) hakemlik eder. Katılımcılar, blok zincir ağına sözleşmeyi dağıttıktan sonra, bir miktar fon yatırır ve kilitler, iki taraf imzalarıyla onayladıktan sonra kanal resmi olarak açılır. Kanal, katılımcılar arasında, yatırılan token'ların toplam miktarını ( aşmadığı sürece, sınırsız sayıda off-chain ücretsiz işlem yapmalarına olanak tanır ). Katılımcılar sırayla birbirlerine durum güncellemeleri gönderir ve diğerinin imzasını bekler. Diğer taraf imzasını onayladığında, bu durum güncellemesi tamamlanmış sayılır. Normal koşullarda, iki tarafın anlaştığı durum güncellemeleri ana ağa yüklenmez; sadece bir anlaşmazlık ortaya çıktığında veya kanal kapatıldığında ana ağ onayına başvurulur. Kanalın kapatılması gerektiğinde, herhangi bir katılımcı, ana ağda bir işlem talebi oluşturabilir; eğer çıkış talebi tüm katılımcıların imzasıyla onaylanırsa, zincir üzerinde hemen gerçekleştirilir, yani akıllı sözleşme, kanalın son durumundaki her katılımcının bakiyesine göre, kalan kilitli fonları dağıtır; eğer diğer katılımcılar onay vermezse, herkesin kalan fonları alabilmesi için "meydan okuma dönemi"nin sona ermesini beklemesi gerekir.
Yukarıda belirtilenlere göre, durum kanalı çözümü ana ağın hesaplama yükünü büyük ölçüde azaltabilir, işlem hızını artırabilir ve işlem maliyetini düşürebilir.
3.1.2 Zaman Çizgisi
2015/02, Joseph Poon ve Thaddeus Dryja, Lightning Network beyaz kağıdı taslağını yayınladılar.
2015/11, Jeff Coleman, State Channel kavramını ilk kez sistematik olarak özetledi ve Bitcoin'in Payment Channel'ının State Channel kavramındaki bir alt durum olduğunu ileri sürdü.
2016/01, Joseph Poon ve Thaddeus Dryja, Bitcoin Lightning Network: Ölçeklenebilir Off-Chain Anlık Ödemeler adlı beyaz kitabı resmi olarak yayımladı ve Bitcoin için bir genişleme çözümü olarak Payment Channel( ödeme kanalı) önerdi, bu çözüm yalnızca Bitcoin ağı üzerindeki transfer ödemelerini işlemek için kullanılmaktadır.
2017/11, Payment Channel çerçevesine dayanan ilk State Channel tasarım standardı Sprites önerildi.
2018/06, Counterfactual, çok ayrıntılı bir Genelleşmiş Durum Kanalları tasarımı önerdi, bu durum kanallarıyla tamamen ilgili olan ilk tasarımdır.
2018/10, Generalised State Channel Networks makalesi State Channel Networks ve Sanal Kanallar kavramını ortaya koymuştur.
2019/02, durum kanalı kavramı N-Party Kanallara genişletildi, Nitro bu düşünceye dayalı olarak oluşturulan ilk protokoldür.
2019/10, Pisa, tüm katılımcıların sürekli çevrimiçi olma sorununu çözmek için Watchtowers kavramını genişletti.
2020/03, Hydra Hızlı İzomorfik Kanalları önerdi.
3.1.3 Teknik İlkeler
Durum kanallarının genel çalışma akışı aşağıdaki gibidir:
Alice ve Bob, kişisel EOA'larından fonları zincir üzerindeki sözleşme adresine yatırarak, bu fonlar sözleşmede kilitlenir ve yalnızca kanal kapandığında bakiye kullanıcıya iade edilir; iki taraf imza onayladıktan sonra, aralarındaki durum kanalı resmi olarak açılır.
Alice ve Bob, bu kanal aracılığıyla teorik olarak off-chain olarak sınırsız sayıda işlem gerçekleştirebilir, katılımcılar şifreli imza mesajları ile birbirleriyle iletişim kurar ( ve blok zincir ağı ile iletişim kurmazlar ). Her iki kullanıcı da her işlem için imza atmak zorundadır, bu da çift harcama dolandırıcılığını önlemeye yardımcı olur. Bu mesajlar aracılığıyla, kendi hesaplarının durum güncellemelerini sunarlar ve karşı tarafın sunduğu durum güncellemelerini kabul ederler.
Eğer Alice, Bob ile olan işlemi sonlandırmak istiyorsa, Alice sözleşmeye kendi hesabının nihai durumunu sunmalıdır. Eğer Bob imzayı onaylarsa, sözleşme nihai duruma göre kilitlenmiş fonları ilgili kullanıcıya geri serbest bırakacaktır. Eğer Bob imzaya yanıt vermezse, sözleşme itiraz süresi sona erdikten sonra kilitlenmiş fonları ilgili kullanıcıya geri serbest bırakacaktır.
3.1.4 Avantajlar ve Dezavantajlar
Avantajlar:
İşlem hızı hızlı, neredeyse anında onay
Çok düşük işlem ücretleri
Yüksek işleme kapasitesi, teorik olarak işlem sayısında sınırlama yoktur.
İyi bir gizlilik, sadece nihai durum zincir üzerinde.
Eksileri:
Fonların kilitlenmesi gerekiyor
Tüm katılımcıların sürekli çevrimiçi olması gerekmektedir
Geçit kapasitesi sınırlı
Kanalın açılması ve kapatılması işlem ücreti gerektirir.
Karmaşık akıllı sözleşmelerin uygulanması zordur
Likidite sorunu
3.1.5 Uygulama
Bitcoin Lightning Network
Özet:
Lightning Network, Bitcoin ağı için küçük ödemeler kanalıdır, genel teknik evrimi şunları içermektedir: 2/2 çoklu imza ile tek yönlü ödeme kanalı inşası, RSMC eklenerek çift yönlü ödeme kanalı oluşturulması, ardından HTLC eklenerek ödeme kanallarının çoklu ödemelere genişletilmesi, en sonunda ödeme ağı olan Lightning Network'ün inşası. Off-chain küçük ödeme kanalları aracılığıyla, ardından aracıları kullanarak bir işlem ağı oluşturulabilir, bu da Bitcoin ağının ölçeklenebilirlik sorununu çözebilir. Lightning Network'ün genel kullanımı "Depozit ( Kanal Kurulumu ) → Lightning Network İşlemi ( Kanal Durumunun Güncellenmesi ) → İade / Hesaplaşma ( Kanalın Sonlandırılması )" sürecini takip eder; teorik olarak Lightning Network her saniye bir milyon işlem gerçekleştirebilir.
Zaman çizelgesi:
Şubat 2015'te, Joseph Poon ve Thaddeus Dryja, Lightning Network beyaz kağıdının taslağını yayınladılar.
2016 Ocak ayında resmi beyaz kitabı yayınladı ve Lightning Labs'ı kurdu
15 Mart 2018'de, Lightning Labs ilk Lightning Network ana ağ sürümünü Lightning Network Daemon (LND) 0.4 sürümünü yayınladı.
2021'in başlarında, Lightning Network'ün kamu kapasitesi (TVL) yaklaşık 40 milyon dolar civarındaydı ve yaklaşık 100.000 kullanıcı Lightning Network'ü kullanıyordu.
2021 Haziran'ında El Salvador, Bitcoin'i yasal para birimi olarak benimsedi, Eylül'de Lightning Network tabanlı Chivo cüzdanını yayınladı.
2022 yılında, Cash App ve OKX, Kraken, Bitfinex dahil olmak üzere 26 kripto para borsa platformu, Lightning Network'ü desteklediğini açıkladı ve BTC yatırma, çekme ve transfer işlemleri için anlık ve ucuz hizmet sağladı.
2022 Ekim'de, Lightning Labs Taproot tabanlı yeni bir protokol olan Taro protocol( alpha sürümünü) yayınladı, şu anda test ağında test ediliyor, gelecekte Bitcoin ağı üzerinde varlık oluşturmak, göndermek ve almak için kullanılabilecek ve Lightning Network üzerinden işlem yapabilecektir.
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.
16 Likes
Reward
16
5
Share
Comment
0/400
LightningPacketLoss
· 08-01 23:04
Hala Kutsal Olmayan Üçlü oynuyor, off-chain Rug Pull daha cazip.
View OriginalReply0
BlockDetective
· 08-01 23:04
Ölçeklendirme gerçekten zor, TPS'yi nasıl artıracağız?
View OriginalReply0
CoffeeOnChain
· 08-01 22:58
Bu üçgeni hala çözememek çok sinir bozucu...
View OriginalReply0
WagmiOrRekt
· 08-01 22:49
Ah, sonuçta bu hala üçgen probleminden saç dökülmesi.
View OriginalReply0
RooftopVIP
· 08-01 22:45
Aman tanrım, bu makale yine bayat konuları gündeme getiriyor.
Derinlemesine Analiz: Blok Zinciri Performansını Optimize Etmenin Yenilikçi Çözümü
off-chain ölçeklenme Derinlik analizi
Yazarlar: Ellaine Xu, Hettie Jiang, June Wang, Walon Lin, Yiliu Lin
1. Ölçeklenmenin Gerekliliği
Blockchain'ın geleceği, merkeziyetsizlik, güvenlik ve ölçeklenebilirlikten oluşan büyük bir vizyondur; ancak genellikle blockchain yalnızca bunlardan ikisini gerçekleştirebilir, bu üç talebi karşılamak ise blockchain'ın imkansız üçgen problemi olarak adlandırılır. Yıllar boyunca, bu sorunu nasıl çözebileceğimiz, merkeziyetsizlik ve güvenliği garanti ederken blockchain'ın işlem hacmini ve işlem hızını artırmanın yollarını araştırdık, yani ölçeklenebilirlik sorununu çözmek, mevcut blockchain gelişim sürecinde tartışılan en sıcak konulardan biridir.
Öncelikle blok zincirinin merkeziyetsizliğini, güvenliğini ve ölçeklenebilirliğini genel hatlarıyla tanımlayalım:
Bitcoin ağının ilk büyük hard fork'u, ölçeklenme sorunundan kaynaklanmaktadır. Bitcoin kullanıcı sayısı ve işlem hacmi arttıkça, her bloğun 1MB'lık üst sınırı olan Bitcoin ağı tıkanma sorunu ile karşılaşmaya başladı; 2015 yılından itibaren, Bitcoin topluluğunda ölçeklenme sorununda anlaşmazlıklar ortaya çıktı, bir tarafı Bitcoin ABC'yi temsil eden blok genişletmeyi destekleyen genişletme yanlıları, diğer tarafı ise Bitcoin Core'u temsil eden küçük blok yanlıları, ana zincir yapısını optimize etmek için Segwit çözümünü kullanmaları gerektiğini savundu. 1 Ağustos 2017'de, Bitcoin ABC, 8MB'lık bir istemci sistemi geliştirerek çalışmaya başladı, bu da Bitcoin tarihindeki ilk büyük hard fork'un ortaya çıkmasına neden oldu ve bu yeni bir kripto para birimi olan BCH'nin doğmasına yol açtı.
Aynı şekilde, Ethereum ağı da güvenliğini ve merkeziyetsizliğini sağlamak için bir miktar ölçeklenebilirlikten feragat etmeyi seçmiştir; Ethereum ağı, Bitcoin ağı gibi işlem hacmini sınırlamak için blok boyutunu kısıtlamamış, bunun yerine tek bir bloğun alabileceği yakıt ücretine bir üst sınır koymaya dönüşmüştür, ancak amaç her iki durumda da Trustless Consensus'u gerçekleştirmek ve düğümlerin geniş bir dağılımını sağlamaktır. ( Sınırın kaldırılması veya artırılması, birçok bant genişliği, depolama ve hesaplama kapasitesi yetersiz küçük düğümün elenmesine neden olacaktır. ).
2017 yılındaki CryptoKitties, DeFi yazı, ardından GameFi ve NFT gibi zincir üzerindeki uygulamaların yükselişi ile birlikte, pazarın işlem hacmi talebi sürekli artmaktadır, ancak Turing tamamlayıcı olan Ethereum bile saniyede yalnızca 15-45 işlem ( TPS ) gerçekleştirebiliyor. Bunun sonucu olarak, işlem maliyetleri sürekli artmakta, uzlaşma süreleri uzamakta, çoğu Dapp işletme maliyetlerini karşılamakta zorlanmakta, tüm ağ kullanıcılar için hem yavaş hem de pahalı hale gelmektedir, blok zinciri ölçeklendirme sorunu acilen çözülmelidir. İdeal ölçeklendirme çözümü, merkeziyetsizlik ve güvenlikten ödün vermeden, blok zinciri ağının işlem hızını mümkün olduğunca artırmak, ( daha kısa finalite süresi ) ve işlem hacmini ( daha yüksek TPS ) sağlamak olmalıdır.
2. Ölçekleme Çözümünün Kategorileri
"Ana ağda bir katman değişip değişmeyeceği" standardına göre, genişleme planlarını on-chain genişleme ve off-chain genişleme olmak üzere iki ana kategoriye ayırıyoruz.
2.1 Zincir Üzerinde Ölçekleme
Kilit kavram: Bir ana ağ protokolünü değiştirerek ölçeklenme etkisi elde etme çözümü, mevcut ana çözüm parçalama (sharding) olarak bilinmektedir.
Zincir üzerinde ölçeklendirme için çeşitli çözümler bulunmaktadır, bu makalede bunlar üzerinde durulmayacak, aşağıda iki çözüm kısaca sıralanmıştır:
Ana ağ protokolünün kodunu değiştirmek, alt yapıda herhangi bir küçük güvenlik açığının tüm ağın güvenliğini ciddi şekilde tehdit edebileceği için öngörülemeyen olumsuz etkilere yol açabilir. Ağ, bir çatallaşmaya veya kesintili düzeltme güncellemesine zorlanabilir. Örneğin, 2018'deki Zcash enflasyon açığı olayı: Zcash'in kodu, Bitcoin 0.11.2 sürüm kodu üzerinde yapılan değişikliklere dayanıyordu. 2018 yılında bir mühendis, alt yapıda yüksek riskli bir açık buldu; yani tokenler sınırsız bir şekilde basılabiliyordu. Takım, açık kapatıldıktan sonra bu olayı kamuya açıklamadan önce 8 ay boyunca gizli bir şekilde onarım yaptı.
2.2 off-chain genişleme
Temel Kavram: Mevcut birinci katman ana ağ protokolünü değiştirmeden ölçeklenme çözümü.
off-chain ölçeklendirme çözümleri ayrıca Layer2 ve diğer çözümler olarak ayrılabilir:
3. Off-chain ölçeklendirme çözümleri
3.1 Eyalet Kanalları
3.1.1 Özet
Durum kanalları, yalnızca kanal açıldığında, kapandığında veya anlaşmazlık çözüldüğünde kullanıcıların ana ağ ile etkileşimde bulunması gerektiğini belirler ve kullanıcılar arasındaki etkileşimleri off-chain gerçekleştirerek, kullanıcı işlemlerinin zaman ve maliyet yükünü azaltır ve işlem sayısında sınırlama getirmeden işlemlerin gerçekleştirilmesini sağlar.
Durum kanalları, iki kişilik satranç oyunu gibi "tur bazlı uygulamalar" için uygun olan basit bir P2P protokolüdür. Her kanal, ana ağda çalışan çok imzalı akıllı sözleşmeler tarafından yönetilir; bu sözleşme, kanala yatırılan varlıkları kontrol eder, durum güncellemelerini doğrular ve katılımcılar arasındaki anlaşmazlıkları (, imza ve zaman damgası ile birlikte sahtecilik kanıtına dayanarak ) hakemlik eder. Katılımcılar, blok zincir ağına sözleşmeyi dağıttıktan sonra, bir miktar fon yatırır ve kilitler, iki taraf imzalarıyla onayladıktan sonra kanal resmi olarak açılır. Kanal, katılımcılar arasında, yatırılan token'ların toplam miktarını ( aşmadığı sürece, sınırsız sayıda off-chain ücretsiz işlem yapmalarına olanak tanır ). Katılımcılar sırayla birbirlerine durum güncellemeleri gönderir ve diğerinin imzasını bekler. Diğer taraf imzasını onayladığında, bu durum güncellemesi tamamlanmış sayılır. Normal koşullarda, iki tarafın anlaştığı durum güncellemeleri ana ağa yüklenmez; sadece bir anlaşmazlık ortaya çıktığında veya kanal kapatıldığında ana ağ onayına başvurulur. Kanalın kapatılması gerektiğinde, herhangi bir katılımcı, ana ağda bir işlem talebi oluşturabilir; eğer çıkış talebi tüm katılımcıların imzasıyla onaylanırsa, zincir üzerinde hemen gerçekleştirilir, yani akıllı sözleşme, kanalın son durumundaki her katılımcının bakiyesine göre, kalan kilitli fonları dağıtır; eğer diğer katılımcılar onay vermezse, herkesin kalan fonları alabilmesi için "meydan okuma dönemi"nin sona ermesini beklemesi gerekir.
Yukarıda belirtilenlere göre, durum kanalı çözümü ana ağın hesaplama yükünü büyük ölçüde azaltabilir, işlem hızını artırabilir ve işlem maliyetini düşürebilir.
3.1.2 Zaman Çizgisi
3.1.3 Teknik İlkeler
Durum kanallarının genel çalışma akışı aşağıdaki gibidir:
Alice ve Bob, kişisel EOA'larından fonları zincir üzerindeki sözleşme adresine yatırarak, bu fonlar sözleşmede kilitlenir ve yalnızca kanal kapandığında bakiye kullanıcıya iade edilir; iki taraf imza onayladıktan sonra, aralarındaki durum kanalı resmi olarak açılır.
Alice ve Bob, bu kanal aracılığıyla teorik olarak off-chain olarak sınırsız sayıda işlem gerçekleştirebilir, katılımcılar şifreli imza mesajları ile birbirleriyle iletişim kurar ( ve blok zincir ağı ile iletişim kurmazlar ). Her iki kullanıcı da her işlem için imza atmak zorundadır, bu da çift harcama dolandırıcılığını önlemeye yardımcı olur. Bu mesajlar aracılığıyla, kendi hesaplarının durum güncellemelerini sunarlar ve karşı tarafın sunduğu durum güncellemelerini kabul ederler.
Eğer Alice, Bob ile olan işlemi sonlandırmak istiyorsa, Alice sözleşmeye kendi hesabının nihai durumunu sunmalıdır. Eğer Bob imzayı onaylarsa, sözleşme nihai duruma göre kilitlenmiş fonları ilgili kullanıcıya geri serbest bırakacaktır. Eğer Bob imzaya yanıt vermezse, sözleşme itiraz süresi sona erdikten sonra kilitlenmiş fonları ilgili kullanıcıya geri serbest bırakacaktır.
3.1.4 Avantajlar ve Dezavantajlar
Avantajlar:
Eksileri:
3.1.5 Uygulama
Bitcoin Lightning Network
Özet: Lightning Network, Bitcoin ağı için küçük ödemeler kanalıdır, genel teknik evrimi şunları içermektedir: 2/2 çoklu imza ile tek yönlü ödeme kanalı inşası, RSMC eklenerek çift yönlü ödeme kanalı oluşturulması, ardından HTLC eklenerek ödeme kanallarının çoklu ödemelere genişletilmesi, en sonunda ödeme ağı olan Lightning Network'ün inşası. Off-chain küçük ödeme kanalları aracılığıyla, ardından aracıları kullanarak bir işlem ağı oluşturulabilir, bu da Bitcoin ağının ölçeklenebilirlik sorununu çözebilir. Lightning Network'ün genel kullanımı "Depozit ( Kanal Kurulumu ) → Lightning Network İşlemi ( Kanal Durumunun Güncellenmesi ) → İade / Hesaplaşma ( Kanalın Sonlandırılması )" sürecini takip eder; teorik olarak Lightning Network her saniye bir milyon işlem gerçekleştirebilir.
Zaman çizelgesi: