2 Nisan'da kötü niyetli Ethereum ağ aktörleri, bir MEV arayıcısından 20 milyon dolar çalmak için MEV-Boost rölesindeki bir güvenlik açığından yararlandı (bkz. Flashbots raporu). Önümüzdeki birkaç gün içinde, geliştiriciler beş yama yayınlayarak bu güvenlik açığını giderdiler. Ağ gecikmeleri ve doğrulayıcı politikalarıyla birleşen bu yamalar, 6 Nisan'da Ethereum ağında kısa bir dalgalanmaya neden oldu. Blokları yeniden düzenlemek, blok üretim hızını yavaşlattığı ve yerleşim güvencelerini azalttığı için ağın sağlığına zarar verebilir.
Bu gönderide, Arayıcılar saldırı altındayken ve ağ geçici olarak istikrarsızken, MEV-Boost ile konsensüs arasındaki etkileşimi keşfediyor, Ethereum'un stake kanıtı mekanizmasının inceliklerini analiz ediyor ve ileriye dönük bazı olası adımları listeliyoruz.
MEV-Boost ve neden önemli
MEV-Boost, Flashbots ve topluluk tarafından Maksimum Çıkarılabilir Değerin (MEV) Ethereum ağı üzerindeki olumsuz etkisini azaltmak için tasarlanmış bir protokoldür.
MEV-Boost'ta 3 oyuncu var:
Röle - Blok üreticileri ile blok inşaatçılarını birbirine bağlayan, birbirine güvenen müzayedeciler
Yapıcılar - kendileri ve blok yaratıcıları için MEV'yi en üst düzeye çıkarmak için bloklar oluşturan karmaşık varlıklar
Oluşturucular, kullanıcılardan, arama yapanlardan veya diğer (özel veya genel) sipariş akışlarından işlem alarak bir blok oluşturur.
Oluşturucu, bloğu aktarıcıya gönderir
Röle, bloğun geçerliliğini doğrular ve blok üreticisine ödediği tutarı hesaplar.
Aktarıcı, mevcut slotun blok üreticisine boş bir başlık ve ödeme değeri gönderir.
Blok Üreticileri aldıkları tüm teklifleri değerlendirir ve en yüksek ödeme ile ilgili boş başlığı imzalar.
Blok üreticisi bu imzalı başlığı röleye geri gönderir.
Röleler, yerel işaret düğümlerini kullanarak bloklar yayınlar ve bunları blok verene geri gönderir. Ödüller, bloklar içindeki işlemler ve blok ödülleri yoluyla inşaatçılara ve teklif verenlere dağıtılır.
Röle, blok üreticileri tarafından blok alanı adil bir şekilde değiş tokuş edilmesini ve inşaatçılar tarafından MEV çıkarımı için işlem siparişi verilmesini kolaylaştıran güvenilir bir üçüncü taraftır. Röleler, inşaatçıları MEV hırsızlığından koruyarak inşaatçıları korur ve blok üreticilerinin, onu bulan arayıcılara/inşaatçılara dağıtmadan MEV'i alıp götürmek için inşaatçı işlemlerini kopyalamasını engeller. Röleler, blok üreticilerini, bloklarının geçerliliğini onaylayarak, yuva başına yüzlerce bloğu onlar adına işleyerek ve blok üreticisi ödemelerinin doğruluğunu sağlayarak korur.
MEV-Boost, tüm blok üreticilerinin, Ethereum'un uzun vadeli ademi merkeziyetçiliğine katkıda bulunan, oluşturucular veya arama yapanlarla bir güven ilişkisi gerektirmeden MEV'ye demokratik bir şekilde erişmesini sağladığı için kilit protokol altyapısıdır.
Ethereum'un çatal seçim kuralları ve MEV-Boost
Saldırıyı ve yanıtı tartışmadan önce, Ethereum'un proof-of-stake mekanizmasına ve ilgili çatal seçim kurallarına bir göz atalım. Çatal seçim kuralı, "Ethereum birleşme sonrası yeniden yapılanma" makalesinde tanımlandığı gibi, ağın zincir başı üzerinde fikir birliğine varmasını sağlar:
"Çatal seçim kuralı, müşteri tarafından değerlendirilen, görülen blokları ve diğer bilgileri girdi olarak alan ve "kanonik zinciri" müşteriye veren bir işlevdir. Çatal seçim kuralı önemlidir, çünkü aralarından seçim yapılabilecek birden çok geçerli zincir olabilir (örneğin, aynı üst bloğa sahip iki rakip blok aynı anda yayınlanırsa). "
Çatal seçim kuralları da blok üretimi üzerinde önemli bir etkiye sahip olan zamana bağlıdır.
slot ve alt slot döngüsü
Ethereum'un proof-of-stake mekanizmasında, zaman her 12 saniyede bir yuvalara bölünür. Proof-of-stake algoritması rastgele bir doğrulayıcıya o yuva içinde bir blok önermesi için bir lisans atar; bu doğrulayıcıya blok üreticisi denir. Aynı yuva içinde, diğer doğrulayıcılara yerel görüşlerine göre çatal seçimi kurallarını uygulayan zincir başkanı için doğrulama (oylama) görevi atanır. Bu 12 saniyelik dilim, her biri 4 saniyeye mal olan üç aşamaya bölünmüştür.
Yuvada meydana gelen olaylar aşağıdaki gibidir, burada t=0, yuvanın başlangıcını gösterir.
Yuva sırasında en kritik an, t=4'teki kimlik doğrulama son tarihidir. Tasdik eden doğrulayıcılar, tasdik son tarihine kadar bloğu görmezlerse, zincirin daha önce kabul edilen başkanına (çatal seçim kuralına göre) oy vereceklerdir. Bir blok ne kadar erken teklif edilirse, yayılması ve dolayısıyla daha fazla onay alması için o kadar fazla zaman gerekir (çünkü daha fazla onaylayıcı bunu son onay tarihinden önce görür).
Bir ağ sağlığı perspektifinden, bir bloğun serbest bırakılması için en uygun zaman t=0'dır (spesifikasyona göre). Bununla birlikte, blok değeri zaman içinde tekdüze bir şekilde arttığından, blok üreticilerinin bloklarının piyasaya sürülmesini geciktirme teşviki vardır, böylece daha fazla MEV birikebilir. Ayrıntılar için Proof-of-Stake'te Zamanlama oyunlarına ve bu tartışmaya bakın.
Daha önce, bir blok üreticisi, bir sonraki doğrulayıcı sonraki slotu için bloğu oluşturmadan önce bloğu gözlemlediği sürece, sertifikasyon son tarihinden sonra (hatta slotun sonuna yakın) bir blok yayınlayabilirdi. Bunun nedeni alt bloğun üst bloğun ağırlığını devralmasıdır ve çatal seçim kuralı yaprak düğümde sona erer. Bu nedenle, blok yayınlarını ertelemenin hiçbir yan etkisi yoktur. Rasyonel davranışı (blok sürümlerini erteleme) dürüst davranışa (zamanında yayınlama) kaydırmaya yardımcı olmak için bir "dürüst yeniden düzenleme" uygulandı.
Blok Yapımcı Ödül Mekanizması ve Dürüst Yeniden Düzenleme
Konsensüs istemcisine, kimlik doğrulama son tarihi üzerinde kritik bir etkiye sahip olan iki yeni kavram eklenmiştir.
Blok Üreticisi Ödül Mekanizması - Blok üreticilerine tam kimlik doğrulama ağırlığının %40'ına eşit bir çatal seçimi "ödülü" vererek yeniden dengeleme saldırılarını en aza indirmeyi amaçlar. Daha da önemlisi, bu ödül yalnızca slotun tamamı için geçerlidir.
Dürüst yeniden düzenleme - dürüst blok üreticilerinin kimlik doğrulama ağırlıkları %20'nin altında olan blokları yeniden düzenlemeye zorlamalarına izin veren blok üreticisi hızlandırmasından yararlanın. Bu, Lighthouse ve Prysm'de zaten uygulanmaktadır (v4.0 - Capella sürümünden başlayarak). Bu değişiklik isteğe bağlıdır çünkü blok üreticileri tarafından verilen bir karardır ve doğrulayıcıların kimliğini doğrulama davranışını etkilemez. Bu nedenle, bunu tüm istemcilere aynı anda uygulamıyoruz ve belirli bir hard fork'a bağlı değil.
Bazı özel durumlarda dürüst yeniden düzenlemeden kaçınıldığına dikkat edilmelidir:
Dönem sınır blokları sırasında
Zincir tamamlanmadıysa
Yeniden düzenlemeden önce zincirin başı yuvanın başı değilse
Durum 3, dürüst yeniden düzenlemelerin zincirden yalnızca bir bloğu kaldırmasını sağlar; bu blok, bir devre kesici görevi görerek, aşırı ağ gecikmesi dönemlerinde zincirin blok üretmeye devam etmesine izin verir. Ayrıca, önerilen gelişmiş blokların norm olarak kabul edilip edilmeyeceğinden emin olamadıklarından, teklif verenlerin ağın algısına daha az güvendiklerini de yansıtır.
Aşağıdaki şekil, bir yeniden yapılandırma stratejisi uygulamak için dürüst davranışın nasıl değiştirilebileceğini göstermektedir.
Bu durumda, b1 bir geç bloğu temsil etsin. Gecikme nedeniyle, b1, n'inci yuvanın kanıt ağırlığının yalnızca %19'una sahiptir. Prova ağırlığının kalan %81'lik kısmı HEAD ana bloğuna atanır çünkü birçok provacı b1'i prova son tarihinden önce görmemiştir.
Dürüst bir yeniden düzenleme yoksa, n+1 dilimini öneren kişi b1'i zincirin başı olarak kabul edecek ve b2 alt bloğunu oluşturacaktır. Öneri sahibi, yalnızca %19 kanıt ağırlığına sahip olmasına rağmen b1'i yeniden düzenlemek için hiçbir çaba göstermedi. n+1 slotunda, b2 teklif verenin geliştirmesine sahiptir, zamanında teslim edildiği varsayılırsa, b2 o slot için kanıtların çoğunu toplayarak norm haline gelecektir.
Dürüst Yeniden Yapılanma ile işler çok farklı. Şimdi, slot n+1'i öneren kişi, b1'in kanıt ağırlıklarının %19'unun yeniden düzenleme eşiğinin altında olduğunu görür, bu nedenle üst öğe olarak HEAD ile bir blok oluşturur ve b1'i yeniden düzenlemeye zorlar. Yuva n+1 için kanıtlama son tarihine ulaştığımızda, dürüst kanıtlayıcı b1'in (%19) ve b2'nin (teklif edenin desteğinden %40) göreli ağırlıklarını karşılaştıracaktır. Tüm müşteriler, teklif veren geliştirmesini uygular, bu nedenle b2, zincirin başı olarak kabul edilecek ve n+1 yuvası için kanıtları toplayacaktır.
Ayrışma saldırıları için Aktarma ve İşaret düğümü düzeltmeleri
2 Nisan'daki ayrıştırma saldırısında, teklif sahibi geçişe geçersiz bir imza başlığı göndermek için bir geçiş güvenlik açığından yararlandı. Sonraki birkaç gün içinde geçiş ve çekirdek geliştirme ekipleri, tekrarlanan saldırı riskini azaltmak için çok sayıda yazılım yaması yayınladı. Beş ana değişiklik aşağıdaki gibidir:
Röle Değişiklikleri: Bilinen kötü niyetli teklifçiler için veritabanını kontrol edin (yalnızca Ultrasonic Relay tarafından üretimde kullanılır ve kaldırılmıştır). Rölenin tüm bloğu P2P ağındaki bir yuvaya teslim edip etmediğini kontrol eder. Bir blok yayınlanmadan önce 0-500 ms aralığında tekdüze bir rasgele gecikme sunar (tüm rölelerden kaldırılır).
İşaret düğümü değişikliği (yalnızca röle işaret düğümleri): Yayından önce işaret bloklarını doğrulayın. Bir bloğu yayınlamadan önce ağı yanlış onaylar için kontrol edin. Bu değişikliklerin kombinasyonu, onaylayıcıların çoğunluğunun artık yukarıda açıklanan dürüst yeniden düzenleme stratejisini kullanması gerçeğiyle daha da kötüleşen bir fikir birliği istikrarsızlığına yol açtı.
İSTENMEYEN SONUÇLAR
Her şeyden önce beş değişiklik, geçiş bloğu düzenlemesinin sıcak yolunda gecikmelere neden olur ve bu da geçiş bloklarının son onay tarihinden sonra yayınlanma olasılığını artırır. Aşağıdaki diyagram, bu beş kontrolün sırasını ve tanıtılan gecikmenin, blok yayının onay son tarihini aşmasına nasıl neden olduğunu göstermektedir.
Gecikmesi t = 0 olan (ör. t = 3) çok sayıda imzalı başlık, genellikle bu kontroller uygulanana kadar sorun yaratmaz. Rölenin ek yükü çok düşük olduğu için, onay son tarihini beklemeden bloğu t = 4'ten önce yayınlayacaktır.
Bununla birlikte, bu beş yamanın gecikmeli olarak kullanıma sunulması nedeniyle, röle artık geciken yayından kısmen sorumlu olabilir. Aşağıdaki varsayımsal blok yayınlama sürecine bakalım.
Röle, t = 3'te blok üreticisinden imzalı başlığı alır. t = 4'e göre, röle hala kontrol yapıyor, bu nedenle yayın, son onay tarihinden sonra gerçekleşecek. Bu durumda, blok üreticisi tarafından gönderilen gecikmeli imzalı başlık ile geçiş tarafından getirilen bazı ek gecikmelerin birleşimi, son onay tarihinden önce yayının yapılamamasına neden oldu. Dürüst bir yeniden yapılanma olmasaydı, bu bloklar muhtemelen zincirin üzerine çıkacaktı. Şekil 2'de gösterildiği gibi, bir sonraki yuvanın dürüst blok üreticileri, bu bloklar geciktiği için kasıtlı olarak yeniden organize olmayacaklardır. Ancak onay süresinin kaçırılması durumunda bloklar bir sonraki blok üreticisi tarafından yeniden düzenlenecektir.
Sonuç olarak, saldırıyı takip eden günlerde çatallı blokların sayısı önemli ölçüde arttı.
Metrika'nın iki haftalık verileri, en kötü durum senaryosunda, normal oranın yaklaşık 5 katı olan bir saat içinde 13 bloğun (%4,3) yeniden düzenlenebileceğini gösterdi. Çatallı blokların sayısındaki çarpıcı artış, aktarıcılar çeşitli değişiklikler yaptıkça ortaya çıktı. Aktarma operatörlerinin ve çekirdek geliştiricilerin büyük topluluk çabaları sayesinde, etki bilindiğinde, birçok değişiklik geri alındı ve ağ sağlıklı bir duruma geri getirildi.
Bugün itibariyle en yararlı değişiklikler, yayınlanmadan önce beacon node blok doğrulama ve ret kontrolleridir. Kötü amaçlı blok üreticileri, geçişlere geçersiz başlıklar göndererek ve geçiş işaret düğümlerinin reddedilen blokları yayınlamadan önce görmemesini sağlayarak artık saldırı gerçekleştiremez. Yine de röleler, MEV-Boost ve ePBS'de önerilen daha genel saldırı engellemeyle karşı karşıyadır.
Sonraki eylem
Bu yazıda, MEV-Boost'un nasıl çalıştığını ve Ethereum mutabakatı için ne kadar kritik olduğunu vurguluyoruz. Ayrıca, zamanlamayla ilgili Ethereum çatal seçim kurallarının daha az bilinen bazı yönlerinin ayrıntılı bir analizini sunuyoruz. "Ayrıştırma" saldırısını ve geliştirici yanıtlarını bir vaka çalışması olarak kullanarak, çatal seçim kuralının zamanlamayla ilgili yönlerinin potansiyel güvenlik açığını ve bunun ağ kararlılığı üzerindeki etkisini vurguluyoruz.
Bunu göz önünde bulundurarak, araştırma topluluğu, hafifletme önlemlerinin uygulanıp uygulanmayacağını belirlemek için, inkar saldırılarının daha genel açığa çıkışını dikkate alarak "kabul edilebilir" yeniden yapılanma sayısını değerlendirmelidir.
Ek olarak, şu anda aktif olarak araştırılan birkaç gelecek yönü var:
MEV-boost'u denklik hatası saldırılarından korumak için bir kafa kilitleme mekanizması uygulayın. Bu aynı zamanda mutabakat istemci yazılımında değişiklikler ve kanıt sunma son tarihini uzatmak için muhtemelen spesifikasyon değişiklikleri gerektirecektir.
MEV-Boost yazılımı için bug bounty programlarının sayısını ve dağıtımını artırmak.
Simülasyon yazılımını genişleterek alt yuva zamanlamasının ağ kararlılığını nasıl etkilediğini keşfedin; bu, yeniden düzenlemeyi azaltmak için kanıt gönderme son tarihlerinin nasıl ayarlanacağını değerlendirmek için kullanılabilir.
Gereksiz gecikmeleri azaltmak için röle üzerindeki blok serbest bırakma yolunu optimize edin - bu zaten araştırılmaktadır.
MEV-boost'u temel bir protokol özelliği olarak kabul edin ve onu mutabakat istemcisine, yani "enhrined-PBS (ePBS)"'ye dahil edin. İki yuvalı ePBS bariz saldırılara karşı savunmasızdır, bu nedenle bir "boyunduruk mekanizması" uygulamak hala bir seçenektir.
Gecikme ve sertifikasyon son tarihleriyle ilgili sorunlar etrafında daha fazla kovan ve/veya spesifikasyon testi ekleyerek.
Geçiş belirtiminin ek uygulamalarını oluşturarak geçiş istemcisi çeşitliliğini teşvik edin.
Bariz saldırılar için cezaları ayarlamayı düşünün, ancak aşırı MEV fırsatı söz konusu olduğunda tam bir 32 ETH cezasının bile kötü niyetli davranışı caydıramayacağını unutmayın.
Alt alan zamanlamasını yeniden gözden geçirin ve blok yayılım aşamasını ayarlamayı düşünün (örneğin, sertifikasyon son tarihini t=4'ten t=6'ya ayarlama).
Genel olarak, MEV'in ve mev-boost ekosisteminin yeniden dirilişi bizi heyecanlandırıyor. Saldırıları ve azaltmaları ayrıştırarak gecikme, MEV artırma ve fikir birliği mekanizmaları arasındaki kritik ilişkiyi öğrendik; protokolün bunun üstesinden gelmek için sağlamlaştırılmaya devam edeceğini umuyoruz.
View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
MEV-Boost çalışma prensibi ve Ethereum fork seçim kurallarının detaylı anlatımı
Yazar: Georgios Konstantopoulos, Mike Neuder
Derleme: Kxp, BlockBeats
Giriiş
2 Nisan'da kötü niyetli Ethereum ağ aktörleri, bir MEV arayıcısından 20 milyon dolar çalmak için MEV-Boost rölesindeki bir güvenlik açığından yararlandı (bkz. Flashbots raporu). Önümüzdeki birkaç gün içinde, geliştiriciler beş yama yayınlayarak bu güvenlik açığını giderdiler. Ağ gecikmeleri ve doğrulayıcı politikalarıyla birleşen bu yamalar, 6 Nisan'da Ethereum ağında kısa bir dalgalanmaya neden oldu. Blokları yeniden düzenlemek, blok üretim hızını yavaşlattığı ve yerleşim güvencelerini azalttığı için ağın sağlığına zarar verebilir.
Bu gönderide, Arayıcılar saldırı altındayken ve ağ geçici olarak istikrarsızken, MEV-Boost ile konsensüs arasındaki etkileşimi keşfediyor, Ethereum'un stake kanıtı mekanizmasının inceliklerini analiz ediyor ve ileriye dönük bazı olası adımları listeliyoruz.
MEV-Boost ve neden önemli
MEV-Boost, Flashbots ve topluluk tarafından Maksimum Çıkarılabilir Değerin (MEV) Ethereum ağı üzerindeki olumsuz etkisini azaltmak için tasarlanmış bir protokoldür.
MEV-Boost'ta 3 oyuncu var:
Röle - Blok üreticileri ile blok inşaatçılarını birbirine bağlayan, birbirine güvenen müzayedeciler
Yapıcılar - kendileri ve blok yaratıcıları için MEV'yi en üst düzeye çıkarmak için bloklar oluşturan karmaşık varlıklar
Blok üreticileri - Ethereum'un hisse kanıtı doğrulayıcıları
Her blok için yaklaşık olay sırası şöyledir:
Oluşturucular, kullanıcılardan, arama yapanlardan veya diğer (özel veya genel) sipariş akışlarından işlem alarak bir blok oluşturur.
Oluşturucu, bloğu aktarıcıya gönderir
Röle, bloğun geçerliliğini doğrular ve blok üreticisine ödediği tutarı hesaplar.
Aktarıcı, mevcut slotun blok üreticisine boş bir başlık ve ödeme değeri gönderir.
Blok Üreticileri aldıkları tüm teklifleri değerlendirir ve en yüksek ödeme ile ilgili boş başlığı imzalar.
Blok üreticisi bu imzalı başlığı röleye geri gönderir.
Röleler, yerel işaret düğümlerini kullanarak bloklar yayınlar ve bunları blok verene geri gönderir. Ödüller, bloklar içindeki işlemler ve blok ödülleri yoluyla inşaatçılara ve teklif verenlere dağıtılır.
Röle, blok üreticileri tarafından blok alanı adil bir şekilde değiş tokuş edilmesini ve inşaatçılar tarafından MEV çıkarımı için işlem siparişi verilmesini kolaylaştıran güvenilir bir üçüncü taraftır. Röleler, inşaatçıları MEV hırsızlığından koruyarak inşaatçıları korur ve blok üreticilerinin, onu bulan arayıcılara/inşaatçılara dağıtmadan MEV'i alıp götürmek için inşaatçı işlemlerini kopyalamasını engeller. Röleler, blok üreticilerini, bloklarının geçerliliğini onaylayarak, yuva başına yüzlerce bloğu onlar adına işleyerek ve blok üreticisi ödemelerinin doğruluğunu sağlayarak korur.
MEV-Boost, tüm blok üreticilerinin, Ethereum'un uzun vadeli ademi merkeziyetçiliğine katkıda bulunan, oluşturucular veya arama yapanlarla bir güven ilişkisi gerektirmeden MEV'ye demokratik bir şekilde erişmesini sağladığı için kilit protokol altyapısıdır.
Ethereum'un çatal seçim kuralları ve MEV-Boost
Saldırıyı ve yanıtı tartışmadan önce, Ethereum'un proof-of-stake mekanizmasına ve ilgili çatal seçim kurallarına bir göz atalım. Çatal seçim kuralı, "Ethereum birleşme sonrası yeniden yapılanma" makalesinde tanımlandığı gibi, ağın zincir başı üzerinde fikir birliğine varmasını sağlar:
"Çatal seçim kuralı, müşteri tarafından değerlendirilen, görülen blokları ve diğer bilgileri girdi olarak alan ve "kanonik zinciri" müşteriye veren bir işlevdir. Çatal seçim kuralı önemlidir, çünkü aralarından seçim yapılabilecek birden çok geçerli zincir olabilir (örneğin, aynı üst bloğa sahip iki rakip blok aynı anda yayınlanırsa). "
Çatal seçim kuralları da blok üretimi üzerinde önemli bir etkiye sahip olan zamana bağlıdır.
slot ve alt slot döngüsü
Ethereum'un proof-of-stake mekanizmasında, zaman her 12 saniyede bir yuvalara bölünür. Proof-of-stake algoritması rastgele bir doğrulayıcıya o yuva içinde bir blok önermesi için bir lisans atar; bu doğrulayıcıya blok üreticisi denir. Aynı yuva içinde, diğer doğrulayıcılara yerel görüşlerine göre çatal seçimi kurallarını uygulayan zincir başkanı için doğrulama (oylama) görevi atanır. Bu 12 saniyelik dilim, her biri 4 saniyeye mal olan üç aşamaya bölünmüştür.
Yuvada meydana gelen olaylar aşağıdaki gibidir, burada t=0, yuvanın başlangıcını gösterir.
Yuva sırasında en kritik an, t=4'teki kimlik doğrulama son tarihidir. Tasdik eden doğrulayıcılar, tasdik son tarihine kadar bloğu görmezlerse, zincirin daha önce kabul edilen başkanına (çatal seçim kuralına göre) oy vereceklerdir. Bir blok ne kadar erken teklif edilirse, yayılması ve dolayısıyla daha fazla onay alması için o kadar fazla zaman gerekir (çünkü daha fazla onaylayıcı bunu son onay tarihinden önce görür).
Bir ağ sağlığı perspektifinden, bir bloğun serbest bırakılması için en uygun zaman t=0'dır (spesifikasyona göre). Bununla birlikte, blok değeri zaman içinde tekdüze bir şekilde arttığından, blok üreticilerinin bloklarının piyasaya sürülmesini geciktirme teşviki vardır, böylece daha fazla MEV birikebilir. Ayrıntılar için Proof-of-Stake'te Zamanlama oyunlarına ve bu tartışmaya bakın.
Daha önce, bir blok üreticisi, bir sonraki doğrulayıcı sonraki slotu için bloğu oluşturmadan önce bloğu gözlemlediği sürece, sertifikasyon son tarihinden sonra (hatta slotun sonuna yakın) bir blok yayınlayabilirdi. Bunun nedeni alt bloğun üst bloğun ağırlığını devralmasıdır ve çatal seçim kuralı yaprak düğümde sona erer. Bu nedenle, blok yayınlarını ertelemenin hiçbir yan etkisi yoktur. Rasyonel davranışı (blok sürümlerini erteleme) dürüst davranışa (zamanında yayınlama) kaydırmaya yardımcı olmak için bir "dürüst yeniden düzenleme" uygulandı.
Blok Yapımcı Ödül Mekanizması ve Dürüst Yeniden Düzenleme
Konsensüs istemcisine, kimlik doğrulama son tarihi üzerinde kritik bir etkiye sahip olan iki yeni kavram eklenmiştir.
Blok Üreticisi Ödül Mekanizması - Blok üreticilerine tam kimlik doğrulama ağırlığının %40'ına eşit bir çatal seçimi "ödülü" vererek yeniden dengeleme saldırılarını en aza indirmeyi amaçlar. Daha da önemlisi, bu ödül yalnızca slotun tamamı için geçerlidir.
Dürüst yeniden düzenleme - dürüst blok üreticilerinin kimlik doğrulama ağırlıkları %20'nin altında olan blokları yeniden düzenlemeye zorlamalarına izin veren blok üreticisi hızlandırmasından yararlanın. Bu, Lighthouse ve Prysm'de zaten uygulanmaktadır (v4.0 - Capella sürümünden başlayarak). Bu değişiklik isteğe bağlıdır çünkü blok üreticileri tarafından verilen bir karardır ve doğrulayıcıların kimliğini doğrulama davranışını etkilemez. Bu nedenle, bunu tüm istemcilere aynı anda uygulamıyoruz ve belirli bir hard fork'a bağlı değil.
Bazı özel durumlarda dürüst yeniden düzenlemeden kaçınıldığına dikkat edilmelidir:
Dönem sınır blokları sırasında
Zincir tamamlanmadıysa
Yeniden düzenlemeden önce zincirin başı yuvanın başı değilse
Durum 3, dürüst yeniden düzenlemelerin zincirden yalnızca bir bloğu kaldırmasını sağlar; bu blok, bir devre kesici görevi görerek, aşırı ağ gecikmesi dönemlerinde zincirin blok üretmeye devam etmesine izin verir. Ayrıca, önerilen gelişmiş blokların norm olarak kabul edilip edilmeyeceğinden emin olamadıklarından, teklif verenlerin ağın algısına daha az güvendiklerini de yansıtır.
Aşağıdaki şekil, bir yeniden yapılandırma stratejisi uygulamak için dürüst davranışın nasıl değiştirilebileceğini göstermektedir.
Bu durumda, b1 bir geç bloğu temsil etsin. Gecikme nedeniyle, b1, n'inci yuvanın kanıt ağırlığının yalnızca %19'una sahiptir. Prova ağırlığının kalan %81'lik kısmı HEAD ana bloğuna atanır çünkü birçok provacı b1'i prova son tarihinden önce görmemiştir.
Dürüst bir yeniden düzenleme yoksa, n+1 dilimini öneren kişi b1'i zincirin başı olarak kabul edecek ve b2 alt bloğunu oluşturacaktır. Öneri sahibi, yalnızca %19 kanıt ağırlığına sahip olmasına rağmen b1'i yeniden düzenlemek için hiçbir çaba göstermedi. n+1 slotunda, b2 teklif verenin geliştirmesine sahiptir, zamanında teslim edildiği varsayılırsa, b2 o slot için kanıtların çoğunu toplayarak norm haline gelecektir.
Dürüst Yeniden Yapılanma ile işler çok farklı. Şimdi, slot n+1'i öneren kişi, b1'in kanıt ağırlıklarının %19'unun yeniden düzenleme eşiğinin altında olduğunu görür, bu nedenle üst öğe olarak HEAD ile bir blok oluşturur ve b1'i yeniden düzenlemeye zorlar. Yuva n+1 için kanıtlama son tarihine ulaştığımızda, dürüst kanıtlayıcı b1'in (%19) ve b2'nin (teklif edenin desteğinden %40) göreli ağırlıklarını karşılaştıracaktır. Tüm müşteriler, teklif veren geliştirmesini uygular, bu nedenle b2, zincirin başı olarak kabul edilecek ve n+1 yuvası için kanıtları toplayacaktır.
Ayrışma saldırıları için Aktarma ve İşaret düğümü düzeltmeleri
2 Nisan'daki ayrıştırma saldırısında, teklif sahibi geçişe geçersiz bir imza başlığı göndermek için bir geçiş güvenlik açığından yararlandı. Sonraki birkaç gün içinde geçiş ve çekirdek geliştirme ekipleri, tekrarlanan saldırı riskini azaltmak için çok sayıda yazılım yaması yayınladı. Beş ana değişiklik aşağıdaki gibidir:
Röle Değişiklikleri: Bilinen kötü niyetli teklifçiler için veritabanını kontrol edin (yalnızca Ultrasonic Relay tarafından üretimde kullanılır ve kaldırılmıştır). Rölenin tüm bloğu P2P ağındaki bir yuvaya teslim edip etmediğini kontrol eder. Bir blok yayınlanmadan önce 0-500 ms aralığında tekdüze bir rasgele gecikme sunar (tüm rölelerden kaldırılır).
İşaret düğümü değişikliği (yalnızca röle işaret düğümleri): Yayından önce işaret bloklarını doğrulayın. Bir bloğu yayınlamadan önce ağı yanlış onaylar için kontrol edin. Bu değişikliklerin kombinasyonu, onaylayıcıların çoğunluğunun artık yukarıda açıklanan dürüst yeniden düzenleme stratejisini kullanması gerçeğiyle daha da kötüleşen bir fikir birliği istikrarsızlığına yol açtı.
İSTENMEYEN SONUÇLAR
Her şeyden önce beş değişiklik, geçiş bloğu düzenlemesinin sıcak yolunda gecikmelere neden olur ve bu da geçiş bloklarının son onay tarihinden sonra yayınlanma olasılığını artırır. Aşağıdaki diyagram, bu beş kontrolün sırasını ve tanıtılan gecikmenin, blok yayının onay son tarihini aşmasına nasıl neden olduğunu göstermektedir.
Gecikmesi t = 0 olan (ör. t = 3) çok sayıda imzalı başlık, genellikle bu kontroller uygulanana kadar sorun yaratmaz. Rölenin ek yükü çok düşük olduğu için, onay son tarihini beklemeden bloğu t = 4'ten önce yayınlayacaktır.
Bununla birlikte, bu beş yamanın gecikmeli olarak kullanıma sunulması nedeniyle, röle artık geciken yayından kısmen sorumlu olabilir. Aşağıdaki varsayımsal blok yayınlama sürecine bakalım.
Röle, t = 3'te blok üreticisinden imzalı başlığı alır. t = 4'e göre, röle hala kontrol yapıyor, bu nedenle yayın, son onay tarihinden sonra gerçekleşecek. Bu durumda, blok üreticisi tarafından gönderilen gecikmeli imzalı başlık ile geçiş tarafından getirilen bazı ek gecikmelerin birleşimi, son onay tarihinden önce yayının yapılamamasına neden oldu. Dürüst bir yeniden yapılanma olmasaydı, bu bloklar muhtemelen zincirin üzerine çıkacaktı. Şekil 2'de gösterildiği gibi, bir sonraki yuvanın dürüst blok üreticileri, bu bloklar geciktiği için kasıtlı olarak yeniden organize olmayacaklardır. Ancak onay süresinin kaçırılması durumunda bloklar bir sonraki blok üreticisi tarafından yeniden düzenlenecektir.
Sonuç olarak, saldırıyı takip eden günlerde çatallı blokların sayısı önemli ölçüde arttı.
Metrika'nın iki haftalık verileri, en kötü durum senaryosunda, normal oranın yaklaşık 5 katı olan bir saat içinde 13 bloğun (%4,3) yeniden düzenlenebileceğini gösterdi. Çatallı blokların sayısındaki çarpıcı artış, aktarıcılar çeşitli değişiklikler yaptıkça ortaya çıktı. Aktarma operatörlerinin ve çekirdek geliştiricilerin büyük topluluk çabaları sayesinde, etki bilindiğinde, birçok değişiklik geri alındı ve ağ sağlıklı bir duruma geri getirildi.
Bugün itibariyle en yararlı değişiklikler, yayınlanmadan önce beacon node blok doğrulama ve ret kontrolleridir. Kötü amaçlı blok üreticileri, geçişlere geçersiz başlıklar göndererek ve geçiş işaret düğümlerinin reddedilen blokları yayınlamadan önce görmemesini sağlayarak artık saldırı gerçekleştiremez. Yine de röleler, MEV-Boost ve ePBS'de önerilen daha genel saldırı engellemeyle karşı karşıyadır.
Sonraki eylem
Bu yazıda, MEV-Boost'un nasıl çalıştığını ve Ethereum mutabakatı için ne kadar kritik olduğunu vurguluyoruz. Ayrıca, zamanlamayla ilgili Ethereum çatal seçim kurallarının daha az bilinen bazı yönlerinin ayrıntılı bir analizini sunuyoruz. "Ayrıştırma" saldırısını ve geliştirici yanıtlarını bir vaka çalışması olarak kullanarak, çatal seçim kuralının zamanlamayla ilgili yönlerinin potansiyel güvenlik açığını ve bunun ağ kararlılığı üzerindeki etkisini vurguluyoruz.
Bunu göz önünde bulundurarak, araştırma topluluğu, hafifletme önlemlerinin uygulanıp uygulanmayacağını belirlemek için, inkar saldırılarının daha genel açığa çıkışını dikkate alarak "kabul edilebilir" yeniden yapılanma sayısını değerlendirmelidir.
Ek olarak, şu anda aktif olarak araştırılan birkaç gelecek yönü var:
MEV-boost'u denklik hatası saldırılarından korumak için bir kafa kilitleme mekanizması uygulayın. Bu aynı zamanda mutabakat istemci yazılımında değişiklikler ve kanıt sunma son tarihini uzatmak için muhtemelen spesifikasyon değişiklikleri gerektirecektir.
MEV-Boost yazılımı için bug bounty programlarının sayısını ve dağıtımını artırmak.
Simülasyon yazılımını genişleterek alt yuva zamanlamasının ağ kararlılığını nasıl etkilediğini keşfedin; bu, yeniden düzenlemeyi azaltmak için kanıt gönderme son tarihlerinin nasıl ayarlanacağını değerlendirmek için kullanılabilir.
Gereksiz gecikmeleri azaltmak için röle üzerindeki blok serbest bırakma yolunu optimize edin - bu zaten araştırılmaktadır.
MEV-boost'u temel bir protokol özelliği olarak kabul edin ve onu mutabakat istemcisine, yani "enhrined-PBS (ePBS)"'ye dahil edin. İki yuvalı ePBS bariz saldırılara karşı savunmasızdır, bu nedenle bir "boyunduruk mekanizması" uygulamak hala bir seçenektir.
Gecikme ve sertifikasyon son tarihleriyle ilgili sorunlar etrafında daha fazla kovan ve/veya spesifikasyon testi ekleyerek.
Geçiş belirtiminin ek uygulamalarını oluşturarak geçiş istemcisi çeşitliliğini teşvik edin.
Bariz saldırılar için cezaları ayarlamayı düşünün, ancak aşırı MEV fırsatı söz konusu olduğunda tam bir 32 ETH cezasının bile kötü niyetli davranışı caydıramayacağını unutmayın.
Alt alan zamanlamasını yeniden gözden geçirin ve blok yayılım aşamasını ayarlamayı düşünün (örneğin, sertifikasyon son tarihini t=4'ten t=6'ya ayarlama).
Genel olarak, MEV'in ve mev-boost ekosisteminin yeniden dirilişi bizi heyecanlandırıyor. Saldırıları ve azaltmaları ayrıştırarak gecikme, MEV artırma ve fikir birliği mekanizmaları arasındaki kritik ilişkiyi öğrendik; protokolün bunun üstesinden gelmek için sağlamlaştırılmaya devam edeceğini umuyoruz.