off-chain genişletme Derinlik analizi

1. Genişlemenin Gerekliliği

Blockchain'ın gelecekteki vizyonu merkeziyetsizlik, güvenlik ve ölçeklenebilirliktir, ancak genellikle yalnızca ikisi gerçekleştirilebilir, bu, blockchain'ın imkansız üçgen problemi olarak adlandırılır. Yıllar boyunca, bu sorunu nasıl çözeceğimizi araştırdık, merkeziyetsizlik ve güvenliği sağlarken blockchain'in işlem hacmini ve işlem hızını artırmanın yollarını bulmak, yani ölçeklenme 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:

• Dağıtık: Herkes, blockchain sisteminin üretimi ve doğrulamasına katılmak için bir düğüm olabilir. Düğüm sayısı arttıkça, dağıtıklık derecesi de artar ve böylece ağı küçük bir grup büyük merkezi katılımcının kontrolünden korur.

• Güvenlik: Bir blockchain sisteminin kontrolünü elde etmek için ödenen maliyet ne kadar yüksekse, güvenlik o kadar yüksektir; böylece zincir, katılımcıların ona yapacağı saldırılara karşı daha büyük bir oranda direnç gösterebilir.

• Ölçeklenebilirlik: Blockchain'in büyük miktarda işlemi işleme yeteneği.

Bitcoin ağı üzerindeki ilk büyük sert bölünme, ölçeklendirme sorunundan kaynaklanmıştır. Bitcoin kullanıcı sayısı ve işlem hacmi arttıkça, her blok için üst sınırın 1MB olduğu 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 farklı görüşler ortaya çıkmıştır. Bir taraf, Bitcoin ABC tarafından temsil edilen blok boyutunun genişletilmesini destekleyen ölçeklendirme yanlılarıdır, diğer taraf ise Bitcoin Core tarafından temsil edilen küçük blok yanlılarıdır ve ana zincir yapısını optimize etmek için Segwit çözümünün kullanılmasını savunmaktadır. 1 Ağustos 2017'de, Bitcoin ABC kendi geliştirdiği 8MB istemci sistemini çalıştırmaya başlamış ve bu durum Bitcoin tarihindeki ilk büyük sert bölünmenin meydana gelmesine neden olmuştur. Aynı zamanda bu olay yeni bir kripto para birimi olan BCH'nin doğmasına da yol açmıştır.

Aynı şekilde, Ethereum ağı da güvenliğini ve merkeziyetsizliğini sağlamak için bir miktar ölçeklenebilirlikten feragat etmeyi seçmiştir; Ethereum ağı, Bitcoin ağı gibi işlem hacmini sınırlamak için blok boyutunu kısıtlamamıştır, bunun yerine tek bir bloğun alabileceği yakıt ücretine bir üst sınır koyarak dolaylı olarak bir değişim yapmıştır, ancak amaç hepsi Trustless Consensus'u gerçekleştirmek ve düğümlerin geniş dağılımını sağlamaktır. ( Sınırın kaldırılması veya artırılması, birçok bant genişliği, depolama ve hesaplama kapasitesi yetersiz olan daha küçük düğümlerin ortadan kalkmasına neden olacaktır. ).

2017'deki CryptoKitties, DeFi yazı, ardından GameFi ve NFT gibi zincir üstü uygulamaların yükselişi ile birlikte, piyasada 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. Bunun sonucu olarak, işlem maliyetleri sürekli artmakta, uzlaşma süresi uzamakta, çoğu Dapp işletme maliyetlerini karşılamakta zorlanmakta ve tüm ağ kullanıcılar için hem yavaş hem de pahalı hale gelmektedir. Blockchain genişleme sorunu acilen çözülmelidir. İdeal durumdaki genişleme çözümü, merkezsizlik ve güvenlikten ödün vermeden, mümkün olduğunca blockchain ağının işlem hızını ( daha kısa finalite süresi) ve işlem hacmini ( daha yüksek TPS) artırabilmektir.

2. Ölçekleme Çözümünün Kategorileri

"Ana ağın bir katmanını değiştirip değiştirmeme" kriterine göre, genişleme planlarını zincir içi genişleme ve zincir dışı genişleme 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 elde etme çözümü, mevcut ana çözüm parçalama (sharding) olarak belirlenmiştir.

Zincir üzerindeki ölçeklenme için çeşitli çözümler bulunmaktadır, bu makalede detaylandırılmayacak, aşağıda iki çözüm kısaca listelenmiştir:

• Birinci seçenek, blok alanını genişletmektir, yani her bloğun paketlediği işlem sayısını artırmak, 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" düzeyini azaltacaktır.

