Ethereum Konsensüs katmanı iki gece ardışık kısa anormallik analizi

Son günlerde, Ethereum konsensüs katmanında kısa süreli bir anormallik meydana geldi ve bu durum sektörde geniş bir ilgi uyandırdı. Bu yazıda, bu olayı derinlemesine analiz edeceğiz.

Olay Özeti

11 ve 12 Mayıs tarihlerinde, Ethereum konsensüs katmanında kısa süreli bir anormallik meydana geldi. Analizler, bunun esasen bazı Ethereum konsensüs katmanı istemci düğümlerinin aşırı yüklenmesinden kaynaklandığını göstermektedir. Bu, doğrulayıcı düğüm (Validator)'in çökmesine ve çevrimdışı kalmasına neden olmuştur. Bu durum, Epoch oylamasını doğrudan etkilemiş ve gerekli 2/3 eşik değerine ulaşmasını engelleyerek konsensüs katmanının nihai onayı doğrulamasını sağlamamıştır.

Dikkate değer olan, anormal durumlara rağmen, Ethereum ağının kısa bir süre içinde kendini normale döndürmesidir. Bu, Ethereum'un PoS konsensüs algoritmasının dayanıklılığını ve kendini onarma yeteneğini göstermektedir.

Olay Ayrıntıları

Genellikle, Ethereum PoS konsensüs ağı durumu 2 Epoch içinde kesinleşir (Finalized). Ancak geçen hafta yaşanan iki olayda, Epoch kesinleşmesinde gecikme oldu:

• 11 Mayıs: Epoch 3 Epoch gecikti, yaklaşık 20 dakika.
• 12 Mayıs: Epoch, 8 Epoch kadar, yaklaşık 51 dakika gecikti.

Epoch zamanında kesinleşemediği halde, Ethereum ağı hâlâ bloklar üretmeye ve işlemleri işlemeye devam ediyor. Ancak, doğrulayıcı düğümlerin oy verme oranının yetersizliği nedeniyle, Epoch Ethereum PoS ağının konsensüs düzeyi güvenlik garantisini elde edemiyor.

Şunu belirtmek gerekir ki, ikinci olayda, onay süresinin belirlenen eşik değeri aşması nedeniyle Ethereum konsensüs algoritmasının Inactivity leak mekanizması devreye girdi. Bu, yaklaşık 28 ETH'nin cezalandırılmasına ve yaklaşık 50 ETH'nin ihraç edilmemesine neden oldu.

Sebep Analizi

Bu iki olayın doğrudan nedeni, bazı Ethereum konsensüs katmanı istemci düğümlerinin aşırı yüklenmesi, bu da doğrulayıcı düğümlerin çökmesine ve çevrimdışı kalmasına, konsensüs oylamasını normal bir şekilde gerçekleştirememesine yol açmıştır. Daha spesifik olarak:

1. Düğüm, eski bir bloğa işaret eden ( Attestation ) aldığında, bu tanıkları doğrulamak için beacon zincirinin durumunu yeniden hesaplaması gerekir, bu süreç büyük miktarda CPU ve bellek kaynağı gerektirir.

2. Eski bloklara yönlendiren çok sayıda tanıklık alındığında, düğümün kaynakları tükenir ve doğrulama düğümü çevrimdışı kalır.

3. Bu tür sorunlar, bloklara işaret eden bir tanık temelli önbellekle çözülse de, doğrulayıcı düğümlerin sayısının artması ve bu tür çok sayıda attestation'ın ortaya çıkması, sorunlu istemci uygulamalarının önbelleğinin aşılmasına neden olmuştur.

Şu anda, Konsensüs katmanı istemcisi Teku ve Prysm, bu sorunu çözmek için yaman versiyonlar yayımladı. Yaman versiyon, bu eski tanıkları filtreleyecek; tanık eski bir Slot'a işaret ettiğinde veya düğümün daha önce hiç görmediği bir Checkpoint'e işaret ettiğinde, bu tanığı göz ardı edecektir.

Ethereum tasarım avantajları

Bu olayda, Ethereum tasarım avantajını gösterdi:

1. İstemci çeşitliliği: Farklı istemcilerin uygulama tasarımları farklıdır, bu nedenle bazı istemciler sorun yaşasa bile, diğer istemcilerin normal çalışmasını etkilemez.

2. Gasper algoritması tasarımı: Blok üretimini ve onaylamayı ayırır, blok onayı engellense bile blok üretimi durmaz, ağın kullanılabilirliğini garanti eder.

Deneyim ve İpuçları

1. Müşteri çeşitliliği hala güçlendirilmeli: Şu anda Ethereum istemci çeşitliliğinde iyileştirme alanları mevcut; özellikle yürütme katmanı istemcileri Geth'e yoğunlaşmış durumda ve bu oran %61'e kadar çıkıyor, bu da potansiyel riskler taşıyor.

2. İstemci değiştirme mekanizmasının geliştirilmesi gerekiyor: Bir istemcinin bir sorun yaşaması durumunda, normal bir istemci uygulamasına güvenli bir şekilde geçiş yapmak hala bir zorluk.

3. Konsensüs izleme güçlendirilmelidir: Ethereum PoS ağının gerçek zamanlı durumunu sürekli izleyen Safe Head benzeri hizmetlere ihtiyaç vardır, anormallikleri zamanında tespit edip uyarı vermek için.

4. Kullanıcı eğitimini güçlendirin: Ethereum PoS konsensüs mekanizmasını açıklayın, kullanıcıların gereksiz panik yapmalarını önleyin.

5. Uygulama katmanının hazırlıklı olması gerekir: Layer2, borsa, Oracle gibi uygulamalar, ağın kararsız olduğu durumları doğru bir şekilde ele almalıdır, örneğin onay süresini uygun bir şekilde uzatmalı veya hizmeti durdurmalıdır.

Özet

Bu olay, Ethereum'un PoS Konsensüs algoritmasının dayanıklılığını ve kendini onarma yeteneğini gösterirken, aynı zamanda geliştirilmesi gereken bazı yönleri de ortaya koydu. Gelecekte, Ethereum ekosisteminin istemci çeşitliliği, ağ izleme, kullanıcı eğitimi gibi alanlara sürekli yatırım yapması gerekecek; bu, tüm ağın istikrarını ve güvenilirliğini artırmak içindir.