Base’de 48 Saatte İki Kez Blok Üretimi Durdu: Sıralayıcı Hatasının Perde Arkası

Bu geçersiz blok, bir konsensüs hatasını tetikliyordu: sıralayıcı, blok 47.806.542'den sonra geçersiz bir blok ürettiği için ağ daha fazla blok üretemez hale geliyordu. Düğüm (node) operatörleri, sorun giderilene kadar normal senkronizasyona devam edemiyordu.

İki Kesintinin Zaman Çizelgesi

26 Haziran'daki ikinci kesinti, ilk olaydan kısa bir süre sonra tekrarlanan aynı türden bir blok üretim hatası olarak tanımlandı, ancak ağ bu sefer daha hızlı toparlandı.

Her iki kesinti sırasında da yeni bloklar dondu veya durduruldu ve zincir üstü işlemler aksadı. Ancak her iki olayda da kullanıcı fonlarının risk altında olmadığı bildirildi.

Uygulanan Çözüm

Base mühendislik ekibi, başarısız bir işlem sonrasında günlük durumunun doğru şekilde güncellenmesini sağlamak için sıralayıcıya bir yama (patch) uyguladı. Yama, GitHub üzerindeki genel bir pull request'te (#3806) takip edilebiliyor.

Yama sonrası normal işlemler devam etti ancak Base, doğrulayıcı-düğüm (validator node) operatörlerine senkronizasyon durumlarını düzeltmek için düğümlerini yeniden başlatmalarını veya yeniden senkronize etmelerini tavsiye etti. Ekip, her iki kesintinin de aynı hatadan kaynaklandığını ve ikinci, ilişkili bir sorunun (PR #3805) ertesi gün olayın tekrarlanmasına neden olduğunu belirtti.

Olayın ardından Base, ağı dengelemek için planlanan Beryl ana ağ (mainnet) yükseltmesini ve B20 token standardı aktivasyonunu bir gün geciktirdi.

Tek Sıralayıcı Mimarisi: Daha Büyük Bir Endişe

Ardı ardına yaşanan kesintiler, birçok iyimser toplama (optimistic rollup) için yaygın olan ancak bariz bir tek nokta arızası oluşturan Base'in tek sıralayıcılı tasarımının dayanıklılığı konusundaki tartışmaları yeniden alevlendirdi.

Rapor ve sektör yorumcuları tarafından öne çıkarılan başlıca endişeler şunlar:

• Tek nokta arızası: Blok oluşturma mantığındaki bir sıralayıcı hatası, Base'in tüm blok üretimini durdurabiliyor ve ağ genelinde yeni blokların oluşmasını engelliyor.
• Manuel kurtarma: Ağın kendi kendini iyileştirmesi mümkün olmadı; kurtarma için doğrulayıcı-düğüm operatörlerinin düğümlerini manuel olarak yeniden başlatması veya yeniden senkronize etmesi gerekti.
• Güvenilirlik riski: Art arda gelen arızalar, hızla büyüyen Katman-2 ekosisteminin güvenilirliği hakkında, özellikle yüksek işlem hacmi veya planlı yükseltme dönemlerinde, yeni soru işaretleri doğurdu.
• Planlanan iyileştirmeler: Base, tekrarlanma olasılığını azaltmak için fuzz testleri, yük testleri, izleme ve daha iyi kurtarma araçları ile test süreçlerini güçlendireceğini açıkladı.

Bu olay, en büyük Ethereum Katman-2 ağlarının bile tek bir sıralayıcıdaki bir durum yönetimi uç durumu (edge case) nedeniyle çevrimdışı kalabileceğini ve otomatik yedekleme ile kurtarma sistemlerinin toplama (rollup) ekosisteminde hala geliştirme aşamasında olduğunu gösterdi.