Tôi chỉ đi tìm hiểu vì tôi đã cố gắng chuyển $DUSK qua cây cầu và cuối cùng lại đọc lịch sử sự cố.
Vào ngày 16 tháng 1 năm 2026, một kẻ tấn công đã truy cập được vào một ví ký được dùng bởi dịch vụ cầu của Dusk. @Dusk đã mô tả các hoạt động đáng ngờ liên quan đến một ví vận hành do nhóm quản lý, sau đó đã tắt và tái sử dụng các địa chỉ liên quan, tạm dừng cầu và phối hợp với Binance.
Họ cũng đã thêm một danh sách chặn người nhận vào Web Wallet để ngăn việc chuyển tiền tới các địa chỉ đã bị xâm nhập, liên quan đến lừa đảo hoặc bị trừng phạt.
Dusk cho biết đây không phải là sự cố đồng thuận hay một lỗ hổng khai thác ở cấp giao thức của DuskDS, và rằng tiền của người dùng không bị ảnh hưởng.
Tôi đọc thông tin đó theo hai cách.
Thứ nhất, phản hồi là một tín hiệu tích cực. Họ phát hiện hành vi bất thường, tắt đường đi rủi ro, công bố sự cố và sau đó công bố một bản phân tích chi tiết sau sự cố thay vì dừng ở "tiền an toàn."
Đối với một mạng ở giai đoạn sớm, điều đó rất quan trọng. Tốc độ ngăn chặn và mức độ rõ ràng trong công bố cũng là một phần của hồ sơ bảo mật.
Nhưng phần thứ hai thì khó bỏ qua hơn.
Cây cầu dựa vào một ví ký nằm trong một lộ trình vận hành do nhóm quản lý. Bài đăng sau sự cố của Dusk cho biết thiết kế ban đầu ưu tiên tốc độ và sự đơn giản, nhưng lại tập trung quá nhiều niềm tin vào một lộ trình duy nhất. Khi lộ trình ký đó bị xâm nhập, kẻ tấn công không cần phải bẻ gãy sự đồng thuận của Dusk.
Điều này lại có phần không khớp với định hướng "cầu gốc tin cậy không cần tin tưởng" của DuskDS ↔ DuskEVM. Một giao thức có thể phi tập trung, nhưng lớp hạ tầng phía trên nó vẫn có thể tồn tại các điểm nghẽn mang tính con người.
Về phía Dusk, họ đã làm đúng: cây cầu được thiết kế lại—việc ký được tách khỏi xử lý sự kiện, việc giải phóng quỹ được tách khỏi khâu nạp sự kiện, bề mặt phơi nhiễm của hot-wallet được giảm xuống, và dịch vụ được cô lập quyết liệt hơn.
Tài liệu hiện tại mô tả các luồng cầu giữa Dusk mainnet và BSC, nên việc gọi đợt tắt máy tháng 1 đó là "vẫn đã đóng" sẽ đã lỗi thời.
Vì vậy, câu hỏi thực sự là:
Tốc độ và mức độ chi tiết trong phản hồi của Dusk có xây dựng được thêm niềm tin, hay việc một lộ trình ký do một nhóm vận hành nắm giữ quá nhiều quyền lực vẫn là mối quan ngại lớn hơn?
#dusk $DUSK @Dusk
Vào ngày 16 tháng 1 năm 2026, một kẻ tấn công đã truy cập được vào một ví ký được dùng bởi dịch vụ cầu của Dusk. @Dusk đã mô tả các hoạt động đáng ngờ liên quan đến một ví vận hành do nhóm quản lý, sau đó đã tắt và tái sử dụng các địa chỉ liên quan, tạm dừng cầu và phối hợp với Binance.
Họ cũng đã thêm một danh sách chặn người nhận vào Web Wallet để ngăn việc chuyển tiền tới các địa chỉ đã bị xâm nhập, liên quan đến lừa đảo hoặc bị trừng phạt.
Dusk cho biết đây không phải là sự cố đồng thuận hay một lỗ hổng khai thác ở cấp giao thức của DuskDS, và rằng tiền của người dùng không bị ảnh hưởng.
Tôi đọc thông tin đó theo hai cách.
Thứ nhất, phản hồi là một tín hiệu tích cực. Họ phát hiện hành vi bất thường, tắt đường đi rủi ro, công bố sự cố và sau đó công bố một bản phân tích chi tiết sau sự cố thay vì dừng ở "tiền an toàn."
Đối với một mạng ở giai đoạn sớm, điều đó rất quan trọng. Tốc độ ngăn chặn và mức độ rõ ràng trong công bố cũng là một phần của hồ sơ bảo mật.
Nhưng phần thứ hai thì khó bỏ qua hơn.
Cây cầu dựa vào một ví ký nằm trong một lộ trình vận hành do nhóm quản lý. Bài đăng sau sự cố của Dusk cho biết thiết kế ban đầu ưu tiên tốc độ và sự đơn giản, nhưng lại tập trung quá nhiều niềm tin vào một lộ trình duy nhất. Khi lộ trình ký đó bị xâm nhập, kẻ tấn công không cần phải bẻ gãy sự đồng thuận của Dusk.
Điều này lại có phần không khớp với định hướng "cầu gốc tin cậy không cần tin tưởng" của DuskDS ↔ DuskEVM. Một giao thức có thể phi tập trung, nhưng lớp hạ tầng phía trên nó vẫn có thể tồn tại các điểm nghẽn mang tính con người.
Về phía Dusk, họ đã làm đúng: cây cầu được thiết kế lại—việc ký được tách khỏi xử lý sự kiện, việc giải phóng quỹ được tách khỏi khâu nạp sự kiện, bề mặt phơi nhiễm của hot-wallet được giảm xuống, và dịch vụ được cô lập quyết liệt hơn.
Tài liệu hiện tại mô tả các luồng cầu giữa Dusk mainnet và BSC, nên việc gọi đợt tắt máy tháng 1 đó là "vẫn đã đóng" sẽ đã lỗi thời.
Vì vậy, câu hỏi thực sự là:
Tốc độ và mức độ chi tiết trong phản hồi của Dusk có xây dựng được thêm niềm tin, hay việc một lộ trình ký do một nhóm vận hành nắm giữ quá nhiều quyền lực vẫn là mối quan ngại lớn hơn?
#dusk $DUSK @Dusk