Tôi đang đào sâu cơ chế đồng thuận của Dusk về “Bằng chứng Ngắn gọn” (Succinct Attestation) để hiểu chính xác điều gì xảy ra khi một ủy ban không thể tạo khối trong một lần lặp nhất định. Giả định của tôi lúc ban đầu: một lần lặp thất bại nghĩa là có gì đó không ổn — lỗi, bị bỏ lỡ slot, hoặc một vấn đề cần phải lách/né.
Nhưng không hẳn như vậy.
Đồng thuận của Dusk vận hành theo các lần lặp (iterations), mỗi lần có một ủy ban được chọn ngẫu nhiên để đề xuất (proposal), xác thực (validation) và phê chuẩn/niêm quyết (ratification). Nếu một ủy ban không đạt được ngưỡng (quorum) — có thể là không đủ trình xác thực phản hồi kịp thời, có thể do độ trễ mạng (network latency), và cũng chẳng có gì kịch tính — thì hệ thống không xem điều đó như một sự cố cần vá. Nó chỉ chuyển sang lần lặp tiếp theo với một ủy ban mới được chọn. Không có khối nào bị mất, không có phân nhánh chuỗi (chain forks), không có rollback. Lần thử đó đơn giản là hết hạn, và đồng thuận lại thử lần nữa với những trình xác thực khác đảm nhận trách nhiệm.
Điều khiến tôi chú ý là đây không phải một cơ chế dự phòng (fallback) được gắn thêm vào thiết kế. Nó chính là kỳ vọng mặc định. Giao thức giả định rằng một số lần lặp sẽ không thể hoàn tất, và xây dựng việc luân phiên ủy ban xoay quanh giả định đó, thay vì dựa vào hy vọng rằng mọi lần lặp đều thành công.

Điều này làm tôi đọc lại khái niệm “block time” (thời gian tạo khối) của Dusk. Nó không phải là một lần thử duy nhất kèm thời hạn (timeout) — mà là một chuỗi các lần thử, trong đó sự thất bại là bình thường, không phải trường hợp ngoại lệ, và tính cuối cùng (finality) chỉ chờ cho đến khi lần lặp nào đó hội tụ (converge) thực sự.

Tôi vẫn chưa chắc cơ chế này sẽ hoạt động ra sao khi mạng chịu áp lực kéo dài thay vì chỉ bị bỏ lỡ ngưỡng (quorum) một cách cô lập. @Dusk #dusk $DUSK