Chặn lối tấn công và loại bỏ các giả định sai là hai việc khác nhau
AEGIS tự nhấn mạnh một sự phân biệt rất thẳng thắn: việc các đường tấn công trọng yếu bị chặn không có nghĩa là nguyên nhân gốc đã được tái cấu trúc hoàn toàn. Chuỗi chi phí của Phoenix có thể được ngăn chặn sự phình to, dừng chuỗi và đánh cắp tiền hoàn bằng cách kiểm tra tính nhất quán và ràng buộc trường; còn việc sắp xếp thiết kế sâu hơn vẫn là một hạng mục công việc khác. Trạng thái an toàn vì vậy không phải là đơn giản “có lỗ/không có lỗ”.
Tôi nghĩ những cách diễn đạt như vậy phù hợp hơn với hạ tầng tài chính so với một câu “vấn đề đã được giải quyết”. Mục tiêu của giảm thiểu khẩn cấp là nhanh chóng giảm rủi ro thực tế; còn việc sửa nguyên nhân gốc là phải loại bỏ các giả định sai được chia sẻ giữa nhiều module. Hai việc này khác nhau về thời gian, cách xác minh và chi phí di chuyển. Trộn chúng lại thành một dấu “hoàn thành” sẽ khiến thị trường mất đi căn cứ để đánh giá rủi ro còn tồn tại.
Khuyến nghị công bố tốt nên giải thích riêng: việc khai thác hiện tại có còn khả thi hay không, những đoạn mã nào vẫn phụ thuộc cấu trúc cũ, cách xác minh quá trình tái cấu trúc tiếp theo, và liệu ngữ nghĩa các giao dịch lịch sử có bị ảnh hưởng hay không. Như vậy người dùng sẽ không hoảng sợ vì thuật ngữ kỹ thuật, đồng thời cũng sẽ không bị dỗ yên bằng những khẩu hiệu an toàn quá đơn giản.
Tôi thấy tiến độ an toàn của @Dusk sẽ ghi riêng “exploit closure” và “root-cause closure”. $DUSK , #dusk , đáng tin không phải là việc không bao giờ thừa nhận nợ kỹ thuật, mà là mỗi lớp nợ đều có tên, có trạng thái và có điều kiện để kết thúc.
AEGIS tự nhấn mạnh một sự phân biệt rất thẳng thắn: việc các đường tấn công trọng yếu bị chặn không có nghĩa là nguyên nhân gốc đã được tái cấu trúc hoàn toàn. Chuỗi chi phí của Phoenix có thể được ngăn chặn sự phình to, dừng chuỗi và đánh cắp tiền hoàn bằng cách kiểm tra tính nhất quán và ràng buộc trường; còn việc sắp xếp thiết kế sâu hơn vẫn là một hạng mục công việc khác. Trạng thái an toàn vì vậy không phải là đơn giản “có lỗ/không có lỗ”.
Tôi nghĩ những cách diễn đạt như vậy phù hợp hơn với hạ tầng tài chính so với một câu “vấn đề đã được giải quyết”. Mục tiêu của giảm thiểu khẩn cấp là nhanh chóng giảm rủi ro thực tế; còn việc sửa nguyên nhân gốc là phải loại bỏ các giả định sai được chia sẻ giữa nhiều module. Hai việc này khác nhau về thời gian, cách xác minh và chi phí di chuyển. Trộn chúng lại thành một dấu “hoàn thành” sẽ khiến thị trường mất đi căn cứ để đánh giá rủi ro còn tồn tại.
Khuyến nghị công bố tốt nên giải thích riêng: việc khai thác hiện tại có còn khả thi hay không, những đoạn mã nào vẫn phụ thuộc cấu trúc cũ, cách xác minh quá trình tái cấu trúc tiếp theo, và liệu ngữ nghĩa các giao dịch lịch sử có bị ảnh hưởng hay không. Như vậy người dùng sẽ không hoảng sợ vì thuật ngữ kỹ thuật, đồng thời cũng sẽ không bị dỗ yên bằng những khẩu hiệu an toàn quá đơn giản.
Tôi thấy tiến độ an toàn của @Dusk sẽ ghi riêng “exploit closure” và “root-cause closure”. $DUSK , #dusk , đáng tin không phải là việc không bao giờ thừa nhận nợ kỹ thuật, mà là mỗi lớp nợ đều có tên, có trạng thái và có điều kiện để kết thúc.