Solana teknolojik mimarisini yeniden incelemek: İkinci baharını mı yaşayacak?

Solana, yüksek performanslı bir blok zinciri platformudur ve yüksek throughput ve düşük gecikme sağlamak için benzersiz bir teknoloji mimarisi kullanmaktadır. Temel teknolojileri arasında, işlem sırasını ve küresel saati sağlamak için Proof of History (POH) algoritması, blok oluşturma hızını artırmak için Leader Rotation Schedule 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 performans sağladığı mimari tasarımlardır, ancak aynı zamanda ağ kesintileri, işlem başarısızlıkları, MEV sorunları, durumun çok hızlı büyümesi ve merkeziyetçilik sorunları gibi bazı problemleri de beraberinde getirmiştir. Bu makalede, bu mekanizmanın getirdiği sorunları da vurguladık.

Solana ekosistemi hızla gelişiyor, ilk altı ayda tüm veri göstergeleri hızla ilerledi, özellikle DeFi, altyapı, GameFi/NFT, DePin/AI ve tüketici uygulamaları alanlarında. Solana'nın yüksek TPS'si ve tüketici uygulamalarına yönelik stratejisi ile zayıf marka etkisi olan ekosistemi, 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'lar ile, 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 zinciri ve mobil teknolojiyi birleştirerek kullanıcılara yenilikçi bir fitness ve sosyal deneyim sunuyor. Mevcut birçok tüketici uygulaması hala en iyi iş modelleri ve pazar konumlarını keşfetmesine rağmen, Solana'nın sunduğu teknoloji platformu 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, 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 blockchain sektöründe önemli bir pazar payı elde etmesine rağmen, diğer yeni nesil halka açık blok zincirlerinden yoğun bir rekabetle karşı karşıya. EVM ekosistemindeki potansiyel rakibi Base'in zincir üzerindeki aktif adres sayısı hızla artarken, Solana'nın DeFi alanındaki toplam kilitli değeri (TVL) tarihi bir zirveye ulaşmasına rağmen, Base gibi rakipler de hızlı bir şekilde pazar payını kapmakta. Base ekosisteminin finansman miktarı da Q2 çeyreğinde Solana'yı ilk kez geride bıraktı.

Solana, teknik ve pazar 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 iyileştirme yapması gerekmektedir. Özellikle ağ 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 endüstrisindeki liderliğini korumak için teknik mimarisini ve ağ protokollerini 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ınır. Bileşenlerinin nasıl çalıştığını, yüksek performans hedefini mimari tasarımda nasıl gerçekleştirdiğini 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ğil, bir işlem sırasını belirleyen bir algoritmadır. POH teknolojisi, temel kriptografi SHA256 teknolojisinden gelmektedir. SHA256 genellikle verilerin bütünlüğünü hesaplamak için kullanılır; belirli bir X girişi verildiğinde, yalnızca benzersiz bir Y çıktısı vardır, bu nedenle X'teki herhangi bir değişiklik Y'yi tamamen farklı kılacaktır.

Solana'nın POH dizisinde, sha256 algoritması uygulanarak dizinin bütünlüğü sağlanabilir ve böylece içindeki işlemlerin bütünlüğü de belirlenir. Bir örnek vermek gerekirse, eğer işlemleri bir blok içinde paketleyip ilgili sha256 hash değerini oluşturursak, o zaman o 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 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 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ış mimarisinde, POH mekanizması altında işlem sürecini tanımlamaktadır. Leader Rotation Schedule olarak adlandırılan bir döngü mekanizması altında, tüm zincir doğrulayıcıları arasında bir Leader düğümü üretilir. Bu Leader düğümü işlemleri toplar ve sıralı bir şekilde gerçekleştirir, POH dizisi oluşturur ve ardından bir blok oluşturarak diğer düğümlere yayar.

Tek noktada arıza oluşumunu önlemek için Lider düğümünde zaman sınırlaması getirilmiştir. Solana'da zaman birimi epoch ile bölümlenir, her epoch 432.000 slot( zaman dilimini içerir, her slot 400ms sürer. Her bir slotta, döngü sistemi her slot içinde bir Lider düğüm atar, Lider düğüm, belirlenen slot süresi içinde blok)400ms( yayınlamak zorundadır, aksi takdirde bu slot atlanır ve bir sonraki slotun Lider düğümü yeniden seçilir.

Genel olarak, Leader düğümü POH mekanizmasını kullanarak geçmiş işlemleri kesinleştirir. Solana'nın temel zaman birimi Slot'tur, Leader düğümünün bir slot içinde blok yayınlaması gerekir. Kullanıcılar işlemleri RPC düğümleri aracılığıyla Leader'a iletir, Leader 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, blok içindeki işlemler ve sıralama üzerinde uzlaşmak için bir mekanizma kullanmak zorundadır, 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 mühendislik uygulamasıdır. Bu algoritma hala POH algoritması ile ilgilidir. 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şlemleri tarafından oluşturulan 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 oy detayları benzersiz bir şekilde doğrulanabilir.

![Tekrar Çözüm Solana Teknoloji Mimarisi: İkinci Baharını mı Yaşayacak?]###https://img-cdn.gateio.im/webp-social/moments-d55d3cfbc13036ed0d5747abb521cc1a.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 onaylanabilir. 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; yani bir doğrulayıcı bloğu aldığında, etrafındaki doğrulayıcılara gönderir. Bu, bir doğrulayıcının yalnızca bir kez aldığı aynı bloğun ağda çok fazla gereksizlik yaratmasına neden olur.

