Tôi đang tìm hiểu cách đồng thuận của Dusk thực sự đi đến trạng thái cuối cùng (finality), và cách diễn đạt "một khối, một lần xác nhận" bắt đầu cảm thấy chưa đầy đủ.

Chứng thực súc tích (Succinct Attestation) hoạt động theo từng vòng, và mỗi vòng có thể chạy qua nhiều lần lặp nếu ủy ban không kịp tạo hoặc xác thực một khối. Nhìn bề ngoài, đó chỉ là cơ chế thử lại — đúng thôi, mạng sẽ tự hiệu chỉnh. Nhưng khi tôi theo dõi một lần lặp thất bại thực sự tiêu tốn điều gì, thì nó không chỉ là một lần thử lại trừu tượng. Mỗi lần lặp thất bại sẽ sắp xếp lại ủy ban, đặt lại cửa sổ bỏ phiếu và đẩy thời điểm finality lùi xa hơn. Khoảng trễ này không xuất hiện ở đâu như một con số duy nhất — nó được phân bổ cho tất cả những ai đang chờ khối đó: một đối tác thanh toán, một bộ chuyển tiếp cầu (bridge relay), một ứng dụng đang kiểm tra trạng thái xác nhận.

Vì vậy, "thời gian finality" mà mọi người trích dẫn thực ra là một con số theo trường hợp tốt nhất. Chi phí thực sự mang tính điều kiện — nó phụ thuộc và cộng dồn theo điều kiện mạng, mức độ phản hồi của trình xác thực và tần suất các ủy ban hoàn thành công việc ngay từ lần đầu. Không ai gánh rủi ro đó một cách đồng đều; người đang chờ giao dịch sẽ hấp thụ rủi ro, không phải giao thức.

Tôi vẫn chưa chắc tỷ lệ thất bại đó sẽ diễn biến ra sao khi cả khối lượng giao dịch và tốc độ thay vòng (committee turnover) đều tăng lên cùng lúc.
#dusk $DUSK @Dusk