Điều gì đã phá vỡ bản nâng cấp Fusaka của Ethereum? Báo cáo hậu sự cố của Prysm tiết lộ nguyên nhân

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

Client đồng thuận đã gặp phải tình trạng cạn kiệt tài nguyên do việc tính toán lại trạng thái tốn kém khi xử lý các xác nhận cụ thể, khiến các validator phải đối mặt với các vấn đề hoạt động nghiêm trọng.

Lỗi xuất hiện ngay sau khi Fusaka được 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 đã bỏ lỡ 41 epochs khi tỷ lệ tham gia của validator giảm xuống còn 75%, dẫn đến mất khoảng 382 Ethereum (ETH) phần thưởng xác thực. 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 bản sửa lỗi vĩnh viễn trong 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 chung cuộc

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 nút bị ảnh hưởng.

Nhà phát triển cốt lõi của Prysm, Terence Tsao giải thích rằng "trạng thái lịch sử tiêu tốn nhiều bộ nhớ tính toán, một nút có thể bị tấn công bởi số lượng lớn các phát lại trạng thái xảy ra song song."

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

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

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

Bản nâng cấp Fusaka đã giới thiệu công nghệ PeerDAS (Peer Data Availability Sampling) được thiết kế để tăng dung lượng blob lên gấp tám lần cho khả năng mở rộng Layer 2.

Việc nâng cấp đã thực hiện thành công mà không có thời gian ngừng hoạt động 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 sự cố 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 tiếp tục xác thực các khối mà không bị gián đoạn.

Cấu trúc client phi tập trung 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 chung cuộc và giữ cho mạng tiếp tục xử lý các giao dịch bất chấp trạng thái suy giảm của Prysm.

Ethereum Foundation đã nhanh chóng đưa ra hướng dẫn khẩn cấp cho các nhà vận hành Prysm. Các validator đã áp dụng bản sửa lỗi 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, tỷ lệ tham gia của mạng đã phục hồi lên gần 99%, khôi phục hoạt động bình thường trong vòng 24 giờ sau sự cố.