Tổng quan
Tổng quan
tiêu đề cấp đầu tiên
sự kiện và bối cảnh
Thông thường, trạng thái mạng đồ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.
Đầu tiênNó xảy ra vào ngày 11 tháng 5 và quá trình hoàn thiện Epoch bị trì hoãn 3 Epoch, khoảng 20 phút.
lần thứ haiNó xảy ra vào ngày 12 tháng 5 và việc hoàn thiện Kỷ nguyên bị trì hoãn 8 Kỷ nguyên, 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 Kỷ nguyên bị trì hoãn 8 Kỷ nguyên, do độ trễ hoàn tất lớn hơnMIN_EpochS_TO_INACTIVITY_PENALTY(= 4) do đó kích hoạt thuật toán đồng thuận EthereumInactivity leakcơ chế xử lý.
Xử phạt Trình xác thực ngoại tuyến bằng cách cắt giảm số tiền cam kết của họ,Khoảng 28 ETH đã bị tịch thu。
Hủy phần thưởng Chứng thực, dẫn đếnKhoảng 50 ETH chưa đượ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 các chứng thực trỏ đến các khối cũ, cá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 các chứng thực 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ộ nhớ đệ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á.
tiêu đề cấp đầu tiên
Prysm：v 4.0.3-hotfix
Teku：v2 3.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:
1. Sự đa dạng của khách hàng Ethereum
tiêu đề phụ
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. Giống như khách hàng Ngọn hải đăng lần này vàkhông bị ảnh hưởng, vì các máy 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.
tiêu đề phụ
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.
tiêu đề cấp đầu tiên
tiêu đề phụ
Thách thức nhiều khách hàng Ethereum
Mô tả hình ảnh
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
tiêu đề phụ
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 mới nhất có liên quan có thể được tìm thấy trongtiêu đề phụ。
Khoa học phổ biến về thuật toán đồng thuận Ethereum
tiêu đề phụ
Ý 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.
Layer 1 ->Thời gian gửi lớp 2 sẽ lâu hơn. Khi Lớp 2 đượ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.
tóm tắt
tóm tắt
liên kết tham khảo
