Neden Solana'da Prop AMM'ler dolup taşarken, EVM'de hâlâ boş?

Orijinal Başlık: Monad Ana Ağı Lansmanından Sonra İzlenmesi Gereken dApp'ler

Orijinal yazar: Optimus

Kaynak metin:

Alıntı: Mars Finans

Prop AMM'ler, Solana'nın toplam işlem hacminin %40'ını hızla ele geçirdi. Peki, neden EVM'de henüz görünmüyorlar?

Profesyonel Otonom Piyasa Yapıcılar (Proprietary AMMs, kısaca Prop AMMs), Solana DeFi ekosisteminde hızla hakim bir güç haline geliyor ve şu anda ana işlem çiftlerinde %40'tan fazla işlem hacmine katkıda bulunuyorlar. Profesyonel piyasa yapıcılar tarafından işletilen bu özel likidite alanları, derin likidite ve daha rekabetçi fiyatlandırma sunabiliyor; bunun temel nedeni, piyasa yapıcıların “eski fiyat teklifleri” (stale quotes) kullanılarak önceden işlem yapma (front-running) arbitrajı riskiyi önemli ölçüde azaltmalarıdır.

Ancak, bunların başarısı neredeyse tamamen Solana ile sınırlıdır. Base veya Optimism gibi hızlı ve düşük maliyetli Layer 2 ağlarında bile, EVM ekosisteminde Prop AMM'nin izleri pek görünmemektedir. Neden EVM üzerinde kök salmadılar?

Bu makale üç ana konuyu ele alıyor: Prop AMM nedir, EVM zincirlerinde hangi teknik ve ekonomik engellerle karşılaşıyorlar ve nihayetinde EVM DeFi öncüsü olabilecek umut verici yeni yapılar.

Prop AMM nedir?

Prop AMM, geleneksel AMM'nin aksine, likiditeyi ve fiyatlandırmayı pasif bir şekilde sağlayan kitle yerine, tek bir profesyonel piyasa yapıcı tarafından aktif olarak yönetilen bir otomatik piyasa yapıcıdır.

