#dusk $DUSK @Dusk $DUSK
Đề xuất, Xác thực, Phê chuẩn: Con đường ba bước của Dusk để đi tới một khối cuối cùng
Tôi cứ tưởng rằng tính “chốt khối” trên Dusk hoạt động như một lá phiếu duy nhất — đề xuất, xác nhận, xong.
Nhưng thực ra là ba bước tách biệt, và tôi đã phải đi lần lượt qua từng bước để hiểu vì sao.
Bước Đề xuất chọn ra một bên cung cấp (provisioner) thông qua cơ chế chọn lọc ngẫu nhiên quyết định (deterministic sortition), để tạo một khối ứng viên rồi phát tán nó đi. Nếu không có gì đến trước thời hạn (timeout) thì vòng lặp đó chỉ thất bại — không có khối ứng viên, và theo những gì tôi xem được trong tài liệu, dường như không có bước sinh dự phòng (fallback generator) nào được kích hoạt cả.
Tôi đã lần theo những gì xảy ra tiếp theo. Kết quả đầu vào được đưa vào bước Xác thực: một ủy ban mới, cũng được chọn ngẫu nhiên, sẽ kiểm tra khối ứng viên so với đỉnh chuỗi hiện tại và bỏ phiếu Hợp lệ (Valid) hoặc Không hợp lệ (Invalid). Cần có ngưỡng hai phần ba bỏ phiếu Hợp lệ, hoặc đa số đơn bỏ phiếu Không hợp lệ — bất kỳ ngưỡng nào cũng sẽ kết thúc bước đó.
Bước thứ ba, và đây là điểm suýt nữa tôi bỏ lỡ: Phê chuẩn (Ratification). Lần này lại là một ủy ban khác, bỏ phiếu cụ thể xem việc Xác thực có thực sự đạt được “quorum” (tỷ lệ cần thiết) hay không — chứ không phải xem lại nội dung của khối lần nữa. Quy tắc hai phần ba hoặc đa số cũng áp dụng tương tự ở đây.
Ba ủy ban, ba phán quyết riêng — tôi không thể tìm thấy bước nào lặp lại một công việc mà bước trước đó đã làm.
Điểm nổi bật với tôi là chuỗi trình tự này được soi xét kỹ đến mức nào trước khi đưa lên mainnet. Dusk đã chạy mười cuộc kiểm toán trên toàn bộ hệ thống, với hơn hai trăm trang báo cáo. Trong số mười cuộc đó, một cuộc của Oak Security tập trung cụ thể vào SA, nêu ra các vấn đề liên quan đến động lực cắt phạt (slashing incentives) và logic bỏ phiếu — tất cả đều được giải quyết trước khi ra mắt.
Vì vậy, theo những gì tôi thấy, “chốt khối” không phải là một quyết định duy nhất. Đó là ba lần kiểm tra độc lập được xếp chồng theo trình tự, và mỗi lần đều có thể khởi động lại quy trình — tối đa đến năm mươi lần lặp mỗi vòng — nếu không đạt.
Mức độ soi xét trước khi ra mắt như vậy có thực sự làm giảm rủi ro ở đây, hay chỉ có nghĩa là mọi lỗi lọt qua thì sau này sẽ khó phát hiện hơn?
Đề xuất, Xác thực, Phê chuẩn: Con đường ba bước của Dusk để đi tới một khối cuối cùng
Tôi cứ tưởng rằng tính “chốt khối” trên Dusk hoạt động như một lá phiếu duy nhất — đề xuất, xác nhận, xong.
Nhưng thực ra là ba bước tách biệt, và tôi đã phải đi lần lượt qua từng bước để hiểu vì sao.
Bước Đề xuất chọn ra một bên cung cấp (provisioner) thông qua cơ chế chọn lọc ngẫu nhiên quyết định (deterministic sortition), để tạo một khối ứng viên rồi phát tán nó đi. Nếu không có gì đến trước thời hạn (timeout) thì vòng lặp đó chỉ thất bại — không có khối ứng viên, và theo những gì tôi xem được trong tài liệu, dường như không có bước sinh dự phòng (fallback generator) nào được kích hoạt cả.
Tôi đã lần theo những gì xảy ra tiếp theo. Kết quả đầu vào được đưa vào bước Xác thực: một ủy ban mới, cũng được chọn ngẫu nhiên, sẽ kiểm tra khối ứng viên so với đỉnh chuỗi hiện tại và bỏ phiếu Hợp lệ (Valid) hoặc Không hợp lệ (Invalid). Cần có ngưỡng hai phần ba bỏ phiếu Hợp lệ, hoặc đa số đơn bỏ phiếu Không hợp lệ — bất kỳ ngưỡng nào cũng sẽ kết thúc bước đó.
Bước thứ ba, và đây là điểm suýt nữa tôi bỏ lỡ: Phê chuẩn (Ratification). Lần này lại là một ủy ban khác, bỏ phiếu cụ thể xem việc Xác thực có thực sự đạt được “quorum” (tỷ lệ cần thiết) hay không — chứ không phải xem lại nội dung của khối lần nữa. Quy tắc hai phần ba hoặc đa số cũng áp dụng tương tự ở đây.
Ba ủy ban, ba phán quyết riêng — tôi không thể tìm thấy bước nào lặp lại một công việc mà bước trước đó đã làm.
Điểm nổi bật với tôi là chuỗi trình tự này được soi xét kỹ đến mức nào trước khi đưa lên mainnet. Dusk đã chạy mười cuộc kiểm toán trên toàn bộ hệ thống, với hơn hai trăm trang báo cáo. Trong số mười cuộc đó, một cuộc của Oak Security tập trung cụ thể vào SA, nêu ra các vấn đề liên quan đến động lực cắt phạt (slashing incentives) và logic bỏ phiếu — tất cả đều được giải quyết trước khi ra mắt.
Vì vậy, theo những gì tôi thấy, “chốt khối” không phải là một quyết định duy nhất. Đó là ba lần kiểm tra độc lập được xếp chồng theo trình tự, và mỗi lần đều có thể khởi động lại quy trình — tối đa đến năm mươi lần lặp mỗi vòng — nếu không đạt.
Mức độ soi xét trước khi ra mắt như vậy có thực sự làm giảm rủi ro ở đây, hay chỉ có nghĩa là mọi lỗi lọt qua thì sau này sẽ khó phát hiện hơn?
Reduces the risk
50%
Harder to find later
17%
Depends on the audit
17%
Not sure yet
16%
6 phiếu bầu • Cuộc bỏ phiếu đã kết thúc