Solana teknik mimarisi ve ekosistem gelişimi analizi

Solana, yüksek performanslı bir blockchain platformudur, yüksek throughput ve düşük gecikme sağlamak için benzersiz bir teknik mimari benimsemektedir. Ana teknolojileri arasında, işlem sırasını ve küresel saat sağlamayı garanti eden 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ılımını optimize etmek için Reed-solomon kodlamasını kullanır. Solana Virtual Machine (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 elde etmesini sağlayan mimari tasarımlardır, ancak aynı zamanda ağ kesintileri, işlem hataları, MEV sorunları, durumun aşırı büyümesi ve merkeziyetçilik 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 marka etkisi zayıf olan 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 destekleyerek ve tüketici uygulamaları için özel olarak inşa edilmiş 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, blockchain endüstrisinde yüksek işlem hacmi ve düşük işlem maliyeti ile önemli bir pazar payı elde etmiş olmasına rağmen, diğer yeni nesil kamu blok zincirlerinden gelen yoğun bir rekabetle karşı karşıyadır. EVM ekosisteminde 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) tarihi bir zirveye ulaşmış olmasına rağmen, Base gibi rakipler de hızla pazar payı kazanıyor ve Base ekosisteminin finansman miktarı Q2 çeyreğinde ilk kez Solana'yı geçmiştir.

Solana, teknik ve pazar kabulünde belirli başarılar elde etmesine rağmen, Base gibi rakiplerin getirdiği zorluklarla başa çıkmak için sürekli olarak yenilik yapması ve gelişmesi gerekmektedir. Özellikle ağ 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 teknolojik mimarisini ve ağ protokolünü sürekli olarak optimize etmelidir; böylece blockchain sektöründeki liderliğini sürdürebilir.

Teknik Mimari

POH algoritması

POH(Tarih Kanıtı), küresel zamanı belirleyen bir tekniktir; bu bir konsensüs mekanizması değil, işlem sırasını belirleyen bir algoritmadır. POH teknolojisi, en temel kriptografi SHA256 teknolojisinden kaynaklanmaktadır. SHA256 genellikle verinin bütünlüğünü hesaplamak için kullanılır; verilen bir X girişi için, yalnızca tek bir Y çıktısı vardır ve bu nedenle X'teki herhangi bir değişiklik, Y'nin tamamen farklı olmasına neden olur.

Solana'nın POH sırasındaki bütünlüğü sağlamak için sha256 algoritması uygulanarak tüm sıranın bütünlüğü güvence altına alını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 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 parçası olarak kullanılacak ve bir sonraki bloğun hash'i eklenecektir, böylece önceki blok ve sonraki blok belirlenmiş olur, herhangi bir değişiklik yeni Y'nin farklı olmasına neden olur.

Solana'nın işlem akışı mimarisinde, POH mekanizması altında işlem sürecini tanımlamaktadı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ü üretilir. Bu Leader düğümü işlemleri toplar ve sıralı bir şekilde gerçekleştirir, POH dizisi oluşturur. Ardından, diğer düğümlere iletilmek üzere bir blok oluşturur.

Bir Leader düğümünde tek nokta arızasını önlemek için zaman sınırları getirilmiştir. Solana'da zaman birimleri epoch ile bölünmüştür, 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ü belirlenen slot zamanında blok yayınlamak zorundadır)400ms(, aksi takdirde bu slot atlanır ve bir sonraki slotun Leader düğümü yeniden seçilir.

Genel olarak, Lider düğümü POH mekanizmasını kullanarak geçmişteki tüm işlemleri kesinleştirebilir. Solana'nın temel zaman birimi Slot'tur, Lider düğümü bir slot içinde blokları yayınlamak zorundadır. 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 uzlaşmak için bir mekanizma kullanarak uzlaşmaya ulaşmalıdır; bu uzlaşma, Tower BFT uzlaşma mekanizmasını kullanmaktadır.

) Tower BFT konsensüs mekanizması

