Giriş

Bu yazıda, keyfi uygulamaların kendi MEV yakalamak için kullanabilecekleri bir mekanizma olan MEV vergilerini tanıtıyoruz.

Bu mekanizma bugün OP Ana Ağ, Base ve Blast gibi OP Stack L2'lerde kullanılabilir, çünkü bu zincirlerdeki blok teklif edenler rekabetçi öncelik sıralaması dediğimiz bir dizi kuralı takip eder.

Bu zincirlerden birine MEV vergisi uygulamak için akıllı sözleşme, işlemin öncelik ücretinin bir fonksiyonu olan bir ücret alır. Bir uygulama, arama yapanlardan her 1 ABD doları öncelik ücreti için 99 ABD doları tutarında bir MEV vergisi alırsa, bu işlem için rekabetçi MEV %99'unu yakalayabileceğini gösteriyoruz.

MEV vergileri, geniş bir tasarım alanı açan basit bir tekniktir. Bunları, zincirdeki herhangi bir uygulamanın, herhangi bir zincir dışı altyapıya ihtiyaç duymadan, yalnızca blok teklif sahibi tarafından yürütülen tek bir paylaşılan açık artırmaya bağlanarak kendi özel MEV açık artırmasını yürütmesine izin vermek olarak düşünebilirsiniz.

MEV araştırmasında üç ana sorunu çözmek için MEV vergilerin nasıl kullanılabileceğini gösteriyoruz:

