#newt $NEWT @NewtonProtocol #Newt
tôi từng nghĩ rằng các chính sách giao thức chủ yếu là những “sổ tay luật” tĩnh. Cập nhật chúng một lần, kiểm toán một lần, và coi như xong. Càng đọc về Newton Protocol, tôi càng nhận ra giả định đó còn xa mới đúng.
Điểm khiến tôi chú ý là Newton Protocol tách logic chính sách Rego có thể tái sử dụng khỏi cấu hình động gắn với một PolicyClient. Thay vì viết lại mã chính sách cho từng trường hợp sử dụng, cùng một logic có thể được tái sử dụng trong khi các tham số như ngưỡng (thresholds), giới hạn phơi nhiễm (exposure limits) và danh sách cho phép (allowlists) đã được phê duyệt được truyền qua data.params dưới dạng JSON phẳng.
Điều này gợi cho tôi một ví dụ đơn giản từ đời thực. Gia đình tôi dùng chung bộ quy tắc cho mọi người, nhưng em họ tôi có những giới hạn khác với tôi ở cùng độ tuổi. Các quy tắc không thay đổi. Cấu hình đã thay đổi. Nguyên tắc giữ nguyên, còn các “ranh giới” thì được điều chỉnh.
Newton cũng theo triết lý tương tự, nhưng với những cam kết mạnh mẽ hơn nhiều. Một chi tiết tôi thấy đặc biệt thú vị là expireAfter. Nó xác định “cửa sổ” thực thi cho một bản chứng thực (attestation), chứ không phải thời điểm bản thân các tham số hết hạn. Đặt quá ngắn thì các lần thực thi hợp lệ có thể thất bại vì cửa sổ đóng quá sớm. Đặt quá dài thì rủi ro cho việc phát lại (replay) hoặc thực thi trễ sẽ tăng lên. Không có lựa chọn nào tự động là đúng. Tùy ngữ cảnh.
Một lựa chọn thiết kế tinh tế khác là việc cập nhật tham số thông qua setPolicy(PolicyConfig) sẽ tạo ra một policyId hoàn toàn mới. Cấu hình trước đó lập tức trở nên lỗi thời, tạo ra một ranh giới rõ ràng giữa trạng thái chính sách cũ và mới thay vì âm thầm làm biến đổi các giả định về độ tin cậy.
Bài học lớn nhất của tôi không phải là sự linh hoạt. Mà là trách nhiệm. Rego định nghĩa logic, nhưng con người định nghĩa các tham số, rà soát chúng, và cuối cùng quyết định kết quả.
Vậy các nhà rà soát nên dành phần lớn sự tập trung vào đâu: mã chính sách có thể tái sử dụng, hay các cài đặt bị ẩn bên trong data.params? Kiến trúc này có giúp các quy tắc được tái sử dụng một cách an toàn không, hay nó chuyển những giả định tin cậy quan trọng nhất vào các cấu hình mà nhiều người sẽ không kiểm tra?
tôi từng nghĩ rằng các chính sách giao thức chủ yếu là những “sổ tay luật” tĩnh. Cập nhật chúng một lần, kiểm toán một lần, và coi như xong. Càng đọc về Newton Protocol, tôi càng nhận ra giả định đó còn xa mới đúng.
Điểm khiến tôi chú ý là Newton Protocol tách logic chính sách Rego có thể tái sử dụng khỏi cấu hình động gắn với một PolicyClient. Thay vì viết lại mã chính sách cho từng trường hợp sử dụng, cùng một logic có thể được tái sử dụng trong khi các tham số như ngưỡng (thresholds), giới hạn phơi nhiễm (exposure limits) và danh sách cho phép (allowlists) đã được phê duyệt được truyền qua data.params dưới dạng JSON phẳng.
Điều này gợi cho tôi một ví dụ đơn giản từ đời thực. Gia đình tôi dùng chung bộ quy tắc cho mọi người, nhưng em họ tôi có những giới hạn khác với tôi ở cùng độ tuổi. Các quy tắc không thay đổi. Cấu hình đã thay đổi. Nguyên tắc giữ nguyên, còn các “ranh giới” thì được điều chỉnh.
Newton cũng theo triết lý tương tự, nhưng với những cam kết mạnh mẽ hơn nhiều. Một chi tiết tôi thấy đặc biệt thú vị là expireAfter. Nó xác định “cửa sổ” thực thi cho một bản chứng thực (attestation), chứ không phải thời điểm bản thân các tham số hết hạn. Đặt quá ngắn thì các lần thực thi hợp lệ có thể thất bại vì cửa sổ đóng quá sớm. Đặt quá dài thì rủi ro cho việc phát lại (replay) hoặc thực thi trễ sẽ tăng lên. Không có lựa chọn nào tự động là đúng. Tùy ngữ cảnh.
Một lựa chọn thiết kế tinh tế khác là việc cập nhật tham số thông qua setPolicy(PolicyConfig) sẽ tạo ra một policyId hoàn toàn mới. Cấu hình trước đó lập tức trở nên lỗi thời, tạo ra một ranh giới rõ ràng giữa trạng thái chính sách cũ và mới thay vì âm thầm làm biến đổi các giả định về độ tin cậy.
Bài học lớn nhất của tôi không phải là sự linh hoạt. Mà là trách nhiệm. Rego định nghĩa logic, nhưng con người định nghĩa các tham số, rà soát chúng, và cuối cùng quyết định kết quả.
Vậy các nhà rà soát nên dành phần lớn sự tập trung vào đâu: mã chính sách có thể tái sử dụng, hay các cài đặt bị ẩn bên trong data.params? Kiến trúc này có giúp các quy tắc được tái sử dụng một cách an toàn không, hay nó chuyển những giả định tin cậy quan trọng nhất vào các cấu hình mà nhiều người sẽ không kiểm tra?