Solana işlem hızı ve değer yaratımının dengesi

Solana, hızlı işlem hızı ve yüksek işlem hacmi ile tanınır, ancak bu onun mükemmel bir seviyeye ulaştığı anlamına mı geliyor? Bu işlemleri dikkatlice incelediğimizde, ortaya çıkan önemli bir soru var: Bu işlemlerin hepsi gerçekten değer mi yaratıyor?

Aslında, Solana üzerindeki büyük işlem hacminin çoğu gerçek işlem talebinden kaynaklanmıyor. Önemli bir kısmı, milisaniye seviyesindeki bilgi farklarını kullanarak kâr elde eden yüksek frekanslı arbitrajcılardan geliyor. Bu sözde "zehirli traderlar", teknik avantajlarını kullanarak, piyasa yapıcıların emirlerini geri çekmeye hazır olduğu anda, kendi işlemlerinin öncelikli olarak paketlenmesi için Gas ücretlerini artırarak arbitraj yapıyor ve bu da piyasa yapıcıların zarar görmesine neden oluyor. Bu zararları telafi etmek için, piyasa yapıcılar alım satım farkını genişletmek zorunda kalıyor ve sonuçta bu ek maliyetler sıradan kullanıcılar tarafından üstleniliyor.

Solana her zaman merkeziyetsiz borsa vizyonunu gerçekleştirmek için zincir üzerinde bir emir defteri uygulama peşindeydi. Ancak, "zehirli traderlar"ın varlığı, bu hedefe ulaşmanın önündeki en büyük engel haline geldi. İşte Solana'nın şu anda karşılaştığı yeni zorluk: işlem hacmi, likiditeyle eş anlamlı değildir. Gerçekten sağlıklı bir pazar için gereken, daha fazla işlem değil, daha yüksek kaliteli işlemlerdir.

Zehirli işlemleri nasıl çıkarabiliriz ve likiditeyi daha iyi koruyabiliriz?

Mevcut sistemde, Solana'nın konsensüs mekanizması döngüsel müzayede kullandığı için, alım yapanlar aslında öncelik hakkına sahiptir, bu da kötü niyetli MEV (madenci tarafından çıkarılabilir değer) davranışlarının piyasa adilliğini etkilemesine neden olmaktadır.

Özellikle, Solana'nın konsensüs mekanizmasında, her zaman diliminde (Slot) yapılan işlemler ödenen öncelikli Gas ücretine göre sıralanır ve en yüksek teklifi veren işlemler öncelikli olarak gerçekleştirilir. Bu ihale mekanizması her 400 milisaniyede bir gerçekleşir. Bu süreçte, piyasa yapıcıları sürekli olarak teklifleri ayarlamak, iptal etmek ve yeninden listelemek zorundadırlar; bu, piyasa fiyatlarındaki değişikliklere uyum sağlamak içindir.

Ve yalnızca alım yapanlar, özellikle yüksek frekanslı arbitrajcılar, fiyat farklılıklarını sürekli izlerler ve bir fırsat tespit eder etmez hemen işlem yaparlar. İşlem tamamlanmadan önce piyasa yapıcının emir iptali gerçekleştirmesi için daha yüksek ücret ödeyerek işlemlerini güvence altına alabilirler ve bu durum piyasa yapıcıların sık sık zarar etmesine neden olur.

Sıralı order book merkeziyetsiz borsa (DEX) için ideal işlem sıralaması şunlardır: Fiyat dalgalanmaları ile birlikte, önce tüm iptal işlemleri gerçekleştirilir, sonra yeni emirler, en son olarak da işlemler yapılır. Ancak, Solana'nın mevcut konsensüs mekanizması mikro düzeyde bunu gerçekleştiremiyor.

Aynı sorun, oracle fiyatlandırma düzeyinde de mevcuttur. İdeal olarak, önce oracle fiyatlarının güncellenmesi, ardından bu fiyata bağlı işlemlerin gerçekleştirilmesi gerekir. Ancak mevcut 400 milisaniyelik aralık içinde, piyasa aşırı dalgalanmalar nedeniyle işlemler hâlâ önceki fiyat üzerinden gerçekleştirilebilir.

Kredi protokolleri için en iyi işlem sırası önce teminat eklemek, sonra tasfiye yapmaktır.

Bu nedenle, Solana'nın farklı protokollerin kendi ihtiyaçlarına göre işlemleri sıralamasına izin veren bir mekanizmaya ihtiyacı vardır. Bu, Solana'nın sürekli olarak vurguladığı Uygulama Kontrollü İcra (Application-Controlled Execution, ACE) kavramıdır.

Bu sorunları çözmek için Solana, BAM (Blok Montaj Pazarı) çözümünü önerdi.

BAM: Solana'nın Yeni Cevabı

BAM, Solana'nın uygulama katmanı ile ana ağı arasında bir sıralama katmanı inşa etti, bu katman ön işleme katmanı olarak da adlandırılabilir. Bu, güvenilir yürütme ortamları (TEE'ler) kullanarak bir gizlilik kum havuzu oluşturur ve bu ortamda önceden belirlenmiş kurallara veya ilk gelen ilk hizmet (FIFO) ilkesine göre işlemleri sıralar.

