Tuần trước tôi gửi chuyển phát nhanh bị nhầm một món. Sau khi liên hệ chăm sóc khách hàng, họ giải thích rằng tình trạng logistics không phải chỉ là “đã gửi” hay “chưa gửi” một cách đơn giản; giữa còn có các giai đoạn như “đã phát hàng”, “đang vận chuyển”, “đã ký nhận”. Ở mỗi giai đoạn, có thể ngăn chặn, thu hồi lại được không—quy tắc hoàn toàn khác nhau. Cúp máy xong tôi chợt nghĩ ra: “xác nhận” trên chuỗi khối cũng vận hành theo logic tương tự—không phải cứ “đã xác nhận” hoặc “chưa xác nhận”.
Bên Dusk, trạng thái của khối được chia làm bốn cấp. Khối vừa ra đời nếu lần bỏ phiếu đầu tiên đã thông qua thì gọi là “attested” (đã được chứng thực). Nếu trước đó đã từng có vòng bỏ phiếu thất bại, đến bây giờ mới thông qua thì gọi là “accepted” (đã được chấp nhận); và khối này vẫn có khả năng bị các khối ở vòng thấp hơn thay thế. Đi tiếp về sau, miễn là có các khối tiếp theo nối vào sau thì “attested” sẽ chuyển thành “confirmed” (đã xác nhận). Còn “accepted” phải đợi đủ số lượng khối tiếp theo để giữ vững thì mới được nâng cấp lên “confirmed”. Bước cuối cùng: “confirmed” chỉ có thể nâng cấp thành “final” (trạng thái chung cuộc) khi “khối cha” của nó cũng ở trạng thái “final”. Trạng thái này một khi đạt được thì hoàn toàn không thể đảo ngược.
Thiết kế phân cấp này giải quyết bài toán “cần nhanh đến mức nào để yên tâm”. Không phải tất cả các khối đều phải chờ đến cấp cao nhất mới dùng được; với tình huống nhẹ (lightweight) có thể chấp nhận “attested” để tiến hành, còn với tài sản giá trị lớn (heavy asset) thì phải đợi tới “final” mới dám yên tâm hoàn toàn. Mức độ chấp nhận rủi ro khác nhau sẽ tương ứng với các ngưỡng xác nhận khác nhau—độ linh hoạt này khá hữu dụng.
Nhưng cái giá phải trả là độ phức tạp—người dùng phổ thông rất khó tự đánh giá giao dịch của mình rốt cuộc đã đi tới cấp nào. Hiện tại phần này chủ yếu dựa vào việc hiển thị của phần mềm nút và lớp ví; trải nghiệm tốt hay không còn phải xem việc triển khai thực tế.
$DUSK
#dusk @Dusk
Bên Dusk, trạng thái của khối được chia làm bốn cấp. Khối vừa ra đời nếu lần bỏ phiếu đầu tiên đã thông qua thì gọi là “attested” (đã được chứng thực). Nếu trước đó đã từng có vòng bỏ phiếu thất bại, đến bây giờ mới thông qua thì gọi là “accepted” (đã được chấp nhận); và khối này vẫn có khả năng bị các khối ở vòng thấp hơn thay thế. Đi tiếp về sau, miễn là có các khối tiếp theo nối vào sau thì “attested” sẽ chuyển thành “confirmed” (đã xác nhận). Còn “accepted” phải đợi đủ số lượng khối tiếp theo để giữ vững thì mới được nâng cấp lên “confirmed”. Bước cuối cùng: “confirmed” chỉ có thể nâng cấp thành “final” (trạng thái chung cuộc) khi “khối cha” của nó cũng ở trạng thái “final”. Trạng thái này một khi đạt được thì hoàn toàn không thể đảo ngược.
Thiết kế phân cấp này giải quyết bài toán “cần nhanh đến mức nào để yên tâm”. Không phải tất cả các khối đều phải chờ đến cấp cao nhất mới dùng được; với tình huống nhẹ (lightweight) có thể chấp nhận “attested” để tiến hành, còn với tài sản giá trị lớn (heavy asset) thì phải đợi tới “final” mới dám yên tâm hoàn toàn. Mức độ chấp nhận rủi ro khác nhau sẽ tương ứng với các ngưỡng xác nhận khác nhau—độ linh hoạt này khá hữu dụng.
Nhưng cái giá phải trả là độ phức tạp—người dùng phổ thông rất khó tự đánh giá giao dịch của mình rốt cuộc đã đi tới cấp nào. Hiện tại phần này chủ yếu dựa vào việc hiển thị của phần mềm nút và lớp ví; trải nghiệm tốt hay không còn phải xem việc triển khai thực tế.
$DUSK
#dusk @Dusk