off-chain ölçeklendirme Derinlik analizi

1. Genişlemenin Gerekliliği

Blok zincirinin geleceği, merkeziyetsizlik, güvenlik ve ölçeklenebilirlikten oluşan büyük bir vizyondur; ancak genellikle blok zinciri yalnızca bunlardan ikisini gerçekleştirebilir. Bu üç gereksinimi aynı anda karşılamanın imkansızlık üçgeni problemi olarak adlandırıldığı bilinmektedir. Yıllar boyunca, bu sorunla nasıl başa çıkılacağı, merkeziyetsizlik ve güvenliği sağlamanın yanı sıra blok zincirinin işlem hacmini ve işlem hızını artırmanın yolları, yani ölçeklendirme sorununu çözmek, mevcut blok zinciri gelişim sürecinde tartışılan en sıcak konulardan biri olmuştur.

Öncelikle blok zincirinin merkeziyetsizliğini, güvenliğini ve ölçeklenebilirliğini genel hatlarıyla tanımlayalım:

• Merkeziyetsizlik: Herkes, blok zinciri sisteminin üretimi ve doğrulanması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 bu da ağın küçük bir grup büyük merkezi katılımcının kontrolünden etkilenmesini sağlar.
• Güvenlik: Bir blockchain sisteminin kontrolünü elde etmek için harcanan maliyet ne kadar yüksekse, güvenlik o kadar yüksektir; bu durumda, ağ, katılımcıların daha büyük bir oranından gelecek saldırılara karşı direnç gösterebilir.
• Ölçeklenebilirlik: Blockchain'in büyük miktarda işlemi işleme yeteneği.

Bitcoin ağının ilk büyük hard fork'u, ölçeklenebilirlik sorunundan kaynaklanmıştır. Bitcoin kullanıcı sayısı ve işlem hacminin artmasıyla, her blok için 1MB'lık üst sınırla Bitcoin ağı tıkanma sorunuyla karşılaşmaya başladı; 2015'ten itibaren, Bitcoin topluluğunda ölçeklenebilirlik konusunda görüş ayrılıkları oluştu, bir tarafı Bitcoin ABC'nin temsil ettiği blok genişletme yanlıları, diğer tarafı ise Bitcoin Core'un temsil ettiği küçük blok yanlıları, ana zincir yapısını optimize etmek için Segwit çözümünün kullanılmasını savundular. 1 Ağustos 2017'de, Bitcoin ABC, 8MB'lık istemci sistemini kendi başına geliştirmeye başlayarak çalıştırmaya başladı ve bu, Bitcoin tarihindeki ilk büyük hard fork'un ortaya çıkmasına neden oldu ve bu durum yeni bir kripto para birimi olan BCH'nin doğmasına yol açtı.

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ğının yaptığı gibi işlem hacmini sınırlamak için blok boyutunu kısıtlamamış, aksine tek bir blokta kabul edilebilecek yakıt ücretlerine bir üst sınır koyarak dolaylı bir şekilde dönüşüm yapmıştır. Ancak amaç, Trustless Consensus'u gerçekleştirmek ve düğümlerin geniş dağılımını sağlamaktır. ( Limitlerin kaldırılması veya artırılması, birçok bant genişliği, depolama ve hesaplama kapasitesi yetersiz olan daha küçük düğümlerin elenmesine neden olacaktır. ).

2017 yılındaki CryptoKitties, DeFi yazı, daha sonra GameFi ve NFT gibi zincir üzerindeki uygulamaların yükselişi ile, piyasanın işlem hacmi talebi sürekli artmaktadır, ancak Turing tam olan Ethereum bile saniyede yalnızca 15~45 işlem ( TPS ) gerçekleştirebilmektedir, bu da işlem maliyetlerinin sürekli artmasına, uzlaşma süresinin uzamasına neden olmakta, çoğu Dapp'in işletim maliyetlerini karşılaması zorlaşmakta, tüm ağ kullanıcılar için hem yavaş hem de pahalı hale gelmektedir, blok zinciri genişleme sorunu acil olarak çözülmelidir. İdeal durumu genişletme çözümü: merkezileşmeyi ve güvenliği feda etmeden, blok zinciri ağının işlem hızını ( daha kısa finalite süresi ) ve işlem hacmini ( daha yüksek TPS ) ile mümkün olduğunca artırmaktır.

