Solana teknik mimarisi yeniden analiz: İkinci baharını mı yaşıyor?
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şlemlerin sırasını ve küresel saati garanti eden Proof of History (POH) algoritması, blok oluşturma hızını artıran Lider Değişim Programı ve Tower BFT konsensüs mekanizması bulunmaktadır. Turbine mekanizması, büyük blokların iletimini optimize etmek için Reed-solomon kodlamasını kullanır. Solana Sanal Makinesi (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 sağlaması için mimari tasarımlardır, ancak aynı zamanda ağ kesintileri, işlem hataları, MEV sorunları, durumun hızlı büyümesi ve merkezileşme sorunları gibi bazı sorunları da beraberinde getirmiştir.
Solana ekosistemi hızla gelişiyor, çeşitli 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 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, blok zinciri 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, Solana blok zinciri teknolojisini günlük uygulamalara entegre etmeye çalışıyor, böylece kullanıcıların kabulünü ve kolaylığını artırıyor. Örneğin, Stepn gibi uygulamalar, blok zincirini ve mobil teknolojiyi birleştirerek kullanıcılara yenilikçi bir spor ve sosyal deneyim sunuyor. Şu anda birçok tüketici uygulaması en iyi iş modeli ve pazar konumunu keşfetmeye devam etse de, Solana'nın sunduğu teknolojik platform ve ekosistem desteği, 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ı hikayesi gerçekleştirmesi bekleniyor.
Solana, yüksek işlem hacmi ve düşük işlem maliyeti ile blok zinciri endüstrisinde önemli bir pazar payı elde etmesine rağmen, diğer yeni ortaya çıkan kamu zincirlerinden gelen yoğun bir rekabetle karşı karşıya kalmaktadır. Bir işlem platformu, EVM ekosisteminde potansiyel bir rakip olarak, zincir üzerindeki aktif adres sayısını hızla artırmakta, aynı zamanda, Solana'nın DeFi alanındaki toplam kilitli değeri (TVL) tarihi bir zirveye ulaşmış olsa da, bir işlem platformu gibi rakipler de hızlı bir şekilde pazar payını ele geçirmektedir. Bir işlem platformu ekosisteminin finansman miktarı da Q2 çeyreğinde ilk kez Solana'yı geçmiştir.
Solana, teknik ve pazar kabulü açısından belirli başarılar elde etmesine rağmen, belirli bir ticaret platformu 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ı düşürme, MEV sorununu çözme ve durum büyüme hızını yavaşlatma konularında, Solana'nın blockchain sektöründeki liderliğini korumak için teknik mimarisini ve ağ protokolünü sürekli optimize etmesi gerekmektedir.
Teknik Mimari
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ınmaktadır. Bileşenlerin nasıl çalıştığını, yüksek performans hedeflerinin mimari tasarıma nasıl yansıtıldığını ve bu mimari tasarımın getirdiği dezavantajlar ve 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ğildir, bunun yerine işlemlerin sırasını belirleyen bir algoritmadır. POH teknolojisi, en temel kriptografi olan 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 benzersiz çıktı Y vardır, bu nedenle X'teki herhangi bir değişiklik Y'yi tamamen farklı hale getirecektir.
Solana'nın POH dizisinde, sha256 algoritmasının uygulanmasıyla tüm dizinin bütünlüğü sağlanır ve böylece içindeki işlemlerin bütünlüğü de belirlenir. Örneğin, işlemleri bir blokta toplarsak, ilgili sha256 hash değeri oluşturulur, bu durumda 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 ve bir sonraki blok hash'i eklenecektir, böylece önceki blok ve bir sonraki blok belirlenmiş olur; herhangi bir değişiklik yeni Y'nin farklı olmasına yol açar.
Bu, Proof of History teknolojisinin temel anlamıdır; bir önceki blok hash'i, bir sonraki sha256 fonksiyonunun bir parçası olarak kullanılacak, bir zincir gibi, en son Y her zaman geçmişin kanıtını içerir.
Solana'nın işlem akış mimarisi şemasında, POH mekanizması altındaki işlem süreci tanımlanmıştır. 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ı bir şekilde yürütür, POH dizisi oluşturur ve ardından bir blok oluşturup diğer düğümlere yayar.
Leader düğümünde tek nokta hatasını önlemek için zaman sınırlaması getirildi. Solana'da zaman birimi epoch ile belirlenir, her epoch 432,000 slot( içerir, her slot 400ms sürer. Her bir slotta, döngüsel sistem her slot içinde bir Leader düğümü atar, Leader düğümü belirli slot zamanı içinde blok)400ms( yayınlamalıdı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 tüm geçmiş işlemleri kesinleştirebilir. Solana'nın temel zaman birimi Slot'tur, Leader 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şturur, blok diğer doğrulayıcılara yayılır, doğrulayıcılar bir mekanizma aracılığıyla konsensusa ulaşmak zorundadır, blok içindeki işlemler ve sıralama üzerinde konsensusa varılır, bu konsensusta kullanılan mekanizma Tower BFT konsensüs mekanizmasıdır.
) Tower BFT konsensüs mekanizması
Tower BFT konsensüs protokolü, BFT konsensüs algoritmasından kaynaklanır ve onun bir mühendislik uygulamasıdır. Bu algoritma hala POH algoritması ile ilişkilidir. Bloklar oylanırken, eğer doğrulayıcıların oyu kendisi bir işlem ise, o zaman kullanıcı işlemleri ve doğrulayıcı işlemleri tarafından oluşturulan 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ıların oy detaylarının benzersiz bir şekilde doğrulanması mümkündür.
![Solana teknik mimarisi yeniden değerlendiriliyor: İ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 kullanırsa ve %2/3'ten fazla doğrulayıcı onay oyu verirse, o zaman bu blok onaylanmış olur. Bu mekanizmanın avantajı, yalnızca hash dizisi üzerinde oy kullanarak blokun onaylanabilmesi nedeniyle büyük miktarda bellek tasarrufu sağlamasıdır. Ancak geleneksel konsensüs mekanizmalarında genellikle blok seli kullanılır; yani bir doğrulayıcı bloğu aldığında, hemen çevresindeki doğrulayıcılara gönderir, bu da ağda büyük bir fazlalığa neden olur çünkü bir doğrulayıcı aynı bloğu birden fazla kez alır.
Solana'da, çok sayıda doğrulayıcı oy işleminin bulunması ve Leader düğümünün merkezileşmesinin getirdiği verimlilik ile 400ms'lik Slot süresi nedeniyle, genel blok boyutu ve blok üretim sıklığı oldukça yüksektir. Büyük blokların yayılması, ağa büyük bir baskı yapabilir. Solana, büyük blokların yayılma sorununu çözmek için Turbine mekanizmasını kullanır.
) Turbine
Leader düğümü, Sharding adı verilen bir süreçle blokları shred adı verilen alt parçalara böler. Bu parçaların boyutu, MTU### maksimum iletim birimi olarak belirlenmiştir; bu sayede daha küçük birimlere bölmeden, bir düğümden diğerine iletilebilecek maksimum veri miktarı ( birimi cinsindendir. 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 aktarımı sırasında paket kaybı ve hasarını önlemek amacıyla 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 mimarisi ile iyi bir şekilde uyum sağlamaktadır.
![Tekrar çözüm Solana teknik mimarisi: İkinci bahar mı geliyor?])https://img-cdn.gateio.im/webp-social/moments-e9bc35d0c790496c59c20979e5af1491.webp(
Altyapı veri iletiminde genellikle UDP/TCP protokolünün kullanılması düşünülür. Solana'nın paket kaybına karşı toleransı yüksek olduğundan, iletim için UDP protokolü kullanılmıştır. Bunun dezavantajı, paket kaybı durumunda tekrar iletim yapılmamasıdır, ancak avantajı daha hızlı iletim hızıdır. Aksine, TCP protokolü paket kaybı durumunda tekrar tekrar iletim yapar ve 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 bir ortamda verimlilik 9 kat artırılabilir.
Turbine, verileri parçalayarak çok katmanlı bir yayılma mekanizması kullanır; Lider düğüm, her Slot'un sonundan önce 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ı üretir. Bu doğrulayıcı daha sonra Turbine yayılmasını başlatır. İlk olarak kök düğüme yayılması gerekir, 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:
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ı olan ) 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 birinci katmanını oluşturmak için kendi düğüm listesini oluşturacaktır.
Kat oluşumu: 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 sahibi olan düğümler, katmanların belirlenmesinde bir üst seviyede yer alırsa, tam shreds'leri önceden alabilirler. Bu durumda tam blokları geri yükleyebilirler. 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ı gerekecektir. Bu aşamada veri iletimi ağaç iç kısmına yönlendirilir ve ilk katmandaki düğümler çoktan tam blok onayını oluşturmuşlardır; dolayısıyla daha sonraki katmanlardaki doğrulayıcıların blok inşasını tamamlayıp oy verme süresi daha uzun olacaktır.
Bu mekanizmanın düşüncesi, Lider düğümün tek düğüm mekanizmasına benzerdir. Blok yayılım sürecinde bazı öncelikli düğümler de vardır; bu düğümler, oylama konsensüsünü sağlamak için önce shreds parçalarını alarak tam blok oluştururlar. Fazlalığı daha derin katmanlara yönlendirmek, Finality'nin ilerlemesini ö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 ediyorsa, sonraki düğümlerin oylaması artık önemsiz hale gelir.
( SVM
Solana, saniyede binlerce işlemi işleyebilme yeteneğine, esas olarak POH mekanizması, Tower BFT konsensüsü ve Turbine veri yayılım mekanizması sayesinde sahiptir. Ancak, SVM bir durum geçiş 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 durum tüm sistemin verimliliğini azaltır. Bu nedenle SVM için Solana, işlemlerin yürütme hızını artırmak amacıyla Sealevel paralel yürütme motorunu geliştirmiştir.
![Solana teknik mimarisini yeniden keşfedin: İkinci baharını mı yaşayacak?])https://img-cdn.gateio.im/webp-social/moments-9fd8693259e2864d6978d2b4e8ef2e85.webp###
SVM'de, talimatlar 4 bölümden oluşur: program kimliği, program talimatı ve okuma/yazma verileri için hesap listesi. Mevcut hesabın okuma mı yoksa yazma mı durumunda olduğunu ve durum değişikliği yapılacak işlemlerin çelişip çelişmediğini belirleyerek, hesapların işlem talimatlarındaki çelişki olmayan durumların paralel hale getirilmesine izin verilebilir, her talimat Program ID ile temsil edilir. Bu da, Solana'nın doğrulayıcılarının yüksek gereksinimlerinin nedenlerinden biridir, çünkü doğrulayıcının GPU/CPU'sunun SIMD( tek talimat çoklu veri) ve AVX gelişmiş 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
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.
25 Likes
Reward
25
7
Repost
Share
Comment
0/400
FlyingLeek
· 08-16 08:29
sol tekrar büyük yükseliş mi yapmak istiyor?
View OriginalReply0
NervousFingers
· 08-15 01:45
Bu kadar hızlı koşmak sadece satmak demek.
View OriginalReply0
MemeTokenGenius
· 08-13 22:07
Ritim yine geldi, solun ayağa kalkabileceğine inanmıyorum.
Solana teknolojisi mimarisi Derinlik analizi Yüksek TPS'in arkasındaki zorluklar ve fırsatlar
Solana teknik mimarisi yeniden analiz: İkinci baharını mı yaşıyor?
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şlemlerin sırasını ve küresel saati garanti eden Proof of History (POH) algoritması, blok oluşturma hızını artıran Lider Değişim Programı ve Tower BFT konsensüs mekanizması bulunmaktadır. Turbine mekanizması, büyük blokların iletimini optimize etmek için Reed-solomon kodlamasını kullanır. Solana Sanal Makinesi (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 sağlaması için mimari tasarımlardır, ancak aynı zamanda ağ kesintileri, işlem hataları, MEV sorunları, durumun hızlı büyümesi ve merkezileşme sorunları gibi bazı sorunları da beraberinde getirmiştir.
Solana ekosistemi hızla gelişiyor, çeşitli 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 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, blok zinciri 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, Solana blok zinciri teknolojisini günlük uygulamalara entegre etmeye çalışıyor, böylece kullanıcıların kabulünü ve kolaylığını artırıyor. Örneğin, Stepn gibi uygulamalar, blok zincirini ve mobil teknolojiyi birleştirerek kullanıcılara yenilikçi bir spor ve sosyal deneyim sunuyor. Şu anda birçok tüketici uygulaması en iyi iş modeli ve pazar konumunu keşfetmeye devam etse de, Solana'nın sunduğu teknolojik platform ve ekosistem desteği, 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ı hikayesi gerçekleştirmesi bekleniyor.
Solana, yüksek işlem hacmi ve düşük işlem maliyeti ile blok zinciri endüstrisinde önemli bir pazar payı elde etmesine rağmen, diğer yeni ortaya çıkan kamu zincirlerinden gelen yoğun bir rekabetle karşı karşıya kalmaktadır. Bir işlem platformu, EVM ekosisteminde potansiyel bir rakip olarak, zincir üzerindeki aktif adres sayısını hızla artırmakta, aynı zamanda, Solana'nın DeFi alanındaki toplam kilitli değeri (TVL) tarihi bir zirveye ulaşmış olsa da, bir işlem platformu gibi rakipler de hızlı bir şekilde pazar payını ele geçirmektedir. Bir işlem platformu ekosisteminin finansman miktarı da Q2 çeyreğinde ilk kez Solana'yı geçmiştir.
Solana, teknik ve pazar kabulü açısından belirli başarılar elde etmesine rağmen, belirli bir ticaret platformu 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ı düşürme, MEV sorununu çözme ve durum büyüme hızını yavaşlatma konularında, Solana'nın blockchain sektöründeki liderliğini korumak için teknik mimarisini ve ağ protokolünü sürekli optimize etmesi gerekmektedir.
Teknik Mimari
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ınmaktadır. Bileşenlerin nasıl çalıştığını, yüksek performans hedeflerinin mimari tasarıma nasıl yansıtıldığını ve bu mimari tasarımın getirdiği dezavantajlar ve 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ğildir, bunun yerine işlemlerin sırasını belirleyen bir algoritmadır. POH teknolojisi, en temel kriptografi olan 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 benzersiz çıktı Y vardır, bu nedenle X'teki herhangi bir değişiklik Y'yi tamamen farklı hale getirecektir.
Solana'nın POH dizisinde, sha256 algoritmasının uygulanmasıyla tüm dizinin bütünlüğü sağlanır ve böylece içindeki işlemlerin bütünlüğü de belirlenir. Örneğin, işlemleri bir blokta toplarsak, ilgili sha256 hash değeri oluşturulur, bu durumda 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 ve bir sonraki blok hash'i eklenecektir, böylece önceki blok ve bir sonraki blok belirlenmiş olur; herhangi bir değişiklik yeni Y'nin farklı olmasına yol açar.
Bu, Proof of History teknolojisinin temel anlamıdır; bir önceki blok hash'i, bir sonraki sha256 fonksiyonunun bir parçası olarak kullanılacak, bir zincir gibi, en son Y her zaman geçmişin kanıtını içerir.
Solana'nın işlem akış mimarisi şemasında, POH mekanizması altındaki işlem süreci tanımlanmıştır. 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ı bir şekilde yürütür, POH dizisi oluşturur ve ardından bir blok oluşturup diğer düğümlere yayar.
Leader düğümünde tek nokta hatasını önlemek için zaman sınırlaması getirildi. Solana'da zaman birimi epoch ile belirlenir, her epoch 432,000 slot( içerir, her slot 400ms sürer. Her bir slotta, döngüsel sistem her slot içinde bir Leader düğümü atar, Leader düğümü belirli slot zamanı içinde blok)400ms( yayınlamalıdı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 tüm geçmiş işlemleri kesinleştirebilir. Solana'nın temel zaman birimi Slot'tur, Leader 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şturur, blok diğer doğrulayıcılara yayılır, doğrulayıcılar bir mekanizma aracılığıyla konsensusa ulaşmak zorundadır, blok içindeki işlemler ve sıralama üzerinde konsensusa varılır, bu konsensusta kullanılan mekanizma Tower BFT konsensüs mekanizmasıdır.
) Tower BFT konsensüs mekanizması
Tower BFT konsensüs protokolü, BFT konsensüs algoritmasından kaynaklanır ve onun bir mühendislik uygulamasıdır. Bu algoritma hala POH algoritması ile ilişkilidir. Bloklar oylanırken, eğer doğrulayıcıların oyu kendisi bir işlem ise, o zaman kullanıcı işlemleri ve doğrulayıcı işlemleri tarafından oluşturulan 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ıların oy detaylarının benzersiz bir şekilde doğrulanması mümkündür.
![Solana teknik mimarisi yeniden değerlendiriliyor: İ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 kullanırsa ve %2/3'ten fazla doğrulayıcı onay oyu verirse, o zaman bu blok onaylanmış olur. Bu mekanizmanın avantajı, yalnızca hash dizisi üzerinde oy kullanarak blokun onaylanabilmesi nedeniyle büyük miktarda bellek tasarrufu sağlamasıdır. Ancak geleneksel konsensüs mekanizmalarında genellikle blok seli kullanılır; yani bir doğrulayıcı bloğu aldığında, hemen çevresindeki doğrulayıcılara gönderir, bu da ağda büyük bir fazlalığa neden olur çünkü bir doğrulayıcı aynı bloğu birden fazla kez alır.
Solana'da, çok sayıda doğrulayıcı oy işleminin bulunması ve Leader düğümünün merkezileşmesinin getirdiği verimlilik ile 400ms'lik Slot süresi nedeniyle, genel blok boyutu ve blok üretim sıklığı oldukça yüksektir. Büyük blokların yayılması, ağa büyük bir baskı yapabilir. Solana, büyük blokların yayılma sorununu çözmek için Turbine mekanizmasını kullanır.
) Turbine
Leader düğümü, Sharding adı verilen bir süreçle blokları shred adı verilen alt parçalara böler. Bu parçaların boyutu, MTU### maksimum iletim birimi olarak belirlenmiştir; bu sayede daha küçük birimlere bölmeden, bir düğümden diğerine iletilebilecek maksimum veri miktarı ( birimi cinsindendir. 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 aktarımı sırasında paket kaybı ve hasarını önlemek amacıyla 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 mimarisi ile iyi bir şekilde uyum sağlamaktadır.
![Tekrar çözüm Solana teknik mimarisi: İkinci bahar mı geliyor?])https://img-cdn.gateio.im/webp-social/moments-e9bc35d0c790496c59c20979e5af1491.webp(
Altyapı veri iletiminde genellikle UDP/TCP protokolünün kullanılması düşünülür. Solana'nın paket kaybına karşı toleransı yüksek olduğundan, iletim için UDP protokolü kullanılmıştır. Bunun dezavantajı, paket kaybı durumunda tekrar iletim yapılmamasıdır, ancak avantajı daha hızlı iletim hızıdır. Aksine, TCP protokolü paket kaybı durumunda tekrar tekrar iletim yapar ve 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 bir ortamda verimlilik 9 kat artırılabilir.
Turbine, verileri parçalayarak çok katmanlı bir yayılma mekanizması kullanır; Lider düğüm, her Slot'un sonundan önce 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ı üretir. Bu doğrulayıcı daha sonra Turbine yayılmasını başlatır. İlk olarak kök düğüme yayılması gerekir, 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:
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ı olan ) 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 birinci katmanını oluşturmak için kendi düğüm listesini oluşturacaktır.
Kat oluşumu: 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 sahibi olan düğümler, katmanların belirlenmesinde bir üst seviyede yer alırsa, tam shreds'leri önceden alabilirler. Bu durumda tam blokları geri yükleyebilirler. 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ı gerekecektir. Bu aşamada veri iletimi ağaç iç kısmına yönlendirilir ve ilk katmandaki düğümler çoktan tam blok onayını oluşturmuşlardır; dolayısıyla daha sonraki katmanlardaki doğrulayıcıların blok inşasını tamamlayıp oy verme süresi daha uzun olacaktır.
Bu mekanizmanın düşüncesi, Lider düğümün tek düğüm mekanizmasına benzerdir. Blok yayılım sürecinde bazı öncelikli düğümler de vardır; bu düğümler, oylama konsensüsünü sağlamak için önce shreds parçalarını alarak tam blok oluştururlar. Fazlalığı daha derin katmanlara yönlendirmek, Finality'nin ilerlemesini ö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 ediyorsa, sonraki düğümlerin oylaması artık önemsiz hale gelir.
( SVM
Solana, saniyede binlerce işlemi işleyebilme yeteneğine, esas olarak POH mekanizması, Tower BFT konsensüsü ve Turbine veri yayılım mekanizması sayesinde sahiptir. Ancak, SVM bir durum geçiş 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 durum tüm sistemin verimliliğini azaltır. Bu nedenle SVM için Solana, işlemlerin yürütme hızını artırmak amacıyla Sealevel paralel yürütme motorunu geliştirmiştir.
![Solana teknik mimarisini yeniden keşfedin: İkinci baharını mı yaşayacak?])https://img-cdn.gateio.im/webp-social/moments-9fd8693259e2864d6978d2b4e8ef2e85.webp###
SVM'de, talimatlar 4 bölümden oluşur: program kimliği, program talimatı ve okuma/yazma verileri için hesap listesi. Mevcut hesabın okuma mı yoksa yazma mı durumunda olduğunu ve durum değişikliği yapılacak işlemlerin çelişip çelişmediğini belirleyerek, hesapların işlem talimatlarındaki çelişki olmayan durumların paralel hale getirilmesine izin verilebilir, her talimat Program ID ile temsil edilir. Bu da, Solana'nın doğrulayıcılarının yüksek gereksinimlerinin nedenlerinden biridir, çünkü doğrulayıcının GPU/CPU'sunun SIMD( tek talimat çoklu veri) ve AVX gelişmiş 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