Tôi đã xem xét kỹ hơn cách @Dusk xử lý sự đồng thuận, và một chi tiết mà tôi thấy dễ bỏ qua là quy trình này không được coi như một quyết định duy nhất.

Ban đầu, khối Ama được chuẩn bị và đề xuất. Sau đó, các người tham gia bỏ phiếu sẽ đánh giá nó trước khi mạng đồng ý về trạng thái kết quả.

Tôi thấy sự tách bạch này quan trọng vì việc tạo ra một khối ứng viên và việc chấp nhận khối đó không phải là cùng một việc. Nếu một đề xuất là sai, giai đoạn bỏ phiếu sẽ cung cấp một điểm riêng để người tham gia có thể từ chối, thay vì coi việc tạo khối bản thân là sự chấp nhận.

Tôi thích thiết kế này từ góc nhìn hệ thống. Nó làm cho logic dễ tách bạch hơn: đề xuất trước, đạt đồng thuận sau.

Nhưng còn một khía cạnh khác mà tôi cứ nghĩ tới. Các giai đoạn rõ ràng hơn cũng đồng nghĩa với việc cần nhiều phối hợp hơn giữa các thành phần. Nếu các giai đoạn đó phụ thuộc vào nhau, thì cấu trúc bổ sung có thể tạo ra thêm những nơi mà việc phối hợp cần phải hoạt động đúng.

Quan điểm của tôi là câu hỏi thú vị không phải liệu thiết kế có vẻ “sophisticated” (tinh vi) hay không. Mà là liệu sự tách bạch đó có thực sự cải thiện khả năng chịu lỗi mà không tạo ra sự phức tạp không cần thiết hay không.

Liệu đồng thuận theo giai đoạn có làm cho Dusk vững chắc hơn trước các đề xuất xấu không? Hay sự phối hợp bổ sung tạo ra một sự đánh đổi mới?
#dusk $DUSK