Solana yeterince hızlı ve hacim yeterince büyük. Peki gerçekten "yeterince" mi?
Bu işlemleri incelediğimizde, sürekli bir soru var: Bu işlemler gerçekten değer mi yaratıyor?
Solana'nın büyük işlem hacmi, gerçek işlem talebinden değil, milisaniye düzeyindeki bilgi farkını kullanarak kar elde eden yüksek frekanslı arbitrajcılar tarafından gelmektedir. Bu "zehirli işlemciler" (Toxic-takers) teknik avantajlarını kullanarak, piyasa yapıcıların (Maker) emirlerini geri çekmeye yakınken Gas'i artırarak kendi işlemlerinin önce paketlenmesini sağlamakta ve arbitraj gerçekleştirerek piyasa yapıcıların zarar etmesine neden olmaktadır. Zararları telafi etmek için piyasa yapıcılar, alım-satım fiyat farkını genişletmek zorunda kalmaktadır.
Sonunda, sıradan kullanıcılar bunun bedelini ödüyor. Solana her zaman CEX'in yerini alacak bir on-chain emir defteri gerçekleştirme hayaline sahipti. Ancak bu durumda, "toksik traderlar" hayali gerçekleştirmek için engel haline geliyor. İşte Solana'nın karşılaştığı yeni zorluk: hacim ≠ likidite. Gerçekten sağlıklı bir piyasa, daha fazla işlem değil, daha iyi işlemler gerektirir.
Zararlı işlemleri nasıl çıkarabiliriz ve likiditeyi daha iyi koruyabiliriz?
Mevcut sistemde, alıcılar (Takers), Solana'nın konsensüs dönemsel açık artırma mekanizması nedeniyle gerçek bir önceliğe sahiptir, bu da kötü niyetli MEV'nin piyasa adaletini etkilemesine neden olur.
Nasıl anlamalıyız?
Solana'nın mevcut konsensüsünde, her zaman dilimi Slot içinde, işlemler ödenen öncelikli Gas ücretlerine göre sıralanır; kim daha yüksek teklif verirse, işlemi öncelikli olarak gerçekleştirilir. Bu açık artırma periyodik olarak, her 400 milisaniyede bir Slot'ta gerçekleşir.
Bu süreçte, piyasa yapıcıların tekliflerini sık sık ayarlamaları, sipariş iptali ve yeniden sipariş vermeleri gerekir. Piyasa fiyatı değiştiğinde hemen güncellenmesi gerekir.
Ve alım yapanlar (Taker), özellikle yüksek frekanslı arbitrajcılar, fiyat farklarını izler ve fırsat bulduklarında hemen işlem yaparlar. Bu nedenle, arbitrajcılar, emir iptal edilmeden önce işlem yapmak için daha yüksek ücretler ödeyebilirler. Bu durum, piyasa yapıcıların sık sık "nişan alındığı" ve zarar etmek zorunda kaldığı anlamına gelir.
Sipariş defteri DEX için ideal sıralama, fiyat dalgalanmaları ile birlikte önce tüm iptalleri gerçekleştirmek, sonra yeni bekleyen emirleri işlemek ve nihayetinde işlemleri tamamlamaktır. Bu, şu anda Solana konsensüsünün mikro düzeyde başaramadığı bir şeydir.
Ve oracle fiyat katmanında da durum aynıdır, ideal durum, önce oracle fiyatlarının güncellenmesi, ardından bu fiyata dayanan işlemlerin gerçekleştirilmesidir. Ancak mevcut 400 milisaniyelik aralıkta, piyasa aşırı dalgalanmalar nedeniyle, işlemler hala önceki fiyatla gerçekleştirilebilir.
Kredilendirme sözleşmeleri için, teminatı önce tamamlamak, sonra tasfiye işlemi gerçekleştirmek en iyisidir.
Bu nedenle, farklı protokollerin ihtiyaçlara göre işlemleri sıralayabilmesi için bir yol olması en iyisidir; bu, Solana'nın sürekli vurguladığı ACE uygulama kontrolü yürütmesi (Application-Controlled Execution) ile ilgilidir.
BAM (Block Assembly Marketplace, Blok Montaj Pazarı) tam olarak Solana'nın cevabıdır.
BAM, Solana ağı üzerindeki ana ağ ile uygulama arasında bir sıralama katmanı veya ön işleme katmanı inşa etti.
Güvenilir yürütme ortamlarını (Trusted Execution Environments, TEEs) kullanarak gizlilik sandıkları oluşturun, sandık içinde önceden belirlenmiş sıralama kurallarına veya FIFO (ilk giren, ilk çıkar) göre işlem sıralaması yapın.
Sipariş defterlerini (CLOB'lar), sürekli sözleşme borsalarını (Perpetual Exchanges) ve karanlık havuz (Dark Pools) protokollerini daha iyi hizmet vermek.
Solana genellikle hacim paketleme ile BAM modunu karşılaştırır
BAM'ın Solana uygulamaları ile ana ağ arasında bir sıralama katmanı oluşturduğunu nasıl anlamalıyız? Öncelikle görsel bir karşılaştırma yapalım.
Solana normal işlem süreci,
1）Kullanıcı cüzdanında işlemi onaylar,
2）RPC düğümüne gönderilen işlem,
RPC, mevcut Slot döneminde, Solana ana ağının Lider düğümüne gönderilir,
4）Leader, işlem havuzundaki işlemleri toplar, sıralar, blok haline paketler ve yayınlar,
5）Diğer düğümlerin oylaması.
Eğer bir uygulama BAM'ı entegre ederse, işlem süreci aşağıdaki gibidir,
1）Kullanıcı cüzdanında işlemi onaylar,
RPC düğümüne işlem gönderildi,
İşlemler BAM ağına aktarılır ve TEE gizliliği içinde sıralanır. Bu süreçte, düğümler ek işlemler eklemek için eklentiler aracılığıyla, örneğin oracle fiyatlarını güncellemek gibi, ardından kanıt oluşturur,
4）İşlem veri paketi Solana ana ağ Lider düğümüne gönderildi,
5）Leader işlem toplarken, BAM veri paketini toplar, ardından blok haline getirip yayınlar,
Diğer düğümlerin oylaması.
Yani, aslında BAM, mevcut Solana ana ağ konsensüs süreciyle çelişmiyor, aksine bir "seçenek" olarak hizmet ediyor. BAM, doğrudan Solana ana ağında çalışmıyor, sözde "çalışma dışı" bir yöntemle, işlem sıralamasını önceden tamamlayarak, işlemleri paketleyip, ardından Solana ana ağına gönderiyor.
BAM hacim sıralama modu
BAM üç çalışma modunu destekler,
1）Solana varsayılan modu；
Block-Engine modu; mevcut Jito'nun MEV çözümü, çekirdek olarak bir teklif mekanizmasına sahiptir.
BAM modu, doğrulayıcılar FIFO (ilk gelen ilk hizmet) sıralamasına sıkı bir şekilde uyar.
BAM modelinin temelinde aşağıdaki noktalar bulunmaktadır,
Güvenilir İcra Ortamları TEEs: Gizlilik ve Adalet Güvenilir İcra Ortamları TEEs kullanarak, gizlilik ortamı oluşturmak ve işlemleri sıralamak. Gizliliğin bir diğer yüzü adalet olarak adlandırılır.
2）Eklenti Sistemi Plugin: Karmaşık Sıralama Eklenti sistemi aracılığıyla, BAM uygulamaların özel işlem sıralama mantığını oluşturmasına izin verir. Ancak bu özel sıralama, düğümlerin istedikleri gibi sıralama yapmaları anlamına gelmez, önceden belirlenmiş kurallara göre sıralama yapılır.
Eklenti, karmaşık işlem sıralamasını gerçekleştirmeyi planlıyor ve TEE ortamının güvenlik garantisini koruyor. Şu anda erken geliştirme aşamasında.
Yukarıda bahsedilenler gibi,
Sipariş defteri DEX için ideal sıralama, fiyat dalgalandıkça önce tüm iptalleri gerçekleştirmek, sonra yeni emirleri vermek ve en son olarak işlemleri gerçekleştirmektir. Bu, şu anda Solana konsensüsünün mikro düzeyde başaramadığı bir şeydir.
Ve oracle fiyat katmanında da durum aynıdır. İdeal senaryo, önce oracle fiyatının güncellenmesi, ardından bu fiyata bağlı işlemlerin gerçekleştirilmesidir. Ancak mevcut 400 milisaniyelik gecikme süresinde, piyasa aşırı dalgalanma nedeniyle, işlemler hâlâ önceki fiyattan gerçekleştirilebilir.
Kredilendirme sözleşmeleri için en iyisi önce teminatı tamamlamak, ardından tasfiye işlemine geçmektir. Bu aslında ACE uygulama kontrol yürütme işlevini gerçekleştirir.
Peki, BAM tam olarak neyi başardı?
Örneğin,
1）Kredi Teminat Koruması
Kredi protokolleri için, tasfiye riski tespit edildiğinde, öncelikle ek teminat işlemlerini gerçekleştirin, ardından tasfiye kontrolünü yapın.
2）Atomik düzeyde işlem kombinasyonu
DEX için önce oracle fiyatını güncelle, bu fiyata bağlı işlemleri gerçekleştir. Eğer bu bir sözleşme DEX ise, ilgili türev ürünlerin de hesaplanması mümkündür. Yukarıdaki işlemlerin hepsi aynı zaman diliminde tamamlanır.
3）Fiyat dalgalanması koruması
DEX için anormal büyük emirleri tespit et, büyük emirleri küçük parçalara ayır, aşamalı olarak gerçekleştir, piyasaya tepki verme süresi tanı, zincirleme likidasyon veya arbitrajın ölüm sarmalı yaratmasını önle.
4）Piyasa yapıcı koruması
Acelesi olan bir durum meydana geldi, milisaniyeler içinde emir iptali, oracle fiyatı güncellendi, piyasa yapıcılar yeniden emir girdi. Kötü niyetli arbitrajdan kaçınmak için, fiyat farkını azaltın.
BAM aslında Temmuz sonunda piyasaya sürülecekti.
Ayrıca, BAM'ın dağıtımı ile Solana işlem deneyimi önemli ölçüde iyileşecektir. BAM, Solana ana ağ uygulamalarının deneyimini CEX'e daha yakın hale getirecektir.
Özetle,
BAM, Solana'nın işlem işleme sürecine doğrulama, gizlilik koruma ve programlanabilirlik getirerek geliştiricilerin merkezi limit emir defterleri (CLOB'lar), sürekli sözleşme borsaları (Perpetual Exchanges), karanlık havuzlar (Dark Pools) ve diğer sıralama kontrolü, belirlenebilir yürütme ve gizlilik koruması gerektiren finansal altyapılar inşa etmelerini sağlıyor ve böylece Solana ekosisteminin yenilikçi gelişimini teşvik ediyor.
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.
Solana BAM Blok Montaj Pazarını Yorumlamak: Hız Artık Tek Amaç Olmadığında
Solana yeterince hızlı ve hacim yeterince büyük. Peki gerçekten "yeterince" mi?
Bu işlemleri incelediğimizde, sürekli bir soru var: Bu işlemler gerçekten değer mi yaratıyor?
Solana'nın büyük işlem hacmi, gerçek işlem talebinden değil, milisaniye düzeyindeki bilgi farkını kullanarak kar elde eden yüksek frekanslı arbitrajcılar tarafından gelmektedir. Bu "zehirli işlemciler" (Toxic-takers) teknik avantajlarını kullanarak, piyasa yapıcıların (Maker) emirlerini geri çekmeye yakınken Gas'i artırarak kendi işlemlerinin önce paketlenmesini sağlamakta ve arbitraj gerçekleştirerek piyasa yapıcıların zarar etmesine neden olmaktadır. Zararları telafi etmek için piyasa yapıcılar, alım-satım fiyat farkını genişletmek zorunda kalmaktadır.
Sonunda, sıradan kullanıcılar bunun bedelini ödüyor. Solana her zaman CEX'in yerini alacak bir on-chain emir defteri gerçekleştirme hayaline sahipti. Ancak bu durumda, "toksik traderlar" hayali gerçekleştirmek için engel haline geliyor. İşte Solana'nın karşılaştığı yeni zorluk: hacim ≠ likidite. Gerçekten sağlıklı bir piyasa, daha fazla işlem değil, daha iyi işlemler gerektirir.
Zararlı işlemleri nasıl çıkarabiliriz ve likiditeyi daha iyi koruyabiliriz?
Mevcut sistemde, alıcılar (Takers), Solana'nın konsensüs dönemsel açık artırma mekanizması nedeniyle gerçek bir önceliğe sahiptir, bu da kötü niyetli MEV'nin piyasa adaletini etkilemesine neden olur.
Nasıl anlamalıyız?
Solana'nın mevcut konsensüsünde, her zaman dilimi Slot içinde, işlemler ödenen öncelikli Gas ücretlerine göre sıralanır; kim daha yüksek teklif verirse, işlemi öncelikli olarak gerçekleştirilir. Bu açık artırma periyodik olarak, her 400 milisaniyede bir Slot'ta gerçekleşir.
Bu süreçte, piyasa yapıcıların tekliflerini sık sık ayarlamaları, sipariş iptali ve yeniden sipariş vermeleri gerekir. Piyasa fiyatı değiştiğinde hemen güncellenmesi gerekir.
Ve alım yapanlar (Taker), özellikle yüksek frekanslı arbitrajcılar, fiyat farklarını izler ve fırsat bulduklarında hemen işlem yaparlar. Bu nedenle, arbitrajcılar, emir iptal edilmeden önce işlem yapmak için daha yüksek ücretler ödeyebilirler. Bu durum, piyasa yapıcıların sık sık "nişan alındığı" ve zarar etmek zorunda kaldığı anlamına gelir.
Sipariş defteri DEX için ideal sıralama, fiyat dalgalanmaları ile birlikte önce tüm iptalleri gerçekleştirmek, sonra yeni bekleyen emirleri işlemek ve nihayetinde işlemleri tamamlamaktır. Bu, şu anda Solana konsensüsünün mikro düzeyde başaramadığı bir şeydir.
Ve oracle fiyat katmanında da durum aynıdır, ideal durum, önce oracle fiyatlarının güncellenmesi, ardından bu fiyata dayanan işlemlerin gerçekleştirilmesidir. Ancak mevcut 400 milisaniyelik aralıkta, piyasa aşırı dalgalanmalar nedeniyle, işlemler hala önceki fiyatla gerçekleştirilebilir.
Kredilendirme sözleşmeleri için, teminatı önce tamamlamak, sonra tasfiye işlemi gerçekleştirmek en iyisidir.
Bu nedenle, farklı protokollerin ihtiyaçlara göre işlemleri sıralayabilmesi için bir yol olması en iyisidir; bu, Solana'nın sürekli vurguladığı ACE uygulama kontrolü yürütmesi (Application-Controlled Execution) ile ilgilidir.
BAM (Block Assembly Marketplace, Blok Montaj Pazarı) tam olarak Solana'nın cevabıdır.
BAM, Solana ağı üzerindeki ana ağ ile uygulama arasında bir sıralama katmanı veya ön işleme katmanı inşa etti.
Güvenilir yürütme ortamlarını (Trusted Execution Environments, TEEs) kullanarak gizlilik sandıkları oluşturun, sandık içinde önceden belirlenmiş sıralama kurallarına veya FIFO (ilk giren, ilk çıkar) göre işlem sıralaması yapın.
Sipariş defterlerini (CLOB'lar), sürekli sözleşme borsalarını (Perpetual Exchanges) ve karanlık havuz (Dark Pools) protokollerini daha iyi hizmet vermek.
Solana genellikle hacim paketleme ile BAM modunu karşılaştırır
BAM'ın Solana uygulamaları ile ana ağ arasında bir sıralama katmanı oluşturduğunu nasıl anlamalıyız? Öncelikle görsel bir karşılaştırma yapalım.
Solana normal işlem süreci,
1）Kullanıcı cüzdanında işlemi onaylar,
2）RPC düğümüne gönderilen işlem,
4）Leader, işlem havuzundaki işlemleri toplar, sıralar, blok haline paketler ve yayınlar,
5）Diğer düğümlerin oylaması.
Eğer bir uygulama BAM'ı entegre ederse, işlem süreci aşağıdaki gibidir,
1）Kullanıcı cüzdanında işlemi onaylar,
RPC düğümüne işlem gönderildi,
İşlemler BAM ağına aktarılır ve TEE gizliliği içinde sıralanır. Bu süreçte, düğümler ek işlemler eklemek için eklentiler aracılığıyla, örneğin oracle fiyatlarını güncellemek gibi, ardından kanıt oluşturur,
4）İşlem veri paketi Solana ana ağ Lider düğümüne gönderildi,
5）Leader işlem toplarken, BAM veri paketini toplar, ardından blok haline getirip yayınlar,
Yani, aslında BAM, mevcut Solana ana ağ konsensüs süreciyle çelişmiyor, aksine bir "seçenek" olarak hizmet ediyor. BAM, doğrudan Solana ana ağında çalışmıyor, sözde "çalışma dışı" bir yöntemle, işlem sıralamasını önceden tamamlayarak, işlemleri paketleyip, ardından Solana ana ağına gönderiyor.
BAM hacim sıralama modu
BAM üç çalışma modunu destekler,
1）Solana varsayılan modu；
Block-Engine modu; mevcut Jito'nun MEV çözümü, çekirdek olarak bir teklif mekanizmasına sahiptir.
BAM modu, doğrulayıcılar FIFO (ilk gelen ilk hizmet) sıralamasına sıkı bir şekilde uyar.
BAM modelinin temelinde aşağıdaki noktalar bulunmaktadır,
2）Eklenti Sistemi Plugin: Karmaşık Sıralama Eklenti sistemi aracılığıyla, BAM uygulamaların özel işlem sıralama mantığını oluşturmasına izin verir. Ancak bu özel sıralama, düğümlerin istedikleri gibi sıralama yapmaları anlamına gelmez, önceden belirlenmiş kurallara göre sıralama yapılır.
Eklenti, karmaşık işlem sıralamasını gerçekleştirmeyi planlıyor ve TEE ortamının güvenlik garantisini koruyor. Şu anda erken geliştirme aşamasında.
Yukarıda bahsedilenler gibi,
Sipariş defteri DEX için ideal sıralama, fiyat dalgalandıkça önce tüm iptalleri gerçekleştirmek, sonra yeni emirleri vermek ve en son olarak işlemleri gerçekleştirmektir. Bu, şu anda Solana konsensüsünün mikro düzeyde başaramadığı bir şeydir.
Ve oracle fiyat katmanında da durum aynıdır. İdeal senaryo, önce oracle fiyatının güncellenmesi, ardından bu fiyata bağlı işlemlerin gerçekleştirilmesidir. Ancak mevcut 400 milisaniyelik gecikme süresinde, piyasa aşırı dalgalanma nedeniyle, işlemler hâlâ önceki fiyattan gerçekleştirilebilir.
Kredilendirme sözleşmeleri için en iyisi önce teminatı tamamlamak, ardından tasfiye işlemine geçmektir. Bu aslında ACE uygulama kontrol yürütme işlevini gerçekleştirir.
Peki, BAM tam olarak neyi başardı?
Örneğin,
1）Kredi Teminat Koruması
Kredi protokolleri için, tasfiye riski tespit edildiğinde, öncelikle ek teminat işlemlerini gerçekleştirin, ardından tasfiye kontrolünü yapın.
2）Atomik düzeyde işlem kombinasyonu
DEX için önce oracle fiyatını güncelle, bu fiyata bağlı işlemleri gerçekleştir. Eğer bu bir sözleşme DEX ise, ilgili türev ürünlerin de hesaplanması mümkündür. Yukarıdaki işlemlerin hepsi aynı zaman diliminde tamamlanır.
3）Fiyat dalgalanması koruması
DEX için anormal büyük emirleri tespit et, büyük emirleri küçük parçalara ayır, aşamalı olarak gerçekleştir, piyasaya tepki verme süresi tanı, zincirleme likidasyon veya arbitrajın ölüm sarmalı yaratmasını önle.
4）Piyasa yapıcı koruması
Acelesi olan bir durum meydana geldi, milisaniyeler içinde emir iptali, oracle fiyatı güncellendi, piyasa yapıcılar yeniden emir girdi. Kötü niyetli arbitrajdan kaçınmak için, fiyat farkını azaltın.
BAM aslında Temmuz sonunda piyasaya sürülecekti.
Ayrıca, BAM'ın dağıtımı ile Solana işlem deneyimi önemli ölçüde iyileşecektir. BAM, Solana ana ağ uygulamalarının deneyimini CEX'e daha yakın hale getirecektir.
Özetle,
BAM, Solana'nın işlem işleme sürecine doğrulama, gizlilik koruma ve programlanabilirlik getirerek geliştiricilerin merkezi limit emir defterleri (CLOB'lar), sürekli sözleşme borsaları (Perpetual Exchanges), karanlık havuzlar (Dark Pools) ve diğer sıralama kontrolü, belirlenebilir yürütme ve gizlilik koruması gerektiren finansal altyapılar inşa etmelerini sağlıyor ve böylece Solana ekosisteminin yenilikçi gelişimini teşvik ediyor.
Yukarıda.