Solana Teknoloji Mimarisi Analizi: İkinci Bahar mı?

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 üretim hızını artıran Lider Rotasyon Programı 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ı 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 elde etmesini sağlayan mimari tasarımlardır, ancak aynı zamanda ağ çökmesi, işlem hataları, MEV sorunları, durumun hızlı büyümesi ve merkezileşme sorunları gibi bazı problemleri de beraberinde getirmiştir.

Solana ekosistemi hızla gelişiyor, ilk yarıda tüm veri göstergeleri hızlı bir şekilde büyüyor, ö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 projeleri destekleyerek ve tüketici uygulamaları için özel SDK'lar geliştirerek, blockchain teknolojisini günlük uygulamalara entegre etmeyi amaçlıyor, böylece kullanıcıların 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 fitness ve sosyal deneyim sunuyor. Şu anda birçok tüketici uygulaması en iyi iş modeli ve pazar konumlamasını keşfetmeye devam etse de, Solana'nın sağladığı teknolojik 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 birlikte, Solana'nın tüketici uygulamaları alanında daha fazla atılım ve başarı hikayesi gerçekleştirmesi bekleniyor.

Solana, yüksek işlem hacmi ve düşük işlem maliyetleri ile blok zinciri sektöründe önemli bir pazar payı elde etse de, diğer yeni ortaya çıkan kamu blok zincirlerinden gelen yoğun 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ğer (TVL) tarihi bir zirveye ulaşmış olmasına rağmen, Base gibi rakipler de hızla pazar payı elde etmektedir. Base ekosisteminin finansman miktarı da Q2 çeyreğinde Solana'yı ilk kez geçmiştir.

Solana, teknik 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 geliştirme gerektirmektedir. Özellikle ağ 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ı yavaşlatma konularında, Solana'nın teknolojik mimarisini ve ağ protokolünü sürekli optimize etmesi gerekmektedir; böylece blok zinciri sektöründeki liderliğini sürdürebilir.

Teknik Mimari

Solana, POH algoritması, Tower BFT konsensüs mekanizması, Trubine veri iletim ağı ve SVM sanal makinesinin sağladığı yüksek TPS ve hızlı Finality ile tanınmaktadır. Bileşenlerinin nasıl çalıştığını, yüksek performans hedefinin mimari tasarımda nasıl gerçekleştirildiğ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ğil, işlem sırasını belirleyen bir algoritmadır. POH teknolojisi, en temel kriptografi olan SHA256 teknolojisinden kaynaklanmaktadır. SHA256 genellikle verilerin bütünlüğünü hesaplamak için kullanılır, verilen bir girdi X için, yalnızca benzersiz bir çıktı Y vardır. Bu nedenle, X üzerindeki herhangi bir değişiklik Y'yi tamamen farklı kılacaktır.

Solana'nın POH dizisinde, sha256 algoritmasının uygulanmasıyla tüm dizinin bütünlüğü sağlanabilir, bu da içindeki işlemlerin bütünlüğünü belirler. Bir örnek vermek gerekirse, eğer işlemleri bir blokta toplarsak, karşılık gelen sha256 hash değeri üretilir, o zaman bu bloktaki işlemler kesinleşir, 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, daha sonra bir sonraki bloğun hash'i eklenir, bu durumda önceki blok ve 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ılacaktır, bir zincir gibi, en son Y her zaman geçmişin kanıtını içerir.

Solana'nın işlem akış mimarisi diagramında, POH mekanizması altında işlem süreci açıklanmaktadır. Leader Rotation Schedule olarak adlandırılan bir döngü mekanizması altında, tüm zincir üzerindeki doğrulayıcılar (Validator) arasından 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 yaymak için bir blok oluşturur.

Tekil hataların önlenmesi için Leader düğümünde zaman sınırları getirilmiştir. Solana'da zaman birimi epoch olarak sınıflandırılır, her epoch 432.000 slot( içerir, her slot 400 ms sürer. Her bir slot içinde, döner sistem her slotta bir Leader düğümü atar, Leader düğümü belirlenen slot süresi içinde blok yayımlamak zorundadır)400ms(, 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ştirebilir. Solana'nın temel zaman birimi Slot'tur, Lider düğümünün bir slot içinde blok yayması gerekir. Kullanıcılar işlemleri RPC düğümü aracılığıyla Lidere iletir, Lider düğümü işlemleri paketleyip sıralayarak blok oluşturur, 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şmak için bir mekanizma kullanmaları gerekir; 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 tür mühendislik uygulamasıdır. Bu algoritma, POH algoritmasıyla da ilişkilidir. Bloklar üzerinde oylama yaparken, eğer doğrulayıcının oyu kendisi bir işlemse, kullanıcı işlemleri ve doğrulayıcı işlemlerinin oluşturduğu blok hash'i de tarihsel bir kanıt olarak kullanılabilir; hangi kullanıcının işlem detayları ve doğrulayıcının oylama detayları benzersiz bir şekilde onaylanabilir.

![Solana teknik mimarisini yeniden inceleme: İkinci bahar mı geliyor?]###https://img-cdn.gateio.im/webp-social/moments-d55d3cfbc13036ed0d5747abb521cc1a.webp(

