Ban đầu tôi nghĩ rằng @NewtonProtocol chủ yếu là về sự tuân thủ có thể lập trình. Sau khi dành thêm thời gian để tìm hiểu kiến trúc, tôi nhận ra mình ít chú ý hơn đến từng chính sách riêng lẻ và nhiều hơn đến việc các chính sách đó thực sự nằm ở đâu. Sự thay đổi này đã làm cách tôi nhìn nhận giao thức thay đổi.

Thiết kế tách việc ủy quyền khỏi việc thực thi ứng dụng thay vì nhúng các quy tắc nghiệp vụ trực tiếp vào từng hợp đồng thông minh. Các chính sách viết bằng Rego định nghĩa logic ủy quyền, trong khi từng ứng dụng riêng lẻ cung cấp các ràng buộc vận hành của riêng họ thông qua cấu hình PolicyClient. Các giới hạn chi tiêu, người nhận được phê duyệt, các hạn chế theo thẩm quyền pháp lý và các yêu cầu tương tự trở thành cấu hình runtime có cấu trúc thay vì được mã hóa vĩnh viễn trong logic chính sách.

Sự phân biệt đó có vẻ quan trọng hơn so với những gì thoạt đầu tưởng. Một chính sách có thể vẫn được tái sử dụng trong khi các ứng dụng khác nhau hoạt động trong các ranh giới ủy quyền khác nhau chỉ bằng cách thay đổi cấu hình. Chính sách mô tả quy trình ra quyết định. Ứng dụng cung cấp bối cảnh. Những trách nhiệm đó được chủ ý tách biệt.

Nhưng có một điều gì đó cứ làm tôi băn khoăn.

Khả năng tái sử dụng chỉ hoạt động nếu việc ủy quyền vẫn gắn với đúng các giả định đã tạo ra nó. Newton giải quyết điều này bằng cách tạo ra một mã định danh chính sách mới mỗi khi cấu hình của PolicyClient thay đổi. Các bản chứng thực được tạo ra theo cấu hình trước đó sẽ không còn được áp dụng khi mã định danh chính sách được tham chiếu thay đổi. Do đó, việc ủy quyền không chỉ gắn với logic chính sách mà còn gắn với cấu hình chính xác tồn tại tại thời điểm phê duyệt được tạo ra.

Thiết kế thay đổi ranh giới.

Thay vì sửa đổi mã ứng dụng mỗi khi yêu cầu vận hành thay đổi, nhà phát triển điều chỉnh chính sách hoặc cấu hình trong khi vẫn giữ nguyên logic ứng dụng. Điều này có thể đơn giản hóa việc bảo trì giữa nhiều ứng dụng, nhưng đồng thời nó chuyển trách nhiệm sang việc quản lý chính sách. Bản thân cấu hình trở thành một phần của mô hình bảo mật thay vì chỉ là chi tiết triển khai.Thông tin bên ngoài đưa thêm một lớp trách nhiệm nữa. PolicyData Oracles thực thi dưới dạng các thành phần WASM tách biệt, trả về dữ liệu runtime có cấu trúc mà các chính sách đánh giá một cách quyết định (deterministically). Runtime cố ý giới hạn truy cập mạng, và các lỗi được xử lý khác nhau tùy theo nơi chúng xảy ra. Các lỗi ứng dụng có cấu trúc vẫn hiển thị cho quá trình đánh giá chính sách, trong khi lỗi thực thi trở thành các sự kiện DataProviderError khiến ủy quyền bị dừng hoàn toàn thay vì tạo ra một quyết định bình thường.

Nó không loại bỏ sự tin cậy. Nó chỉ chuyển vị trí của sự tin cậy.

Hết hạn bản chứng thực đưa thêm một quyết định vận hành nữa. Các cửa sổ phê duyệt ngắn làm giảm cơ hội phát lại, trong khi các cửa sổ dài cho người dùng nhiều linh hoạt hơn trước khi thực thi. Không lựa chọn nào trong số đó là các cửa sổ hết hạn cân bằng giữa khả năng chống phát lại và tính dễ dùng. Cuối cùng, người dùng tương tác với các bản chứng thực mà tính hợp lệ của chúng phản ánh cả phiên bản chính sách lẫn bối cảnh thực thi, chứ không chỉ trạng thái của hợp đồng.

Xét theo cách này, Newton dường như ít tập trung hơn vào việc thay thế logic của hợp đồng thông minh, và nhiều hơn vào việc chuyển vị trí nơi việc ủy quyền phát triển theo các thay đổi về yêu cầu ứng dụng.

Việc chuyển tiến hóa chính sách ra khỏi các hợp đồng đã triển khai có làm đơn giản hơn an ninh lâu dài hay chỉ tạo ra một lớp khác nơi độ phức tạp vận hành tích tụ?

$NEWT #Newt $SUI $ETH