Bu yenilik, order book, perpetual kontrat borsası ve karanlık havuz gibi protokollere daha iyi hizmet vermeyi amaçlamaktadır.

Solana Geleneksel İşlem İşleme ve BAM Modelinin Karşılaştırması

BAM'ın Solana uygulamaları ve ana ağı arasında nasıl bir sıralama katmanı inşa ettiğini daha iyi anlamak için, geleneksel Solana işlem sürecini ve BAM'ın benimsenmesinin ardından oluşan süreci karşılaştırabiliriz:

Geleneksel Solana işlem süreci:

1. Kullanıcı cüzdanında işlemi onaylar
2. İşlem RPC düğümüne gönderilir
3. RPC, işlemi mevcut dönemin Solana ana ağ Lider düğümüne gönderir.
4. Lider, işlem havuzundaki işlemleri toplar, sıralar, bloklara paketler ve yayınlar.
5. Diğer düğümler oylama yapar

BAM sonrası işlem süreci:

1. Kullanıcı cüzdanında işlemi onaylar
2. İşlem RPC düğümüne gönderildi
3. İşlemler BAM ağına yönlendirilir ve TEE ortamında sıralanır. Bu süre zarfında, düğümler ek işlemler eklemek için eklentiler aracılığıyla (örneğin, oracle fiyatlarını güncellemek) ekleyebilir ve ardından kanıt oluşturabilir.
4. İşlem veri paketi Solana ana ağ Lider düğümüne gönderildi.
5. Lider, işlem toplarken BAM veri paketini içerir, blok haline getirir ve yayınlar.
6. Diğer düğümler oylama yapar

Dikkate değer bir nokta, BAM'ın Solana ana ağının konsensüs süreci ile çelişmediği, aksine isteğe bağlı bir özellik olarak sunulduğudur. BAM, doğrudan Solana ana ağında çalışmaz, bunun yerine "off-chain" olarak işlem sıralamasını önceden tamamlar, işlemleri paketler ve ardından Solana ana ağına gönderir.

BAM'ın işlem sıralama modeli

BAM üç çalışma modunu destekler:

1. Solana varsayılan modu
2. Block-Engine Modu: Mevcut Jito'nun MEV çözümü, çekirdek olarak açık artırma mekanizmasıdır.
3. BAM Modu: Doğrulayıcılar, ilk giren ilk çıkar (FIFO) ilkesine sıkı bir şekilde göre sıralanır.

BAM modunun temel özellikleri şunlardır:

1. Güvenilir Çalıştırma Ortamları (TEEs): İşlemleri sıralamak için TEEs kullanarak gizlilik ortamı oluşturmak, adilliği sağlamak.

2. Eklenti Sistemi: Eklenti sistemi aracılığıyla, BAM uygulamaların özel işlem sıralama mantığı oluşturmasına izin verir. Bu özel sıralama, düğümlerin keyfine göre sıralaması yerine önceden belirlenmiş kurallara dayanmaktadır. Eklenti sisteminin, TEE ortamının güvenlik garantilerini korurken karmaşık işlem sıralamaları gerçekleştirmesi planlanmaktadır. Şu anda bu sistem hala erken geliştirme aşamasındadır.

BAM'ın Gerçek Uygulamaları

BAM'ın gerçek uygulamaları şunlardır:

1. Kredi Teminat Koruması: Kredi sözleşmeleri için, iflas riski tespit edildiğinde, öncelikle ek teminat işlemleri gerçekleştirilir, ardından iflas kontrolü yapılır.

2. Atomik düzeyde ticaret kombinasyonu: DEX için, önce oracle fiyatını güncelleyin, ardından bu fiyata dayanan ticareti gerçekleştirin. Sözleşme DEX için, ilgili türevleri aynı zaman diliminde de hesaplayabilirsiniz.

3. Fiyat dalgalanması koruması: DEX için, olağanüstü büyük emirleri tespit etmek, bunları küçük işlemlere ayırarak aşamalı olarak gerçekleştirmek, piyasaya yeterli tepki süresi tanımak ve zincirleme tasfiye veya arbitraj nedeniyle ölüm sarmalını önlemek.

4. Piyasa yapıcı koruması: Ani olaylar meydana geldiğinde, milisaniyeler içinde emir iptali, oracle fiyat güncellemesi, piyasa yapıcı yeniden emir verme gibi işlemleri gerçekleştirebilme, kötü niyetli arbitrajdan kaçınma ve fiyat farkını azaltma.

BAM'ın dağıtımıyla birlikte, Solana'nın işlem deneyiminin önemli ölçüde iyileşmesi bekleniyor ve bu da ana ağ uygulamalarının deneyimini merkezi borsa deneyimine daha da yakınlaştıracak.

Genel olarak, BAM, Solana'nın işlem işleme sürecine doğrulanabilirlik, gizlilik koruma ve programlanabilirlik getirdi. Bu, geliştiricilerin merkezi limit emir defteri, sürekli sözleşme borsası, karanlık havuz ve sıralama kontrolü, belirleyici yürütme ve gizlilik koruma gerektiren diğer finansal altyapılar inşa etmelerini sağladı ve böylece Solana ekosisteminin yenilikçi gelişimini teşvik etti.