Tối qua, tôi đã xem lại whitepaper Dusk, tập trung vào các phần chế độ khẩn cấp, cơ chế dự phòng và tính cuối cùng theo vòng (rolling finality). Những chi tiết còn tinh tế hơn tôi tưởng ban đầu.

Chế độ khẩn cấp kích hoạt sau 16 lần lặp thất bại. Khi đó, thời gian chờ (step timeouts) sẽ bị tắt, và các lần lặp mở tiếp tục cho đến khi một khối ứng viên đạt được ngưỡng (quorum) ở cả giai đoạn xác thực và phê chuẩn (ratification). Có thể chạy nhiều lần lặp cùng lúc, điều này giúp tăng khả năng tạo ra một khối nhưng đồng thời cũng làm tăng khả năng xảy ra các nhánh (forks). Nếu một số ứng viên đạt được sự đồng thuận, lần lặp có chỉ số thấp nhất sẽ được chọn. Ở lần lặp cuối cùng, các provisioners có thể yêu cầu một khối khẩn cấp, nhưng yêu cầu này cần các provisioners nắm giữ đa số tổng giá trị stake của toàn mạng.

Các quy tắc dự phòng cũng thu hút sự chú ý của tôi: một khối từ lần lặp J > 0 về mặt lý thuyết có thể bị thay thế bởi một khối ở lần lặp có chỉ số thấp hơn mà sau đó đạt được sự đồng thuận, trong khi khối ở lần lặp 0 thì không thể bị thay thế theo cách này.

Sau đó, rolling finality lại bổ sung thêm một lớp khác. Nếu n lần lặp trước đó thất bại trong việc attestation, thì một khối sẽ được chấp nhận và cần 2×n khối liên tiếp đã được attested hoặc confirmed để trở thành confirmed. Ví dụ trong bài báo sử dụng iteration 5, n=2, nghĩa là cần thêm 4 khối nữa.

Tôi vẫn đang tự hỏi: thiết kế này có tạo ra rủi ro tập trung hóa mang ý nghĩa nào liên quan đến cơ chế phục hồi khẩn cấp được cân theo stake hay không?

@Dusk #dusk $DUSK