off-chain genişletme Derinlik analizi

Yazarlar: Ellaine Xu, Hettie Jiang, June Wang, Walon Lin, Yiliu Lin

1. Ölçeklenmenin Gerekliliği

Blok zincirinin geleceği büyük bir vizyondur: merkeziyetsizlik, güvenlik ve ölçeklenebilirlik; ancak genellikle blok zinciri bu üçünden yalnızca ikisini gerçekleştirebilir, bu üç talebi karşılamanın imkansızlığına blok zincirinin imkansız üçgen problemi denir. Yıllardır insanlar bu sorunu çözmenin yollarını araştırıyor, merkeziyetsizlik ve güvenliği sağlarken blok zincirinin verimliliğini ve işlem hızını artırmak, yani ölçeklendirme sorununu çözmek, mevcut blok zinciri gelişim sürecinde tartışılan sıcak konulardan biridir.

Öncelikle, blok zincirinin merkezsizliğini, güvenliğini ve ölçeklenebilirliğini genel hatlarıyla tanımlayalı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 fazlaysa, dağıtıklık seviyesi o kadar yüksek olur, böylece ağın küçük bir grup büyük merkeziyetçi katılımcı tarafından kontrol edilmesini engeller.
• Güvenlik: Blok zinciri sisteminin kontrolünü ele geçirmek için harcanan maliyet ne kadar yüksek olursa, güvenlik o kadar yüksek olur ve bu durumda zincir, katılımcıların daha büyük bir oranının saldırıları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 sert çatallanması, ölçeklendirme sorunundan kaynaklanmıştır. Bitcoin kullanıcı sayısı ve işlem hacminin artmasıyla birlikte, her blok için maksimum 1MB olan Bitcoin ağı tıkanıklık sorunlarıyla karşılaşmaya başlamıştır; 2015 yılından itibaren Bitcoin topluluğunda ölçeklendirme konusunda görüş ayrılıkları ortaya çıkmıştır. Bir taraf, Bitcoin ABC ile temsil edilen blok boyutunu genişletme yanlısı ölçeklendirme taraftarı iken, diğer taraf Bitcoin Core ile temsil edilen küçük blok yanlısı, ana zincir yapısını optimize etmek için Segwit çözümünün kullanılmasını savunmuştur. 1 Ağustos 2017'de, Bitcoin ABC kendi geliştirdiği 8MB'lık istemci sistemini çalıştırmaya başlamış ve bu da Bitcoin tarihindeki ilk büyük sert çatallanmanın ortaya çıkmasına neden olmuştur. Bu süreçte yeni bir kripto para birimi olan BCH de doğmuştur.

Benzer şekilde, Ethereum ağı da güvenlik ve merkeziyetsizliği sağlamak için bir miktar ölçeklenebilirlikten feragat etmeyi seçmiştir; Ethereum ağı, Bitcoin ağı gibi blok boyutunu kısıtlayarak işlem hacmini sınırlamamakta, bunun yerine tek bir bloğun alabileceği yakıt ücretine üst sınır koyarak dolaylı yoldan değişmektedir, ancak amaç her iki durumda da Trustless Consensus'u sağlamak ve düğümlerin geniş bir dağılımını güvence altına almaktır. ( Limitlerin kaldırılması veya artırılması, yetersiz bant genişliği, depolama ve hesaplama gücüne sahip birçok küçük düğümü ortadan kaldıracaktır. )

2017 yılındaki CryptoKitties, DeFi yazı, ardından GameFi ve NFT gibi zincir üzerindeki uygulamaların yükselişi ile birlikte, piyasada işlem hacmine olan talep sürekli artıyor. Ancak Turing tam olan Ethereum bile saniyede yalnızca 15~45 işlem (TPS) gerçekleştirebiliyor. Bu durum, işlem maliyetlerinin sürekli artmasına, uzlaşma sürelerinin uzamasına ve çoğu Dapp'ın işletme maliyetlerini karşılamakta zorlanmasına neden oluyor. Tüm ağ, kullanıcılar için yavaş ve pahalı hale geliyor ve blockchain genişleme sorunu acilen çözülmesi gereken bir durum. İdeal genişleme çözümünde, merkeziyetsizlik ve güvenlikten ödün vermeden, blockchain 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 gerekiyor.

2. Ölçeklenme Planlarının Türleri

"Ana ağda bir katman değişip değişmeyeceği" standartına göre, ölçeklendirme çözümlerini on-chain ve off-chain olmak üzere iki ana kategoriye ayırıyoruz.

2.1 On-Chain Ölçeklenebilirlik

Kilit kavram: Bir ana ağ protokolünün bir katmanını değiştirerek genişleme etkisi elde etme çözümü, şu anda ana çözüm parçalama (sharding) olarak bilinmektedir.

Zincir üzerinde ölçeklendirme için çeşitli çözümler vardır, bu makalede bunlar üzerinde durulmayacak, aşağıda iki çözüm kısaca listelenmiştir:

• Plan bir, blok alanını genişletmektir, yani her blokta paketlenen 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ç parçaya ayırmaktır, artık her düğüm tüm muhasebe işlemlerine katılmayacak, bunun yerine farklı parçalar yani farklı düğümler farklı muhasebe işlemlerinden sorumlu olacak, paralel hesaplama birden fazla işlemi aynı anda işleyebilir; bu, düğüm hesaplama yükünü ve katılım eşiğini azaltabilir, işlem işleme hızını ve merkeziyetsizlik derecesini artırabilir; ancak bu, tüm ağın hesaplama gücünün dağılması anlamına gelir ve bu, tüm ağın "güvenliğini" azaltacaktır.

