Karanlık Ormanı Aydınlatmak: MEV'nin Gizem Perdesini Aralamak

Artan zincir üzerindeki aktiviteler 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 faaliyetlerine doğrudan kâr kaybı ve kullanıcı deneyiminin düşmesi gibi olumsuz etkiler yapmaktadır. Bu makalenin başlığı "Karanlık Ormanı Aydınlatmak", Ethereum 2.0'ın blok üretim mekanizması ve önerici-yapıcı ayrımı (PBS) üzerindeki teknik evrime dayanarak, bu mekanizmanın getirdiği doğal merkezileşme ve güven sorunlarını Ethereum'un değerleriyle tam zıt bir gerçeklik olarak analiz etmeyi amaçlamaktadır.

Zincir üzerindeki MEV'nin artışı gerçekten de bir çift taraflı kılıçtır; hem olumlu hem de olumsuz dışsal etkilere sahiptir. Olumlu etkiler arasında DEX fiyat farklılıklarını azaltmak ve likidasyon işlemlerine yardımcı olmak bulunurken; olumsuz etkiler arasında kullanıcıların sandwich ticareti zarar görmektedir. Bu nedenle, MEV çözümleri daha çok olumsuz dışsal etkileri azaltmaya yönelik olup, kökten ortadan kaldırma imkanı yoktur. MEV'nin olumsuz dışsal etkilerini azaltma ve mevcut üçüncü taraf güvenine dayalı ara katman sorunlarını çözme mekanizmalarını araştırma sürecimiz üç ana önlem kategorisine 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ı üzerinde farklı derecelerde etki yaratacaktır; ancak bazı çözümler, kullanıcıların karşılaştığı sandwich saldırısı sorununu etkili bir şekilde çözemez. Kullanıcı işlemleri hala kamu havuzunda olduğundan, kullanıcı işlemlerinin isteğe bağlı gizliliğini korumak için daha fazla gizlilik havuzu tekniğinin uygulanması gerekmektedir. Bu MEV çözümleri bir araya getirilip denenmeye değer.

Bunun yanı sıra, MEV kaçınılmaz bir mekanizma tasarımı yan ürünü olarak, gelecekte daha da karmaşık hale gelecektir. Biz de yazıda 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ı araştırdık.

Son olarak, bu makale ile 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, yalnızca gelecekte kullanıcıların bulunduğu karanlık ormanı aydınlatmak için değil, aynı zamanda sektör araştırmacılarına MEV'yi daha fazla araştırmaları için karanlık ormanı aydınlatmak amacıyla.

Ethereum 2.0

The Merge'den bu yana, Ethereum, ağın güvenliğini sağlamak için POS mekanizmasını benimsedi ve blok üretimi açısından hesap yoğun rekabetten vazgeçerek hisse kanıtı yöntemine geçti. Birleştikten sonra, Ethereum yürütme katmanı ve konsensüs katmanı olarak ikiye ayrıldı. Tüm blok üretimi de değişti, her bir Epoch bir POS döngüsüdür ve her Epoch, 32 Slot'a ayrılmıştır; her Slot, bir blok oluşturma zaman birimi olarak 12 saniyeye eşittir.

Tüm ağ, her Epoch'ta doğrulayıcılardan rastgele bir komite seçecek, blok önermeyi yapan kişi komite grubundan rastgele seçilecek, bu blok önericisi işlemleri paketleyip sıralayıp 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 üretimi ve oylama verimliliğini sağlamak için belirli bir işlem süresi kısıtlaması da uygulanmaktadır. Burada, okuyucular için terimleri düzenliyoruz, Payload, işlem yüklemesi anlamına gelir, yani işlemlerin durum değişiklikleri, blokların bir parçası olarak değerlendirilebilir. Blok önericisi, işlem yüklemesi ( Execution Payload'ı uygulayacak, yani işlem sonuçlarının durum değişikliklerini ) ve blok önerisini gerçekleştirecektir.

PBS mimarisi

Gerçekten de, doğrulayıcılar blok önericisi olarak seçildiğinde, genellikle önericinin Payload'u yürütme konusunda bir motivasyonu yoktur; yani işlemleri sıralamak ve yürütmek, çünkü bu durum durum değişikliklerini gerçekleştirmek için büyük miktarda hesaplama gücü gerektirir. Başlangıçta düşündüğümüz şey, eğer merkeziyetsiz bir komite seçimi ile bunu gerçekleştirirsek, o zaman yük yürütme işlemleri merkeziyetsiz bir hale gelecektir. Ancak doğrulayıcılar, bu kısmı tamamlamak için doğal olarak üçüncü taraflara bırakmak ve kendi odaklarını blok önermeye yöneltmek istiyorlar gibi görünüyor. Bu nedenle, PBS fikri ortaya çıktı; bu, 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ıdır. Önerici ile inşaatçı arasındaki ayrım, blok önericilerin blok inşaatçılardan blok alabileceği açık bir pazarın oluşmasını teşvik etmektedir. Bu inşaatçılar, blokları inşa etmek için rekabet ederler ve önericilere en yüksek ücreti sunarlar; buna "blok açık artırması" diyoruz.