Tower BFT konsensüs protokolü, BFT konsensüs algoritmasından gelmektedir ve bunun bir somut mühendislik uygulamasıdır. Bu algoritma hala POH algoritması ile ilişkilidir. Bloklar üzerinde oy kullanırken, 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şturulan blok hash'i, hangi kullanıcının işlem detaylarının ve doğrulayıcıların oy detaylarının benzersiz bir şekilde onaylanabileceği tarihsel bir kanıt olarak da kullanılabilir.

![Solana teknik mimarisinin yeniden açıklaması: İkinci bahar mı geliyor?]###panews/images/90Jj8P8FH5.webp(

Tower BFT algoritmasında, tüm doğrulayıcılar bu bloğa oy verirse ve %2/3'ten fazla doğrulayıcı onay oyu verirse, bu blok kesinleşir. Bu mekanizmanın avantajı, yalnızca hash dizisi üzerinde oy vererek bloğun onaylanmasını gerektirdiği için büyük miktarda bellek tasarrufu sağlamasıdır. Ancak geleneksel konsensüs mekanizmalarında genellikle blok seli kullanılmaktadır; yani bir doğrulayıcı bloğu aldığında, çevresindeki diğer doğrulayıcılara gönderir. Bu da ağda büyük miktarda 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 işlemlere dahil olması ve Lider düğümün merkezileşmesinin getirdiği verimlilik ile 400ms'lik Slot süresi nedeniyle, genel blok boyutu ve blok üretim sıklığı oldukça yüksek olmaktadır. Büyük blokların yayılması, ağa büyük bir baskı yapabilmektedir. Solana, büyük blokların yayılma sorununu çözmek için Turbine mekanizmasını kullanmaktadır.

) Türbin

Leader düğümü, Sharding olarak adlandırılan bir süreç aracılığıyla blokları shred adlı alt bloklara böler. Bu alt blokların boyutları, MTU### maksimum iletim birimi olarak belirlenmiştir ve daha küçük birimlere bölünmesine gerek kalmadan bir düğümden diğerine gönderilebilecek maksimum veri miktarı ( birimidir. Daha sonra verilerin bütünlüğünü ve kullanılabilirliğini sağlamak için Reed-solomon silme kodu şeması kullanılır.

Veri paketlerini dört Data Shred'e bölerek, veri iletim sürecinde paket kaybı ve hasarını önlemek için, dört paketi sekiz pakete kodlamak amacıyla Reed-solomon kodlaması kullanılmaktadır. Bu sistem, en fazla %50 paket kaybı toleransı sağlayabilir. Gerçek testlerde, Solana'nın paket kaybı oranı yaklaşık %15'tir, bu nedenle bu sistem mevcut Solana mimarisi ile oldukça uyumludur.

Veri iletiminde genellikle UDP/TCP protokolü kullanılması düşünülür. Solana'nın paket kaybı toleransı yüksek olduğu için iletimde UDP protokolü tercih edilmiştir. 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 yeniden iletim yapar ve bu da 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 artırılabilir.

Turbine verileri parçaladıktan sonra, çok katmanlı bir yayılma mekanizması kullanarak yayılır. Lider düğüm, her Slot'un bitiminden önce bir blok vericiye herhangi bir blok verecektir. Daha sonra bu blok verici, bloğu Shred'lere bölecek ve hata düzeltme kodu üretecektir. Bu blok verici daha sonra Turbine yayılımını başlatacaktır. Öncelikle kök düğüme yayılması gerekmektedir, ardından bu kök düğüm hangi doğrulayıcıların hangi katmanda olduğunu belirleyecektir. Süreç aşağıda gösterilmektedir:

