Tác giả: phòng thí nghiệm imToken
Tổng quan
Trong hai đêm liên tiếp vào ngày 11 và 12 tháng 5, lớp đồng thuận của Ethereum tạm thời bất thường. imToken đã phân tích rằng sự bất thường này chủ yếu là do tải cao của các nút máy khách nhất định của lớp đồng thuận của Ethereum, khiến Trình xác thực ngoại tuyến, điều này đã trực tiếp khiến cuộc bỏ phiếu Epoch không đạt được 2/3. Lớp đồng thuận không thể xác nhận tính chính xác, nhưng mạng Ethereum sẽ trở lại bình thường sau một khoảng thời gian ngắn. imToken tin rằng điều này cho thấy thuật toán đồng thuận Ethereum PoS có khả năng phục hồi và khả năng tự phục hồi.
sự kiện và bối cảnh
Thông thường, trạng thái mạng lưới đồng thuận Ethereum PoS sẽ được hoàn thiện (Finalized) trong 2 Kỷ nguyên, nhưng tuần trước đã có sự chậm trễ trong 2 Kỷ nguyên hoàn thiện.
Lần đầu tiên xảy ra vào ngày 11 tháng 5, quá trình hoàn thiện Epoch bị trì hoãn 3 Epoch, khoảng 20 phút.
Lần thứ hai xảy ra vào ngày 12 tháng 5 và quá trình hoàn thiện Epoch bị trì hoãn 8 Epoch, khoảng 51 phút.
Trong sự kiện này, mạng Ethereum tiếp tục tạo khối và xử lý giao dịch. Tuy nhiên, do tỷ lệ bỏ phiếu không đủ của Trình xác thực (nút xác minh), Epoch không thể được hoàn thiện (nghĩa là Epoch đã nhận được bảo đảm bảo mật ở mức độ đồng thuận của mạng Ethereum PoS). Việc Epoch không thể hoàn thiện có nghĩa là trong trường hợp hầu hết các trình xác thực làm điều xấu và chuyển đổi, epcoh có thể bị khôi phục, dẫn đến giao dịch bị khôi phục.
Trên thực tế, trong thời gian xảy ra sự cố, không có phân nhánh nào trong mạng Ethereum và Người xác thực đã không bỏ phiếu ác ý. Chỉ là do một số lượng lớn Người xác thực ngoại tuyến nên tỷ lệ bỏ phiếu không đủ, điều này đã ngăn Epoch được hoàn thiện trong quá trình sự kiện.
Sau khi quan sát, tình trạng quá tải CPU bất thường trong Trình xác thực ngoại tuyến được coi là nguyên nhân trực tiếp của Trình xác thực ngoại tuyến.
Trong sự kiện thứ hai, quá trình hoàn tất Epoch bị trì hoãn 8 Epoch. Do độ trễ hoàn tất lớn hơn MIN_EpochS_TO_INACTIVITY_PENALTY (=4), nên cơ chế xử lý của thuật toán đồng thuận Ethereum không hoạt động đã bị rò rỉ.
- Trừng phạt Trình xác thực ngoại tuyến, cắt số tiền cam kết của nó và phạt khoảng 28 ETH .
- Phần thưởng Chứng thực đã bị hủy, dẫn đến khoảng 50 ETH không được phát hành .
- Cơ chế này đảm bảo rằng Trình xác thực trực tuyến cuối cùng có thể nắm giữ ⅔ tổng số tiền được cam kết của Ethereum, để trạng thái mạng cuối cùng có thể được hoàn thiện
Dịch vụ nút của imToken cũng đã phát hiện ra sự cố này. Bằng cách theo dõi trạng thái bỏ phiếu của Trình xác thực lớp đồng thuận Ethereum trong thời gian thực, dịch vụ này có thể đưa ra cảnh báo sớm về sự bất thường của mạng đồng thuận Ethereum trước khi Epoch không được hoàn thiện bình thường. Hình bên dưới là trạng thái của nút khi sự kiện đầu tiên xảy ra.
Theo cơ chế PoW, thành công của giao dịch là xác định rằng giao dịch sẽ không bị khôi phục sau một số khối liên tiếp nhất định và PoS dựa trên chiều cao khối do Safe Head trả về để xác định thành công của giao dịch. giao dịch. Trong thông số kỹ thuật hiện tại, Điểm kiểm tra hợp lý được sử dụng làm trạng thái của Đầu an toàn, do đó, dựa trên trạng thái của Kỷ nguyên trước đó, có thể có độ trễ 6,4 phút, đây là một trải nghiệm rất tệ cho người dùng.
Dịch vụ Safe Head do imToken phát triển sẽ tính toán một khối an toàn để xác nhận giao dịch dựa trên dữ liệu lớp đồng thuận Ethereum thời gian thực và rút ngắn thời gian xác nhận giao dịch trên cơ sở đảm bảo tính bảo mật cho giao dịch của người dùng. Trong các trường hợp bình thường, chiều cao khối được trả về bởi thuật toán Safe Head của imToken (màu vàng trong hình trên) sẽ rất gần với chiều cao khối mới nhất (màu xanh lá cây), do đó cải thiện trải nghiệm người dùng.
Thông tin thêm về cơ chế Safe Head:
Phân tích nguyên nhân
Nguyên nhân trực tiếp của sự cố trên là do tải của một số nút máy khách lớp đồng thuận Ethereum nhất định quá cao, khiến Trình xác thực ngoại tuyến, do đó việc bỏ phiếu đồng thuận không thể được thực hiện bình thường. Sau khi phân tích, lý do tải cao của các nút này là:
Khi nhận được một nhân chứng ( Chứng thực ) trỏ đến một khối cũ , nút cần tính toán lại trạng thái của chuỗi đèn hiệu để xác minh những nhân chứng này và quá trình này tiêu tốn rất nhiều tài nguyên CPU và bộ nhớ.
Khi một số lượng lớn nhân chứng trỏ đến các khối cũ được nhận cùng một lúc, tài nguyên CPU và bộ nhớ của nút sẽ cạn kiệt, khiến các Trình xác thực này chuyển sang chế độ ngoại tuyến.
Ban đầu, loại vấn đề này có thể được giải quyết bằng cách lưu vào bộ đệm dựa trên nhân chứng chỉ vào khối. Tuy nhiên, do sự phát triển quy mô của Trình xác thực và sự xuất hiện của một số lượng lớn các chứng thực như vậy, bộ đệm được triển khai bởi máy khách có vấn đề đã bị hỏng ngừng hoạt động và nút phải tiêu tốn rất nhiều tài nguyên để khởi động lại Tính toán trạng thái chuỗi đèn hiệu.
Các ứng dụng khách lớp đồng thuận Teku và Prysm đã phát hành các phiên bản vá lỗi để giải quyết vấn đề này. Cụ thể, việc triển khai ứng dụng khách của phiên bản vá lỗi sẽ lọc ra những nhân chứng cũ này, tức là bỏ qua nhân chứng khi các điều kiện sau được đáp ứng:
- Nhân chứng chỉ vào một Khe cắm cũ
- Nhân chứng trỏ đến Điểm kiểm tra mà nút chưa từng thấy
Tuy nhiên, chúng ta vẫn cần tiếp tục quan sát quá trình hoàn thiện mạng chính Ethereum để xác nhận tính hiệu quả của bản vá.
Phiên bản vá của ứng dụng khách lớp đồng thuận Teku và Prysm:
- Prysm: v4.0.3-hotfix
- Teku: v23.5.0
Ưu điểm thiết kế Ethereum
Trong sự cố này, Ethereum đảm bảo tính khả dụng và tiếp tục tạo khối cũng như xử lý giao dịch, và chìa khóa để chỉ trì hoãn việc hoàn thiện Epoch nằm ở hai điểm:
- Sự đa dạng của khách hàng Ethereum
- Thiết kế thuật toán Gasper
Sự đa dạng của khách hàng Ethereum
Trong sự cố này, mặc dù có sự cố trong quá trình triển khai ứng dụng khách lớp đồng thuận Teku và Prysm, nhưng nó không ảnh hưởng đến hoạt động bình thường của các ứng dụng khách lớp đồng thuận khác. Ví dụ: ứng dụng khách Lighthouse không bị ảnh hưởng lần này, vì các ứng dụng khách khác nhau có thiết kế triển khai khác nhau nên Trình xác thực vẫn hoạt động bình thường.
Sự đa dạng của các máy khách Ethereum đảm bảo rằng ngay cả khi một số máy khách gặp sự cố (thậm chí khiến Epoch không thể hoàn thành), thì điều đó sẽ không ảnh hưởng đến các máy khách bình thường trong việc tạo khối và xử lý giao dịch, do đó tính khả dụng của Ethereum được duy trì.
Thiết kế thuật toán đồng thuận Ethereum Gasper cho khả năng sử dụng
Đảm bảo tính khả dụng của Ethereum là một trong những điểm khởi đầu thiết kế của thuật toán đồng thuận Ethereum Gasper, thuật toán này phân tách việc sản xuất và hoàn thiện các khối Ethereum. Do đó, ngay cả khi việc hoàn thiện khối bị chặn, việc sản xuất khối sẽ không bị chấm dứt. Xét rằng trong hầu hết các trường hợp, quá trình hoàn thiện khối cuối cùng sẽ tiếp tục (các khối đã tạo sẽ vẫn được hoàn thiện), tác động đối với người dùng thực sự sẽ rất thấp. So với các thuật toán đồng thuận BFT khác: nếu việc hoàn thiện khối không thành công, nút đồng thuận sẽ ngừng tạo khối tiếp theo. Do đó, toàn bộ chuỗi khối không khả dụng trong khoảng thời gian này, thường được gọi là "chuỗi khối bị treo".
Ngoài ra, sự kiện thứ hai cũng kích hoạt cơ chế Rò rỉ không hoạt động, chủ yếu để đảm bảo rằng Ethereum vẫn có thể hoàn thiện các khối trong các trường hợp khắc nghiệt (một số lượng lớn Người xác thực đã ngoại tuyến trong một thời gian dài).
Kinh nghiệm và giác ngộ
Thách thức nhiều khách hàng Ethereum
Hiện tại, trạng thái đa dạng của các máy khách Ethereum được hiển thị trong hình sau:
Nguồn: https://clientdiversity.org/#distribution
Có thể thấy, sự đa dạng của Ethereum client vẫn cần được thúc đẩy và công khai. Có thể hình dung, nếu việc triển khai ứng dụng khách đủ đa dạng để Prysm và Teku chiếm ít hơn ⅓, thì sự kiện này thậm chí sẽ không xảy ra (⅔ ứng dụng khách hoạt động đủ bình thường để hoàn thiện Kỷ nguyên). Ngoài ra, các máy khách của lớp thực thi hiện tại tập trung ở Geth, chiếm tới 61%. Đây thực sự là một rủi ro tiềm ẩn: nếu Geth không hoạt động bình thường, Ethereum sẽ bị ảnh hưởng rất nhiều.
Ngoài nhu cầu nỗ lực hơn nữa trong việc đa dạng hóa các ứng dụng khách Ethereum, việc chuyển đổi ứng dụng khách Ethereum cũng là một điểm khó khăn do sự cố này bộc lộ: khi một triển khai ứng dụng khách nhất định không thành công, Trình xác thực sẽ chuyển sang triển khai ứng dụng khách thông thường như thế nào. Quá trình này bao gồm:
- Di chuyển an toàn Khóa xác thực của máy khách có vấn đề sang máy khách bình thường
- Vì sự đồng thuận của Ethereum có các quy tắc Slash nên cần phải đảm bảo rằng hành vi của khách hàng cũ và khách hàng mới nhất quán mà không bị cắt giảm. Ví dụ:
- Khách hàng cũ và mới đã bỏ phiếu cho các trạm kiểm soát ở cả hai bên ngã ba, do đó bị chém
- Máy khách mới và cũ tạo ra các khối khác nhau trong cùng một Khe, do đó bị cắt giảm
Giám sát sự đồng thuận của Ethereum
Các dịch vụ như Safe Head là cần thiết để liên tục theo dõi trạng thái thời gian thực của mạng Ethereum PoS, để phát hiện và cảnh báo trước các sự kiện như vậy, thay vì đợi cho đến khi Epoch không thể hoàn thành như dự kiến để biết rằng trạng thái mạng là bất thường. Nghiên cứu gần đây có liên quan có thể được tìm thấy trong bài báo này .
Khoa học phổ biến về thuật toán đồng thuận Ethereum
Sự cố này cho thấy sự cần thiết của cơ chế đồng thuận Ethereum PoS trong khoa học phổ biến. Trong sự cố này, nhiều người dùng đã nhầm tưởng rằng "Ethereum đang ngừng hoạt động", điều này đã gây ra sự hoảng loạn không cần thiết. Tuy nhiên, trên thực tế, mạng Ethereum liên tục tạo ra các khối và xử lý các giao dịch. Sự kết hợp giữa lớp đồng thuận Ethereum và lớp thực thi mang lại sự đảm bảo kép cho việc xác nhận giao dịch của Ethereum. việc hoàn thiện Epoch cũng nằm trong Ethereum Có các thiết kế xử lý tương ứng trong thuật toán đồng thuận Fang. Việc phổ biến kiến thức blockchain hướng đến người dùng vẫn là hướng đi mà các học viên cần tiếp tục nỗ lực.
Ý nghĩa đối với các ứng dụng Ethereum
Mặc dù mạng Ethereum đủ mạnh, nhưng sự bất ổn định thường xuyên sẽ có tác động nhất định đến các ứng dụng. Đồng thời, ứng dụng sẽ xử lý chính xác các tình huống không ổn định này.
- Thời gian gửi Layer1 -> Layer2 sẽ lâu hơn. Khi Layer2 được đúc, một điều kiện tiên quyết quan trọng là đảm bảo rằng các giao dịch tiền gửi L1 sẽ không bị hủy bỏ. Do đó, khi quá trình hoàn thiện Epoch của mạng Ethereum bị trì hoãn, thời gian ký gửi của L1->L2 sẽ dài hơn tương ứng.
- Tương tự, sàn giao dịch cũng cần ngăn không cho giao dịch nạp tiền trên chuỗi bị hủy bỏ, do đó thời gian nạp tiền sẽ lâu hơn tương ứng.
- Các trích dẫn trên chuỗi Oracle có nguy cơ bị hủy bỏ, vì vậy các dịch vụ có giá trị cao dựa vào nó sẽ bị tạm ngưng một cách thích hợp.
- Trong sự cố này, Uniswap không hiển thị số dư và chỉ có thể mua chứ không thể bán, trong khi dYdX tạm dừng tiền gửi.
tóm tắt
Trong sự cố này, chúng ta có thể thấy khả năng phục hồi và tự phục hồi của thuật toán đồng thuận Ethereum PoS, đồng thời chúng ta cũng có thể thấy rằng khách hàng phản hồi và sửa lỗi ngay sau khi xảy ra sự cố. Đối với toàn bộ hệ sinh thái của Ethereum, cần đầu tư liên tục vào các lĩnh vực sau: tăng tính đa dạng của khách hàng, tối ưu hóa giám sát thời gian thực và cảnh báo sớm về trạng thái mạng, giáo dục người dùng chuyên sâu (không chỉ cho người dùng thông thường mà còn cho các học viên), Chuẩn bị kế hoạch khẩn cấp cho những người tham gia sinh thái khi mạng bất thường.
liên kết tham khảo
