@Dusk
Ban đầu tôi cho rằng chế độ khẩn cấp của Dusk chủ yếu là một phương án dự phòng cho việc tạo khối bị kẹt. Nhưng khi tôi xem kỹ hơn, một chi tiết nhỏ lại nổi bật: các lần lặp mở (open iterations) có thể tiếp tục đồng thời. Một lần lặp mới bắt đầu sau khi hết thời gian chờ tối đa cho bước (maximum step timeout), trong khi các lần lặp trước vẫn còn sống cho đến khi chúng thực sự đạt được ngưỡng chấp nhận (quorum). Điều đó có nghĩa là giao thức chấp nhận các nỗ lực song song tạm thời thay vì bắt mạng phải chờ trên một nhánh bị kẹt. Chi phí hiển nhiên là cuối cùng có thể có một vài ứng viên đạt được đồng thuận, tạo ra một nhánh tách (fork) và sau đó phải được giải quyết bằng cách chọn iteration có giá trị thấp nhất. Tôi thấy sự đánh đổi này thú vị hơn chính cái nhãn “khẩn cấp”. Dusk thực chất đang đổi một phần rối loạn ngắn hạn để lấy cơ hội tốt hơn rằng ít nhất một lộ trình sẽ tiến triển khi các bộ cung cấp (provisioners) bị thiếu hoặc bị cô lập. Có lẽ đây là một kiểu hỏng hóc hợp lý, nhưng nó lại chuyển độ phức tạp từ việc chờ sang việc giải quyết fork.
Làm tôi tự hỏi liệu đôi khi khả năng phục hồi (resilience) không hẳn là để tránh các trạng thái lộn xộn, mà là để đảm bảo rằng sự lộn xộn đó có một lối thoát mang tính xác định (deterministic) không?
@Dusk #dusk $DUSK
Ban đầu tôi cho rằng chế độ khẩn cấp của Dusk chủ yếu là một phương án dự phòng cho việc tạo khối bị kẹt. Nhưng khi tôi xem kỹ hơn, một chi tiết nhỏ lại nổi bật: các lần lặp mở (open iterations) có thể tiếp tục đồng thời. Một lần lặp mới bắt đầu sau khi hết thời gian chờ tối đa cho bước (maximum step timeout), trong khi các lần lặp trước vẫn còn sống cho đến khi chúng thực sự đạt được ngưỡng chấp nhận (quorum). Điều đó có nghĩa là giao thức chấp nhận các nỗ lực song song tạm thời thay vì bắt mạng phải chờ trên một nhánh bị kẹt. Chi phí hiển nhiên là cuối cùng có thể có một vài ứng viên đạt được đồng thuận, tạo ra một nhánh tách (fork) và sau đó phải được giải quyết bằng cách chọn iteration có giá trị thấp nhất. Tôi thấy sự đánh đổi này thú vị hơn chính cái nhãn “khẩn cấp”. Dusk thực chất đang đổi một phần rối loạn ngắn hạn để lấy cơ hội tốt hơn rằng ít nhất một lộ trình sẽ tiến triển khi các bộ cung cấp (provisioners) bị thiếu hoặc bị cô lập. Có lẽ đây là một kiểu hỏng hóc hợp lý, nhưng nó lại chuyển độ phức tạp từ việc chờ sang việc giải quyết fork.
Làm tôi tự hỏi liệu đôi khi khả năng phục hồi (resilience) không hẳn là để tránh các trạng thái lộn xộn, mà là để đảm bảo rằng sự lộn xộn đó có một lối thoát mang tính xác định (deterministic) không?
@Dusk #dusk $DUSK