1. Düğüm listesi oluşturma: Ana düğüm, tüm aktif doğrulayıcıları bir listeye toplar ve ardından her doğrulayıcının ağdaki payı ) yani stake edilen SOL miktarına ( göre sıralar; daha yüksek ağırlığa sahip olanlar birinci katmanda yer alır ve bu şekilde devam eder.

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

3. Kat oluşumu: Listenin üst kısmından düğümleri 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.

![Solana teknik mimarisi yeniden çözülüyor: İkinci bahar mı geliyor?])panews/images/iQ41c4b6DM.webp(

Hak sahibi olan düğümler, katmanlı dağılımda daha yüksek bir seviyeye çıktıklarında, tam shreds elde etme şansına sahip olurlar. Bu durumda, tam blokları geri yükleyebilirler. Ancak, daha alt katmanlardaki 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ı istenir. Bu durumda, veri iletimi ağaç içindeki düğümlere doğru yönelir ve ilk katmandaki düğümler çoktan tam blok onayı oluşturmuşlardır. Daha alt katmanlardaki doğrulayıcıların blok yapımını tamamlaması için oylama süresi 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 ilk olarak shreds parçalarını alarak tam bir blok oluşturmak ve oy birliği sağlamak için sürecin tamamlanmasını sağlar. Fazlalıkları daha derin bir seviyeye itmek, Finality'nin gerçekleşmesini önemli ölçüde hızlandırabilir ve verimliliği ve throughput'u maksimize edebilir. Çünkü gerçekte, ilk birkaç katman muhtemelen 2/3 düğümü temsil edebilir, bu nedenle sonraki düğümlerin oyu da önemsiz hale gelir.

) SVM

Solana, saniyede binlerce işlem gerçekleştirebilme kapasitesine sahiptir; bunun başlıca nedeni POH mekanizması, Tower BFT konsensüsü ve Turbine veri yayılım mekanizmasıdır. Ancak, SVM durum dönüşüm 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 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.

SVM'de, talimatlar 4 bölümden oluşur ve program ID'si, program talimatı ile okuma/yazma verilerinin hesap listesi içerir. Mevcut hesabın okuma mı yoksa yazma durumunda olduğunu ve durum değişikliği yapılacak işlemin çelişkisi olup olmadığını belirleyerek, hesapların işlem talimatlarındaki çelişkisiz durumları paralelleştirmeye izin verilir; her talimat Program ID'si ile temsil edilir. Bu, Solana'nın doğrulayıcıları için yüksek gereksinimlerin olmasının 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.

![Solana teknik mimarisini yeniden incelemek: İkinci baharını mı迎来？])panews/images/Czi5MR4h94.webp(

Ekosistem Gelişimi

Solana ekosisteminin mevcut gelişim sürecinde, giderek daha fazla pratik faydaya yöneliyor, örneğin Blinks ve Actions hatta Solana Mobile gibi, resmi destekli uygulama geliştirme yönü de altyapının sonsuz bir iç çekişme yerine tüketici uygulamalarına daha fazla odaklanıyor. Solana'nın mevcut performansı yeterli olduğunda, uygulama çeşitliliği daha zengin hale geliyor. Ethereum'a bakacak olursak, TPS'sinin düşük olması nedeniyle Ethereum ekosistemi hala altyapı ve ölçeklendirme teknolojilerine odaklanıyor; altyapı uygulamaları taşıyamayacak durumda olduğunda, tüketici uygulamaları inşa edemiyor, bu da altyapıya yapılan yatırımların fazlasıyla, ancak uygulamalara yapılan yatırımları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 birlikçi ekosistem havası nedeniyle, genellikle bir projenin token çıkış tarihine yakın diğer projeler mümkün olduğunca uzak durmaya çalışır, böylece yeterli piyasa ilgisini çekebilirler.

Şu anda tüm DEX pazarında rekabet oldukça yoğun, lider de Raydium, Orca'dan şu anda Jupiter'e kadar birçok kez değişti.

Dikkat edilmesi gereken bir nokta, DEX işlemlerinin yaklaşık %50'sinin MEV botları tarafından başlatıldığıdır; bunun başlıca nedeni, düşük ücretleri ve Meme ticaretinin aktif olmasıdır, bu da MEV'nin karlı hale gelmesine neden olmaktadır. Bu durum, kullanıcıların yoğun ticaret yaparken sık sık başarısızlık yaşamasının ve sistemin çökmesinin başlıca nedenlerinden biridir.

Solana üzerindeki DeFi protokolleri, SOL fiyatının artışıyla birlikte, USD cinsinden nominal TVL'de patlayıcı bir artışa tanık oldu. TVL'deki artış trendi hala durmadı, yeni bir artış trendi oluşuyor.

![Tekrar Açıklama Solana Teknoloji Mimarisi: İkinci Baharını mı Bekliyor?])