Solana'da, çok sayıda doğrulayıcı oylama işlemi ve Lider düğümünün merkezileşmesinden kaynaklanan yüksek verimlilik ile 400 ms'lik Slot süresi nedeniyle, toplam blok boyutu ve blok oluşturma sıklığı oldukça yüksektir. Büyük bloklar yayılırken, ağa büyük bir baskı yapabilir. 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 adlı alt bloklara böler. Bu alt blokların boyutu, MTU### maksimum iletim birimi olarak belirlenmiştir ve daha küçük birimlere bölünmesine gerek kalmadan bir düğümden diğerine gönderilebilecek maksimum veri miktarı ( birimindedir. 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'e bölerek, veri iletimi sırasında paket kaybı ve bozulmayı önlemek için Reed-solomon kodlaması kullanılarak dört paket sekiz pakete kodlanır. Bu sistem en fazla %50 paket kaybı toleransına sahiptir. 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.

![Solana teknik mimarisi yeniden gün yüzüne çıkacak mı?])https://img-cdn.gateio.im/webp-social/moments-e9bc35d0c790496c59c20979e5af1491.webp(

Veri iletimi sırasında genellikle UDP/TCP protokollerinin kullanılması düşünülür. Solana'nın kayıp oranına karşı yüksek toleransı nedeniyle, veri iletimi için UDP protokolü kullanılmıştır. Bunun dezavantajı, kayıp durumunda yeniden iletim yapılmamasıdır, ancak avantajı daha hızlı iletim hızıdır. Aksine, TCP protokolü kayıp durumunda birden fazla yeniden 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; gerçek ortamda, verimlilik 9 kat artabilir.

Turbine verileri parçalayarak, çok katmanlı bir yayılma mekanizması kullanarak yayılmayı gerçekleştirir. Lider düğüm, her Slot'un bitiminden önce bir blok verecek herhangi bir blok doğrulayıcısına blok gönderecektir. Ardından, bu doğrulayıcı blokları Shred'lere böler ve hata düzeltme kodları üretir. Bu doğrulayıcı daha sonra Turbine yayılımını başlatır. İlk olarak kök düğüme yayılmalıdır, ardından bu kök düğüm hangi doğrulayıcıların hangi katmanda olduğunu belirleyecektir. Süreç aşağıda gösterilmiştir:

1. 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ı ) yani stake edilen SOL miktarı ( üzerinden sıralar. Daha yüksek ağırlığa sahip olanlar birinci katmanda yer alır, böylece devam eder.

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

3. Kat oluşumu: Listenin üst kısmından düğümleri katlara ayırarak, derinlik ve genişlik değerlerini belirleyerek tüm ağacın genel şeklini belirlemek mümkündür. Bu parametre, shreds'in yayılma hızını etkiler.

![Solana teknik mimarisinin yeniden açıklaması: İkinci baharını mı迎 geliyor?])https://img-cdn.gateio.im/webp-social/moments-9fd8693259e2864d6978d2b4e8ef2e85.webp(

Hak sahibi olan düğümler, katmanların belirlenmesi sırasında daha üst bir seviyede yer alır, böylece tam shreds'leri önceden elde edebilirler. Bu durumda, tam blokları geri yükleyebilirler. Ancak daha sonraki katmanlardaki düğümler, iletim kaybı nedeniyle tam shreds alma olasılıkları azalır. Eğer bu shreds, tam parçaları oluşturmak için yeterli değilse, Lider'den doğrudan yeniden iletim talep edilecektir. Bu durumda veri iletimi ağaç iç kısmına doğru yönelir ve ilk katmanın düğümleri çoktan tam blok onayı oluşturmuşlardır. Arkadaki 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üğüm mekanizmasına benzer. Blok yayılım sürecinde bazı öncelikli düğümler de vardır; bu düğümler öncelikle shreds parçalarını alarak tamamlayıcı blokları oluşturur ve oylama konsensüsüne ulaşır. Redundansı daha derin bir seviyeye itmek, Finality sürecini önemli ölçüde hızlandırabilir ve verimliliği maksimuma çıkarabilir. Çünkü aslında ilk birkaç katman 2/3 düğümü temsil ediyorsa, sonraki düğümlerin oylaması önemsiz hale gelir.

) SVM

Solana, saniyede binlerce işlemi işleyebilme yeteneğine 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 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 önermiş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 mı yoksa yazma mı durumunda olduğunu belirleyerek ve durum değişikliği yapılacak işlemlerin çakışıp çakışmadığını kontrol ederek, hesapların işlem talimatlarında duruma çakışmayanların paralel olmasına izin verilebilir, her bir talimat Program ID'si ile temsil edilir. Bu, Solana'nın doğrulayıcıları için yüksek gereksinimlerin olmasının nedenlerinden biridir, çünkü doğrulayıcıların GPU/CPU'sunun SIMD### tek talimat çoklu veri( ve AVX gelişmiş vektör genişletme yeteneklerini desteklemesi gerekmektedir.

![Solana teknik mimarisini yeniden inceleme: İkinci baharını mı bekliyor?])https://img-cdn.gateio.im/webp-social/moments-636ac72327705b9f93e62e394355436f.webp(

Ekosistem Geliştirme