Solana Teknoloji Mimarisi Yeniden İnceleniyor: İkinci Baharını mı Yaşayacak?
Solana, yüksek performanslı bir blok zinciri platformudur ve yüksek işlem hacmi ile düşük gecikme sürelerini 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 Takvimi 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ı kullanmaktadır. Solana Sanal Makinesi (SVM) ve Sealevel paralel yürütme motoru, işlem yürütme hızını artırmaktadır. Bunlar, Solana'nın yüksek performansını sağlayan mimari tasarımlardır, ancak aynı zamanda ağ kesintileri, işlem hataları, MEV sorunları, durumun hızla büyümesi ve merkeziyetçilik gibi bazı sorunları da beraberinde getirmiştir. Bu makalede, bu mekanizmaların getirdiği sorunlara da vurgu yapılmaktadır.
Solana ekosistemi hızla gelişiyor, tüm veri göstergeleri ilk yarıda hızlı bir şekilde ilerliyor, ö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 bir 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 destekleyerek ve tüketici uygulamaları için özel olarak oluşturulmuş SDK ile, Solana, blok zinciri teknolojisini günlük uygulamalara entegre etmeye çalışıyor ve böylece kullanıcıların kabulünü ve rahatlığını artırıyor. Örneğin, Stepn gibi uygulamalar, 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ı hala en iyi iş modeli ve pazar konumunu keşfederken, Solana'nın sunduğu teknolojik platform ve ekosistem desteği kuşkusuz bu yenilikçi girişimlere 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ı hikayeleri 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 nesil blok zincirlerinden yoğun bir rekabetle karşı karşıyadır. Bir işlem platformu, EVM ekosisteminde potansiyel bir rakip olarak, zincir üzerindeki aktif adres sayısını hızla artırıyor. Aynı zamanda, Solana'nın DeFi alanındaki toplam kilitli değer (TVL) tarihi bir zirveye ulaşmış olsa da, bir işlem platformu gibi rakipler de pazar payını hızla ele geçiriyor ve bir işlem platformu ekosisteminin finansman miktarı, Q2 çeyreğinde ilk kez Solana'yı geçiyor.
Solana, teknik ve pazar kabulü açısından belli bir başarı elde etmesine rağmen, belirli bir ticaret platformu gibi rakiplerin getirdiği zorluklarla başa çıkmak için sürekli yenilik ve iyileştirme yapması 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ı yavaşlatma konularında, Solana'nın teknik mimarisini ve ağ protokollerini sürekli olarak optimize etmesi gerekmektedir, böylece blockchain endüstrisindeki lider konumunu koruyabilir.
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ı sonlanma (Finality) ile tanınmaktadır. Bileşenlerinin nasıl çalıştığını, yüksek performans hedeflerini gerçekleştirmek için mimari tasarımda nasıl işlev gördüğünü ve bu mimari tasarımın getirdiği dezavantajlar ile türetilen 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, temel şifreleme SHA256 teknolojisinden kaynaklanmaktadır. SHA256 genellikle verilerin bütünlüğünü hesaplamak için kullanılır; verilen bir X girişi için yalnızca benzersiz bir Y çıktısı vardır, bu nedenle X'teki herhangi bir değişiklik Y'yi tamamen farklı hale getirecektir.
Solana'nın POH dizisinde, sha256 algoritması uygulanarak tüm dizinin bütünlüğü sağlanabilir ve bu da içindeki işlemlerin bütünlüğünü belirler. Örneğin, işlemleri bir blok haline getirip karşılık gelen sha256 hash değerini oluşturursak, bu blok içindeki işlemler kesinleşmiş olur; herhangi bir değişiklik hash değerinin değişmesine neden olur. Daha sonra bu blok hash, bir sonraki sha256 fonksiyonunun X'inin bir parçası olarak kullanılacak ve bir sonraki blokun hash'i eklenecektir. Böylece ö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 blok 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ış ş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 Lider düğümü oluşturulmaktadır. Bu Lider düğüm, işlemleri toplar ve sıralı bir şekilde yürütür, POH dizisi üretir, ardından bir blok oluşturup diğer düğümlere dağıtır.
Leader düğümünde tek nokta arızasını önlemek için zaman sınırlaması getirilmiştir. Solana'da zaman birimleri epoch ile bölünmüştür; her epoch 432.000 slot (zaman dilimi) içerir ve her slot 400 ms sürer. Her bir slotta, döngü sistemi her slot içinde bir Leader düğümü atar. Leader düğümü, belirlenen slot süresi içinde blok yayımlamak zorundadır (400 ms); aksi takdirde, bu slot atlanır ve bir sonraki slotun Leader düğümü yeniden seçilir.
Genel olarak, Lider düğümleri 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 Lidere iletir, Lider düğümü işlemleri paketleyip sıralar ve ardından blok üretir, 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 kullanmaları 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 belirli bir mühendislik uygulamasıdır. Bu algoritma, POH algoritmasıyla da ilişkilidir. Bloklar oylanırken, eğer doğrulayıcıların oyları kendileri bir işlemse, o zaman kullanıcı işlemleri ve doğrulayıcı işlemlerinin oluşturduğu blok hash'i tarihi bir kanıt olarak kullanılabilir. Hangi kullanıcının işlem detayları ve doğrulayıcının oy detayları benzersiz olarak doğrulanabilir.
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ştirilebilir. Bu mekanizmanın avantajı, sadece hash dizisine oy vermek yeterli olduğu için büyük miktarda bellek tasarrufu sağlamasıdır. Ancak geleneksel konsensüs mekanizmalarında genellikle blok yayılması kullanılır; bir doğrulayıcı bloku aldığında, çevresindeki doğrulayıcılara gönderir. Bu, bir doğrulayıcının aynı bloğu birden fazla kez almasına neden olarak ağda büyük bir fazlalığa yol açar.
Solana'da, çok sayıda doğrulayıcı oylama işlemi bulunması ve Lider düğümünün merkezileşmesinin getirdiği verimlilik ile 400ms'lik Slot süresi nedeniyle, genel blok boyutu ve blok üretim sıklığı özellikle yüksektir. Büyük blokların yayılması, ağda büyük bir baskı yaratır; Solana, büyük blokların yayılma sorununu çözmek için Turbine mekanizmasını kullanır.
Türbin
Leader düğümü, Sharding olarak bilinen bir süreç aracılığıyla blokları shred adı verilen alt bloklara böler, bu alt blokların boyutları MTU (Maksimum İletim Birimi, bir düğümden diğerine bölmeye gerek kalmadan gönderilebilecek maksimum veri miktarı) cinsindendir. Daha sonra verilerin bütünlüğünü ve kullanılabilirliğini sağlamak için Reed-Solomon silme kodu şemasını kullanır.
Verileri dört Data Shred'e bölerek, veri aktarımı sırasında paket kaybı ve bozulmayı önlemek için Reed-Solomon kodlaması kullanılarak dört paket sekiz pakete kodlanır; bu yöntem 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 yöntem mevcut Solana mimarisi ile çok iyi bir şekilde uyum sağlamaktadır.
Alt düzeyde veri iletiminde genellikle UDP/TCP protokolünün kullanılması düşünülür. Solana'nın paket kaybı oranına 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ı iletim hızıdır. Aksine, TCP protokolü paket kaybı durumunda yeniden birçok kez iletim yapar ve 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 ve gerçek ortamda verimliliği 9 kat artırabilir.
Turbine verileri parçalayarak, çok katmanlı yayılma mekanizması kullanarak yayıyor. Lider düğüm, her Slot'un bitiminden önce blokları herhangi bir blok doğrulayıcısına teslim edecek, ardından bu doğrulayıcı blokları Shred'lere ayıracak ve hata düzeltme kodu üretecek. Bu doğrulayıcı daha sonra Turbine yayılmasını başlatacak. Öncelikle kök düğüme yayılacak ve ardından bu kök düğüm hangi doğrulayıcıların hangi katmanda olduğunu belirleyecek. Süreç aşağıdaki gibidir:
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 payına (yani stake edilen SOL miktarına) göre sıralar; daha yüksek ağırlığa sahip olanlar birinci katmanda yer alır, bu şekilde devam eder.
Düğüm Gruplaması: Ardından, birinci katmanda bulunan her doğrulayıcı kendi düğüm listesini oluşturarak kendi birinci katmanını inşa edecektir.
Kat oluşturma: Liste üstünden düğümleri katlara ayırarak, derinlik ve genişlik değerlerini belirleyerek, tüm ağacın genel şekli belirlenebilir. Bu parametre, shreds'in yayılma hızını etkiler.
Yüksek hak sahipliği oranına sahip olan düğümler, katmanların bölünmesinde bir üst kata geçerse, tam shreds'leri önceden elde edebilirler. Bu durumda, tam blokları geri yükleyebilirler. Daha sonraki katmanlardaki düğümler ise, iletim kaybı nedeniyle, tam shreds'leri elde etme olasılıkları azalır. Eğer bu shreds'ler tam parçalar oluşturmak için yeterli değilse, Lider'in doğrudan yeniden iletim yapması istenecektir. Bu durumda, veri iletimi ağacın iç kısmına yönlendirilir ve ilk katman düğümleri çoktan tam blok onayını oluşturmuşlardır. Daha sonraki katmanlardaki doğrulayıcıların blok oluşturmayı tamamladıktan sonra oy verme 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 önce shreds parçalarını alarak tam bir blok oluşturur ve oylama konsensüsünü sağlamak için süreci tamamlar. Gereksizliği 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ü aslında ilk birkaç katman, 2/3 düğümü temsil ediyor olabilir; bu durumda sonraki düğümlerin oyu artık önemli olmayacaktır.
SVM
Solana, saniyede binlerce işlemi işleyebilme yeteneğine sahip olmasının başlıca nedeni, POH mekanizması, Tower BFT konsensüsü ve Turbine veri yayılım mekanizmasıdır. Ancak, SVM bir durum dönüşüm sanal makinesi olarak, eğer Lider düğüm işlem yürütme sırasında SVM 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.
SVM'de, talimatlar 4 bölümden oluşur; program ID'si, program talimatı ve veri okuma/yazma hesap listesi içerir. Mevcut hesabın okuma veya yazma durumunda olup olmadığını ve durum değişikliği yapılacak işlemin çakışıp çakışmadığını belirleyerek, hesapların ticaret talimatlarında durum çakışması olmayan paralelleştirmeye izin verilebilir, her talimat Program ID'si ile temsil edilir. Bu da Solana'nın doğrulayıcılar için yüksek gereksinimlere sahip olmasının nedenlerinden biridir, çünkü doğrulayıcıların GPU/CPU'larının SIMD (tek talimat çok veri) ve AVX yüksek desteklemesi gerekmektedir.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
13 Likes
Reward
13
5
Share
Comment
0/400
FancyResearchLab
· 07-30 11:46
Yine hangi gösterişli özelliği araştırıyorsun? Cüzdanın için gerçekten üzülüyorum.
Solana teknik mimarisi analizi: Yüksek performans ve zorluklar bir arada, ekosistem gelişimi yeni fırsatlar sunuyor.
Solana Teknoloji Mimarisi Yeniden İnceleniyor: İkinci Baharını mı Yaşayacak?
Solana, yüksek performanslı bir blok zinciri platformudur ve yüksek işlem hacmi ile düşük gecikme sürelerini 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 Takvimi 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ı kullanmaktadır. Solana Sanal Makinesi (SVM) ve Sealevel paralel yürütme motoru, işlem yürütme hızını artırmaktadır. Bunlar, Solana'nın yüksek performansını sağlayan mimari tasarımlardır, ancak aynı zamanda ağ kesintileri, işlem hataları, MEV sorunları, durumun hızla büyümesi ve merkeziyetçilik gibi bazı sorunları da beraberinde getirmiştir. Bu makalede, bu mekanizmaların getirdiği sorunlara da vurgu yapılmaktadır.
Solana ekosistemi hızla gelişiyor, tüm veri göstergeleri ilk yarıda hızlı bir şekilde ilerliyor, ö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 bir 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 destekleyerek ve tüketici uygulamaları için özel olarak oluşturulmuş SDK ile, Solana, blok zinciri teknolojisini günlük uygulamalara entegre etmeye çalışıyor ve böylece kullanıcıların kabulünü ve rahatlığını artırıyor. Örneğin, Stepn gibi uygulamalar, 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ı hala en iyi iş modeli ve pazar konumunu keşfederken, Solana'nın sunduğu teknolojik platform ve ekosistem desteği kuşkusuz bu yenilikçi girişimlere 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ı hikayeleri 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 nesil blok zincirlerinden yoğun bir rekabetle karşı karşıyadır. Bir işlem platformu, EVM ekosisteminde potansiyel bir rakip olarak, zincir üzerindeki aktif adres sayısını hızla artırıyor. Aynı zamanda, Solana'nın DeFi alanındaki toplam kilitli değer (TVL) tarihi bir zirveye ulaşmış olsa da, bir işlem platformu gibi rakipler de pazar payını hızla ele geçiriyor ve bir işlem platformu ekosisteminin finansman miktarı, Q2 çeyreğinde ilk kez Solana'yı geçiyor.
Solana, teknik ve pazar kabulü açısından belli bir başarı elde etmesine rağmen, belirli bir ticaret platformu gibi rakiplerin getirdiği zorluklarla başa çıkmak için sürekli yenilik ve iyileştirme yapması 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ı yavaşlatma konularında, Solana'nın teknik mimarisini ve ağ protokollerini sürekli olarak optimize etmesi gerekmektedir, böylece blockchain endüstrisindeki lider konumunu koruyabilir.
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ı sonlanma (Finality) ile tanınmaktadır. Bileşenlerinin nasıl çalıştığını, yüksek performans hedeflerini gerçekleştirmek için mimari tasarımda nasıl işlev gördüğünü ve bu mimari tasarımın getirdiği dezavantajlar ile türetilen 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, temel şifreleme SHA256 teknolojisinden kaynaklanmaktadır. SHA256 genellikle verilerin bütünlüğünü hesaplamak için kullanılır; verilen bir X girişi için yalnızca benzersiz bir Y çıktısı vardır, bu nedenle X'teki herhangi bir değişiklik Y'yi tamamen farklı hale getirecektir.
Solana'nın POH dizisinde, sha256 algoritması uygulanarak tüm dizinin bütünlüğü sağlanabilir ve bu da içindeki işlemlerin bütünlüğünü belirler. Örneğin, işlemleri bir blok haline getirip karşılık gelen sha256 hash değerini oluşturursak, bu blok içindeki işlemler kesinleşmiş olur; herhangi bir değişiklik hash değerinin değişmesine neden olur. Daha sonra bu blok hash, bir sonraki sha256 fonksiyonunun X'inin bir parçası olarak kullanılacak ve bir sonraki blokun hash'i eklenecektir. Böylece ö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 blok 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ış ş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 Lider düğümü oluşturulmaktadır. Bu Lider düğüm, işlemleri toplar ve sıralı bir şekilde yürütür, POH dizisi üretir, ardından bir blok oluşturup diğer düğümlere dağıtır.
Leader düğümünde tek nokta arızasını önlemek için zaman sınırlaması getirilmiştir. Solana'da zaman birimleri epoch ile bölünmüştür; her epoch 432.000 slot (zaman dilimi) içerir ve her slot 400 ms sürer. Her bir slotta, döngü sistemi her slot içinde bir Leader düğümü atar. Leader düğümü, belirlenen slot süresi içinde blok yayımlamak zorundadır (400 ms); aksi takdirde, bu slot atlanır ve bir sonraki slotun Leader düğümü yeniden seçilir.
Genel olarak, Lider düğümleri 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 Lidere iletir, Lider düğümü işlemleri paketleyip sıralar ve ardından blok üretir, 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 kullanmaları 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 belirli bir mühendislik uygulamasıdır. Bu algoritma, POH algoritmasıyla da ilişkilidir. Bloklar oylanırken, eğer doğrulayıcıların oyları kendileri bir işlemse, o zaman kullanıcı işlemleri ve doğrulayıcı işlemlerinin oluşturduğu blok hash'i tarihi bir kanıt olarak kullanılabilir. Hangi kullanıcının işlem detayları ve doğrulayıcının oy detayları benzersiz olarak doğrulanabilir.
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ştirilebilir. Bu mekanizmanın avantajı, sadece hash dizisine oy vermek yeterli olduğu için büyük miktarda bellek tasarrufu sağlamasıdır. Ancak geleneksel konsensüs mekanizmalarında genellikle blok yayılması kullanılır; bir doğrulayıcı bloku aldığında, çevresindeki doğrulayıcılara gönderir. Bu, bir doğrulayıcının aynı bloğu birden fazla kez almasına neden olarak ağda büyük bir fazlalığa yol açar.
Solana'da, çok sayıda doğrulayıcı oylama işlemi bulunması ve Lider düğümünün merkezileşmesinin getirdiği verimlilik ile 400ms'lik Slot süresi nedeniyle, genel blok boyutu ve blok üretim sıklığı özellikle yüksektir. Büyük blokların yayılması, ağda büyük bir baskı yaratır; Solana, büyük blokların yayılma sorununu çözmek için Turbine mekanizmasını kullanır.
Türbin
Leader düğümü, Sharding olarak bilinen bir süreç aracılığıyla blokları shred adı verilen alt bloklara böler, bu alt blokların boyutları MTU (Maksimum İletim Birimi, bir düğümden diğerine bölmeye gerek kalmadan gönderilebilecek maksimum veri miktarı) cinsindendir. Daha sonra verilerin bütünlüğünü ve kullanılabilirliğini sağlamak için Reed-Solomon silme kodu şemasını kullanır.
Verileri dört Data Shred'e bölerek, veri aktarımı sırasında paket kaybı ve bozulmayı önlemek için Reed-Solomon kodlaması kullanılarak dört paket sekiz pakete kodlanır; bu yöntem 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 yöntem mevcut Solana mimarisi ile çok iyi bir şekilde uyum sağlamaktadır.
Alt düzeyde veri iletiminde genellikle UDP/TCP protokolünün kullanılması düşünülür. Solana'nın paket kaybı oranına 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ı iletim hızıdır. Aksine, TCP protokolü paket kaybı durumunda yeniden birçok kez iletim yapar ve 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 ve gerçek ortamda verimliliği 9 kat artırabilir.
Turbine verileri parçalayarak, çok katmanlı yayılma mekanizması kullanarak yayıyor. Lider düğüm, her Slot'un bitiminden önce blokları herhangi bir blok doğrulayıcısına teslim edecek, ardından bu doğrulayıcı blokları Shred'lere ayıracak ve hata düzeltme kodu üretecek. Bu doğrulayıcı daha sonra Turbine yayılmasını başlatacak. Öncelikle kök düğüme yayılacak ve ardından bu kök düğüm hangi doğrulayıcıların hangi katmanda olduğunu belirleyecek. Süreç aşağıdaki gibidir:
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 payına (yani stake edilen SOL miktarına) göre sıralar; daha yüksek ağırlığa sahip olanlar birinci katmanda yer alır, bu şekilde devam eder.
Düğüm Gruplaması: Ardından, birinci katmanda bulunan her doğrulayıcı kendi düğüm listesini oluşturarak kendi birinci katmanını inşa edecektir.
Kat oluşturma: Liste üstünden düğümleri katlara ayırarak, derinlik ve genişlik değerlerini belirleyerek, tüm ağacın genel şekli belirlenebilir. Bu parametre, shreds'in yayılma hızını etkiler.
Yüksek hak sahipliği oranına sahip olan düğümler, katmanların bölünmesinde bir üst kata geçerse, tam shreds'leri önceden elde edebilirler. Bu durumda, tam blokları geri yükleyebilirler. Daha sonraki katmanlardaki düğümler ise, iletim kaybı nedeniyle, tam shreds'leri elde etme olasılıkları azalır. Eğer bu shreds'ler tam parçalar oluşturmak için yeterli değilse, Lider'in doğrudan yeniden iletim yapması istenecektir. Bu durumda, veri iletimi ağacın iç kısmına yönlendirilir ve ilk katman düğümleri çoktan tam blok onayını oluşturmuşlardır. Daha sonraki katmanlardaki doğrulayıcıların blok oluşturmayı tamamladıktan sonra oy verme 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 önce shreds parçalarını alarak tam bir blok oluşturur ve oylama konsensüsünü sağlamak için süreci tamamlar. Gereksizliği 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ü aslında ilk birkaç katman, 2/3 düğümü temsil ediyor olabilir; bu durumda sonraki düğümlerin oyu artık önemli olmayacaktır.
SVM
Solana, saniyede binlerce işlemi işleyebilme yeteneğine sahip olmasının başlıca nedeni, POH mekanizması, Tower BFT konsensüsü ve Turbine veri yayılım mekanizmasıdır. Ancak, SVM bir durum dönüşüm sanal makinesi olarak, eğer Lider düğüm işlem yürütme sırasında SVM 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.
SVM'de, talimatlar 4 bölümden oluşur; program ID'si, program talimatı ve veri okuma/yazma hesap listesi içerir. Mevcut hesabın okuma veya yazma durumunda olup olmadığını ve durum değişikliği yapılacak işlemin çakışıp çakışmadığını belirleyerek, hesapların ticaret talimatlarında durum çakışması olmayan paralelleştirmeye izin verilebilir, her talimat Program ID'si ile temsil edilir. Bu da Solana'nın doğrulayıcılar için yüksek gereksinimlere sahip olmasının nedenlerinden biridir, çünkü doğrulayıcıların GPU/CPU'larının SIMD (tek talimat çok veri) ve AVX yüksek desteklemesi gerekmektedir.