Off-chain Ölçeklenebilirlik Derinlemesine Analiz

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

1. Genişlemenin Gerekliliği

Blok zincirinin gelecekteki vizyonu merkeziyetsizlik, güvenlik ve ölçeklenebilirliktir. Ancak genellikle blok zinciri bunlardan yalnızca ikisini gerçekleştirebilir, bu da blok zincirinin imkansız üçgen problemi olarak adlandırılır. Yıllar boyunca insanlar, merkeziyetsizlik ve güvenliği garanti ederken blok zincirinin işlem hacmini ve işlem hızını artırmanın yollarını keşfetmeye çalıştılar, yani ölçeklendirme sorununu çözmeyi, bu da mevcut blok zinciri gelişim sürecindeki sıcak konulardan biridir.

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

• Merkeziyetsizlik: Herkes blockchain sistemine katılmak için bir düğüm olabilir, düğüm sayısı arttıkça merkeziyetsizlik derecesi artar ve ağın az sayıdaki katılımcının kontrolünden uzak durmasını sağlar.

• Güvenlik: Bir blok zinciri sisteminin kontrolünü elde etme maliyeti ne kadar yüksekse, güvenlik o kadar yüksektir, zincir daha yüksek oranda katılımcıların saldırılarına karşı direnç gösterebilir.

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

Bitcoin ağının ilk büyük hard fork'u, ölçeklenme sorunlarından kaynaklanmaktadır. Bitcoin kullanıcı sayısı ve işlem hacmi arttıkça, 1MB blok sınırına sahip ağ tıkanıklık yaşamaya başladı. 2015 yılında, Bitcoin topluluğu ölçeklenme sorunu konusunda anlaşmazlıklar yaşadı; bir taraf blok boyutunun artırılmasını desteklerken, diğer taraf Segwit'in ana zincir yapısını optimize etmesini destekledi. 1 Ağustos 2017'de, büyük blokları destekleyen taraf, 8MB istemci sistemini geliştirerek çalışmaya başladı ve bu durum Bitcoin'in ilk büyük hard fork'unu doğurdu, bu arada yeni bir kripto para birimi BCH ortaya çıktı.

Aynı şekilde, Ethereum ağı da ağ güvenliğini ve merkeziyetsizliği sağlamak için belirli bir ölçeklenebilirlikten feragat etmiştir ve işlem hacmini sınırlamak için tek bir blokta kabul edilebilecek yakıt ücretine bir üst sınır koymuştur. Amaç, güvenilmez bir konsensüs sağlamak ve düğümlerin geniş bir şekilde dağıtılmasını temin etmektir.

2017'deki CryptoKitties, DeFi yazı, ardından GameFi ve NFT gibi zincir üzerindeki uygulamaların ortaya çıkmasıyla birlikte, piyasada işlem hacmine olan talep sürekli artmaktadır, ancak Ethereum hala saniyede yalnızca 15-45 işlem gerçekleştirebilmektedir. Bu, işlem maliyetlerinin artmasına ve uzlaşma sürelerinin uzamasına neden oldu; çoğu DApp, işletim maliyetlerini karşılamakta zorlanıyor, bu da tüm ağı kullanıcılar için hem yavaş hem de pahalı hale getiriyor. Blok zinciri genişletme sorunu acilen çözülmelidir. İdeal genişletme çözümü, merkeziyetsizlik ve güvenlikten ödün vermeden, blok zinciri ağının işlem hızını ve hacmini mümkün olduğunca artırmaktır.

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

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

2.1 Zincir Üstü Ölçeklendirme

Kilit kavram: Bir ana ağ protokolünü değiştirerek ölçeklenebilirlik sağlama çözümü, mevcut ana çözüm parçalama (sharding) olarak belirlenmiştir.

Blockchain genişletme için çeşitli çözümler vardır, bu makalede detaylandırılmayacak, kısaca iki tanesi listelenecektir:

• Birinci öneri, blok alanını genişletmek, her blokta paketlenen işlem sayısını artırmaktır, ancak bu, yüksek performanslı düğüm cihazlarına olan gereksinimleri artıracak, düğümlerin katılım eşiğini yükseltecek ve "merkeziyetsizlik" seviyesini azaltacaktır.

• İkinci seçenek parçalama, blok zinciri defterini birden fazla parçaya ayırmak, farklı parçaların farklı defter tutma işlemlerini üstlenmesi ve eş zamanlı hesaplamanın birden fazla işlemi aynı anda işleyebilmesidir. Bu, düğüm hesaplama yükünü ve katılım engelini azaltabilir, işlem işleme hızını ve merkeziyetsizliği artırabilir, ancak genel ağın "güvenliğini" azaltacaktır.

Ana ağ protokolündeki bir değişiklik, temel güvenlik açığı nedeniyle ağın güvenliğini ciddi şekilde tehdit edebileceği için öngörülemeyen olumsuz etkiler yaratabilir. Örneğin, 2018'de Zcash'in enflasyon açığı olayı: Zcash kod tabanı, Bitcoin 0.11.2 sürümüne dayanarak değiştirilmişti. 2018'de, temel kodda yüksek tehlikeli bir açığın bulunduğu ve tokenlerin sınırsız bir şekilde artırılabildiği keşfedildi. Ekip, bu olayı gizlice düzeltmek için 8 ay harcadı ve onarımdan sonra olayı kamuoyuna açıkladı.

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çeklendirme çözümleri, Layer2 ve diğer çözümler olarak daha da ayrılabilir:

3. off-chain ölçeklenme çözümleri

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şimde bulunması gerektiğini belirtir ve kullanıcılar arasındaki etkileşimlerin off-chain gerçekleştirilmesini sağlayarak kullanıcıların işlem sürelerini ve maliyetlerini azaltır ve işlem sayısında herhangi bir kısıtlama olmaksızın gerçekleştirilmesini sağ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 ç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ı ( imzalı ve zaman damgalı dolandırıcılık kanıtlarına ) göre hakemlik eder. Katılımcılar, blok zinciri ağına sözleşmeyi dağıttıktan sonra, fonları yatırır ve kilitler, her iki tarafın onay imzasıyla birlikte kanal resmi olarak açılır. Kanal, katılımcılar arasında sınırsız sayıda off-chain ücretsiz işlem yapmalarına izin verir (, yalnızca transfer net değerleri yatırılan toplam token miktarını aşmadığı sürece ). Katılımcılar sırayla birbirlerine durum güncellemeleri gönderir ve diğerinin onay imzasını bekler. Diğer taraf onay imzasını verdiğinde, bu durum güncellemesi tamamlanmış sayılır. Normal şartlar altında, 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ğın onayına ihtiyaç duyulur. 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 tarafından 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 bakiyesine göre, kalan kilitli fonları dağıtır; eğer diğer katılımcılar onay vermezse, herkes kalan fonları almak için "mücadele süresinin" bitmesini beklemek zorundadır.

Sonuç olarak, 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 maliyetlerini düşürebilir.

3.1.2 Zaman Çizgisi

• 2015/02, Joseph Poon ve Thaddeus Dryja, Lightning Network beyaz kağıdının taslağını yayınladı.

• 2015/11, Jeff Coleman, State Channel kavramını sistematik olarak ilk kez özetledi ve Bitcoin'in Payment Channel'ının State Channel kavramındaki bir alt vaka olduğunu öne sürdü.

• 2016/01, 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 Lightning Network'ün genişletme çözümü olan Payment Channel ( ödeme kanalı )'ı önerdiler. Bu çözüm yalnızca Bitcoin ağı üzerindeki para transferi ödemelerini işlemek için kullanılmaktadır.

• 2017/11, Payment Channel çerçevesine dayanan ilk State Channel tasarım standardı Sprites önerilmiştir.

• 2018/06, Counterfactual, tamamen durum kanallarıyla ilgili ilk tasarım olan çok ayrıntılı bir Genel Durum Kanalları tasarımını sundu.

• 2018/10, Generalised State Channel Networks makalesi, 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ını önerdi.

3.1.3 Teknolojik Prensip

Şekil 1, geleneksel zincir üzerindeki çalışma akışını göstermektedir: Alice ve Bob, ana ağda dağıtılan akıllı sözleşmelerle etkileşime geçmektedir, 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.

Şekil 2, çoğu durum kanalı protokolünün takip ettiği genel iş akışını göstermektedir: İyimser bir durumda, Alice ve Bob önceki işlemleri aynı şekilde gerçekleştirmeleri gerekmektedir, ancak bu sefer durum kanalı kullanarak, zincir üstü sözleşmelerle etkileşime geçmek yerine.

• İlk adım, Alice ve Bob kişisel EOA'larından ( adresine para yatırarak etkileşimde bulunurlar, 1,2), bu fonlar sözleşmede kilitlenir ve yalnızca kanal kapandığında bakiye kullanıcıya iade edilir; ikili imza onayladıktan sonra, ikili arasındaki durum kanalı resmi olarak açılmış olur.

• İkinci adımda, 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 şifreli imzalı mesajlar aracılığıyla birbirleriyle iletişim kurarlar (, blockchain 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, hesaplarının durum güncellemelerini önerir ve karşı tarafın önerdiği durum güncellemelerini kabul ederler.

• Üçüncü adım, Alice Bob ile olan işlemi kapatmak istediğinde, Alice sözleşmeye kendi hesabının nihai durumunu ( etkileşim 3) göndermelidir. Eğer Bob onaylayarak imzalar ise, sözleşme nihai duruma göre kilitlenmiş 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 kilitlenmiş fonları ilgili kullanıcıya geri serbest bırakacaktır.

Şekil 3, olumsuz bir durumda durum kanalının çalışma akışını göstermektedir: Öncelikle, iki katılımcı ( etkileşim 1, 2) miktarını yatırır, ardından durum güncellemelerini ( mavi kesikli çizgi ) değiş tokuş etmeye başlar. Farz edelim ki, bir noktada, Bob, Alice'in gönderdiği durum güncelleme imzasına ( etkileşim 3) yanıt vermez. Bu durumda, Alice, sözleşmeye kendi son geçerli durumunu sunarak bir meydan okuma başlatabilir ( etkileşim 4); bu geçerli durum, Bob'un önceki imzasını da içermektedir ve böylece son işlemin Bob'un onayını aldığını kanıtlar, son durum Bob'un onayını almıştır. Daha sonra, sözleşme Bob'a bir süre içinde bir sonraki durumu sözleşmeye sunarak yanıt verme imkanı tanır; eğer Bob yanıt verirse, iki taraf durum kanalı içinde 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 parayı Alice'e geri döndürür ( etkileşim 5).

3.1.4 Artılar ve Eksiler

Avantajlar:

• Anlık: off-chain işlemler neredeyse anlıktır
• Ölçeklenebilirlik: off-chain işlem sayısı sınırlı değil
• Gizlilik: Yalnızca kanalın nihai durumu zincire aktarılacaktır.
• Düşük ücret: on-chain işlem ücretlerini büyük ölçüde azalttı.

Eksiler:

• Kullanılabilirlik: Katılımcıların rakiplerin meydan okumalarına yanıt vermek için sürekli çevrimiçi olmaları gerekir.
• Fon verimliliği: Fonların kilitlenmesi gerekiyor
• Merkezileşme riski: Koridor ağının uzun vadeli gelişimi, bazı düğümlerin merkezileşmiş "düğüm" haline gelmesine neden olabilir.
• Karmaşıklık: Durum güncelleme mekanizması oldukça karmaşık.

3.1.5 Uygulama

Bitcoin Lightning Network

Genel Bakış:

Lightning Network, Bitcoin ağı için küçük ölçekli ödeme kanalıdır. Tüm teknolojik evrimi şu aşamalardan geçmiştir: 2/2 çok imzalı tek yönlü ödeme kanalı kurulumu, RSMC( Revocable Sequence Maturity Contract) eklenerek çift yönlü ödeme kanalı oluşturulması, ardından HTLC( Hash Time Lock Contract) eklenerek ödeme kanallarının çoklu ödeme ile bağlantı kurması, nihayetinde ödeme ağı olan Lightning Network'ün inşası. Off-chain küçük ölçekli ödeme kanalları aracılığıyla, aracıların yardımıyla bir ticaret ağı oluşturularak Bitcoin ağı 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/hesaplama( kanal sonlandırma)" sürecine uymaktadır; teorik olarak, Lightning Network her saniyede 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ınladılar;
• 2016 yılında resmi beyaz kitap yayımlandı ve Lightning Labs kuruldu;
• 15 Mart 2018'de, Lightning Labs ilk Lightning Network ana ağ sürümü Lightning Network Daemon (LND) 0.4 sürümünü yayınladı.
• 2021 yılı başında, Lightning Network'ün kamu kapasitesi (TVL) yalnızca yaklaşık 40 milyon dolardı ve yaklaşık 100 bin kullanıcı Lightning Network'ü kullanıyordu.
• Haziran 2021'de El Salvador, Bitcoin'i yasal para birimi olarak kabul etti ve Eylül'de Lightning Network tabanlı Chivo cüzdanını piyasaya sürdü.
• 2022 yılında, Cash App ve OKX, Kraken, Bitfinex dahil 26 kripto para borsa platformu, anlık ve ucuz BTC para yatırma ve çekme işlemleri ile transfer özelliklerini desteklediğini duyurdu.
• Ekim 2022'de, Lightning Labs Taproot tabanlı yeni protokolü - Taro protocol(alpha versiyonunu) duyurdu, amac