Solana Prop AMM'lerle doluyken EVM neden boş kalıyor?

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

Orijinal Makale Yazarı: @0xOptimus

Orijinal Makale Çevirisi: Dingdang, Odaily Planet Daily

Özel AMM'ler, Solana'nın toplam işlem hacminin %40'ını hızla ele geçirdi. Peki neden henüz EVM'de yer almadılar?

Özel Otomatik Piyasa Yapıcıları (Prop AMM'ler), Solana DeFi ekosisteminde hızla baskın güç haline geliyor ve şu anda ana paritelerdeki işlem hacminin %40'ından fazlasını oluşturuyor. Profesyonel piyasa yapıcıları tarafından işletilen bu likidite platformları, derin likidite ve daha rekabetçi fiyatlandırma sağlayabilir. Bunun temel nedeni, piyasa yapıcılarının "geçici fiyat teklifleri" nedeniyle istismar edilerek önden işlem arbitrajı yapma riskini önemli ölçüde azaltmalarıdır.

Resim Kaynağı: dune.com

Ancak başarıları neredeyse tamamen Solana ile sınırlı kaldı. Base veya Optimism gibi hızlı ve düşük maliyetli 2. Katman ağlarında bile, Prop AMM'lerin EVM ekosisteminde varlığı nadirdir. Peki neden EVM'de kök salmadılar?

Bu makale temel olarak üç konuyu ele almaktadır: Prop AMM'lerin ne olduğu, EVM zincirinde karşılaştıkları teknik ve ekonomik engeller ve onları sonunda EVM DeFi'nin ön saflarına taşıyabilecek umut verici yeni mimariler.

Prop AMM'ler Nelerdir?

Özel AMM'ler, geleneksel AMM'lerde olduğu gibi fonların halk tarafından pasif olarak sağlanması yerine, tek bir profesyonel piyasa yapıcısının likiditeyi ve fiyatlandırmayı aktif olarak yönettiği bir tür otomatik piyasa yapıcıdır.

Geleneksel AMM'ler (Uniswap v2 gibi), fiyatı belirlemek için genellikle x * y = k formülünü kullanır; burada x ve y, havuzdaki iki varlığın miktarını, k ise sabit bir değeri temsil eder. Prop AMM'lerde ise fiyatlandırma formülü sabit olmayıp sık sık güncellenir (genellikle saniyede birkaç kez). Çoğu Prop AMM'nin iç mekaniği bir "kara kutu" olarak kabul edildiğinden, dış dünya kullandıkları algoritmayı tam olarak bilmez. Ancak, Obric'in Sui zincirindeki Prop AMM akıllı sözleşme kodu herkese açıktır (@markoggwp'nin keşfi sayesinde). Burada değişmez k, mult_x, mult_y ve concentration dahili değişkenlerine bağlıdır. Aşağıdaki görsel, piyasa yapıcının bu değişkenleri nasıl sürekli olarak güncellediğini göstermektedir.

Açıklığa kavuşturulması gereken bir nokta, Obric fiyatlandırma eğrisinin sol tarafındaki formülün basit bir x*y formülünden daha karmaşık olmasıdır. Ancak, Prop AMM'yi anlamanın anahtarı, her zaman değişken bir k'ye eşit olması ve likidite sağlayıcılarının fiyat eğrisini ayarlamak için bu k'yi sürekli olarak güncellemesidir.

İnceleme: AMM Fiyatları Nasıl Belirler?

Bu makalede, "fiyat eğrisi" kavramından birkaç kez bahsedeceğiz. Fiyat eğrisi, kullanıcıların bir AMM kullanarak işlem yaparken ödemeleri gereken fiyatı belirler ve likidite sağlayıcılarının Prop AMM'de sürekli olarak güncellediği kısımdır. Bunu daha iyi anlamak için, önce geleneksel bir AMM'nin fiyatlandırma mekanizmasını inceleyebiliriz.

Uniswap v2'deki WETH-USDC havuzunu örnek alalım (ücretsiz olduğunu varsayarak). Fiyat, x * y = k formülüyle pasif olarak belirlenir. Havuzda 100 WETH ve 400.000 USDC olduğunu varsayarsak, mevcut eğri noktası x = 100, y = 400.000'dir ve bu da 400.000 / 100 = 4.000 USDC/WETH başlangıç fiyatına karşılık gelir. Bu da k = 100 * 400.000 = 40.000.000 sabitini verir.

Bir yatırımcı 1 WETH satın almak isterse, havuza USDC eklemesi ve havuzdaki WETH miktarını 99'a düşürmesi gerekir. Sabit ürün k değerini korumak için, yeni nokta (x, y) eğri üzerinde kalmalıdır, bu nedenle y 40.000.000 / 99 ≈ 404.040,40 olmalıdır. Bu, yatırımcının 1 WETH için başlangıç fiyatından biraz daha yüksek olan yaklaşık 4.040,40 USDC ödediği anlamına gelir. Bu olguya "fiyat kayması" denir. Bu nedenle x*y=k "fiyat eğrisi" olarak adlandırılır: alınıp satılabilen herhangi bir fiyat bu eğri üzerinde olmalıdır.

Likidite Sağlayıcıları Neden Merkezi Emir Defteri (CLOB) Yerine AMM Tasarımını Seçiyor?

Likidite sağlayıcılarının likidite sağlamak için neden AMM tasarımını kullanmak isteyebileceğini açıklayalım. Zincir içi Merkezi Limit Emir Defteri'nde (CLOB) fiyat teklifi veren bir piyasa yapıcı olduğunuzu düşünün. Fiyat teklifinizi güncellemek isterseniz, binlerce limit emrini iptal edip değiştirmeniz gerekir. N emriniz varsa, güncelleme maliyeti zincir içi yavaş ve maliyetli olan bir O(N) işlemidir.

Peki ya tüm teklifleri matematiksel bir eğriyle temsil edebilseydiniz? Bu eğriyi tanımlayan birkaç temel parametreyi güncelleyerek, bir O(N) işlemini sabit bir O(1) karmaşıklığa dönüştürebilirsiniz.

"Fiyat Eğrisi"nin farklı efektif 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 başvurabiliriz. Spesifik fiyat eğrisi bilinmemekle ve gizli kalmakla birlikte, Ghostlabs belirli bir Solana slotu (blok zaman aralığı) içinde farklı miktarlarda SOL'u USDC ile değiştirdiğinizde efektif fiyatı gösteren bir grafik oluşturmuştur. Her çizgi farklı bir WSOL/USDC havuzunu temsil eder ve bu da birden fazla fiyat katmanının bir arada bulunabileceğini gösterir. Likidite sağlayıcısı fiyat eğrisini güncelledikçe, bu efektif fiyat grafiği de farklı slotlar arasında değişecektir.

Resim Kaynağı: GitHub

Buradaki anahtar nokta, likidite sağlayıcılarının yalnızca birkaç fiyat eğrisi parametresini güncelleyerek, her N emrini ayrı ayrı değiştirmek zorunda kalmadan, efektif fiyat dağılımını istedikleri zaman dinamik olarak değiştirebilmeleridir. Prop AMM'nin temel değer önerisi de tam olarak budur: likidite sağlayıcılarının daha yüksek sermaye ve hesaplama verimliliğiyle dinamik ve derin likidite sunmalarını sağlar.

Solana'nın Mimarisi Prop AMM İçin Neden İdealdir?

Prop AMM "aktif olarak yönetilen" bir sistemdir, yani iki temel koşulu gerektirir:

1. Düşük Güncelleme Maliyetleri

2. Öncelikli Yürütme

Solana'da bu iki husus iç içe geçmiş durumdadır: Düşük maliyetli güncellemeler, genellikle güncellemelerin öncelikli olarak yürütülebileceği anlamına gelir.

Peki likidite sağlayıcıları neden bu iki noktaya ihtiyaç duyuyor? İlk olarak, envanter değişikliklerine veya varlık endeksi fiyatlarındaki dalgalanmalara (örneğin, merkezi borsa fiyatları) bağlı olarak fiyat eğrisini blok zinciri hızında sürekli olarak güncelleyecekler. Solana gibi yüksek frekanslı bir zincirde, güncelleme maliyetleri çok yüksekse, yüksek frekanslı ayarlamalar yapmak zor olacaktır.

İkinci olarak, bir likidite sağlayıcısı güncellemesini bir bloğun en üstüne ekleyemezse, eski fiyat teklifi arbitrajcılar tarafından "önceden" işlem görecek ve bu da kaçınılmaz bir kayba yol açacaktır. Bu iki özellik olmadan, likidite sağlayıcıları verimli bir şekilde çalışamaz ve kullanıcılar daha düşük işlem fiyatları alır.

Solana'daki Prop AMM HumidiFi örneğini ele aldığımızda, @SliceAnalytics verilerine göre likidite sağlayıcısı, fiyat teklifini saniyede 74 defaya kadar güncelliyor.

EVM'den gelen oyuncular şunu sorabilir: "Solana'nın yuvası yaklaşık 400ms, Prop AMM tek bir yuva içinde fiyatı nasıl birden fazla kez güncelleyebilir?"

Cevap, EVM'nin ayrık blok modelinden temelde farklı olan Solana'nın sürekli mimarisinde yatıyor.

· EVM: İşlemler genellikle tam bir blok önerildikten ve onaylandıktan sonra sırayla yürütülür. Bu, ortada gönderilen güncellemelerin bir sonraki blokta yürürlüğe gireceği anlamına gelir.

· Solana: Lider Doğrulayıcı düğümler tam bir blok beklemez; bunun yerine, işlemleri küçük veri paketlerine ("parçalar" olarak adlandırılır) böler ve bunları sürekli olarak ağa yayınlar. Bir yuva içinde birden fazla borsa olabilir, ancak #1 parçalamadaki fiyat güncellemesi #1 takasını, #2 parçalamadaki fiyat güncellemesi ise #2 takasını etkiler.

Not: Flashblock'lar, Solana'nın shred'lerine benzer. CBER konferansında Anza Labs'tan @Ashwinningg'e göre, slotun her 400 ms'de 32.000 shred sınırı, milisaniyede 80 shred'e denk geliyor. 200 ms'lik Flashblock'ların, Solana'nın sürekli mimarisiyle karşılaştırıldığında likidite sağlayıcı gereksinimlerini karşılayacak kadar hızlı olup olmadığı ise hala belirsizliğini koruyor.

Peki, Solana güncellemeleri neden bu kadar ucuz? Ve öncelikli olarak uygulanmalarının sebebi ne?

Öncelikle, Prop AMM'nin Solana'da uygulanması bir kara kutu olsa da, Solana programlarında CU'ların yazılma şeklini optimize eden Pinocchio gibi bir kütüphane mevcut. Helius'un blogu harika bir açıklama sunuyor. Bu kütüphane sayesinde, Solana programlarının CU tüketimi yaklaşık 4000 CU'dan yaklaşık 100 CU'ya düşürülebiliyor.

Resim Kaynağı: github

Şimdi ikinci kısma bakalım. Daha üst seviyede, Solana, EVM'de olduğu gibi, en yüksek Ücret/Hesaplama Birimi oranına sahip işlemleri seçerek öncelik sırasına koyar (Hesaplama Birimleri, EVM'nin Gas'ına benzer).

· Özellikle Jito kullanılıyorsa formül Jito İpucu / Hesaplama Birimleridir

· Aksi takdirde: Öncelik = (Bahşiş + Temel Ücret) / (1 + CU Limiti + İmza CU + Yazma Kilidi CU)

Prop AMM güncellemesinin Hesaplama Birimleri Jupiter Swap ile karşılaştırıldığında, güncellemenin 1:1000 oranıyla son derece ucuz olduğu ortaya çıkıyor.

Prop AMM Güncellemesi: Basit eğri güncellemesi oldukça ucuz. Wintermute'un güncellemesi sadece 109 CU ve toplam maliyeti sadece 0,000007506 SOL.

Jüpiter Takası: Jüpiter rotası üzerinden yapılan bir takas, toplam 0,000005 SOL maliyetiyle ~100.000 CU'ya ulaşabilir

Bu önemli fark nedeniyle, likidite sağlayıcıları güncelleme işlemleri için yalnızca asgari bir ücret ödemek zorunda kalıyor ve borsalardan çok daha yüksek bir Ücret/CU oranına ulaşarak güncellemelerin bloğun en üstünde yürütülmesini sağlıyor ve kendilerini arbitraj saldırılarından koruyor.

Prop AMM Neden Henüz EVM'ye Ulaşmadı?

Bir Prop AMM güncellemesinin, varlık çiftinin fiyat eğrisini belirleyen bir değişkene yazmayı içerdiğini varsayarsak. Prop AMM'nin Solana üzerindeki kodu, likidite sağlayıcılarının stratejilerini gizli tutmak istediği bir "kara kutu" olsa da, bu varsayımı kullanarak Obric'in Prop AMM'yi Sui üzerinde nasıl uyguladığını anlayabiliriz: Varlık çiftinin fiyatını belirleyen değişken, bir güncelleme fonksiyonu aracılığıyla akıllı sözleşmeye yazılır.

Keşif için @markoggwp'ye teşekkürler!

Bu varsayımla, Solana'nın Prop AMM modelinin EVM üzerinde uygulanamaz hale gelmesine neden olan EVM mimarisinde önemli bir engel bulduk.

OP-Stack Katman 2 blok zincirlerinde (Base ve Unichain gibi) işlemlerin öncelik sırasının Gas başına ücretlere göre belirlendiğini hatırlayın (Solana'nın Ücret/CU sıralamasına benzer şekilde).

EVM'de yazma işlemlerinin Gas maliyeti son derece yüksektir. Solana'nın güncellemeleriyle karşılaştırıldığında, SSTORE işlem kodu aracılığıyla EVM'ye bir değer yazmanın maliyeti şaşırtıcıdır:

· SSTORE (0 → 0 olmayan): ~22.100 gaz

· SSTORE (0 olmayan → 0 olmayan): ~5.000 gaz

· Tipik AMM takası: ~200.000–300.000 gaz

Not: EVM'deki gaz, Solana'daki Hesaplama Birimlerine (CU) benzerdir. Yukarıdaki SSTORE gaz sayıları, her işlemin yalnızca bir yazma (soğuk yazma) işlemi yaptığını varsayar; bu da makul bir yaklaşımdır çünkü genellikle tek bir işlem içinde birden fazla güncelleme gönderilmez.

Güncellemeler hala takaslardan daha ucuz olsa da, gaz verimliliği yalnızca yaklaşık 10x'tir (güncellemeler birden fazla SSTORE içerebilir), oysa Solana'da bu oran yaklaşık 1000x'tir.

Bu, aynı Solana Prop AMM modelinin EVM'de daha riskli olduğunu gösteren iki sonuca yol açar:

1. Yüksek Gaz maliyetleri, güncelleme önceliğinin sağlanmasını zorlaştırır: Düşük gaz ücretleri, yüksek bir ücret/Gaz oranını garanti edemez. Güncellemelerin önceden başlatılmaması ve bir bloğun en üstüne yerleştirilmesi için daha yüksek gaz ücretleri gerekir ve bu da maliyetleri artırır.

2. EVM'de daha yüksek arbitraj riski: EVM'de Gas/Swap Gas oranı güncellemesi yalnızca 1:10 iken, Solana'da 1:1000'dir. Bu, arbitrajcıların bir likidite sağlayıcısının güncellemesini önceden yapmak için ücretleri yalnızca 10 kat artırmaları gerektiği anlamına gelir; Solana'da ise bu oran 1000 kattır. Bu düşük oranlı senaryoda, arbitrajcıların düşük maliyet nedeniyle eski fiyat tekliflerini yakalamak için fiyat güncellemelerini önceden yapma olasılıkları daha yüksektir.

Bazı yenilikler (örneğin geçici depolama için EIP-1153'ün TSTORE'u) yaklaşık 100 gas'lık bir yazma maliyeti sağlar, ancak bu depolama geçicidir, yalnızca tek bir işlem içinde geçerlidir ve türev ticaretinde daha sonra kullanılmak üzere fiyat güncellemelerini kalıcı hale getirmek için kullanılamaz (örneğin, tüm bir blok dönemi boyunca).

Prop AMM'yi EVM'ye Nasıl Tanıtabiliriz?

Cevap vermeden önce, "neden" sorusuna bir bakalım: Kullanıcılar her zaman daha iyi işlem fiyatları, yani paralarının karşılığında daha fazla getiri elde etmek isterler. Ethereum ve Layer 2'nin Prop AMM'si, kullanıcılara daha önce yalnızca Solana veya merkezi borsalarda mevcut olan rekabetçi fiyatlar sağlayabilir.

Prop AMM'yi EVM'de uygulanabilir kılmak için Solana'daki başarısının nedenlerinden birini inceleyelim:

· Blok Üstü Güncelleme Koruması: Solana'da, Prop AMM güncellemeleri, likidite sağlayıcılarını önden işlem yapmaktan korumak için blok üstünde yapılır. Üst düzey güncellemeler, hesaplama birimi maliyetinin minimum olması sayesinde mümkün olur ve bu sayede düşük ücretlerle bile, özellikle türev işlemlere kıyasla, yüksek bir ücret/CU oranı elde edilebilir.

Peki, 2. Katman EVM blok zincirine blok üstü Prop AMM güncellemelerini nasıl ekleyebiliriz? İki yaklaşım var: ya yazma maliyetini düşüreceğiz ya da Prop AMM güncellemeleri için bir öncelik kanalı oluşturacağız.

EVM'nin durum büyüme sorunu nedeniyle, yazma maliyetini azaltma yaklaşımı daha az uygulanabilirdir, çünkü ucuz SSTORE'lar durum şişkinliği saldırılarına yol açacaktır.

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

Uniswap'tan @MarkToda, Küresel Depolama Akıllı Sözleşmesi + Özel Blok Oluşturucu Stratejisinden yararlanan yeni bir yaklaşım önerdi:

İşte nasıl çalıştığı:

· Küresel Depolama Sözleşmesi: Basit bir akıllı sözleşmeyi genel anahtar-değer deposu olarak dağıtın. Likidite sağlayıcıları bu sözleşmeye fiyat eğrisi parametrelerini yazar (örneğin, set(ETH-USDC_CONCENTRATION, 4000)).

· Oluşturucu Stratejisi: Bu, zincir dışı önemli bir bileşendir. Blok oluşturucu, küresel depolama sözleşmesine gönderilen işlemleri belirler, bloğun Gaz miktarının %5-10'unu bu güncelleme işlemlerine ayırır, bunları ücrete göre önceliklendirir ve spam işlemlerini önlemek için sıralar.

Lütfen dikkat: İşlemlerin bloğun en üstüne yerleştirilmelerini garantilemek için doğrudan küresel depolama adresine gönderilmesi gerekir.

Özel blok oluşturma algoritması örneklerine rblib'den ulaşabilirsiniz.

Prop AMM Entegrasyonu: Likidite sağlayıcılarının Prop AMM sözleşmesi, takaslar sırasında küresel depolama sözleşmesinden fiyat eğrisi verilerini okuyarak teklif sağlar.

Bu mimari iki konuyu ustalıkla ele alıyor:

1. Koruma: Oluşturucu stratejisi, bloktaki tüm fiyat güncellemelerinin işlemlerden önce yürütülmesini sağlamak için "hızlı bir şerit" oluşturur ve böylece önden işlem yapma riskini ortadan kaldırır.

2. Maliyet Verimliliği: Likidite sağlayıcıları artık bloğun en üstüne çıkmak için tüm DeFi kullanıcılarıyla yüksek Gas Fiyatları için rekabet etmiyor; bunun yerine, yalnızca yerel ücret piyasasında güncelleme işlemleri için ayrılmış en üst blok için rekabet etmeleri gerekiyor ve bu da maliyetleri önemli ölçüde azaltıyor.

Kullanıcı işlemleri, aynı bloğun başlangıcında likidite sağlayıcısı tarafından belirlenen fiyat eğrisine göre yürütülecek ve böylece kotasyonların güncelliği ve güvenliği sağlanacaktır. Bu model, Solana'daki düşük maliyetli ve yüksek öncelikli güncelleme ortamını EVM'de taklit ederek, EVM'de Prop AMM'nin önünü açacaktır.

Ancak bu modelin bazı dezavantajları da var; bunları yazının sonunda tartışmaya açacağım.

Çözüm

Prop AMM'nin uygulanabilirliği, temel bir ekonomik sorunun ele alınmasına bağlıdır: Öne geçmeyi önlemek için ucuz ve öncelikli uygulama.

Standart EVM mimarisi bu tür işlemleri maliyetli ve riskli hale getirirken, yeni tasarımlar bu sorunu çözmek için farklı yaklaşımlar sunuyor. Yeni tasarımda zincir üstü küresel depolama akıllı sözleşmeleri ve zincir dışı oluşturucu stratejisi birleştirilerek, güncellemelerin blok üstü yürütülmesini sağlamak için özel bir "hızlı şerit" oluşturulabilir ve aynı zamanda yerel, kontrollü bir ücret piyasası oluşturulabilir. Bu, Prop AMM'yi EVM'de uygulanabilir kılmakla kalmaz, aynı zamanda blok üstü oracle güncellemelerine dayanan tüm EVM DeFi'sini de kökten değiştirebilir.

Açık Sorular

· EVM üzerindeki Prop AMM'nin 200ms Flashblock hızı, Solana'nın sürekli mimarisiyle rekabet etmek için yeterli mi?

· Solana'da AMM trafiğinin çoğu, kolay AMM entegrasyonu için bir SDK sağlayan Jupiter adlı tek bir toplayıcıdan gelir. Ancak, 2. Katman EVM'de trafik, genel bir SDK olmadan birden fazla toplayıcıya dağıtılır. Bu durum, Prop AMM için bir zorluk teşkil ediyor mu?

· Solana'da, Prop AMM güncellemeleri yalnızca yaklaşık 100 CU tüketiyor. Bu verimliliğin ardındaki uygulama mekanizması nedir?

· Hızlı yol modeli yalnızca bir bloğun en üstündeki güncellemeleri garanti eder. Bir Flashblock içinde birden fazla borsa varsa, likidite sağlayıcıları bu borsalar arasındaki fiyatları nasıl günceller?

· Solana'nın Pinokyo optimizasyon yaklaşımına benzer şekilde Yul veya Huff gibi dilleri kullanarak optimize edilmiş EVM programları yazmak mümkün müdür?

· Prop AMM, RFQ ile nasıl karşılaştırılır?

· Likidite sağlayıcılarının kullanıcıları cezbetmek için N Blok'ta rekabetçi teklifler sunup ardından N+1 Blok'ta rekabetçi olmayan tekliflere geçmesini nasıl önleyebiliriz? Jupiter bu riski nasıl azaltıyor?

· Jupiter Ultra V3'ün Ultra Sinyalizasyon özelliği, Prop AMM'nin zararlı ve zararsız trafik arasında ayrım yapmasını sağlayarak daha sıkı teklifler sunmasını sağlar. Bu toplayıcı özellikleri, EVM'de Prop AMM için ne kadar önemlidir?

Orijinal Gönderi Bağlantısı

Resmi BlockBeats topluluğuna katılmaya hoş geldiniz:

Telegram Abonelik Grubu: https://t.me/theblockbeats

Telegram Tartışma Grubu: https://t.me/BlockBeats_App

Resmi Twitter Hesabı: https://twitter.com/BlockBeatsAsia