Các validator Ethereum được khuyến nghị tắt Prysm do rủi ro trạng thái lỗi thời

Các nhà vận hành validator Ethereum sử dụng client đồng thuận Prysm đã nhận được một cảnh báo khẩn cấp vào ngày 4 tháng 12. Nhóm Prysm xác nhận rằng một số node đang tạo ra các trạng thái cũ để xử lý các xác thực lỗi thời. Điều này có thể dẫn đến hành vi xác thực không chính xác nếu không được kiểm soát. Để ngăn chặn tình trạng này, Prysm đã yêu cầu tất cả các nhà vận hành tắt ngay một chức năng cụ thể bằng cách thêm một cờ duy nhất vào beacon node của họ. Bản sửa lỗi này không yêu cầu nâng cấp toàn bộ client và không ảnh hưởng đến các client validator.

Nhóm đã hướng dẫn các nhà vận hành thêm dòng này: –disable-last-epoch-targets. Cờ này hoạt động với Prysm v7.0.0, nghĩa là hầu hết các node có thể áp dụng bản sửa lỗi trong vài phút. Cảnh báo này đã kích hoạt phản ứng nhanh chóng trên toàn cộng đồng validator. Điều này phản ánh dấu ấn lớn của Prysm trong lớp đồng thuận của Ethereum.

Thị phần của Prysm biến sự cố này thành sự kiện cấp mạng lưới

Dữ liệu từ MigaLabs cho thấy Prysm chiếm gần 20% thị phần client đồng thuận của Ethereum. Điều này khiến nó trở thành client lớn thứ hai, chỉ sau Lighthouse. Quy mô này đã biến một lỗi phía client thành mối quan tâm trên toàn bộ chuỗi. Khi một client có sức nặng như vậy xử lý dữ liệu trạng thái lỗi thời, nó không chỉ ảnh hưởng đến một validator. Nó có thể lan rộng thành:

• Bỏ lỡ xác thực (missed attestations)
• Tín hiệu lựa chọn fork không chính xác
• Nguy cơ bị phạt hoặc bị cắt giảm (slashing) tăng lên trong các trường hợp rủi ro

Cho đến nay, chưa có bằng chứng về việc chuỗi ngừng hoạt động trực tiếp hoặc thất bại về tính cuối cùng liên quan đến sự cố này. Tuy nhiên, mối quan tâm chỉ liên quan đến phòng ngừa rủi ro, không phải kiểm soát thiệt hại. Prysm đã hành động trước khi tình hình leo thang. Nói cách khác, đây là một cuộc diễn tập phòng cháy chủ động, không phải dọn dẹp sau sự cố.

Chính xác thì điều gì đã xảy ra bên trong Prysm

Theo nhóm Prysm, các node bị ảnh hưởng đã tạo ra các trạng thái cũ không cần thiết khi cố gắng xử lý các xác thực lỗi thời từ các epoch trước đó. Hành vi này làm tăng áp lực lên CPU và bộ nhớ, đồng thời có thể làm sai lệch cách một node theo dõi tiến trình chuỗi khi bị căng thẳng. Kiểu hành vi này không mới trong lịch sử Ethereum. Các sự cố tương tự về xử lý trạng thái đã xuất hiện trong:

• Sự cố tính cuối cùng vào tháng 5 năm 2023
• Các lỗi hỏng chỉ mục cơ sở dữ liệu trước đây
• Các vấn đề đột biến bộ nhớ ở nhiều client khác nhau

Sự khác biệt chính lần này là tốc độ. Prysm phát hiện vấn đề sớm, công bố giải pháp tạm thời chỉ với một bước. Ngoài ra, tránh việc ép hàng nghìn validator phải nâng cấp client vội vàng.

Validator nên làm gì ngay bây giờ

Nếu bạn đang chạy Prysm, danh sách kiểm tra rất ngắn và khẩn cấp:

• Thêm cờ –disable-last-epoch-targets
• Khởi động lại beacon node
• Kiểm tra log để xác nhận luồng xác thực bình thường
• Theo dõi bộ nhớ và CPU sau khi khởi động lại

Không cần thay đổi khóa validator. Không cần đồng bộ lại và không cần thoát. Đối với toàn bộ Ethereum, sự kiện này nhấn mạnh một sự thật quen thuộc: đa dạng client vẫn rất quan trọng. Khi một client nắm giữ gần 20% mạng lưới, ngay cả một lỗi có thể kiểm soát cũng trở thành sự kiện lớn. Tuy nhiên, sự cố này cũng cho thấy sự trưởng thành trong vận hành của Ethereum. Vấn đề đã được xác định, công bố và khắc phục trong vòng vài giờ, không phải vài ngày. Đó là cách một lớp thanh toán trị giá hơn $400 tỷ vẫn giữ được sự kiên cường. Hiện tại, chuỗi vẫn ổn định. Hạn chót duy nhất là các nhà vận hành Prysm phải hành động nhanh và bật công tắc an toàn.