#dusk $DUSK

Thành thật mà nói, tôi bị sốc. Chỉ 5 điểm dù đã nhận được 5K lượt xem, cảm giác rất bất công và thất vọng.

Hôm nay đăng bài với một trái tim nặng trĩu… nhưng trước khi đăng, đây là một đoạn scalp nhanh:

Long $PORTAL 📈
Short $CYS 📉
đừng quên cảm ơn tôi khi bạn chốt lợi nhuận

Ban đầu tôi nghĩ rằng bị chém trên @Dusk nghĩa là một điều: mất stake và khởi động lại node

Hướng dẫn phục hồi vẽ ra một ranh giới rõ ràng hơn.

Hình phạt mềm có thể tạm dừng tư cách đủ điều kiện của một provisioner và chuyển một phần stake đang hoạt động của nó sang stake bị khóa. Phần stake đó vẫn thuộc về bên vận hành và có thể được rút (unstake).

Hình phạt cứng áp dụng cho các hành vi đồng thuận rõ ràng là không hợp lệ như bỏ phiếu xung đột hoặc gian lận (equivocation). Một phần stake bị đốt, và việc khởi động lại hoặc restake không thể lấy lại phần đó

Chính sự khác biệt đó đã “đóng” lại trong đầu.

Dusk đối xử khác nhau giữa việc tham gia bị bỏ lỡ và tham gia mâu thuẫn. Một phiên bản lỗi thời, thời gian downtime kéo dài, đồng bộ kém hoặc lưu lượng mạng bị chặn có thể tạo ra lỗi vận hành. Việc ký các thông điệp mâu thuẫn đi qua ranh giới sang một hành vi mà giao thức có thể chứng minh là không hợp lệ.

Cảnh báo về khóa trùng lặp khiến ranh giới này trở nên thực tế.

Chạy cùng một consensus key trên hai node đang hoạt động có thể khiến cả hai máy ký các thông điệp không tương thích, ngay cả khi người vận hành nghĩ rằng node thứ hai chỉ để dự phòng.

Tôi thích cách phục hồi bắt đầu từ việc sửa phiên bản, đồng bộ, kết nối và cấu hình key trước khi tạo một vị trí provisioner mới. Restake mà không tìm ra nguyên nhân chỉ khiến một vị trí mới lại “xếp hàng” sau cùng một cấu hình bị hỏng

Mô hình cũng cho thấy tính dự phòng phải được thiết kế cẩn thận. Một bản dự phòng nhằm tăng tính sẵn sàng có thể tạo rủi ro bị chém cứng nếu nó trở thành active với cùng một key.

Việc tách lỗi vận hành khỏi equivocation có tạo ra hình phạt công bằng hơn không, hay quản lý consensus-key lại là phần khắt khe nhất trong việc vận hành một provisioner?
Provisioner slashing trên @Dusk đặt ra một câu hỏi thú vị
Điều gì quan trọng hơn để giữ cho validator an toàn?