Solana Teknik Mimarisi Analizi: İkinci 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 teknik mimari kullanmaktadı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 Takvimi 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 gerçekleştirme hızını artırır. Bunlar, Solana'nın yüksek performansını elde etmesi için mimari tasarımıdır, ancak aynı zamanda ağ kesintileri, işlem hataları, MEV sorunları, durumun aşırı büyümesi ve merkezileşme gibi bazı sorunları da beraberinde getirmiştir.

Solana ekosistemi hızla gelişiyor, tüm veri göstergeleri ilk yarıda 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 zayıf marka etkisine sahip ekosistemi, 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 inşa edilen SDK ile, Solana blockchain teknolojisini günlük uygulamalara entegre etmeye çalışıyor, böylece kullanıcıların kabulünü ve kolaylığını artırıyor.

Solana, blok zinciri endüstrisinde yüksek işlem hacmi ve düşük işlem maliyetleri ile önemli bir pazar payı elde etmesine rağmen, diğer yeni nesil halka açık zincirlerden gelen şiddetli bir rekabetle karşı karşıyadır. EVM ekosistemindeki potansiyel bir rakip olan Base'in zincir üzerindeki aktif adres sayısı hızla artmaktadır. Aynı zamanda, Solana'nın DeFi alanındaki toplam kilitli değeri (TVL) tarihsel bir zirveye ulaşmış olsa da, Base gibi rakipler de hızla pazar payı kazanmaktadır ve Base ekosisteminin finansman miktarı, Q2 çeyreğinde Solana'yı ilk kez geçmiştir.

Solana, teknolojik ve piyasa kabulü açısından belli bir başarı elde etmesine rağmen, Base gibi rakiplerden gelen zorluklarla başa çıkmak için sürekli yenilik ve geliştirme gerekmektedir. Özellikle, ağın kararlılığı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ı yavaşlatma konularında, Solana'nın teknik mimarisini ve ağ protokolünü sürekli olarak optimize etmesi gerekmektedir; böylece blockchain endüstrisindeki liderliğini sürdürebilir.

Teknik Mimarisi

Solana, POH algoritması, Tower BFT konsensüs mekanizması, Trubine veri iletim 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 hedefini mimari tasarımda nasıl gerçekleştirdiğini ve bu mimari tasarımın getirdiği dezavantajlar ile ortaya çıkan 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, ancak bir işlem sırasını belirleme algoritmasıdır. POH teknolojisi, temel kriptografi SHA256 teknolojisinden gelmektedir. SHA256 genellikle verilerin bütünlüğünü hesaplamak için kullanılır; belirli bir X girişi verildiğinde, yalnızca tek bir Y çıktısı vardır, bu nedenle bu X'teki herhangi bir değişiklik, Y'nin tamamen farklı olmasına yol açar.

Solana'nın POH dizisinde, tüm dizinin bütünlüğünü sağlamak için sha256 algoritması uygulanarak, içindeki işlemlerin bütünlüğü de belirlenir. Bir örnek vermek gerekirse, eğer işlemleri bir blok halinde paketlersek ve ilgili sha256 hash değerini oluşturursak, o bloktaki işlemler kesinleşmiş 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 parçası olarak kullanılacak ve bir sonraki blokun hash'i eklenecektir, böylece bir önceki blok ve bir sonraki blok kesinleşmiş olur, herhangi bir değişiklik yeni Y'nin farklı olmasına neden olur.

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 tarihsel kanıtı içerir.

Solana'nın işlem akış şeması, POH mekanizması altındaki işlem sürecini tanımlar. Leader Rotation Schedule adı verilen bir döngü mekanizması altında, tüm zincir doğrulayıcıları arasında bir Leader düğümü oluşturulur. Bu Leader düğümü işlemleri toplar ve sıralı olarak işler, POH dizisi üretir, ardından diğer düğümlere yayılan bir blok oluşturur.