• İkinci seçenek parçalara ayırmadır, blok zinciri defterini birkaç parçaya bölerek, artık her düğüm tüm muhasebeye katılmayacak, bunun yerine farklı parçalar yani farklı düğümler farklı muhasebe işlemlerini üstlenecek, paralel hesaplama aynı anda birden fazla işlemi işleyebilir; bu, düğümlerin hesaplama baskısını ve katılım eşiğini düşürerek, işlem işleme hızını ve merkeziyetsizlik düzeyini artırabilir; ancak bu, tüm ağın hesaplama gücünün dağılacağı anlamına gelir, bu da tüm ağın "güvenliğini" azaltır.

Bir ana ağ protokolünün kodunu değiştirmek, beklenmeyen olumsuz etkiler doğurabilir, çünkü alt katmandaki en küçük güvenlik açığı, tüm ağın güvenliğini ciddi şekilde tehdit edebilir. Ağ, bir çatallaşmaya veya kesintisiz bir onarım yükseltmesine zorlanabilir. Örneğin, 2018'deki Zcash enflasyon açığı olayı: Zcash'in kodu, Bitcoin 0.11.2 sürüm kodu üzerinde yapılan değişikliklere dayanıyor. 2018'de bir mühendis, alt katmandaki kodda yüksek riskli bir açığın bulunduğunu keşfetti; yani tokenlerin sınırsız bir şekilde basılabileceğini. Hemen ardından ekip, bu açığı gizlice düzeltmek için 8 ay harcadı ve düzeltme sonrasında bu olayı kamuoyuna açıkladı.

2.2 off-chain genişleme

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 ayrılabilir:

• Layer2: durum kanalları, yan zincirler, Plasma, Rollups

• Diğer: Validium, Volition

3. off-chain genişletme planı

3.1 Durum Kanalları (State Channels )

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 belirtir ve kullanıcılar arasındaki etkileşimleri off-chain olarak gerçekleştirerek kullanıcıların işlem sürelerini ve maliyetlerini azaltır ve işlem sayısında bir kısıtlama olmamasını sağlar.

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ö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ı (, imza ve zaman damgası ile birlikte sağlanan dolandırıcılık kanıtları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 imza onayı ile kanal resmen açılır. Kanal, katılımcıların yatırılan toplam token miktarını ) aşmadığı sürece, sınırsız sayıda off-chain ücretsiz işlem yapmasına olanak tanır. Katılımcılar sırayla birbirlerine durum güncellemeleri gönderir ve diğerinin imza onayını bekler. Diğer taraf imza onayı verdikten sonra, bu durum güncellemesi tamamlanmış sayılır. Normalde, her iki tarafın onayladığı durum güncellemeleri ana ağa yüklenmez, yalnızca bir anlaşmazlık ortaya çıktığında veya kanal kapatıldığında ana ağ onayına başvurulur. Kanalı kapatmak gerektiğinde, herhangi bir katılımcı ana ağda işlem talebi yapabilir. Eğer çıkış talebi herkesin oybirliğiyle onayını alırsa, zincir üzerinde hemen uygulanır; yani akıllı sözleşme, kanalın nihai durumundaki her katılımcının bakiyesi üzerinden kilitli kalan fonları dağıtır; eğer diğer katılımcılar onay vermezse, herkesin kalan fonları almak için "mücadele süresi"nin sona ermesini beklemesi gerekir.

Yukarıda belirtildiği gibi, 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 maliyetini düşürebilir.

