#dusk $DUSK @Dusk
Tôi đã lỡ một lượt bỏ phiếu chỉ vì thiếu đúng bốn mươi giây vào tháng trước và dành thêm một tiếng đồng hồ để làm mới bảng điều khiển, chắc mẩm mình đã mất phần stake. Hóa ra là không. Từ đó tôi lạc vào một “hố thỏ” tìm hiểu xem hệ thống phần thưởng của Dusk hoạt động ra sao, và thiết kế đã giải đáp nỗi lo của tôi tốt hơn tôi kỳ vọng.

Việc chia phần thưởng cho phép người tạo khối nhận tới tám mươi phần trăm, và một phần trong khoản “dư” đó được gắn với việc có bao nhiêu credit được đưa vào trong chứng chỉ. Mười phần trăm được chuyển vào quỹ phát triển và mười phần trăm cuối cùng được chia đều giữa các ủy ban thẩm định và phê chuẩn. Không có gì quá bất ngờ ở đó. Thứ khiến tôi chú ý là việc nó được cân nặng chủ ý nghiêng về phía người tạo khối. Lúc đầu tôi thấy hơi lạ khi phân bổ quá nhiều cho một vai trò, nhưng lại hợp lý nếu nghĩ xem ai là người thực sự “gánh nặng” cho từng khối.

Phần quan trọng thực sự nằm ở hệ thống xử phạt lỗi (fault). Dusk tách các lỗi nhỏ khỏi các lỗi lớn thay vì đối xử mọi sai sót như nhau. Lỡ bỏ phiếu vì node của bạn bị chập chờn và bạn sẽ bị đình chỉ tạm thời kèm theo việc khóa stake trong một khoảng thời gian. Không bị đốt (burn). Còn nếu làm điều gì đó có thể chứng minh là độc hại như ký các phiếu bầu mâu thuẫn thì đó là một hạng mục hoàn toàn khác, với stake bị đốt thật sự. Tôi nhớ đã đọc các giao thức từ nhiều năm trước chỉ “đốt” stake cho mọi thời gian downtime, và thật lòng lúc nào nó cũng khiến tôi cảm thấy mang tính trừng phạt hơn là bảo vệ.

Có thể tôi đang suy nghĩ quá mức, nhưng sự phân biệt này giống như “insight” thiết kế cốt lõi ở đây. Nó không trừng phạt các nhà vận hành trung thực vì vấn đề hạ tầng, đồng thời vẫn làm cho các cuộc tấn công có chủ đích trở nên đắt đỏ. Liệu sự cân bằng đó có còn đứng vững khi mạng thực sự chịu áp lực ở quy mô lớn hay không là điều tôi vẫn tò mò. Các hệ thống slashing luôn nhìn “sạch” hơn trên giấy so với cách chúng vận hành khi hàng nghìn validator thực sự đang chạy.

$TUT
$ZRO
Dusk nên xử lý lỗi của validator như thế nào?