#dusk $DUSK Thông báo nguy hiểm nhất trong hậu trường chứng khoán: không nhất định là “thất bại”, mà là “đã được tiếp nhận”. Thất bại ít nhất khiến người ta dừng lại; còn “đã được tiếp nhận” lại rất dễ bị hiểu nhầm là tiền hàng đã chốt xong. Trên chuỗi cũng vậy: khối đã vào sổ cái địa phương không có nghĩa là nó đã đi đến bước cuối cùng tuyệt đối không thể thay thế.
Tôi đọc lại whitepaper @Dusk về Rolling Finality, và mới nhận ra Dusk không trộn tất cả “xác nhận” thành một từ, mà tách thành bốn trạng thái: accepted, attested, confirmed và final. Khối accepted dù đã có bằng chứng thành công, nhưng nếu nó đến từ một vòng lặp (iteration) cao hơn, và các iteration trước đó không có bằng chứng thất bại, thì khi về sau xuất hiện một khối hợp lệ ở iteration thấp hơn, nó vẫn có thể bị thay thế; các khối phía sau cũng sẽ bị quay lui theo.
attested thì vững hơn, vì nó hoặc đến từ lần lặp thứ 0, hoặc trước đó tất cả các iteration đều đã để lại bằng chứng thất bại; confirmed còn cần các khối tiếp theo tiếp tục tăng độ tin cậy cho chuỗi hiện tại; chỉ có final mới đại diện cho việc khối cha cũng đã final—tức toàn bộ đường tổ tiên bị “khóa cứng”, không còn có thể bị thay thế.
Whitepaper đưa ra một ví dụ cụ thể: một khối được sinh ở lần lặp thứ 5, nhưng trước đó chỉ có hai lần lặp mang bằng chứng thất bại. Khối đó ban đầu được đánh dấu là accepted, cần đợi thêm 4 khối attested hoặc confirmed liên tiếp thì mới chuyển sang confirmed. Nói cách khác, giữa “đã tạo ra khối” và “có thể coi việc giao nhận chứng khoán như một thực tế không thể hủy bỏ”, đúng là có thể có vài bước.
Tôi đánh giá cao sự thẳng thắn này. Hệ thống tài chính sợ nhất việc giấu xác suất vào một dấu tick màu xanh. Nhưng nó cũng để lại bài học cho phía sản phẩm: ví, nơi giao dịch và hệ thống đăng ký rốt cuộc sẽ hiển thị trạng thái nào? Khi người dùng thấy accepted, họ có thể tiếp tục chuyển nhượng hay được quyền chuộc lại hay không? Nếu giao diện thống nhất viết “thành công”, thì dù trạng thái đồng thuận có chặt chẽ đến đâu cũng có thể bị lời copy của sản phẩm làm phẳng đi.
Vì vậy, khi tôi xem “kết thúc theo giây” của Dusk, tôi không chỉ nhìn trung bình mất bao nhiêu giây, mà còn nhìn phân bố từ accepted sang final trong các iteration bất thường, và liệu ứng dụng có thực sự đợi đến final rồi mới “ghi nhận” hay không. Tính cuối cùng không phải là một con số marketing, mà là một kỷ luật không cho phép nói “gần như xong” thành “đã xong”.
Tôi đọc lại whitepaper @Dusk về Rolling Finality, và mới nhận ra Dusk không trộn tất cả “xác nhận” thành một từ, mà tách thành bốn trạng thái: accepted, attested, confirmed và final. Khối accepted dù đã có bằng chứng thành công, nhưng nếu nó đến từ một vòng lặp (iteration) cao hơn, và các iteration trước đó không có bằng chứng thất bại, thì khi về sau xuất hiện một khối hợp lệ ở iteration thấp hơn, nó vẫn có thể bị thay thế; các khối phía sau cũng sẽ bị quay lui theo.
attested thì vững hơn, vì nó hoặc đến từ lần lặp thứ 0, hoặc trước đó tất cả các iteration đều đã để lại bằng chứng thất bại; confirmed còn cần các khối tiếp theo tiếp tục tăng độ tin cậy cho chuỗi hiện tại; chỉ có final mới đại diện cho việc khối cha cũng đã final—tức toàn bộ đường tổ tiên bị “khóa cứng”, không còn có thể bị thay thế.
Whitepaper đưa ra một ví dụ cụ thể: một khối được sinh ở lần lặp thứ 5, nhưng trước đó chỉ có hai lần lặp mang bằng chứng thất bại. Khối đó ban đầu được đánh dấu là accepted, cần đợi thêm 4 khối attested hoặc confirmed liên tiếp thì mới chuyển sang confirmed. Nói cách khác, giữa “đã tạo ra khối” và “có thể coi việc giao nhận chứng khoán như một thực tế không thể hủy bỏ”, đúng là có thể có vài bước.
Tôi đánh giá cao sự thẳng thắn này. Hệ thống tài chính sợ nhất việc giấu xác suất vào một dấu tick màu xanh. Nhưng nó cũng để lại bài học cho phía sản phẩm: ví, nơi giao dịch và hệ thống đăng ký rốt cuộc sẽ hiển thị trạng thái nào? Khi người dùng thấy accepted, họ có thể tiếp tục chuyển nhượng hay được quyền chuộc lại hay không? Nếu giao diện thống nhất viết “thành công”, thì dù trạng thái đồng thuận có chặt chẽ đến đâu cũng có thể bị lời copy của sản phẩm làm phẳng đi.
Vì vậy, khi tôi xem “kết thúc theo giây” của Dusk, tôi không chỉ nhìn trung bình mất bao nhiêu giây, mà còn nhìn phân bố từ accepted sang final trong các iteration bất thường, và liệu ứng dụng có thực sự đợi đến final rồi mới “ghi nhận” hay không. Tính cuối cùng không phải là một con số marketing, mà là một kỷ luật không cho phép nói “gần như xong” thành “đã xong”.
