off-chain ölçeklenme Derinlik analizi

1. Ölçeklenmenin Gerekliliği

Blockchain'ın gelecekteki vizyonu merkeziyetsizlik, güvenlik ve ölçeklenebilirliktir, ancak genellikle bunlardan sadece iki tanesi gerçekleştirilebilir, bu da imkansız üçgen sorunu olarak adlandırılır. Yıllar boyunca, insanlar merkeziyetsizlik ve güvenliği sağlarken blockchain'in işlem hacmini ve hızını artırmanın yollarını keşfetmeye çalıştılar; yani ölçeklendirme sorununu çözmek, bu da mevcut blockchain gelişim sürecinin en sıcak konularından biridir.

Blok zincirinin merkeziyetsizliği, güvenliği ve ölçeklenebilirliği tanımı:

• Merkeziyetsizlik: Herkes, sistemin üretim ve doğrulamasına katılan bir düğüm haline gelebilir, düğüm sayısı arttıkça merkeziyetsizlik derecesi artar ve ağın az sayıda büyük merkezi katılımcı tarafından kontrol edilmesi sağlanmaz.

• Güvenlik: Sistem kontrolünü ele geçirmenin maliyeti ne kadar yüksekse, güvenlik o kadar yüksektir; zincir, daha büyük bir katılımcı oranına karşı direncini artırabilir.

• Ölçeklenebilirlik: Blok zincirinin büyük miktarda işlemi işleme yeteneği.

Bitcoin ağı üzerindeki ilk büyük hard fork, ölçeklenebilirlik sorunundan kaynaklandı. Kullanıcı sayısı ve işlem hacmi arttıkça, her blok için 1MB'lik üst sınırı olan Bitcoin ağı tıkanıklık sorunlarıyla karşılaşmaya başladı; 2015 yılından itibaren Bitcoin topluluğu ölçeklenebilirlik konusunda ayrılığa düştü, bir taraf blokların genişletilmesini desteklerken, diğer taraf Segwit ayrıştırılmış tanık çözümünü kullanarak ana zincir yapısını optimize etmenin gerektiğine inanıyordu. 1 Ağustos 2017'de, blok genişletmeyi destekleyen Bitcoin ABC, 8MB istemci sistemini geliştirmeye başladı ve bu, Bitcoin tarihindeki ilk büyük hard fork'a yol açarak yeni bir kripto para birimi olan BCH'nin doğmasına neden oldu.

Ethereum ağı da ağ güvenliği ve merkeziyetsizliği sağlamak için belirli bir ölçeklenebilirlikten feragat etmeyi seçmiştir. Ethereum ağı, Bitcoin ağının işlem hacmini sınırlamak için blok boyutunu kısıtlaması gibi bir yaklaşım benimsememiştir; bunun yerine tek bir blokta yer alabilecek yakıt ücretleri için bir üst sınır koyarak dolaylı bir değişim gerçekleştirmiştir. Ancak her iki durumda da amaç, Trustless Consensus'u sağlamak ve düğümlerin geniş bir dağılımını güvence altına almaktır.

2017'deki CryptoKitties, DeFi yazı, ardından GameFi ve NFT gibi zincir üstü uygulamaların ortaya çıkmasıyla birlikte, 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 artmasına, hesaplama 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, blok zinciri genişleme sorunlarının acilen çözülmesi gerekmektedir. İdeal genişleme çözümü: merkeziyetsizlik ve güvenlikten ödün vermeden, ağın işlem hızını ve işlem hacmini mümkün olduğunca artırmaktır.

2. Ölçeklenebilirlik Çözüm Türleri

"Ana ağın bir katmanını değiştirip değiştirmeyeceği" standardına göre, genişletme planlarını on-chain genişletme ve off-chain genişletme olarak iki ana kategoriye ayırıyoruz.

2.1 Zincir üstü genişleme

Temel Kavram: Bir ana ağ protokolünün bir katmanını değiştirerek ölçeklendirme etkisi sağlamak için bir çözüm, mevcut ana çözüm parçalama (sharding) yöntemidir.

Zincir üzerinde ölçekleme için çeşitli çözümler bulunmaktadır, bu makalede detaylandırılmayacak, aşağıda iki çözüm kısaca sıralanmıştır:

• 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" derecesini azaltacaktır.

• İkinci seçenek parça parça ayırmaktır, blok zinciri defterini birkaç parçaya bölmek, artık her düğüm tüm defter tutma işlemlerine katılmamakta, bunun yerine farklı parçalar yani farklı düğümler farklı defter tutma işlemlerinden sorumlu olmaktadır, paralel hesaplama aynı anda birden fazla işlemi işleyebilir; bu, düğümlerin hesaplama yükünü ve katılım eşiğini azaltabilir, işlem işleme hızını ve merkeziyetsizleşme derecesini artırabilir; ancak bu, tüm ağın hesaplama gücünün dağıtılması anlamına gelir ve bu da tüm ağın 'güvenliğini' azaltabilir.

