Trước đây tôi thấy xác nhận khối khá đơn giản: giao dịch được đưa vào một khối, rồi đếm thêm vài khối phía sau là cơ bản có thể xem như an toàn. Nhưng tối nay khi xem tài liệu vòng đời giao dịch cho mã @Dusk , một câu đã khiến tôi bị kẹt: “accepted blocks can still be reverted”. Đã được chấp nhận rồi thì tại sao vẫn có thể bị hoàn tác?
Tôi lại lật 2024 Whitepaper và mới hiểu. Một vòng đồng thuận của Dusk sẽ trải qua nhiều iteration; trong cùng một round có thể xuất hiện các khối cạnh tranh. Những khối ở iteration cao hơn, dù đã được accepted, vẫn có thể kích hoạt fallback nếu một khối cạnh tranh ở iteration thấp hơn thỏa điều kiện.
“Thấy được lên chuỗi” không đồng nghĩa với “không thể thay thế”.
Rolling Finality còn ngược trực giác hơn. Whitepaper dùng n để chỉ số iteration phía trước mà phần attestation chưa hoàn tất tính chắc chắn. Các khối đã accepted phải chờ thêm 2×n khối kế tiếp liên tiếp được attested hoặc confirmed thì mới đi vào confirmed. Giả sử n=3, thì phải theo dõi thêm 6 khối tiếp theo thỏa điều kiện.
Đến đây tôi mới nhận ra: “số lượng xác nhận” không phải là một thước đo thống nhất. Cùng là đã lên chuỗi, nhưng lịch sử đồng thuận khác nhau thì mức độ ổn định cũng khác nhau.
Khuyến nghị trong Docs hiện tại còn thẳng hơn: included, accepted thậm chí confirmed cũng đừng coi như tín hiệu “đã到账”; hãy đợi cho đến khi thật sự được finalized.
Chuyển khoản nhỏ có thể chỉ chênh nhau vài giây; nhưng nếu đưa vào việc thanh toán DvP cho các giao dịch OTC giá trị lớn hoặc RWA, thì “thấy giao dịch” và “thanh toán không thể đảo ngược” hoàn toàn là hai chuyện khác nhau. Về sau khi xem giao dịch lớn trên Dusk, chỉ hỏi: đã finalized chưa?
#dusk $DUSK @Dusk
Tôi lại lật 2024 Whitepaper và mới hiểu. Một vòng đồng thuận của Dusk sẽ trải qua nhiều iteration; trong cùng một round có thể xuất hiện các khối cạnh tranh. Những khối ở iteration cao hơn, dù đã được accepted, vẫn có thể kích hoạt fallback nếu một khối cạnh tranh ở iteration thấp hơn thỏa điều kiện.
“Thấy được lên chuỗi” không đồng nghĩa với “không thể thay thế”.
Rolling Finality còn ngược trực giác hơn. Whitepaper dùng n để chỉ số iteration phía trước mà phần attestation chưa hoàn tất tính chắc chắn. Các khối đã accepted phải chờ thêm 2×n khối kế tiếp liên tiếp được attested hoặc confirmed thì mới đi vào confirmed. Giả sử n=3, thì phải theo dõi thêm 6 khối tiếp theo thỏa điều kiện.
Đến đây tôi mới nhận ra: “số lượng xác nhận” không phải là một thước đo thống nhất. Cùng là đã lên chuỗi, nhưng lịch sử đồng thuận khác nhau thì mức độ ổn định cũng khác nhau.
Khuyến nghị trong Docs hiện tại còn thẳng hơn: included, accepted thậm chí confirmed cũng đừng coi như tín hiệu “đã到账”; hãy đợi cho đến khi thật sự được finalized.
Chuyển khoản nhỏ có thể chỉ chênh nhau vài giây; nhưng nếu đưa vào việc thanh toán DvP cho các giao dịch OTC giá trị lớn hoặc RWA, thì “thấy giao dịch” và “thanh toán không thể đảo ngược” hoàn toàn là hai chuyện khác nhau. Về sau khi xem giao dịch lớn trên Dusk, chỉ hỏi: đã finalized chưa?
#dusk $DUSK @Dusk