• Takas tarafından alınan fiyatı optimize eden merkezi olmayan borsa (DEX) yönlendiriciler
• Likidite sağlayıcılarının yaşadığı kayıp ve yeniden dengelemeyi (LVR) en aza indiren otomatik piyasa yapıcılar (AMM'ler)
• Kullanıcılarının işlemleri tarafından oluşturulan herhangi bir "geri dönük" MEV yakalamasına izin veren cüzdanlar

Ama bir sorun var. MEV vergileri, yalnızca blok teklif edenlerin, işlemleri sansürlemeden, gözetlemeden veya geciktirmeden öncelik ücretine göre sıralamayı içeren rekabetçi öncelik sıralaması kurallarına sıkı sıkıya uyması durumunda işe yarar. Blok teklif edenler bu kurallardan saparlarsa, değeri kendileri için yakalamak için MEV vergilerinden kaçınabilirler. Bu nedenle, bugün, MEV vergileri, L2 sıralayıcılarına güvenmeye bağlıdır ve blok oluşturmanın, teklif sahibi için geliri en üst düzeye çıkaran bir rekabetçi inşaatçı açık artırmasının hakim olduğu Ethereum L1'de muhtemelen hiç çalışmayacaktır.

Yine de, MEV vergilerinin gücü ve esnekliği, öncelikli sıralamanın bugün bunu sağlayabilen platformlar için doğru seçim olabileceğini gösteriyor. Ve rekabetçi öncelik sıralamasının göreceli basitliği, tek bir sıralayıcıya güvenmek zorunda kalmadan, merkezi olmayan bir şekilde uygulamanın uygun bir yolu olabileceğini düşündürmektedir. Umarız bu yazı, bu sorun üzerinde daha fazla çalışmayı motive eder.

Öncelik sıralaması

Birisi L1 veya L2 Ethereum bir işlem gönderdiğinde, blok teklif edene ödedikleri bir öncelik ücreti belirler.1 Bunun, builderPriorityFee'yi (ETH cinsinden toplam ödeme) elde etmek için işlemde kullanılan gas ile çarpılan bir sayı olan priorityFeePerGas olarak belirtildiğini hayal edebilirsiniz. 2

Bir bloktaki işlemlerin azalan priorityFeePerGas ile açgözlülükle sıralanması gerektiğine dair bir kural Ethereum protokol yoktur. Ancak bu, blok oluşturmanın popüler bir yoludur - örneğin, OP Yığın zincirlerinin yanı sıra geth ve reth sıralayıcıları tarafından kullanılan varsayılan algoritmadır. Öncelik sıralaması, işlem yapanların işlemlerinin aciliyetini verimli bir şekilde ifade etmesine izin vermekle kalmaz, aynı zamanda doğal olarak belirli MEV türlerini blok teklif edene yönlendirir.

Bunun nedeni, öncelikli sıralamanın MEV için rekabeti öncelikli gas açık artırmasına dönüştürmesidir. Merkezi bir borsa karşı bir AMM tahkim etmek gibi zincirle etkileşimden kâr elde etme fırsatı olduğunda, arama yapanlar önce bu fırsatı talep etmek için rekabet ederler. Zincir, işlem katılımını ve sıralamasını belirlemek için öncelikli sıralamayı kullanıyorsa, arama yapanlar işlemlerinde yüksek öncelikli ücretler belirleyerek rekabet eder.

Risksiz kârların sıfıra kadar rekabet ettiği rekabetçi bir senaryoda, kazanan araştırmacı, MEV tutarının tamamını öncelikli ücretlerle ödemelidir. 3 Dolayısıyla, bir sözleşmeyle etkileşimden elde edilecek 100 ETH kâr varsa, bunu talep eden ilk işlem 100 ETH'lik bir öncelik ücreti belirleyecektir. (Bununla ilgili bazı uyarıları Sınırlamalar bölümünde tartışıyoruz).

MEV vergiler

Bir akıllı sözleşmenin, kendisiyle etkileşime giren herhangi bir işlemden MEV almak istediğini varsayalım. akıllı sözleşmeler kendi MEV yakalamaya çalışabilecekleri, uygulamaya özel farklı yollar hakkında geniş bir araştırma kütüphanesi vardır.

Ama aslında, uygulama hakkında hiçbir şey bilmemize gerek yok. Bloğun rekabetçi öncelik sıralaması yoluyla oluşturulduğunu biliyorsak, işlemdeki MEV miktarı için evrensel bir sinyalimiz olur: öncelik ücreti.

Akıllı sözleşmenin, işlemin öncelik ücretine bakabileceğini ve bunun artan bir işlevi olarak kendi ücretini talep edebileceğini öneriyoruz. Örneğin, sözleşme, onu çağıran kişinin sözleşmeye ETH applicationPriorityFee = 99 * proposerPriorityFee aktarmasını gerektirebilir. 4

Bu yeni ücret, işlemi gönderen arama yapan kişi tarafından ödenir, bu nedenle bu arama yapan kişinin davranışını etkiler. Bir fırsatta 100 MEV varsa, kazanan işlem artık yalnızca 1 ETH'lik bir öncelik ücreti belirleyecektir, çünkü bu toplam 100 ETH ödeme ile sonuçlanacaktır (blok teklif edene 1 ETH ve akıllı sözleşmeye ETH 99). Daha yüksek öncelikli herhangi bir ücret, işlemi kârsız hale getirecektir; Daha düşük öncelikli herhangi bir ücret, daha yüksek bir ücret belirleyen bir rakibe fırsatı kaybetmenize neden olur. Bu, akıllı sözleşmenin işlemdeki MEV %99'unu ele geçirdiği anlamına gelir.

Akıllı sözleşme tarafından uygulanan bu ekstra ücrete MEV vergisi diyoruz. MEV vergileri, bir uygulamanın öncelik sıralamasını kendi yararına ele geçirmesine izin vererek, blok önerene sızdırmak yerine kullanıcıları için MEV yeniden yakalamasına izin verir.

Bu ücret, priorityFeePerGas'ın bir fonksiyonu olarak yeterince hızlı artarsa, teklif sahibine yalnızca ihmal edilebilir miktarda MEV tahakkuk edecektir. priorityFeePerGas Wei cinsinden olduğundan (bir ETH milyarda birinin milyarda biri), üzerinde çalışmak için çok fazla hassasiyetimiz var. Örneğin, MEV vergisi, 50.000'lik bir priorityFeePerGas'ın aşırı derecede yüksek bir vergiye yol açacak kadar hassas olduğu long, teklif sahibine yapılan toplam ödeme 0,01 ABD dolarından az olacaktır. 5

Ancak, önemli bir uyarı var. Sınırlamalar bölümünde tartışıldığı gibi, MEV vergileri, yalnızca blok teklif edenlerin kendi gelirlerini en üst düzeye çıkarmak emir bu kurallardan sapmak yerine, "rekabetçi öncelik sıralaması" dediğimiz belirli kurallara uyması durumunda işe yarar. Bu kuralların güvene dayalı olmayan bir şekilde uygulanması açık bir sorundur.

Tek uygulama MEV yakalama

Burada, blok oluşturma için rekabetçi öncelik sıralamasını kullanması garanti edilen bir zincirde, MEV vergilerin MEV'daki üç önemli sorunu azaltmak için nasıl kullanılabileceğini özetliyoruz: DEX arayüzlerinin takasçılar için ticaret yürütmeyi iyileştirmesine izin vermek, AMM'lerin LP'leri için arbitraj kayıplarını azaltmasına izin vermek ve cüzdanların kullanıcıyı geri çalıştırma hakkını satarak kullanıcıları için MEV sızıntısını azaltmasına izin vermek.

DEX yönlendiriciler

UniswapX ve 1inch Fusion gibi amaç tabanlı DEX yönlendirme protokollerinde, bir kullanıcı (Alice) takas etme niyetini imzalar ve arama yapanlar bu niyeti Alice için mümkün olan en iyi fiyata yönlendirmek veya doldurmak için rekabet eder.

UniswapX'in mevcut sürümleri, bu rekabeti yürütmek için iki mekanizma kullanır: Alice'in limit fiyatının, bir araştırmacı onu doldurana kadar zaman içinde değiştiği bir Hollanda açık artırması ve bu Hollanda açık artırmasının başlangıç fiyatını belirlemek için bir ilk zincir dışı teklif talebi (RFQ) açık artırması.

Rekabetçi öncelik sıralamasını garanti eden bir platformda, UniswapX bunları tek bir mekanizma ile değiştirebilir: MEV vergisi. Bunu, kullanıcının herkes tarafından hemen doldurulabilecek, ancak işlemin önceliğinin bir işlevi olarak belirlenen bir yürütme fiyatı ile bir emir imzalamasını sağlayarak uygulayabilir.

Örneğin, Alice'in 1 ETH satmak için bir UniswapX emir varsa, emir gerçekleştirme fiyatını minimumPrice + (0,01 $ * priorityFeePerGas) olarak tanımlayabilir. minimumFiyat, mevcut fiyattan önemli ölçüde daha düşük olmasını beklediği sabit bir değer olabilir.

Araştırmacılar, işlemleri göndererek Alice'in emir doldurmak için yarışacaktı. Hangi işlem en yüksek öncelik ücretine sahipse ve geri dönmezse, emir dolduracaktır, bu da takasçının arama yapanların bulabileceği en iyi fiyatı almasını garanti etmelidir. (Bunun bazı istisnaları Sınırlamalar bölümünde ele alınmıştır.)

Alice'in minimum fiyatı 3.000$ ve ETH'in mevcut fiyatı 3.500$ ise, kazanan işlemdeki priorityFeePerGas yaklaşık 50.000 olacaktır. (200.000 gas'ye mal olan bir işlemde, bunun blok teklif edene yalnızca yaklaşık 10 milyar Wei (yaklaşık 0,000035 $) ödeme ile sonuçlanacağını gözlemleyin.)

Bunun, UniswapX'te kullanılan mevcut mekanizmalara göre bazı potansiyel faydaları vardır.

MEV vergileri kullanan siparişler, Hollanda açık artırmalarını kullanan siparişlere göre daha hızlı ve daha iyi bir fiyatla tamamlanabilir. bu yazıda tartışıldığı gibi, zincir üstü Hollanda müzayedeleri, bloklar arasındaki fiyat hareketleri nedeniyle MEV bir miktar değer sızdırır ve tamamlanması birçok blok alabilir. Buna karşılık, MEV vergileri kullanan siparişler, MEV büyük çoğunluğunu yakalarken genellikle bir sonraki blokta tamamlanabilir.

Zincir dışı bir RFQ'dan farklı olarak, MEV vergileri kullanan bir emir doldurmak için yapılan açık artırma, zincir üzerinde işlem yürütme ile atomik olarak gerçekleşir. Bu, kazanan bir teklif sahibinin, yalnızca zincir üstü işlemleri başarılı olursa emir doldurmayı taahhüt ettiğinin garanti edilebileceği anlamına gelir. Bu, AMM'ler gibi zincir üstü likiditenin zincir dışı likidite ile rekabet etmesini kolaylaştırabilir, bu da UniswapX'in Uniswap v4 gibi çok havuzlu sistemler için daha da etkili bir yönlendirici görevi görebileceği anlamına gelir.

AMM'ler

Normalde, AMM'ler, loss-vs-rebalancing papers'da tartışıldığı gibi, bloğun tepesinde eski fiyatlara karşı işlem yapan arbitrajcılara değer sızdırır. AMM'lerin bu MEV yakalamasını sağlamak için MEV vergileri kullanabiliriz. İşleri basit tutmak için, bunun konsantre likidite olmayan bir AMM üzerinde nasıl çalışabileceğini tartışacağız. (Bu tür bir sorunun konsantre likidite ile nasıl çözülebileceğiyle ilgileniyorsanız, Sorella yakında bir çözüm yayınlayacak.)

Bir AMM, işlemdeki öncelik ücretinin bir fonksiyonu olarak ekstra bir ücret talep ederek MEV yakalayabilir ve bu da blokta ilk işlem yapma hakkını açık artırmaya çıkarmasına olanak tanır. Bu ücreti hesaplamanın ve tanımlamanın birçok yolu vardır. Tartışmasız nötr olanı tartışacağız - onu havuz likiditesi birimleri, sqrt(xy) cinsinden ifade edeceğiz. Kazanan işlem, havuzun likiditesini en çok artıran işlem olacaktır.

Bir bloktaki bir havuzda ilk işlemi yürütürken, y_end > x_start y_start koşulu x_end zorlamak yerine, havuz koşulu uygulayabilir (bazı sabitler olarak):

x_end y_end > (sqrt(x_start y_start) + a*priorityFeePerGas)^2

Bu formül, arbitraj tüccarını gerçek fiyattan işlem yapmaya teşvik eder ve bu işlemden sonra havuzdaki orta nokta fiyatı gerçek fiyat olmalıdır. 6

Bu ilk işlemden sonra alım satımlar, sabit takas ücretleriyle Uniswap v2'de olduğu gibi çalışabilir. Ekstra bir MEV vergisi ödemeden havuzda işlem yapmak isteyen bilgisiz işlemler, düşük öncelikli bir ücret belirleyecektir.

Farklı etkileri olacak bir AMM MEV vergileri uygulamanın başka birçok yolu vardır. Örneğin, MEV vergileri, takasın giriş veya çıkış tokeninde ifade edilebilir, havuz tarafından uygulanan takas ücreti yüzdesini etkileyebilir veya kullanıcının alım satımının minimum fiyatını belirleyebilir. Bunun keşfedilecek ilginç bir tasarım alanı olduğunu düşünüyoruz.

Backrunning auctions

Yukarıdaki açıklamalar, belirli uygulamaların MEV sızdırılmasını önlemek için nasıl tasarlanabileceğini göstermektedir. Bununla birlikte, bir cüzdan, kullanıcılarının herhangi bir uygulamayla, hatta MEV vergileri içermeyenler de dahil olmak üzere rastgele işlemlerden yarattıkları MEV yakalamalarına yardımcı olmak isterse ne olur?

Örneğin, Alice bir AMM üzerinde büyük bir işlem yaptığında, bazen "geri dönenlerin" fiyatı geri çekmesi için bir arbitraj fırsatı yaratır. Bu normalde Alice'e gitmek yerine MEV sızdırılır.

MEV-Share ve MEVBlocker, kullanıcıların işlemlerinden MEV yakalamalarına olanak tanıyan iki protokoldür, ancak karmaşık bir zincir dışı açık artırma sistemine güvenirler. Orderflow Açık Artırma Tasarım Alanı diğer bazı çözümleri açıklar.

MEV vergileri, amaca dayalı bir akıllı sözleşme cüzdanı ile birleştirildiğinde, Alice için geriye dönük MEV yakalamak için alternatif bir sistem oluşturmamıza izin verebilir. Alice'in, AMM üzerinde işlem gören bir işlem oluşturmak yerine, herkesin Alice'in akıllı sözleşme cüzdanına gönderebileceği bir niyet imzaladığını ve bu eylemi gerçekleştirmesini sağladığını varsayalım. Alice'in akıllı sözleşme cüzdanı, bu işlemi gönderen kişiden Alice'e ödenen bir MEV vergisi alır.

Alice'in niyetini gönderen araştırmacı, aynı işlemde atomik olarak yapabildikleri için onu geri alma hakkına sahip olacaktır. Sonuç olarak, arama rekabetçiyse, Alice'i geri almaktan elde edilen tüm kâr, Alice'in MEV vergisi yoluyla Alice'e tahakkuk etmelidir.

Bu sistemin, kullanıcıları önden çalışan kullanıcı işlemlerini içeren saldırılara karşı korumayabileceğini unutmayın, çünkü bir kullanıcıyı önden çalıştıran bir işlem, o kullanıcıya MEV vergisi ödemekten kaçınabilir. Bu sorun (ve bunun için bazı olası azaltıcı etkenler) aşağıdaki Sınırlamalar bölümünde daha ayrıntılı olarak ele alınmıştır. Bununla birlikte, bu en azından herhangi bir azaltma olmadan genel bellek havuzlarını kullanan sistemlerde bir gelişme olabilir.

Diğer kullanım örnekleri

Bu örneklere ek olarak, MEV vergilerinin diğer potansiyel kullanımları, şu anda zincir dışı veya Hollanda açık artırması kullanan hemen hemen her şeyi içerebilir, örneğin:

• Oval
• gibi NFT teminatlı borç verme ihalelerinde a protokol href="https://moallemi.com/ciamac/papers/pricing-dutch-auctions-2024.pdf" daha az sızıntı yapan tasfiyelerde teminatlı borç verme açık artırmalarını yeniden finanse etmek gibi oracle'ların oluşturdukları oracle çıkarılabilir değerini yakalamaları için
• protokoller Hollanda müzayedelerinden daha değerli

Uygulamalar arası MEV yakalama

Yukarıdaki çözümler, tek bir uygulamayla etkileşimden MEV yakalamak için tasarlanmıştır. Ancak bazen bir araştırmacının aynı işlemde birden fazla uygulamayla etkileşime girerek daha da fazla değer elde etmesi mümkün olabilir.

Bu uygulamalardan yalnızca birinin MEV vergisi varsa, bu MEV verginin ne kadar yüksek veya düşük olduğuna bakılmaksızın, işlemden elde edilen tüm MEV MEV vergisi ile uygulamaya gitmelidir.

Ancak, bir arama yapan kişinin işlemi MEV vergileri kullanan iki uygulamayla etkileşime girerse ne olur? Örneğin, MEV vergilendirilmiş bir AMM karşı yukarıda açıklanan MEV vergilendirilmiş UniswapX emirlerinden birini doldurarak elde edilebilecek bazı MEV varsa ne olur?

Bu durumda, her bir başvuru tarafından yakalanan nispi fazla MEV miktarı, bu uygulamaların MEV vergilerini nasıl belirlediğine göre belirlenir. MEV vergisi olarak app_i değeri tax_i(öncelik) fonksiyonu tarafından verilirse, kazanan işlemin önceliği şu denklemde öncelik çözülerek belirlenebilir:

tax_1(priorityPerGas) + tax_2(priorityPerGas) = toplam MEV

(Teknik olarak, blok teklif edene ödenen öncelik ücretini hesap için kullanılan öncelikPerGas * gasUsed için üçüncü bir terim ekleyebiliriz, ancak Ek A'da tartışıldığı gibi, normal koşullar altında muhtemelen ihmal edilebilir olacağından bunu görmezden geleceğiz.)

PriorityPerGas'ta doğrusal olan basit MEV vergileri durumunda (yani tax_1(priorityPerGas) = a_1 * priorityPerGas), her uygulama tarafından alınan MEV payını çözebilirsiniz:

a_1 priorityPerGas + a_2 priorityPerGas = MEV

priorityPerGas = MEV/(a_1 + a_2)

tax_1(priorityPerGas) = (a_1/(a_1+a_2))*MEV

tax_2(priorityPerGas) = (a_2/(a_1+a_2))*MEV

Kendi MEV vergisini belirlerken, bir uygulama bir ödünleşimle karşı karşıya kalır - daha yüksek vergiler, gerçekleştiğinde çapraz uygulama MEV daha büyük bir pay almasına izin verir, ancak onu çıkarmanın rekabet eden yolları varsa, bazı çapraz uygulama MEV kaçırabileceği anlamına gelir. Örneğin, her işlemde MEV vergisi alan bir AMM varsa, MEV vergili bir UniswapX emir farklı bir AMM veya zincir dışı bir doldurucu tarafından doldurulma olasılığı daha yüksek olabilir.

Çoğu durumda, iki uygulamanın MEV vergilerini MEV her birinin refahını en üst düzeye çıkaracak şekilde paylaşmak emir tasarladığı bir denge olabilir. Örneğin, bir MEV vergisi AMM, bloğun tepesine yakın tek bir bilgili tüccardan değer elde etmek isteyecektir, ancak daha sonra diğer tüccarlara ve uygulamalara (MEV vergileri kullananlar dahil) düşük bir sabit ücretle likidite sağlamak isteyecektir. Bu durumda, AMM nispeten düşük bir MEV vergisi belirlemesi muhtemeldir (örneğin, 0,00001 $ priorityFeePerGas), böylece arbitraj işlemi (varsa) bloğun başlarında gerçekleşir ve ardından bloktaki sonraki işlemlerden MEV vergi almaz. AMM ile etkileşim kurmak isteyen UniswapX gibi uygulamalar, havuz zaten arbitraj edildikten sonra işlemlerinin dahil edilmesini sağlamak için çok daha yüksek bir MEV vergisi (örneğin 0,01 $ priorityFeePerGas) belirleyebilir. Bu nispi vergilerle, üzerinde yalnızca 1 dolarlık MEV ve bir UniswapX emir 50.000 dolarlık MEV olsa bile, AMM ilk sırada yer alacaktı.

Bunun gelecekteki çalışmalara değer geniş bir tasarım alanı olduğunu düşünüyoruz.

Sınırlamalar

MEV vergilerin bazı komplikasyonları ve sakıncaları vardır. Bunların her birinin gelecekteki araştırmalar için ilginç bir alan olduğunu düşünüyoruz.

Vergiler MEV teşvik uyumsuzluğu

, tekelci bir blok teklif sahibi için teşvikle uyumlu değildir. Yalnızca işlemin dahil edilmesi için adil bir rekabet varsa işe yararlar, bu da yalnızca blok teklif sahibinin kendi gelirini maksimize etmek yerine "rekabetçi öncelik sıralaması" olarak adlandıracağımız kurallara uyması durumunda gerçekleşebilir. Gayri resmi ve kapsamlı olmayan bir şekilde, bu kuralların şunları içermesi gerektiğini öneriyoruz:

• Öncelik sıralaması. Bir blok içindeki işlemler, priorityFeePerGas'ın azalan emir göre sıralanmalıdır.
• Sansür DİRENÇ. Blok öneren, blok sırasında bir t1 işlemi alırsa ve blok ya dolu değilse ya da t2.priorityFeePerGas < t1.priorityFeePerGas gibi bir miktar t2 işlemi içeriyorsa, blok t1 işlemini içermelidir.
• İşlem öncesi gizlilik. Blok öneren, özel bir uç nokta aracılığıyla işlemleri kabul etmeli ve bloğa taahhütte bulunmadan önce bu tür işlemleri başkalarıyla paylaşmamalı veya bu işlemlerin içeriğini kendi işlemlerini oluştururken bir girdi olarak kullanmamalıdır.
• Son bakış yok. Blok öneren, daha önce kimseden işlem kabul ettiği ve bundan sonra kimseden işlem kabul etmediği belirli bir zaman blockTime belirlemelidir.

Bu özelliklerden biri veya daha fazlası ihlal edilirse, MEV vergilerinin etkinliğini zayıflatabilir. Sansür DİRENÇ ihlal eden bir blok teklif sahibi, rakip işlemleri hariç tutarak ve fırsatı kendisi için alan sıfır öncelikli bir işlem sunarak çoğu MEV vergisinden kaçınabilir. İşlem öncesi gizliliği ihlal eden bir blok teklif sahibi, diğer işlemlerden MEV çalabilir veya kendi başına tam olarak ne kadar yüksek belirlemesi gerektiğini bilmek için öncelik ücretlerine göz atabilirken, işlemleri herkesten daha geç gönderebilen bir kişi, bir fırsat için diğerlerinden daha fazla teklif verip vermeme konusunda ücretsiz bir "son bakışa" sahip olacaktır. her ikisi de nihayetinde rekabeti caydıran olumsuz seçim sorunları yaratabilir.

Ne yazık ki, ilk mülkün protokol katmanı uygulanması kolay olsa da, diğer mülklerin güvenilir bir şekilde uygulanması açık bir sorundur.

protokol katmanı'de yaptırımın yokluğunda, bu kurallara bağlı olan tek bir sıralayıcının bunlardan sapmaması için güvenilmesi gerekir ve teklif verenler blok oluşturmayı rekabetçi bir gelir maksimizasyonu müzayedesine (Ethereum L1'in MEV-Boost'u gibi) dış kaynak sağlarsa, bloklar muhtemelen bunları takip etmeyecektir.

Bu sorunlar, blok oluşturma için rekabetçi öncelik sıralamasını kullanmayı taahhüt eden tek bir güvenilir sıralayıcı ile "çözülebilir". Ayrıca, Sorella'nın Angstrom'u, Flashbots'un SUAVE'si, Lidersiz Açık Artırmalar veya Multiplicity gibi fikir birliği, kriptografi ve/veya güvenilir yürütme ortamlarının bir kombinasyonunu kullanan merkezi olmayan bir mekanizma ile çözülebilirler.

Full bloklar

MEV vergilerinin normal işleyişinin bir istisnası, bloklar tamamen dolduğunda meydana gelir. Bu durumda, blok teklif edenler, daha düşük öncelikli işlemleri bloğa geç dahil etmek yerine dışarıda bırakmak zorunda kalabilirler. MEV vergilendirilmiş uygulamalarla etkileşime giren işlemlerin son derece düşük öncelikli ücretlere sahip olması muhtemel olduğundan, bu uygulamaların MEV vergileri kullanmayan veya son derece düşük MEV vergileri olan uygulamalar tarafından dışlanması muhtemeldir. Bununla birlikte, ayrı bir taban ücret belirlemek için EIP-1559 benzeri bir mekanizma kullanan bir zincirde, blokların tamamen dolu olması nispeten nadir olmalıdır. Ek olarak, bloklar dolduğunda bazı işlemlerin ertelenmesi gerektiği göz önüne alındığında, daha yüksek MEV vergileri belirleyerek daha düşük aciliyet ifade eden işlemleri geciktirmek makul bir sonuç olabilir.

Vergiler MEV geri alınan işlemler

her "teklifin" bir işlem olduğu tek bloklu açık artırmalara etkin bir şekilde dayanır. Bu açık artırmaların bir dezavantajı, kaybedilen tekliflerin genellikle geri alınan işlemlerin zincire dahil edilmesine, bir miktar taban ücret ödenmesine ve zincirin tıkanmasına neden olmasıdır.

Bir sıralayıcı başarısız işlemleri tamamen hariç tutabilirse, bu sorunu hafifletir, ancak merkezi bir sıralayıcıyla bile uygulanması zor olabilir. (Ayrıca, yukarıda açıklanan sansür DİRENÇ özelliğine kesinlikle uymaz, ancak bu tanım değiştirilebilir.) Daha gelişmiş bir sıralayıcı, işlemlerin hangi çekişmeli açık artırmalara katılacaklarını belirlemelerine izin vererek, sıralayıcıya başarısız olacağını bildiği sonraki işlemleri atlamak için yeterli bilgi vererek bu süreci optimize edebilir.

Kullanıcı amaçlarının MEV vergilerin sızdırılması

, yalnızca arama yapanlar arasında rekabet varsa işe yarar, bu da fırsatın biraz yaygın olarak bilinmesi gerektiği anlamına gelir. Fırsatın zincir üzerinde görünür olduğu AMM'ler gibi uygulamalar için bu doğal olarak gerçekleşmelidir. Ancak, amaca dayalı yönlendirme veya geri çalışan açık artırmalar gibi uygulamalar için bu, uygulamanın kullanıcının amacını arama yapanlarla paylaşması gerekebileceği anlamına gelir.

Bazı durumlarda, yerine getirilmeden önce kullanıcının amacının yayınlanmasından kaynaklanan geçici gizlilik, MEV bir vergi tarafından geri alınamayacak şekilde değer sızdırabilir.

Örneğin, Alice'in yukarıda açıklanan açık artırma protokol kullanarak düşük likiditeye sahip bir token satın almak istediğini varsayalım. Akıllı sözleşme cüzdanının bu tokeni bir AMM satın alması için imzalı bir niyet yayınlayarak bir miktar kayma toleransı belirliyor. Arama yapanlar, kullanıcının emir doldurmadan yüksek öncelikli bir işlemde bu tokenin fiyatını kayma toleransına itmek için yarışabilir. Kazanan Bob, daha sonra Alice'in niyetini düşük öncelikli bir işleme dahil ederek ve geri alarak rekabetçi olmayan bir şekilde doldurabilir, böylece Alice'in ticaretini sandviçleyebilir ve MEV vergisinden kaçarken ona daha kötü bir fiyat verebilir. Benzer bir sorun NFT satın alımlarında da olabilir.

Böyle bir saldırının Bob için riskli olacağını unutmayın, çünkü jetonu satın almakla Alice'e satmak arasında atomikliği garanti edemez. Saf bir Bob düşüş Alice'in kendisinden değersiz bir jeton satın alma niyetini yayınladığı ve Bob'un ticaretini tamamlama beklentisiyle satın almasına neden olduğu bir "sandviç sökme" tuzak kurbanı olabilir, ancak Alice, Bob sandviçi tamamlayamadan niyetini iptal eder.

Uygulamalar, mevcut birçok sipariş akışı açık artırmasının yaptığı gibi, amaçları paylaştıkları arama yapanları sınırlayarak ve davranışlarını izleyerek de bunu azaltabilir.

MEV vergileri, Flashbots'un SUAVE tasarımlarında öngörüldüğü gibi gizliliğe duyarlı oluşturucu özellikleriyle birleştirmek de mümkün olabilir.

Son olarak, Alice'in niyetini paylaşmanın maliyetinin rekabetçi aramanın faydasından daha ağır bastığına karar verdiği durumlarda, kendisi bir işlem oluşturabilir ve bunu doğrudan bloğa gönderebilir. Yukarıda tartışıldığı gibi, rekabetçi öncelik sıralamasının ideal bir uygulaması, blok teklif edenden işlem öncesi gizlilik sağlayacaktır.

Tartışma ve önceki çalışmalar

Öncelikli gas açık artırmalar. Merkeziyetsiz blok zincirlerinde öncelik sıralamasının bazı dinamikleri, "madenci çıkarılabilir değeri" terimini ortaya atan Flash Boys 2.0 makalesinde incelenmiştir. Bu makale, Ethereum madencinin (bu ağ iş kanıtı kullandığında) zaten işlemleri önceliğe göre sıraladığını ve arbitrajcıların bir bloğa ilk dahil olma hakkı için teklif verdikleri "öncelikli gas müzayedelerine" katılmak için bu davranışa güvendiklerini ve bunun da merkezi olmayan borsa arbitrajdan madencilere tahakkuk eden MEV çoğuna yol açtığını gözlemledi.

İlk gelen alır. Themis veya Arbitrum One'ın mevcut sıralayıcısı,7 gibi işlem sıralama kuralları aracılığıyla MEV azaltmaya yönelik bazı girişimler, blok önerenlerin emir onları gördükleri emir işlemler.

Öncelik sıralaması farklı bir yaklaşım benimser - belirli bir süre içinde gelen işlemleri eşit olarak ele alır ve bunun yerine beyan edilen önceliklerine göre sıralar.

İlk gelene ilk hizmet, birden fazla doğrulayıcının bulunduğu gerçek bir ağ ortamında uygulanması ve hatta tanımlanması zordur. Ayrıca, tek bir güvenilir sıralayıcı ile bile savurgan gecikme süresi yarışlarına ve spam'e neden olabilir. Son olarak, MEV vergileri, varlık fiyatlarındaki süreksiz "sıçramalardan" elde edilen arbitraj karları gibi, ilk gelene ilk hizmet emrinin yapamayacağı belirli MEV türlerini ortadan kaldırabilir. Öncelikli sıralamanın ilk gelene ilk hizmet sıralamasına göre potansiyel avantajları, Budish, Cramton, Shim (2015)'de tartışılan sürekli zamanlı değiş tokuşlara göre ayrık zamanın avantajlarıyla bir şekilde ilişkilidir.

Bu arada, öncelik sıralaması varsayılan olarak MEV değer sızdırıyor gibi görünse de, bu gönderi uygulamaların onu yeniden yakalamak için nasıl tasarlanabileceğini gösteriyor.

Ücret paylaşımı. Bir Ethereum L2 olan Blast hem öncelikli hem de taban ücretlerin bir kısmını bir işlemde erişilen akıllı sözleşmeler paylaşır.

MEV vergiler benzer bir şeye izin verir (en azından öncelikli ücretler için), ancak ücret paylaşımı için özel bir destek olmaksızın, rekabetçi öncelik sıralaması kullanan herhangi bir zincirde uygulama katmanında uygulanabilir. Ayrıca, uygulamaların kendi vergilerini öncelikli ücretin özel işlevleri olarak tanımlamasına olanak tanıyarak daha fazla esneklik sağlar ve potansiyel olarak MEV duyarlı uygulamaların daha fazla birleştirilebilirliği ile sonuçlanır.

Güvenilmez çözümler. Bu gönderi, platformların rekabetçi öncelik sıralamasını kullanma motivasyonuna ve bunu yapan platformlardan yararlanmanın yollarına odaklanıyor, bunun nasıl güvenilir bir şekilde uygulanacağını tartışmak yerine.

Rekabetçi öncelik sıralaması için gerekli olan diğer özelliklerin her biri hakkında önceden önemli bir tartışma yapılmıştır. Örneğin, Fox, Pai, Resnick (2023)'de yazarlar, sansür direnişi yokluğunda zincir üstü açık artırmalardaki güvenlik açıklarını tartışıyor ve birden fazla eşzamanlı teklif sahibi kullanarak sansüre dayanıklı bir açık artırma için bir tasarım açıklıyor. Ancak, işlemler için belirli bir sıralama önermezler.

Flashbots'un SUAVE, , Sorella'nın Angstrom'u, Lidersiz Müzayedeler, Espresso ve Offchain Labs' dahil olmak üzere, güveni en aza indirilmiş blok oluşturma mekanizmaları oluşturma konusunda başka araştırmalar da yapılmıştır. @espressosys/espresso-systems-and-offchain-labs-release-r-d-roadmap-for-decentralized-timeboost-5d0007dff66d">decentralized Timeboost ve Péter Szilági tarafından zorunlu halka açık işlem katılımı.

Sonuç

Bu gönderinin L2'leri öncelikli sıralamayı (OP Yığını'nda varsayılan olarak desteklendiği gibi) kullanmayı düşünmeye teşvik ettiğini ve uygulamalara desteklendiği yerlerde MEV vergileri denemeleri için ilham verdiğini umuyoruz.

Ayrıca, hem L1 hem de L2'de güveni en aza indirilmiş rekabetçi öncelik sıralaması için protokoller hakkında daha fazla araştırmayı motive edeceğini umuyoruz. Bu sorun üzerinde işbirliği yapmakla ilgileniyorsanız ve bunu 6 Haziran Perşembe gününden önce okuyorsanız, Dan ile MEV dirençli L2 sıralayıcılar üzerinde çalışmak için TLDR Bursu'na başvurabilirsiniz. Ya da fikirlerinizi iletmek için dan@paradigm.xyz ve Dipnotlar

1. Bu yazıda, belirli bir bloğa hangi işlemlerin dahil edileceğini belirleyen aktöre veya sürece atıfta bulunmak için "teklif veren" kullanıyoruz. Ethereum L2'lerde bu rol tipik olarak bir "sıralayıcı" tarafından doldurulur. Ethereum L1'de, teklif sahibi adı verilen belirli bir Ethereum doğrulayıcı tarafından doldurulur, ancak genellikle teklif sahibi, bloğu oluşturma görevini "aktarıcıların" ve "inşaatçıların" katıldığı rekabetçi bir açık artırmaya yaptırır. Bu sorumlulukların nasıl bölündüğüne ilişkin ayrıntılar bu yazının kapsamı dışındadır. gas ↩
2. başına öncelik ücreti aslında işlemde açıkça belirtilmez, ancak içinde hesaplanabilir. İşlem bir gas fiyatı belirtir, ancak Ethereum ayrıca gas fiyatı çıkarılan ve yakılan bir taban ücret alır. Taban ücret, işlem yapan kişinin kontrolü altında olmadığı için MEV vergileri amacıyla göz ardı edilmelidir. gas başına öncelik ücreti — işlem ücretinin blok önerene giden kısmının fiyatı — Solidity'de priorityGasPrice = tx.gasprice - block.basefee olarak hesaplanabilir. ↩
3. Alternatif olarak, herhangi bir arama yapan kârını hariç tutmak ve yalnızca doğrulayıcıya gidecek değere atıfta bulunmak için basitçe "MEV" tanımlayabiliriz. ↩
4. İşlemin ne kadar gas kullanılacağını bilmenin bir yolu olmadığından, proposerPriorityFee'nin (işlemde kullanılan toplam gas priorityFeePerGas çarpımına eşit) sözleşme sırasında gerçekten hesaplanamayacağını unutmayın. Ancak, bu genellikle önemli olmayacaktır, çünkü ihtiyacımız olan tek şey bunun için bir üst sınırdır. Güvende olmak için, priorityFeePerGas'ı bir Ethereum bloğundaki mevcut maksimum gas olan 30 milyon ile çarpabilirsiniz. Bu değerin fazla tahmin edilmesi, MEV vergisinin daha da büyük bir MEV yüzdesini yakaladığı anlamına gelir. ↩
5. Bir işlemin 30 milyon gas'den fazla olamayacağını varsayarsak, 50.000'lik bir priorityFeePerGas, 1500 gwei'lik bir gas ödemeyle sonuçlanacaktır - ETH fiyatı 4000 ABD Doları olan yaklaşık 0,006 ABD Doları. ↩
6. priorityFeePerGas'ın arbitrajcı kârı sıfır olacak şekilde ayarlanması durumunda, kârı maksimize eden arbitraj işlemi, fonksiyon-maksimizasyon AMM üzerindeki aynı işleme karşılık gelmelidir. Bunu kanıtlamak okuyucu için bir alıştırma olarak bırakılmıştır. ↩
7. Arbitrum, bunu Timeboost adı verilen bir öncelik sıralaması biçimiyle değiştirmeyi tartıştı, ancak bu, bu yazı itibariyle üretime alınmadı. ↩

Yasal Uyarı:

1. Bu makale [paradigm] adresinden yeniden basılmıştır. Tüm telif hakları orijinal yazara aittir [Dan Robinson & Dave White]. Bu yeniden baskıya itirazlar varsa, lütfen Gate Learn ekibiyle iletişime geçin, derhal ilgileneceklerdir.

2. Sorumluluk Reddi: Bu makalede ifade edilen görüş ve görüşler yalnızca yazara aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.

3. Makalenin diğer dillere çevirileri Gate Learn ekibi tarafından yapılır. Bahsedilmediği sürece, tercüme edilen makalelerin kopyalanması, dağıtılması veya intihal edilmesi yasaktır.