Tối nay mình đang xem phần “tính cuối cùng cuộn” (Rolling Finality) của whitepaper @Dusk , vốn chỉ định lướt qua cho biết. Ai ngờ mắc kẹt gần hai tiếng mà chưa kịp đọc tiếp.
Hầu hết mọi người hiểu khá sơ về “xác nhận khối” (block confirmation): khối đã được đưa lên chuỗi thì coi như an toàn, cùng lắm chỉ đợi thêm vài lần xác nhận để yên tâm hơn. Trước đây mình cũng nghĩ như vậy, cho đến khi mình tính chi tiết các quy tắc Rolling Finality của Dusk, mới phát hiện trực giác “đợi thêm số lần xác nhận” trên chuỗi này có thể là sai.
Dusk chia trạng thái của khối thành bốn mức: accepted, attested, confirmed, final. Nghe giống cách phân cấp thông thường, nhưng “quỷ nằm ở chi tiết” — nếu một khối không đạt đồng thuận trong điều kiện “lặp lại thất bại của các tiền thứ tự bằng 0” (tức là n>0, phía trước đã từng có lần lặp thất bại), thì khối đó chỉ được gắn nhãn accepted trước, chứ chưa thể chuyển sang attested chắc chắn hơn. Trạng thái accepted có nghĩa về mặt lý thuyết nó vẫn có thể bị thay thế bởi một khối ứng viên có thứ tự vòng lặp (iteration) thấp hơn.
Muốn trở thành confirmed thì cần bao nhiêu khối xác nhận tiếp theo? Câu trả lời không phải là 1 hay 3 khối cố định, mà là 2×n khối. n là số lần lặp thất bại trước đó. Ví dụ trong whitepaper: iteration số 5, có 2 lần lặp thất bại trước đó — trong trường hợp này, phải chờ đủ 4 khối attested/confirmed tiếp theo thì mới coi là ổn.
Mình đã đọc quy tắc này đến ba lần mới chắc chắn rằng mình không hiểu nhầm.
Điều này đồng nghĩa là hai khối “đã được đưa lên chuỗi” trông có vẻ như nhau nhưng rủi ro lại không cân bằng — một khối đạt thành công ngay từ đầu (không có thất bại ở tiền thứ tự) gần như lập tức bước vào trạng thái attested vững hơn; còn một khối đã trải qua vài lần thất bại lặp rồi mới thành công thì cần chờ thêm nhiều khối phía sau để đạt cùng mức “kháng thay thế” như nhau. Bề ngoài đều là “đã xác nhận”, nhưng mức độ mong manh ở phía dưới được phân tầng.
Vì vậy, cách mình làm bây giờ là: trong các tình huống cần đánh giá “giao dịch này rốt cuộc có thực sự vững không”, mình không chỉ nhìn mỗi chỉ số số lần xác nhận. Thay vào đó, mình sẽ xem giao dịch nằm trong khối đã trải qua bao nhiêu lần lặp thất bại — iteration càng cao thì mình sẵn sàng chờ thêm càng nhiều khối xác nhận, đặc biệt trong các kịch bản thanh toán số tiền lớn.
Nếu bạn chỉ thực hiện chuyển khoản nhỏ tần suất cao thì các chi tiết này không mấy ý nghĩa, vì “cửa sổ rủi ro” vốn đã ngắn. Nhưng nếu bạn đang làm settlement cấp tổ chức theo kiểu DvP hoặc các giao dịch OTC giá trị lớn, thì giá trị n này đáng để bạn tự tra trong dữ liệu các node của Dusk. #dusk $DUSK @Dusk
Hầu hết mọi người hiểu khá sơ về “xác nhận khối” (block confirmation): khối đã được đưa lên chuỗi thì coi như an toàn, cùng lắm chỉ đợi thêm vài lần xác nhận để yên tâm hơn. Trước đây mình cũng nghĩ như vậy, cho đến khi mình tính chi tiết các quy tắc Rolling Finality của Dusk, mới phát hiện trực giác “đợi thêm số lần xác nhận” trên chuỗi này có thể là sai.
Dusk chia trạng thái của khối thành bốn mức: accepted, attested, confirmed, final. Nghe giống cách phân cấp thông thường, nhưng “quỷ nằm ở chi tiết” — nếu một khối không đạt đồng thuận trong điều kiện “lặp lại thất bại của các tiền thứ tự bằng 0” (tức là n>0, phía trước đã từng có lần lặp thất bại), thì khối đó chỉ được gắn nhãn accepted trước, chứ chưa thể chuyển sang attested chắc chắn hơn. Trạng thái accepted có nghĩa về mặt lý thuyết nó vẫn có thể bị thay thế bởi một khối ứng viên có thứ tự vòng lặp (iteration) thấp hơn.
Muốn trở thành confirmed thì cần bao nhiêu khối xác nhận tiếp theo? Câu trả lời không phải là 1 hay 3 khối cố định, mà là 2×n khối. n là số lần lặp thất bại trước đó. Ví dụ trong whitepaper: iteration số 5, có 2 lần lặp thất bại trước đó — trong trường hợp này, phải chờ đủ 4 khối attested/confirmed tiếp theo thì mới coi là ổn.
Mình đã đọc quy tắc này đến ba lần mới chắc chắn rằng mình không hiểu nhầm.
Điều này đồng nghĩa là hai khối “đã được đưa lên chuỗi” trông có vẻ như nhau nhưng rủi ro lại không cân bằng — một khối đạt thành công ngay từ đầu (không có thất bại ở tiền thứ tự) gần như lập tức bước vào trạng thái attested vững hơn; còn một khối đã trải qua vài lần thất bại lặp rồi mới thành công thì cần chờ thêm nhiều khối phía sau để đạt cùng mức “kháng thay thế” như nhau. Bề ngoài đều là “đã xác nhận”, nhưng mức độ mong manh ở phía dưới được phân tầng.
Vì vậy, cách mình làm bây giờ là: trong các tình huống cần đánh giá “giao dịch này rốt cuộc có thực sự vững không”, mình không chỉ nhìn mỗi chỉ số số lần xác nhận. Thay vào đó, mình sẽ xem giao dịch nằm trong khối đã trải qua bao nhiêu lần lặp thất bại — iteration càng cao thì mình sẵn sàng chờ thêm càng nhiều khối xác nhận, đặc biệt trong các kịch bản thanh toán số tiền lớn.
Nếu bạn chỉ thực hiện chuyển khoản nhỏ tần suất cao thì các chi tiết này không mấy ý nghĩa, vì “cửa sổ rủi ro” vốn đã ngắn. Nhưng nếu bạn đang làm settlement cấp tổ chức theo kiểu DvP hoặc các giao dịch OTC giá trị lớn, thì giá trị n này đáng để bạn tự tra trong dữ liệu các node của Dusk. #dusk $DUSK @Dusk