Modüler MEV ile adil işlem sıralaması nasıl sağlanır?

Yazar: Maven11

Derleyen: Luffy, Öngörü Haberleri

Bu serinin ilk iki bölümünde, yığını bölerken ortaya çıkan teknik sorunlara ve modüler dünyada yapılması gereken iyileştirmelere odaklandık. Etki alanları arası kurulumlarda doğal olarak ortaya çıkan sorunları ele almak için bir dizi iş ilerlemesini ele aldık. Ancak serinin son bölümünde kullanıcı deneyimine daha fazla odaklanmak istiyoruz. Modülerleştirme, özelleştirme ve özelleştirmenin daha iyi uygulamalar oluşturmaya nasıl yardımcı olabileceğine bakmak istedik. Bu serinin son bölümü, geliştiricilerin Web3 doğrulanabilirliği ile Web2 kullanıcı deneyimleri oluşturmaları için modülerlikteki heyecan verici ve benzersiz yaratıcılığa ve olanaklara bakacaktır.

Modülerlik oluşturmanın arkasındaki neden, yalnızca anlatıya hitap etmek veya yalnızca modüler olmak değil, daha iyi, daha verimli ve daha özelleştirilebilir uygulamalar oluşturmamıza izin verdiği için olmalıdır. Modüler ve özel sistemler oluştururken, bir dizi benzersiz özellik ortaya çıkar. Bazıları açık, bazıları ise daha az belirgindir. Bu nedenle amacımız, modüler sistemin ölçeklenebilirlik gibi bilmediğiniz yeteneklerine genel bir bakış sağlamaktır.

Modülerliğin geliştiricilere sağladığı özelliklerden birinin, son kullanıcılar için daha iyi bir deneyim sağlayan son derece özelleştirilebilir, profesyonel uygulamalar oluşturma yeteneği olduğuna inanıyoruz. İşlemlerin gerçekleştirildiği sırayı kural koyma veya yeniden sıralama yeteneğinden daha önce bahsetmiştik.

Doğrulanabilir harmanlamalar (bundan böyle VSR'ler olarak anılacaktır), özellikle uygulama açısından "daha adil" ticaret sistemleri oluşturmak isteyen geliştiriciler için kontrollü sıralamanın sunduğu ilginç fırsatlardan biridir. Açıkçası, Likidite Sağlayıcı kayıpları ile yeniden dengeleme (LVR) arasındaki ilişki bu makalenin kapsamı dışındadır, bu nedenle buna çok fazla değinmekten kaçınacağız. Açıklayacağımız ayarların emir defteri modeli için değil, öncelikle AMM için olduğunu unutmayın. Ek olarak, CLOB (ve hatta CEX), kendi özel ayarlarına uyan doğrulanabilir harmanlamalardan yararlanmaktan da büyük fayda sağlayacaktır. Zincir dışı bir kurulumda, kriptoekonomik güvenlik tarafından desteklenen sıfır bilgi veya iyimser yürütme kavramına açık bir ihtiyaç vardır.

VSR, perakende yatırımcıların çoğunluğunun henüz bir koruma yaklaşımı benimsemediği (veya olası olmadığı) gerçeğini göz önünde bulundurduğumuzda özellikle ilginçtir. Çoğu Cüzdan/DEX ayrıca özel mempool'lar, RPC'ler veya benzer yöntemler uygulamaz. Çoğu işlem doğrudan ön uç aracılığıyla gönderilir (ister toplayıcı ister DEX ön ucu olsun). Sonuç olarak, uygulama süreçlerine ve siparişlerin işlenme şekline doğrudan müdahale etmediği sürece, son kullanıcı tatmin edici bir yürütmeden daha azıyla karşılaşabilir.

İşlem tedarik zincirinin nerede sipariş edildiğini düşündüğümüzde, VSR'nin rolü belirginleşiyor. Profesyonel katılımcıların, genellikle bir açık artırma veya taban ücrete dayalı olarak işlemleri sıraladığı (veya dahil ettiği) yerde oturur. Bu sıralama çok önemlidir çünkü hangi işlemlerin ne zaman gerçekleştirileceğini belirler. Esasen, tasnif yetkisine sahip olan kişi, genellikle öncelikli ücret (veya bahşiş) şeklinde MEV'i çıkarma yeteneğine sahiptir.

Sonuç olarak, son kullanıcıya daha adil bir ticaret uygulaması (bir DEX kurulumunda) sağlamak için sıralamanın nasıl ele alınacağına dair kurallar yazmak ilginç olabilir. Ancak, genel amaçlı bir ağ oluşturuyorsanız, bu tür kurallara uymaktan kaçınmaya çalışmalısınız.

Ayrıca Arbitraj, likidasyon vb. gibi önemli olan bazı MEV'ler de vardır. Fikirlerden biri, bloğun üst kısmında, özellikle daha yüksek ücretler ödeyen ve gelirin bir kısmını protokolle paylaşan İzin Verilenler Listesindeki Arbitrajcıları ve tasfiye memurlarını hedefleyen bir "otoyol" kanalı oluşturmaktır.

Matheus V., X. Ferreira ve David C. Parkes, "Doğrulanabilir Harmanlamalarla Güvenilir DEX Borsalarının Tasarımı" başlıklı makalede, bir bloğun sıralayıcısının harmanlamaları yürüten bir dizi kısıtlamaya tabi olduğu (ve bu kısıtlamaların doğrulanabilir olduğu) bir model önermektedir. Belirlenen kurallara bağlı kalmadan, gözlemci hatanın kanıtını oluşturabilir (veya kısıtlamalar matematiksel olarak doğrulanabilir olduğundan, bu kısıtlamalara sahip bir ZK devresi de hayal edebilirsiniz, bu da ZKP'yi geçerlilik kanıtı olarak kullanır). Ana fikir, esasen son kullanıcıya (tüccara) bir uygulama fiyatı garantisi sağlamaktır. Bu garanti, işlemin bloktaki tek işlem kadar iyi bir şekilde yürütülmesini sağlar (açıkçası, ilk gelene ilk hizmet esasına dayalı bir alım/satım/alım/satım emri varsayarsak, burada belirli bir gecikme söz konusudur). Makaledeki tekliflerin temel fikri, bloğun tepesinde bulunan fiyattan daha iyi bir fiyata performans gösterirlerse, bu harmanlamaların oluşturucuyu (bir PBS senaryosunda) veya sıralayıcıyı yalnızca aynı yöndeki işlemleri dahil etmekten (örneğin sat/sat) kısıtlayacağıdır. Buna ek olarak, bir dizi satın alma işleminin sonunda satış yaptığınız bir durum varsa, satış gerçekleştirilmeyecektir (örneğin, satın al, satın al, sat, bu da arama yapanların (veya inşaatçıların/sıralayıcıların) bu satın alımları fiyatı kendi lehlerine itmek için kullandıklarını gösterebilir. Bu, esasen, protokolün kurallarının, kullanıcıların başka birine daha iyi bir fiyat (yani MEV) sunmak veya öncelikli ücretler nedeniyle fiyatın düşmesine neden olmak için kullanılmayacağını garanti ettiği anlamına gelir. Açıkçası, buradaki kuralın kusuru (satın almaktan daha fazla satış yapılması durumunda ve bunun tersi de geçerlidir), nispeten düşük bir uzun kuyruk fiyatı alabilmenizdir.

Genel bir Akıllı Sözleşme platformu için, bu kuralları tamamen zincir üzerinde oluşturmak neredeyse imkansızdır çünkü yürütme ve sıralama üzerinde hiçbir kontrolünüz yoktur. Aynı zamanda, diğerleriyle rekabet ediyorsunuz, bu nedenle bloğun tepesindekileri öncelikli bir ücret ödemeye zorlamaya çalışmak gereksiz yere pahalı olacaktır. Modüler kurulumun özelliklerinden biri, uygulama geliştiricilerin yürütme ortamlarının nasıl davranması gerektiğini özelleştirmelerine izin vermesidir. Harmanlama, farklı bir sanal makine kullanma veya mevcut bir sanal makinede yeni bir İşlem Kodu ekleme veya gaz limitini değiştirme gibi özel değişiklikler yapma olsun, ürünlerine bağlı olarak bu gerçekten geliştiriciye bağlıdır.

Veri kullanılabilirliği, Konsensüs katmanları ve LiquiditySettlement katmanları kullanılarak yapılan bir toplama durumunda, olası ayarlar aşağıdaki gibidir:

Başka bir olası fikir, işlem bölmedir. Bir işlem havuzu hayal edin, büyük sipariş işlemlerinin nasıl yürütüleceğini (çok fazla kaymaya neden olur) ve bu işlem ardışık bloklar arasında (veya VSR uyumluysa bloğun sonunda) yürütülürse, bu son kullanıcı için adil midir?

Son kullanıcı gecikmeden endişe duyuyorsa, bu kullanıcı siparişinin bölünmesini istemeyebilir. Bununla birlikte, bu daha az yaygındır ve daha büyük siparişlerin ticaret bölünmesi için optimizasyon, kullanıcıların büyük çoğunluğu için daha verimli yürütme ile sonuçlanabilir. Her iki durumda da, endişelerden biri, MEV araştırmacılarının bu sıralı işlemlerden haberdar olabilmeleri ve işlemlerini söz konusu tüccarlardan önce veya sonra konumlandırmaya çalışabilmeleridir. Bununla birlikte, bir dizi blok üzerindeki küçük ölçekli bölme işlemleri nedeniyle, çıkarılan MEV'in toplam değeri çok daha küçük olabilir.

Yazıda daha önce bahsettiğimiz bir başka ilginç fikir de, efsanevi Eric Budish ve meslektaşları tarafından savunulan sık toplu müzayedeleri (FBA), işlemleri seri bir şekilde değil, toplu bir müzayede tarzında işlemek için kullanmaktır. Bu, çakışan talebin (CoW) belirlenmesine ve arbitraj fırsatlarının piyasa mekanizması tasarımına entegre edilmesine yardımcı olmak içindir. Bu aynı zamanda sürekli Blok yapılarında (veya seri Blokta öncelikli maliyet savaşlarında) ertelenmiş oyunlarla "savaşmaya" yardımcı olur. Bu makaleyi dikkatimize sunduğu ve Gecikme Kızartmasını azaltma konusundaki çalışmaları için Michael Jordan'a (DBA) teşekkür ederiz. Bunu Rollup'ın çatal seçimi ve harmanlamasının bir parçası olarak uygulamak da geliştiricilerin kullanabileceği ilginç bir kurulumdur ve geçen yıl özellikle Penumbra ve CoWSwap için önemli bir çekiş gördük. Olası bir kurulum şöyle görünür:

Bu kurulumda, ilk gelene ilk hizmet veya öncelikli gaz ücreti savaşı yoktur, bunun yerine kümülatif emirlere dayalı olarak her Blok arasındaki sürede toplu müzayedeyi sona erdirmek için bir Blok vardır.

Genel olarak, çoğu işlemin gözetimsiz bir "zincir üstü" dünyaya taşındığı yerlerde, FBA, blok süresine bağlı olarak "gerçek" fiyat keşfi için daha etkili yollardan biri olabilir. Amazon Lojistik'ten yararlanmak aynı zamanda tüm toplu siparişlerin toplu olduğu ve açık artırma sona erene kadar açıklanmayacağı için (bazı kripto kurulumları olduğu varsayılarak), önden çalışan işlemlerde önemli bir azalma olacağı anlamına gelir. İşlemleri yeniden sıralamanın bir anlamı olmadığı için uzlaşma fiyatları burada anahtardır.

2018'de, az önce ele aldığımız tasarımlar gibi tasarımların Ethresear.ch forumlarında tartışıldığını da belirtmek önemlidir (buraya bakın). Gönderide, her partinin belirli bir maksimum limit fiyattan ek ERC20 Token'ları satın almak için siparişleri kabul ettiği Plasma'da (biraz modern Rollup'ların bir prequel gibi) toplu bir açık artırma mekanizması sağlayan iki makaleden bahsediyorlar. Bu emirler belirli aralıklarla toplanır ve tüm Token işlem çiftleri için tek tip bir uzlaşma fiyatı sağlar. Bu modelin arkasındaki genel fikir, popüler AMM'lerde yaygın olan önden koşma olgusunu ortadan kaldırmaya yardımcı olacağıdır.

Unutulmaması gereken bir diğer önemli nokta da, bu kurulumlarda sıralayıcının yukarıdaki kuralları uygulamak (ve uygulamak) için bazı teşviklere ihtiyaç duyabileceğidir. Bu genellikle göz ardı edilir, ancak Blockchain ağının altyapısının çoğu, maliyeti ortalama bir ev katılımcısınınkinden oldukça farklı olan uzman şirketler tarafından yürütülür. Genel olarak, teşvikler güvenlik altyapısı uygulamasının önemli bir parçasıdır. Sıralayıcılar ve inşaatçılar, teşvikler uygulanan kurallarla uyumlu olduğunda daha fazla çaba gösterme olasılıkları daha yüksektir. Bu, bu kurulumların da aktif bir pazara sahip olması gerektiği anlamına gelir. Açıkçası, uzmanlaşma için sermaye maliyeti yüksek olabileceğinden, bu tür bir pazar daha merkezi hale geliyor. Sonuç olarak, Satoshi'nin (ve en zenginlerin) mümkün olduğunca fazla değer elde etmek için konsolide olması ve uzmanlaşması muhtemeldir. Burada, münhasırlık sırası akışı, bazı katılımcılar için diz üzerinde bir ok olabilir ve merkezileşmede bir artışa yol açabilir. Genel bir Benchmark ücreti yeterli olabilir, ancak sıralama katılımcılarını gerçekten uzmanlaşmaya itmez. Sonuç olarak, özel durumunuza göre uyarlanmış teşvikler aracılığıyla tüccarları sonuçlardan memnun eden bazı kavramlar sunmak isteyebilirsiniz.

Bu çoğu insan için açıktır, ancak Rollup seviyelerinin sıralamasını tartışırken yine de belirtilmesi gerekir. Sıralamayı kontrol edebilirseniz, protokolün değerini "çıkarmak" daha kolay olacaktır. Bunun nedeni, çoğu L1'de genellikle öncelikli ücretlere (MEV-boost-esque ayarları) dayanan işlemleri yeniden sıralama gücünü kontrol etmenizdir. Zincir üzerinde değer elde eden karmaşık katılımcılar tarafından ödenen öncelikli ücretler sağlar. Bu katılımcılar genellikle önemli miktarda ödemeye isteklidir (artık değer sağlayamayacak duruma gelene kadar). Bununla birlikte, mevcut toplamaların çoğu öncelikle ilk gelene ilk hizmet esasına göredir. MEV çıkarımlarının çoğu, Rollup altyapısı üzerinde ciddi bir yük oluşturan gecikmeli savaşlar yoluyla gerçekleştirilir. Yukarıdakilerin bir sonucu olarak, giderek daha fazla rollup'ın öncelikli ücretler kavramıyla (örneğin, Arbitrum'un zaman artırma mekanizması) bir sıralama yapısı uygulamaya başladığını görmemiz muhtemeldir.

Sevdiğimiz bir diğer örnek ise Uniswap. Şu anda, bir protokol olarak Uniswap birçok verimsizlik "yaratmaktadır". Bu verimsizlikler, MEV (Likidite Sağlayıcıları pahasına Arbitraj) çıkarmak isteyen katılımcılar tarafından istismar edilir. Aynı zamanda, bu katılımcılar değer elde etmek için çok fazla ücret öderler, ancak bu değerin hiçbiri Uniswap protokolünün veya Token sahiplerinin eline geçmez. Bunun yerine, çıkarılan bu değerin önemli bir kısmına, bir noktada değer yakalamaya izin veren bir bloğa dahil olma hakkını elde etmek için MEV-Boost aracılığıyla Ethereum teklif edenlere (doğrulayıcılara) bir öncelik ücreti ödenir. Sonuç olarak, Uniswap emir akışları için çok sayıda MEV fırsatı olsa da, bunların hiçbiri Uniswap tarafından yakalanmadı.

Uniswap, protokol içindeki sıralamayı kontrol edebiliyorsa (ve arama yapanlardan öncelikli ücretler alma yeteneği), ticarileştirilebilir ve hatta bu kârların bir kısmını Token sahiplerine, Likidite Sağlayıcılarına veya diğerlerine ödeyebilir. Uniswap'ta (örneğin UniswapX, vb.) yapılan değişikliklerin zincir dışı yürütmeye (ve bir yerleşim katmanı olarak Ethereum'a) geçmesiyle, bu mekanizma giderek daha olası görünüyor.

Kısmi PBS mekanizmasına sahip bir toplama olduğunu varsayarsak, sipariş akışı ve ticarileştirme süreci şöyle görünebilir:

Sonuç olarak, toplama sıralayıcılarının ve teklif sahiplerinin ticarileştirilmesi aşağıdaki formülü izleyebilir:

İhraç (PoS) + Ücret Geliri (+öncelikli) - DA, eyalet barı, depolama maliyeti

Şu anda Ethereum'da (özellikle Arbitraj) ne kadar değer çekildiğini görmenin iyi bir yolu, verimsizliklerden gerçekte ne kadar değer çıkarılabileceğine dair iyi bir genel bakış sağlayan Mevboost.pics'te bulunabilir.

Buna ek olarak, öncelikli ücret gaz savaşını zincir dışı yapıdan ayırmak, MEV çıkarımını yürütme ortamına izole ederek tedarik zinciri kesintilerinin kontrol altına alınmasına yardımcı olabilir. Bununla birlikte, lider seçimi Rollup'ta gerçekleşirse, MEV'nin çoğunluğunun Rollup'ta çekileceği göz önüne alındığında, DA katmanı dahil edilmedikçe, Uzlaşma katmanının öncelik ücretleri likidite konsolidasyonundan veya diğer ölçek ekonomilerinden gelmedikçe bu, temel yapı için çok az yer bırakır.

Açıklığa kavuşturmak gerekirse, bu yapıların çoğu, herhangi bir doğrulama köprüsüne veya güçlü güvenlik garantilerine ihtiyaç duymadan tamamen zincir dışı yapılar olarak işlev görebilir. Ancak, orada yapılması gereken bazı ödünleşimler var. Hem var olan hem de görünmez olan bu şeylerin daha fazlasının ortaya çıktığını görmeye başlıyoruz. Belirtmek istediğim bir şey, modülerliğin mutlaka rollup'lar anlamına gelmediğidir.

Yukarıdaki harmanlama, altyapıda ince ayar yapmanın, üzerine inşa edilen uygulamayı önemli ölçüde iyileştirebileceği bir örneği temsil eder.