Kısa bir şekilde PBS( Proposer Builder Seperate) kapalı ilk ihale modelini tanıtalım. Kullanıcılar aracılar üzerinden işlem gönderdiklerinde, aracı bir düğüm çalıştırıyormuş gibi hareket eder ve işlemi kamuya açık Mempool'a gönderir. Birden fazla Builder, en uygun işlemleri bulup sıralayarak maksimum kâr elde eden bir blok oluşturur(. Maksimum kâr, işlem ücretleri Base+Priority+MEV) ile ifade edilir. Ardından, birden fazla Builder, MEV-Boost aracılığıyla Proposer ile etkileşime geçer; bu, Builder'lar ile Proposer arasındaki etkileşim köprüsüdür. Builder, teklif göndermek için Proposer'a birden fazla blok başlığı ve ilgili teklifleri sunar. Proposer genellikle en yüksek teklifi kabul eder. Bu süreçte MEVBoost standartları uygulanır; bu, Builder'lar ile Proposer arasındaki etkileşim ve teklif verme sürecini nasıl düzenleyeceğine dair bir teknik standarttır. Bu süreçte, tüm bilgiler kapalıdır; yalnızca blok başlıkları Proposer'a gönderilir. Bu nedenle, Proposer sansüre dayanıklıdır.

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

Ana katılımcıları arasında Builder, Proposer, MEVbot( ve Searcher) bulunmaktadır.

Yapıcı

Builder, blok içeriğini oluşturmakla sorumlu olan kişidir. MEV-Boost teknolojisi kullanıldıktan sonra, ihalelerde daha avantajlı bir konumda bulunmaktadır, çünkü yalnızca Gas Ücretlerini değil, aynı zamanda MEV kazançlarını da desteklemektedir. Builder, kullanıcıların ve Searcher'ların işlemlerini doğrudan inceleyebilir; bu, özellikle ABD hükümeti OFAC'ı açıkladıktan sonra eleştirilen bir noktadır. Çok sayıda Builder OFAC Uyumlu hale geldi. Başlangıçta, blokları inceleme oranı son zamanlarda azalmış olsa da, blok inşa sürecinde Builder'ın işlemleri doğrudan incelemede etkisi olduğu görülebilir.

Mevcut Builder pazar payına göre, tamamen denetim gerektirmeyen Build, pazar payını kademeli olarak artırıyor, her şey kâr odaklı.

Arayıcı

Esasında, kâr maksimizasyonu işi, Searcher ile Builder'ın ortak çabalarını 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 yalnızca belirli Builder'a gösterilir. Bazı Builder'lar, kârı maksimize eden MEV işlemleri elde eder ve 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 aşamalı olarak azalmasına yol açar. Bu nedenle, Searcher'a bağımlı olan Builder'lar genellikle kötü niyetli davranmanın gizli maliyetlerini göz önünde bulundururlar. Yukarıdaki grafik, MEV ve günlük Gas kazançlarını göstermektedir. Belirgin piyasa dalgalanmaları durumunda, Searcher'ın katkıda bulunduğu MEV kazançlarının, günlük Gas kazançlarının iki katı kadar olabileceği görülmektedir.

Searcher için, CEX-DEX( zincir dışı ) arbitraj ve DEX, ara katman, tasfiye olmak üzere iki ana kategori ( saf zincir üstü ).

Şu anda bir borsa platformu, CEX --- DEX arbitraj ticaretinde pazar payında birinci sırada.

Saf zincir üzerindeki MEV fırsatlarına yönelik, stüdyolaşma eğilimi yavaş yavaş oluşmaktadır. Bu bağlamda, belirli bir hesabın pazar payı şaşırtıcı bir şekilde %37,2'ye ulaşmıştır ve bu hesap zincir üzerindeki kullanıcılara karşı sandviç saldırıları yapma konusunda uzmandır. Bir dönem, zincir üzerindeki en yüksek gaz tüketen kullanıcı haline gelmiş, günlük gaz tüketiminin yaklaşık %1,5'ini kullanmıştır. 2023 Şubat'tan 2024 Haziran'a kadar, bu robot toplamda 76,916 ETH harcamıştır ve bu işlemlerin gerçekleştirildiği değere göre, yaklaşık 175 milyon dolara denk gelmektedir. Seacher ile Builder arasındaki sıkı bağlantı nedeniyle, pratikte birçok Seacher kendi emir akışını ilk üç Builder'a göndermektedir. Aslında tüm Builder'lara yayınlanması mümkünken, bazı küçük Builder'lar Seacher'ın emir akışını bölebilir ve bu da Seacher'ın MEV stratejilerinin başarısız olmasına yol açarak zarar riski oluşturabilir. Ayrıca, Builder'a bağlanmak, onun ekosistem içindeki etkisini sürdürmesine yardımcı olabilir.

