Tôi đã lục lại tài liệu về Dusk ( @Dusk ) vào tối qua, và càng đi sâu vào phần đồng thuận thì các trường hợp thất bại càng trở nên thú vị.
Ban đầu, chế độ khẩn cấp nghe có vẻ như một bản sao lưu đơn giản. Nhưng tại sao Dusk cần nó nếu giao thức thông thường đã có thể thử lại những vòng lặp bị lỗi? Tài liệu giải thích rằng sau nhiều lần thất bại, giao thức có thể tiếp tục mở các vòng lặp đang chạy cho đến khi đạt được đồng thuận. Điều này khiến tôi tự hỏi liệu mức độ ưu tiên về tính sống (liveness) đang được đặt cao hơn hiệu quả (efficiency) trong các điều kiện mạng cực đoan đến mức nào.
Rồi đến câu hỏi về nhánh (fork). Làm sao hai khối ứng viên có thể đạt đồng thuận trong cùng một vòng? Dusk sử dụng số hiệu vòng lặp và phương án fallback để giải quyết, nhưng một khối có số vòng lặp cao hơn vẫn có thể bị hoàn tác. Với mục đích quyết toán tài chính, sự khác biệt này có vẻ rất quan trọng.
Tôi cũng để ý đến cấu trúc phần thưởng. Các bộ sinh (generators) nhận phần lớn phần thưởng của khối, trong khi người bỏ phiếu nhận một phần riêng. Điều này trở nên hợp lý hơn khi tôi cân nhắc bài toán khuyến khích: điều gì ngăn một bộ sinh trong tương lai được hưởng lợi trong khi các vòng lặp trước đó thất bại?
Hệ thống lỗi bổ sung thêm một lớp khác. Tại sao phải tách các lỗi nhỏ khỏi các lỗi lớn? Việc tạm đình chỉ và soft slashing dường như được thiết kế khác với hard slashing cho các hành vi nghiêm trọng như bỏ phiếu hai lần hoặc tạo các khối không hợp lệ.
Cuối cùng, Moonlight và Phoenix khiến tôi phải suy nghĩ lại lớp giao dịch. Tại sao cần duy trì cả một mô hình minh bạch dựa trên tài khoản (account-based) lẫn một mô hình riêng tư dựa trên UTXO?
Thiết kế song song này có tạo ra tính linh hoạt hữu ích hay chỉ làm tăng thêm độ phức tạp? Và khi Dusk phát triển, liệu phân quyền và an ninh sẽ trở nên khó duy trì ở đâu?
@Dusk_Foundation #dusk $DUSK
Ban đầu, chế độ khẩn cấp nghe có vẻ như một bản sao lưu đơn giản. Nhưng tại sao Dusk cần nó nếu giao thức thông thường đã có thể thử lại những vòng lặp bị lỗi? Tài liệu giải thích rằng sau nhiều lần thất bại, giao thức có thể tiếp tục mở các vòng lặp đang chạy cho đến khi đạt được đồng thuận. Điều này khiến tôi tự hỏi liệu mức độ ưu tiên về tính sống (liveness) đang được đặt cao hơn hiệu quả (efficiency) trong các điều kiện mạng cực đoan đến mức nào.
Rồi đến câu hỏi về nhánh (fork). Làm sao hai khối ứng viên có thể đạt đồng thuận trong cùng một vòng? Dusk sử dụng số hiệu vòng lặp và phương án fallback để giải quyết, nhưng một khối có số vòng lặp cao hơn vẫn có thể bị hoàn tác. Với mục đích quyết toán tài chính, sự khác biệt này có vẻ rất quan trọng.
Tôi cũng để ý đến cấu trúc phần thưởng. Các bộ sinh (generators) nhận phần lớn phần thưởng của khối, trong khi người bỏ phiếu nhận một phần riêng. Điều này trở nên hợp lý hơn khi tôi cân nhắc bài toán khuyến khích: điều gì ngăn một bộ sinh trong tương lai được hưởng lợi trong khi các vòng lặp trước đó thất bại?
Hệ thống lỗi bổ sung thêm một lớp khác. Tại sao phải tách các lỗi nhỏ khỏi các lỗi lớn? Việc tạm đình chỉ và soft slashing dường như được thiết kế khác với hard slashing cho các hành vi nghiêm trọng như bỏ phiếu hai lần hoặc tạo các khối không hợp lệ.
Cuối cùng, Moonlight và Phoenix khiến tôi phải suy nghĩ lại lớp giao dịch. Tại sao cần duy trì cả một mô hình minh bạch dựa trên tài khoản (account-based) lẫn một mô hình riêng tư dựa trên UTXO?
Thiết kế song song này có tạo ra tính linh hoạt hữu ích hay chỉ làm tăng thêm độ phức tạp? Và khi Dusk phát triển, liệu phân quyền và an ninh sẽ trở nên khó duy trì ở đâu?
@Dusk_Foundation #dusk $DUSK