2. Ölçeklenebilirlik çözümlerinin türleri

"Ana ağın bir katmanını değiştirip değiştirmeyeceğine" göre, ölçekleme çözümlerini on-chain ve off-chain olmak üzere iki ana kategoriye ayırıyoruz.

2.1 Zincir üstü genişleme

Temel Kavram: Bir katman ana ağ protokolünü değiştirerek ölçeklenme etkisi yaratan çözüm, mevcut ana çözüm parçalama (sharding) olarak belirlenmiştir.

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 listelenmiştir:

• Birinci seçenek blok alanını genişletmektir, yani her blokta paketlenmiş 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ırmak, artık her düğümün tüm hesaplamalara katılmadığı, bunun yerine farklı parçaların yani farklı düğümlerin farklı hesaplamalardan sorumlu olduğu, paralel hesaplamanın aynı anda birden fazla işlemi işleyebileceği anlamına gelir; bu, düğümlerin hesaplama yükünü ve katılım eşiğini azaltabilir, işlem hızı ve merkeziyetsizlik derecesini artırabilir; ancak bu, tüm ağın hesaplama gücünün dağılacağı ve bu durumun genel ağın "güvenliğini" azaltacağı anlamına gelir.

Bir ana ağ protokolünün kodunu değiştirmek, temel düzeydeki herhangi bir küçük güvenlik açığının tüm ağın güvenliğini ciddi şekilde tehdit etmesi nedeniyle öngörülemeyen olumsuz etkilere yol açabilir. Ağ, bir çatallaşmaya veya kesintili bir onarım güncellemesine zorlanabilir. Örneğin, 2018 yılında Zcash'in enflasyon açığı olayı: Zcash'in kodu Bitcoin 0.11.2 sürüm kodu üzerinde yapılan değişikliklere dayanmaktadır, 2018 yılında bir mühendis, temel kodda yüksek riskli bir güvenlik açığı buldu, yani tokenlar sonsuz bir şekilde artırılabiliyordu. Takım, açığı gizlice onarmak için 8 ay harcadı ve açığın düzeltilmesinin ardından bu olayı kamuoyuna açıkladı.

2.2 off-chain genişleme

Ana kavram: Mevcut birinci katman ana ağ protokolünü değiştirmeden ölçeklendirme çözümü.

off-chain ölçeklendirme çözümleri ayrıca Layer2 ve diğer çözümlere ayrılabilir:

3. off-chain genişletme 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şimde bulunması gerektiğini ve kullanıcılar arası etkileşimlerin off-chain gerçekleştirilmesini sağlayarak kullanıcıların işlem sürelerini ve maliyetlerini azaltmayı ve işlem sayısında sınırlama olmaksızın gerçekleştirmeyi amaçlar.

Durum kanalları, "dönem tabanlı 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ö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 para yatırır ve kilitler, her iki taraf imzalayıp onayladıktan sonra kanal resmi olarak açılır. Kanal, katılımcılar arasında, yatırılan token toplamı ) aşılamadığı sürece, sınırsız sayıda off-chain ücretsiz işlem yapılmasına izin verir. 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. Normalde, her iki tarafın kabul ettiği durum güncellemeleri ana ağa yüklenmez; yalnızca bir anlaşmazlık ortaya çıktığında veya kanal kapatıldığında ana ağa doğrulama için başvurulur. Kanalı kapatmak gerektiğinde, herhangi bir katılımcı ana ağda işlem talebinde bulunabilir; eğer çıkış talebi tüm katılımcıların imzasıyla onaylanırsa, zincir üzerinde hemen yürütülür; yani akıllı sözleşme, kanalın son durumundaki her katılımcının bakiyesi üzerinden kalan kilitli fonları dağıtır; eğer diğer katılımcılar onaylamazsa, herkes kalan fonları almak için "meydan okuma süresi"nin sona ermesini beklemek zorundadır.

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 maliyetlerini düşürebilir.