Leader düğümünde tek nokta hatasını önlemek için zaman sınırlaması getirilmiştir. Solana'da zaman birimleri epoch'larla sınıflandırılmaktadır, her epoch 432.000 slot( zaman dilimi içerir, her slot 400 ms sürer. Her bir slotta, döngü sistemi her slot içinde bir Leader düğümü atar, Leader düğümü verilen slot süresi içinde blok)400ms( yayınlamak zorundadır, 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 geçmişteki tüm işlemleri kesinleştirebilir. Solana'nın temel zaman birimi Slot'tur, Leader düğümünün bir slot içinde blok yayması gerekir. Kullanıcılar işlemleri RPC düğümü aracılığıyla Leader'a iletir, Leader düğümü işlemleri paketler, sıralar ve ardından blok oluşturarak işlemleri gerçekleştirir; blok diğer doğrulayıcılara yayılır. Doğrulayıcıların, blok içindeki işlemler ve sıralama üzerinde uzlaşmaya varmak için bir mekanizma kullanması gerekir; bu uzlaşma, Tower BFT uzlaşma mekanizmasını kullanır.

) Tower BFT konsensüs mekanizması

Tower BFT konsensüs protokolü, BFT konsensüs algoritmasından gelmektedir ve bunun bir tür mühendislik uygulamasıdır; bu algoritma hâlâ POH algoritması ile ilişkilidir. Blokların oylanması sırasında, eğer doğrulayıcının oyu kendisi bir işlemse, o zaman kullanıcı işlemi ve doğrulayıcı işlemi tarafından oluşturulan blok hash'i, hangi kullanıcının işlem detayları ve doğrulayıcının oy detaylarının benzersiz olarak onaylanabileceği tarihsel bir kanıt olarak da kullanılabilir.

![Tekrar Ele Alınan Solana Teknoloji Mimarisi: İkinci Baharını mı Yaşayacak?]###https://img-cdn.gateio.im/webp-social/moments-224796bc8e080649730bb8736334abba.webp(

Tower BFT algoritmasında, tüm doğrulayıcılar bu blok için oy kullandığında, doğrulayıcıların %2/3'ünden fazlası onay oyu verirse, bu blok kesinleşebilir. Bu mekanizmanın avantajı, yalnızca hash dizisine oy vermek gerektiğinden büyük miktarda belleği tasarruf etmektir. Ancak geleneksel konsensüs mekanizmalarında genellikle blok seli uygulanır; yani bir doğrulayıcı bloğu aldığında, etrafındaki diğer doğrulayıcılara gönderir, bu da ağa büyük bir fazlalık oluşturur, çünkü bir doğrulayıcı aynı bloğu birden fazla kez alır.

Solana'da, birçok doğrulayıcı oylama işlemi bulunduğundan ve Lider düğümün merkeziyetçiliği ile sağlanan verimlilik ve 400ms'lik Slot süresi nedeniyle, genel blok boyutu ve blok oluşturma sıklığı oldukça yüksektir. Büyük bloklar yayıldığında, ağa büyük bir baskı yapabilir. Solana, büyük blokların yayılma sorununu çözmek için Turbine mekanizmasını kullanmaktadır.

) Turbine

Leader düğümü, Sharding olarak adlandırılan bir süreçle blokları shred alt bloklarına ayırır, bunun boyut standartları MTU### maksimum iletim birimi olup, daha küçük birimlere bölmeden bir düğümden diğerine gönderilebilecek 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.

Verileri dört Data Shred'ine bölerek, veri iletimi sırasında paket kaybı ve hasarını önlemek için Reed-Solomon kodlaması kullanarak dört paketi sekiz pakete kodluyoruz. Bu sistem en fazla %50 paket kaybına tolerans gösterebilir. Gerçek testlerde, Solana'nın paket kaybı oranı yaklaşık %15'tir, bu nedenle bu sistem mevcut Solana mimarisi ile oldukça uyumludur.

![Solana teknik mimarisinin yeniden çözümü: İkinci baharını mı bekliyor?])https://img-cdn.gateio.im/webp-social/moments-46a028270f3c2da92e7056c17c1d9e16.webp(

Veri iletiminin alt yapısında genellikle UDP/TCP protokollerinin kullanılması düşünülmektedir. Solana'nın kayıp oranlarına karşı toleransı yüksek olduğundan, iletim için UDP protokolü kullanılmıştır. Bunun dezavantajı kayıp olduğunda yeniden iletim yapılmamasıdır, ancak avantajı daha hızlı iletim hızıdır. Aksine, TCP protokolü kayıp durumunda iletimi birçok kez yeniden yapacak ve bu da iletim hızını ve verimliliği büyük ölçüde azaltacaktı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çaladıktan sonra, çok katmanlı bir yayılma mekanizması kullanarak yayılmayı gerçekleştirir. Lider düğüm, her Slot'un bitiminden önce bloğu herhangi bir blok doğrulayıcısına teslim eder ve ardından bu doğrulayıcı bloğu Shred'lere böler ve hata düzeltme kodu üretir. Bu doğrulayıcı daha sonra Turbine yayılmasını başlatır. Öncelikle kök düğüme yayılmalıdır, ardından bu kök düğüm hangi doğrulayıcıların hangi katmanda bulunduğ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 haklarını, yani stake edilen SOL miktarını ) kullanarak sıralar. Daha yüksek ağırlığa sahip olanlar birinci katmanda, buna göre devam eder.

