Yazarlar: Ellaine Xu, Hettie Jiang, June Wang, Walon Lin, Yiliu Lin
1. Kapasite Artışının Gerekliliği
Blok zincirinin geleceği büyük bir vizyondur: merkeziyetsizlik, güvenlik ve ölçeklenebilirlik; ancak genellikle blok zinciri yalnızca bunlardan ikisini gerçekleştirebilir, bu üç gereksinimi aynı anda karşılamak blok zincirinin imkansız üçgen problemi olarak adlandırılır. Yıllar boyunca, bu sorunu nasıl çözeceğimizi, merkeziyetsizlik ve güvenliği sağlarken blok zincirinin işlem hacmini ve işlem hızını nasıl artıracağımızı araştırıyoruz; yani ölçeklenebilirlik sorununu çözmek, günümüzde blok zinciri 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:
Merkeziyetsizlik: Herkes blockchain sisteminin üretim ve doğrulamasına katılmak için bir düğüm olabilir. Düğüm sayısı arttıkça, merkeziyetsizlik derecesi de artar ve böylece ağın küçük bir grup büyük merkezi katılımcının kontrolü altında olmaması sağlanır.
Güvenlik: Bir blockchain sisteminin kontrolünü ele geçirmek için harcanan maliyet ne kadar yüksekse, güvenlik o kadar yüksektir, böylece zincir, katılımcıların büyük bir oranının saldırısına karşı direnç gösterebilir.
Ö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çeklenebilirlik sorunlarından kaynaklanmıştır. Bitcoin 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şlamıştır; 2015 yılından itibaren, Bitcoin topluluğunda ölçeklenebilirlik konusunda anlaşmazlıklar ortaya çıkmıştır. Bir tarafta, blokların genişletilmesini destekleyen Bitcoin ABC temsilcileri olan genişletme yanlıları, diğer tarafta ise Segwit çözümü ile ana zincir yapısını optimize edilmesi gerektiğini savunan Bitcoin Core temsilcileri olan küçük blok yanlıları bulunmaktadır. 1 Ağustos 2017'de, Bitcoin ABC tarafından 8MB'ye kadar geliştirilmiş istemci sistemi çalışmaya başlamış ve bu durum, Bitcoin tarihi boyunca meydana gelen ilk büyük hard fork'un ortaya çıkmasına neden olmuştur. Aynı zamanda bu durum, yeni bir kripto para birimi olan BCH'nin doğmasına yol açmıştır.
Aynı şekilde, Ethereum ağı da ağın güvenliğini ve merkeziyetsizliğini sağlamak için bir miktar ölçeklenebilirlikten feragat etmeyi seçmiştir; Ethereum ağı, Bitcoin ağı gibi blok boyutunu sınırlayarak işlem hacmini sınırlamasa da, tek bir bloğa kabul edilebilecek yakıt ücretine üst sınır koyma konusunda dolaylı bir değişim yapmıştır, ancak amaç Trustless Consensus'u sağlamak ve düğümlerin geniş bir dağılımını güvence altına almaktır. ( sınırın kaldırılması veya artırılması, birçok bant genişliği, depolama ve işlem gücü yetersiz olan daha küçük düğümlerin devre dışı kalmasına neden olacaktır. ).
2017 yılındaki CryptoKitties, DeFi yazı, ardından gelen GameFi ve NFT gibi zincir üstü uygulamaların yükselişi ile birlikte, piyasanın işlem hacmi talebi sürekli artmaktadır. Ancak, Turing tam Ethereum bile saniyede yalnızca 15~45 işlem ( TPS ) gerçekleştirebilmektedir. Bu durum, işlem maliyetlerinin sürekli artmasına, uzlaşma sürelerinin uzamasına ve çoğu Dapp'in işletme maliyetlerini karşılamada zorlanmasına neden olmaktadır. Tüm ağ, kullanıcılar için hem yavaş hem de pahalı hale gelmektedir ve blok zinciri ölçeklenebilirlik sorunu acilen çözülmelidir. İdeal durumdaki ölçeklenme çözümü, merkezileşmenin ve güvenliğin feda edilmeden blok zinciri ağının işlem hızını mümkün olduğunca artırmasıdır ( daha kısa nihai süre ) ve işlem hacmi ( daha yüksek TPS ).
2. Ölçeklenebilirlik çözümlerinin türleri
"Ana ağın bir katını değiştirme durumu"nu kriter olarak alarak, genişletme planlarını on-chain genişletme ve off-chain genişletme olarak iki ana kategoriye ayırıyoruz.
2.1 On-chain genişleme
Kilit Kavram: Bir ana ağ protokolünü değiştirerek ölçeklenebilirlik etkisi elde etme çözümü, mevcut ana çözüm parçalama (sharding) yöntemidir.
Zincir üzerindeki genişletme için çeşitli çözümler bulunmaktadır, bu makalede detaylandırılmayacak, aşağıda iki çözüm kısaca listelenmiştir:
Plan bir, blok alanını genişletmek, yani her bloğun paketlediği işlem sayısını artırmaktır, ancak bu, yüksek performanslı düğüm donanımı gereksinimlerini 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ç parçaya ayırmaktır, artık her düğüm tüm muhasebe işlemlerine katılmamaktadır, bunun yerine farklı parçalar yani farklı düğümler farklı muhasebe işlemlerinden sorumludur, paralel hesaplama aynı anda birden fazla işlemi 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ırır; ancak bu, tüm ağın hesaplama gücünün dağıtılacağı anlamına gelir ve bu, genel ağın "güvenliğini" düşürecektir.
Bir ana ağ protokolünün kodunu değiştirmek, temelindeki en küçük güvenlik açığının tüm ağın güvenliğini ciddi şekilde tehdit edeceği için tahmin edilemeyen olumsuz etkiler yaratabilir. Ağ, bir çatallaşmaya veya kesintili onarım güncellemesine zorlanabilir. Örneğin, 2018'de Zcash'in enflasyon açığı olayı: Zcash'in kodu Bitcoin 0.11.2 sürüm kodu üzerinde değişiklik yapılarak oluşturulmuştur. 2018'de bir mühendis, temel kodda ciddi bir açık tespit etti; yani tokenler sonsuz şekilde basılabilir. Takım, bu açığı gizlice onarmak için 8 ay harcadı ve açık düzeltildikten sonra bu olayı kamuya açıkladı.
2.2 off-chain genişleme
Ana kavram: Mevcut birinci katman ana ağ protokolünün genişletme çözümü değiştirilmeden.
Off-chain ölçeklenme çö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 Genel Bakış
Durum kanalları, yalnızca kanal açıldığında, kapandığında veya anlaşmazlık çözüldüğünde, kullanıcıların ana ağla etkileşimde bulunmalarını gerektirir ve kullanıcılar arasındaki etkileşimleri off-chain gerçekleştirerek, kullanıcı işlemlerinin zaman ve para maliyetlerini azaltmayı ve işlem sayısını sınırsız hale getirmeyi amaçlar.
Durum kanalları, "tur bazlı uygulamalar" için uygun basit bir P2P protokolüdür, örneğin, iki kişilik satranç oyunu. 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ı ( imzalı ve zaman damgası ile birlikte sunulan dolandırıcılık kanıtına dayanarak tahkim eder. Katılımcılar, blok zinciri ağına 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 izin verir ), yeter ki transfer net değeri yatırılan tokenların toplamını aşmasın (. Katılımcılar sırayla birbirlerine durum güncellemeleri gönderir ve karşı tarafın imzasını bekler. Karşı taraf imzasını onayladığında, bu durum güncellemesi tamamlanmış sayılır. Normal koşullarda, her iki tarafın onayladığı durum güncellemeleri ana ağa yüklenmez; yalnızca bir anlaşmazlık çıktığında veya kanal kapandığında ana ağ onayına ihtiyaç duyulur. Kanalı kapatmak gerektiğinde, herhangi bir katılımcı ana ağda işlem talebinde bulunabilir; eğer çıkış talebi herkesin oybirliğiyle onaylanı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; diğer katılımcılar onay vermezse, herkes "meydan okuma süresinin" bitmesini beklemek zorundadır. Kalan fonları almak için.
Yukarıda belirtildiği gibi, durum kanalı çözümü ana ağdaki hesaplama yükünü büyük ölçüde azaltabilir, işlem hızını artırabilir ve işlem maliyetini düşürebilir.
2015/02, Joseph Poon ve Thaddeus Dryja, Lightning Network beyaz kağıdı taslağını yayımladı.
2015/11, Jeff Coleman, State Channel kavramını ilk kez sistematik olarak özetledi ve Bitcoin'in Payment Channel'ının State Channel kavramının bir alt durumu olduğunu öne sürdü.
2016/01, Joseph Poon ve Thaddeus Dryja, Bitcoin Lightning Network: Scalable Off-Chain Instant Payments adlı beyaz kitabı resmi olarak yayımladı ve Bitcoin için ödeme kanalı ) ödeme kanalı ( önerdi. Bu yöntem yalnızca Bitcoin ağı üzerindeki transfer ödemelerini işlemek için kullanılır.
2017/11, Payment Channel çerçevesine dayanan ilk State Channel tasarım standardı Sprites önerilmiştir.
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, makale Generalised State Channel Networks, State Channel Networks ve Virtual Channels kavramlarını ortaya koymuştur.
2019/02, durum kanallarının kavramı N-Party Channels'a genişletildi, Nitro bu fikirle 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 Prensipler
Durum kanallarının çalışma akışı:
Alice ve Bob, kişisel EOA'larından fonları zincir üzerindeki sözleşme adresine yatırarak bu fonları sözleşmede kilitler; bu fonlar, kanal kapandığında kullanıcıya bakiye iade edilene kadar kilitli kalır. İkili imza onayladıktan sonra, ikisi arasında durum kanalı resmi olarak açılır.
Alice ve Bob, bu kanal aracılığıyla teorik olarak off-chain sınırsız sayıda işlem gerçekleştirebilir, katılımcılar birbirleriyle şifreli imza mesajları aracılığıyla iletişim kurar ), blok zincir ağıyla iletişim kurmak yerine (. 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, kendi hesaplarının durum güncellemelerini önerirler ve diğerinin önerdiği durum güncellemelerini kabul ederler.
Alice, kanalın sonu ile Bob arasındaki işlemi kapatmak isterse, Alice'in hesabının son durumunu sözleşmeye sunması gerekir ve Bob imzalayıp onaylarsa, sözleşme kilitlenen fonları son duruma göre ilgili kullanıcıya geri bırakacaktır. Bob imzaya yanıt vermezse, sözleşme, sorgulama süresi sona erdikten sonra kilitli fonları ilgili kullanıcıya geri bırakacaktır.
Kötümser durumda durum kanallarının iş akışı: Öncelikle, iki katılımcı fon yatırır ve ardından durum güncellemelerini değiştirmeye başlar. Diyelim ki bir noktada, Bob, Alice'in gönderdiği durum güncellemesi imzasına yanıt vermez; bu durumda, Alice, sözleşmeye kendi son geçerli durumunu sunarak bir meydan okuma başlatabilir, bu geçerli durum ayrıca Bob'un önceki imzasını da içerir, böylece son işlemin Bob'un onayını aldığını kanıtlar ve son durum Bob'un onayını almıştır. Ardından, sözleşme, Bob'un bir süre içinde sözleşmeye bir sonraki durumu sunarak yanıt vermesine izin verir; Bob yanıt verirse, ikili durum kanalı içinde işlem yapmaya devam edebilir; Bob bu süre içinde yanıt vermezse, sözleşme otomatik olarak durum kanalını kapatır ve fonları Alice'e geri iade eder.
Düşük işlem ücreti, yalnızca kanal açma sırasında zincir üzerindeki işlem ücretini ödemeniz gerekmektedir.
İyi gizlilik, off-chain işlemler ana ağda yayımlanmaz.
Eksiler:
Fon kullanım oranı düşük, fonların kilitlenmesi gerekiyor.
Kullanıcı dostu değil, sürekli çevrimiçi bir kanal izleme gerektiriyor
Kanal oluşturma oldukça karmaşık.
Genel bir durum kanalı tasarlamak zor.
Likidite eksikliği, kanallar fonları esnek bir şekilde aktaramıyor.
3.1.5 Uygulama
Bitcoin Lightning Network
Özet:
Lightning Network, Bitcoin ağının küçük ödemeler için bir kanalidir. Genel teknik evrimi şu şekilde gerçekleşmiştir: 2/2 çoklu imza ile tek yönlü ödeme kanalı oluşturulması, RSMC)Revocable Sequence Maturity Contract( eklenmesiyle iki yönlü ödeme kanalı oluşturulması, ardından HTLC)Hash Time Lock Contract( eklenmesiyle ödeme kanallarının çoklu ödemeleri bağlayacak şekilde genişletilmesi ve nihayetinde ödeme ağının yani Lightning Network'ün oluşturulması. Off-chain küçük ödeme kanalları aracılığıyla, ardından aracılar kullanılarak bir işlem ağı oluşturulması, Bitcoin ağının ölçeklenme sorununu çözebilir. Lightning Network'ün genel kullanımı "depozito) kanal oluşturma(→ Lightning Network işlemi) kanal durumunu güncelleme(→ geri ödeme/uzlaşma) kanal sonlandırma(" sürecini izler; teorik olarak Lightning Network her saniye bir milyon işlem gerçekleştirebilir.
Zaman çizgisi:
Şubat 2015'te Joseph Poon ve Thaddeus Dryja, Lightning Network teknik incelemesinin bir taslağını yayınladı;
2016 yılında resmi beyaz kitabın yayımlanması ve kurulması
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 ölçeklenme çözümleri derinliği analizi: State Channels ve Bitcoin Lighting Ağı
Off-chain Ölçeklenebilirlik Derinlik Analizi
Yazarlar: Ellaine Xu, Hettie Jiang, June Wang, Walon Lin, Yiliu Lin
1. Kapasite Artışının Gerekliliği
Blok zincirinin geleceği büyük bir vizyondur: merkeziyetsizlik, güvenlik ve ölçeklenebilirlik; ancak genellikle blok zinciri yalnızca bunlardan ikisini gerçekleştirebilir, bu üç gereksinimi aynı anda karşılamak blok zincirinin imkansız üçgen problemi olarak adlandırılır. Yıllar boyunca, bu sorunu nasıl çözeceğimizi, merkeziyetsizlik ve güvenliği sağlarken blok zincirinin işlem hacmini ve işlem hızını nasıl artıracağımızı araştırıyoruz; yani ölçeklenebilirlik sorununu çözmek, günümüzde blok zinciri 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çeklenebilirlik sorunlarından kaynaklanmıştır. Bitcoin 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şlamıştır; 2015 yılından itibaren, Bitcoin topluluğunda ölçeklenebilirlik konusunda anlaşmazlıklar ortaya çıkmıştır. Bir tarafta, blokların genişletilmesini destekleyen Bitcoin ABC temsilcileri olan genişletme yanlıları, diğer tarafta ise Segwit çözümü ile ana zincir yapısını optimize edilmesi gerektiğini savunan Bitcoin Core temsilcileri olan küçük blok yanlıları bulunmaktadır. 1 Ağustos 2017'de, Bitcoin ABC tarafından 8MB'ye kadar geliştirilmiş istemci sistemi çalışmaya başlamış ve bu durum, Bitcoin tarihi boyunca meydana gelen ilk büyük hard fork'un ortaya çıkmasına neden olmuştur. Aynı zamanda bu durum, yeni bir kripto para birimi olan BCH'nin doğmasına yol açmıştır.
Aynı şekilde, Ethereum ağı da ağın güvenliğini ve merkeziyetsizliğini sağlamak için bir miktar ölçeklenebilirlikten feragat etmeyi seçmiştir; Ethereum ağı, Bitcoin ağı gibi blok boyutunu sınırlayarak işlem hacmini sınırlamasa da, tek bir bloğa kabul edilebilecek yakıt ücretine üst sınır koyma konusunda dolaylı bir değişim yapmıştır, ancak amaç Trustless Consensus'u sağlamak ve düğümlerin geniş bir dağılımını güvence altına almaktır. ( sınırın kaldırılması veya artırılması, birçok bant genişliği, depolama ve işlem gücü yetersiz olan daha küçük düğümlerin devre dışı kalmasına neden olacaktır. ).
2017 yılındaki CryptoKitties, DeFi yazı, ardından gelen GameFi ve NFT gibi zincir üstü uygulamaların yükselişi ile birlikte, piyasanın işlem hacmi talebi sürekli artmaktadır. Ancak, Turing tam Ethereum bile saniyede yalnızca 15~45 işlem ( TPS ) gerçekleştirebilmektedir. Bu durum, işlem maliyetlerinin sürekli artmasına, uzlaşma sürelerinin uzamasına ve çoğu Dapp'in işletme maliyetlerini karşılamada zorlanmasına neden olmaktadır. Tüm ağ, kullanıcılar için hem yavaş hem de pahalı hale gelmektedir ve blok zinciri ölçeklenebilirlik sorunu acilen çözülmelidir. İdeal durumdaki ölçeklenme çözümü, merkezileşmenin ve güvenliğin feda edilmeden blok zinciri ağının işlem hızını mümkün olduğunca artırmasıdır ( daha kısa nihai süre ) ve işlem hacmi ( daha yüksek TPS ).
2. Ölçeklenebilirlik çözümlerinin türleri
"Ana ağın bir katını değiştirme durumu"nu kriter olarak alarak, genişletme planlarını on-chain genişletme ve off-chain genişletme olarak iki ana kategoriye ayırıyoruz.
2.1 On-chain genişleme
Kilit Kavram: Bir ana ağ protokolünü değiştirerek ölçeklenebilirlik etkisi elde etme çözümü, mevcut ana çözüm parçalama (sharding) yöntemidir.
Zincir üzerindeki genişletme için çeşitli çözümler bulunmaktadır, bu makalede detaylandırılmayacak, aşağıda iki çözüm kısaca listelenmiştir:
Bir ana ağ protokolünün kodunu değiştirmek, temelindeki en küçük güvenlik açığının tüm ağın güvenliğini ciddi şekilde tehdit edeceği için tahmin edilemeyen olumsuz etkiler yaratabilir. Ağ, bir çatallaşmaya veya kesintili onarım güncellemesine zorlanabilir. Örneğin, 2018'de Zcash'in enflasyon açığı olayı: Zcash'in kodu Bitcoin 0.11.2 sürüm kodu üzerinde değişiklik yapılarak oluşturulmuştur. 2018'de bir mühendis, temel kodda ciddi bir açık tespit etti; yani tokenler sonsuz şekilde basılabilir. Takım, bu açığı gizlice onarmak için 8 ay harcadı ve açık düzeltildikten sonra bu olayı kamuya açıkladı.
2.2 off-chain genişleme
Ana kavram: Mevcut birinci katman ana ağ protokolünün genişletme çözümü değiştirilmeden.
Off-chain ölçeklenme çö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 Genel Bakış
Durum kanalları, yalnızca kanal açıldığında, kapandığında veya anlaşmazlık çözüldüğünde, kullanıcıların ana ağla etkileşimde bulunmalarını gerektirir ve kullanıcılar arasındaki etkileşimleri off-chain gerçekleştirerek, kullanıcı işlemlerinin zaman ve para maliyetlerini azaltmayı ve işlem sayısını sınırsız hale getirmeyi amaçlar.
Durum kanalları, "tur bazlı uygulamalar" için uygun basit bir P2P protokolüdür, örneğin, iki kişilik satranç oyunu. 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ı ( imzalı ve zaman damgası ile birlikte sunulan dolandırıcılık kanıtına dayanarak tahkim eder. Katılımcılar, blok zinciri ağına 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 izin verir ), yeter ki transfer net değeri yatırılan tokenların toplamını aşmasın (. Katılımcılar sırayla birbirlerine durum güncellemeleri gönderir ve karşı tarafın imzasını bekler. Karşı taraf imzasını onayladığında, bu durum güncellemesi tamamlanmış sayılır. Normal koşullarda, her iki tarafın onayladığı durum güncellemeleri ana ağa yüklenmez; yalnızca bir anlaşmazlık çıktığında veya kanal kapandığında ana ağ onayına ihtiyaç duyulur. Kanalı kapatmak gerektiğinde, herhangi bir katılımcı ana ağda işlem talebinde bulunabilir; eğer çıkış talebi herkesin oybirliğiyle onaylanı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; diğer katılımcılar onay vermezse, herkes "meydan okuma süresinin" bitmesini beklemek zorundadır. Kalan fonları almak için.
Yukarıda belirtildiği gibi, durum kanalı çözümü ana ağdaki hesaplama yükünü büyük ölçüde azaltabilir, işlem hızını artırabilir ve işlem maliyetini düşürebilir.
![Binlerce kelimelik Derinlik raporu: Off-chain genişlemenin kapsamlı analizi])https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.webp(
3.1.2 Zaman Çizgisi
3.1.3 Teknik Prensipler
Durum kanallarının çalışma akışı:
Alice ve Bob, kişisel EOA'larından fonları zincir üzerindeki sözleşme adresine yatırarak bu fonları sözleşmede kilitler; bu fonlar, kanal kapandığında kullanıcıya bakiye iade edilene kadar kilitli kalır. İkili imza onayladıktan sonra, ikisi arasında durum kanalı resmi olarak açılır.
Alice ve Bob, bu kanal aracılığıyla teorik olarak off-chain sınırsız sayıda işlem gerçekleştirebilir, katılımcılar birbirleriyle şifreli imza mesajları aracılığıyla iletişim kurar ), blok zincir ağıyla iletişim kurmak yerine (. 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, kendi hesaplarının durum güncellemelerini önerirler ve diğerinin önerdiği durum güncellemelerini kabul ederler.
Alice, kanalın sonu ile Bob arasındaki işlemi kapatmak isterse, Alice'in hesabının son durumunu sözleşmeye sunması gerekir ve Bob imzalayıp onaylarsa, sözleşme kilitlenen fonları son duruma göre ilgili kullanıcıya geri bırakacaktır. Bob imzaya yanıt vermezse, sözleşme, sorgulama süresi sona erdikten sonra kilitli fonları ilgili kullanıcıya geri bırakacaktır.
Kötümser durumda durum kanallarının iş akışı: Öncelikle, iki katılımcı fon yatırır ve ardından durum güncellemelerini değiştirmeye başlar. Diyelim ki bir noktada, Bob, Alice'in gönderdiği durum güncellemesi imzasına yanıt vermez; bu durumda, Alice, sözleşmeye kendi son geçerli durumunu sunarak bir meydan okuma başlatabilir, bu geçerli durum ayrıca Bob'un önceki imzasını da içerir, böylece son işlemin Bob'un onayını aldığını kanıtlar ve son durum Bob'un onayını almıştır. Ardından, sözleşme, Bob'un bir süre içinde sözleşmeye bir sonraki durumu sunarak yanıt vermesine izin verir; Bob yanıt verirse, ikili durum kanalı içinde işlem yapmaya devam edebilir; Bob bu süre içinde yanıt vermezse, sözleşme otomatik olarak durum kanalını kapatır ve fonları Alice'e geri iade eder.
![万字Derinlik研报:全面解析off-chain扩容])https://img-cdn.gateio.im/webp-social/moments-ad088ac016d75b1ae0b0eda699e74709.webp(
3.1.4 Avantajlar ve Dezavantajlar
Avantajlar:
Eksiler:
3.1.5 Uygulama
Bitcoin Lightning Network
Özet: Lightning Network, Bitcoin ağının küçük ödemeler için bir kanalidir. Genel teknik evrimi şu şekilde gerçekleşmiştir: 2/2 çoklu imza ile tek yönlü ödeme kanalı oluşturulması, RSMC)Revocable Sequence Maturity Contract( eklenmesiyle iki yönlü ödeme kanalı oluşturulması, ardından HTLC)Hash Time Lock Contract( eklenmesiyle ödeme kanallarının çoklu ödemeleri bağlayacak şekilde genişletilmesi ve nihayetinde ödeme ağının yani Lightning Network'ün oluşturulması. Off-chain küçük ödeme kanalları aracılığıyla, ardından aracılar kullanılarak bir işlem ağı oluşturulması, Bitcoin ağının ölçeklenme sorununu çözebilir. Lightning Network'ün genel kullanımı "depozito) kanal oluşturma(→ Lightning Network işlemi) kanal durumunu güncelleme(→ geri ödeme/uzlaşma) kanal sonlandırma(" sürecini izler; teorik olarak Lightning Network her saniye bir milyon işlem gerçekleştirebilir.
Zaman çizgisi: