Karanlık Ormanı Aydınlatmak: MEV'nin Gizemini Açığa Çıkarmak

Artan zincir üzerindeki etkinlikler ve zincir üzerindeki altyapının evrimi ve zenginleşmesi ile birlikte, zincir üzerindeki MEV her zaman Ethereum'un karanlık ormanındaki en tehlikeli kısımlardan biri olarak görülmüştür. Bu durum, kullanıcıların zincir üzerindeki finansal etkinlikleri üzerinde doğrudan kar kaybı ve kullanıcı deneyiminin düşmesi gibi olumsuz etkiler yaratmıştır. Bu makalenin başlığı olan "Karanlık Ormanı Aydınlatmak" ise Ethereum 2.0'ın blok oluşturma mekanizması ve önerici-oluşturucu ayrımı olan (PBS) teknolojik evrimi temel alınarak, bu mekanizmanın getirdiği doğal merkezileşme ve güven sorunlarını Ethereum'un değerleri ile tam zıt bir gerçeklik durumu olarak kapsamlı bir şekilde analiz etmeyi amaçlamaktadır.

Zincir üzerindeki MEV'nin artışı gerçekten çift taraflı bir kılıçtır, hem olumlu hem de olumsuz dışsallıkları vardır. Olumlu olanlar arasında DEX fiyat farklarını azaltmak ve likidasyon işlemlerine yardımcı olmak; olumsuz olanlar ise kullanıcıların sandviç ticareti zararına yol açmaktadır. Bu nedenle, MEV'nin çözüm önerileri daha çok olumsuz dışsallıkları azaltmaya yönelik olup, ortadan kaldırmayı başaramamaktadır. MEV'nin olumsuz dışsallıklarını hafifletme ve mevcut üçüncü taraf güvene dayalı ara katman Relayer sorununu çözme mekanizmaları üzerindeki keşif sürecimiz, esasen üç tür önlem olarak 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ı ölçülerde etkileyecektir, ancak bazı çözüm önerileri kullanıcıların karşılaştığı sandviç saldırısı sorununu önemli ölçüde çözmemektedir. Kullanıcı işlemleri hala public pool’da olduğundan, kullanıcı işlemlerinin isteğe bağlı gizliliğini korumak için daha fazla gizlilik havuzu teknolojisinin devreye alınması gerekmektedir; bu MEV çözümleri birlikte bir araya getirilip denenmeye değer.

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

Son olarak, bu makale ile MEV'nin olumsuz dışsallık sorununu hafifletmek için potansiyel çözümleri keşfetmeyi ve mevcut MEV çözümlerinin avantajları ve dezavantajları hakkında kapsamlı bir anlayış sağlamayı umuyoruz. Bu yalnızca 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 fazla araştırmaları için karanlık ormanı aydınlatmak içindir.

Ethereum 2.0

The Merge'den bu yana, Ethereum ağı güvenliğini sağlamak için POS mekanizmasını benimsemiştir. Aynı zamanda blok üretimi açısından, hesaplama yoğun rekabetten vazgeçmiş ve bunun yerine hisse kanıtını kullanmıştır. Birleşmeden sonra, Ethereum, yürütme katmanı ve konsensüs katmanına ayrılmıştır. Tüm blok üretimi de değişmiştir; her bir Epoch bir POS döngüsüdür ve her Epoch, 12 saniyelik bir blok üretim zaman birimine eşdeğer olan 32 Slot'a ayrılmıştır.

