Điều gì đã khiến nâng cấp Fusaka của Ethereum gặp sự cố? Phân tích hậu sự kiện của Prysm tiết lộ nguyên nhân

Các nhà phát triển Prysm đã phát hành bài phân tích hậu sự cố giải thích về sự cố mainnet Fusaka ngày 4 tháng 12 đã đe dọa đến sự ổn định của mạng Ethereum.
Tóm tắt

• Một lỗi Prysm sau Fusaka khiến sự tham gia của validator giảm xuống còn 75%.
• Mạng lỡ 41 epoch và mất khoảng 382 ETH trong phần thưởng bằng chứng.
• Ethereum tránh được mất tính cuối cùng nhờ đa dạng client và các sửa lỗi nhanh chóng.

Client đồng thuận gặp phải tình trạng cạn kiệt tài nguyên do tính toán lại trạng thái đắt đỏ khi xử lý các attestations cụ thể, gây ra các vấn đề vận hành nghiêm trọng cho validator.

Lỗi này xuất hiện ngay sau khi Fusaka kích hoạt tại epoch 411392 vào ngày 4 tháng 12 năm 2025, lúc 21:49 UTC.

Mạng lỡ 41 epoch khi sự tham gia của validator giảm xuống còn 75%, dẫn đến mất khoảng 382 ETH trong phần thưởng bằng chứng. Các nhà phát triển Prysm đã triển khai các cờ runtime khẩn cấp trước khi thực hiện các sửa lỗi vĩnh viễn trong các phiên bản v7.0.1 và v7.1.0.

Cạn kiệt tài nguyên đẩy mạng đến gần mất tính cuối cùng

Sự cố kỹ thuật tập trung vào các trạng thái lịch sử lỗi thời đã tạo ra các điều kiện từ chối dịch vụ trên các node bị ảnh hưởng.

Nhà phát triển cốt lõi Prysm Terence Tsao giải thích rằng “trạng thái lịch sử là bộ nhớ tính toán nặng, một node có thể bị tấn công từ số lượng lớn các lần phát lại trạng thái diễn ra đồng thời.”

Các validator chạy Prysm, chiếm khoảng 15% đến 22.71% các validator của mạng, đã gặp phải sự suy giảm hiệu suất nghiêm trọng. Sự giảm tham gia từ mức bình thường trên 95% xuống còn 75% đã đẩy Ethereum đến gần mất tính cuối cùng một cách nguy hiểm.

Nếu lỗi này ảnh hưởng đến một client đồng thuận khác như Lighthouse thay vì Prysm, mạng có thể đã mất tính cuối cùng hoàn toàn.

Một sự kiện như vậy có thể làm đóng băng các hoạt động Layer 2 rollup và chặn rút validator cho đến khi các nhà phát triển giải quyết vấn đề.

Cập nhật Fusaka đã giới thiệu công nghệ PeerDAS (Peer Data Availability Sampling) nhằm tăng khả năng chứa blob gấp tám lần để mở rộng Layer 2.

Việc nâng cấp đã thành công với thời gian chết bằng 0 trước khi lỗi Prysm xuất hiện.

Mười client đồng thuận đã ngăn chặn sự sụp đổ của mạng Ethereum

Kiến trúc đa dạng client của Ethereum đã ngăn chặn thất bại thảm khốc. Trong khi các validator Prysm gặp khó khăn, mười client đồng thuận khác bao gồm Lighthouse, Nimbus, và Teku vẫn tiếp tục xác thực các block mà không bị gián đoạn.

Cấu trúc client phi tập trung này có nghĩa là khoảng 75% đến 85% validator duy trì hoạt động bình thường trong suốt cuộc khủng hoảng. Điều này đã ngăn chặn mất tính cuối cùng và giữ cho mạng xử lý các giao dịch mặc dù trạng thái Prysm bị suy giảm.

Quỹ Ethereum đã nhanh chóng phát hành hướng dẫn khẩn cấp cho các nhà vận hành Prysm. Các validator đã áp dụng sửa tạm thời trong khi các nhà phát triển Prysm xây dựng các giải pháp vĩnh viễn.

Đến ngày 5 tháng 12, sự tham gia của mạng đã phục hồi gần 99%, khôi phục hoạt động bình thường trong vòng 24 giờ sau sự cố.