Ai cũng bàn về tính chốt cuối nhanh của Dusk. Tôi lại thấy phần thú vị nằm ở chuyện gì xảy ra khi khối đầu tiên bị lỗi.@Dusk

Tôi đã dành cả buổi chiều để đào sâu các quy tắc chốt cuối của Dusk trong whitepaper và tài liệu hiện hành, và chính nhánh n=0 mới là thứ đã chặn tôi lại.

Các khối đi qua bốn trạng thái: Được chấp nhận (Accepted), Đã được chứng thực (Attested), Xác nhận (Confirmed), rồi Cuối cùng (Final). Con số then chốt là n — số lần lặp trước đó trong cùng một lượt đã thất bại.

Khi n bằng không, khối sẽ được đánh dấu Attested ngay lập tức. Khi nó có một người kế nhiệm duy nhất mà bản thân người kế nhiệm đó là Attested hoặc Confirmed, thì nó sẽ trở thành Confirmed. Đây chính là “đường nhanh” mà tài liệu mô tả.

Khi n lớn hơn không, các quy tắc thay đổi. Khối chỉ bắt đầu ở trạng thái Accepted. Sau đó, nó cần 2n khối liên tiếp là Attested hoặc Confirmed sau nó trước khi có thể đạt Confirmed. Chẳng hạn, một khối ở vòng lặp-5 (iteration-5) với hai lần thất bại trước đó sẽ cần thêm bốn khối “tốt” nữa. Chỉ sau khi nó đã Confirmed và cha của nó đã Final thì nó mới trở nên không thể đảo ngược.

Thiết kế cố ý trao cho bộ tạo (generator) thành công đầu tiên tính chốt cuối mạnh hơn. Các bộ tạo sau chỉ nhận được cùng mức độ mạnh đó khi mạng đã thấy thêm bằng chứng rằng các nỗ lực trước thực sự đã thất bại.

Phần đó thì ổn.

Điều làm tôi cứ băn khoăn là vì sao đường chậm lại hiếm khi xuất hiện trong câu chuyện hằng ngày. Trong điều kiện bình thường, hầu hết các khối đi theo lộ trình n=0 và đạt chốt cuối mạnh rất nhanh. Những yêu cầu bổ sung chỉ xuất hiện khi mạng đã bắt đầu chịu áp lực.

Tuy vậy, vẫn tò mò không biết có bao nhiêu người trích dẫn “chốt cuối tức thì” thực sự đã ngồi lại để so sánh giữa hai con đường.
#dusk $DUSK