Mình đã đào sâu cách Succinct Attestation thực sự xử lý một lần lặp (iteration), và một điều về nhánh thất bại cứ làm mình bận tâm.

Câu chuyện hiển nhiên: một ủy ban xác thực một khối, phê chuẩn nó, xong. Nhưng giao thức của Dusk không chỉ theo dõi “hợp lệ” — nó theo dõi các Attestation (bản chứng nhận), và một Failed Attestation (một đa số đủ lớn đồng ý rằng một khối là *không* hợp lệ) là một kết quả “hạng nhất”, không phải là chi tiết phụ.

Đây là điều mình đã chưa cân nhắc: từ chối thì về mặt cấu trúc dễ hơn chấp nhận. Để phê chuẩn một khối hợp lệ, ủy ban phải thực sự kiểm tra các chuyển trạng thái, chữ ký, toàn bộ ứng viên (candidate). Còn để đạt tới một Failed Attestation, các thành viên chỉ cần sự đồng thuận siêu đa số rằng *có gì đó sai* — dữ liệu bị định dạng lỗi (malformed), người đề xuất (proposer) làm sai, hết thời gian chờ (timeout). Việc kiểm tra ở đây “nông” hơn nhiều.

Vì vậy về mặt cơ chế, một khối xấu có thể vượt ngưỡng quorum nhanh hơn so với một khối tốt vượt qua khâu xác thực — không phải vì mạng ưu ái các khối không hợp lệ, mà vì việc từ chối không cần phải xây dựng lại tính đúng đắn, chỉ cần phát hiện sự vắng mặt của nó. Điều đó không phải là một khiếm khuyết. Thực ra đó là lý do mà các iteration tồn tại ngay từ đầu: fail fast (thất bại nhanh), nhường slot cho bên cung cấp (provisioner) tiếp theo, và giữ cho thời gian tạo khối (block time) có thể dự đoán.

Mình vẫn đang tiếp tục tìm hiểu bất đối xứng này có ý nghĩa gì khi kích thước ủy ban thay đổi theo phân bổ stake. Liệu việc từ chối nhanh trở thành một bề mặt tấn công, hay chỉ là khả năng phục hồi (resilience) được thiết kế sẵn?

@Dusk #dusk $DUSK