Toplu tekliflerin toplanmasından sorumludur, ardından Proposer’a blok başlıklarını ve açık artırma bloklarının fiyatlarını ileten bir ara istasyon olarak hareket eder; bu aşamada Proposer, bloktaki işlem ayrıntılarını bilmez. Proposer blok başlığını seçip imzaladıktan sonra, tüm işlem içeriği Proposer’a serbest bırakılacaktır. Görüyoruz ki, ekonomik teşvik olmayan bir üçüncü taraf olarak, büyük bir güven kazanmıştır; Builder, Proposer’a teklif vermekte bağımlıdır ve Proposer da teklif ve blok içeriğine bağımlıdır. Tarihte benzer sorunlar yaşanmıştır; Proposer’ın 20 milyon dolardan fazla MEV çekmesine neden olan potansiyel bir açık bulunmaktadır. Bu açıklar kapatılabilir olsa da, kötü niyetli davranmayı ve MEV çalmayı seçebilirler.

Yukarıdaki grafik, pazar payı durumunu göstermektedir. MAX Profit Builder'ın pazar payının Merge'den sonra kademeli olarak genişlediğini göreceğiz. Bu nedenle serbest piyasada, Builder'ın MEV'yi insan müdahalesiyle kontrol etmesi mümkün değildir.

Aynı zamanda ekonomik teşviklerin olmaması gibi bir sorunla da karşı karşıya. Bu nedenle bazı şirketler araştırma ve geliştirme yönünden geri çekildi. Şu anda, MEVBoost standardını oluşturmak için bağımlılık söz konusu; Ethereum, üçüncü tarafların PBS sağlamasına güveniyor, bu da uzun vadeli bir çözüm değil. Bu nedenle, Ethereum topluluğu şu anda PBS'yi protokol seviyesine dahil etme yollarını araştırıyor.

Teklifçi

Proposer için, tüm doğrulayıcılar arasında algoritmik olarak rastgele bir komite grubu seçmek ve her slotta bir blok önericisi seçmek gerekmektedir. Blok önericisi, yükü yerine getirme yeteneğine sahip olmasına rağmen, önericinin doğal olarak bu kısmı dışarıya devretmek istemesi nedeniyle Builder ile Proposer arasında dikey işbirliği sağlama riski bulunmaktadır. MEV-boost, bu şekilde bir ara nokta olarak hizmet etmeyi hedeflemekte, böylece ikisi arasındaki doğrudan iletişimden kaynaklanan dikey işbirliği bağlantılarını azaltmaktadır. Şu anda, doğrulayıcı havuzu olarak madencilik havuzları mevcut, ancak bu madencilik havuzları ve LSD doğrulayıcı havuzları güçlü bir ölçek etkisine sahiptir, özellikle LSD'nin ortaya çıkması, daha önce stake edilen token'ların 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 haline gelmektedir.

Bir platform şu anda pazar payının yaklaşık %28,7'sini elinde bulunduruyor, bir borsa ve bir platform ikinci ve üçüncü sırada yer alıyor. Geçmişte MEV-BOOST PBS çözümünü aktif olarak uygulamadıklarında, Proposer, Builder'ın görevlerini üstlenmek zorundaydı, yani (Payload) yükünü yürütmek zorundaydı, ancak çoğu Proposer, işlem sıralama yürütme yeteneklerinden vazgeçti çünkü bu ağır hesaplama işleri doğrulama performansını ciddi şekilde etkiliyordu, bu nedenle yürütme yükünü dış kaynak kullanarak üçüncü tarafların blokları açık artırma yapmasına izin vermek daha iyiydi.

Kullanıcı

Son olarak, Kullanıcıdan bahsetmek gerekirse, kullanıcılar genellikle tüm mimari tasarımda en zayıf tarafta yer alır, çünkü kullanıcıların işlemleri Mempool'a yerleştirilir ve çeşitli MEVbot'ları tarafından MEV karı elde etmek amacıyla kullanılır; ancak bu karlar kullanıcıya yönlendirilmez. Ancak bu her zaman kötü bir durum değildir; örneğin, belirli bir DEX'te, zincir üzerindeki fiyat dalgalanmaları büyük olduğunda veya kullanıcının işlem hacmi DEX'in likiditesinden daha fazla olduğunda, MEVbot'ları kayma etkisini azaltmak ve farklı platformlar arasındaki fiyat farklarını azaltmak için arbitraj yapabilir. Bu nedenle, MEV'nin varlığı hem pozitif hem de negatif dışsallıklara sahiptir ve ayrı ayrı tartışılması gerekir; bu da karmaşıklığının bir nedenidir.

Kullanıcıların MEVbot tarafından izlenmesini ve dolayısıyla zarar görmesini engellemek için, birçok düğüm sağlayıcısı kullanıcıların işlemlerini özel Mempool'da yerleştirmelerine yardımcı olabilir; örneğin, Builder ile doğrudan etkileşimde bulunmak mümkündür. Oldukça yenilikçi bir yöntem, OFA( Sipariş Akışı Müzayede aracılığıyladır.