Phân tích bất thường ngắn hạn của Ethereum trong hai đêm liên tiếp

Vào tối ngày 11 và 12 tháng 5, lớp đồng thuận Ethereum đã xuất hiện sự cố tạm thời. Phân tích cho thấy, nguyên nhân chủ yếu là do một số nút máy khách lớp đồng thuận Ethereum bị quá tải, dẫn đến việc các nút xác thực bị ngắt kết nối. Điều này đã ảnh hưởng trực tiếp đến việc bỏ phiếu Epoch không thể đạt ngưỡng 2/3, khiến lớp đồng thuận không thể xác nhận tính cuối cùng. Tuy nhiên, mạng Ethereum đã tự phục hồi bình thường trong thời gian ngắn, điều này cũng thể hiện độ bền và khả năng tự sửa chữa của thuật toán đồng thuận PoS của Ethereum.

Tóm tắt sự kiện

Thông thường, trạng thái mạng đồng thuận PoS của Ethereum sẽ được xác định trong 2 Epoch. Tuy nhiên, tuần trước đã xảy ra hai lần trì hoãn trong việc xác định Epoch:

• Ngày 11 tháng 5: Epoch đã bị hoãn lại 3 Epoch, khoảng 20 phút.
• Ngày 12 tháng 5: Epoch đã bị trì hoãn 8 Epoch, khoảng 51 phút.

Trong thời gian này, mạng Ethereum vẫn tiếp tục tạo ra các khối và xử lý giao dịch. Nhưng do tỷ lệ bỏ phiếu của các nút xác thực không đủ, Epoch không thể được xác nhận, tức là không thể đạt được bảo đảm an toàn cấp độ đồng thuận của mạng PoS Ethereum. Điều này có nghĩa là trong các trường hợp cực đoan, các giao dịch trong epoch đó có thể bị lật ngược.

Trên thực tế, trong khoảng thời gian này, mạng Ethereum không xảy ra phân nhánh, và các nút xác thực cũng không thực hiện bỏ phiếu ác ý. Sự ra đi của một lượng lớn các nút xác thực dẫn đến tỷ lệ bỏ phiếu không đủ là nguyên nhân trực tiếp khiến Epoch không thể được xác nhận. Quan sát cho thấy, các nút xác thực ngoại tuyến đã gặp phải tình trạng quá tải CPU.

Trong sự kiện thứ hai, do việc xác định bị trì hoãn hơn 4 Epoch, đã kích hoạt cơ chế rò rỉ hoạt động của thuật toán đồng thuận Ethereum:

• Phạt các nút xác thực ngoại tuyến, cắt giảm vốn staking của họ, khoảng 28 ETH bị tịch thu.
• Hủy bỏ phần thưởng Attestation, khoảng 50 ETH chưa được phát hành.
• Cơ chế này đảm bảo rằng các người xác thực trực tuyến cuối cùng có thể nắm giữ 2/3 tổng số tiền đặt cọc của Ethereum, từ đó trạng thái mạng cuối cùng có thể được xác định.

Phân tích nguyên nhân

Nguyên nhân trực tiếp gây ra sự kiện này là một số nút khách hàng lớp đồng thuận Ethereum bị quá tải, dẫn đến việc các nút xác thực bị ngưng hoạt động và không thể tiến hành bỏ phiếu đồng thuận bình thường. Phân tích cụ thể như sau:

Khi nhận được chứng thực (Attestation) chỉ tới khối cũ, nút cần phải tính toán lại trạng thái chuỗi dấu hiệu để xác minh những chứng thực này, quá trình này sẽ tiêu tốn rất nhiều tài nguyên CPU và bộ nhớ. Khi nhận được nhiều chứng thực chỉ tới khối cũ cùng lúc, tài nguyên CPU và bộ nhớ của nút sẽ bị tiêu tốn hết, dẫn đến các nút xác thực này bị sập và không trực tuyến.

Về lý thuyết, những vấn đề này có thể được giải quyết thông qua bộ nhớ đệm dựa trên các chứng nhận trỏ đến khối. Tuy nhiên, do quy mô của các xác nhận viên tăng lên và sự xuất hiện của một lượng lớn các chứng nhận như vậy, dẫn đến bộ nhớ đệm của các triển khai khách hàng gặp sự cố bị phá vỡ, các nút buộc phải tiêu tốn một lượng lớn tài nguyên để tính toán lại trạng thái của chuỗi tín hiệu.

Các khách hàng của lớp đồng thuận Teku và Prysm đã phát hành phiên bản vá để giải quyết vấn đề này. Phiên bản vá của khách hàng sẽ lọc bỏ những chứng cứ cũ này, tức là sẽ bỏ qua chứng cứ khi thỏa mãn các điều kiện sau:

• Chứng kiến chỉ vào một Slot cũ
• Chứng kiến một điểm kiểm tra mà nút chưa bao giờ thấy

Ưu điểm thiết kế của Ethereum

Trong sự kiện này, Ethereum đã duy trì khả năng sử dụng, liên tục tạo khối và xử lý giao dịch, chỉ hoãn việc xác định Epoch. Điều này chủ yếu nhờ vào hai điểm:

1. Đa dạng của các client Ethereum
2. Thiết kế thuật toán Gasper

Đa dạng của các khách hàng Ethereum

