Một nhóm các nhà nghiên cứu đã xác định ba kịch bản tiềm năng cho các cuộc tấn công chống lại mạng Proof-of-Stake của Ethereum. Hai kịch bản đã được xác định trong quá khứ và kịch bản thứ ba được phát hiện là kết quả của việc kết hợp các kỹ thuật từ cả hai kịch bản. Bài báo được viết bởi các nhà nghiên cứu từ Stanford bao gồm Casper Schwarz-Schilling, Joachim Neu và David Tse.
Kịch bản đầu tiên liên quan đến một tình huống mà “tổ chức lại phạm vi ngắn của chuỗi đồng thuận cơ bản được sử dụng để tăng lợi nhuận của nút xác nhận cá nhân.” Thứ hai là việc tận dụng sự chậm trễ mạng đối nghịch có thể làm đình trệ các quyết định đồng thuận trên mạng. Để mô phỏng mức độ nghiêm trọng tiềm tàng của các cuộc tấn công, các nhà nghiên cứu đã giảm bớt các yêu cầu đối với kích hoạt cho thấy nguy cơ thứ ba cho mạng.
Những tình huống này gây ra những rủi ro không lành mạnh cho sự an toàn của Bằng chứng cổ phần của Ethereum. Ethereum đã hoàn toàn hướng tới quá trình chuyển đổi sang Proof-of-Stake sau khi nâng cấp Altair thành công. Người ta thường tin rằng việc chuyển đổi sẽ diễn ra vào một ngày vào năm 2022 và sẽ là câu trả lời cho phí gas cao của Ethereum.
Để trả lời các câu hỏi thích hợp được đưa ra bởi các nhà nghiên cứu, Danny Ryan, nhà nghiên cứu chính của việc triển khai Ethereum 2.0 đã viết câu trả lời của mình. Ông xác nhận rằng các tình huống giả định được nêu ra là “các cuộc tấn công nghiêm trọng” mà nếu không được giám sát, “có thể đe dọa sự ổn định của mạng”.
Ông trấn an người dùng bằng cách nói rằng các vấn đề có thể được giải quyết thông qua việc sử dụng hai bản sửa lỗi đơn giản. Đầu tiên là thông qua việc sử dụng “proposer boosting” và “proposer view synchronization”. Ông tiếp tục tuyên bố thông qua blog của Ethereum rằng việc thúc đẩy người đề xuất đã được nghiên cứu sâu bởi các nhà nghiên cứu Stanford và đã được thực hiện bởi Teku, một khách hàng Ethereum 2.0 để đặt cược tổ chức.
Theo Ryan, giải pháp thứ hai vẫn đang trong giai đoạn đầu của phân tích chính thức nhưng cho thấy rất nhiều hứa hẹn cho tương lai. Ông nói rằng việc triển khai các bản sửa lỗi sẽ không ảnh hưởng đến thời gian của Merge và nó có thể được thực hiện mà không cần hard fork.
Theo zycrypto