Aynen Kardeşim, Solana Duruyor
SOLANA..
15 yıllık Blockchain tarihinin belki de en şeytanlaştırılmış projesi. Özellikle de ülkemizde.
Peki bu önyargının sebebi ne?
Solana ağı, tam 6 kez durdu. ALTI.
8 yazan kaynaklara itibar etmeyiniz, ağdaki 2 performans düşüşünü durma olarak tanımlıyorlar. Tüm Durmaları aşağıda sıraladım.
- 21 Ocak 2022 -> Node yazılımına gelen 1.8.12 Güncellemesi sorun çıkarttı, 1.8.14 güncellemesi ile çözüldü.
- 28 Mart 2022 -> RPC Node Yazılımındaki v1.8 sürümünden dolayı RPC Nodeları, ağda bir fork yarattı. v1.9 Güncellemesi ile çözüldü.
- 30 Nisan 2022 -> Ağ 7 saatliğine durdu. Sebebi belirli değil.
- 1 Haziran 2022 -> Node yazılımındaki bir hata sebebiyle ağ 4.5 saatliğine durdu.
- 30 Eylül 2022 -> Sebebi bilinmiyor.
- 25 Şubat 2023 -> Noda yazılımındaki bir hata sebebiyle ağdaki ekonomik faaliyet durdu, validatör oyları devam etti (Vote-Only Mode). Validatör Node yazılımını 1.13'den 1.14'e güncelleyen nodelar blokları finalize edemedi. 1.13.6 sürümüne geri dönüldü.
Solana dünden bugüne neyi değiştirdi?
1. TCP x UDP x QUIC
Herhangi bir ağ üzerinde veri göndereceğiniz bir uygulama yazıyorsunuz. Önemli bir seçim yapmanız gerekiyor.
İletişimi nasıl sağlayacaksınız?
Normal şartlarda HTTP gibi halihazırda mevcut bir application-layer kullanabilirsiniz.
Fakat ya bir “Blockchain” yazıyorsanız?
Bu noktada kendi application-layer’ınızı yazıyorsunuz demektir. Bu yeni protokol üzerinde iletişimi sağlamak için 3 seçeneğiniz var.
TCP, UDP ve QUIC.
Hangisini seçmeniz gerektiğini nereden bileceksiniz?
1.1) TCP (Transmission Control Protocol)
TCP, bu 3 seçenek arasında seçebileceğiniz en güvenilir protokoldür. İletilen dosyanın eksiksiz bir şekilde iletildiğinden emin olur ve hataları/eksik dosyaları düzeltir.
Blockchain nodeları arasında son bloğunuzu dağıtmak istiyorsunuz.
TCP, sizin için bu veriyi, 2 node arasında elinden gelenin en iyisini yaparak ulaştıracaktır.
- Blok verileri bir node’a eksik mi ulaştı? Verileri tekrar gönderecek ve node’un her şeyi aldığından emin olacaktır.
- İletilen blok verilerinde bazı bozulmalar mı mevcut? TCP her veriye sıra numarası ekler. Bu sayede blok verileri doğru sırayla birleştirilebilir.
- Çok hızlı bir blockchain ağı mı yapmak istiyorsunuz? Bu nodeları zorlayacak olmalı. Belki de sistemde aşırı bir yüklenme oluşturursunuz? Hayır! TCP, “Flow and Congestion Control” isimli akış ve tıkanıklık kontrolü adı verilen teknikler ile bunu engellemeye çalışır.
TCP kullanan bir ağda veri gönderilmeden önce, nodeların kendi aralarında onaylanmış bir bağlantı kurmaları gerekir. Buna “three-way handshake” diyoruz. Anlaşma sağlanmadan veri iletimi başlayamaz.
1.2) UDP (User Datagram Protocol)
UDP, bu 3 seçenek arasında en hızlısı ve basitidir. UDP kullanarak bir veri göndermek isterseniz, veri sadece gider.
Nasıl gitti, karşıdaki beni dinliyor mu, hızlı mı göndersem yavaş mı, acaba ulaşıyor mu bu veriler?????
HİÇBİR ŞEY UMRUMDA DEĞİL.
Ben gönderdim hacı. Benim görevim burada biter. Veri kayıp mı oldu, bozuldu mu, uyarımı yaparım, belki de veriyi çöpe atarım.
Bu, blockchain ağları için çok büyük bir sorun.
UDP için en uygun kullanım alanı canlı yayınlar, görüntülü sohbetler gibi gecikmeye hassas uygulamalar olur. Umursamaz yapısı sayesinde gecikme sıfıra yakın olur.
UDP, bozuk verilerini düzeltmeye çalışmaz. Bozuk veri, bir uyarıyla iletilir ya da çöpe atılır.
Ama UDP’nin MUHTEŞEM bir özelliği mevcut. Bir veriyi aynı anda birden fazla alıcıya gönderebilmek.
Ee tabi, saniyede neredeyse 3 tane blok basıyorsan, bastığın blokları da nodelara en hızlı şekilde gönderebilmen lazım hacı.
Solana, UDP kullanıyordu. Geliştiricilerinin ona 1 kereden bir şey olmaz demesi yüzünden bu hataya düştü ve 6 kere durdu. Zararlı bir alışkanlık olduğunu fark etti ve bıraktı. Peki şu an ne yapıyor?
1.3) QUIC (Quick UDP Internet Connections)
UDP’ye çok benzeyen bir alışkanlığa sahip. Ama durun, kızmayın ona. QUIC, çok daha güvenilir. Gelin inceleyelim.
QUIC, TCP’nin sunduğu her şeyi daha az gecikmeyle ve ekstra özellikler ile sunar. TCP gibi güvenli ve tutarlıdır. TCP’den daha az gecikme sağlar.
TCP, 1970'lerde ortaya çıkan bir protokol. Yılların da emeğiyle hamuru iyice mayalanmış. QUIC ise küçük enişte gibi, 2012'de ortaya çıkıyor. Ve adından da anlaşılabileceği gibi sıfırdan inşa edilmedi.
UDP’nin üzerine inşa edilmesi sayesinde, geçmişe dönük uyumluluğu en üst düzeye çıkarıyor. Ayrıca QUIC bir Google ürünü. 2013'ten beri aktif olarak kullanılıyor. Arkada bir youtube videosu ya da şarkısı açık mı? Açıksa evet, şu an QUIC kullanan bir platformu kullanıyorsunuz.
QUIC, iletişiminizin her zaman şifrelenmesini istediğinizi varsayar. TCP üzerinde güvenli bir iletişim için üç aşamalı bir TCP anlaşması, ardından yine üç aşamalı bir TLS anlaşması yapmalısınız. (TLS’in üzerine gitmiyorum, şifreleme için kullanıldığını bilmeniz yeterli.).
QUIC ise, TLS anlaşmasını bağlantı kurulumuna entegre eder, veri şifreleme görevini kendisine alır. Sadece 1 kere three-way handshake yapmanız yeterlidir.
Güvenli bağlantıya hoşgeldiniz.
Gönderilen her veri ayrı ayrı şifrelenir, bu sayede alıcı mükün olan en kısa sürede şifreleri çözmeye başlar.
QUIC övmeye devam edeceğim biraz daha. QUIC’in mantığını anladıysanız atlayıp devam ediniz lütfen.
TCP üzerinden büyük bir dosya indiriyorsunuz. Ama bir anda Mobil Veri’de olduğunuzu fark ettiniz. Haydaaa. Hemen WiFi açtınız ve anlık olarak bağlantınız kesildi. TCP şimdi yeniden bağlantı kuracak da, önceden indirilen dosyalar kontrol edilecek… Ölme eşeğim ölme. QUIC kullanıyorsanız her şey yolunda. Ağ değiştirseniz bile bağlantınızın devam etmesini sağlayan bir “Connection Migration” özelliği mevcut.
Eee, sonuç? Sonuç şu:
Solana UDP kullanan bir protokoldü. Yani nodelar arasındaki iletişim takır takır hiçbir sorgulama olmadan gerçekleşiyordu. Ağdaki herhangi bir aşırı yüklenme, UDP’nin umursamazlığı sonucu eksik/hatalı veri miktarını artırıyordu. Ayrıca bazı nodelar hem gelen verileri işleyip hem de ağı yakalayamıyordu. BFT consensus’ların en büyük sıkıntısı, ağdaki nodeların %33+1'i ağdan düşerse consensusun durmasıdır. Solana’ya da bunlar oluyordu işte.
Solana artık QUIC kullanıyor. Nodelar arası iletişim garantileniyor ve güvenli hale getiriliyor. Bu sayede verilerin doğruluğu ve güvenilirliği de artıyor.
2. Stake-weighted QoS
Proof of Stake (PoS) sistemlerin nasıl çalıştığını inceleyelim.
- PoS ile çalışan ağlarda, her blok başına bir Lider seçilir.
- Node’lar kendilerine gelen işlemleri Lider Node’a gönderir.
- Lider Node bu işlemleri alır, bir blok oluşturur.
Bize bu kadarı yeter. Kafa karıştırmayalım.
Ethereum’da validatör olmak için 32 Ether stake etmeniz gerekiyor. Avalanche üzerinde bu sayı 2000 AVAX. Solana’da ise SIFIR SOL. Evet, sıfır.
Solana üzerinde validatör node kurmak için SOL stake etmenize gerek yok. Fakat bu sistemin bir sıkıntısı mevcut.
Sunucu kiralamayı bilen ya da evine Süper Bilgisayar alabilecek maddi güce sahip herkes Solana Validatör Node kurabilir.
Sıkıntıyı sezdiniz mi?
Ağ, spam yemeye açık. Node kurup, bu node üzerinden istediğiniz kadar işlemi Lider Node’a gönderebilirsiniz.
+ Ne oldu?
- Ağ çöktü.
+ Neden?
- Çünkü Node’ların bir ağ kapasitesi var. Aşırı fazla işlem gelirse ağ bant genişliği bunu kaldıramaz ve bumm. Yukarıda bahsettiğim BFT Consensus sorunundan dolayı ağa yetişemeyen node’lar düşer ve oy çoğunluğu yoksa ağ durur.
Solana mühendisleri bunu çözmek için çok akıllıca bir sistem geliştirdi. Direkt örnek üzerinden gidelim.
Diyelim ki ağdaki stake oranının %1'ine sahip bir Validatör Node çalıştırıyorsunuz. Mevcut bloğun en az %1'i sizin gönderdiğiniz işlemlerden oluşacak. %1'lik hakkınız dolana kadar kimse sizin ağ üzerindeki trafiğinizi baskılayamayacak.
Peki herhangi bir stake’e sahip olmayan Validatör Node’lar, ya da yazılımsal olarak asla bir stake’e sahip olamayacak RPC Node’lar?
Bu Nodelar, stake oranında yer kaplayan bir validatör node’a işlemleri gönderecekler.
İşte biz buna Stake-Weight Quality of Service (Stake-Weight QoS) Diyoruz. Ağdaki aşırı yüklenmenin önüne geçiyoruz.
3. Fee Markets
Solana üzerinde kullanıcıların ödeyeceği ücretler sabitti, işlem başı 0.000005 SOL. İşte bunu değiştiriyoruz.
+ Fee Market nedir?
- Kısaca şudur, kullanıcılar işlemler için istedikleri kadar ücret verebilirler ve kendi işlemlerinin bloğa ilk sıralardan girmesini sağlayabilirler. Yani işleminiz için fazla ödeme yaparak blok içerisinden yer satın alıyorsunuz.
+ Bunun ağa katkısı ne olacak peki?
- İşlem ücretlerinin sabit ve düşük olması sebebiyle herkes ağa işlem spamlayabiliyor ve yukarıda bahsettiğimiz ağ bant genişliği mevzusu sebebiyle node’lar ağdan kopuyor. Bummm
Görselden de görülebileceği gibi Fee Market (Priority Fees) şu an ağ üzerinde aktif. Fakat siz bunu Mainnet üzerinde kullanamıyorsunuz kriptovarlık cüzdanı kullanan sıradan kullanıcılar olarak. Çünkü cüzdanlara henüz güncelleme gelmedi. Cüzdan güncellemeleri sadece Devnet üzerinde aktif.
Aktif olmama sebebi şu, mecvut şartlarda ağdaki ortalama işlem ücretleri bilinemeyecek ve herkesin kafasından fiyat vermesiyle ağ sıradan kullanıcılar için kullanılamaz hale gelecek. Ethereum Gas Fee’lerinin takip edilebildiği gibi Solana Gas Fee’lerinin de takip edilebileceği API’lar geliştiriliyor şu an (https://github.com/solana-labs/solana/pull/27278). Ortalama fiyat tarifesi belirlenebildiği zaman Solana Cüzdanları gerekli güncellemeleri yapacaklar.
QUIC, Stake-Weight QoS ve Fee Market ile ağ sorunlarını çözdü. 20 Nisan 2023 günü MadLads NFT Mint’i public olarak gerçekleşti, ağ en yoğun zamanını yaşadı ve bir sıkıntı ortaya çıkmadı.
Ağdaki durmaların en önemli sebebi de tek bir validatör client olmasından kaynaklanıyor. Tek bir satırdaki kod hatası tüm ağda sorun yaratıyor. Solana’da şu an geliştirilen DÖRT adet yeni consensus client var.
Bunların ikisi aktif durumda.
1. Solana Labs tarafından geliştirilen,
2. Jito Labs tarafından geliştirilen.
3 tanesi ise geliştirilme aşamasında.
Benim en çok beklediğim ise FireDancer. 2023 Kasım’da, Breakpoint sırasında aktif hale getirilmesini ve Solana Mainnet’in beta sürecinden çıkarak Solana 2.0 olarak duyurulacağını düşünüyorum.
Buraya kadar okuduğunuz için teşekkür ederim. Umarım keyif almışsınızdır.
Yazıyı paylaşarak destek olabilirsiniz.
Alperen Tunçkıran
Solana University Ambassador
Twitter: @BlockofChain