Solana Teknoloji Mimarisi Yeniden İnceleniyor: İkinci Baharını mı Yaşayacak?

Solana, yüksek verimlilikte bir blockchain platformudur ve yüksek işlem hacmi ile düşük gecikmeyi sağlamak için benzersiz bir teknik mimari kullanmaktadır. Temel teknolojileri arasında, işlem sırasını ve küresel saati güvence altına alan Proof of History (POH) algoritması, blok üretim hızını artıran Leader Rotation Schedule ve Tower BFT konsensüs mekanizması bulunmaktadır. Turbine mekanizması, büyük blokların yayılmasını optimize etmek için Reed-solomon kodlamasını kullanır. Solana Sanal Makinesi (SVM) ve Sealevel paralel yürütme motoru, işlem yürütme hızını artırır. Bunlar, Solana'nın yüksek performansını sağlamak için yapılandırılmış tasarım unsurlarıdır, ancak aynı zamanda ağ kesintisi, işlem hatası, MEV sorunları, durum büyümesinin çok hızlı olması ve merkezileşme gibi bazı sorunları da beraberinde getirmektedir; bu makalede bu mekanizmaların neden olduğu sorunları da vurguladık.

Solana ekosistemi hızla gelişiyor, ilk yarıda tüm veri göstergeleri hızla ilerledi, özellikle DeFi, altyapı, GameFi/NFT, DePin/AI ve tüketici uygulamaları alanlarında. Solana'nın yüksek TPS'si ve tüketici uygulamalarına yönelik stratejisi ile marka etkisi zayıf olan ekosistem, girişimciler ve geliştiriciler için zengin girişim fırsatları sunuyor. Tüketici uygulamaları açısından, Solana, blok zinciri teknolojisinin daha geniş alanlarda uygulanmasını teşvik etme vizyonunu sergiliyor. Solana Mobile gibi projeleri destekleyerek ve tüketici uygulamaları için özel olarak yapılandırılmış SDK'lar geliştirerek, Solana blok zinciri teknolojisini günlük uygulamalara entegre etmeye odaklanıyor, böylece kullanıcı kabulünü ve kolaylığını artırıyor. Örneğin, bir spor fitness uygulaması, blok zinciri ve mobil teknolojiyi birleştirerek kullanıcılara yenilikçi bir fitness ve sosyal deneyim sunuyor. Şu anda birçok tüketici uygulaması en iyi iş modeli ve pazar konumunu keşfetmeye devam etmesine rağmen, Solana'nın sunduğu teknik platform ve ekosistem desteği, bu yenilikçi girişimlere kesinlikle güçlü bir destek sağlıyor. Teknolojinin daha da gelişmesi ve pazarın olgunlaşmasıyla, Solana'nın tüketici uygulamaları alanında daha fazla atılım ve başarı örneği gerçekleştirmesi bekleniyor.

Solana, blockchain sektöründe yüksek işlem hacmi ve düşük işlem maliyetleri ile önemli bir pazar payı elde etmesine rağmen, diğer yeni ortaya çıkan halka açık blok zincirlerinden gelen şiddetli bir rekabetle karşı karşıya kalmaktadır. EVM ekosistemindeki potansiyel bir rakip olan Base'in zincir üzerinde aktif adres sayısı hızla artmaktadır. Aynı zamanda, Solana'nın DeFi alanındaki toplam kilitli değeri (TVL) tarihi bir zirveye ulaşmasına rağmen, Base gibi rakipler de hızlı bir şekilde pazar payı kazanmaktadır ve Base ekosisteminin finansmanı, Q2 çeyreğinde Solana'yı ilk kez geçmiştir.

Solana, teknik ve pazar kabulü açısından belirli bir başarı elde etmesine rağmen, Base gibi rakiplerden gelen zorluklarla başa çıkmak için sürekli yenilik ve gelişim gerekmektedir. Özellikle ağın istikrarını artırma, işlem başarısızlık oranını düşürme, MEV sorununu çözme ve durum büyüme hızını azaltma konularında, Solana'nın blockchain endüstrisindeki liderliğini sürdürmek için teknik mimarisini ve ağ protokollerini sürekli olarak optimize etmesi gerekmektedir.

Teknik Mimari

Solana, POH algoritması, Tower BFT konsensüs mekanizması, Trubine veri iletim ağı ve SVM sanal makinesi sayesinde yüksek TPS ve hızlı kesinlik ile tanınmaktadır. Bileşenlerinin nasıl çalıştığını, yüksek performans hedeflerini gerçekleştirmek için mimari tasarımının nasıl şekillendiğini ve bu mimari tasarımın getirdiği dezavantajları ve türeyen sorunları kısaca tanıtacağız.

POH algoritması

POH(Tarih Kanıtı), küresel zamanı belirleyen bir tekniktir; bu bir konsensüs mekanizması değildir, yalnızca işlem sırasını belirleyen bir algoritmadır. POH teknolojisi, en temel kriptografi SHA256 teknolojisinden türetilmiştir. SHA256 genellikle verilerin bütünlüğünü hesaplamak için kullanılır; belirli bir girdi X verildiğinde, yalnızca benzersiz bir çıktı Y elde edilir, dolayısıyla X'teki herhangi bir değişiklik Y'de tamamen farklı bir sonuç doğurur.

Solana'nın POH dizisinde, sha256 algoritmasının uygulanmasıyla dizinin bütünlüğü sağlanabilir, böylece içindeki işlemlerin bütünlüğü de belirlenmiş olur. Bir örnek vermek gerekirse, eğer işlemleri bir blok haline paketlersek ve karşılık gelen sha256 hash değerini oluşturursak, o zaman bu blok içindeki işlemler belirlenmiş olur, herhangi bir değişiklik hash değerinin değişmesine neden olur. Daha sonra, bu blok hash'i bir sonraki sha256 fonksiyonunun X kısmı olarak kullanılacak ve bir sonraki blok hash'i eklenecektir, böylece önceki blok ve sonraki blok da belirlenmiş olur, herhangi bir değişiklik yeni Y'nin farklı olmasına sebep olur.

Bu, Proof of History teknolojisinin temel anlamıdır; bir önceki blok hash'i, bir sonraki sha256 fonksiyonunun bir parçası olarak kullanılır, bir zincir gibi, en son Y her zaman geçmişin kanıtını içerir.

Solana'nın işlem akış mimarisinde, POH mekanizması altındaki işlem süreci tanımlanmıştır. Leader Rotation Schedule adı verilen bir döngü mekanizması altında, tüm zincir doğrulayıcıları (Validator) arasında bir Leader düğümü oluşturulur. Bu Leader düğümü işlemleri toplar ve sıralı bir şekilde yürütür, POH dizisi oluşturur ve ardından bir blok oluşturup diğer düğümlere iletir.

Leader düğümünde tek nokta hatasını önlemek için zaman sınırlaması getirilmiştir. Solana'da zaman birimi epoch ile bölünmektedir, her epoch 432.000 slot( içermektedir, her slot 400ms sürmektedir, her bir slotta döngü sistemi her slot içinde bir Leader düğümü atayacaktır, Leader düğümü verilen slot süresi içinde blok)400ms( yayınlamalıdır, aksi takdirde bu slot atlanacak ve bir sonraki slotun Leader düğümü yeniden seçilecektir.

Genel olarak, Lider düğümü POH mekanizmasını kullanarak geçmişteki tüm işlemleri kesinleştirir. Solana'nın temel zaman birimi Slot'tur, Lider düğümünün bir slot içinde blok yayımlaması gerekir. Kullanıcılar işlemleri RPC düğümü aracılığıyla Lider'e iletir, Lider düğümü işlemleri paketler, sıralar ve ardından blok oluşturmak için yürütür, blok diğer doğrulayıcılara yayılır. Doğrulayıcılar, blok içindeki işlemler ve sıralama üzerinde konsensüse varmak için bir mekanizma aracılığıyla anlaşmaya varmalıdır; bu konsensüs, Tower BFT konsensüs mekanizmasını kullanır.

) Tower BFT konsensüs mekanizması

Tower BFT konsensüs protokolü, BFT konsensüs algoritmasından türetilmiş olup, bunun bir mühendislik uygulamasıdır. Bu algoritma hala POH algoritması ile ilişkilidir. Blokların oylanması sırasında, eğer doğrulayıcıların oyları kendileri bir işlem ise, o zaman kullanıcı işlemleri ve doğrulayıcı işlemleri ile oluşan blok hash'i de tarihsel bir kanıt olarak kullanılabilir; hangi kullanıcının işlem detayları ve doğrulayıcıların oy detayları benzersiz bir şekilde doğrulanabilir.

Tower BFT algoritmasında, tüm doğrulayıcıların bu blok için oy kullanması durumunda, %2/3'ten fazla doğrulayıcı onay oyu verirse, bu blok onaylanabilir. Bu mekanizmanın avantajı, yalnızca hash dizisine oy vermekle bloğun onaylanabilmesi nedeniyle büyük miktarda bellek tasarrufu sağlamasıdır. Ancak geleneksel konsensüs mekanizmalarında, genellikle blok seli kullanılır; yani bir doğrulayıcı bloğu aldığında, etrafındaki doğrulayıcılara gönderir, bu da ağda büyük bir gereksizlik yaratır çünkü bir doğrulayıcı, aynı bloğu birden fazla kez alır.

Solana'da, çok sayıda doğrulayıcı oyununun ve Lider düğümünün merkeziyetten kaynaklanan verimliliği ile 400 ms'lik Slot süresinin bulunmasından dolayı, genel blok boyutu ve blok çıkarma sıklığı oldukça yüksektir. Büyük blokların yayılması, ağa büyük bir baskı yapar. Solana, büyük blokların yayılma sorununu çözmek için Turbine mekanizmasını kullanmaktadır.

Türbini

Leader düğümü, Sharding adı verilen bir süreç aracılığıyla blokları shred adı verilen alt bloklara böler; bu alt blokların boyutları, MTU### maksimum iletim birimi olarak tanımlanır ve bir düğümden bir sonraki düğüme, daha küçük birimlere bölünmesine gerek kalmadan gönderilebilecek maksimum veri miktarı ( biriminde tanımlanır. Ardından, verilerin bütünlüğünü ve kullanılabilirliğini sağlamak için Reed-Solomon silme kodu şeması kullanılır.

Verileri dört Data Shred'e bölerek, veri aktarımı sırasında veri kaybı ve hasarını önlemek için, dört paketi sekiz pakete kodlamak üzere Reed-solomon kodlaması kullanılır. Bu sistem en fazla %50 kayıp oranına tolerans gösterebilir. Gerçek testlerde, Solana'nın kayıp oranı yaklaşık %15'tir, bu nedenle bu sistem mevcut Solana mimarisiyle iyi bir uyum sağlar.

![Solana teknik mimarisi yeniden değerlendiriliyor: İkinci bahar mı geliyor?])https://img-cdn.gateio.im/webp-social/moments-46a028270f3c2da92e7056c17c1d9e16.webp(

Veri iletiminin alt yapısında, genellikle UDP/TCP protokollerinin kullanılması düşünülür. Solana'nın paket kaybı oranına olan toleransı yüksek olduğundan, iletim için UDP protokolü kullanılmıştır. Bunun dezavantajı, paket kaybı durumunda yeniden iletim yapılmamasıdır, ancak avantajı daha hızlı iletim hızıdır. Aksine, TCP protokolü paket kaybı durumunda birçok kez yeniden iletim yapar ve bu, iletim hızını ve verimliliği büyük ölçüde düşürür. Reed-Solomon ile birlikte, bu sistem, Solana'nın verimliliğini önemli ölçüde artırabilir; gerçek ortamda verimlilik 9 kat artabilir.

Turbine verileri parçalara ayırdıktan sonra, çok katmanlı yayılma mekanizmasını kullanarak yayılma gerçekleştirir. Lider düğüm, her Slot'un bitiminden önce bir blok verisini herhangi bir blok doğrulayıcısına teslim eder, ardından bu doğrulayıcı bloğu Shred'lere ayırır ve hata düzeltme kodları oluşturur. Bu doğrulayıcı daha sonra Turbine yayılmasını başlatır. Öncelikle kök düğüme yayılmalıdır, sonra bu kök düğüm hangi doğrulayıcıların hangi katmanda olduğunu belirler. Süreç aşağıda gösterilmiştir:

1. Düğüm listesi oluşturma: Kök düğüm, tüm aktif doğrulayıcıları bir listeye toplar ve ardından her doğrulayıcının ağdaki hissesi olan ) yani stake edilmiş SOL miktarına göre sıralar. Daha yüksek ağırlığa sahip olanlar ilk katmanda yer alır, bununla birlikte devam eder.

2. Düğüm Grupları: Ardından, birinci katmandaki her doğrulayıcı kendi düğüm listesini oluşturarak kendi birinci katmanını inşa edecektir.

3. Kat oluşumu: Düğüm noktalarını listenin en üstünden katlara ayırarak, derinlik ve genişlik değerlerini belirleyerek, tüm ağacın kabaca şeklini belirleyebilirsiniz. Bu parametre, shreds'in yayılma hızını etkiler.

Yüksek hak sahibi olan düğümler, hiyerarşik olarak bir üst seviyeye geçtiğinde, tam shreds'leri önceden alabilirler. Bu durumda tam blokları geri yükleyebilirler. Ancak daha sonraki seviyedeki düğümler, iletim kaybı nedeniyle tam shreds alma olasılıkları düşecektir. Eğer bu shreds, tam parçaları oluşturmak için yetersizse, Lider'in doğrudan yeniden iletim yapması gerekecektir. Bu durumda veri iletimi ağaç yapısının içine doğru gerçekleşecektir ve birinci seviyedeki düğümler çoktan tam blok onayını oluşturmuşlardır. Daha sonraki seviyedeki doğrulayıcıların blok inşasını tamamlayıp oylama yapma süresi daha uzun olacaktır.

Bu mekanizmanın düşüncesi, Lider düğümünün tek düğüm mekanizmasına benzer. Blok yayılım sürecinde bazı öncelikli düğümler de bulunmaktadır, bu düğümler öncelikle shreds parçalarını alarak tam blok oluşturma sürecinde oy birliği sağlamak için çalışırlar. Redundansı daha derin bir seviyeye itmek, Finality'nin gerçekleşimini önemli ölçüde hızlandırabilir ve toplam verim ve verimliliği maksimize edebilir. Çünkü aslında ilk birkaç katman, 2/3 düğümünü temsil edebilir, bu nedenle sonraki düğümlerin oyu artık önemsiz hale gelir.

( SVM

Solana, saniyede binlerce işlemi işleyebilme kapasitesine sahip olmasının başlıca nedeni, POH mekanizması, Tower BFT uzlaşısı ve Turbine veri yayılma mekanizmasıdır. Ancak, SVM durum geçişinin sanal makinesi olarak, eğer Lider düğümü işlem yürütme sırasında SVM'nin işleme hızı yavaşsa, bu durum tüm sistemin throughput'unu azaltacaktır. Bu nedenle, SVM için Solana, işlem hızını artırmak amacıyla Sealevel paralel yürütme motorunu geliştirmiştir.

SVM'de talimatlar 4 bölümden oluşur ve program ID'si, program talimatı ve okuma/yazma verileri için hesap listesi içerir. Mevcut hesabın okuma mı yoksa yazma mı durumunda olduğunu ve durum değişikliği yapılacak işlemlerin çakışıp çakışmadığını belirleyerek, hesapların işlem talimatları çakışma olmayan durumlarda paralelleştirilmesine izin verilebilir, her talimat Program ID'si ile temsil edilir. Bu, Solana'nın doğrulayıcıları için yüksek gereksinimlerin nedenlerinden biridir, çünkü doğrulayıcıların GPU/CPU'larının SIMD) tek talimat çoklu veri### ve AVX gelişmiş vektör genişletme yeteneklerini desteklemesi gerekmektedir.

Ekosistem Gelişimi

Solana ekosisteminin mevcut gelişim sürecinde, giderek daha fazla pratik faydaya yöneliyor, örneğin bazı akıllı telefon projeleri, bazı uygulama mağazaları ve hatta bazı mobil cihazlar gibi, resmi destekli uygulamaların gelişim yönü de altyapının sonsuz içe dönmesine değil, tüketici uygulamalarına daha fazla yöneliyor. Solana'nın şu anki performansı yeterli.