"Hãy chờ 12 xác nhận" là lời khuyên tiêu chuẩn trên hầu hết các chuỗi, và thành thật mà nói, chẳng ai bao giờ giải thích tại sao lại là 12, hoặc điều gì thực sự đang xảy ra trong các khối đó. Dusk không dùng cách rút gọn đó — nó chạy một máy trạng thái thực sự để quyết định khi nào một khối là an toàn.
Một khối đi qua bốn trạng thái: accepted, attested, confirmed, final. Điểm bắt đầu phụ thuộc vào một con số — số lần lặp trước đó trong cùng lượt đó đã thất bại trước khi lần lặp của khối này thành công. Bài nghiên cứu gọi con số này là n. Nếu n = 0, nghĩa là khối rơi vào lần lặp đầu tiên ngay lập tức và không có lần thất bại nào trước nó, thì nó được đánh dấu là attested ngay. Nếu n lớn hơn 0, nghĩa là các lần lặp trước trong lượt đó thất bại trước, thì khối chỉ được đánh dấu là accepted — đây là trạng thái yếu hơn.
Sự khác biệt này quan trọng vì một khối đã được accepted vẫn có thể bị thay thế bởi một khối cạnh tranh đến từ một lần lặp thấp hơn — lúc đó nó chưa an toàn. Một khối attested thì không thể bị thay thế theo cách đó, vì không còn lần lặp thấp hơn nào có thể vượt qua nó. Từ đó, confirmed chỉ có nghĩa là khối đã có đủ các khối successor đúng loại được xếp chồng lên trên, và final nghĩa là toàn bộ chuỗi tổ tiên (ancestors) của nó cũng ở trạng thái final, khóa vĩnh viễn nó lại.
Phần mà tôi thấy thực sự bị đánh giá thấp ở đây là ví dụ ngay trong bài nghiên cứu: một khối ở lần lặp 5, nơi chỉ có hai trong các lần lặp trước đó có fail attestations, được đánh dấu là accepted và cần thêm bốn khối attested hoặc confirmed xếp chồng lên phía trên trước khi được coi là confirmed. Đây không phải là một con số xác nhận tùy tiện rút ra từ đâu, mà là một con số được tính trực tiếp dựa trên mức độ “hỗn loạn” của riêng lượt đó. Lượt suôn sẻ thì hoàn tất nhanh hơn. Lượt rối thì mất nhiều thời gian hơn. Đây là một mô hình hoàn toàn khác với việc "chỉ chờ 12 khối bất kể chuyện gì đã xảy ra".
Nếu tôi nói thật thì, chi tiết thiết kế kiểu này dường như là thứ quan trọng hơn rất nhiều đối với các tổ chức đánh giá tính cuối cùng (settlement finality) hơn là đối với các nhà giao dịch lẻ — không ai đổi token quan tâm đến số lần lặp, nhưng một ngân hàng vận hành một nghiệp vụ thanh toán chứng khoán chắc chắn sẽ quan tâm.
@Dusk
$DUSK
#dusk
Một khối đi qua bốn trạng thái: accepted, attested, confirmed, final. Điểm bắt đầu phụ thuộc vào một con số — số lần lặp trước đó trong cùng lượt đó đã thất bại trước khi lần lặp của khối này thành công. Bài nghiên cứu gọi con số này là n. Nếu n = 0, nghĩa là khối rơi vào lần lặp đầu tiên ngay lập tức và không có lần thất bại nào trước nó, thì nó được đánh dấu là attested ngay. Nếu n lớn hơn 0, nghĩa là các lần lặp trước trong lượt đó thất bại trước, thì khối chỉ được đánh dấu là accepted — đây là trạng thái yếu hơn.
Sự khác biệt này quan trọng vì một khối đã được accepted vẫn có thể bị thay thế bởi một khối cạnh tranh đến từ một lần lặp thấp hơn — lúc đó nó chưa an toàn. Một khối attested thì không thể bị thay thế theo cách đó, vì không còn lần lặp thấp hơn nào có thể vượt qua nó. Từ đó, confirmed chỉ có nghĩa là khối đã có đủ các khối successor đúng loại được xếp chồng lên trên, và final nghĩa là toàn bộ chuỗi tổ tiên (ancestors) của nó cũng ở trạng thái final, khóa vĩnh viễn nó lại.
Phần mà tôi thấy thực sự bị đánh giá thấp ở đây là ví dụ ngay trong bài nghiên cứu: một khối ở lần lặp 5, nơi chỉ có hai trong các lần lặp trước đó có fail attestations, được đánh dấu là accepted và cần thêm bốn khối attested hoặc confirmed xếp chồng lên phía trên trước khi được coi là confirmed. Đây không phải là một con số xác nhận tùy tiện rút ra từ đâu, mà là một con số được tính trực tiếp dựa trên mức độ “hỗn loạn” của riêng lượt đó. Lượt suôn sẻ thì hoàn tất nhanh hơn. Lượt rối thì mất nhiều thời gian hơn. Đây là một mô hình hoàn toàn khác với việc "chỉ chờ 12 khối bất kể chuyện gì đã xảy ra".
Nếu tôi nói thật thì, chi tiết thiết kế kiểu này dường như là thứ quan trọng hơn rất nhiều đối với các tổ chức đánh giá tính cuối cùng (settlement finality) hơn là đối với các nhà giao dịch lẻ — không ai đổi token quan tâm đến số lần lặp, nhưng một ngân hàng vận hành một nghiệp vụ thanh toán chứng khoán chắc chắn sẽ quan tâm.
@Dusk
$DUSK
#dusk