Ağ, her Epoch'ta doğrulayıcılardan rastgele bir komite seçer, blok önericisi bu komite setinden rastgele seçilir, blok önericisinin işlemleri paketlemesi ve sıralayıp son olarak bir blok üretmesi gerekir, diğer komite doğrulayıcıları bu süreci denetler ve ardından bu blok için oy kullanırlar. Ayrıca bu komite her Epoch'tan sonra yeniden seçilir. Aynı zamanda blok üretimi ve oylama verimliliğini sağlamak için belirli bir işlem zaman sınırlaması uygulanır. Burada okuyucular için terimleri standart hale getiriyoruz, Payload yürütme yükü anlamına gelir, yani işlemlerin durum değişiklikleri, blok yürütmesinin 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, doğrulayıcılar blok önericisi olarak seçildiğinde, genellikle önericinin Payload'u yerine getirme motivasyonu yoktur; yani işlemleri sıralayıp yürütmek, çünkü bu durum durum değişikliklerini gerçekleştirmek için büyük miktarda hesaplama gücü gerektirir. Aslında düşündüğümüz şey, eğer merkeziyetsiz bir komite seçimi ile yürütme yükünü dahil edersek, o zaman işlem sıralama vb. merkeziyetsiz bir hale gelecektir. 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 fikri ortaya çıktı; yani blok önerimi ve inşasını ayırarak, önericilerin yalnızca blokları doğrulamakla sorumlu olduğu ve blok inşasına katılmadığı bir yapı. Önericiler ile inşacılar arasındaki ayrım açık bir pazar oluşturur; bu pazarda blok önericileri, blok inşacılarından blok alabilirler. Bu inşacılar, blokları inşa etme konusunda birbirleriyle rekabet eder ve önericilere en yüksek ücreti sunar; buna "blok açık artırması" diyoruz.

PBS( Proposer Builder Seperate) mühürlü ilk ihale modeli hakkında kısaca bilgi verelim. Kullanıcılar, RPC aracıyla işlem gönderdiğinde, RPC bir düğüm çalıştırmış gibi olur ve işlemi kamu Mempool'una gönderir. Birden fazla Builder, en uygun işlemi sıralamak için buluşarak maksimum kâr elde eden bir blok oluşturur. ( maksimum kâr, işlem ücretleri Base + Priority + MEV) anlamına gelir. Ardından, birden fazla Builder, MEV-Boost Relayer aracılığıyla Proposer ile etkileşime girer. Relayer, birden fazla Builder ile Proposer arasındaki etkileşim köprüsüdür. Builder, Relayer'a teklif sunar ve Relayer, Proposer'a birden fazla blok başlığı ve karşılık gelen teklifi gönderir. Proposer genellikle en yüksek teklifi kabul eder. Bu süreçte, Relayer MEVBboost standartlarını uygular; bu, Flashbot'un Builder ile Proposer arasındaki etkileşimi nasıl standartlaştıracağına dair bir teknik düzenlemedir. Bu süreçte, tüm bilgiler kapalıdır; Relayer yalnızca blok başlıklarını Proposer'a gönderir, bu nedenle Proposer, sansüre karşı dayanıklıdır.

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

Ana katılımcıları Builder, Relayer, Proposer, MEVbot(Searcher)'dır.

Builder

Builder, blok içeriğini inşa etmekle sorumlu olan kişidir. MEV-Boost teknolojisi kullanıldığında, tekliflerde daha avantajlı bir konumda olur çünkü yalnızca Gas Fees'i desteklemekle kalmaz, aynı zamanda MEV kazançlarını da destekler. Builder, kullanıcıların ve Searcher'ın işlemlerini doğrudan inceleyebilir; bu, özellikle ABD hükümeti OFAC'ı açıkladıktan sonra eleştirilen bir noktadır. OFAC uyumlu bir şekilde birçok Builder katıldı. Başlangıçta olduğu gibi, blokların incelenme oranı son zamanlarda azalmış olsa da, blok inşa sürecinde Builder'ın işlemlere doğrudan inceleme yapma konusunda etkisinin olduğunu görebiliyoruz.

Günümüzde Builder'ın pazar payına bakıldığında, tamamen denetimsiz bir Build, pazar payını yavaş yavaş genişletiyor, her şey kâr odaklı.

Arayıcı

Temelde, kâr maksimize etme çalışması, Searcher ile Builder'ın birlikte çaba göstermesini gerektirir. Searcher genellikle belirli bir Builder ile işbirliği yapar, bu da bir Dark Pool veya Private Pool oluşturur; burada Searcher'ın işlemleri sadece belirli Builder'a gösterilir. Bazı Builder'lar, maksimum kâr elde eden MEV işlemleri alır ve böylece blok alanı için teklif verirler. Teorik olarak, eğer Builder kötü niyetli davranır veya sansür uygularsa, Searcher diğer Builder'ları seçebilir, bu da Builder'ın pazar payının kademeli olarak azalmasına neden olur. Bu nedenle, Searcher tarafından kısıtlandıkları için, Builder genellikle kötü niyetli davranmanın gizli maliyetlerini dikkate alır. Yukarıdaki grafik, MEV ve günlük Gas gelirlerini göstermektedir; burada, Searcher'ın katkıda bulunduğu MEV gelirlerinin, piyasa dalgalanmalarının belirgin olduğu durumlarda, hatta günlük Gas gelirinin iki katına kadar çıkabildiği görülebilir.

Searcher için, CEX-DEX( zincir dışı ) arbitrajı ve DEX, katman arası, likidasyon olmak üzere iki ana kategori ( tamamen zincir içi ).

Şu anda bir ticaret platformu CEX --- DEX arbitraj ticareti pazar payında birinci sırada.

Saf zincir üzerindeki MEV fırsatları için, stüdyolaşma eğilimi giderek artmaktadır. Bu stüdyolardan biri, pazar payının şaşırtıcı bir şekilde %37,2'sini elinde tutmakta olup, Etheruem zincirindeki kullanıcılara karşı sandviç saldırıları gerçekleştirmekte, bir dönem zincir üzerindeki en yüksek gaz tüketen kullanıcı haline gelmiştir ve yaklaşık gaz tüketimi, bir günün %1,5'ini kapsamaktadır. 2023 Şubat'ından 2024 Haziran'ına kadar bu robot toplamda 76,916 ETH harcamıştır ve bu işlemlerin gerçekleştirilmesindeki değer hesaplandığında, yaklaşık 175 milyon dolara eşdeğerdir. Seacher ve Builder arasındaki sıkı bağlantı nedeniyle, pratikte birçok Seacher, kendi emir akışlarını ilk üç Builder'a göndermektedir; aslında tüm Builder'lara yayınlanabilirdi ama bazı küçük Builderlar, Seacher'ın emir akışını bölerek, Seacher'ın MEV stratejisinin başarısız olmasına ve dolayısıyla zarar riski yaratmasına neden olabilir. Ayrıca, Builder'la bağlanmak, ekosistem içinde etki sağlamasına yardımcı olabilir.

Relayer

Relayer, birleşik açık artırmayı toplamakla sorumludur ve ardından Proposer'a blok başlıklarını ve açık artırma bloklarının fiyatlarını iletmek için bir geçiş noktası olarak hareket eder. Bu aşamada 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. Gördüğümüz gibi, Relayer, ekonomik bir teşviğe sahip olmayan bir üçüncü taraf olarak büyük bir güven kazanmıştır; Builder, Proposer'a teklif vermekte, Proposer ise Relayer'ın teklifine ve blok içeriğine güvenmektedir. Tarihte benzer sorunlar yaşanmıştır; bir Relayer'da potansiyel bir açık bulunmuş ve bu, Proposer'ın 20 milyon dolardan fazla MEV çekmesine neden olmuştur. Bu açıklar kapatılabilir, ancak Relayer kendisi hala kötü niyetli davranmayı seçebilir ve MEV'yi çalabilir.

Yukarıdaki grafik, Relayer'ın pazar payı durumunu göstermektedir. Merge'den sonra, yalnızca MAX Profit oluşturan Builder'ın pazar payının giderek arttığını göreceğiz. Bu nedenle serbest piyasada, Builder aracılığıyla MEV'yi insan müdahalesi ile kontrol etmenin imkânı yoktur.

Aynı zamanda Relayer, ekonomik teşviklerin olmaması gibi bir sorunla da karşı karşıya. Bu nedenle bir şirket, Relayer yönündeki Ar-Ge çalışmalarından da çekildi. Relayer şu anda, Flashbots'un MEVBoost standardını geliştirmesine dayanarak inşa ediliyor, Ethereum üçüncü taraflara PBS sağlamaya bağımlı olmakla birlikte, bu kalıcı bir çözüm değil. Bu nedenle, şu anda Ethereum topluluğu PBS'yi protokol seviyesine entegre etme konusunda da araştırmalar yapıyor.

Teklif Sahibi

Proposer için, tüm doğrulayıcılar arasında bir algoritma ile rastgele bir komite grubu seçmek, her slotta bir blok önericisi seçmek gerekiyor. Blok önericisi, yükü yerine getirme yeteneğine sahipken, önericinin bu kısmı dışarıya devretmek istemesi nedeniyle, Builder ile Proposer arasında dikey işbirlikleri oluşması kolaylaşmaktadır. MEV-boost'un Relayer'ı, bu tür bir yöntemin ara noktası olarak hizmet vermek ve iki tarafın doğrudan iletişiminden kaynaklanan dikey işbirliği anlaşmalarını azaltmak istemektedir. Şu anda, doğrulayıcı havuzu olarak madencilik havuzları bulunuyor, ancak bu tür madencilik havuzları ve LSD doğrulayıcı havuzları, özellikle LSD'nin ortaya çıkmasıyla birlikte, oldukça güçlü bir ölçek etkisine sahiptir. Bu durum, önceki stake edilmiş tokenlerin potansiyelini serbest bırakmakta, sermaye verimliliğini artırmakta ve arkasındaki DEFI yapı taşlarının etkisiyle, doğrulayıcı havuzu daha merkezi bir eğilim içerisinde bulunmaktadır.

Bir LSD platformu şu anda yaklaşık %28.7 pazar payına sahip, bir ticaret platformu ve bir diğer LSD platformu ise ikinci ve üçüncü sıradadır. Geçmişte MEV-BOOST PBS çözümünü aktif olarak uygulamadığında, Proposer Builder'ın görevlerinden sorumlu olmak zorundaydı, yani yük (Payload)'ı yerine getirmek zorundaydı. Ancak çoğu Proposer, işlem sıralama yürütme yeteneklerinden vazgeçti, çünkü bu yoğun hesaplama işi doğrulama performansını ciddi şekilde etkileyebilir; bu nedenle yükü dışarıdan almak ve üçüncü tarafların blokları açık artırmaya çıkarmasına izin vermek daha iyidir.

Kullanıcı

Son olarak, Kullanıcıdan bahsedelim. Kullanıcılar genellikle tüm mimari tasarımda en zayıf taraf olarak yer alırlar, çünkü kullanıcıların işlemleri Mempool'a konulmakta ve çeşitli MEVbotlar tarafından MEV karı elde etmek için kullanılmaktadır, ancak bu karlar kullanıcıya akmaz. Ancak bu her zaman kötü bir durum değildir; örneğin DEX'te, zincir üzerindeki fiyat dalgalanmaları büyük olduğunda veya kullanıcının işlem hacmi DEX'in likiditesinden fazla olduğunda, MEVbotlar kayıpları azaltmak ve çeşitli platformlardaki fiyat farklarını hafifletmek için arbitraj yapabilirler. Bu nedenle, MEV'nin varlığı pozitif ve negatif dışsallıklara sahiptir, bu nedenle ayrı ayrı tartışılması gerekmektedir ve bu da onun karmaşıklığıdır.

Kullanıcıların MEVbot tarafından izlenmesini önlemek için, bu da kullanıcıya zarar verebilir.