Ana ağ protokolünün kodunu değiştirmek, altında yatan herhangi bir küçük güvenlik açığının tüm ağın güvenliğini ciddi şekilde tehdit edebileceği için, öngörülemeyen olumsuz etkilere yol açabilir. Ağ, bir çatallaşma veya kesinti onarım güncellemesi yapmak zorunda kalabilir. Örneğin, 2018'deki Zcash enflasyon güvenlik açığı olayı: Zcash'in kodu Bitcoin 0.11.2 versiyon kodu üzerinde değiştirilmiştir. 2018'de bir mühendis, altında yatan kodda yüksek riskli bir açığın bulunduğunu keşfetti; yani, token'lar sonsuz şekilde artırılabiliyordu. Takım, açığı gizlice düzeltmek için 8 ay harcadı ve açığın düzeltildiği ancak ardından bu olayı kamuoyuna 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çeklenme çözümleri, Layer2 ve diğer çözümler olarak daha da alt kategorilere ayrılabilir:

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şime girmesi gerektiğini belirtir ve kullanıcılar arasındaki etkileşimlerin off-chain gerçekleştirilmesini sağlar. Bu, kullanıcıların işlem süresi ve maliyetlerini azaltır ve işlem sayısında bir sınırlama olmaksızın işlem yapmalarını sağlar.

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ö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ı içeren dolandırıcılık kanıtına dayanarak ) tahkim eder. Katılımcılar, blok zinciri ağında sözleşmeyi kurduktan sonra bir miktar para yatırır ve kilitler; her iki taraf da imza onayı verdikten sonra, kanal resmen 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 (, tek koşul, aktarım net değerlerinin yatırılan token toplamını aşmamasıdır ). Katılımcılar sırayla birbirlerine durum güncellemeleri gönderir ve karşı tarafın imza onayını bekler. Diğer taraf imza onayını verdiğinde, bu durum güncellemesi tamamlanmış sayılır. Normal koşullar altında, 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ı gerektirir. Kanalın kapatılması gerektiğinde, herhangi bir katılımcı ana ağda bir işlem talebi oluşturabilir; eğer çıkış talebi tüm katılımcıların imza onayı alırsa, zincir üzerinde derhal uygulanır. Yani, akıllı sözleşme, kanalın son durumundaki her katılımcının bakiyesi doğrultusunda kilitli kalan fonları dağıtır; eğer diğer katılımcılar imza onayı vermezse, herkesin kalan fonları almak için "mücadele süresi"nin bitmesini beklemesi gerekir.

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 Çizgisi

• 2015/02, Joseph Poon ve Thaddeus Dryja, Lightning Network beyaz kitabı taslağını yayınladılar.
• 2015/11, Jeff Coleman ilk kez State Channel kavramını sistematik olarak özetledi ve Bitcoin'in Payment Channel'ının State Channel kavramındaki bir alt örnek olduğunu önerdi.
• 2016/01, Joseph Poon ve Thaddeus Dryja, Bitcoin Lightning Network: Scalable Off-Chain Instant Payments başlıklı beyaz kitabı resmi olarak yayımlayarak Bitcoin için Payment Channel( ödeme kanalı) genişletme çözümünü önerdiler. Bu çözüm, yalnızca Bitcoin ağı üzerindeki para transferi ödemelerini işlemek için kullanılır.
• 2017/11, Payment Channel çerçevesine dayanan ilk State Channel tasarım standardı Sprites önerildi.
• 2018/06, Counterfactual çok ayrıntılı bir Genel Devlet 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 kanalı kavramı N-Party Channels'a genişletildi, Nitro bu fikir üzerine inşa edilen 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ını ö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 zincire işlem göndererek akıllı sözleşmenin durumunu değiştirir. Dezavantajı, yukarıda tartışılan zaman ve maliyet sorunlarını beraberinde getirmesidir.

Şekil 2, çoğu durum kanalı protokolünün izlediği genel iş akışını göstermektedir: İyimser bir senaryoda, Alice ve Bob daha öncekiyle aynı işlemleri gerçekleştirmeleri gerekmektedir, ancak bu sefer durum kanalı kullanarak, zincir üstü sözleşmelerle etkileşimde bulunmak yerine.