(# 3.1.2 Zaman Çizgisi

• Şubat 2015'te, Joseph Poon ve Thaddeus Dryja Lightning Network beyaz kağıdının taslağını yayımladı.

• Kasım 2015'te, 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 örneği olduğunu öne sürdü.

• Ocak 2016'da, Joseph Poon ve Thaddeus Dryja, Bitcoin Lightning Network: Ölçeklenebilir Off-Chain Anlık Ödemeler başlıklı beyaz kitabı resmi olarak yayınlayarak Bitcoin için Lightning Network genişletme çö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.

• Kasım 2017'de, Payment Channel çerçevesine dayanan ilk State Channel tasarım standardı olan Sprites önerildi.

• Haziran 2018'de, Counterfactual, durum kanallarıyla tamamen ilgili olan ilk tasarım olan çok ayrıntılı bir Genel Durum Kanalları tasarımı önerdi.

• Ekim 2018'de, Generalised State Channel Networks makalesi State Channel Networks ve Virtual Channels kavramlarını ortaya koydu.

• Şubat 2019'da, durum kanallarının konsepti N-Party Kanalları'na genişletildi, Nitro bu fikre dayalı olarak kurulan ilk protokoldür.

• Ekim 2019'da, Pisa tüm katılımcıların sürekli çevrimiçi olma sorununu çözmek için Watchtowers kavramını genişletti.

• Mart 2020'de, Hydra Hızlı İzomorfik Kanallar'ı önerdi.

(# 3.1.3 Teknik Prensipler

Durum kanallarının çalışma akışı şu şekildedir:

1. Alice ve Bob, kişisel EOA'larından fonları zincir üzerindeki sözleşme adresine yatırarak bu fonların sözleşmede kilitlenmesini sağlar, bu fonlar yalnızca kanal kapandığında kullanıcının bakiyesini iade edecektir; ikisi de imza onayı verdikten sonra, ikisi arasındaki durum kanalı resmi olarak açılır.

2. 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 şifreli imza mesajları ile birbirleriyle iletişim kurar ), blok zinciri ağı ile değil ###. Her iki kullanıcı da çift harcamayı önlemek için her işlem için imza atmak zorundadır. Bu mesajlar aracılığıyla, hesaplarının durum güncellemelerini önerirler ve diğer tarafın önerdiği durum güncellemelerini kabul ederler.

3. Eğer Alice, Bob ile olan işlemi sonlandırmak için kanalı kapatmak istiyorsa, Alice, sözleşmeye kendi hesabının nihai durumunu sunmalıdır. Eğer Bob onaylamak için imzalar, sözleşme nihai duruma göre kilitlenmiş fonları ilgili kullanıcıya geri bırakacaktır. 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.

Eğer belirli bir zamanda, Bob kendi turunda Alice tarafından gönderilen durum güncellemesi imzasına yanıt vermezse, Alice son geçerli durumunu sözleşmeye sunarak bir meydan okuma başlatabilir. Bu geçerli durum, Bob'un önceki imzasını da içerir, böylece son işlemin Bob'un onayını aldığı ve son durumun Bob'un onayını aldığı kanıtlanmış olur. Ardından, sözleşme Bob'a bir süre içinde sözleşmeye bir sonraki durumu sunarak yanıt verme izni verir; eğer Bob yanıt verirse, her iki taraf 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.

(# 3.1.4 Artılar ve Eksiler

Avantajlar:

• Anlık: Durum güncellemeleri neredeyse anlık olup, blok onayı beklemeye gerek yoktur.
• Gizlilik: Sadece nihai durum zincire eklenir, ara durumlar gizlidir.
• Ölçeklenebilirlik: Teorik olarak sonsuz ölçekte genişletilebilir, yeterli katılımcı fonu olduğu sürece.
• Düşük maliyet: off-chain işlemler gas ücreti ödemez

Eksiler:

• Düşük sermaye verimliliği: Fonları kilitlemek gerekiyor
• Çevrimiçi gereksinimler: Katılımcıların sürekli çevrimiçi izleme yapması gerekmektedir.
• Çıkış süresi uzun: Kanalı kapatırken meydan okuma süresini beklemek gerekiyor
• Merkezi düğümlere bağımlılık: Üçüncü taraf izleme hizmetine ihtiyaç var ) gibi Watchtowers ###
• Durum Patlaması: N kullanıcı N(N-1)/2 kanalına ihtiyaç duyar
• Sınırlı likidite: Fonlar belirli bir kanalda kilitlenmiştir.

(# 3.1.5 Uygulama

Bitcoin Lightning Network

Özet: Lightning Network, Bitcoin ağı için küçük ölçekli ödeme kanallarıdır. Genel teknik evrimi 2/2 çok imzalı tek yönlü ödeme kanalı oluşturma, ardından RSMC) Revocable Sequence Maturity Contract### eklenerek iki yönlü ödeme kanalı oluşturma, daha sonra HTLC( Hash Time Lock Contract) eklenerek ödeme kanallarını çoklu ödemelere bağlama sürecinden geçmektedir. Sonunda ödeme ağı, yani Lightning Network oluşturulur. Off-chain küçük ölçekli ödeme kanalları aracılığıyla, ardından aracılar kullanılarak bir işlem ağı oluşturulabilir ve Bitcoin ağının ölçeklenebilirlik sorunları çözülebilir. Lightning Network'ün genel kullanımı, "depozit( kanal oluşturma)→ Lightning Network işlemi( kanal durumunu güncelleme)→ iade/uzlaşma( kanalı kapatma)" sürecine uymaktadır; teorik olarak Lightning Network, saniyede bir milyon işlem işleyebilir.

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ımladı ve Lightning Labs'ı kurdu;
• 15 Mart 2018'de, Lightning Labs ilk Lightning Network ana ağ sürümü olan Lightning Network Daemon (LND) 0.4 sürümünü yayınladı.
• 2021'in başlarında, Lightning Network'ün halka açık kapasitesi ( TVL ) yalnızca yaklaşık 40 milyon dolardı ve yaklaşık 100 bin kullanıcı Lightning Network'ü kullanıyordu.
• 2021 Haziran, El Salvador