Karanlık Ormanı Aydınlatmak: MEV'in Gizemini Ortaya Çıkarmak

Artan zincir içi faaliyetler ve zincir içi altyapının evrimi ve zenginleşmesiyle birlikte, zincir içi MEV her zaman Ethereum'un karanlık ormanındaki en tehlikeli kısım olarak görülmüştür; bu durum doğrudan kullanıcıların zincir içi finansal faaliyetlerinde kâr kaybına ve kullanıcı deneyiminin kötüleşmesine yol açmıştır. Bu makale "Karanlık Ormanı Aydınlatmak" başlığı altında, Ethereum 2.0'ın blok üretim mekanizması ve önerici-yapıcı ayrımı (PBS) üzerine teknik evrimi temel alarak, bu mekanizmanın getirdiği doğal merkezileşme ve güven sorunlarını Ethereum'un değerleriyle tamamen zıt bir gerçeklik olarak vurgulamayı amaçlamaktadır.

Zincir üstü MEV'nin artışı gerçekten de iki ucu keskin bir kılıçtır; hem olumlu hem de olumsuz dışsallıkları vardır. Olumlu yanları arasında DEX fiyat farklarını azaltma ve likidite sağlama yer alırken; olumsuz yanları arasında kullanıcıların sandviç ticareti zarar görmesi bulunmaktadır. Bu nedenle, MEV çözümleri daha çok olumsuz dışsallıkları hafifletmeye yöneliktir ve ortadan kaldıramaz. MEV'nin olumsuz dışsallıklarını hafifletme ve mevcut üçüncü taraf güvene dayalı ara yazılım Relayer sorununu çözme mekanizması keşif sürecimiz üç ana önlem sınıfına ayrılmaktadır: ihale mekanizmasının iyileştirilmesi, konsensüs katmanının iyileştirilmesi ve uygulama katmanının iyileştirilmesi. Bu üç iyileştirme, MEV'nin modern yapısını farklı derecelerde etkileyecek, ancak bazı çözümler kullanıcıların karşılaştığı sandviç saldırısı sorununu esasen çözmemektedir; kullanıcı işlemleri hala public pool'da kalmaktadır. Bu nedenle, kullanıcı işlemlerinin isteğe bağlı gizliliğini korumak için daha fazla gizlilik havuz teknolojisinin devreye sokulması gerekmektedir. Bu MEV çözümlerinin birlikte denenmeye değer olduğu görülmektedir.

Bunun dışında, MEV kaçınılmaz bir mekanizma tasarımı yan ürünü olarak, gelecekte daha da karmaşık hale gelecektir. Biz de makalede Layer2 mimarisi, EIP-4337 hesap soyutlaması gibi yeni işlem türlerinin uygulanmasıyla ortaya çıkabilecek daha fazla MEV teknik zorlukları ve fırsatlarını keşfettik.

Son olarak, bu makaleyle, MEV negatif dışsallık sorununu hafifletmenin potansiyel çözümlerini keşfetmeyi ve mevcut MEV çözümlerinin artılarını ve eksilerini kapsamlı bir şekilde anlamayı umuyoruz. Bu sadece gelecekte kullanıcıların bulunduğu karanlık ormanı aydınlatmak için değil, aynı zamanda sektördeki araştırmacılara MEV'yi daha ileri düzeyde araştırmaları için karanlık ormanı aydınlatmak içindir.

Ethereum 2.0

The Merge'den beri, Ethereum ağın güvenliğini sağlamak için POS mekanizmasını benimsedi ve blok üretiminde hesaplama yoğun rekabeti bırakarak, hisse kanıtına yöneldi. Birleşmeden sonra, Ethereum yürütme katmanı ve konsensüs katmanı olarak ikiye ayrıldı. Ayrıca, tüm blok üretimi de değişti; her Epoch bir POS döngüsüdür ve her Epoch 32 Slot'a bölünmüştür. Her Slot, bir blok oluşturma zaman birimi olan 12 saniyeye eşittir.

Validator öneri blok diyagramı

Tüm ağ, her Epoch'ta doğrulayıcılardan rastgele bir komite seçecek, blok öneren kişi bu komite üyeleri arasından rastgele seçilecektir. Bu blok önericisi, işlemleri paketleyip sıralayarak nihayetinde bir blok üretmek zorundadır; diğer komite doğrulayıcıları bu süreci denetleyecek ve ardından bu blok için oy vereceklerdir. Ayrıca bu komite, her Epoch'tan sonra yeniden seçilecektir. Blok üretim ve oylama verimliliğini sağlamak için belirli bir işlem zaman kısıtlaması uygulanmaktadır. Burada okuyucular için terimleri standardize ediyoruz; Payload, yürütme yükü anlamına gelir ve işlemlerin durum değişikliklerini ifade eder, bir bloğun yürütülmesinin bir parçası olarak görülebilir. Blok önericisi, yürütme yükü ( Execution Payload'ı uygulayacak yani işlem sonuçlarının durum değişikliklerini ) ve blok önerisini gerçekleştirecektir.

PBS Mimarisi

Aslında, bir doğrulayıcı blok önericisi olarak seçildiğinde, genellikle önericinin Payload'u, yani işlemleri sıralayıp yürütme konusunda bir motivasyonu yoktur, çünkü bu durum durum değişikliklerini yürütmek için büyük miktarda hesaplama gücü gerektirir. Aslında, eğer merkeziyetsiz bir komite seçimi ile yükü yürütmeye dahil edersek, o zaman işlemlerin sıralanması gibi şeyler merkeziyetsiz bir hale gelecekti. Ancak doğrulayıcılar doğal olarak bu kısmı üçüncü taraflara devretmek istiyor gibi görünüyor, ve kendileri Proposer olarak blok önermeye odaklanıyorlar. Bu nedenle, PBS'nin konsepti ortaya çıktı; blok önerimini ve inşasını ayırarak, önericilerin yalnızca blokları doğrulamakla sorumlu olduğu, blok inşasına katılmadığı bir yapı oluşturuldu. Önericiler ve inşacılar arasındaki ayrım, blok önericilerin blok inşacılardan blok alabileceği açık bir pazarın gelişimini teşvik etti. Bu inşacılar birbirleriyle blok inşa etme konusunda rekabet ederler ve önericilere en yüksek ücreti sunarlar, buna "blok müzayedesi" diyoruz.

PBS akış diyagramı

PBS( Proposer Builder Seperate) mühürlü ilk ihale modelini kısaca tanıtalım. Kullanıcılar, RPC aracılığıyla işlem gönderdiklerinde, RPC bir düğüm çalıştırmış gibi davranır ve işlemi kamu Mempool'una gönderir, birden fazla Builder en uygun işlemleri bulup sıralayarak karı maksimize eden bir blok oluşturur(, karı maksimize etme, işlem ücretleri Base+Priority+MEV) ile ilgilidir. Ardından, birden fazla Builder, belirli bir ticaret platformu Relayer aracılığıyla Proposer ile etkileşime geçer; Relayer, birden fazla Builder ile Proposer arasındaki etkileşimin köprüsüdür. Builder, Relayer'a teklif sunar, Relayer Proposer'a birden fazla blok başlığı ve ilgili teklifleri gönderir; Proposer genellikle en yüksek teklifi kabul eder. Relayer, Builder ile Proposer arasındaki etkileşim ve ihale için kuralların nasıl belirleneceğini belirleyen bir standart uygular. Bu süreçte, tüm bilgiler kapalıdır; Relayer yalnızca blok başlıklarını Proposer'a sunar, bu nedenle Proposer sansüre karşı dayanıklıdır.

PBS altında çeşitli katılımcılar ve oyun

Başlıca katılımcılar Builder, Relayer, Proposer, arayıcı (Searcher).

Yaratıcı

Builder, blok içeriğini oluşturmakla sorumlu olan bir bileşendir. İlgili teknolojileri kullandıktan sonra, ihale süreçlerinde daha avantajlı bir konumda bulunmaktadır, çünkü sadece Gas Fees'i değil, aynı zamanda MEV kazançlarını da desteklemektedir. Builder, kullanıcıların ve arayıcıların işlemlerini doğrudan inceleyebilme yeteneğine sahiptir, bu da her zaman eleştirilen bir nokta olmuştur, özellikle ABD hükümeti OFAC'ı açıkladıktan sonra, birçok Builder OFAC Uyumlu projelerine katılmıştır. Başlangıçta olduğu gibi, son günlerde blok inceleme oranı azalmış olsa da, blok oluşturma sürecinde Builder'ın işlemlerin doğrudan denetimi üzerinde doğrudan bir etkisi olduğunu görebiliyoruz.

OFAC uyumlu blok oranı, kaynak: MEV Watch

Builder pazar payı, kaynak: MEV Watch

Mevcut Builder pazar payına bakıldığında, bazı tamamen denetimsiz Build'lerin pazar paylarını kademeli olarak artırdığı görülüyor, her şey kâr odaklı.

arama motoru

MEV kazancı ile Gas Fees kazancı oranı, kaynak: mevboost

Temelde, kâr maksimize etme görevi, arayıcılar ile Builderların birlikte çalışmasını gerektirir. Arayıcılar genellikle belirli Builderlarla işbirliği yapar, böylece bir Dark Pool veya Private Pool oluşur. Bu ortamda, arayıcıların işlemleri yalnızca belirli Builderlar için görünür hale gelir; bazı Builderlar maksimum kâr elde eden MEV işlemlerini alır ve böylece blok alanı için teklif verirler. Teorik olarak, eğer Builder kötü niyetliyse veya sansür uyguluyorsa, arayıcılar diğer Builderları seçebilir. Bu durum, Builderların pazar payının aşamalı olarak azalmasına yol açar. Bu nedenle, arayıcılara bağımlı olan Builderlar, kötü niyetin gizli maliyetlerini genellikle dikkate alırlar. Yukarıdaki resim, MEV ve günlük Gas gelirlerinin durumunu göstermektedir; arayıcıların katkıda bulunduğu MEV gelirlerinin, piyasa dalgalanmalarının belirgin olduğu durumlarda, günlük Gas gelirinin iki katına kadar çıkabildiğini görebiliyoruz.

Arama motorları için, CEX-DEX( dışındaki ) arbitraj ve DEX, ara katman, likidasyon olmak üzere iki ana kategoriye ayrılır ( tamamen zincir üstü ).

Arama motoru pazar payı, görsel kaynağı: Searcherbuilder

Şu anda bir şirket, CEX --- DEX arbitraj ticaretinin pazar payında birinci sırada.

Arama motoru pazar payı, kaynak: Searcherbuilder

Saf zincir üzerinde MEV fırsatları için, stüdyolaşma eğilimi yavaş yavaş oluşuyor, bu süreçte belirli bir adresin pazar payı şaşırtıcı bir şekilde %37.2'ye ulaştı; bu adres, Ethereum zincirindeki kullanıcılar üzerinde sandviç saldırıları yapma konusunda uzmanlaşmış ve bir dönem zincir üzerindeki en yüksek gas tüketen kullanıcı haline gelmiştir, günlük gas tüketimi yaklaşık %1.5'lik bir oran oluşturmaktadır. 2023 Şubat'tan 2024 Haziran'a kadar, bu robot toplamda 76,916 ETH harcamıştır; bu işlemlerin gerçekleştirildiği değer üzerinden hesaplandığında, yaklaşık 175 milyon dolara eşdeğerdir. Arama motorları ile Builder'lar arasındaki sıkı bağlantılar nedeniyle pratikte, birçok arama motoru kendi sipariş akışlarını ilk üç Builder'a göndermektedir; aslında tüm Builder'lara yayın yapmaları mümkündür, ancak bazı küçük Builder'lar arama motorunun sipariş akışını bölebilir, bu da arama motorunun MEV stratejisinin etkisiz hale gelmesine ve dolayısıyla zarar etme riskine yol açabilir. Ayrıca, Builder'lara bağlanmak, onların ekosistem içindeki etkilerini sürdürmelerine de yardımcı olabilir.

Relayer

Relay pazar payı, kaynak: mevboost

Relayer, birleşik müzayede için sorumludur ve ardından Proposer'a blok başlıklarını ve müzayededeki blok fiyatlarını bir ara istasyon olarak sunar, bu esnada Proposer bloktaki işlem detaylarını bilmemektedir. Proposer blok başlığını seçip imzaladıktan sonra, Relayer tüm işlem içeriğini Proposer'a serbest bırakır. Burada, Relayer'ın ekonomik bir teşviki olmadan büyük bir güven kazandığını göreceğiz; Builder, Proposer'dan teklif alırken, Proposer ise Relayer'ın teklifine ve blok içeriğine güvenmektedir. Tarihte benzer sorunlar yaşanmıştır; bir Relayer, Proposer'ın 20 milyon dolardan fazla MEV çekmesine neden olan bir potansiyel güvenlik açığına sahip olmuştur. Bu tür güvenlik açıkları düzeltilebilirken, Relayer kendisi kötü niyetli davranmayı ve MEV'yi çalmayı seçebilir.

Pazar payı trend grafiği, kaynak: mevboost

Yukarıdaki resim, Relayer'ın pazar payı durumunu göstermektedir. MAX Profit'i yalnızca çalıştıran Builder'ın pazar payının Merge'den sonra kademeli olarak genişlediğini göreceğiz. Bu nedenle serbest piyasada, Builder aracılığıyla MEV'yi yapay olarak kontrol etmek mümkün değildir.

Aynı zamanda Relayer, ekonomik bir teşvik olmaması gibi bir sorunla karşı karşıya. Bu nedenle, bir şirket de Relayer yönündeki araştırma geliştirmeden çekildi. Relayer şu anda önerilen standartlara dayanarak inşa ediliyor, Ethereum üçüncü tarafların PBS sağlamasına bağımlı, bu da her zaman kalıcı bir çözüm değil, bu nedenle şu anda Ethereum topluluğu PBS'yi protokol seviyesine dahil etme yolunu araştırıyor.

Teklif Sahibi

Proposer için, tüm doğrulayıcılar arasında bir algoritma ile rastgele bir komite grubu seçmek ve her slotta bir blok önericisi seçmek söz konusudur. Blok önericisi, yükü yerine getirme kapasitesine sahiptir; ancak önericinin bu kısmı dış kaynak kullanmak istemesi nedeniyle, Builder ile Proposer arasında dikey bir işbirliği oluşması kolaydır. İlgili Relayer, bu tür bir aracı olarak hareket etmek isteyerek, iki taraf arasındaki doğrudan iletişimden kaynaklanan dikey işbirliği komplolarını azaltmayı ummaktadır. Şu anda, doğrulayıcı havuzu olarak madenci havuzları bulunmakta; ancak bu madenci havuzları ve LSD doğrulayıcı havuzları, özellikle LSD'nin ortaya çıkmasıyla, son derece güçlü bir ölçek etkisine sahiptir. Bu durum, aslen stake edilmiş tokenların potansiyelini serbest bırakmakta, sermaye verimliliğini artırmakta ve arkasındaki DEFI yapı taşlarının etkisiyle, doğrulayıcı havuzunun daha merkezi bir eğilim içinde olmasına yol açmaktadır.

Doğrulayıcı piyasa payı, görsel kaynak: mevboost

Bir proje şu anda yaklaşık %28,7 pazar payına sahip ve diğer borsalar ikinci ve üçüncü sırada yer alıyor. Geçmişte aktif olarak katılmadı.