Blockchain'ın gelecekteki vizyonu merkeziyetsizlik, güvenlik ve ölçeklenebilirliktir, ancak genellikle bunlardan yalnızca ikisi gerçekleştirilebilmektedir; bu, blockchain'in imkansız üçgen problemi olarak adlandırılmaktadır. Yıllardır insanlar bu sorunu çözmenin yollarını araştırıyor; merkeziyetsizliği ve güvenliği sağlarken blockchain'in işlem hacmini ve işlem hızını artırmak, yani ölçeklendirme sorununu çözmek, günümüzde blockchain gelişim sürecinin en sıcak konularından biridir.
Blok zincirinin merkeziyetsizliği, güvenliği ve ölçeklenebilirliği aşağıdaki gibi tanımlanır:
Merkeziyetsizlik: Herkes, blok zinciri sisteminin üretimi ve doğrulamasına katılmak için bir düğüm olabilir; düğüm sayısı ne kadar fazla olursa, merkeziyetsizlik seviyesi o kadar yüksek olur ve ağın merkezi katılımcılar tarafından kontrol edilmesini sağlar.
Güvenlik: Bir blockchain sisteminin kontrolünü ele geçirmek için gereken maliyet ne kadar yüksekse, güvenlik o kadar yüksektir; zincir, daha büyük bir katılımcı oranının saldırılarına karşı dayanabilir.
Ölçeklenebilirlik: Blok zincirinin büyük miktarda işlemi işleme kapasitesi.
Bitcoin ağı üzerindeki ilk büyük hard fork, ölçeklenebilirlik sorunlarından kaynaklandı. Kullanıcı sayısı ve işlem hacmi arttıkça, her blok için maksimum 1MB olan Bitcoin ağı tıkanma sorunlarıyla karşı karşıya kalmaya başladı. 2015'te, Bitcoin topluluğu ölçeklenebilirlik konusunda bölünmeye başladı; bir taraf blok boyutunun artırılmasını desteklerken, diğer taraf ana zincir yapısını optimize etmek için SegWit çözümünün kullanılmasını savundu. 1 Ağustos 2017'de, Bitcoin ABC, 8MB blok boyutuna sahip bir istemci sistemini geliştirmeye başladı ve bu, Bitcoin'in ilk büyük hard fork'una neden oldu ve bu durum yeni bir kripto para birimi olan BCH'yi doğurdu.
Ethereum ağı, ağın güvenliğini ve merkeziyetsizliğini sağlamak için bir miktar ölçeklenebilirlikten vazgeçmeyi de tercih etmiştir. Bitcoin gibi blok boyutunu sınırlamasa da, tek bir blokta yer alabilecek yakıt ücretlerini sınırlayarak işlem hacmini kısıtlamaktadır. Bu, Trustless Consensus'u gerçekleştirmek ve düğümlerin geniş bir dağılımını sağlamak amacıyla yapılmaktadır.
2017'deki CryptoKitties'den, DeFi yazına, ardından GameFi ve NFT gibi zincir üstü uygulamaların yükselişine kadar, piyasanın işlem hacmi talebi sürekli artmaktadır. Ancak, Turing tam olan Ethereum bile saniyede yalnızca 15-45 işlem gerçekleştirebilmektedir, bu da işlem maliyetlerini artırmakta, uzlaşma sürelerini uzatmakta ve çoğu Dapp'in işletme maliyetlerini karşılamasını zorlaştırmaktadır, bu nedenle tüm ağ kullanıcılar için hem yavaş hem de pahalı hale gelmektedir. Blok zinciri ölçeklenebilirlik sorunu acilen çözülmelidir. İdeal ölçeklenebilirlik çözümü, merkeziyetsizliği ve güvenliği feda etmeden, blok zinciri ağının işlem hızını ve derinliğini mümkün olduğunca artırmaktır.
2. Ölçeklenebilirlik Planlarının Türleri
"Ana ağda bir katman değişip değişmeyeceğine" göre, ölçeklendirme çözümleri on-chain ve off-chain olmak üzere iki ana kategoriye ayrılabilir.
2.1 zincir üzerinde genişleme
Temel kavram: Bir ana ağ protokolünün bir katmanını değiştirerek ölçeklenme etkisi elde etme çözümü, mevcut ana çözüm parçalama (sharding) yöntemidir.
Zincir üzerindeki genişleme için çeşitli çözümler bulunmaktadır, iki tanesini kısaca listeleyelim:
Seçenek 1, blok alanını genişletmek, her bloğun paketlediği işlem sayısını artırmaktır, ancak bu, yüksek performanslı düğüm cihazlarına olan talepleri artıracak ve "merkeziyetsizlik" derecesini azaltacaktır.
İkinci seçenek parçalama, blok zinciri defterini birkaç parçaya ayırmak, farklı düğümlerin farklı muhasebe işlemlerini yürütmesini sağlamak ve paralel hesaplama ile birden fazla işlemi aynı anda işlemek. 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 seviyesini artırabilir, ancak tüm ağın "güvenliğini" azaltabilir.
Ana ağ protokolünün kodunu değiştirmek, temelindeki herhangi bir küçük güvenlik açığının tüm ağın güvenliğini ciddi şekilde tehdit edebileceği için tahmin edilemeyen olumsuz etkilere yol açabilir; ağ, bir çatallanmaya veya kesintili bir düzeltme güncellemesine zorlanabilir. Örneğin, 2018'de Zcash'ın enflasyon açığı olayı: Zcash'ın kodu Bitcoin 0.11.2 sürüm kodunun değiştirilmiş haline dayanıyordu, 2018'de bir mühendis, temel kodda yüksek riskli bir açığın bulunduğunu keşfetti, yani token'lar sınırsız bir şekilde basılabiliyordu; ekip, açığı gizlice düzeltmek için 8 ay harcadı ve açığın düzeltilmesinin ardından bu olayı kamuya açıkladı.
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çekleme çözümleri Layer2 ve diğer çözümlere ayrılabilir:
Layer2: Ana zincirin üzerinde yeni katmanlar inşa etmek, çoğu işlemi ve hesaplamayı işlemek, yalnızca gerektiğinde ana zincirle etkileşimde bulunmak. Durum kanalları, yan zincirler, Plasma, Rollups vb. dahil.
Diğer çözümler: Yeni bir katman inşa etmek yerine, Validium, Volition gibi diğer teknik yöntemlerle ölçeklenebilirlik sağlamak.
3. off-chain ölçeklendirme çözümü
3.1 Eyalet Kanalları
3.1.1 Özet
Durum kanalı, 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 belirtir. Kullanıcılar arasındaki etkileşimleri off-chain gerçekleştirmek, işlem süresi ve maliyetlerini düşürmek ve işlem sayısını sınırlamadan gerçekleştirmek için yapılmaktadır.
Durum kanalları, "tur bazlı uygulamalar" için uygun olan basit P2P protokolleridir, örneğin iki kişilik satranç oyunu. Her kanal, ana ağda çalışan çoklu imza akıllı sözleşmeler 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ıtlarına dayanarak arabuluculuk yapar (. 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ın imzasıyla onaylandı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 yapılmasına olanak tanır ), sadece transfer net değerleri yatırılan toplam token miktarını aşmadığı sürece (. Katılımcılar sırayla birbirlerine durum güncellemeleri gönderir ve karşı tarafın imzasını beklerler. Karşı taraf imzasını onayladığında, bu durum güncellemesi tamamlanmış sayılır. Normal şartlar altında, her iki tarafın üzerinde anlaştığı durum güncellemeleri ana ağa yüklenmez; yalnızca bir anlaşmazlık çıktığında veya kanal kapatıldığında ana ağ onayına güvenilir. Kanalı kapatmak gerektiğinde, herhangi bir katılımcı ana ağda işlem talebi yapabilir; eğer çıkış talebi tüm tarafların onay imzasını alırsa, zincir üzerinde hemen uygulanır; 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 imzalı onay vermezse, herkes "meydan okuma süresi"nin sonunu beklemek zorundadır, böylece kalan fonları alabilirler.
Sonuç olarak, durum kanalı çözümü ana ağ üzerindeki hesaplama yükünü önemli ö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ı taslağını yayınladı.
2015/11, Jeff Coleman, State Channel kavramını sistematik olarak ilk kez özetlemiş ve Bitcoin'in Payment Channel'ının State Channel kavramının bir alt örneği olduğunu önermiştir.
2016/01, Joseph Poon ve Thaddeus Dryja, Bitcoin Lightning Network: Scalable Off-Chain Instant Payments adlı beyaz kitaplarını yayımlayarak Bitcoin Lightning Network'ün genişleme çözümü olan Payment Channel### ödeme kanalı('ı önerdiler; 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, tamamen durum kanallarıyla ilgili ilk tasarımı olan çok ayrıntılı bir Genelleşmiş Durum Kanalları tasarımı sundu.
2018/10, Generalised State Channel Networks makalesi State Channel Networks ve Virtual Channels kavramlarını önerdi.
2019/02, durum kanalı kavramı N-Party Channels'a genişletildi, Nitro bu fikre dayanan ilk protokoldür.
2019/10,Pisa, tüm katılımcıların sürekli çevrimiçi olması gerektiği 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ış akıllı sözleşmelerle etkileşimde bulunur, kullanıcılar akıllı sözleşmenin durumunu değiştirmek için zincire işlem gönderir. Dezavantajı, yukarıda tartışılan zaman ve maliyet sorunlarını gündeme getirmesidir.
![Bin kelime derinlik raporu: Zincir dışı genişlemenin kapsamlı analizi]###https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.webp(
Şekil 2, çoğu durum kanalı protokolünün takip ettiği genel iş akışını göstermektedir: İyimser durumda, Alice ve Bob daha öncekiyle aynı işlemi gerçekleştirmeleri gerekmektedir, ancak bu sefer durum kanalı kullanarak, zincir üstü sözleşmelerle etkileşime girmeden.
İlk adım, Alice ve Bob'un kişisel EOA'larından ) adresine fon yatırarak etkileşime girmesidir; bu işlemde 1,2(, bu fonlar sözleşmede kilitlenir ve kanal kapandığında bakiyeler kullanıcıya geri döner; her iki taraf imza onayladıktan sonra, ikisi arasındaki durum kanalı resmen 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 gerçekleştirebilirler ) mavi kesik çizgi (, katılımcılar şifreli imzalı mesajlar aracılığıyla birbirleriyle iletişim kurarlar ), blockchain ağıyla 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ı önlerler. Bu mesajlar aracılığıyla, hesaplarının durum güncellemelerini önerirler ve karşı tarafın sunduğu durum güncellemelerini kabul ederler.
Üçüncü adım, eğer Alice kanalı kapatıp Bob ile olan işlemi sonlandırmak 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ş fonları ilgili kullanıcıya iade edecektir ) 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 iade edecektir.
Şekil 3, olumsuz bir durumda durum kanalının çalışma akışını göstermektedir: İlk olarak, iki katılımcı ) etkileşim 1, 2( miktarını yatırır, ardından durum güncellemelerini ) mavi kesik çizgi ( değiştirmeye başlar. Diyelim ki bir noktada, Bob kendi turunda Alice'in gönderdiği durum güncelleme imzasına ) etkileşim 3( yanıt vermez, bu noktada Alice, sözleşmeye en son geçerli durumunu göndererek bir meydan okuma başlatabilir ) etkileşim 4(, bu geçerli durum ayrıca Bob'un önceki imzasını içerir, böylece son işlemin Bob'un onayını aldığı ve son durumun Bob'un onayını aldığı kanıtlanır. Ardından, sözleşme, Bob'un bir süre içinde sözleşmeye bir sonraki durumu göndererek yanıt vermesine izin verir; Eğer Bob yanıt verirse, ikili durum kanalında işlem yapmaya devam edebilir; Bob bu süre zarfında yanıt vermezse, sözleşme otomatik olarak durum kanalını kapatır ve fonları Alice'e geri gönderir ) etkileşim 5(.
![Binlerce kelimelik Derinlik Raporu: Off-chain ölçeklendirmeyi kapsamlı bir şekilde analiz etme])https://img-cdn.gateio.im/webp-social/moments-815c5eb2bdba725e04eebe67b22d42aa.webp(
)# 3.1.4 Artıları ve Eksileri
Avantajlar:
Anlık işlem onayı
Yüksek İşlem Hacmi
Düşük işlem maliyeti
İyi gizlilik
Eksiler:
Fonları kilitlemek gerekiyor
Tüm katılımcıların çevrimiçi olması gerekiyor
Çekim gecikmesi var
Kanal başlatma maliyeti yüksek
Yeniden kanal açmak sorun
Kanal ağının karmaşıklığı yüksek
3.1.5 Uygulama
Bitcoin Lightning Network
Genel Bakış:
Lightning Network, Bitcoin ağı için bir mikro ödeme kanalıdır. Genel teknoloji evrimi, 2/2 çoklu imza ile tek yönlü ödeme kanalı oluşturma, RSMC###Revocable Sequence Maturity Contract( eklenmesiyle çift yönlü ödeme kanalı oluşturma, ardından HTLC)Hash Time Lock Contract( eklenmesiyle ödeme kanallarını çoklu ödemelere genişletme sürecinden geçmiştir ve nihayetinde ödeme ağı, yani Lightning Network oluşturulmuştur. Off-chain mikro ödeme kanalları aracılığıyla, aracıların yardımıyla bir ticaret ağı oluşturularak Bitcoin ağının genişleme sorunu çözülebilir. Lightning Network'ün genel kullanımı, "depozito)kanal oluşturma(→Lightning Network işlemi)kanal durumunu güncelleme(→geri ödeme/hesaplama)kanalı kapatma(" akışını 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 beyaz kağıdının taslağını yayınladılar;
2016 yılının 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ü Lightning Network Daemon )LND( 0.4 sürümünü yayınladı.
2021 yılının başında, Lightning Network'ün kamu kapasitesi ) TVL ( yalnızca yaklaşık 40 milyon dolardı ve yaklaşık 100 bin kullanıcı Lightning Network'ü kullanıyordu.
2021 Haziran'ında, El Salvador Bitcoin'i yasal para birimi olarak kabul etti,
View Original
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.
Off-chain genişletme çözümü analizi: iletim kanalı teknolojisi prensipleri ve uygulamaları
Off-chain ölçeklendirme derinlik analizi
1. Genişlemenin Gerekliliği
Blockchain'ın gelecekteki vizyonu merkeziyetsizlik, güvenlik ve ölçeklenebilirliktir, ancak genellikle bunlardan yalnızca ikisi gerçekleştirilebilmektedir; bu, blockchain'in imkansız üçgen problemi olarak adlandırılmaktadır. Yıllardır insanlar bu sorunu çözmenin yollarını araştırıyor; merkeziyetsizliği ve güvenliği sağlarken blockchain'in işlem hacmini ve işlem hızını artırmak, yani ölçeklendirme sorununu çözmek, günümüzde blockchain gelişim sürecinin en sıcak konularından biridir.
Blok zincirinin merkeziyetsizliği, güvenliği ve ölçeklenebilirliği aşağıdaki gibi tanımlanır:
Merkeziyetsizlik: Herkes, blok zinciri sisteminin üretimi ve doğrulamasına katılmak için bir düğüm olabilir; düğüm sayısı ne kadar fazla olursa, merkeziyetsizlik seviyesi o kadar yüksek olur ve ağın merkezi katılımcılar tarafından kontrol edilmesini sağlar.
Güvenlik: Bir blockchain sisteminin kontrolünü ele geçirmek için gereken maliyet ne kadar yüksekse, güvenlik o kadar yüksektir; zincir, daha büyük bir katılımcı oranının saldırılarına karşı dayanabilir.
Ölçeklenebilirlik: Blok zincirinin büyük miktarda işlemi işleme kapasitesi.
Bitcoin ağı üzerindeki ilk büyük hard fork, ölçeklenebilirlik sorunlarından kaynaklandı. Kullanıcı sayısı ve işlem hacmi arttıkça, her blok için maksimum 1MB olan Bitcoin ağı tıkanma sorunlarıyla karşı karşıya kalmaya başladı. 2015'te, Bitcoin topluluğu ölçeklenebilirlik konusunda bölünmeye başladı; bir taraf blok boyutunun artırılmasını desteklerken, diğer taraf ana zincir yapısını optimize etmek için SegWit çözümünün kullanılmasını savundu. 1 Ağustos 2017'de, Bitcoin ABC, 8MB blok boyutuna sahip bir istemci sistemini geliştirmeye başladı ve bu, Bitcoin'in ilk büyük hard fork'una neden oldu ve bu durum yeni bir kripto para birimi olan BCH'yi doğurdu.
Ethereum ağı, ağın güvenliğini ve merkeziyetsizliğini sağlamak için bir miktar ölçeklenebilirlikten vazgeçmeyi de tercih etmiştir. Bitcoin gibi blok boyutunu sınırlamasa da, tek bir blokta yer alabilecek yakıt ücretlerini sınırlayarak işlem hacmini kısıtlamaktadır. Bu, Trustless Consensus'u gerçekleştirmek ve düğümlerin geniş bir dağılımını sağlamak amacıyla yapılmaktadır.
2017'deki CryptoKitties'den, DeFi yazına, ardından GameFi ve NFT gibi zincir üstü uygulamaların yükselişine kadar, piyasanın işlem hacmi talebi sürekli artmaktadır. Ancak, Turing tam olan Ethereum bile saniyede yalnızca 15-45 işlem gerçekleştirebilmektedir, bu da işlem maliyetlerini artırmakta, uzlaşma sürelerini uzatmakta ve çoğu Dapp'in işletme maliyetlerini karşılamasını zorlaştırmaktadır, bu nedenle tüm ağ kullanıcılar için hem yavaş hem de pahalı hale gelmektedir. Blok zinciri ölçeklenebilirlik sorunu acilen çözülmelidir. İdeal ölçeklenebilirlik çözümü, merkeziyetsizliği ve güvenliği feda etmeden, blok zinciri ağının işlem hızını ve derinliğini mümkün olduğunca artırmaktır.
2. Ölçeklenebilirlik Planlarının Türleri
"Ana ağda bir katman değişip değişmeyeceğine" göre, ölçeklendirme çözümleri on-chain ve off-chain olmak üzere iki ana kategoriye ayrılabilir.
2.1 zincir üzerinde genişleme
Temel kavram: Bir ana ağ protokolünün bir katmanını değiştirerek ölçeklenme etkisi elde etme çözümü, mevcut ana çözüm parçalama (sharding) yöntemidir.
Zincir üzerindeki genişleme için çeşitli çözümler bulunmaktadır, iki tanesini kısaca listeleyelim:
Seçenek 1, blok alanını genişletmek, her bloğun paketlediği işlem sayısını artırmaktır, ancak bu, yüksek performanslı düğüm cihazlarına olan talepleri artıracak ve "merkeziyetsizlik" derecesini azaltacaktır.
İkinci seçenek parçalama, blok zinciri defterini birkaç parçaya ayırmak, farklı düğümlerin farklı muhasebe işlemlerini yürütmesini sağlamak ve paralel hesaplama ile birden fazla işlemi aynı anda işlemek. 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 seviyesini artırabilir, ancak tüm ağın "güvenliğini" azaltabilir.
Ana ağ protokolünün kodunu değiştirmek, temelindeki herhangi bir küçük güvenlik açığının tüm ağın güvenliğini ciddi şekilde tehdit edebileceği için tahmin edilemeyen olumsuz etkilere yol açabilir; ağ, bir çatallanmaya veya kesintili bir düzeltme güncellemesine zorlanabilir. Örneğin, 2018'de Zcash'ın enflasyon açığı olayı: Zcash'ın kodu Bitcoin 0.11.2 sürüm kodunun değiştirilmiş haline dayanıyordu, 2018'de bir mühendis, temel kodda yüksek riskli bir açığın bulunduğunu keşfetti, yani token'lar sınırsız bir şekilde basılabiliyordu; ekip, açığı gizlice düzeltmek için 8 ay harcadı ve açığın düzeltilmesinin ardından bu olayı kamuya açıkladı.
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çekleme çözümleri Layer2 ve diğer çözümlere ayrılabilir:
Layer2: Ana zincirin üzerinde yeni katmanlar inşa etmek, çoğu işlemi ve hesaplamayı işlemek, yalnızca gerektiğinde ana zincirle etkileşimde bulunmak. Durum kanalları, yan zincirler, Plasma, Rollups vb. dahil.
Diğer çözümler: Yeni bir katman inşa etmek yerine, Validium, Volition gibi diğer teknik yöntemlerle ölçeklenebilirlik sağlamak.
3. off-chain ölçeklendirme çözümü
3.1 Eyalet Kanalları
3.1.1 Özet
Durum kanalı, 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 belirtir. Kullanıcılar arasındaki etkileşimleri off-chain gerçekleştirmek, işlem süresi ve maliyetlerini düşürmek ve işlem sayısını sınırlamadan gerçekleştirmek için yapılmaktadır.
Durum kanalları, "tur bazlı uygulamalar" için uygun olan basit P2P protokolleridir, örneğin iki kişilik satranç oyunu. Her kanal, ana ağda çalışan çoklu imza akıllı sözleşmeler 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ıtlarına dayanarak arabuluculuk yapar (. 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ın imzasıyla onaylandı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 yapılmasına olanak tanır ), sadece transfer net değerleri yatırılan toplam token miktarını aşmadığı sürece (. Katılımcılar sırayla birbirlerine durum güncellemeleri gönderir ve karşı tarafın imzasını beklerler. Karşı taraf imzasını onayladığında, bu durum güncellemesi tamamlanmış sayılır. Normal şartlar altında, her iki tarafın üzerinde anlaştığı durum güncellemeleri ana ağa yüklenmez; yalnızca bir anlaşmazlık çıktığında veya kanal kapatıldığında ana ağ onayına güvenilir. Kanalı kapatmak gerektiğinde, herhangi bir katılımcı ana ağda işlem talebi yapabilir; eğer çıkış talebi tüm tarafların onay imzasını alırsa, zincir üzerinde hemen uygulanır; 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 imzalı onay vermezse, herkes "meydan okuma süresi"nin sonunu beklemek zorundadır, böylece kalan fonları alabilirler.
Sonuç olarak, durum kanalı çözümü ana ağ üzerindeki hesaplama yükünü önemli ö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ı taslağını yayınladı.
2015/11, Jeff Coleman, State Channel kavramını sistematik olarak ilk kez özetlemiş ve Bitcoin'in Payment Channel'ının State Channel kavramının bir alt örneği olduğunu önermiştir.
2016/01, Joseph Poon ve Thaddeus Dryja, Bitcoin Lightning Network: Scalable Off-Chain Instant Payments adlı beyaz kitaplarını yayımlayarak Bitcoin Lightning Network'ün genişleme çözümü olan Payment Channel### ödeme kanalı('ı önerdiler; 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, tamamen durum kanallarıyla ilgili ilk tasarımı olan çok ayrıntılı bir Genelleşmiş Durum Kanalları tasarımı sundu.
2018/10, Generalised State Channel Networks makalesi State Channel Networks ve Virtual Channels kavramlarını önerdi.
2019/02, durum kanalı kavramı N-Party Channels'a genişletildi, Nitro bu fikre dayanan ilk protokoldür.
2019/10,Pisa, tüm katılımcıların sürekli çevrimiçi olması gerektiği 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ış akıllı sözleşmelerle etkileşimde bulunur, kullanıcılar akıllı sözleşmenin durumunu değiştirmek için zincire işlem gönderir. Dezavantajı, yukarıda tartışılan zaman ve maliyet sorunlarını gündeme getirmesidir.
![Bin kelime derinlik raporu: Zincir dışı genişlemenin kapsamlı analizi]###https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.webp(
Şekil 2, çoğu durum kanalı protokolünün takip ettiği genel iş akışını göstermektedir: İyimser durumda, Alice ve Bob daha öncekiyle aynı işlemi gerçekleştirmeleri gerekmektedir, ancak bu sefer durum kanalı kullanarak, zincir üstü sözleşmelerle etkileşime girmeden.
İlk adım, Alice ve Bob'un kişisel EOA'larından ) adresine fon yatırarak etkileşime girmesidir; bu işlemde 1,2(, bu fonlar sözleşmede kilitlenir ve kanal kapandığında bakiyeler kullanıcıya geri döner; her iki taraf imza onayladıktan sonra, ikisi arasındaki durum kanalı resmen 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 gerçekleştirebilirler ) mavi kesik çizgi (, katılımcılar şifreli imzalı mesajlar aracılığıyla birbirleriyle iletişim kurarlar ), blockchain ağıyla 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ı önlerler. Bu mesajlar aracılığıyla, hesaplarının durum güncellemelerini önerirler ve karşı tarafın sunduğu durum güncellemelerini kabul ederler.
Üçüncü adım, eğer Alice kanalı kapatıp Bob ile olan işlemi sonlandırmak 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ş fonları ilgili kullanıcıya iade edecektir ) 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 iade edecektir.
![Binlerce Derinlik Raporu: Off-chain Ölçeklenmenin Kapsamlı Analizi])https://img-cdn.gateio.im/webp-social/moments-ad088ac016d75b1ae0b0eda699e74709.webp(
Şekil 3, olumsuz bir durumda durum kanalının çalışma akışını göstermektedir: İlk olarak, iki katılımcı ) etkileşim 1, 2( miktarını yatırır, ardından durum güncellemelerini ) mavi kesik çizgi ( değiştirmeye başlar. Diyelim ki bir noktada, Bob kendi turunda Alice'in gönderdiği durum güncelleme imzasına ) etkileşim 3( yanıt vermez, bu noktada Alice, sözleşmeye en son geçerli durumunu göndererek bir meydan okuma başlatabilir ) etkileşim 4(, bu geçerli durum ayrıca Bob'un önceki imzasını içerir, böylece son işlemin Bob'un onayını aldığı ve son durumun Bob'un onayını aldığı kanıtlanır. Ardından, sözleşme, Bob'un bir süre içinde sözleşmeye bir sonraki durumu göndererek yanıt vermesine izin verir; Eğer Bob yanıt verirse, ikili durum kanalında işlem yapmaya devam edebilir; Bob bu süre zarfında yanıt vermezse, sözleşme otomatik olarak durum kanalını kapatır ve fonları Alice'e geri gönderir ) etkileşim 5(.
![Binlerce kelimelik Derinlik Raporu: Off-chain ölçeklendirmeyi kapsamlı bir şekilde analiz etme])https://img-cdn.gateio.im/webp-social/moments-815c5eb2bdba725e04eebe67b22d42aa.webp(
)# 3.1.4 Artıları ve Eksileri
Avantajlar:
Eksiler:
3.1.5 Uygulama
Bitcoin Lightning Network
Genel Bakış: Lightning Network, Bitcoin ağı için bir mikro ödeme kanalıdır. Genel teknoloji evrimi, 2/2 çoklu imza ile tek yönlü ödeme kanalı oluşturma, RSMC###Revocable Sequence Maturity Contract( eklenmesiyle çift yönlü ödeme kanalı oluşturma, ardından HTLC)Hash Time Lock Contract( eklenmesiyle ödeme kanallarını çoklu ödemelere genişletme sürecinden geçmiştir ve nihayetinde ödeme ağı, yani Lightning Network oluşturulmuştur. Off-chain mikro ödeme kanalları aracılığıyla, aracıların yardımıyla bir ticaret ağı oluşturularak Bitcoin ağının genişleme sorunu çözülebilir. Lightning Network'ün genel kullanımı, "depozito)kanal oluşturma(→Lightning Network işlemi)kanal durumunu güncelleme(→geri ödeme/hesaplama)kanalı kapatma(" akışını izler; teorik olarak Lightning Network, saniyede bir milyon işlem gerçekleştirebilir.
Zaman çizgisi: