Solana Teknik Mimarisi Analizi: Yeni Bir Bahar mı Geliyor?

Solana, yüksek performanslı bir blok zinciri platformudur ve yüksek işlem hacmi ile düşük gecikme süresi sağlamak için benzersiz bir teknoloji mimarisi kullanır. Temel teknolojileri arasında, işlem sırasını ve küresel saati garanti eden Proof of History (POH) algoritması, blok oluşturma hızını artıran Lider Rotasyon Programı ve Tower BFT konsensüs mekanizması bulunmaktadır. Turbine mekanizması, büyük blokların iletimini optimize etmek için Reed-solomon kodlaması kullanır. Solana Sanal Makinesi (SVM) ve Sealevel paralel yürütme motoru, işlem yürütme hızını artırır. Tüm bunlar, Solana'nın yüksek performansını sağlamak için mimari tasarımıdır, ancak aynı zamanda bazı sorunlar da getirmektedir, örneğin ağ kesintileri, işlem hataları, MEV sorunları, durumun hızlı büyümesi ve merkeziyetçilik sorunları.

Solana ekosistemi hızla gelişiyor, ilk yarıda çeşitli veri göstergeleri hızlı bir şekilde büyüdü, ö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, blockchain teknolojisinin daha geniş alanlarda uygulanmasını teşvik etme vizyonunu sergiliyor. Solana Mobile gibi projeleri destekleyerek ve tüketici uygulamaları için özel olarak tasarlanmış SDK'lar geliştirerek, blockchain teknolojisini günlük uygulamalara entegre etmeye çalışıyor ve böylece kullanıcı kabulünü ve kolaylığını artırıyor. Örneğin, Stepn gibi uygulamalar blockchain ve mobil teknolojiyi birleştirerek kullanıcılara yenilikçi bir spor ve sosyal deneyim sunuyor. Şu anda birçok tüketici uygulaması hala en iyi iş modeli ve pazar konumunu keşfetme aşamasında olsa da, Solana'nın sunduğu teknolojik platform ve ekosistem desteği, bu yenilikçi girişimlere kesinlikle güçlü bir destek sağlıyor. Teknolojinin daha fazla gelişimi ve pazarın olgunlaşması ile, Solana'nın tüketici uygulamaları alanında daha fazla atılım ve başarı hikayesi 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 gelişen halka açık blok zincirlerinden gelen yoğun bir rekabetle karşı karşıya kalmaktadır. EVM ekosisteminde potansiyel bir rakip olarak Base'in zincir üzerindeki aktif adres sayısı hızla artmaktadır. Ayrıca, Solana'nın DeFi alanındaki toplam kilitli değeri (TVL) tarihi bir zirveye ulaşmasına rağmen, Base gibi rakipler de hızla pazar payı kazanmaktadır ve Base ekosisteminin finansman miktarı, Q2 çeyreğinde Solana'yı ilk kez geride bırakmıştır.

Solana, teknolojik ve piyasa kabulü açısından belirli başarılar elde etmesine rağmen, Base gibi rakiplerin getirdiği zorluklarla başa çıkmak için sürekli yenilik ve iyileştirme gerekmektedir. Özellikle ağın kararlılığını artırma, işlem başarısızlık oranını azaltma, MEV sorununu çözme ve durum büyüme hızını yavaşlatma konularında, Solana teknik mimarisini ve ağ protokollerini sürekli olarak optimize etmelidir, böylece blockchain endüstrisindeki liderliğini koruyabilir.

Teknik Mimari

Solana, POH algoritması, Tower BFT konsensüs mekanizması, Trubine veri aktarım ağı ve SVM sanal makinesi ile sağladığı yüksek TPS ve hızlı Finality ile tanınır. Bileşenlerinin nasıl çalıştığını, yüksek performans hedeflerini mimari tasarımda nasıl gerçekleştirdiğini ve bu mimari tasarımın getirdiği dezavantajları ve ortaya çıkan sorunları kısaca tanıtacağız.

POH algoritması

POH(Tarih Kanıtı), küresel zamanı belirleyen bir teknolojidir; bu bir konsensüs mekanizması değildir, daha çok işlem sırasını belirleyen bir algoritmadır. POH teknolojisi, en temel kriptografi SHA256 teknolojisinden gelmektedir. SHA256 genellikle verilerin bütünlüğünü hesaplamak için kullanılır; verilen bir girdi X için yalnızca bir tane benzersiz çıktı Y vardır, bu nedenle X'teki herhangi bir değişiklik Y'nin tamamen farklı olmasına neden olur.

Solana'nın POH sıralamasında, sha256 algoritmasının uygulanmasıyla bütün sıralamanın bütünlüğü sağlanır ve böylece içindeki işlemlerin bütünlüğü de belirlenmiş olur. Örneğin, eğer işlemleri bir blok içinde paketlersek ve buna karşılık gelen bir sha256 hash değeri üretirsek, 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, ardından bir sonraki blokun hash'i eklenecek, böylece bir önceki blok ve bir sonraki blok belirlenmiş olacaktır; herhangi bir değişiklik yeni Y'nin farklı olmasına neden olacaktır.

Bu, Proof of History teknolojisinin temel anlamıdır; bir önceki blokun hash'i, bir sonraki sha256 fonksiyonunun bir parçası olarak kullanılacak, bir zincir gibi, en son Y, her zaman tarihi bir kanıt içerir.

Solana'nın işlem akış mimarisinde, POH mekanizması altında işlem sürecini açıklamaktadır. Leader Rotation Schedule adında bir döngü mekanizması altında, tüm zincir üzerindeki doğrulayıcılar arasında bir Lider düğümü oluşturulur. Bu Lider düğümü işlemleri toplar ve sıralı bir şekilde yürütür, POH dizisi oluşturur; ardından diğer düğümlere yayılacak bir blok oluşturur.

Leader düğümünde tek bir arıza noktasını önlemek için zaman sınırlaması getirilmiştir. Solana'da zaman birimleri epoch ile bölünmektedir; her epoch 432.000 slot( zaman dilimi içerir, her slot 400ms sürer. Her bir slotta, döngü sistemi her slot içinde bir Leader düğümü atar. Leader düğümü, belirli bir slot süresi içinde blok yayınlamak zorundadır)400ms(, aksi takdirde bu slot atlanır ve bir sonraki slotun Leader düğümü yeniden seçilir.

Genel olarak, Leader düğümü POH mekanizmasını kullanarak tarihsel işlemlerin tamamını kesinleştirebilir. Solana'nın temel zaman birimi Slot'tur, Leader düğümü bir slot içinde blok yaymak zorundadır. Kullanıcılar işlemleri RPC düğümü aracılığıyla Leadere iletir, Leader düğümü işlemleri paketler, sıralar ve ardından blok oluşturur, blok diğer doğrulayıcılara yayılır, doğrulayıcıların bir mekanizma aracılığıyla uzlaşma sağlaması gerekir, blok içindeki işlemler ve sıralama üzerinde uzlaşma sağlanır, bu uzlaşma için kullanılan mekanizma Tower BFT uzlaşma mekanizmasıdır.

) Tower BFT konsensüs mekanizması

Tower BFT konsensüs protokolü, BFT konsensüs algoritmasından gelmektedir ve bunun bir mühendislik uygulamasıdır. Bu algoritma hala POH algoritması ile ilişkilidir. Bloklar üzerinde oylama yaparken, eğer doğrulayıcıların oyu kendisi bir işlemse, 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ının ve doğrulayıcının oy detaylarının benzersiz olarak doğrulanabilmesi mümkündür.

Tower BFT algoritmasında, tüm doğrulayıcılar bu blok için oy verdiklerinde, %2/3’ten fazla doğrulayıcı onay oyu verdiğinde, bu blok onaylanabilir. Bu mekanizmanın avantajı, yalnızca hash dizisi üzerinde oy vermek yeterli olduğu için büyük miktarda bellek tasarrufu sağlamasıdır. Ancak geleneksel mutabakat mekanizmalarında genellikle blok seli kullanılır; yani bir doğrulayıcı bir blok aldığında, çevresindeki doğrulayıcılara gönderir, bu da ağda büyük bir fazlalığa yol açar, çünkü bir doğrulayıcı aynı bloğu birden fazla kez alır.

![Tekrar çözüm Solana teknik mimarisi: İkinci bahar mı geliyor?]###https://img-cdn.gateio.im/webp-social/moments-46a028270f3c2da92e7056c17c1d9e16.webp(

Solana'da, çok sayıda doğrulayıcı oylama işlemi ve Lider düğümünün merkezileşmesinin sağladığı verimlilik ile 400 ms'lik Slot süresi nedeniyle, genel blok boyutu ve blok oluşturma sıklığı özellikle yüksektir. Büyük blokların yayılması, ağa büyük bir baskı yapabilir, bu nedenle Solana, büyük blokların yayılma sorununu çözmek için Turbine mekanizmasını kullanır.

) Turbine

Lider düğümleri, Sharding olarak adlandırılan bir süreç aracılığıyla blokları shred adı verilen alt bloklara böler, bunların boyutu MTU### maksimum iletim birimi olarak belirlenir ve daha küçük birimlere bölünmesine gerek kalmadan bir düğümden diğerine iletilebilecek maksimum veri miktarı ( birimidir. Ardından, verilerin bütünlüğünü ve kullanılabilirliğini sağlamak için Reed-solomon silme kodu şeması kullanılır.

