#dusk $DUSK @Dusk
Khi đọc các tài liệu về việc “slashing” của Dusk, một dòng đã khiến tôi dừng lại: cảnh báo và lỗi chỉ được đặt lại khi một provisioner nhận được phần thưởng — nghĩa là nó thực sự đã tạo hoặc bỏ phiếu trên một khối. Không có bộ đếm thời gian. Không có sự suy giảm tự động. Chỉ có sự tham gia mới xóa được bản ghi.
“Slashing” nhẹ trên $DUSK SK không đốt stake. Một lỗi sẽ chuyển một phần stake đó vào quỹ phần thưởng và làm thu nhỏ “kích thước hiệu dụng” của nút, khiến xác suất được chọn cho ủy ban tiếp theo giảm đi. Vì vậy, provisioner bị phạt cần được chọn lại để đặt lại các lỗi của nó — nhưng chính hình phạt lại là thứ khiến việc được chọn ít có khả năng xảy ra ngay từ đầu.
Đó là phần tôi chưa kịp “nhìn ra”. Không chỉ là "các nút xấu bị trừng phạt". Mà là một cơ chế trong đó việc phục hồi đi qua đúng cánh cửa đã trở nên khó bước qua hơn. #dusk mô tả chuyện này như việc bảo vệ độ tin cậy, và về mặt cơ chế thì đúng — những kẻ tụt lại bị hạ ưu tiên, và thời gian uptime được thưởng. Nhưng con đường quay lại hoàn toàn phụ thuộc vào việc lại được chọn, chứ không phải chờ cho thời gian trôi qua.
Đáng kiểm tra: thông thường, mất bao nhiêu epoch để một provisioner bị treo trên @Dusk có thể quay lại một ủy ban hoạt động sau chỉ một lần có lỗi.
Khi đọc các tài liệu về việc “slashing” của Dusk, một dòng đã khiến tôi dừng lại: cảnh báo và lỗi chỉ được đặt lại khi một provisioner nhận được phần thưởng — nghĩa là nó thực sự đã tạo hoặc bỏ phiếu trên một khối. Không có bộ đếm thời gian. Không có sự suy giảm tự động. Chỉ có sự tham gia mới xóa được bản ghi.
“Slashing” nhẹ trên $DUSK SK không đốt stake. Một lỗi sẽ chuyển một phần stake đó vào quỹ phần thưởng và làm thu nhỏ “kích thước hiệu dụng” của nút, khiến xác suất được chọn cho ủy ban tiếp theo giảm đi. Vì vậy, provisioner bị phạt cần được chọn lại để đặt lại các lỗi của nó — nhưng chính hình phạt lại là thứ khiến việc được chọn ít có khả năng xảy ra ngay từ đầu.
Đó là phần tôi chưa kịp “nhìn ra”. Không chỉ là "các nút xấu bị trừng phạt". Mà là một cơ chế trong đó việc phục hồi đi qua đúng cánh cửa đã trở nên khó bước qua hơn. #dusk mô tả chuyện này như việc bảo vệ độ tin cậy, và về mặt cơ chế thì đúng — những kẻ tụt lại bị hạ ưu tiên, và thời gian uptime được thưởng. Nhưng con đường quay lại hoàn toàn phụ thuộc vào việc lại được chọn, chứ không phải chờ cho thời gian trôi qua.
Đáng kiểm tra: thông thường, mất bao nhiêu epoch để một provisioner bị treo trên @Dusk có thể quay lại một ủy ban hoạt động sau chỉ một lần có lỗi.