#dusk $DUSK Tôi hiện đang xem xét vấn đề an toàn của @Dusk , và cố tình tách bạch “an toàn giao thức” với “an toàn hệ sinh thái”. Trước hết, “an toàn giao thức” bao gồm cơ chế đồng thuận, hiện thực mật mã, hợp đồng thông minh và ranh giới của máy ảo; còn “an toàn hệ sinh thái” thì bao gồm ví, giao diện người dùng, dịch vụ cầu nối, quản lý khóa, vận hành node và tích hợp bên thứ ba. Nhiều dự án sau khi xảy ra sự cố thường thích nhấn mạnh rằng “chuỗi lõi không có vấn đề”. Câu này đôi khi là đúng, nhưng với những người nắm giữ $DUSK và sử dụng các sản phẩm hệ sinh thái, tài sản có an toàn hay không sẽ không tự động được khôi phục chỉ vì ranh giới trách nhiệm được phân chia thật rõ ràng.$SPCXB
Mạng lưới như Dusk—định hướng các kịch bản tài chính vì quyền riêng tư—thực ra đòi hỏi yêu cầu an toàn cao hơn. Bởi vì người dùng và tổ chức sẵn sàng sử dụng khả năng quyền riêng tư không chỉ cần tin rằng thuật toán hoạt động đáng tin cậy, mà còn phải tin rằng các điểm truy cập, dịch vụ và quy trình vận hành được kiểm soát đủ chặt chẽ. Chỉ một sơ suất trong quản lý khóa ký, một trang ủy quyền bị thay thế, hoặc một lần trễ trong giám sát cầu nối cũng có thể vượt qua thiết kế chặt chẽ của giao thức nền tảng. Vị trí mỏng manh nhất của hệ thống kỹ thuật thường không nằm ở phần mật mã phức tạp nhất, mà nằm ở những phần “mặc định tin cậy” khi các thành phần bàn giao cho nhau.$SNDKB
Tôi thừa nhận ý nghĩa của việc công khai rà soát lại và tiếp tục sửa chữa, nhưng tôi còn muốn xem sau khi rà soát thì có hình thành các cải tiến có thể được xác minh hay không. Ví dụ: liệu các quyền truy cập then chốt có được tách hoàn toàn hay chưa; liệu các thao tác nhạy cảm có cần được xác nhận nhiều lớp hay không; mức phơi bày rủi ro đối với ví nóng hoặc tài khoản dịch vụ có giới hạn rõ ràng hay không; giao dịch bất thường có thể được phát hiện kịp thời hay không; và người dùng có thể biết dịch vụ đang ở trạng thái gì hay không. Đối với hệ sinh thái DUSK, thông báo an toàn không nên chỉ là phần giải thích sau khi sự cố xảy ra, mà phải trở thành tài liệu để người dùng đánh giá mức độ trưởng thành trong quản lý rủi ro.
Vì thế, tôi không nghĩ một vấn đề đơn lẻ là đủ để phủ định hướng phát triển kỹ thuật của Dusk, nhưng tôi cũng sẽ không xem “đã được sửa” như điểm kết thúc của cuộc thảo luận. Điều thực sự đáng theo dõi là việc bản sửa có bao phủ các tuyến đường tương tự hay không; việc đánh giá bên ngoài có được duy trì liên tục hay không; cảnh báo rủi ro có đủ minh bạch hay không; và trong áp lực, đội ngũ có thể nhanh chóng cung cấp thông tin có thể kiểm chứng hay không. Tài chính vì quyền riêng tư cần sự tin tưởng, nhưng sự tin tưởng không thể chỉ dựa trên khẩu hiệu. Nếu Dusk muốn tiếp nhận các tài sản và người dùng phức tạp hơn, thì mỗi lớp dịch vụ phải chịu được những câu hỏi truy vấn nghiêm ngặt tương tự: khi có bất thường, ai là người phát hiện, ai là người có thể hạn chế, ai là người có thể giải thích, và ai là người chịu trách nhiệm.
#dusk @Dusk
Mạng lưới như Dusk—định hướng các kịch bản tài chính vì quyền riêng tư—thực ra đòi hỏi yêu cầu an toàn cao hơn. Bởi vì người dùng và tổ chức sẵn sàng sử dụng khả năng quyền riêng tư không chỉ cần tin rằng thuật toán hoạt động đáng tin cậy, mà còn phải tin rằng các điểm truy cập, dịch vụ và quy trình vận hành được kiểm soát đủ chặt chẽ. Chỉ một sơ suất trong quản lý khóa ký, một trang ủy quyền bị thay thế, hoặc một lần trễ trong giám sát cầu nối cũng có thể vượt qua thiết kế chặt chẽ của giao thức nền tảng. Vị trí mỏng manh nhất của hệ thống kỹ thuật thường không nằm ở phần mật mã phức tạp nhất, mà nằm ở những phần “mặc định tin cậy” khi các thành phần bàn giao cho nhau.$SNDKB
Tôi thừa nhận ý nghĩa của việc công khai rà soát lại và tiếp tục sửa chữa, nhưng tôi còn muốn xem sau khi rà soát thì có hình thành các cải tiến có thể được xác minh hay không. Ví dụ: liệu các quyền truy cập then chốt có được tách hoàn toàn hay chưa; liệu các thao tác nhạy cảm có cần được xác nhận nhiều lớp hay không; mức phơi bày rủi ro đối với ví nóng hoặc tài khoản dịch vụ có giới hạn rõ ràng hay không; giao dịch bất thường có thể được phát hiện kịp thời hay không; và người dùng có thể biết dịch vụ đang ở trạng thái gì hay không. Đối với hệ sinh thái DUSK, thông báo an toàn không nên chỉ là phần giải thích sau khi sự cố xảy ra, mà phải trở thành tài liệu để người dùng đánh giá mức độ trưởng thành trong quản lý rủi ro.
Vì thế, tôi không nghĩ một vấn đề đơn lẻ là đủ để phủ định hướng phát triển kỹ thuật của Dusk, nhưng tôi cũng sẽ không xem “đã được sửa” như điểm kết thúc của cuộc thảo luận. Điều thực sự đáng theo dõi là việc bản sửa có bao phủ các tuyến đường tương tự hay không; việc đánh giá bên ngoài có được duy trì liên tục hay không; cảnh báo rủi ro có đủ minh bạch hay không; và trong áp lực, đội ngũ có thể nhanh chóng cung cấp thông tin có thể kiểm chứng hay không. Tài chính vì quyền riêng tư cần sự tin tưởng, nhưng sự tin tưởng không thể chỉ dựa trên khẩu hiệu. Nếu Dusk muốn tiếp nhận các tài sản và người dùng phức tạp hơn, thì mỗi lớp dịch vụ phải chịu được những câu hỏi truy vấn nghiêm ngặt tương tự: khi có bất thường, ai là người phát hiện, ai là người có thể hạn chế, ai là người có thể giải thích, và ai là người chịu trách nhiệm.
#dusk @Dusk
安全最弱环节在哪
67%
桥接风险该如何控制
0%
复盘报告够透明吗
33%
3 phiếu bầu • Cuộc bỏ phiếu đã kết thúc