Mặc dù các khách hàng Teku và Prysm gặp sự cố, nhưng không ảnh hưởng đến hoạt động bình thường của các khách hàng lớp đồng thuận khác. Ví dụ, khách hàng Lighthouse lần này không bị ảnh hưởng. Do sự khác biệt trong thiết kế triển khai giữa các khách hàng khác nhau, nên vẫn có các nút xác thực hoạt động bình thường.

Sự đa dạng của các khách hàng Ethereum đảm bảo rằng: ngay cả khi một số khách hàng gặp sự cố ( thậm chí dẫn đến Epoch không thể xác nhận ), điều đó cũng không ảnh hưởng đến việc các khách hàng bình thường tạo ra khối và xử lý giao dịch, đảm bảo khả năng sử dụng của Ethereum.

Thiết kế khả dụng của thuật toán đồng thuận Gasper

Đảm bảo tính khả dụng của Ethereum là một trong những điểm khởi đầu trong thiết kế của thuật toán Gasper, nó tách biệt việc sản xuất khối và xác nhận. Do đó, ngay cả khi việc xác nhận khối bị cản trở, việc sản xuất khối sẽ không dừng lại. Xét rằng trong hầu hết các trường hợp, việc xác nhận khối cuối cùng sẽ phục hồi, ảnh hưởng thực tế đến người dùng là rất nhỏ.

So với đó, các thuật toán đồng thuận BFT khác sẽ dừng việc sản xuất khối tiếp theo khi việc chốt khối thất bại, dẫn đến toàn bộ chuỗi khối không khả dụng trong thời gian này.

Ngoài ra, sự kiện thứ hai cũng đã kích hoạt cơ chế Inactivity Leak, cơ chế này chủ yếu nhằm đảm bảo rằng Ethereum vẫn có thể xác nhận lại các khối trong trường hợp cực đoan ( có một lượng lớn các xác nhận viên offline trong thời gian dài ).

Kinh nghiệm và bài học

Thách thức của nhiều khách hàng Ethereum

Sự đa dạng của các khách hàng Ethereum hiện tại vẫn cần được tiếp tục thúc đẩy và quảng bá. Nếu khách hàng đạt được sự đa dạng đủ lớn, khiến tỷ lệ của Prysm và Teku nhỏ hơn 1/3, thì sự kiện này thậm chí sẽ không xảy ra ( 2/3 khách hàng hoạt động bình thường đủ để xác định Epoch ).

Ngoài ra, khi một triển khai khách hàng gặp sự cố, cách các nút xác thực an toàn chuyển sang triển khai khách hàng bình thường cũng là một vấn đề cần giải quyết. Quá trình này bao gồm:

• Di chuyển khóa xác thực của khách hàng gặp sự cố một cách an toàn sang khách hàng bình thường
• Đảm bảo tính nhất quán giữa hành vi của khách hàng cũ và khách hàng mới, tránh bị phạt

Giám sát đồng thuận Ethereum

Cần có dịch vụ giống như Safe Head để liên tục giám sát trạng thái thời gian thực của mạng PoS Ethereum, phát hiện sớm và cảnh báo các sự kiện như vậy, thay vì phải đợi đến khi Epoch không thể được xác định như mong đợi mới phát hiện ra trạng thái mạng bất thường.

Kiến thức phổ thông về thuật toán đồng thuận của Ethereum

Sự kiện lần này đã phơi bày sự cần thiết phải phổ cập cơ chế đồng thuận PoS của Ethereum. Nhiều người dùng đã hiểu nhầm rằng "Ethereum đã ngừng hoạt động", gây ra sự hoảng loạn không cần thiết. Thực tế, mạng lưới Ethereum vẫn đang tiếp tục tạo ra các khối và xử lý giao dịch. Việc phổ cập kiến thức blockchain cho người dùng vẫn là một hướng đi mà những người làm nghề cần nỗ lực không ngừng.

đối với ứng dụng Ethereum

Mặc dù mạng Ethereum đủ mạnh mẽ, nhưng sự không ổn định thỉnh thoảng có thể ảnh hưởng đến ứng dụng. Ứng dụng cần xử lý đúng các tình huống không ổn định này:

• Thời gian gửi tiền từ Layer1 đến Layer2 có thể kéo dài
• Thời gian nạp tiền của sàn giao dịch có thể kéo dài
• Rủi ro bị roll back trong báo giá trên chuỗi Oracle, các dịch vụ có giá trị cao phụ thuộc vào nó nên tạm ngừng thích hợp.
• Một số ứng dụng DeFi có thể cần tạm dừng một số chức năng

Tóm tắt

Sự kiện này đã cho thấy khả năng phục hồi và tự sửa chữa của thuật toán đồng thuận PoS của Ethereum, cũng như khả năng phản ứng nhanh chóng và sửa lỗi của các đội ngũ khách hàng. Đối với hệ sinh thái Ethereum, cần tiếp tục đầu tư vào các lĩnh vực sau: tăng cường sự đa dạng của các khách hàng, tối ưu hóa việc giám sát và cảnh báo tình trạng mạng theo thời gian thực, nâng cao giáo dục người dùng, hoàn thiện các kế hoạch khẩn cấp cho các bên tham gia hệ sinh thái khi có sự cố mạng.