2. Düğüm Gruplaması: Ardından, birinci katmanda bulunan her doğrulayıcı, kendi birinci katmanını oluşturmak için kendi düğüm listesini oluşturacaktır.

3. Katların 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 sahibi olan düğümler, katmanların ayrımında bir üst katmanda yer alırsa, tam shreds'i önceden alabilirler. Bu durumda tam blok geri yüklenebilir. Daha sonraki katmandaki düğümler, iletim kaybı nedeniyle tam shreds alma olasılıkları azalır. Eğer bu shreds, tam parçalar oluşturmak için yeterli değilse, Lider'in doğrudan yeniden iletim yapması talep edilecektir. Bu durumda veri iletimi ağaç iç kısmına yönelir ve birinci katmandaki düğümler çoktan tam blok onayı oluşturmuştur. Sonraki katmanlardaki doğrulayıcıların blok inşasını tamamladıktan sonra oy verme süresi daha uzun olacaktır.

Bu mekanizmanın düşüncesi, Lider düğümünün tek düğüm mekanizmasına benzerdir. Blok yayılım sürecinde bazı öncelikli düğümler de vardır, bu düğümler önce shreds parçalarını alarak tam bir blok oluşturur ve oy birliği sağlama sürecine ulaşır. Gereksizliği daha derin bir seviyeye itmek, Finality sürecini önemli ölçüde hızlandırabilir ve maksimum verim ve verimliliği sağlamak için. Çünkü aslında ilk birkaç katman 2/3 düğümü temsil ediyorsa, o zaman sonraki düğümlerin oyu önemli hale gelmez.

( SVM

Solana, her saniyede binlerce işlemi işleyebilme yeteneğine sahiptir. Bunun başlıca nedeni, POH mekanizması, Tower BFT konsensüsü ve Turbine veri yayılım mekanizmasıdır. Ancak SVM, durum geçişi için bir sanal makine 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 verimliliğini düşürecektir. Bu nedenle SVM için Solana, işlem hızını artırmak amacıyla Sealevel paralel yürütme motorunu geliştirmiştir.

![Solana teknik mimarisi yeniden inceleniyor: İkinci baharını mı yaşıyor?])https://img-cdn.gateio.im/webp-social/moments-d55d3cfbc13036ed0d5747abb521cc1a.webp###

SVM'de, talimatlar 4 bölümden oluşur, program ID'si, program talimatı ve okuma/yazma verilerinin hesap listesini içerir. Mevcut hesabın okuma mı yoksa yazma durumunda olup olmadığını ve durum değişikliği yapılacak işlemlerin çakışıp çakışmadığını belirleyerek, hesapların işlem talimatlarındaki durumu çakışmayanları 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 faydalara yöneliyor, örneğin Blinks ve Actions hatta Solana Mobile gibi, resmi destekli uygulama geliştirme yönü de daha çok tüketici uygulamalarına odaklanıyor, altyapının sonsuz içe dönmesine değil. Solana'nın mevcut performansı yeterli olduğunda, uygulama çeşitliliği daha da zenginleşiyor. Ethereum'a gelince, TPS'sinin düşük olması nedeniyle Ethereum ekosistemi hala altyapı ve ölçeklendirme teknolojileri üzerine odaklanıyor, altyapının uygulamaları taşıyamadığı durumlarda ise tüketici uygulamalarını inşa etmek mümkün olmuyor; bu da altyapıya yapılan yatırımların aşırı, ancak uygulama yatırımlarının yetersiz olduğu dengesiz bir duruma yol açıyor.

( DeFi

Solana üzerindeki DeFi protokollerinde, Kamino) birinci Lending###, Marginfi( Lending + Restaking), SoLayer( Restaking), Meteora gibi birçok henüz token çıkarmamış proje bulunmaktadır. Solana'nın birleşik ekosistem havası nedeniyle, genellikle bir projenin token çıkarma döneminde, diğer projeler mümkün olduğunca kaçınarak yeterli piyasa dikkatini çekmek için çaba gösterir.

Şu anda tüm DEX'te