Hầu hết các blockchain khi gặp tình huống một lượng lớn node ngoại tuyến đều rơi vào một trong hai lựa chọn: hoặc “cứng rắn chống đỡ” để tiếp tục sản xuất khối theo đúng kế hoạch; nếu không bầu đủ người xác thực thì cứ để bị kẹt và chờ vòng tiếp theo; hoặc dừng hẳn hoạt động, chờ can thiệp thủ công. Dusk nằm giữa hai lựa chọn đó và thiết kế một câu trả lời thứ ba.
Bản whitepaper ở mục Section 3.6 viết rất cụ thể: nếu phần lớn Provisioner ngoại tuyến hoặc bị cách ly, nhiều vòng lặp liên tiếp không thể bầu ra người sản xuất khối và không đủ số phiếu để thành lập ủy ban bỏ phiếu, đạt ngưỡng thất bại (hiện được đặt là 16 lần) thì giao thức sẽ chuyển sang chế độ khẩn cấp.
Trong chế độ này, cơ chế timeout ban đầu bị tắt, việc lặp tiếp tục diễn ra cho đến khi thực sự tạo ra được ứng viên khối và ở cả hai bước xác minh lẫn phê duyệt đều đủ số lượng hợp lệ; đồng thời cho phép nhiều vòng lặp chạy song song để tăng xác suất tạo ra khối hợp lệ ngay cả trong tình huống cực đoan.
Nếu ngay cả cơ chế này cũng không gánh nổi, giao thức vẫn giữ “lớp bảo hiểm cuối cùng” — do các Provisioner nắm giữ đa số lượng thế chấp phối hợp khởi xướng yêu cầu, tạo ra một “khối khẩn cấp” không chứa bất kỳ giao dịch nào, chỉ mang theo hạt giống (seed) mới, để chuỗi có thể tiến thêm một bước, tránh việc bị treo vô thời hạn.
Quan điểm của tôi là thiết kế này về bản chất lấy “rủi ro phân nhánh” để đổi lấy “khả năng sống còn của mạng”. Việc cho phép nhiều vòng lặp song song chạy đồng thời sẽ làm xác suất phân nhánh tăng lên; nhưng bù lại, các quy tắc thoái lui/hoàn nguyên phía sau sẽ dọn dẹp hiện trường. Tuy nhiên cái giá đó đồng thời đảm bảo mạng không bị “chết máy hoàn toàn” chỉ vì tình huống cực đoan.
Với các tổ chức, cách xử lý những tình huống biên như thế này có lẽ đáng đưa vào phần thẩm định (due diligence) hơn cả việc thanh toán theo giây ở trạng thái bình thường. Trong trạng thái thông thường, đa số các public chain cấp tài chính đều làm được; khoảng cách thật sự nằm ở khi hệ thống gặp trục trặc, họ sẽ “giảm cấp nhưng vẫn vận hành” hay “kẹt cứng ngay lập tức”.
#dusk $DUSK @Dusk
Các bạn nghĩ sao: khi đánh giá độ tin cậy của một blockchain, thiết kế ứng phó trong tình huống cực đoan nên chiếm bao nhiêu trọng số?
Bản whitepaper ở mục Section 3.6 viết rất cụ thể: nếu phần lớn Provisioner ngoại tuyến hoặc bị cách ly, nhiều vòng lặp liên tiếp không thể bầu ra người sản xuất khối và không đủ số phiếu để thành lập ủy ban bỏ phiếu, đạt ngưỡng thất bại (hiện được đặt là 16 lần) thì giao thức sẽ chuyển sang chế độ khẩn cấp.
Trong chế độ này, cơ chế timeout ban đầu bị tắt, việc lặp tiếp tục diễn ra cho đến khi thực sự tạo ra được ứng viên khối và ở cả hai bước xác minh lẫn phê duyệt đều đủ số lượng hợp lệ; đồng thời cho phép nhiều vòng lặp chạy song song để tăng xác suất tạo ra khối hợp lệ ngay cả trong tình huống cực đoan.
Nếu ngay cả cơ chế này cũng không gánh nổi, giao thức vẫn giữ “lớp bảo hiểm cuối cùng” — do các Provisioner nắm giữ đa số lượng thế chấp phối hợp khởi xướng yêu cầu, tạo ra một “khối khẩn cấp” không chứa bất kỳ giao dịch nào, chỉ mang theo hạt giống (seed) mới, để chuỗi có thể tiến thêm một bước, tránh việc bị treo vô thời hạn.
Quan điểm của tôi là thiết kế này về bản chất lấy “rủi ro phân nhánh” để đổi lấy “khả năng sống còn của mạng”. Việc cho phép nhiều vòng lặp song song chạy đồng thời sẽ làm xác suất phân nhánh tăng lên; nhưng bù lại, các quy tắc thoái lui/hoàn nguyên phía sau sẽ dọn dẹp hiện trường. Tuy nhiên cái giá đó đồng thời đảm bảo mạng không bị “chết máy hoàn toàn” chỉ vì tình huống cực đoan.
Với các tổ chức, cách xử lý những tình huống biên như thế này có lẽ đáng đưa vào phần thẩm định (due diligence) hơn cả việc thanh toán theo giây ở trạng thái bình thường. Trong trạng thái thông thường, đa số các public chain cấp tài chính đều làm được; khoảng cách thật sự nằm ở khi hệ thống gặp trục trặc, họ sẽ “giảm cấp nhưng vẫn vận hành” hay “kẹt cứng ngay lập tức”.
#dusk $DUSK @Dusk
Các bạn nghĩ sao: khi đánh giá độ tin cậy của một blockchain, thiết kế ứng phó trong tình huống cực đoan nên chiếm bao nhiêu trọng số?
A. 权重很高,失灵表现最见真章
B. 权重一般,正常表现更常用
C. 得看具体业务场景需求
6 giờ còn lại
