Tuần trước, chúng tôi đã trải qua một đợt mất điện luân phiên ở Islamabad, trong đó lưới điện cứ liên tục lỗi rồi lại cố gắng hoạt động lại. Mỗi lần nó bật lên thì hệ thống dự phòng lại phải khởi động lại từ đầu thay vì tiếp tục từ chỗ nó dừng. Tôi đã cho rằng chế độ khẩn cấp của Dusk cũng hoạt động theo cách tương tự: bị kẹt mạng thì nó cứ thử lại cùng một khoảng thời gian chờ cố định cho đến khi có điều gì đó “dính”.
Nhưng không phải vậy. Chế độ khẩn cấp chỉ kích hoạt sau 16 lần lặp liên tiếp thất bại, và khi nó được kích hoạt, toàn bộ cấu trúc timeout sẽ bị gỡ bỏ. Các vòng lặp không còn hết hạn nữa; chúng chạy vô thời hạn cho đến khi một khối ứng viên thực sự được đề xuất và đạt được ngưỡng chấp thuận (quorum) ở cả bước xác thực (validation) lẫn phê chuẩn (ratification). Các phiếu bầu NoCandidate và NoQuorum cũng bị vô hiệu hóa, vì vậy mọi bước đều phải thành công đúng cách trước khi bước tiếp theo bắt đầu.
Điều thực sự làm tôi hiểu lại là: nhiều vòng lặp mở (open iterations) có thể chạy cùng lúc. Điều này không phải là lỗi, mà là chủ đích—nó làm tăng xác suất rằng ít nhất một vòng lặp sẽ tạo ra một khối hợp lệ. Đổi lại là rủi ro fork cao hơn, và điều đó được giải quyết bằng việc luôn chọn ứng viên đạt đồng thuận ở số vòng lặp thấp nhất.
Ngoài ra còn có “phương án cuối cùng trong phương án cuối cùng”. Nếu ngay cả vòng lặp cuối cùng cũng bị kẹt, những người cung cấp (provisioners) nắm giữ đa số tổng số stake có thể yêu cầu một khối khẩn cấp: một khối rỗng đặc biệt được Dusk ký, không có giao dịch nào trong đó, chỉ để giữ cho vòng chạy tiếp.
Điều mà whitepaper không nói là: cho đến nay, cơ chế này đã thực sự được kích hoạt bao lâu một lần trên hạ tầng Dusk thực tế. Tôi không có dữ liệu để khẳng định tần suất.
Thử nghiệm thực sự đối với DUSK là mức độ hiếm khi chế độ khẩn cấp cần phải kích hoạt sau khi mainnet hoạt động ở quy mô thực.
Có ai đã thực sự chứng kiến chế độ khẩn cấp kích hoạt trên Dusk chưa?
@Dusk #dusk $DUSK
Nhưng không phải vậy. Chế độ khẩn cấp chỉ kích hoạt sau 16 lần lặp liên tiếp thất bại, và khi nó được kích hoạt, toàn bộ cấu trúc timeout sẽ bị gỡ bỏ. Các vòng lặp không còn hết hạn nữa; chúng chạy vô thời hạn cho đến khi một khối ứng viên thực sự được đề xuất và đạt được ngưỡng chấp thuận (quorum) ở cả bước xác thực (validation) lẫn phê chuẩn (ratification). Các phiếu bầu NoCandidate và NoQuorum cũng bị vô hiệu hóa, vì vậy mọi bước đều phải thành công đúng cách trước khi bước tiếp theo bắt đầu.
Điều thực sự làm tôi hiểu lại là: nhiều vòng lặp mở (open iterations) có thể chạy cùng lúc. Điều này không phải là lỗi, mà là chủ đích—nó làm tăng xác suất rằng ít nhất một vòng lặp sẽ tạo ra một khối hợp lệ. Đổi lại là rủi ro fork cao hơn, và điều đó được giải quyết bằng việc luôn chọn ứng viên đạt đồng thuận ở số vòng lặp thấp nhất.
Ngoài ra còn có “phương án cuối cùng trong phương án cuối cùng”. Nếu ngay cả vòng lặp cuối cùng cũng bị kẹt, những người cung cấp (provisioners) nắm giữ đa số tổng số stake có thể yêu cầu một khối khẩn cấp: một khối rỗng đặc biệt được Dusk ký, không có giao dịch nào trong đó, chỉ để giữ cho vòng chạy tiếp.
Điều mà whitepaper không nói là: cho đến nay, cơ chế này đã thực sự được kích hoạt bao lâu một lần trên hạ tầng Dusk thực tế. Tôi không có dữ liệu để khẳng định tần suất.
Thử nghiệm thực sự đối với DUSK là mức độ hiếm khi chế độ khẩn cấp cần phải kích hoạt sau khi mainnet hoạt động ở quy mô thực.
Có ai đã thực sự chứng kiến chế độ khẩn cấp kích hoạt trên Dusk chưa?
@Dusk #dusk $DUSK
