Blok zincirinin gelecekteki vizyonu, merkeziyetsizlik, güvenlik ve ölçeklenebilirliktir; ancak genellikle bunlardan yalnızca ikisi gerçekleştirilebilir, bu da blok zincirinin imkânsız üçgen sorunu olarak adlandırılır. Yıllardır insanlar bu sorunu çözmenin yollarını araştırıyor; merkeziyetsizliği ve güvenliği sağlarken blok zincirinin işleme kapasitesini ve işlem hızını artırmak, yani ölçeklendirme sorununu çözmek, mevcut blok zinciri gelişim sürecinin en sıcak konularından biridir.
Blok zincirinin merkeziyetsizliği, güvenliği ve ölçeklenebilirliği tanımı:
Dağıtık: 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, dağıtıklaşma derecesi o kadar yüksek olur ve ağın az sayıda büyük merkezileşmiş katılımcı tarafından kontrol edilmesini engeller.
Güvenlik: Blok zinciri sisteminin kontrolünü elde etmek için harcanan maliyet ne kadar yüksekse, güvenlik o kadar yüksektir ve zincir, daha büyük oranda katılımcıların saldırılarına karşı dayanabilir.
Ölçeklenebilirlik: Blockchain'in büyük miktarda işlemi işleme kapasitesi.
Bitcoin ağının ilk büyük sert çatalı genişleme sorunundan kaynaklandı. Kullanıcı sayısı ve işlem hacmi arttıkça, her blok için 1MB'lık üst sınır olan Bitcoin ağı tıkanıklık sorunuyla karşılaşmaya başladı; 2015'te, Bitcoin topluluğu genişleme konusunda görüş ayrılıklarına sahipti, bir taraf blokların genişletilmesini destekleyen genişleme yanlıları, diğer taraf ise Segwit çözümünü destekleyen küçük blok yanlılarıydı. 1 Ağustos 2017'de, genişleme yanlıları 8MB'lık bir istemci sistemini kendileri geliştirerek çalıştırmaya başladı ve bu, Bitcoin tarihindeki ilk büyük sert çatalı doğurdu ve BCH adlı yeni bir kripto para birimi ortaya çıktı.
Ethereum ağı da güvenliği ve merkeziyetsizliği sağlamak için bir miktar ölçeklenebilirlikten vazgeçmeyi seçti. Ethereum ağı, Bitcoin ağının işlem hacmini sınırlamak için blok boyutunu kısıtladığı şekilde hareket etmemiştir; bunun yerine tek bir blokta kabul edilebilecek yakıt ücreti için bir üst sınır belirlenmiştir. Ancak amaç, güvensiz bir uzlaşı sağlamak ve düğümlerin geniş bir dağılımını güvence altına almaktır.
2017'deki CryptoKitties, DeFi yazı ve daha sonra GameFi ve NFT gibi zincir üzerindeki uygulamaların yükselişine kadar, piyasanın işlem hacmi talebi sürekli artıyor, ancak Turing tam olan Ethereum bile saniyede sadece 15-45 işlem (TPS) işleyebiliyor, bu da işlem maliyetlerinin sürekli artmasına, uzlaşma sürelerinin uzamasına neden oluyor, çoğu Dapp işletme maliyetini karşılamakta zorlanıyor, tüm ağ kullanıcılar için de hem yavaş hem de pahalı hale geliyor, blockchain ölçeklenebilirlik sorunu acil olarak çözülmesi gereken bir konu. İdeal ölçeklenebilirlik çözümü: merkeziyetsizlik ve güvenlikten ödün vermeden, mümkün olduğunca blockchain ağının işlem hızını ve işlem hacmini artırmaktır.
2. Ölçeklenebilirlik Çözüm Türleri
"Ana ağda bir katmanın değişip değişmeyeceği" standardına göre genişletme planlarını on-chain ve off-chain genişletme olarak iki ana kategoriye ayırıyoruz.
2.1 Zincir üstü genişleme
Temel kavram: Bir ana ağ protokolünü değiştirerek ölçeklenme etkisi yaratmak için bir çözüm; mevcut ana çözüm parçalama (sharding) yöntemidir.
Zincir üzerinde genişleme için çeşitli çözümler bulunmaktadır, bu makalede detaylara girmeyeceğim, kısaca iki çözümü sıralayacağım:
Plan bir, blok alanını genişletmektir, yani her bloğun paketlediği 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" seviyesini düşürecektir.
İkinci seçenek parçalama, blok zinciri defterini birkaç parçaya ayırmak, artık her düğümün tüm muhasebe işlemlerine katılmaması, bunun yerine farklı parçaların yani farklı düğümlerin farklı muhasebe işlemlerini üstlenmesi, paralel hesaplamanın aynı anda birden fazla işlemi işleyebilmesi; böylece düğümlerin hesaplama yükünü ve katılım eşiğini düşürmekte, işlem işleme hızını ve merkeziyetsizleşme düzeyini artırmaktadır; ancak bu, tüm ağın hesaplama gücünün dağılacağı anlamına gelir, bu da genel ağın "güvenliğini" azaltacaktır.
Bir ana ağ protokolünün kodunu değiştirmek, altta yatan 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ğ zorunlu olarak çatallanabilir veya kesintili bir onarım güncellemesine tabi tutulabilir. Örneğin, 2018'deki Zcash enflasyon açığı olayı: Zcash'in kodu Bitcoin 0.11.2 sürüm kodunun üzerinde değiştirilmiştir, 2018'de bir mühendis altta yatan kodda yüksek riskli bir açığın bulunduğunu fark etti, yani tokenlar sınırsız bir şekilde basılabilmekteydi, ardından ekip bu açığı gizlice düzeltmek için 8 ay harcadı, açık düzeltildikten sonra bu olayı kamuoyuna açıkladılar.
2.2 off-chain genişletme
Temel kavram: Mevcut birinci katman ana ağ protokolünü değiştirmeden ölçeklendirme çözümü.
off-chain ölçeklendirme çözümleri, Layer2 ve diğer çözümler olarak daha da alt kategorilere ayrılabilir:
3. off-chain genişleme planı
3.1 Eyalet Kanalları
3.1.1 Özet
Durum kanalları, kullanıcıların yalnızca kanal açıldığında, kapandığında veya anlaşmazlık çözüldüğünde ana ağ ile etkileşime girmesi gerektiğini belirtir ve kullanıcılar arası etkileşimi off-chain olarak gerçekleştirmeyi sağlar. Bu sayede kullanıcıların işlem süresi ve maliyetleri düşer ve işlem sayısı sınırsız hale gelir.
Durum kanalları, "tur bazlı uygulamalar" için uygun olan basit bir P2P protokolüdür, örneğin iki kişilik satranç oyunu. Her kanal, ana ağda çalışan çoklu imza akıllı sözleşmeleri tarafından yönetilmektedir; 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ı ( imzalı ve zaman damgalı dolandırıcılık kanıtına dayanarak tahkim eder. Katılımcılar, blok zinciri ağında sözleşmeyi dağıttıktan sonra bir miktar fon yatırır ve kilitler, her iki taraf imzalarıyla onayladıktan sonra, kanal resmi olarak açılır. Kanal, katılımcılar arasında sınırsız sayıda off-chain ücretsiz işlem yapmalarına olanak tanır ), tek şart, transfer net değerlerinin yatırılan token toplamını aşmamasıdır (. Katılımcılar sırayla birbirlerine durum güncellemeleri gönderir, diğerinin imza onayını beklerler. Diğer taraf imza onayını verdiğinde, bu durum güncellemesi tamamlanmış sayılır. Normalde, her iki tarafın onayladığı durum güncellemeleri ana ağa yüklenmez, sadece anlaşmazlık çıktığında veya kanal kapandığında ana ağa doğrulama için başvurulur. Kanalı kapatmak gerektiğinde, herhangi bir katılımcı ana ağda bir işlem talebi yapabilir, eğer çıkış talebi tüm katılımcıların ortak imzasıyla onaylanırsa, zincir üzerinde derhal 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 vermediyse, herkes kalan fonları almak için "mücadele süresi"nin bitmesini beklemek zorundadır.
Yukarıda belirtilenlere göre, durum kanalı çözümü ana ağ üzerindeki hesaplama yükünü büyük ölçüde azaltabilir, işlem hızını artırabilir ve işlem maliyetlerini düşürebilir.
)# 3.1.2 Zaman Çizgisi
2015/02, Joseph Poon ve Thaddeus Dryja, Lightning Network beyaz kağıdının taslağını yayınladılar.
2015/11, Jeff Coleman, State Channel kavramını sistematik olarak özetledi ve Bitcoin'in Payment Channel'ının State Channel kavramının bir alt örneği olduğunu öne 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 ağındaki transfer ödemelerini işlemek için Payment Channel### ödeme kanalı( çözümünü sundu.
2017/11, Payment Channel çerçevesine dayanan ilk State Channel tasarım standardı Sprites önerildi.
2018/06, Counterfactual, tamamen durum kanallarıyla ilgili olan ilk tasarım olan çok ayrıntılı bir Genelleşmiş Durum Kanalları tasarımını sundu.
2018/10, makale Genel Devlet Kanalı Ağları, Devlet Kanalı Ağları ve Sanal Kanallar kavramlarını ortaya koymuştur.
2019/02, durum kanalı kavramı N-Party Channels'a genişletildi, Nitro bu fikre dayalı 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 Prensip
Şekil 1, geleneksel zincir üzerindeki iş akışını göstermektedir: Alice ve Bob, ana ağda dağıtılmış olan akıllı sözleşmelerle etkileşimde bulunuyorlar, kullanıcılar akıllı sözleşmenin durumunu değiştirmek için zincire işlem gönderiyorlar. Dezavantajı, yukarıda tartışılan zaman ve maliyet sorunlarını beraberinde getirmesidir.
Şekil 2, çoğu durum kanalı protokolünün izlediği genel iş akışını göstermektedir: İyimser bir durumda, Alice ve Bob daha önceki işlemleri gerçekleştirmek zorundadır, ancak bu sefer durum kanalı kullanarak, zincir üstü sözleşmelerle etkileşimde bulunmak yerine.
İlk adım, Alice ve Bob, kişisel EOA'larından ) adresine 1,2( para yatırarak etkileşimde bulunurlar, bu fonlar sözleşmede kilitlenir ve yalnızca kanal kapandığında bakiyeler kullanıcılara geri döner; ikili imzalarını onayladıktan sonra, ikisi arasında durum kanalı resmi olarak açılır.
İkinci adım, Alice ve Bob bu kanal aracılığıyla teorik olarak off-chain sınırsız sayıda işlem yapabilirler ) mavi kesikli çizgi (, katılımcılar şifreli imzalı mesajlar aracılığıyla birbirleriyle iletişim kurar ), blok zincir ağı ile değil (. Her iki kullanıcı da her işlem için imza atmak zorundadır, böylece çift harcama dolandırıcılığını önleyebilirler. Bu mesajlar aracılığıyla, kendi hesaplarının durum güncellemelerini önerirler ve karşı tarafın önerdiği durum güncellemelerini kabul ederler.
Üçüncü adımda, eğer Alice Bob ile olan ticareti kapatmak istiyorsa, Alice sözleşmeye kendi hesabının nihai durumunu ) etkileşim 3( göndermelidir, eğer Bob imzalayıp onaylarsa, sözleşme nihai duruma göre kilitlenmiş olan fonları ilgili kullanıcıya geri bırakacaktır ) etkileşim 4,5(. Eğer Bob imzaya yanıt vermezse, sözleşme itiraz süresi sona erdikten sonra kilitlenmiş fonları ilgili kullanıcıya geri bırakacaktır.
Şekil 3, olumsuz bir durumda durum kanallarının iş akışını gösteriyor: İlk olarak, iki katılımcı ) etkileşim 1, 2( miktarında para yatırıyor, ardından durum güncellemelerini ) mavi kesikli çizgi ( değiş tokuş etmeye başlıyor. Varsayalım ki, bir noktada, Bob kendi turunda Alice'in gönderdiği durum güncellemesi imzasına ) etkileşim 3( yanıt vermezse, Alice en son geçerli durumunu sözleşmeye sunarak bir meydan okuma başlatabilir ) etkileşim 4(; bu geçerli durum, Bob'un önceki imzasını da içerir ve böylece son işlemin Bob'un onayını aldığını kanıtlar. Son durumda Bob'un onayı alınmıştır. Ardından sözleşme, Bob'a bir süre içinde sözleşmeye bir sonraki durumu sunarak yanıt verme olanağı tanır; eğer Bob yanıt verirse, iki kişi durum kanalında işlem yapmaya devam edebilir; eğer Bob bu süre içinde yanıt vermezse, sözleşme durum kanalını otomatik olarak kapatır ve parayı Alice'e geri gönderir ) etkileşim 5(.
Tüm katılımcıların sürekli çevrimiçi olması gerekiyor.
Karmaşık hesaplamalar için uygun değildir
Kanal kurmanın ön maliyeti yüksek
Ölçeklenebilirlik zayıf
Önceden kilitlenmiş fonların depozitosu gereklidir
3.1.5 Uygulama
Bitcoin Lightning Network
Özet:
Lightning Network, Bitcoin ağı için küçük ödemeler kanalıdır. Genel teknik evrimi: 2/2 çok imzalı tek yönlü ödeme kanalı inşası, RSMC###Revocable Sequence Maturity Contract( eklendikten sonra çift yönlü ödeme kanalı oluşturulması, ardından HTLC)Hash Time Lock Contract( eklendikten sonra ödeme kanallarının çoklu ödemelere genişletilmesi, sonunda ödeme ağı olan Lightning Network'ün inşası. Off-chain küçük ödeme kanalları aracılığıyla, ardından aracılar yardımıyla bir işlem ağı oluşturulması, Bitcoin ağı genişleme sorununu çözebilir. Lightning Network'ün genel kullanımı "depozit)kanal kurma(→Lightning Network işlemi)kanal durumunu güncelleme(→geri ödeme/hesap kapama)kanalı kapatma(" sürecini izler; teorik olarak Lightning Network saniyede bir milyon işlem gerçekleştirebilir.
Zaman çizgisi:
Şubat 2015'te, Joseph Poon ve Thaddeus Dryja, Lightning Network'ün beyaz kağıdının taslağını yayınladılar;
2016 yılında resmi beyaz kağıt yayınlandı ve Lightning Labs kuruldu;
15 Mart 2018'de, Lightning Labs ilk Lightning Network ana ağ sürümü Lightning Network Daemon )LND( 0.4 sürümünü yayınladı.
2021 yılının başında, Lightning Network'ün genel kapasitesi )TVL( sadece yaklaşık 40 milyon dolardı ve yaklaşık 100,000 kullanıcı Lightning Network'ü kullanıyordu.
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.
7 Likes
Reward
7
4
Share
Comment
0/400
PumpStrategist
· 11h ago
Yine eski tuzak Kutsal Olmayan Üçlü teknik açıdan hala bir atılım göstermedi.
View OriginalReply0
fork_in_the_road
· 11h ago
Büyütme işi hala devam ediyor.
View OriginalReply0
TokenTaxonomist
· 11h ago
istatistiksel olarak konuşursak, ölçeklendi̇rme çözümülerin %99.7'si trilemma optimizasyonunda başarısız olur...
Off-chain ölçekleme çözümleri derinlemesine analiz: State Channels ve Bitcoin Lightning Ağı
off-chain genişleme Derinlik analizi
Yazar: Cobo Ventures
1. Ölçeklenmenin Gerekliliği
Blok zincirinin gelecekteki vizyonu, merkeziyetsizlik, güvenlik ve ölçeklenebilirliktir; ancak genellikle bunlardan yalnızca ikisi gerçekleştirilebilir, bu da blok zincirinin imkânsız üçgen sorunu olarak adlandırılır. Yıllardır insanlar bu sorunu çözmenin yollarını araştırıyor; merkeziyetsizliği ve güvenliği sağlarken blok zincirinin işleme kapasitesini ve işlem hızını artırmak, yani ölçeklendirme sorununu çözmek, mevcut blok zinciri gelişim sürecinin en sıcak konularından biridir.
Blok zincirinin merkeziyetsizliği, güvenliği ve ölçeklenebilirliği tanımı:
Dağıtık: 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, dağıtıklaşma derecesi o kadar yüksek olur ve ağın az sayıda büyük merkezileşmiş katılımcı tarafından kontrol edilmesini engeller.
Güvenlik: Blok zinciri sisteminin kontrolünü elde etmek için harcanan maliyet ne kadar yüksekse, güvenlik o kadar yüksektir ve zincir, daha büyük oranda katılımcıların saldırılarına karşı dayanabilir.
Ölçeklenebilirlik: Blockchain'in büyük miktarda işlemi işleme kapasitesi.
Bitcoin ağının ilk büyük sert çatalı genişleme sorunundan kaynaklandı. Kullanıcı sayısı ve işlem hacmi arttıkça, her blok için 1MB'lık üst sınır olan Bitcoin ağı tıkanıklık sorunuyla karşılaşmaya başladı; 2015'te, Bitcoin topluluğu genişleme konusunda görüş ayrılıklarına sahipti, bir taraf blokların genişletilmesini destekleyen genişleme yanlıları, diğer taraf ise Segwit çözümünü destekleyen küçük blok yanlılarıydı. 1 Ağustos 2017'de, genişleme yanlıları 8MB'lık bir istemci sistemini kendileri geliştirerek çalıştırmaya başladı ve bu, Bitcoin tarihindeki ilk büyük sert çatalı doğurdu ve BCH adlı yeni bir kripto para birimi ortaya çıktı.
Ethereum ağı da güvenliği ve merkeziyetsizliği sağlamak için bir miktar ölçeklenebilirlikten vazgeçmeyi seçti. Ethereum ağı, Bitcoin ağının işlem hacmini sınırlamak için blok boyutunu kısıtladığı şekilde hareket etmemiştir; bunun yerine tek bir blokta kabul edilebilecek yakıt ücreti için bir üst sınır belirlenmiştir. Ancak amaç, güvensiz bir uzlaşı sağlamak ve düğümlerin geniş bir dağılımını güvence altına almaktır.
2017'deki CryptoKitties, DeFi yazı ve daha sonra GameFi ve NFT gibi zincir üzerindeki uygulamaların yükselişine kadar, piyasanın işlem hacmi talebi sürekli artıyor, ancak Turing tam olan Ethereum bile saniyede sadece 15-45 işlem (TPS) işleyebiliyor, bu da işlem maliyetlerinin sürekli artmasına, uzlaşma sürelerinin uzamasına neden oluyor, çoğu Dapp işletme maliyetini karşılamakta zorlanıyor, tüm ağ kullanıcılar için de hem yavaş hem de pahalı hale geliyor, blockchain ölçeklenebilirlik sorunu acil olarak çözülmesi gereken bir konu. İdeal ölçeklenebilirlik çözümü: merkeziyetsizlik ve güvenlikten ödün vermeden, mümkün olduğunca blockchain ağının işlem hızını ve işlem hacmini artırmaktır.
2. Ölçeklenebilirlik Çözüm Türleri
"Ana ağda bir katmanın değişip değişmeyeceği" standardına göre genişletme planlarını on-chain ve off-chain genişletme olarak iki ana kategoriye ayırıyoruz.
2.1 Zincir üstü genişleme
Temel kavram: Bir ana ağ protokolünü değiştirerek ölçeklenme etkisi yaratmak için bir çözüm; mevcut ana çözüm parçalama (sharding) yöntemidir.
Zincir üzerinde genişleme için çeşitli çözümler bulunmaktadır, bu makalede detaylara girmeyeceğim, kısaca iki çözümü sıralayacağım:
Plan bir, blok alanını genişletmektir, yani her bloğun paketlediği 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" seviyesini düşürecektir.
İkinci seçenek parçalama, blok zinciri defterini birkaç parçaya ayırmak, artık her düğümün tüm muhasebe işlemlerine katılmaması, bunun yerine farklı parçaların yani farklı düğümlerin farklı muhasebe işlemlerini üstlenmesi, paralel hesaplamanın aynı anda birden fazla işlemi işleyebilmesi; böylece düğümlerin hesaplama yükünü ve katılım eşiğini düşürmekte, işlem işleme hızını ve merkeziyetsizleşme düzeyini artırmaktadır; ancak bu, tüm ağın hesaplama gücünün dağılacağı anlamına gelir, bu da genel ağın "güvenliğini" azaltacaktır.
Bir ana ağ protokolünün kodunu değiştirmek, altta yatan 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ğ zorunlu olarak çatallanabilir veya kesintili bir onarım güncellemesine tabi tutulabilir. Örneğin, 2018'deki Zcash enflasyon açığı olayı: Zcash'in kodu Bitcoin 0.11.2 sürüm kodunun üzerinde değiştirilmiştir, 2018'de bir mühendis altta yatan kodda yüksek riskli bir açığın bulunduğunu fark etti, yani tokenlar sınırsız bir şekilde basılabilmekteydi, ardından ekip bu açığı gizlice düzeltmek için 8 ay harcadı, açık düzeltildikten sonra bu olayı kamuoyuna açıkladılar.
2.2 off-chain genişletme
Temel kavram: Mevcut birinci katman ana ağ protokolünü değiştirmeden ölçeklendirme çözümü.
off-chain ölçeklendirme çözümleri, Layer2 ve diğer çözümler olarak daha da alt kategorilere ayrılabilir:
3. off-chain genişleme planı
3.1 Eyalet Kanalları
3.1.1 Özet
Durum kanalları, kullanıcıların yalnızca kanal açıldığında, kapandığında veya anlaşmazlık çözüldüğünde ana ağ ile etkileşime girmesi gerektiğini belirtir ve kullanıcılar arası etkileşimi off-chain olarak gerçekleştirmeyi sağlar. Bu sayede kullanıcıların işlem süresi ve maliyetleri düşer ve işlem sayısı sınırsız hale gelir.
Durum kanalları, "tur bazlı uygulamalar" için uygun olan basit bir P2P protokolüdür, örneğin iki kişilik satranç oyunu. Her kanal, ana ağda çalışan çoklu imza akıllı sözleşmeleri tarafından yönetilmektedir; 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ı ( imzalı ve zaman damgalı dolandırıcılık kanıtına dayanarak tahkim eder. Katılımcılar, blok zinciri ağında sözleşmeyi dağıttıktan sonra bir miktar fon yatırır ve kilitler, her iki taraf imzalarıyla onayladıktan sonra, kanal resmi olarak açılır. Kanal, katılımcılar arasında sınırsız sayıda off-chain ücretsiz işlem yapmalarına olanak tanır ), tek şart, transfer net değerlerinin yatırılan token toplamını aşmamasıdır (. Katılımcılar sırayla birbirlerine durum güncellemeleri gönderir, diğerinin imza onayını beklerler. Diğer taraf imza onayını verdiğinde, bu durum güncellemesi tamamlanmış sayılır. Normalde, her iki tarafın onayladığı durum güncellemeleri ana ağa yüklenmez, sadece anlaşmazlık çıktığında veya kanal kapandığında ana ağa doğrulama için başvurulur. Kanalı kapatmak gerektiğinde, herhangi bir katılımcı ana ağda bir işlem talebi yapabilir, eğer çıkış talebi tüm katılımcıların ortak imzasıyla onaylanırsa, zincir üzerinde derhal 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 vermediyse, herkes kalan fonları almak için "mücadele süresi"nin bitmesini beklemek zorundadır.
Yukarıda belirtilenlere göre, durum kanalı çözümü ana ağ üzerindeki hesaplama yükünü büyük ölçüde azaltabilir, işlem hızını artırabilir ve işlem maliyetlerini düşürebilir.
)# 3.1.2 Zaman Çizgisi
2015/02, Joseph Poon ve Thaddeus Dryja, Lightning Network beyaz kağıdının taslağını yayınladılar.
2015/11, Jeff Coleman, State Channel kavramını sistematik olarak özetledi ve Bitcoin'in Payment Channel'ının State Channel kavramının bir alt örneği olduğunu öne 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 ağındaki transfer ödemelerini işlemek için Payment Channel### ödeme kanalı( çözümünü sundu.
2017/11, Payment Channel çerçevesine dayanan ilk State Channel tasarım standardı Sprites önerildi.
2018/06, Counterfactual, tamamen durum kanallarıyla ilgili olan ilk tasarım olan çok ayrıntılı bir Genelleşmiş Durum Kanalları tasarımını sundu.
2018/10, makale Genel Devlet Kanalı Ağları, Devlet Kanalı Ağları ve Sanal Kanallar kavramlarını ortaya koymuştur.
2019/02, durum kanalı kavramı N-Party Channels'a genişletildi, Nitro bu fikre dayalı 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 Prensip
Şekil 1, geleneksel zincir üzerindeki iş akışını göstermektedir: Alice ve Bob, ana ağda dağıtılmış olan akıllı sözleşmelerle etkileşimde bulunuyorlar, kullanıcılar akıllı sözleşmenin durumunu değiştirmek için zincire işlem gönderiyorlar. Dezavantajı, yukarıda tartışılan zaman ve maliyet sorunlarını beraberinde getirmesidir.
![Binlerce Derinlik Araştırması: Off-chain Ölçeklenmenin Kapsamlı Analizi]###https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.webp(
Şekil 2, çoğu durum kanalı protokolünün izlediği genel iş akışını göstermektedir: İyimser bir durumda, Alice ve Bob daha önceki işlemleri gerçekleştirmek zorundadır, ancak bu sefer durum kanalı kullanarak, zincir üstü sözleşmelerle etkileşimde bulunmak yerine.
İlk adım, Alice ve Bob, kişisel EOA'larından ) adresine 1,2( para yatırarak etkileşimde bulunurlar, bu fonlar sözleşmede kilitlenir ve yalnızca kanal kapandığında bakiyeler kullanıcılara geri döner; ikili imzalarını onayladıktan sonra, ikisi arasında durum kanalı resmi olarak açılır.
İkinci adım, Alice ve Bob bu kanal aracılığıyla teorik olarak off-chain sınırsız sayıda işlem yapabilirler ) mavi kesikli çizgi (, katılımcılar şifreli imzalı mesajlar aracılığıyla birbirleriyle iletişim kurar ), blok zincir ağı ile değil (. Her iki kullanıcı da her işlem için imza atmak zorundadır, böylece çift harcama dolandırıcılığını önleyebilirler. Bu mesajlar aracılığıyla, kendi hesaplarının durum güncellemelerini önerirler ve karşı tarafın önerdiği durum güncellemelerini kabul ederler.
Üçüncü adımda, eğer Alice Bob ile olan ticareti kapatmak istiyorsa, Alice sözleşmeye kendi hesabının nihai durumunu ) etkileşim 3( göndermelidir, eğer Bob imzalayıp onaylarsa, sözleşme nihai duruma göre kilitlenmiş olan fonları ilgili kullanıcıya geri bırakacaktır ) etkileşim 4,5(. Eğer Bob imzaya yanıt vermezse, sözleşme itiraz süresi sona erdikten sonra kilitlenmiş fonları ilgili kullanıcıya geri bırakacaktır.
![Milyon kelimelik Derinlik raporu: Off-chain ölçeklendirmesinin kapsamlı analizi])https://img-cdn.gateio.im/webp-social/moments-ad088ac016d75b1ae0b0eda699e74709.webp(
Şekil 3, olumsuz bir durumda durum kanallarının iş akışını gösteriyor: İlk olarak, iki katılımcı ) etkileşim 1, 2( miktarında para yatırıyor, ardından durum güncellemelerini ) mavi kesikli çizgi ( değiş tokuş etmeye başlıyor. Varsayalım ki, bir noktada, Bob kendi turunda Alice'in gönderdiği durum güncellemesi imzasına ) etkileşim 3( yanıt vermezse, Alice en son geçerli durumunu sözleşmeye sunarak bir meydan okuma başlatabilir ) etkileşim 4(; bu geçerli durum, Bob'un önceki imzasını da içerir ve böylece son işlemin Bob'un onayını aldığını kanıtlar. Son durumda Bob'un onayı alınmıştır. Ardından sözleşme, Bob'a bir süre içinde sözleşmeye bir sonraki durumu sunarak yanıt verme olanağı tanır; eğer Bob yanıt verirse, iki kişi durum kanalında işlem yapmaya devam edebilir; eğer Bob bu süre içinde yanıt vermezse, sözleşme durum kanalını otomatik olarak kapatır ve parayı Alice'e geri gönderir ) etkileşim 5(.
![Binlerce Kelimelik Derinlik Raporu: Off-Chain Ölçeklenmenin Kapsamlı Analizi])https://img-cdn.gateio.im/webp-social/moments-815c5eb2bdba725e04eebe67b22d42aa.webp(
)# 3.1.4 Artıları ve Eksileri
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: 2/2 çok imzalı tek yönlü ödeme kanalı inşası, RSMC###Revocable Sequence Maturity Contract( eklendikten sonra çift yönlü ödeme kanalı oluşturulması, ardından HTLC)Hash Time Lock Contract( eklendikten sonra ödeme kanallarının çoklu ödemelere genişletilmesi, sonunda ödeme ağı olan Lightning Network'ün inşası. Off-chain küçük ödeme kanalları aracılığıyla, ardından aracılar yardımıyla bir işlem ağı oluşturulması, Bitcoin ağı genişleme sorununu çözebilir. Lightning Network'ün genel kullanımı "depozit)kanal kurma(→Lightning Network işlemi)kanal durumunu güncelleme(→geri ödeme/hesap kapama)kanalı kapatma(" sürecini izler; teorik olarak Lightning Network saniyede bir milyon işlem gerçekleştirebilir.
Zaman çizgisi: