Càng khám phá VaultKit của Newton Protocol, tôi càng nhận ra một thực tại khó chịu: điều gì xảy ra khi hệ thống được thiết kế để ủy quyền các hành động quan trọng trở nên không khả dụng?
Hầu hết các cuộc thảo luận về bảo mật tập trung vào việc ngăn chặn truy cập trái phép. Rất ít người xem xét cách một giao thức nên khôi phục khi lớp ủy quyền của chính nó không thể đưa ra quyết định.
VaultKit tiếp cận vấn đề này với một triết lý rõ ràng. Các thao tác của trình quản lý vault được bảo vệ được thiết kế để fail-closed. Nếu không thể truy cập Gateway, các nhà vận hành không đạt được quorum, việc đánh giá chính sách từ chối yêu cầu, việc xác thực delegate thất bại, hoặc không thể hoàn tất việc xác minh attestation, thì Shield đơn giản sẽ từ chối chuyển tiếp lệnh gọi quản trị đặc quyền.
Đó chính xác là cách một hệ thống bảo mật nên hoạt động trong điều kiện không chắc chắn. Khi không thể thiết lập được niềm tin, quyền được từ chối.
Nhưng hạ tầng trong thế giới thực lại nảy sinh một vấn đề khác.
Các vault đôi khi có thể cần quản trị khẩn cấp trong khi chính mạng ủy quyền lại không sẵn sàng. Việc để mọi hành động đặc quyền bị chặn vĩnh viễn có thể tạo ra rủi ro vận hành nghiêm trọng không kém gì việc cho phép thực thi trái phép.
Giải pháp của Newton thật sự khá thận trọng.
Thay vì trao cho chủ sở hữu một quyền ghi đè không bị giới hạn, VaultKit giới thiệu một cơ chế bypass khẩn cấp có timelock. Theo tài liệu chính thức, chủ sở hữu phải xếp hàng (queue) cơ chế bypass trước khi có thể thực thi. Mặc định thời gian chờ là một tuần, và SDK ngăn không cho cấu hình nó thấp hơn một ngày. Mọi lần sử dụng bypass cũng phát ra sự kiện onchain, đảm bảo hành động đó có thể quan sát công khai.
Thiết kế đó lập tức gây ấn tượng với tôi.
Giao thức thừa nhận rằng mọi hệ thống fail-closed cuối cùng đều cần một cơ chế khôi phục, nhưng cố tình không biến cơ chế đó trở thành tức thời. Thời gian chờ tạo ra khoảng thời gian để giám sát, rà soát và nâng cao nhận thức của cộng đồng trước khi có thể thực thi quyền lực đặc biệt.
Cảm giác như đây là một sự cân bằng có chủ ý.
Việc ghi đè tức thời sẽ làm giảm sức mạnh thực tiễn của việc thực thi chính sách mỗi khi chủ sở hữu muốn đi theo một hướng khác. Loại bỏ hoàn toàn khả năng khôi phục khẩn cấp có thể khiến quản trị vault quan trọng bị “đóng băng” trong các giai đoạn lỗi hạ tầng kéo dài.
Timelock nằm giữa hai thái cực đó.
Tuy nhiên, nó cũng thay đổi các giả định bảo mật.
Trong vận hành bình thường, các hành động của quản trị viên (privileged manager) sẽ tuân theo đầy đủ quy trình ủy quyền hoàn chỉnh của Newton. Một Intent chính xác được tạo ra, các operator đánh giá nó dựa trên chính sách đã cấu hình, các phê duyệt đạt ngưỡng (quorum), chứng thực (attestations) được tạo ra, và Shield sẽ xác minh các chứng thực đó trước khi chuyển tiếp giao dịch. Mỗi phê duyệt được ràng buộc mật mã với người ký dự định, hợp đồng, calldata, giá trị, chuỗi (chain) và hàm.
Bypass khẩn cấp hoạt động theo cách khác.
Thay vì dựa vào sự đồng thuận của các operator và các chứng thực chính sách, việc thực thi cuối cùng phụ thuộc vào quyền hạn của chủ sở hữu, độ trễ được cấu hình, và khả năng quan sát công khai thông qua các sự kiện được phát ra.
Những biện pháp bảo vệ đó là có giá trị.
Nhưng chúng không phải là cùng một loại biện pháp bảo vệ.
Cơ chế timelock xác định khi nào một hành động khẩn cấp có thể được thực thi. Nó không xác định vì sao hành động đó nên được thực thi.
Tương tự, các sự kiện quan sát được làm cho các hành động đặc biệt trở nên minh bạch, nhưng minh bạch không nên bị nhầm với việc được phê duyệt theo chính sách. Chủ sở hữu có thể kích hoạt bypass vì Gateway đã không sẵn sàng hoặc không thể đạt quorum của operator. Giao dịch kết quả vẫn có thể tiếp tục mà không cần hoàn tất quy trình chứng thực chính sách tiêu chuẩn của Newton.
Sự khác biệt đó quan trọng vì mô hình tin cậy đã thay đổi.
Thời gian trễ được cấu hình cũng trở thành một quyết định quản trị quan trọng, chứ không chỉ là một tham số triển khai đơn thuần.
Thời gian trễ ngắn hơn cho phép khôi phục nhanh hơn trong các tình huống khẩn cấp thực sự nhưng giảm thời gian dành cho giám sát. Thời gian trễ dài hơn sẽ tăng cơ hội để rà soát, đồng thời làm tăng khả năng can thiệp vận hành hợp pháp đến quá muộn.
Không có một giá trị nào cân bằng hoàn hảo cho mọi kịch bản hỏng hóc có thể xảy ra.
Kết luận thú vị nhất có lẽ là mô hình bảo mật của VaultKit không chỉ được xác định bởi ủy quyền tự động.
Nó được định nghĩa bởi hai cam kết bổ sung cho nhau.
Cam kết thứ nhất là hệ thống ủy quyền dựa trên chính sách của Newton: sự đồng thuận của các operator và các chứng thực mật mã quyết định liệu các hành động của quản trị viên đặc quyền có được phép hay không.
Cam kết thứ hai là cơ chế khôi phục do chủ sở hữu kiểm soát như đã được công bố: quyền lực bị giới hạn bởi thời gian thay vì bị thay thế bởi chính sách.
Không cam kết nào tồn tại một cách độc lập.
Hiểu VaultKit đòi hỏi phải hiểu cả hai khía cạnh.
Cũng cần nhớ phạm vi của các biện pháp bảo vệ này. VaultKit bảo vệ các hoạt động của privileged curator và manager như phân bổ lại (reallocations), cập nhật cap (cap updates) và các hành động quản trị tương tự. Các khoản nạp và rút tiền tiêu chuẩn của người dùng vẫn tiếp tục thông qua giao thức vault bên dưới, trừ khi một tích hợp (integration) cho rõ ràng là định tuyến các thao tác đó qua Shield.
Cuối cùng, cơ chế bỏ qua theo timelock không làm suy yếu ý tưởng ủy quyền dựa trên chính sách.
Thay vào đó, nó thừa nhận một sự thật thực tiễn: hạ tầng bền vững phải lên kế hoạch không chỉ cho các thời điểm ủy quyền thành công, mà cả cho những khoảnh khắc hiếm hoi khi chính việc ủy quyền trở nên không khả dụng.
Câu hỏi thực sự là liệu người dùng có đánh giá độc lập hai giả định tin cậy đó hay không — hoặc chỉ đơn giản giả định rằng mọi thao tác của vault được bảo vệ luôn dựa trên cùng các cam kết bảo mật.
Newton’s timelocked emergency bypass có cung cấp khả năng phục hồi vận hành mà quản trị vault phi tập trung cần hay không, hay nó trở thành giả định tin cậy chính khi đường ủy quyền thông thường không sẵn sàng?
#Newt @NewtonProtocol l $NEWT $VANRY $TLM
