#dusk $DUSK @Dusk mình đã qua lại với một vài điều liên quan đến dusk và nghĩ rằng cuối cùng mình cũng tìm ra đúng hình dạng của nó.
mình đã xem danh sách provisioner từ một thời gian trước — mười lăm địa chỉ đầu tiên nắm giữ chỉ dưới một nửa tổng số phần được khóa/bonded, không có dấu gạch chéo (zero slashes) nào trong số đó, và người tham gia sớm nhất đã hoạt động hơn một năm trong khi người tham gia mới nhất đã chín/mature cách đây vài ngày. tất cả những điều đó được lưu ở đó, theo từng địa chỉ, được tính lại lại hoàn toàn mỗi khối (mỗi block). đó là sự chặt chẽ thực sự. không ai cần phải tin vào một lời khẳng định về việc ai giữ chuỗi này, họ chỉ cần nhìn.
rồi sự kiện liên quan đến cầu đã xảy ra. ví bị cảnh báo, tiền được chuyển đi, đội tạm dừng mọi thứ và triển khai một bản fix — nhưng bản fix đó lại không nằm trên đúng lớp có thể kiểm chứng (provable layer) tương tự. nó là một danh sách block người nhận (recipient blocklist) nằm ở phần giao diện ví web (web wallet frontend). nếu bạn chạy công cụ tự viết của mình hoặc dùng CLI, bạn sẽ không thừa hưởng bất kỳ lớp bảo vệ nào như vậy. tất cả điều đó không đụng tới phần của stack mà thực sự mở để có thể kiểm tra/quan sát.
vì vậy đây là điều làm mình băn khoăn: phần của dusk vốn chịu trách nhiệm một cách chặt chẽ và có thể đối chiếu được (ai giữ stake, trong bao lâu, có hình phạt gì) lại không phải là phần cần phản hồi khi sự cố thật sự xảy ra. phần đã phản hồi thì nằm ở đâu đó mà không ai có thể audit (kiểm toán/đối soát) theo cách tương tự.
mình không nói rằng đó nhất thiết là một đánh đổi xấu — giao hàng nhanh có lẽ quan trọng hơn về mặt thời điểm trong tuần đó so với sự trong sạch thuần kiến trúc. nhưng nếu một tổ chức đang đánh giá dusk theo "hệ thống này chứng minh được ở mức nào", họ có thể đang chấm một lớp khác với lớp sẽ thực sự bắt được sự cố tiếp theo.
vậy bạn muốn audit lớp nào trước — lớp đang nắm giữ stake, hay lớp quyết định ai được phép chuyển tiền?
mình đã xem danh sách provisioner từ một thời gian trước — mười lăm địa chỉ đầu tiên nắm giữ chỉ dưới một nửa tổng số phần được khóa/bonded, không có dấu gạch chéo (zero slashes) nào trong số đó, và người tham gia sớm nhất đã hoạt động hơn một năm trong khi người tham gia mới nhất đã chín/mature cách đây vài ngày. tất cả những điều đó được lưu ở đó, theo từng địa chỉ, được tính lại lại hoàn toàn mỗi khối (mỗi block). đó là sự chặt chẽ thực sự. không ai cần phải tin vào một lời khẳng định về việc ai giữ chuỗi này, họ chỉ cần nhìn.
rồi sự kiện liên quan đến cầu đã xảy ra. ví bị cảnh báo, tiền được chuyển đi, đội tạm dừng mọi thứ và triển khai một bản fix — nhưng bản fix đó lại không nằm trên đúng lớp có thể kiểm chứng (provable layer) tương tự. nó là một danh sách block người nhận (recipient blocklist) nằm ở phần giao diện ví web (web wallet frontend). nếu bạn chạy công cụ tự viết của mình hoặc dùng CLI, bạn sẽ không thừa hưởng bất kỳ lớp bảo vệ nào như vậy. tất cả điều đó không đụng tới phần của stack mà thực sự mở để có thể kiểm tra/quan sát.
vì vậy đây là điều làm mình băn khoăn: phần của dusk vốn chịu trách nhiệm một cách chặt chẽ và có thể đối chiếu được (ai giữ stake, trong bao lâu, có hình phạt gì) lại không phải là phần cần phản hồi khi sự cố thật sự xảy ra. phần đã phản hồi thì nằm ở đâu đó mà không ai có thể audit (kiểm toán/đối soát) theo cách tương tự.
mình không nói rằng đó nhất thiết là một đánh đổi xấu — giao hàng nhanh có lẽ quan trọng hơn về mặt thời điểm trong tuần đó so với sự trong sạch thuần kiến trúc. nhưng nếu một tổ chức đang đánh giá dusk theo "hệ thống này chứng minh được ở mức nào", họ có thể đang chấm một lớp khác với lớp sẽ thực sự bắt được sự cố tiếp theo.
vậy bạn muốn audit lớp nào trước — lớp đang nắm giữ stake, hay lớp quyết định ai được phép chuyển tiền?