Tower BFT algoritmasında, eğer tüm doğrulayıcılar bu blok için oy verirse ve oy verenlerin 2/3'ünden fazlası onay oyunu kullanırsa, o zaman bu blok kesinleşebilir. Bu mekanizmanın avantajı, yalnızca hash dizisi üzerinde oy vermek gerektiğinden, büyük miktarda bellek tasarrufu sağlamasıdır. Ancak geleneksel konsensüs mekanizmalarında, genellikle blok seli uygulanır; yani bir doğrulayıcı bir bloğu aldığında, etrafındaki doğrulayıcılara gönderecektir. Bu, ağda büyük miktarda fazlalığa neden olur, çünkü bir doğrulayıcı aynı bloğu birden fazla kez almıştır.

Solana'da, çok sayıda doğrulayıcı oylama işlemi ve Lider düğümünün merkezileşmesinin getirdiği verimlilik ile 400ms'lik Slot süresi nedeniyle, genel blok boyutu ve blok oluşturma sıklığı oldukça yüksektir. Büyük blokların yayılması, ağa büyük bir baskı yaratmaktadır; 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ç aracılığıyla blokları shred adı verilen alt bloklara böler, bu alt blokların boyutu MTU### maksimum iletim birimi olarak belirlenir. Bu, daha küçük birimlere bölünmesine gerek kalmadan bir düğümden diğerine gönderilebilecek maksimum veri miktarıdır ( birimi cinsinden. Ardından, verinin bütünlüğünü ve kullanılabilirliğini sağlamak için Reed-Solomon silme kodu şeması kullanılır.

Verileri dört Data Shreds'e bölerek, veri iletimi 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ğlamaktadır.

![Solana teknik mimarisine yeniden bakış: ikinci baharını mı bekliyor?])https://img-cdn.gateio.im/webp-social/moments-e9bc35d0c790496c59c20979e5af1491.webp(

Veri iletiminin temelinde genellikle UDP/TCP protokolleri kullanılması düşünülür. Solana'nın paket kaybı toleransı yüksek olduğundan, iletim için UDP protokolü tercih edilmiştir. Bunun dezavantajı, paket kaybı durumunda yeniden iletim yapılmamasıdır, ancak avantajı daha hızlı bir iletim hızıdır. Aksine, TCP protokolü paket kaybı olduğunda yeniden birçok kez iletim yapar, 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 ve gerçek ortamda verimlilik 9 kat artırılabilir.

Turbine, verileri parçalara ayırdıktan sonra, çok katmanlı yayılma mekanizması kullanarak yayılma işlemi gerçekleştirir. Lider düğüm, her Slot'un sonunda blokları herhangi bir blok doğrulayıcısına teslim eder, ardından bu doğrulayıcı blokları 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ılma yapılır, ardından 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: 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ı olan ) yani stake edilen SOL miktarına göre sıralar, daha yüksek ağırlığa sahip olanlar ilk katmanda yer alır, bu şekilde devam eder.

2. Düğüm Grupları: Daha sonra birinci katmanda bulunan her doğrulayıcı, kendi birinci katmanını oluşturmak için kendi düğüm listesini 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 payına sahip düğümler, katmanların ayrımında daha üst bir katmanda yer alırlarsa, tam shreds alabilirler. Bu durumda tam bir blok geri yükleyebilirler. Ancak, sonraki katmandaki düğümlerin 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ç kısmına yönlendirilir ve birinci katmandaki düğümler çoktan tam blok onayını oluşturmuşlardır. Sonraki katmanlardaki doğrulayıcıların blok inşasını tamamlamaları için gereken oy verme 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 vardır, bu düğümler önce shreds parçalarını toplayarak tam bir blok oluşturarak oy birliği sağlama sürecine ulaşırlar. Redundansı daha derin bir seviyeye itmek, Finality'nin ilerlemesini önemli ölçüde hızlandırabilir ve maksimum verimlilik ve etkinliği sağlayabilir. Çünkü aslında ilk birkaç katman, 2/3 düğümü temsil edebilir, bu nedenle sonraki düğümlerin oyu artık önemsiz hale gelir.

( SVM

Solana, saniyede binlerce işlemi işleyebilme kapasitesine sahiptir; bunun başlıca nedeni POH mekanizması, Tower BFT konsensüsü ve Turbine veri yayılma mekanizmaları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 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.

![Solana teknik mimarisini yeniden inceleme: İkinci bahar mı geliyor?])https://img-cdn.gateio.im/webp-social/moments-9fd8693259e2864d6978d2b4e8ef2e85.webp###

SVM'de, talimat dört bölümden oluşur; program kimliği, program talimatı ve veri okuma/yazma hesap listesini içerir. Mevcut hesabın okuma mı yoksa yazma mı durumunda olduğunu ve durum değişikliği işlemlerinin çakışıp çakışmadığını belirleyerek, hesapların işlem talimatlarındaki çakışma olmayan durumları paralelleştirmeye izin verilebilir, her talimat Program ID 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 yüksek düzeyde vektör genişletme yeteneklerini desteklemesi gerekmektedir.

Ekosistem Gelişimi

Mevcut Solana ekosisteminin gelişim sürecinde, giderek daha fazla pratik faydaya yöneliyor, örneğin Blinks ve Actions hatta Solana Mobile gibi, resmi destekli uygulama gelişim yönü de altyapıya değil, daha çok tüketici uygulamalarına yöneliyor.