@Dusk_Foundation #dusk $DUSK
Trước đây tôi từng nghĩ rằng nếu một dự án có thiết kế mật mã chặt chẽ, thì điều đó tự động khiến nó an toàn hơn. Hóa ra không, cho dù toán học được xây dựng chặt đến đâu, điểm yếu nhất gần như luôn là cùng một thứ: yếu tố con người.
Khi đội @Dusk phát hiện hoạt động bất thường vào tháng 1, liên quan đến một ví được dùng cho các hoạt động bridge, mọi chuyện lại đúng như vậy. Không phải lỗi trong chính giao thức. Không phải các bằng chứng ZK hay việc các giao dịch được che chắn bị phá vỡ. Chỉ là một ví vận hành phải gánh quá nhiều trách nhiệm.
Họ đã tạm dừng bridge ngay lập tức. Khi một phần của luồng chạm tới Binance, hai đội đã phối hợp trực tiếp để khống chế, và không có quỹ người dùng nào bị ảnh hưởng.
Thứ tôi thực sự quan tâm là điều xảy ra sau đó...
Vì nước đi dễ dàng ở đây là vá đúng một thứ bị tấn công và gọi đó là đã xong. @Dusk đã không làm vậy. Họ đã xây dựng lại toàn bộ thiết kế bridge.
Họ tách riêng các thành phần, tách việc ký khỏi việc xử lý sự kiện, làm rõ luồng giao dịch theo từng bước cụ thể, và giảm mức độ phơi nhiễm mà bất kỳ một hot wallet riêng lẻ nào phải gánh. Còn ví web cũng được bổ sung một blocklist để gắn cờ các địa chỉ xấu đã biết trước khi bạn gửi tới chúng.
Đó mới là phần thực sự quan trọng với tôi. Mật mã có thể hoàn hảo, nhưng lớp vận hành xung quanh nó vẫn có thể là mắt xích yếu. Đó là cách những hệ thống này vận hành.
Vấn đề sẽ xảy ra trong crypto. Vì vậy chúng tôi nhấn mạnh việc stress test dự án, chạy testnet trước khi đưa lên mainnet, và dùng hackathon nơi mọi người chủ động tìm cách phá vỡ. Đó là cách các nhà xây dựng tìm ra điểm yếu và học hỏi từ chúng.
Vậy câu hỏi không phải là liệu một vấn đề có bao giờ xảy ra hay không. Mà là điều gì xảy ra khi nó xảy ra. Bạn chỉ dán một miếng băng tạm thời lên nó 🩹, hay thực hiện trọn ca phẫu thuật 🧑⚕️ và sửa tận gốc thiết kế?
@Dusk_Foundation đã chọn xử lý vấn đề thiết kế. #dusk $SPCX $METAB #DUSKARMY.
Trước đây tôi từng nghĩ rằng nếu một dự án có thiết kế mật mã chặt chẽ, thì điều đó tự động khiến nó an toàn hơn. Hóa ra không, cho dù toán học được xây dựng chặt đến đâu, điểm yếu nhất gần như luôn là cùng một thứ: yếu tố con người.
Khi đội @Dusk phát hiện hoạt động bất thường vào tháng 1, liên quan đến một ví được dùng cho các hoạt động bridge, mọi chuyện lại đúng như vậy. Không phải lỗi trong chính giao thức. Không phải các bằng chứng ZK hay việc các giao dịch được che chắn bị phá vỡ. Chỉ là một ví vận hành phải gánh quá nhiều trách nhiệm.
Họ đã tạm dừng bridge ngay lập tức. Khi một phần của luồng chạm tới Binance, hai đội đã phối hợp trực tiếp để khống chế, và không có quỹ người dùng nào bị ảnh hưởng.
Thứ tôi thực sự quan tâm là điều xảy ra sau đó...
Vì nước đi dễ dàng ở đây là vá đúng một thứ bị tấn công và gọi đó là đã xong. @Dusk đã không làm vậy. Họ đã xây dựng lại toàn bộ thiết kế bridge.
Họ tách riêng các thành phần, tách việc ký khỏi việc xử lý sự kiện, làm rõ luồng giao dịch theo từng bước cụ thể, và giảm mức độ phơi nhiễm mà bất kỳ một hot wallet riêng lẻ nào phải gánh. Còn ví web cũng được bổ sung một blocklist để gắn cờ các địa chỉ xấu đã biết trước khi bạn gửi tới chúng.
Đó mới là phần thực sự quan trọng với tôi. Mật mã có thể hoàn hảo, nhưng lớp vận hành xung quanh nó vẫn có thể là mắt xích yếu. Đó là cách những hệ thống này vận hành.
Vấn đề sẽ xảy ra trong crypto. Vì vậy chúng tôi nhấn mạnh việc stress test dự án, chạy testnet trước khi đưa lên mainnet, và dùng hackathon nơi mọi người chủ động tìm cách phá vỡ. Đó là cách các nhà xây dựng tìm ra điểm yếu và học hỏi từ chúng.
Vậy câu hỏi không phải là liệu một vấn đề có bao giờ xảy ra hay không. Mà là điều gì xảy ra khi nó xảy ra. Bạn chỉ dán một miếng băng tạm thời lên nó 🩹, hay thực hiện trọn ca phẫu thuật 🧑⚕️ và sửa tận gốc thiết kế?
@Dusk_Foundation đã chọn xử lý vấn đề thiết kế. #dusk $SPCX $METAB #DUSKARMY.