Veri parçalarını dört Data Shred'e bölerek, veri aktarımı sırasında paket kaybı ve hasarını önlemek için Reed-Solomon kodlaması kullanılarak dört paket sekiz pakete kodlanır. Bu sistem en fazla %50 paket kaybına dayanıklıdır. Gerçek testlerde, Solana'nın paket kaybı oranı yaklaşık %15'tir, bu nedenle bu sistem mevcut Solana mimarisiyle iyi bir şekilde uyum sağlar.

Veri iletiminde genellikle UDP/TCP protokolleri kullanılması düşünülür. Solana'nın paket kaybına karşı toleransı yüksek olduğundan, iletim için UDP protokolü tercih edilmiştir. Dezavantajı, paket kaybı durumunda yeniden iletim yapmamasıdır; ancak avantajı, daha hızlı iletim hızıdır. Aksine, TCP protokolü paket kaybı durumunda yeniden iletim yapar, bu da iletim hızını ve verimliliği büyük ölçüde azaltı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ı bir yayılma mekanizması kullanarak yayılma gerçekleştirir. Lider düğüm, her Slot sona ermeden önce bir blok vericiye herhangi bir blok vericiye teslim eder, ardından bu blok verici bloğu Shred'lere ayırır ve hata düzeltme kodu oluşturur. Bu blok verici daha sonra Turbine yayılmasını başlatacaktır. Öncelikle kök düğüme yayılmalıdır, ardından bu kök düğüm hangi blok vericilerin hangi katmanda olduğunu belirleyecektir. 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, ardından her doğrulayıcının ağdaki payı olan ) yani stake edilen SOL miktarına göre sıralar, daha yüksek ağırlığa sahip olanlar birinci katmanda yer alır, böylece devam eder.

2. Düğüm Gruplaması: Daha sonra birinci katmanındaki her doğrulayıcı, kendi birinci katmanını oluşturmak için terim kendi düğüm listesini de oluşturacaktır.

3. Kat oluşumu: Liste üstünden düğümleri katlara ayırarak, derinlik ve genişlik değerlerini belirleyerek, tüm ağacın genel şeklini belirlemek mümkündür. Bu parametre, shreds'in yayılma hızını etkiler.

Yüksek hak sahipliği oranına sahip düğümler, seviye ayrımında bir üst seviyede yer alırlarsa, tam shreds'leri önceden elde edebilirler. Bu durumda, tam bir blok geri yüklenebilir; ancak daha alt seviyedeki düğümlerin, iletim kaybı nedeniyle tam shreds elde etme olasılığı azalır. Eğer bu shreds, tam bir parça inşa etmek için yeterli değilse, Lider doğrudan yeniden iletim talep edecektir. Bu durumda veri iletimi ağacın içine doğru yönlendirilirken, birinci seviyedeki düğümler zaten tam blok onayını oluşturmuşlardır. Daha alt seviyedeki doğrulayıcıların blok inşasını tamamlaması için geçen süre uzadıkça oy verme süresi de o kadar uzar.

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 vardır, bu düğümler önce shreds parçalarını alarak tam blok oluşturur ve oy birliği sürecini tamamlar. Fazlalığı daha derin bir düzeye itmek, Finality'nin hızını önemli ölçüde artırabilir ve verimliliği ve verimliliği maksimize edebilir. Çünkü aslında ilk birkaç katman 2/3 düğümü temsil ediyorsa, sonraki düğümlerin oyu artık önemsiz hale gelir.

( SVM

Solana, her saniyede binlerce işlemi işleyebilme kapasitesine sahiptir, bunun başlıca nedeni POH mekanizması, Tower BFT konsensüsü ve Turbine veri yayılma mekanizmasıdır. Ancak, SVM bir durum geçişi sanal makinesi olarak, eğer Lider düğüm işlem yürütme sırasında SVM işleme hızı yavaşsa, bu tüm sistemin iş hacmini düşürecektir. Bu nedenle, SVM için Solana, işlem hızını artırmak amacıyla Sealevel paralel yürütme motorunu önermiştir.

SVM'de, talimatlar 4 bölümden oluşur ve program ID'si, program talimatları ve okuma/yazma verileri için hesap listelerini 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ındaki çakışma olmayan durumları paralelleştirmek mümkündür; 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 gerçek faydaya yöneliyor, örneğin Blinks, Actions ve hatta Solana Mobile gibi, resmi destekli uygulama geliştirme yönü de tüketici uygulamalarına daha fazla yöneliyor, altyapının sonsuz içe dönüklüğü yerine. Şu anda Solana'nın performansı yeterli olduğunda, uygulama çeşitliliği daha zengin. Ethereum açısından bakıldığında, TPS'sinin düşük olması nedeniyle,