Khi tôi bắt đầu tìm hiểu về ủy quyền có thể lập trình, tôi đã cho rằng việc thay đổi một quy tắc đồng nghĩa với việc thay đổi hợp đồng thông minh thực thi nó. Điều đó dường như là không thể tránh khỏi.
Nếu một kho tiền hạ thấp mức phơi nhiễm tối đa của mình, thêm một địa chỉ bị hạn chế, thay đổi điểm rủi ro chấp nhận được hoặc đưa ra một điều kiện tuân thủ mới, chắc chắn hợp đồng bảo vệ kho tiền đó sẽ cần được viết lại và triển khai lại.
Càng tìm hiểu về @NewtonProtocolMainnet Beta, tôi càng thấy giả định đó bắt đầu có vẻ ngược lại. Newton tách ứng dụng đang được bảo vệ khỏi chính sách quyết định ứng dụng đó được phép làm gì.
Một chính sách của Newton đánh giá ý định giao dịch như thế nào
Một chính sách của Newton đánh giá ý định giao dịch bằng ba loại thông tin khác nhau:
Bản thân giao dịch
Các giá trị có thể cấu hình dưới "data.params
Thông tin thời gian thực được các oracle dữ liệu trả về dưới "data.wasm"
Do đó, chính sách có thể so sánh cùng một hành động được yêu cầu với các ngưỡng, danh sách cho phép, kết quả định danh, giá hoặc tín hiệu rủi ro đang thay đổi mà không đẩy toàn bộ logic đó trực tiếp vào hợp đồng ứng dụng.
Điều gì vẫn vĩnh viễn?
Sự phân biệt đó nghe có vẻ mang tính kỹ thuật. Thực ra nó thay đổi điều gì phải được giữ vĩnh viễn.
Ranh giới thực thi có thể vẫn được liên kết với ứng dụng trong khi các quy tắc phía sau ranh giới đó tiếp tục phát triển. Tài liệu nội bộ của Newton mô tả rằng các chính sách có thể được cập nhật mà không cần phải triển khai lại hợp đồng được bảo vệ, trong khi thông báo Mainnet Beta của họ đưa ra ví dụ như một ngưỡng được sửa đổi hoặc yêu cầu trừng phạt mới có hiệu lực mà không phải viết lại hợp đồng ứng dụng.
Điều thu hút tôi là Newton không thực sự chọn giữa mã bất biến và chính sách linh hoạt. Nó đang cố gắng giao cho mỗi cái một vai trò khác nhau:
Hợp đồng ứng dụng: Xác định nơi mà quá trình ủy quyền phải diễn ra.
Chính sách: Xác định những điều kiện hiện tại phải được đáp ứng.
Dữ liệu từ Oracle: Có thể khác nhau cho từng giao dịch.
Nhưng oracle, chính sách và hợp đồng thông minh không nhất thiết phải thay đổi cùng lúc. Bản thân hợp đồng thông minh có thể vẫn nằm đó trong nhiều năm. Một ngưỡng rủi ro có thể thay đổi vào tháng tới. Kết quả áp dụng trừng phạt hoặc tín hiệu sức khoẻ thị trường có thể thay đổi trước khi giao dịch tiếp theo đến. Việc mã hoá cứng cả ba thứ này vào cùng một hợp đồng sẽ khiến phần chậm nhất của hệ thống phải chịu trách nhiệm cho thông tin thay đổi nhanh hơn rất nhiều.
Newton tách họ ra. Điều đó có thể quan trọng hơn vẻ ngoài ban đầu của nó.
Bài toán quản trị chính xác hơn
Trong thiết kế hợp đồng thông minh truyền thống, khả năng nâng cấp thường được xem như một vấn đề ở cấp hợp đồng. Hoặc hợp đồng được cố định, hoặc ai đó có quyền nâng cấp nó.
Newton đưa thêm một lớp khác giữa hai lựa chọn đó. Ứng dụng được bảo vệ có thể vẫn ổn định trong khi các điều kiện ủy quyền xung quanh các hành động cụ thể được điều chỉnh riêng biệt.
Vậy câu hỏi không còn là: Hợp đồng này có thể được nâng cấp không?
Và trở thành: Những phần nào của quy trình ủy quyền được phép thay đổi, ai kiểm soát các thay đổi đó, và những phần nào vẫn liên kết vĩnh viễn với việc thực thi?
Đó là một bài toán quản trị chính xác hơn rất nhiều.
Sự đánh đổi của tính linh hoạt
Tính linh hoạt không phải lúc nào cũng đồng nghĩa với an toàn hơn. Một chính sách cập nhật nhanh có thể thích nghi với luật mới, biến động thị trường hoặc các mối đe doạ an ninh. Nhưng nó cũng có thể thay đổi các quy tắc mà người dùng ban đầu đã chấp nhận.
Giảm giới hạn rủi ro có thể bảo vệ vốn.
Việc mở rộng lặng lẽ danh sách cho phép hoặc làm suy yếu một yêu cầu an ninh có thể làm điều ngược lại.
Mối nguy không biến mất chỉ vì chính sách được tách khỏi hợp đồng; nó chuyển hướng sang quản trị chính sách.
Ai được phép cập nhật các tham số?
Thay đổi có dễ nhận thấy không?
Người dùng có thể kiểm tra chính sách đang bảo vệ một ứng dụng không?
Các phiên bản trước có còn dễ hiểu sau khi phiên bản mới thay thế chúng không?
Những câu hỏi đó trở nên quan trọng không kém gì bản thân logic Rego. Đó là phần mà tôi cứ liên tục quay lại.
Kết luận: Tính vĩnh cửu của việc thực thi
Newton không biến các quy tắc tài chính thành vĩnh viễn. Các yêu cầu tuân thủ thực tế, mức chịu rủi ro và điều kiện an ninh thay đổi quá thường xuyên để điều đó là khả thi.
Thứ mà nó cố gắng làm cho vĩnh viễn là yêu cầu rằng các hành động được bảo vệ phải luôn đi qua cơ chế ủy quyền ở mọi nơi
Quy tắc có thể thay đổi
Dữ liệu có thể thay đổi.
Ngưỡng có thể thay đổi.
Nhưng ứng dụng không thể lặng lẽ dừng việc yêu cầu xin phép.
Với tôi, đó là một dạng tính nhất quán thú vị hơn so với việc cứ mã hoá cứng mọi quy tắc mãi mãi. Newton không đóng băng chính sách tại chỗ. Nó đang sửa điểm mà ở đó chính sách phải có tác dụng.
