Tôi đã nghĩ về sự đồng thuận của <c-1>@Dusk <c-1/> thông qua một tình huống đơn giản.

Hãy tưởng tượng có hai người đi theo hai lộ trình khác nhau để đến cùng một điểm đến. Người thứ nhất bắt đầu sớm hơn nhưng bị trễ. Người thứ hai bắt đầu muộn hơn và đến nơi trước.

Bạn có tự động quyết định rằng lộ trình thứ hai là đúng không?

Đó là điều khiến thiết kế giải quyết nhánh của Dusk trở nên thú vị đối với tôi.

Attestation ngắn gọn hoạt động thông qua các lần lặp. Nếu một lần lặp thất bại, giao thức vẫn có thể tiếp tục tiến về phía trước. Nhưng nếu nhiều lần lặp cuối cùng tạo ra các ứng viên hợp lệ, Dusk sẽ ưu tiên cho lần lặp có số thứ tự nhỏ nhất.

Vì vậy, nếu cả lần lặp 2 và lần lặp 5 đều đạt ngưỡng, thì lần lặp 5 không đơn giản “thắng” chỉ vì hoàn thành muộn hơn, mà là vì nó thực sự đạt được thành công.

Giao thức quan tâm đến việc ứng viên xuất hiện ở vị trí nào trong quá trình đồng thuận.

Điều này trở nên đặc biệt thú vị với tính hoàn tất luân phiên (rolling finality). $DUSK ghi nhận các ứng viên ở các lần lặp thấp hơn chưa được giải quyết, thay vì coi mọi lần lặp thành công muộn hơn là lập tức hoàn tất.

Cũng có một động cơ tinh tế ở đây. các trình xác thực (validators) có lý do để giúp giải quyết các lần lặp sớm hơn thay vì chỉ chờ cái mới nhất.

Tôi thích thiết kế này vì nó coi đồng thuận ít giống như một cuộc đua và nhiều hơn như một chuỗi các lần thử được kiểm soát.

Với hạ tầng tài chính, sự khác biệt đó có thể quan trọng.

Có lẽ “tính hoàn tất tất định” không chỉ là đạt được sự đồng thuận nhanh chóng. Nó còn là việc biết thỏa thuận nào xứng đáng được ưu tiên.

#dusk $DUSK #DUSK