Ana ağ protokolünün kodunu değiştirmek, temel olarak herhangi bir ince 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 çatallaşmaya veya kesinti 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ştirilmiştir; 2018'de bir mühendis, temel kodda yüksek riskli bir açığın bulunduğunu keşfetti, yani token sınırsız bir şekilde artırılabiliyordu ve ekip bu açığı gizlice onarmak için 8 ay harcadı; açığın onarılmasından 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çeklenme çözümleri ayrıca Layer2 ve diğer çözümler olarak alt kategorilere ayrılabilir:

3. off-chain genişletme 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ğ ile etkileşimde bulunması gerektiğini ve kullanıcılar arası etkileşimi off-chain gerçekleştirilmesini gerektirir. Bu, kullanıcıların işlem sürelerini ve maliyetlerini azaltır ve işlem sayısında bir kısıtlama getirilmez.

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ş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ı arabulur (, imza ve zaman damgası ile birlikte sahtekarlık kanıtına dayalı olarak ). 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ını 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 yapılmasına izin verir (, yeter ki transfer net değerleri, yatırılan token toplamını aşmasın ). Katılımcılar sırayla birbirlerine durum güncellemeleri gönderir ve karşı tarafın imza onayını bekler. Karşı taraf imza onayı verdiği anda, bu durum güncellemesi tamamlanmış sayılır. Normalde, her iki tarafın kabul ettiği 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 ihtiyaç vardır. 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 tarafından imza onayı alırsa, zincir üzerindeki işlem hemen gerçekleştirilir; yani, akıllı sözleşme, kanalın son durumundaki her katılımcının bakiyesine göre kilitli fonları dağıtır; eğer diğer katılımcılar imza onayı vermezse, herkes kalan fonları almak için "mücadele süresi"nin sona ermesini beklemek zorundadır.

Yukarıda belirtilenlere göre, durum kanalı çözümü ana ağdaki hesaplama miktarını önemli ölçüde azaltabilir, işlem hızını artırabilir ve işlem maliyetini düşürebilir.

3.1.2 Zaman Çizelgesi

• 2015/02, Joseph Poon ve Thaddeus Dryja, Lightning Network beyaz kağıdının taslağını yayımladı.
• 2015/11, Jeff Coleman ilk sistematik olarak State Channel kavramını ö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: Ölçeklenebilir Off-Chain Anlık Ödemeler adlı beyaz kitabı resmi olarak yayımlayarak, Bitcoin Lightning Network'ün genişleme çözümünü 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 çok ayrıntılı bir Genelleşmiş Durum Kanalları tasarımı sundu, bu, tamamen durum kanallarıyla ilgili 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 fikir üzerine kurulan ilk protokoldür.
• 2019/10, Pisa, tüm katılımcıların sürekli çevrimiçi olma gereksinimini çö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 ve kullanıcı, 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ı getirmesidir.

Şekil 2, çoğu durum kanalı protokolünün izlediği genel çalışma akışını göstermektedir: İyimser bir durumda, Alice ve Bob daha öncekiyle aynı işlemleri gerçekleştirmek zorundadır, ancak bu sefer durum kanalı kullanarak, zincir üstü sözleşmelerle etkileşime girmeden.

• İlk adım, Alice ve Bob, kişisel EOA'larından ( adresine para yatırarak etkileşimde bulunurlar, bu 1,2) tutarındaki fonlar, kanal kapandığında kullanıcıya bakiyenin iade edilmesine kadar sözleşmede kilitlenir; iki taraf imzayı onayladıktan sonra, aralarındaki 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 gerçekleştirebilirler ( mavi kesikli çizgi ), katılımcılar birbirleriyle şifreli imzalı mesajlar üzerinden 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 kötü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 kanalı kapatmak istiyorsa, Alice, sözleşmeye kendi hesabının nihai durumunu ( etkileşim 3) göndermelidir. Eğer Bob imzayı onaylarsa, sözleşme nihai duruma göre kilitlenmiş fonları ilgili kullanıcıya ( etkileşim 4,5) iade edecektir. 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, pessimistik durumda bir durum kanalı iş akışını göstermektedir: İlk olarak, iki katılımcı ( etkileşim 1, 2) miktarını yatırır ve ardından durum güncellemelerini değiş tokuş etmeye başlar ( mavi kesik çizgi ). Diyelim ki bir noktada, Bob, Alice'in gönderdiği durum güncellemesi imzasına ( etkileşim 3) yanıt vermezse, Alice, sözleşmeye kendi en son geçerli durumunu sunarak bir zorlama başlatabilir ( etkileşim 4); bu geçerli durum, Bob'un daha önceki imzasını da içerir ve böylece son işlemin Bob'un onayını aldığını kanıtlar, nihai durumun Bob'un onayını aldığını gösterir. Ardından, sözleşme Bob'a bir süre içinde sözleşmeye bir sonraki durumu sunarak yanıt verme imkanı tanır; eğer Bob yanıt verirse, ikili durum kanalında işlem yapmaya devam edebilir; eğer Bob bu süre içinde yanıt vermezse, sözleşme otomatik olarak durum kanalını kapatır ve fonları Alice'e iade eder ( etkileşim 5).

3.1.4 Avantajlar ve Dezavantajlar

Avantajlar:

• Anlık işlem onayı
• Yüksek throughput
• Düşük işlem ücreti
• Yüksek gizlilik

Eksiler:

• Fonları kilitlemek gerekiyor
• Kullanıcıların sık sık çevrimiçi olması gerekiyor
• Karmaşıklık artışı

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 çok imzalı tek yönlü ödeme kanalı oluşturma, RSMC ekleme.