Solana Teknoloji Mimarisi ve Ekosistem Gelişimi Üzerine İnceleme
Solana, yüksek performanslı bir blok zinciri platformudur ve yüksek işlem hacmi ile düşük gecikmeyi 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 Değişim 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 yürütme hızını artırır. Bunlar, Solana'nın yüksek performanslı mimari tasarımını sağlasa da, ağ kesintileri, işlem başarısızlıkları, MEV sorunları, durum büyümesinin aşırı hızı ve merkeziyetçilik 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 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 daha zayıf olan ekosistem, girişimciler ve geliştiriciler için zengin 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 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 kolaylığını artırmayı hedefliyor.
Solana, blok zinciri endüstrisinde yüksek işlem hacmi ve düşük işlem maliyeti ile önemli bir pazar payı elde etmesine rağmen, diğer yeni ortaya çıkan kamu blok zincirlerinden gelen yoğun rekabetle karşı karşıya kalmaktadır. EVM ekosistemindeki potansiyel bir rakip olan Base'in zincir üzerindeki aktif adres sayısı hızla artmakta, aynı zamanda Solana'nın DeFi alanındaki toplam kilitli değer (TVL) tarihi bir zirveye ulaşmış olsa da, Base gibi rakipler de hızla pazar payı kapmaktadır ve Base ekosisteminin finansman miktarı da Q2 çeyreğinde Solana'yı ilk kez geçmiştir.
Solana, teknik ve piyasa kabulü açısından belli bir başarı elde etmesine rağmen, Base gibi rakiplerinin getirdiği zorluklarla başa çıkmak için sürekli yenilik ve gelişim gerekmektedir. Ö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 gibi konularda, Solana'nın teknik mimarisini ve ağ protokollerini sürekli olarak optimize etmesi gerekmektedir, böylece blockchain endüstrisindeki 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ınır. Her bir bileşenin nasıl çalıştığı, yüksek performans hedefinin mimari tasarımda nasıl gerçekleştirildiği ve bu mimari tasarımın getirdiği dezavantajlar ve türettiği sorunlar.
POH algoritması
POH(Tarih Kanıtı), küresel zamanı belirleyen bir tekniktir; bu bir konsensüs mekanizması değildir, daha çok işlem 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 tane ve benzersiz bir çıktı Y vardır, bu nedenle X'teki herhangi bir değişiklik Y'yi tamamen farklı hale getirir.
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 belirlenmiş olur. Örneğin, işlemleri bir blokta paketlediğimizde, ilgili sha256 hash değerini ürettiğimizde, o bloktaki işlemler belirlenmiş olur, herhangi bir değişiklik hash değerinin değişmesine neden olur. Daha sonra bu blok hash, bir sonraki sha256 fonksiyonunun X kısmı olarak kullanılacak, ardından bir sonraki blok hash'i eklenecek, böylece hem önceki blok hem de sonraki blok belirlenmiş 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 şemasında, POH mekanizması altındaki işlem süreci açıklanmaktadır. Leader Rotation Schedule adlı bir döngü mekanizması altında, tüm zincir üzerindeki doğrulayıcılar arasında bir Leader düğümü oluşturulmaktadır. Bu Leader düğümü işlemleri toplar ve sıralı bir şekilde yürütür, POH dizisi oluşturur, ardından bir blok oluşturup diğer düğümlere yayar.
Bir Leader düğümünün tek noktada arıza vermesini önlemek için zaman sınırlaması getirilmiştir. Solana'da zaman birimleri epoch ile bölümlendirilir, her epoch 432.000 slot( 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 süresi içerisinde blok yayınlamak zorundadır)400ms(, 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 tarihi işlemleri tamamen kesinleştirir. Solana'nın temel zaman birimi Slot'tur, Leader düğümün bir slot içinde blok yayınlaması gerekir. Kullanıcılar, işlemleri RPC düğümü aracılığıyla Leader'a iletir, Leader düğüm işlemleri paketleyip sıralar ve ardından blok oluşturur, 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 aracılığıyla fikir birliğine varmalıdır; 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 somut mühendislik uygulamasıdır. Bu algoritma hala POH algoritmasıyla ilişkilidir. Bloklar üzerinde oy kullanırken, eğer doğrulayıcıların oyu kendisi bir işlemse, o zaman kullanıcı işlemleri ve doğrulayıcı işlemleriyle oluşan 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 doğrulanmasını sağlayan tarihi bir kanıt olarak kullanılabilir.
![Solana teknik mimarisini tekrar açıklamak: İkinci baharını mı yaşayacak?]###https://img-cdn.gateio.im/webp-social/moments-c210b4025cb64385890634a405838d05.webp(
Tower BFT algoritmasında, tüm doğrulayıcıların bu bloğa oy vermesi durumunda, 2/3'ten fazla doğrulayıcı onay oyu verirse, bu blok kesinleşebilir. Bu mekanizmanın avantajı, yalnızca hash dizisi üzerinde 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 seli kullanılır; bir doğrulayıcı bloğu aldığında, çevresindeki doğrulayıcılara gönderecektir. Bu, bir doğrulayıcının aynı bloğu birden fazla kez almasına neden olduğu için ağda büyük bir fazlalığa yol açar.
Solana'da, çok sayıda doğrulayıcı oylama işlemi ve Lider düğümü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üksek olmaktadır. Büyük blokların yayılması, ağa büyük bir yük getirebilir; Solana, büyük blokların yayılma sorununu çözmek için Turbine mekanizmasını kullanır.
) Turbine
Leader düğümü, blokları Sharding olarak adlandırılan bir süreçle shred alt bloklarına ayırır; bunların boyutu, MTU### maksimum iletim birimi olarak belirlenmiştir. Bir düğümden diğerine daha küçük birimlere bölmeden 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.
Blokları dört Data Shred'e bölerek, veri iletimi sırasında paket kaybı ve hasarını önlemek için dört paketi sekiz pakete kodlamak üzere Reed-Solomon kodlaması kullanılır. Bu çözüm, en fazla %50 paket kaybı toleransına sahiptir. Gerçek testlerde, Solana'nın paket kaybı oranı yaklaşık %15'tir, bu nedenle bu çözüm mevcut Solana mimarisiyle iyi bir uyum sağlamaktadır.
Veri iletiminde genellikle UDP/TCP protokollerinin kullanılması düşünülmektedir. Solana'nın kayıp paket oranına toleransı yüksek olduğundan, iletim için UDP protokolü tercih edilmiştir. Bunun dezavantajı, kayıp paket olduğunda yeniden iletim yapılmamasıdır, ancak avantajı daha hızlı iletim hızıdır. Aksine, TCP protokolü kayıp paket olduğunda yeniden birçok kez iletim yapar, bu da iletim hızını ve verimliliğini büyük ölçüde azaltır. Reed-Solomon teknolojisi ile bu sistem, Solana'nın verimliliğini önemli ölçüde artırabilir, gerçek ortamda verimlilik 9 kat artabilir.
![Solana teknik mimarisini yeniden keşfetmek: İkinci bahar mı geliyor?])https://img-cdn.gateio.im/webp-social/moments-224796bc8e080649730bb8736334abba.webp(
Turbine, verileri parçaladıktan sonra, çok katmanlı yayılma mekanizması kullanarak yayılır. Lider düğümü, her Slot'un sona ermesinden önce bir blok verisini rastgele bir blok doğrulayıcısına teslim eder. Ardından, bu doğrulayıcı bloğu Shred'lere ayırır ve hata düzeltme kodu oluşturur. Bu doğrulayıcı daha sonra Turbine yayılımını başlatır. Öncelikle kök düğüme yayılması gerekir, 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:
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ı ) 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.
Düğüm Grupları: Ardından, birinci katmandaki her doğrulayıcı, kendi birinci katmanını oluşturmak için kendi düğüm listesini de oluşturacaktır.
Kat oluşumu: Düğümleri listenin tepesinden 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 düğümler, katmanların belirlenmesi sırasında bir üst katmana çıkarak, tam shreds'leri önceden elde edebilirler. Bu durumda tam blokları geri yükleyebilirler. Daha alt katmandaki düğümler, iletim kaybı nedeniyle tam shreds elde etme olasılıkları düşer. Eğer bu shreds, tam parçalar oluşturmak için yeterli değilse, Leader'dan doğrudan yeniden iletim talep edilecektir. Bu durumda veri iletimi ağaç iç kısmına yönlenecektir ve ilk katmandaki düğümler çoktan tam blok onaylarını oluşturmuşlardır. Bu nedenle daha alt 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üğümlü mekanizmasına benzer. Blok yayılım sürecinde bazı öncelikli düğümler de bulunmaktadı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. Gereksiz olanı daha derin bir seviyeye itmek, Finality'nin gerçekleşimini önemli ölçüde hızlandırabilir ve verimliliği ve throughput'u maksimize edebilir. Çünkü aslında öncelikli birkaç katman, 2/3 düğümü temsil ediyorsa, sonraki düğümlerin oylaması 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 bir durum geçiş 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 işlem hacmini düşürebilir. Bu nedenle, SVM için Solana, işlem hızını artırmak amacıyla Sealevel paralel yürütme motorunu önermiştir.
![Solana teknik mimarisi yeniden açıklanıyor: İkinci bahar mı geliyor?]###https://img-cdn.gateio.im/webp-social/moments-46a028270f3c2da92e7056c17c1d9e16.webp(
SVM'de, talimatlar 4 bölümden oluşur, program ID'si, program talimatı ve okuma/yazma verileri için hesap listesini içerir. Mevcut hesabın okuma mı yoksa yazma mı durumunda olduğunu ve durum değişikliği yapılacak işlemlerin çakışıp çakışmadığını belirleyerek, hesapların işlem talimatlarında durumu çakışmayanları paralelleştirmeye izin verilebilir; her talimat Program ID'si ile temsil edilir. Bu da Solana'nın doğrulayıcılarından beklenen yüksek standartların nedenlerinden biridir, çünkü doğrulayıcıların GPU/CPU'larının SIMD) tek talimat çoklu veri( ve AVX ileri vektör uzantı yeteneklerini desteklemesi gerekmektedir.
Ekosistem Gelişimi
Solana ekosisteminin mevcut gelişim sürecinde, giderek daha fazla pratik faydaya yöneliyor, örneğin Blinks, Actions ve hatta Solana Mobile gibi, ve resmi destekli uygulama geliştirme yönü de altyapının sonsuz bir iç çatışmasına değil, tüketici uygulamalarına daha fazla yöneliyor. Solana'nın mevcut performansı yeterli olduğu için, 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 ile ön planda. Altyapı uygulamaları taşıyamadığında, tüketici uygulamaları inşa edilemez hale geliyor; bu da altyapıya yapılan yatırımların fazla, ancak uygulama yatırımlarının yetersiz olduğu dengesiz bir duruma yol açıyor.
) DeFi
Solana'daki DeFi protokollerinde, Kamino### birinci Lending(, Marginfi) Lending + Restaking(, SoLayer) Restaking(, Meteora gibi birçok henüz token çıkarmamış proje bulunmaktadır. Solana'nın dayanışma ekosistem havası nedeniyle, genellikle bir projenin token çıkış tarihini, diğer projeler gözlemleyerek mümkün olduğunca kaçınmaya çalışır, böylece yeterli piyasa dikkatini çekebilir.
Şu anda DEX alanında rekabet çok yoğun, lider de Raydium, Orca'dan şu anki bazı DEX'lere kadar birçok kez değişti.
Dikkate değer olan, DEX'in işlemlerinin yaklaşık %50'sinin MEV botları tarafından yapıldığıdır.
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.
19 Likes
Reward
19
6
Share
Comment
0/400
staking_gramps
· 07-16 11:08
sol'un performansı gerçekten harika
View OriginalReply0
0xSunnyDay
· 07-15 15:18
Kesinti Kralı hala performanstan bahsediyor mu?
View OriginalReply0
CoconutWaterBoy
· 07-14 03:35
Yine sol mu üflüyorsun?
View OriginalReply0
SandwichTrader
· 07-14 03:21
Tıkanmaktansa açmak daha iyi, düşününce sistem çöküyor.
Solana teknik mimari analizi ve ekosistem gelişim durumu
Solana Teknoloji Mimarisi ve Ekosistem Gelişimi Üzerine İnceleme
Solana, yüksek performanslı bir blok zinciri platformudur ve yüksek işlem hacmi ile düşük gecikmeyi 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 Değişim 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 yürütme hızını artırır. Bunlar, Solana'nın yüksek performanslı mimari tasarımını sağlasa da, ağ kesintileri, işlem başarısızlıkları, MEV sorunları, durum büyümesinin aşırı hızı ve merkeziyetçilik 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 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 daha zayıf olan ekosistem, girişimciler ve geliştiriciler için zengin 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 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 kolaylığını artırmayı hedefliyor.
Solana, blok zinciri endüstrisinde yüksek işlem hacmi ve düşük işlem maliyeti ile önemli bir pazar payı elde etmesine rağmen, diğer yeni ortaya çıkan kamu blok zincirlerinden gelen yoğun rekabetle karşı karşıya kalmaktadır. EVM ekosistemindeki potansiyel bir rakip olan Base'in zincir üzerindeki aktif adres sayısı hızla artmakta, aynı zamanda Solana'nın DeFi alanındaki toplam kilitli değer (TVL) tarihi bir zirveye ulaşmış olsa da, Base gibi rakipler de hızla pazar payı kapmaktadır ve Base ekosisteminin finansman miktarı da Q2 çeyreğinde Solana'yı ilk kez geçmiştir.
Solana, teknik ve piyasa kabulü açısından belli bir başarı elde etmesine rağmen, Base gibi rakiplerinin getirdiği zorluklarla başa çıkmak için sürekli yenilik ve gelişim gerekmektedir. Ö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 gibi konularda, Solana'nın teknik mimarisini ve ağ protokollerini sürekli olarak optimize etmesi gerekmektedir, böylece blockchain endüstrisindeki 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ınır. Her bir bileşenin nasıl çalıştığı, yüksek performans hedefinin mimari tasarımda nasıl gerçekleştirildiği ve bu mimari tasarımın getirdiği dezavantajlar ve türettiği sorunlar.
POH algoritması
POH(Tarih Kanıtı), küresel zamanı belirleyen bir tekniktir; bu bir konsensüs mekanizması değildir, daha çok işlem 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 tane ve benzersiz bir çıktı Y vardır, bu nedenle X'teki herhangi bir değişiklik Y'yi tamamen farklı hale getirir.
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 belirlenmiş olur. Örneğin, işlemleri bir blokta paketlediğimizde, ilgili sha256 hash değerini ürettiğimizde, o bloktaki işlemler belirlenmiş olur, herhangi bir değişiklik hash değerinin değişmesine neden olur. Daha sonra bu blok hash, bir sonraki sha256 fonksiyonunun X kısmı olarak kullanılacak, ardından bir sonraki blok hash'i eklenecek, böylece hem önceki blok hem de sonraki blok belirlenmiş 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 şemasında, POH mekanizması altındaki işlem süreci açıklanmaktadır. Leader Rotation Schedule adlı bir döngü mekanizması altında, tüm zincir üzerindeki doğrulayıcılar arasında bir Leader düğümü oluşturulmaktadır. Bu Leader düğümü işlemleri toplar ve sıralı bir şekilde yürütür, POH dizisi oluşturur, ardından bir blok oluşturup diğer düğümlere yayar.
Bir Leader düğümünün tek noktada arıza vermesini önlemek için zaman sınırlaması getirilmiştir. Solana'da zaman birimleri epoch ile bölümlendirilir, her epoch 432.000 slot( 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 süresi içerisinde blok yayınlamak zorundadır)400ms(, 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 tarihi işlemleri tamamen kesinleştirir. Solana'nın temel zaman birimi Slot'tur, Leader düğümün bir slot içinde blok yayınlaması gerekir. Kullanıcılar, işlemleri RPC düğümü aracılığıyla Leader'a iletir, Leader düğüm işlemleri paketleyip sıralar ve ardından blok oluşturur, 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 aracılığıyla fikir birliğine varmalıdır; 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 somut mühendislik uygulamasıdır. Bu algoritma hala POH algoritmasıyla ilişkilidir. Bloklar üzerinde oy kullanırken, eğer doğrulayıcıların oyu kendisi bir işlemse, o zaman kullanıcı işlemleri ve doğrulayıcı işlemleriyle oluşan 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 doğrulanmasını sağlayan tarihi bir kanıt olarak kullanılabilir.
![Solana teknik mimarisini tekrar açıklamak: İkinci baharını mı yaşayacak?]###https://img-cdn.gateio.im/webp-social/moments-c210b4025cb64385890634a405838d05.webp(
Tower BFT algoritmasında, tüm doğrulayıcıların bu bloğa oy vermesi durumunda, 2/3'ten fazla doğrulayıcı onay oyu verirse, bu blok kesinleşebilir. Bu mekanizmanın avantajı, yalnızca hash dizisi üzerinde 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 seli kullanılır; bir doğrulayıcı bloğu aldığında, çevresindeki doğrulayıcılara gönderecektir. Bu, bir doğrulayıcının aynı bloğu birden fazla kez almasına neden olduğu için ağda büyük bir fazlalığa yol açar.
Solana'da, çok sayıda doğrulayıcı oylama işlemi ve Lider düğümü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üksek olmaktadır. Büyük blokların yayılması, ağa büyük bir yük getirebilir; Solana, büyük blokların yayılma sorununu çözmek için Turbine mekanizmasını kullanır.
) Turbine
Leader düğümü, blokları Sharding olarak adlandırılan bir süreçle shred alt bloklarına ayırır; bunların boyutu, MTU### maksimum iletim birimi olarak belirlenmiştir. Bir düğümden diğerine daha küçük birimlere bölmeden 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.
Blokları dört Data Shred'e bölerek, veri iletimi sırasında paket kaybı ve hasarını önlemek için dört paketi sekiz pakete kodlamak üzere Reed-Solomon kodlaması kullanılır. Bu çözüm, en fazla %50 paket kaybı toleransına sahiptir. Gerçek testlerde, Solana'nın paket kaybı oranı yaklaşık %15'tir, bu nedenle bu çözüm mevcut Solana mimarisiyle iyi bir uyum sağlamaktadır.
Veri iletiminde genellikle UDP/TCP protokollerinin kullanılması düşünülmektedir. Solana'nın kayıp paket oranına toleransı yüksek olduğundan, iletim için UDP protokolü tercih edilmiştir. Bunun dezavantajı, kayıp paket olduğunda yeniden iletim yapılmamasıdır, ancak avantajı daha hızlı iletim hızıdır. Aksine, TCP protokolü kayıp paket olduğunda yeniden birçok kez iletim yapar, bu da iletim hızını ve verimliliğini büyük ölçüde azaltır. Reed-Solomon teknolojisi ile bu sistem, Solana'nın verimliliğini önemli ölçüde artırabilir, gerçek ortamda verimlilik 9 kat artabilir.
![Solana teknik mimarisini yeniden keşfetmek: İkinci bahar mı geliyor?])https://img-cdn.gateio.im/webp-social/moments-224796bc8e080649730bb8736334abba.webp(
Turbine, verileri parçaladıktan sonra, çok katmanlı yayılma mekanizması kullanarak yayılır. Lider düğümü, her Slot'un sona ermesinden önce bir blok verisini rastgele bir blok doğrulayıcısına teslim eder. Ardından, bu doğrulayıcı bloğu Shred'lere ayırır ve hata düzeltme kodu oluşturur. Bu doğrulayıcı daha sonra Turbine yayılımını başlatır. Öncelikle kök düğüme yayılması gerekir, 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:
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ı ) 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.
Düğüm Grupları: Ardından, birinci katmandaki her doğrulayıcı, kendi birinci katmanını oluşturmak için kendi düğüm listesini de oluşturacaktır.
Kat oluşumu: Düğümleri listenin tepesinden 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 düğümler, katmanların belirlenmesi sırasında bir üst katmana çıkarak, tam shreds'leri önceden elde edebilirler. Bu durumda tam blokları geri yükleyebilirler. Daha alt katmandaki düğümler, iletim kaybı nedeniyle tam shreds elde etme olasılıkları düşer. Eğer bu shreds, tam parçalar oluşturmak için yeterli değilse, Leader'dan doğrudan yeniden iletim talep edilecektir. Bu durumda veri iletimi ağaç iç kısmına yönlenecektir ve ilk katmandaki düğümler çoktan tam blok onaylarını oluşturmuşlardır. Bu nedenle daha alt 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üğümlü mekanizmasına benzer. Blok yayılım sürecinde bazı öncelikli düğümler de bulunmaktadı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. Gereksiz olanı daha derin bir seviyeye itmek, Finality'nin gerçekleşimini önemli ölçüde hızlandırabilir ve verimliliği ve throughput'u maksimize edebilir. Çünkü aslında öncelikli birkaç katman, 2/3 düğümü temsil ediyorsa, sonraki düğümlerin oylaması 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 bir durum geçiş 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 işlem hacmini düşürebilir. Bu nedenle, SVM için Solana, işlem hızını artırmak amacıyla Sealevel paralel yürütme motorunu önermiştir.
![Solana teknik mimarisi yeniden açıklanıyor: İkinci bahar mı geliyor?]###https://img-cdn.gateio.im/webp-social/moments-46a028270f3c2da92e7056c17c1d9e16.webp(
SVM'de, talimatlar 4 bölümden oluşur, program ID'si, program talimatı ve okuma/yazma verileri için hesap listesini içerir. Mevcut hesabın okuma mı yoksa yazma mı durumunda olduğunu ve durum değişikliği yapılacak işlemlerin çakışıp çakışmadığını belirleyerek, hesapların işlem talimatlarında durumu çakışmayanları paralelleştirmeye izin verilebilir; her talimat Program ID'si ile temsil edilir. Bu da Solana'nın doğrulayıcılarından beklenen yüksek standartların nedenlerinden biridir, çünkü doğrulayıcıların GPU/CPU'larının SIMD) tek talimat çoklu veri( ve AVX ileri vektör uzantı yeteneklerini desteklemesi gerekmektedir.
Ekosistem Gelişimi
Solana ekosisteminin mevcut gelişim sürecinde, giderek daha fazla pratik faydaya yöneliyor, örneğin Blinks, Actions ve hatta Solana Mobile gibi, ve resmi destekli uygulama geliştirme yönü de altyapının sonsuz bir iç çatışmasına değil, tüketici uygulamalarına daha fazla yöneliyor. Solana'nın mevcut performansı yeterli olduğu için, 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 ile ön planda. Altyapı uygulamaları taşıyamadığında, tüketici uygulamaları inşa edilemez hale geliyor; bu da altyapıya yapılan yatırımların fazla, ancak uygulama yatırımlarının yetersiz olduğu dengesiz bir duruma yol açıyor.
) DeFi
Solana'daki DeFi protokollerinde, Kamino### birinci Lending(, Marginfi) Lending + Restaking(, SoLayer) Restaking(, Meteora gibi birçok henüz token çıkarmamış proje bulunmaktadır. Solana'nın dayanışma ekosistem havası nedeniyle, genellikle bir projenin token çıkış tarihini, diğer projeler gözlemleyerek mümkün olduğunca kaçınmaya çalışır, böylece yeterli piyasa dikkatini çekebilir.
Şu anda DEX alanında rekabet çok yoğun, lider de Raydium, Orca'dan şu anki bazı DEX'lere kadar birçok kez değişti.
Dikkate değer olan, DEX'in işlemlerinin yaklaşık %50'sinin MEV botları tarafından yapıldığıdır.