• İlk adım, Alice ve Bob kişisel EOA'larından ( adresine 1,2) kadar para yatırarak etkileşimde bulunurlar, bu fonlar sözleşmede kilitlenir ve yalnızca kanal kapandığında bakiyeleri kullanıcılara iade edilir; ikili imzayı onayladıktan sonra, ikisi arasında durum kanalı resmi olarak açılmış olur.
• İkinci adımda, Alice ve Bob bu kanal üzerinden 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 (, blok zincir ağı ile iletişim kurmak yerine ). Her iki kullanıcı da her işlem için imza atmak zorundadır, böylece çift harcama kötü niyetli eylemlerini engellerler. Bu mesajlar aracılığıyla, hesaplarının durum güncellemelerini önerirler ve karşı tarafın önerdiği durum güncellemelerini kabul ederler.
• Üçüncü adım, eğer Alice, Bob ile olan işlemi kapatmak istiyorsa, Alice, sözleşmeye kendi hesabının son durumunu ( etkileşim 3) olarak sunmalıdır. Bob onaylayarak imzalarsa, sözleşme son duruma göre kilitli fonları ilgili kullanıcıya geri serbest bırakacaktır ( etkileşim 4,5). Eğer Bob imza ile yanıt vermezse, sözleşme itiraz süresi sona erdikten sonra kilitli fonları ilgili kullanıcıya geri serbest bırakacaktır.

Şekil 3, olumsuz durumlarda durum kanallarının çalışma akışını göstermektedir: İlk olarak, iki katılımcı ( etkileşim 1, 2) miktarında para yatırır, ardından durum güncellemelerini ( mavi kesikli hat ) ile değiştirmeye başlarlar. Belirli bir zamanda, Bob kendi turunda Alice tarafından gönderilen durum güncellemesi imzasına ( etkileşim 3) yanıt vermezse, bu durumda Alice, sözleşmeye en son geçerli durumunu sunarak bir meydan okuma başlatabilir ( etkileşim 4). Bu geçerli durum, Bob'un önceki imzasını da içerir ve son işlemin Bob'un onayını aldığını kanıtlar; son durum Bob'un onayı ile alınmış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 izin verir; eğer Bob yanıt verirse, ikili durum kanalı içinde işlem yapmaya devam edebilir; eğer Bob bu süre içinde yanıt vermezse, sözleşme durumu otomatik olarak kapatır ve parayı Alice'e iade eder ( etkileşim 5).

3.1.4 Artıları ve Eksileri

Avantajlar:

• Yüksek ölçeklenebilirlik: sınırsız işlem yapılabilir
• Düşük gecikme: İşlemler anında tamamlanır
• Düşük maliyet: off-chain işlemlerin neredeyse maliyeti yoktur
• Gizlilik: off-chain işlemler ana zincirde kaydedilmez
• Kullanılabilirlik: Ana zincirde bir sorun olsa bile, durum kanalları kullanılabilir.

Dezavantajlar:

• Fonları kilitleme: Taraflar fonları kilitlemelidir.
• Sürekli çevrimiçi: Katılımcıların kanal durumunu izlemek için sürekli çevrimiçi olmaları gerekir.
• Kanal oluşturma maliyeti: Kanal açmak için ana zincir ile etkileşim gereklidir, maliyet yüksektir.
• Kapatma gecikmesi: Kanalı kapatmak için meydan okuma süresinin beklenmesi gerekir.
• Sınırlı karşı taraf: Kanal yalnızca belirli bir karşı tarafla işlem yapabilir.
• Geniş kapsamda kullanım için uygun değil: sıradan kullanıcılar için dostça değil

3.1.5 Uygulama

Bitcoin Lightning Network

Genel Bakış:

Lightning Network, Bitcoin ağının küçük ödeme kanalıdır. Genel teknik evrimi, 2/2 çoklu imza ile tek yönlü ödeme kanalı oluşturma, RSMC(Revocable Sequence Maturity Contract) eklendikten sonra çift yönlü ödeme kanalı oluşturma, daha sonra HTLC(Hash Time Lock Contract) eklendikten sonra ödeme kanallarını çoklu ödemelere bağlama aşamalarını geçirmiştir. Sonuç olarak, ödeme ağı olan Lightning Network oluşturulmuştur. Off-chain küçük ödeme kanalları aracılığıyla ve 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/hesap kapama(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'ün beyaz kağıdının taslağını yayımladı;
• 2016'nın Ocak ayında resmi beyaz kitabı yayımlandı ve Lightning Labs kuruldu;
• 15 Mart 2018'de, Lightning Labs ilk Lightning Network ana ağ versiyonu Lightning Network Daemon (LND) 0.4 sürümünü yayımladı.
• 2021 yılının başında, Lightning Network'ün kamu kapasitesi (TVL) sadece yaklaşık 40 milyon dolardı.