Karanlık Ormanı Aydınlatmak: MEV'nin Gizemini Açığa Çıkarmak
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ım olarak görülmüştür; bu durum kullanıcıların zincir üzerindeki finansal aktivitelerinde doğrudan kâr kaybına ve kullanıcı deneyiminin kötüleşmesine yol açmaktadır. Bu makale, Ethereum 2.0'ın blok üretim mekanizması ve önerici-yapıcı ayrımı (PBS) üzerindeki teknik evrimi temel alarak, bu mekanizmanın getirdiği doğal merkeziyetçilik ve güven sorunlarını Ethereum'un değerleri ile tamamen zıt bir gerçeklik olarak analiz etmeyi amaçlamaktadır.
Zincir üzerindeki MEV'nin artışı gerçekten de iki ucu keskin bir kılıçtır, hem olumlu hem de olumsuz dışsal etkilere sahiptir. Olumlu etkiler arasında DEX fiyat farklarının azaltılması ve likidite işlemlerine yardımcı olunması yer alırken; olumsuz etkiler arasında kullanıcıların sandwich saldırılarına maruz kalması bulunmaktadır. Bu nedenle MEV çözümleri daha çok olumsuz dışsal etkileri hafifletmeye yöneliktir ve köklü bir çözüm sağlamak mümkün değildir. MEV olumsuz dışsal etkilerini hafifletme ve mevcut üçüncü taraf güvenilir ara katman Relayer sorununu çözme mekanizması keşif süreci üç ana önlem kategorisine ayrılmaktadır: ihale mekanizması iyileştirmeleri, konsensüs katmanı iyileştirmeleri ve uygulama katmanı iyileştirmeleri. Bu üç tür iyileştirme, MEV'nin modern yapısı üzerinde farklı derecelerde etki yaratacak, ancak bazı çözümler kullanıcıların karşılaştığı sandwich saldırısı sorununu somut bir şekilde çözmeyecektir; kullanıcı işlemleri hala public pool içinde yer aldığından, 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 bir araya getirilerek denenmeye değer.
Bunun dışında, MEV kaçınılmaz bir mekanizma tasarım yan ürünü olarak, gelecekte daha da karmaşık hale gelecektir. Ayrıca, metinde Layer2 mimarisi, EIP-4337 hesap soyutlaması gibi yeni işlem türlerinin uygulanması altında ortaya çıkabilecek daha fazla MEV teknik zorluğu ve fırsatını araştırdık.
Son olarak, bu makale aracılığıyla MEV olumsuz dışsallık sorununu hafifletme 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ınlatmakla kalmayacak, aynı zamanda sektördeki araştırmacılara MEV üzerine daha fazla araştırma yapmaları için karanlık ormanı aydınlatacaktır.
Ethereum 2.0
The Merge'den sonra, Ethereum ağı güvenliğini sağlamak için POS mekanizmasını benimsemiştir, aynı zamanda blok üretiminde hesaplama yoğun rekabeti terk ederek, hisse kanıtına geçmiştir. Birleştirmeden sonra, Ethereum yürütme katmanı ve konsensüs katmanına ayrılmıştır. Tüm blok üretiminde de bir değişiklik olmuştur, her bir Epoch bir POS döngüsüdür, her Epoch 32 Slot'a ayrılmıştır ve her Slot, 12 saniyelik bir blok üretim zaman birimine karşılık gelmektedir.
Tüm ağ, her Epoch'ta doğrulayıcılardan rastgele bir komite seçer, blok önericisi komite grubundan rastgele seçilir. Bu blok önericisi, işlemleri paketlemek ve sıralamak zorundadır, sonuç olarak bir blok üretilir. Diğer komite doğrulayıcıları bu süreci denetler ve ardından bu blok için oy verir. Ayrıca bu komite, her Epoch'tan sonra yeniden seçilir. Blok üretimi ve oylama verimliliğini sağlamak için belirli bir işlem süresi kısıtlaması da uygulanır. Burada, okuyucular için terimleri standartlaştırıyoruz, Payload, işlem yükünü ifade eder, yani işlemlerin durum değişikliklerini içeren blokların bir parçası olarak değerlendirilebilir. Blok önericisi, ( 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 işlem 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 yürütme yükünü dahil edersek, o zaman işlemlerin sıralanması gibi şeyler merkeziyetsiz hale gelecekti. Ancak doğrulayıcıların bu kısmı üçüncü taraflara devretmek istediği, kendilerinin ise önerici olarak blok önerme işine odaklandığı görünmektedir. Böylece PBS'nin kavramı ortaya çıktı; bu, blok önerimi ve inşasını ayırmaktır, burada önericiler yalnızca blokları doğrulamakla sorumludur ve blok inşasına katılmazlar. Önericiler ve inşacılar arasındaki ayrım, blok önericilerin blok inşacılardan blok alabileceği açık bir pazar yaratır. Bu inşacılar, blokları oluşturmak için birbirleriyle rekabet eder ve önericilere en yüksek ücreti sunarlar, buna "blok açık artırması" diyoruz.
Tüm PBS(Proposer Builder Seperate) mühürlü birinci 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 olur ve işlemi açık Mempool'a gönderir, birden fazla Builder en uygun işlemleri sıralayarak maksimum kâr elde etmek için bir blok oluşturur( maksimum kâr, işlem ücretleri Base+Priority+MEV) ile ifade edilir, ardından birden fazla Builder MEV-Boost 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 gönderir, Relayer Proposer'a birden fazla blok başlığı ve karşılık gelen teklifleri sunar, Proposer genellikle en yüksek teklifi kabul eder. Burada Relayer, Builder ile Proposer arasındaki etkileşim tekliflerini standart hale getiren MEVBboost spesifikasyonunu uygular; bu, Flashbot'un Builder ve Proposer arasındaki ihale etkileşimini standartlaştırma yöntemidir. 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 etmekten sorumludur ve MEV-Boost teknolojisini kullandıktan sonra, teklif verme sürecinde daha avantajlı bir konumda bulunmaktadır, çünkü yalnızca Gas Fees'i desteklemekle kalmaz, aynı zamanda MEV kazançlarını da destekler. Builder, kullanıcılar ve Searcher'ların işlemlerini doğrudan gözden geçirebilir, 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 hale gelmiştir. Başlangıçta olduğu gibi, blokların gözden geçirilme oranı son zamanlarda azalmış olsa da, blok inşa sürecinde Builder'ın işlemlerin doğrudan gözden geçirilmesi konusunda doğrudan bir etkisi olduğunu görebiliyoruz.
Mevcut Builder pazar payına göre, beaverbuild.org gibi tamamen denetim gerektirmeyen Build'ler, pazar payını adım adım artırıyor, her şey kâr odaklı.
Arayıcı
Esasında, 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. Bu ortamda Searcher'ın işlemleri yalnızca 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 verir. Teorik olarak, eğer Builder kötü niyetliyse veya denetim yapıyorsa, Searcher diğer Builder'ları seçebilir, bu da Builder'ın pazar payının aşamalı olarak düşmesine yol açar. Bu nedenle, Searcher'a bağlı olan Builder'lar genellikle kötü niyetin gizli maliyetlerini göz önünde bulundururlar. Yukarıdaki grafik, MEV ve günlük Gas gelirlerini göstermektedir; Searcher'ın katkıda bulunduğu MEV gelirinin, piyasa dalgalanmalarının belirgin olduğu durumlarda, günlük Gas gelirinin iki katına kadar çıkabildiği görülmektedir.
Searcher için, CEX-DEX( zincir dışı) arbitraj ve DEX, ara katman, likidasyon olmak üzere iki ana kategori( saf zincir üstü) olarak ayrılır.
Şu anda Wintermute, CEX-DEX arbitraj işlemlerinde pazar payında birinci sırada.
Saf zincir üzerindeki MEV fırsatları için, stüdyo tarzında bir oluşum eğilimi giderek gelişmektedir. Bu bağlamda, jaredfromsubway.eth pazar payı şaşırtıcı bir şekilde %37,2'yi kapsıyor ve Etheruem zincirindeki kullanıcıları üzerine sandviç saldırıları gerçekleştirmede uzmanlaşmıştır. Bu kullanıcı, bir dönem zincir üzerindeki en yüksek gas tüketimine sahip olan kullanıcı haline gelmiş ve yaklaşık olarak tüm günün %1,5'ini gas tüketmiştir. 2023 Şubat'tan 2024 Haziran'a kadar, bu bot toplamda 76,916 ETH harcamıştır ki, bu da bu işlemleri gerçekleştirirkenki değerine göre yaklaşık 175 milyon dolara eşdeğerdir. Seacher ile Builder arasındaki sıkı bağlantılar nedeniyle, pratikte birçok Seacher, kendi sipariş akışlarını ilk üç Builder'a göndermektedir. Aslında tüm Builder'lara yayınlanması mümkünken, bazı küçük Builder'lar Seacher'ın sipariş akışını bölme yoluna gidebilir, bu da Seacher'ın MEV stratejilerinin başarısız olmasına ve dolayısıyla zarar riski doğurmasına neden olabilir. Ayrıca, Builder'a bağlılık, ekosistem içinde etkisini sürdürmesine de yardımcı olabilir.
İletici
Relayer, toplu teklifleri toplamakla sorumludur ve ardından Proposer'a blok başlıklarını ve açık artırma bloklarının 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şviği olmayan üçüncü taraf olarak büyük bir güven kazandığını görebiliriz; Builder, teklif vermek için Proposer'a güveniyor, Proposer ise Relayer'ın teklifine ve blok içeriğine güveniyor. Tarihte benzer sorunlar yaşanmıştır; Ultrasound Relayer'in potansiyel bir açığı, Proposer'ın 20 milyon doların üzerinde MEV çekmesine neden olmuştur. Bu tür açıklar kapatılabilir, ancak Relayer kendisi hala kötü niyetli davranmayı ve MEV'yi çalmayı seçebilir.
Yukarıdaki grafik, Relayer'ın pazar payının durumunu göstermektedir. Merge'den sonra, yalnızca MAX Profit yapan Builder'ın pazar payının kademeli olarak arttığını göreceğiz. Bu nedenle serbest piyasada, Builder'ın MEV'yi insan müdahalesiyle kontrol etmesi mümkün değildir.
Aynı zamanda Relayer bir sorunla karşı karşıya, yani ekonomik bir teşvik yok. Bu nedenle Blocknative de Relayer yönündeki geliştirmeyi bıraktı. Relayer şu anda Flashbots tarafından önerilen MEVBoost standartlarına dayanarak inşa edilmektedir, Ethereum üçüncü tarafların PBS sağlamasına bağımlıdır, bu da uzun vadeli bir çözüm değildir. Bu nedenle şu anda Ethereum topluluğu PBS'yi protokol seviyesine dahil etme konusunda araştırmalar yapmaktadır.
Teklifçi
Proposer için, tüm doğrulayıcılar arasında algoritma ile rastgele bir komite grubu seçmek ve her slotta bir blok önerici seçmek söz konusu. Blok önericisi, yükü yerine getirme yeteneğine sahipken, önericinin doğal olarak bu kısmı dışarıdan sağlamaya çalışması nedeniyle, Builder ile Proposer arasında dikey işbirliğine yol açma riski vardır. MEV-boost'un Relayer'ı, bu tür bir aracı olarak, iki taraf arasındaki doğrudan iletişimin getirdiği dikey işbirliği entrikalarını azaltmayı hedefliyor. Şu anda, tüm doğrulayıcı havuzları madenci havuzu olarak işlev görüyor, ancak bu madenci havuzları ve LSD doğrulayıcı havuzları oldukça güçlü bir ölçek etkisine sahip. Özellikle LSD'nin ortaya çıkışı, önceden stake edilmiş tokenlerin potansiyelini serbest bırakıyor ve sermaye verimliliğini artırıyor. Ayrıca, arka plandaki DEFI yapı taşlarının etkisiyle, doğrulayıcı havuzu daha merkezi bir eğilim içinde bulunuyor.
Lido şu anda yaklaşık %28.7 pazar payına sahip, Coinbase ve Ether.fi ikinci ve üçüncü sırada. Geçmişte MEV-BOOST PBS çözümünü aktif olarak uygulamadığı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 yeteneklerini bırakmayı tercih etti çünkü bu yoğun hesaplama yükü doğrulama performansını ciddi şekilde etkiliyordu, bu yüzden yürütme yükünü dışarıdan alıp üçüncü tarafların blokları açık artırmaya çıkarmasını sağlamak daha mantıklıdır.
Kullanıcı
Son olarak User'dan bahsedelim, kullanıcılar genellikle tüm mimari tasarımda en zayıf konumda olan tarafdır, çünkü kullanıcıların işlemleri Mempool'a yerleştirilir ve çeşitli MEVbot'ları tarafından MEV kârı elde edilir, ancak bu kâr kullanıcıya ulaşmaz. Ancak bu tamamen kötü bir durum değil, örneğin DEX'te, on-chain fiyat dalgalanmaları büyük olduğunda veya kullanıcının işlem hacmi DEX'in likiditesinden büyük olduğunda, MEVbot'ları kayıpları azaltmak ve çeşitli platformlardaki fiyat farklarını hafifletmek için arbitraj yapabilir. Bu nedenle, MEV'nin varlığı pozitif ve negatif dışsallıklara sahiptir, bu nedenle ayrı ayrı tartışılması gerekir ve bu da karmaşıklığının bir parçasıdır.
Kullanıcıların MEVbot tarafından izlenmesini ve dolayısıyla zarar görmesini önlemek için, birçok RPC düğüm sağlayıcısı, kullanıcıların işlemlerini halka açık olmayan Mempool'da yerleştirmelerine yardımcı olabilir. Örneğin, Builder ile doğrudan etkileşimde bulunmak için Builder'ın RPC'si kullanılabilir. Kullanıcılara MEV kazançlarını telafi etmek için oldukça yenilikçi bir yöntem, OFA(Order Flow Auction) (Sipariş Akışı Müzayede) aracılığıyla gerçekleştirilir. OFA RPC operatörleri ile Searcher arasında...
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Ethereum MEV sorunu: PBS mimarisinden on-chain karanlık ormana bakış
Karanlık Ormanı Aydınlatmak: MEV'nin Gizemini Açığa Çıkarmak
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ım olarak görülmüştür; bu durum kullanıcıların zincir üzerindeki finansal aktivitelerinde doğrudan kâr kaybına ve kullanıcı deneyiminin kötüleşmesine yol açmaktadır. Bu makale, Ethereum 2.0'ın blok üretim mekanizması ve önerici-yapıcı ayrımı (PBS) üzerindeki teknik evrimi temel alarak, bu mekanizmanın getirdiği doğal merkeziyetçilik ve güven sorunlarını Ethereum'un değerleri ile tamamen zıt bir gerçeklik olarak analiz etmeyi amaçlamaktadır.
Zincir üzerindeki MEV'nin artışı gerçekten de iki ucu keskin bir kılıçtır, hem olumlu hem de olumsuz dışsal etkilere sahiptir. Olumlu etkiler arasında DEX fiyat farklarının azaltılması ve likidite işlemlerine yardımcı olunması yer alırken; olumsuz etkiler arasında kullanıcıların sandwich saldırılarına maruz kalması bulunmaktadır. Bu nedenle MEV çözümleri daha çok olumsuz dışsal etkileri hafifletmeye yöneliktir ve köklü bir çözüm sağlamak mümkün değildir. MEV olumsuz dışsal etkilerini hafifletme ve mevcut üçüncü taraf güvenilir ara katman Relayer sorununu çözme mekanizması keşif süreci üç ana önlem kategorisine ayrılmaktadır: ihale mekanizması iyileştirmeleri, konsensüs katmanı iyileştirmeleri ve uygulama katmanı iyileştirmeleri. Bu üç tür iyileştirme, MEV'nin modern yapısı üzerinde farklı derecelerde etki yaratacak, ancak bazı çözümler kullanıcıların karşılaştığı sandwich saldırısı sorununu somut bir şekilde çözmeyecektir; kullanıcı işlemleri hala public pool içinde yer aldığından, 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 bir araya getirilerek denenmeye değer.
Bunun dışında, MEV kaçınılmaz bir mekanizma tasarım yan ürünü olarak, gelecekte daha da karmaşık hale gelecektir. Ayrıca, metinde Layer2 mimarisi, EIP-4337 hesap soyutlaması gibi yeni işlem türlerinin uygulanması altında ortaya çıkabilecek daha fazla MEV teknik zorluğu ve fırsatını araştırdık.
Son olarak, bu makale aracılığıyla MEV olumsuz dışsallık sorununu hafifletme 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ınlatmakla kalmayacak, aynı zamanda sektördeki araştırmacılara MEV üzerine daha fazla araştırma yapmaları için karanlık ormanı aydınlatacaktır.
Ethereum 2.0
The Merge'den sonra, Ethereum ağı güvenliğini sağlamak için POS mekanizmasını benimsemiştir, aynı zamanda blok üretiminde hesaplama yoğun rekabeti terk ederek, hisse kanıtına geçmiştir. Birleştirmeden sonra, Ethereum yürütme katmanı ve konsensüs katmanına ayrılmıştır. Tüm blok üretiminde de bir değişiklik olmuştur, her bir Epoch bir POS döngüsüdür, her Epoch 32 Slot'a ayrılmıştır ve her Slot, 12 saniyelik bir blok üretim zaman birimine karşılık gelmektedir.
Tüm ağ, her Epoch'ta doğrulayıcılardan rastgele bir komite seçer, blok önericisi komite grubundan rastgele seçilir. Bu blok önericisi, işlemleri paketlemek ve sıralamak zorundadır, sonuç olarak bir blok üretilir. Diğer komite doğrulayıcıları bu süreci denetler ve ardından bu blok için oy verir. Ayrıca bu komite, her Epoch'tan sonra yeniden seçilir. Blok üretimi ve oylama verimliliğini sağlamak için belirli bir işlem süresi kısıtlaması da uygulanır. Burada, okuyucular için terimleri standartlaştırıyoruz, Payload, işlem yükünü ifade eder, yani işlemlerin durum değişikliklerini içeren blokların bir parçası olarak değerlendirilebilir. Blok önericisi, ( 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 işlem 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 yürütme yükünü dahil edersek, o zaman işlemlerin sıralanması gibi şeyler merkeziyetsiz hale gelecekti. Ancak doğrulayıcıların bu kısmı üçüncü taraflara devretmek istediği, kendilerinin ise önerici olarak blok önerme işine odaklandığı görünmektedir. Böylece PBS'nin kavramı ortaya çıktı; bu, blok önerimi ve inşasını ayırmaktır, burada önericiler yalnızca blokları doğrulamakla sorumludur ve blok inşasına katılmazlar. Önericiler ve inşacılar arasındaki ayrım, blok önericilerin blok inşacılardan blok alabileceği açık bir pazar yaratır. Bu inşacılar, blokları oluşturmak için birbirleriyle rekabet eder ve önericilere en yüksek ücreti sunarlar, buna "blok açık artırması" diyoruz.
Tüm PBS(Proposer Builder Seperate) mühürlü birinci 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 olur ve işlemi açık Mempool'a gönderir, birden fazla Builder en uygun işlemleri sıralayarak maksimum kâr elde etmek için bir blok oluşturur( maksimum kâr, işlem ücretleri Base+Priority+MEV) ile ifade edilir, ardından birden fazla Builder MEV-Boost 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 gönderir, Relayer Proposer'a birden fazla blok başlığı ve karşılık gelen teklifleri sunar, Proposer genellikle en yüksek teklifi kabul eder. Burada Relayer, Builder ile Proposer arasındaki etkileşim tekliflerini standart hale getiren MEVBboost spesifikasyonunu uygular; bu, Flashbot'un Builder ve Proposer arasındaki ihale etkileşimini standartlaştırma yöntemidir. 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 etmekten sorumludur ve MEV-Boost teknolojisini kullandıktan sonra, teklif verme sürecinde daha avantajlı bir konumda bulunmaktadır, çünkü yalnızca Gas Fees'i desteklemekle kalmaz, aynı zamanda MEV kazançlarını da destekler. Builder, kullanıcılar ve Searcher'ların işlemlerini doğrudan gözden geçirebilir, 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 hale gelmiştir. Başlangıçta olduğu gibi, blokların gözden geçirilme oranı son zamanlarda azalmış olsa da, blok inşa sürecinde Builder'ın işlemlerin doğrudan gözden geçirilmesi konusunda doğrudan bir etkisi olduğunu görebiliyoruz.
Mevcut Builder pazar payına göre, beaverbuild.org gibi tamamen denetim gerektirmeyen Build'ler, pazar payını adım adım artırıyor, her şey kâr odaklı.
Arayıcı
Esasında, 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. Bu ortamda Searcher'ın işlemleri yalnızca 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 verir. Teorik olarak, eğer Builder kötü niyetliyse veya denetim yapıyorsa, Searcher diğer Builder'ları seçebilir, bu da Builder'ın pazar payının aşamalı olarak düşmesine yol açar. Bu nedenle, Searcher'a bağlı olan Builder'lar genellikle kötü niyetin gizli maliyetlerini göz önünde bulundururlar. Yukarıdaki grafik, MEV ve günlük Gas gelirlerini göstermektedir; Searcher'ın katkıda bulunduğu MEV gelirinin, piyasa dalgalanmalarının belirgin olduğu durumlarda, günlük Gas gelirinin iki katına kadar çıkabildiği görülmektedir.
Searcher için, CEX-DEX( zincir dışı) arbitraj ve DEX, ara katman, likidasyon olmak üzere iki ana kategori( saf zincir üstü) olarak ayrılır.
Şu anda Wintermute, CEX-DEX arbitraj işlemlerinde pazar payında birinci sırada.
Saf zincir üzerindeki MEV fırsatları için, stüdyo tarzında bir oluşum eğilimi giderek gelişmektedir. Bu bağlamda, jaredfromsubway.eth pazar payı şaşırtıcı bir şekilde %37,2'yi kapsıyor ve Etheruem zincirindeki kullanıcıları üzerine sandviç saldırıları gerçekleştirmede uzmanlaşmıştır. Bu kullanıcı, bir dönem zincir üzerindeki en yüksek gas tüketimine sahip olan kullanıcı haline gelmiş ve yaklaşık olarak tüm günün %1,5'ini gas tüketmiştir. 2023 Şubat'tan 2024 Haziran'a kadar, bu bot toplamda 76,916 ETH harcamıştır ki, bu da bu işlemleri gerçekleştirirkenki değerine göre yaklaşık 175 milyon dolara eşdeğerdir. Seacher ile Builder arasındaki sıkı bağlantılar nedeniyle, pratikte birçok Seacher, kendi sipariş akışlarını ilk üç Builder'a göndermektedir. Aslında tüm Builder'lara yayınlanması mümkünken, bazı küçük Builder'lar Seacher'ın sipariş akışını bölme yoluna gidebilir, bu da Seacher'ın MEV stratejilerinin başarısız olmasına ve dolayısıyla zarar riski doğurmasına neden olabilir. Ayrıca, Builder'a bağlılık, ekosistem içinde etkisini sürdürmesine de yardımcı olabilir.
İletici
Relayer, toplu teklifleri toplamakla sorumludur ve ardından Proposer'a blok başlıklarını ve açık artırma bloklarının 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şviği olmayan üçüncü taraf olarak büyük bir güven kazandığını görebiliriz; Builder, teklif vermek için Proposer'a güveniyor, Proposer ise Relayer'ın teklifine ve blok içeriğine güveniyor. Tarihte benzer sorunlar yaşanmıştır; Ultrasound Relayer'in potansiyel bir açığı, Proposer'ın 20 milyon doların üzerinde MEV çekmesine neden olmuştur. Bu tür açıklar kapatılabilir, ancak Relayer kendisi hala kötü niyetli davranmayı ve MEV'yi çalmayı seçebilir.
Yukarıdaki grafik, Relayer'ın pazar payının durumunu göstermektedir. Merge'den sonra, yalnızca MAX Profit yapan Builder'ın pazar payının kademeli olarak arttığını göreceğiz. Bu nedenle serbest piyasada, Builder'ın MEV'yi insan müdahalesiyle kontrol etmesi mümkün değildir.
Aynı zamanda Relayer bir sorunla karşı karşıya, yani ekonomik bir teşvik yok. Bu nedenle Blocknative de Relayer yönündeki geliştirmeyi bıraktı. Relayer şu anda Flashbots tarafından önerilen MEVBoost standartlarına dayanarak inşa edilmektedir, Ethereum üçüncü tarafların PBS sağlamasına bağımlıdır, bu da uzun vadeli bir çözüm değildir. Bu nedenle şu anda Ethereum topluluğu PBS'yi protokol seviyesine dahil etme konusunda araştırmalar yapmaktadır.
Teklifçi
Proposer için, tüm doğrulayıcılar arasında algoritma ile rastgele bir komite grubu seçmek ve her slotta bir blok önerici seçmek söz konusu. Blok önericisi, yükü yerine getirme yeteneğine sahipken, önericinin doğal olarak bu kısmı dışarıdan sağlamaya çalışması nedeniyle, Builder ile Proposer arasında dikey işbirliğine yol açma riski vardır. MEV-boost'un Relayer'ı, bu tür bir aracı olarak, iki taraf arasındaki doğrudan iletişimin getirdiği dikey işbirliği entrikalarını azaltmayı hedefliyor. Şu anda, tüm doğrulayıcı havuzları madenci havuzu olarak işlev görüyor, ancak bu madenci havuzları ve LSD doğrulayıcı havuzları oldukça güçlü bir ölçek etkisine sahip. Özellikle LSD'nin ortaya çıkışı, önceden stake edilmiş tokenlerin potansiyelini serbest bırakıyor ve sermaye verimliliğini artırıyor. Ayrıca, arka plandaki DEFI yapı taşlarının etkisiyle, doğrulayıcı havuzu daha merkezi bir eğilim içinde bulunuyor.
Lido şu anda yaklaşık %28.7 pazar payına sahip, Coinbase ve Ether.fi ikinci ve üçüncü sırada. Geçmişte MEV-BOOST PBS çözümünü aktif olarak uygulamadığı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 yeteneklerini bırakmayı tercih etti çünkü bu yoğun hesaplama yükü doğrulama performansını ciddi şekilde etkiliyordu, bu yüzden yürütme yükünü dışarıdan alıp üçüncü tarafların blokları açık artırmaya çıkarmasını sağlamak daha mantıklıdır.
Kullanıcı
Son olarak User'dan bahsedelim, kullanıcılar genellikle tüm mimari tasarımda en zayıf konumda olan tarafdır, çünkü kullanıcıların işlemleri Mempool'a yerleştirilir ve çeşitli MEVbot'ları tarafından MEV kârı elde edilir, ancak bu kâr kullanıcıya ulaşmaz. Ancak bu tamamen kötü bir durum değil, örneğin DEX'te, on-chain fiyat dalgalanmaları büyük olduğunda veya kullanıcının işlem hacmi DEX'in likiditesinden büyük olduğunda, MEVbot'ları kayıpları azaltmak ve çeşitli platformlardaki fiyat farklarını hafifletmek için arbitraj yapabilir. Bu nedenle, MEV'nin varlığı pozitif ve negatif dışsallıklara sahiptir, bu nedenle ayrı ayrı tartışılması gerekir ve bu da karmaşıklığının bir parçasıdır.
Kullanıcıların MEVbot tarafından izlenmesini ve dolayısıyla zarar görmesini önlemek için, birçok RPC düğüm sağlayıcısı, kullanıcıların işlemlerini halka açık olmayan Mempool'da yerleştirmelerine yardımcı olabilir. Örneğin, Builder ile doğrudan etkileşimde bulunmak için Builder'ın RPC'si kullanılabilir. Kullanıcılara MEV kazançlarını telafi etmek için oldukça yenilikçi bir yöntem, OFA(Order Flow Auction) (Sipariş Akışı Müzayede) aracılığıyla gerçekleştirilir. OFA RPC operatörleri ile Searcher arasında...