Geleneksel AMM'ler (örneğin, Uniswap v2) genellikle fiyatı belirlemek için x * y = k formülünü kullanır; burada x ve y, havuzdaki iki varlığın miktarını temsil eder ve k sabit bir değerdir. Ancak Prop AMM'de, fiyatlandırma formülü sabit değildir; bunun yerine sıklıkla güncellenir (genellikle her saniye birden fazla kez). Çoğu Prop AMM'nin iç mekanizmaları “kara kutu” olduğundan, dışarıdan hangi kesin algoritmaların kullanıldığı bilinmemektedir. Ancak, Sui zincirindeki Obric'in Prop AMM akıllı sözleşme kodu açıktır (bu buluş için @markoggwp'ye teşekkürler), sabit değeri k, iç değişkenler mult_x, mult_y ve concentration'a bağlıdır. Aşağıdaki resim, piyasa yapıcıların bu değişkenleri nasıl sürekli güncellediğini göstermektedir.

Açıklığa kavuşturulması gereken bir nokta var: Obric fiyatlandırma eğrisinin solundaki formül basit x*y'den daha karmaşık, ancak Prop AMM'yi anlamanın anahtarı - her zaman değişken bir sabit k'ya eşit olmasıdır ve piyasa yapıcılar bu k'yı fiyat eğrisini ayarlamak için sürekli günceller.

Gözden geçirme: AMM fiyatı nasıl belirler?

Bu makalede, “fiyat eğrisi” kavramına birçok kez atıfta bulunacağız. Fiyat eğrisi, kullanıcıların AMM ile işlem yaparken ödemesi gereken fiyatı belirler ve aynı zamanda Prop AMM'de piyasa yapıcıların sürekli güncellediği bir bileşendir. Bunu daha iyi anlamak için, önce geleneksel AMM'nin fiyatlandırma yöntemini gözden geçirebiliriz.

Uniswap v2 üzerindeki WETH-USDC havuzunu örnek alalım (ücret olmadığını varsayalım). Fiyat, x * y = k formülü ile pasif olarak belirlenir. Havuzda 100 WETH ve 400.000 USDC olduğunu varsayalım, bu durumda eğri noktası x = 100, y = 400.000 olur ve başlangıç fiyatı 400.000 / 100 = 4.000 USDC/WETH olarak belirlenir. Böylece sabit k = 100 * 400.000 = 40.000.000 olarak bulunur.

Eğer bir trader 1 WETH satın almak istiyorsa, havuzdaki USDC'yi eklemesi gerekiyor, böylece havuzdaki WETH 99'a düşüyor. Sabit çarpan k'yı korumak için, yeni nokta (x, y) hala eğri üzerinde yer almalıdır, bu nedenle y 40.000.000 / 99 ≈ 404.040,40 olmalıdır. Yani, bu trader 1 WETH için yaklaşık 4.040,40 USDC ödüyor, bu da başlangıç fiyatından biraz daha yüksek. Bu olaya “fiyat kayması” (slippage) denir. x*y=k'nın “fiyat eğrisi” olarak adlandırılmasının nedeni budur: Herhangi bir işlem yapılabilir fiyat bu eğrinin üzerinde olmalıdır.

Neden piyasa yapıcılar AMM tasarımını merkezi limit defteri (CLOB) yerine seçiyor?

Piyasa yapıcıların AMM tasarımını kullanmak istemelerinin nedenlerini açıklayalım. Kendinizi bir zincir üzerindeki merkezi limit emir defterinde (CLOB) teklif veren bir piyasa yapıcı olarak hayal edin. Teklifinizi güncellemek istiyorsanız, binlerce limit emrini iptal edip yenisiyle değiştirmeniz gerekir. Eğer N tane emriniz varsa, güncelleme maliyeti O(N) seviyesinde bir işlem olur, bu da zincir üzerinde hem yavaş hem de pahalıdır.

Peki ya tüm teklifleri tek bir matematiksel eğri ile ifade edebilirseniz? Bu durumda, yalnızca bu eğrinin tanımını yapan birkaç parametreyi güncellemeniz yeterli olacaktır, böylece O(N) işlemini O(1) sabit karmaşıklığına dönüştürebilirsiniz.

"Fiyat eğrisi"nin farklı geçerli fiyat aralıklarına nasıl karşılık geldiğini görsel olarak göstermek için, Solana tabanlı bir Prop AMM olan Ellipsis Labs tarafından oluşturulan SolFi'ye bakabiliriz. Spesifik fiyat eğrisi bilinmemekte ve gizlenmiş olmasına rağmen, Ghostlabs, belirli bir Solana slotu (blok zaman dilimi) içinde, farklı miktarlardaki SOL'un USDC'ye dönüştürüldüğünde geçerli fiyatı gösteren bir grafik çizmiştir. Her bir çizgi, farklı bir WSOL/USDC havuzunu temsil eder ve birden fazla fiyat seviyesinin aynı anda var olabileceğini gösterir. Piyasa yapıcılar fiyat eğrisini güncelledikçe, bu geçerli fiyat grafiği de farklı slotlar arasında değişecektir.

Buradaki ana nokta, yalnızca birkaç fiyat eğrisi parametresini güncelleyerek, piyasa yapıcıların etkili fiyat dağılımını her zaman değiştirebilmesidir; bunun için N adet siparişi tek tek değiştirmelerine gerek yoktur. İşte bu, Prop AMM'nin temel değer önerisidir - piyasa yapıcıların daha yüksek sermaye ve hesaplama verimliliği ile dinamik ve derin bir likidite sunmalarını sağlar.

Neden Solana'nın mimarisi Prop AMM için çok uygundur?

Prop AMM, “aktif yönetim” sistemi olduğu anlamına gelir, bu da iki temel koşul gerektirdiği anlamına gelir:

  1. Düşük güncelleme maliyeti (cheap updates)

  2. Öncelikli icra hakkı (priority execution)

Solana'da, bu ikisi birbirini tamamlar: düşük maliyetli güncellemeler genellikle güncellemelerin yürütme önceliği alacağı anlamına gelir.

Piyasa yapıcılarının bu iki noktaya ihtiyaç duyması neden? Öncelikle, stok değişiklikleri veya varlık endeksi fiyatlarının (örneğin merkezi borsa fiyatları) dalgalanmaları doğrultusunda, blok zinciri çalışma hızına göre sürekli olarak fiyat eğrilerini güncelleyebilirler. Solana gibi yüksek frekanslı bir zincirde, güncelleme maliyetleri çok yüksekse, yüksek frekanslı ayarlamaların gerçekleştirilmesi zor olacaktır.

İkincisi, eğer piyasa yapıcılar güncellemelerini blokların en üstüne yerleştiremezse, eski teklifleri arbitrajcılar tarafından “kapılmış” olur ve bu kaçınılmaz bir zarara yol açar. Bu iki özellik eksikse, piyasa yapıcılar verimli bir şekilde işlem yapamaz ve kullanıcılar daha kötü işlem fiyatları alır.

Solana üzerindeki Prop AMM HumidiFi örneğinde, @SliceAnalytics verilerine göre bu piyasa yapıcı her saniye 74 kez fiyat güncellemesi yapıyor.

EVM'den gelen oyuncular şunları sorabilir: “Solana'nın slotu (slot) yaklaşık 400ms, Prop AMM tek bir slot içinde fiyatı nasıl birden fazla güncelleyebilir?”

Cevap, Solana'nın sürekli mimarisindedir; bu, temelde EVM'nin ayrık blok modelinden farklıdır.

· EVM: İşlemler genellikle tam bir blok önerildikten ve nihai olarak onaylandıktan sonra sırayla yürütülür. Bu, ara güncellemelerin bir sonraki bloğa kadar geçerli olmayacağı anlamına gelir.

· Solana: Lider doğrulama düğümleri tam blok beklemez, bunun yerine işlemleri küçük veri paketlerine (“shred” olarak adlandırılır) bölerek ağa sürekli yayınlar. Bir slot içinde birden fazla işlem olabilir, ancak shred #1 的价格更新影响 swap #1, shred #2 的价格更新影响 swap #2.

Not: Flashblocks, Solana'nın shred'ine benzer. Anza Labs'tan @Ashwinningg'nin CBER konferansındaki paylaşımına göre, her 400ms'lik slotun üst sınırı 32.000 shred'dir, bu da her milisaniyede 80 shred'e denk gelir. 200ms'lik Flashblocks'un piyasa yapıcılarının ihtiyaçlarını karşılamak için yeterince hızlı olup olmayacağı, Solana'nın sürekli mimarisi ile karşılaştırıldığında hala açık bir sorudur.

O halde, Solana üzerindeki güncellemeler neden bu kadar ucuz? Ve bu nasıl öncelikli yürütmeye yol açıyor?

İlk olarak, Solana üzerindeki Prop AMM'nin uygulaması bir kara kutu olmasına rağmen, Solana programlarını CU'yu optimize etme biçiminde yazmak için Pinocchio gibi kütüphaneler mevcuttur. Helius'un blogu bu konuda harika bir tanıtım yapıyor, bu kütüphane aracılığıyla, Solana programının CU tüketimi yaklaşık 4000 CU'dan yaklaşık 100 CU'ya düşürülebilir.

Şimdi ikinci bölüme bakalım. Daha yüksek bir seviyede, Solana, EVM'ye benzer şekilde, Fee / Compute Units oranı en yüksek olan işlemleri önceliklendirerek sıralama yapar (Compute Units, EVM'nin Gas'ına benzer).

· Özellikle Jito kullanıldığında, formül Jito İpucu / Hesaplama Birimleri'dir.

· Kullanılmıyor: Öncelik = ( öncelik ücreti + temel ücret ) / (1 + CU üst sınırı + imza CU + yazma kilidi CU )

Prop AMM güncellemesi ile Jupiter Swap'ın Compute Units'ini karşılaştırdığınızda, güncellemenin son derece ucuz olduğu ve oranının 1:1000'e ulaştığı görülmektedir.

Prop AMM Güncellemesi: Basit eğriler güncelleniyor, çok ucuz. Wintermute'un güncellemeleri 109 CU'ya kadar düşüyor, toplam maliyet sadece 0.000007506 SOL

Jupiter Swap: Jupiter yönlendirmesi ile yapılan takas yaklaşık ~100,000 CU'ya ulaşır, toplam ücret 0.000005 SOL'dir.

Bu büyük fark nedeniyle, piyasa yapıcıları güncellenen işlemler için yalnızca çok küçük bir ücret ödeyerek, değişimden çok daha yüksek bir Fee/CU oranı elde edebilirler. Böylece güncellemelerin blokların en üstünde gerçekleştirilmesini sağlayarak kendilerini arbitraj saldırılarından korumuş olurlar.

Neden Prop AMM henüz EVM üzerinde uygulanmadı?

Varsayalım ki Prop AMM'nin güncellemesi, işlem çiftinin fiyat eğrisini belirleyen değişkenlerin yazılmasını içeriyor. Solana üzerindeki Prop AMM kodu bir “kara kutu” olduğu için, piyasa yapıcıları stratejilerini gizli tutmak istiyor, ancak bu varsayımla Obric'in Sui üzerinde Prop AMM'yi nasıl uyguladığını anlayabiliriz: İşlem çiftinin teklifinin belirleyici değişkenleri update fonksiyonu aracılığıyla akıllı sözleşmeye yazılıyor.

Teşekkürler @markoggwp keşfettiğin için!

Bu varsayımı kullanarak, EVM mimarisinde önemli engeller bulunduğunu ve Solana'nın Prop AMM modelinin EVM üzerinde uygulanamaz olduğunu keşfettik.

Bir göz atarsak, OP-Stack Layer 2 blok zincirlerinde (Base ve Unichain gibi) işlemler her Gas öncelik ücreti sırasına göre sıralanır (Solana'nın Fee / CU sıralamasına benzer).

EVM'de yazma işleminin Gas tüketimi çok yüksektir. Solana'nın güncellemeleri ile karşılaştırıldığında, EVM'de SSTORE opcode'u ile bir değer yazmanın maliyeti şaşırtıcıdır:

· SSTORE(0 → 0 olmayan):~22,100 gaz

· SSTORE (0 dışı → 0 dışı): ~5,000 gaz

· Tipik AMM takası:~200,000–300,000 gaz

Not: EVM üzerindeki Gas, Solana üzerindeki hesaplama birimlerine (CU) benzer. Yukarıdaki SSTORE gaz rakamı, her işlemin yalnızca bir yazma (soğuk yazma) işlemi olduğunu varsayıyor; bu makul bir varsayımdır çünkü genellikle bir işlemde birden fazla güncelleme gönderilmez.

Güncellemeler hala takaslardan daha ucuz olsa da, gas kullanımı oranı sadece yaklaşık 10 kat (güncellemeler birden fazla SSTORE içerebilir) iken, Solana'da bu oran yaklaşık 1000 kat.

Bu, aynı Solana Prop AMM modelinin EVM üzerinde daha yüksek risk taşıdığına dair iki sonuç ortaya koyuyor:

  1. Yüksek Gas tüketimi, öncelik ücretlerinin güncellenmesini zorlaştırır; daha düşük öncelik ücretleri yüksek ücret/Gas oranını gerçekleştiremez. Güncellemelerin öncelikli olarak yürütülmesini ve blokta en üstte yer almasını sağlamak için daha yüksek öncelik ücretleri gereklidir, bu da maliyeti artırır.

  2. EVM üzerinde arbitraj riski daha yüksektir, EVM üzerinde güncellenen Gas ile değişim Gas oranı yalnızca 1:10 iken, Solana üzerinde 1:1000'dir. Bu, arbitrajcıların öncelik ücretini 10 kat artırarak piyasa yapıcıların güncellemelerini önceden yapmalarını sağlayabileceği anlamına gelirken, Solana üzerinde 1000 kat artırmaları gerekmektedir. Bu daha düşük oranda, arbitrajcıların fiyat güncellemelerini önceden işlem yaparak fırsatçı fiyatlamalar elde etme olasılığı daha yüksektir çünkü maliyetler düşüktür.

Bazı yenilikler (örneğin, geçici depolama için EIP-1153'ün TSTORE'u) yaklaşık 100 gazlık yazım sağlar, ancak bu depolama geçicidir ve yalnızca tek bir işlemde geçerlidir, fiyat güncellemelerinin sonraki takas işlemlerinde kullanılmak üzere kalıcı hale getirilmesine olanak tanımaz (örneğin, tüm blok süresince).

EVM'ye Prop AMM nasıl entegre edilir?

Cevaplamadan önce, “neden yapmak” sorusunu yanıtlayalım: Kullanıcılar her zaman daha iyi ticaret teklifleri almak ister, bu da ticaretin daha kârlı olduğu anlamına gelir. Ethereum ve Layer 2 Prop AMM, kullanıcılara yalnızca Solana veya merkezi borsalarda elde edilebilecek rekabetçi teklifleri sunabilir.

Prop AMM'nin EVM'de uygulanabilir olabilmesi için, Solana'daki başarısının nedenlerinden birine göz atıyoruz:

· Blok tepe güncelleme koruması: Solana'da, Prop AMM güncellemeleri blok tepesinde yer alır ve piyasa yapıcıları ön alım işlemlerinden korur. Güncellemenin tepe noktada yer almasının nedeni, hesaplama birimi tüketiminin son derece düşük olmasıdır; düşük ücretlerle bile yüksek ücret/CU oranı sağlanabilir, özellikle takas işlemleriyle karşılaştırıldığında.

Peki, blok tepe noktasındaki Prop AMM güncellemesini Layer 2 EVM blok zincirine nasıl getirebiliriz? İki yöntem var: ya yazma maliyetlerini düşürmek ya da Prop AMM güncellemeleri için öncelik kanalları oluşturmak.

EVM'nin durum büyüme sorunu nedeniyle, yazma maliyetlerini düşürmek bu yöntem pek uygulanabilir değil, çünkü ucuz SSTORE çöp durum saldırılarına yol açabilir.

Prop AMM güncellemeleri için öncelikli bir yol oluşturmayı öneriyoruz. Bu uygulanabilir bir çözümdür ve bu makalenin odak noktasıdır.

Uniswap ekibinden @MarkToda, küresel depolama akıllı sözleşmeleri + özel blok oluşturucu stratejisi aracılığıyla yeni bir yöntem önerdi:

Çalışma prensibi şöyledir:

· Küresel Depolama Sözleşmesi: Genel anahtar-değer depolama olarak basit akıllı sözleşmelerin dağıtımı. Piyasa yapıcıları, bu sözleşmeye fiyat eğrisi parametrelerini yazar (örneğin set(ETH-USDC_CONCENTRATION, 4000)).

· Yapılandırıcı stratejisi: Bu, zincir dışı kritik bir bileşendir. Blok yapılandırıcısı, küresel depolama sözleşmesine gönderilen işlemleri tanır, blokun ilk %5-10'luk Gaz'ını bu güncelleme işlemlerine tahsis eder ve ücret önceliğine göre sıralar, böylece isabetsiz işlemleri engeller.

Lütfen dikkat: İşlemler, küresel depolama adresine doğrudan gönderilmelidir, aksi takdirde blokun en üstünde bulunması garanti edilemez.

Özelleştirilmiş blok oluşturma algoritması örneği için rblib'e bakabilirsiniz.

Prop AMM entegrasyonu: Piyasa yapıcıların Prop AMM sözleşmesi, takas sırasında fiyat eğrisi verilerini küresel depolama sözleşmesinden okuyarak alıntı sağlar.

Bu mimari, iki sorunu ustaca çözüyor:

  1. Koruma: Yapıcı strateji, işlemden önce blok içindeki tüm fiyat güncellemelerinin gerçekleştirilmesini sağlamak için “hızlı geçiş” oluşturur, ön alım riskini ortadan kaldırır.

  2. Maliyet etkinliği: Piyasa yapıcılar artık tüm DeFi kullanıcılarıyla yüksek Gas Fiyatı ile blok başı işlemler yapmak için rekabet etmek zorunda değiller, sadece yerel ücret piyasasında güncellenmiş işlem ayrımı için üst blokta rekabet etmeleri yeterli, bu da maliyetleri önemli ölçüde düşürüyor.

Kullanıcı işlemleri, piyasa yapıcıların aynı blokta başlangıçta güncellediği fiyat eğrisi üzerinden gerçekleştirilecektir; bu, tekliflerin tazeliğini ve güvenliğini sağlar. Bu model, EVM üzerinde Solana'daki düşük maliyetli, yüksek öncelikli güncellemelerin ortamını yeniden üretmekte ve Prop AMM'nin EVM üzerinde yolunu açmaktadır.

Ancak, bu modelin bazı dezavantajları da var, bu sorunları makalenin sonunda tartışmak üzere bırakıyorum.

Sonuç

Prop AMM'nin uygulanabilirliği, öncelikli olarak ön alım ticaretini önlemek için ucuz ve öncelikli bir şekilde çözülmesi gereken temel ekonomik sorunlara bağlıdır.

Standart EVM mimarisinin bu tür işlemleri yüksek maliyetli ve riskli hale getirmesine rağmen, yeni tasarımlar bu sorunu çözmek için farklı yaklaşımlar sunmaktadır. Zincir üzerindeki küresel depolama akıllı sözleşmeleri ile zincir dışı kurucu stratejilerini birleştiren yeni tasarım, blokların tepe noktasında güncellemelerin gerçekleştirilmesini garanti eden özel “hızlı geçitler” oluşturabilirken, yerel ve kontrollü bir ücret piyasası da oluşturmaktadır. Bu, Prop AMM'nin EVM üzerinde uygulanabilir olmasını sağlamakla kalmayıp, aynı zamanda blok tepe noktasında kehanet güncellemelerine bağımlı tüm EVM DeFi için devrim niteliğinde olabilir.

Açık uçlu soru

· EVM üzerinde 200ms Flashblock hızı, Solana'nın sürekli mimarisi ile rekabet etmek için yeterli mi?

· Solana üzerindeki çoğu AMM trafiği, AMM entegrasyonunu kolaylaştıran SDK sağlayan tek bir agregat olan Jupiter'den gelmektedir. Ancak Layer 2 EVM üzerinde trafik, birden fazla agregat arasında dağılmış durumda ve ortak bir SDK yok. Bu, Prop AMM için bir zorluk oluşturur mu?

· Prop AMM, Solana'da güncellenmesi yalnızca yaklaşık 100 CU tüketiyor, bu nasıl bir gerçekleştirme mekanizması?

· Hızlı geçiş modeli yalnızca blok üstünün güncellenmesini garanti eder. Eğer bir Flashblock içinde birden fazla takas varsa, piyasa yapıcı bu takaslar arasında fiyatı nasıl günceller?

· Yul veya Huff gibi diller kullanarak, Solana'daki Pinocchio optimizasyon planı gibi optimize edilmiş EVM programları yazmak mümkün mü?

· Prop AMM ile RFQ'nun karşılaştırması nasıl?

· N blokunda piyasa yapıcıların kullanıcılara kaliteli teklifler sunarak kandırmalarını ve ardından N+1 blokunda kötü teklifler ile güncellemelerini nasıl önleyebiliriz? Jupiter bunu nasıl engelliyor?

· Jupiter Ultra V3'ün Ultra Signaling özelliği, Prop AMM'nin zararlı ve zararsız akışları ayırt etmesine olanak tanır ve daha sıkı fiyat teklifleri sunar. Bu tür toplayıcı özelliklerinin Prop AMM'nin EVM üzerindeki önemi nedir?

SOL1.1%
USDC0.01%
ETH1.97%
View Original
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.
  • Reward
  • Comment
  • Repost
  • Share
Comment
0/400
No comments
  • Pin
Trade Crypto Anywhere Anytime
qrCode
Scan to download Gate App
Community
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)