Tôi nhớ hồi trước khi tôi nhìn một thiết kế đồng thuận mới và hỏi trước một câu hỏi.

Làm sao kẻ tấn công có thể phá vỡ điều này?

Việc nghiên cứu Dusk đã thay đổi thói quen đó.

Với Xác thực Gọn nhẹ (Succinct Attestation), tôi bắt đầu nghĩ về một tình huống khác.

Giả sử bạn là một người phụ trách (provisioner). Bạn đang bỏ phiếu cho phiên bản hiện tại, nhưng bạn đã biết rằng bạn sẽ được chọn để tạo một khối ở một phiên bản sau.

Bây giờ, trước mắt bạn là một lựa chọn kỳ lạ.

Bạn có giúp khối hiện tại tiến lên và thu phần thưởng người bỏ phiếu của mình không?

Hay bạn im lặng, để phiên bản hiện tại thất bại và có thể cải thiện vị thế của mình trong vai trò người tạo khối trong tương lai?

Đó là Vấn đề Khuyến khích Người Tạo Khối Tương Lai mà Dusk đã nhận ra trong thiết kế đồng thuận của mình. Phần thú vị là vấn đề này không phải về việc một tin tặc từ bên ngoài tìm ra một lỗ hổng.

Nó xuất phát từ các động lực (incentives) dành cho một người tham gia hợp pháp.

@Dusk_Foundation response là nhằm định hình lại các động lực đó, bao gồm việc tách phần thưởng của người tạo khối và người bỏ phiếu, đồng thời ngăn người tạo khối của phiên bản kế tiếp từ việc tham gia bỏ phiếu ở phiên bản hiện tại.

Chi tiết đó đã đọng lại trong tôi.

Vì nói một hệ đồng thuận là an toàn thì rất dễ.

Nhưng để thiết kế sao cho nước đi hợp lý nhất cũng đồng thời là nước đi trung thực thì khó hơn.

Đó mới là ván cờ thực sự đang diễn ra bên dưới lớp mật mã.

#dusk $DUSK #Dusk