NÚT DỰ PHÒNG CÓ THỂ TRỞ THÀNH LỖI.
Một cảnh báo trong tài liệu của @Dusk về provisioner đã khiến tôi phải suy nghĩ lại “tính dự phòng” có nghĩa là gì đối với một validator.
Dusk cảnh báo rõ ràng cho các nhà vận hành không nên sử dụng cùng một khóa đồng thuận trên nhiều nút đang hoạt động.
Thoạt đầu điều đó nghe có vẻ lạ.
Với hạ tầng thông thường, việc chuẩn bị sẵn hai máy để làm cùng một công việc chính là cách giảm thời gian ngừng hoạt động.
Nhưng khóa đồng thuận lại khác.
Nếu hai nút đang hoạt động dùng chung danh tính và kết thúc việc ký các đề xuất hoặc phiếu bầu xung đột, thì chính sự “dự phòng” đó có thể trở thành equivocation.
Và Dusk xử lý điều này khác rất nhiều so với việc chỉ đơn giản là ngoại tuyến.
Điều này giúp tôi rút ra một sự phân biệt mà trước đây tôi chưa nghĩ rõ ràng:
dự phòng hạ tầng ≠ dự phòng đồng thuận.
Một provisioner muốn nút dự phòng sẵn sàng đủ tốt để chuyển đổi (take over) nhanh chóng.
Nhưng không đến mức cả hai máy đều có thể nói thay cho cùng một danh tính khóa đồng thuận cùng lúc.
Điều đó khiến thiết kế failover trở nên thú vị hơn rất nhiều so với chỉ “chạy thêm một máy chủ.”
Có một ranh giới rất hẹp giữa:
một nút lỗi → nút dự phòng tiếp quản
và
cả hai nút trong khoảnh khắc ngắn đều tin rằng mình là người ký đồng thuận đang hoạt động.
Trong trường hợp thứ hai, hệ thống an toàn có thể trở thành thứ tạo ra rủi ro.
Tài liệu của Dusk phân loại hành vi đồng thuận xung đột là kiểu sự cố có thể dẫn đến hình phạt nặng, bao gồm cả việc đốt một phần số stake.
Vì vậy, chỉ số vận hành mà tôi quan tâm không chỉ là thời gian uptime của provisioner.
Tôi muốn biết mức độ tin cậy của việc một nhà vận hành có thể failover giữa các máy mà không bao giờ vô tình tạo ra một khóa đồng thuận kiểu active-active.
Đó là một định nghĩa hoàn toàn khác về tính sẵn sàng cao.
Nút dự phòng an toàn nhất có lẽ là nút
được chuẩn bị hoàn toàn để sẵn sàng ký—
nhưng không ký cho đến khi nút đầu tiên chắc chắn đã biến mất.
#dusk $DUSK @Dusk
$BTW
$HEMI
Một cảnh báo trong tài liệu của @Dusk về provisioner đã khiến tôi phải suy nghĩ lại “tính dự phòng” có nghĩa là gì đối với một validator.
Dusk cảnh báo rõ ràng cho các nhà vận hành không nên sử dụng cùng một khóa đồng thuận trên nhiều nút đang hoạt động.
Thoạt đầu điều đó nghe có vẻ lạ.
Với hạ tầng thông thường, việc chuẩn bị sẵn hai máy để làm cùng một công việc chính là cách giảm thời gian ngừng hoạt động.
Nhưng khóa đồng thuận lại khác.
Nếu hai nút đang hoạt động dùng chung danh tính và kết thúc việc ký các đề xuất hoặc phiếu bầu xung đột, thì chính sự “dự phòng” đó có thể trở thành equivocation.
Và Dusk xử lý điều này khác rất nhiều so với việc chỉ đơn giản là ngoại tuyến.
Điều này giúp tôi rút ra một sự phân biệt mà trước đây tôi chưa nghĩ rõ ràng:
dự phòng hạ tầng ≠ dự phòng đồng thuận.
Một provisioner muốn nút dự phòng sẵn sàng đủ tốt để chuyển đổi (take over) nhanh chóng.
Nhưng không đến mức cả hai máy đều có thể nói thay cho cùng một danh tính khóa đồng thuận cùng lúc.
Điều đó khiến thiết kế failover trở nên thú vị hơn rất nhiều so với chỉ “chạy thêm một máy chủ.”
Có một ranh giới rất hẹp giữa:
một nút lỗi → nút dự phòng tiếp quản
và
cả hai nút trong khoảnh khắc ngắn đều tin rằng mình là người ký đồng thuận đang hoạt động.
Trong trường hợp thứ hai, hệ thống an toàn có thể trở thành thứ tạo ra rủi ro.
Tài liệu của Dusk phân loại hành vi đồng thuận xung đột là kiểu sự cố có thể dẫn đến hình phạt nặng, bao gồm cả việc đốt một phần số stake.
Vì vậy, chỉ số vận hành mà tôi quan tâm không chỉ là thời gian uptime của provisioner.
Tôi muốn biết mức độ tin cậy của việc một nhà vận hành có thể failover giữa các máy mà không bao giờ vô tình tạo ra một khóa đồng thuận kiểu active-active.
Đó là một định nghĩa hoàn toàn khác về tính sẵn sàng cao.
Nút dự phòng an toàn nhất có lẽ là nút
được chuẩn bị hoàn toàn để sẵn sàng ký—
nhưng không ký cho đến khi nút đầu tiên chắc chắn đã biến mất.
#dusk $DUSK @Dusk
$BTW
$HEMI