Kể từ khi tôi thấy có 8,91 triệu DUSK chuyển khoản bị fail sau 15m55s kể từ thời điểm tắt máy, tôi không còn xem đoạn dừng cầu của Dusk chỉ là một câu chuyện “ngừng hoạt động” đơn thuần nữa, trong khi DuskDS vẫn tiếp tục tạo ra các block.

Chỉ số dễ nhất là không có downtime của giao thức. Hữu ích, nhưng chưa đầy đủ. Bốn giao dịch đánh cắp đã lấy đi 10,91 triệu DUSK, nhưng chỉ có 1,919 triệu, tương đương 17,6%, thành công chuyển qua BSC. Cầu ngắt mạch giới hạn phần “thoát ra”, chứ không phải là sự cố làm lộ ví ban đầu.

Sự tách bạch đó quan trọng. DuskDS vẫn có thể đối soát các giao dịch gốc (native) trong khi các tuyến thanh khoản bên ngoài bị đóng. Tính sẵn sàng của lớp nền (base-layer) và tính sẵn sàng của hệ sinh thái không phải là cùng một thứ. Nếu ví, RPC, trình khám phá (explorer), hoặc mọi cây cầu lớn đều không hoạt động, liệu DUSK có “hoạt động” đối với người dùng hay chỉ “còn sống” đối với các validator?

Tôi muốn Dusk công bố năm đồng hồ riêng cho thời gian uptime của: chuỗi (chain), RPC, explorer, ví (wallet) và cầu (bridge), kèm số block được tạo, finality trung vị (median finality), thông lượng (throughput), số tài khoản mới và mức độ hoạt động native so với hoạt động phụ thuộc vào cầu trong thời gian dừng. Nếu không có các chuỗi dữ liệu đó, việc “không bị ảnh hưởng” chỉ nói lên sự đồng thuận (consensus) không sụp đổ, chứ không nói lên nhu cầu (demand).

Không mất tiền người dùng và không có lỗi giao thức là điều đáng nói. Tuy nhiên bài kiểm tra khó hơn là: hành vi người dùng liệu có giữ vững khi dòng tiền vào bị ngắt, và chi phí cơ hội tích lũy được bao nhiêu cho mỗi ngày ngoại tuyến?

Sự cố cho thấy chuỗi có thể sống sót qua “cổng” (gateway). Nó chưa cho thấy hệ sinh thái có thể bỏ qua sự cố đó.

#dusk $DUSK @Dusk