(# 3.1.2 Zaman Çizelgesi

• 2015/02, Joseph Poon ve Thaddeus Dryja, Lightning Network beyaz kağıdının taslağını yayınladı.
• 2015/11, Jeff Coleman ilk kez State Channel kavramını 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 başlıklı beyaz kitabı resmi olarak yayınlayarak, Bitcoin ağındaki transfer ödemelerini işlemek için sadece kullanılan Payment Channel) ödeme kanalı### çözümünü önerdiler.
• 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 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 fikre dayalı olarak oluşturulan ilk protokoldür.
• 2019/10, Pisa, tüm katılımcıların sürekli çevrimiçi olma ihtiyacını çö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ılan akıllı sözleşmelerle etkileşime geçer, 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ı beraberinde getirmesidir.

![Binlerce Derinlik Raporu: Off-chain Ölçekleme Analizi])https://img-cdn.gateio.im/webp-social/moments-087d35594a04d33375b8199b93eb355e.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 öncekiyle aynı işlemleri gerçekleştirmeleri gerekmektedir, ancak bu sefer durum kanalını kullanırlar, zincir üstü sözleşmelerle etkileşimde bulunmak yerine.

• İlk adım, Alice ve Bob kişisel EOA'larından ( numaralı zincir üstü sözleşme adresine 1,2) kadar fon yatırarak etkileşimde bulunurlar; bu fonlar sözleşmede kilitlenir, ta ki kanal kapatılana kadar bakiyeler kullanıcıya iade edilmez; ikili imza onaylandı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 gerçekleştirebilirler ( mavi kesikli hat ), katılımcılar şifreli imzalı mesajlar aracılığıyla birbirleriyle iletişim kurarlar (, blok zinciri ağıyla değil ). Her iki kullanıcı da her işlem için imza atmak zorundadır, bu da çift harcama kötü niyetini önler. 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ım, Alice Bob ile olan işlemi 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 kilitli fonları ilgili kullanıcıya ( etkileşim 4,5) iade eder. Eğer Bob imzaya yanıt vermezse, sözleşme itiraz süresi sona erdikten sonra kilitli 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şimi 1, 2) miktarını yatırır ve ardından durum güncellemelerini ( mavi kesik çizgi ) ile değiştirmeye başlar. Diyelim ki bir noktada, Bob kendi turunda Alice'in gönderdiği durum güncelleme imzasına ( etkileşimi 3) yanıt vermez, bu durumda Alice, sözleşmeye kendi son geçerli durumunu sunarak bir meydan okuma başlatabilir ( etkileşimi 4), bu geçerli durum ayrıca Bob'un önceki imzasını da içermektedir, böylece son işlemin Bob'un onayını aldığı kanıtlanır ve nihai durum Bob'un onayını almıştır. Ardından, sözleşme Bob'un belirli bir süre içinde bir sonraki durumu sözleşmeye sunarak yanıt vermesine olanak tanır; Eğer Bob yanıt verirse, ikisi 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 geri iade eder ( etkileşimi 5).

(# 3.1.4 Artılar ve Eksiler

Avantajları:

• Anlık: off-chain işlemler hemen onaylanabilir, blok onayı beklemeye gerek yoktur.
• Yüksek veri akışı: Kanal açıldığında ve kapandığında yalnızca ana ağ ile etkileşim gerektirir, bu da veri akışını büyük ölçüde artırır.
• Düşük maliyet: off-chain işlemler için madenci ücreti ödenmesi gerekmez, yalnızca kanalın açılıp kapanması sırasında az miktarda ücret ödenmesi gerekmektedir.
• Gizlilik: off-chain işlem içeriği zincire eklenmeyecek, yalnızca nihai durum ana ağa gönderilecektir.

Eksiler:

• Karmaşıklık: Durum kanallarının uygulanması ve kullanımı oldukça karmaşıktır.
• Likidite kilidi: Önceden belirli bir miktar fonun kilitlenmesi gerekmektedir.
• Çevrimiçi gereksinim: Katılımcıların en son duruma yanıt vermek için çevrimiçi kalması gerekiyor.
• Uygulama alanı sınırlıdır: Öncelikle tarafların sık etkileşimde bulunduğu senaryolar için uygundur.

)# 3.1.5 Uygulama

Bitcoin Lightning Network:

Genel Bakış: Lightning Network, Bitcoin ağı için küçük miktar ödemeler kanalıdır, genel teknik evrimi şu şekildedir: 2/2 çoklu imza ile tek yönlü ödeme kanalı inşası.