@NewtonProtocol cho phép bất kỳ ai cũng có thể gửi mã WebAssembly kéo dữ liệu bên ngoài trực tiếp vào các chính sách Rego. Yêu cầu đưa ra rất đơn giản: điều này giúp các quyết định on-chain linh hoạt như các API ngoài chuỗi mà không phải đánh đổi việc thực thi có thể được kiểm chứng. Trên thực tế, nó chuyển công việc và rủi ro sang người nào chịu trách nhiệm duy trì thành phần WASM đó. $NEWT 
Tôi đã dành thời gian xem tài liệu và ví dụ của họ. Đây là những điểm nổi bật khi bạn thử dùng nó cho một việc thực tế.
Luồng Oracle hoạt động thực sự như thế nào
Bạn viết một chương trình nhỏ (hiện tại chủ yếu là JavaScript) thực thi hàm run. Chương trình nhận JSON, có thể gọi HTTP thông qua host, tùy chọn đọc các bí mật, và trả về JSON sẽ nằm trong chính sách của bạn dưới dạng dữ liệu ở data.wasm.
Mạng chạy nó trong sandboxed Wasmtime trong quá trình đánh giá chính sách. Không có IP riêng, không có giới hạn tính toán vô hạn. Hỗ trợ TLSNotary là cái mới và thú vị cho việc kéo dữ liệu web đã được xác thực mà không cần giới hạn WASM 1 MiB thông thường.
Bằng chứng cho thấy nó thực sự được triển khai: $ARX
Giao diện WIT là rõ ràng: một tệp newton-provider.wit mới định nghĩa việc fetch http, secrets và xác minh tlsn.
Bước build khá thẳng: với jco, jco componentize sẽ biến JS của bạn thành một thành phần policy.wasm với các import đúng.
Bắt buộc có schema: wasm_args_schema.json sẽ bắt các input sai trước khi chúng chạm vào chuỗi; params_schema.json đẩy các ngưỡng có thể cấu hình vào Rego dưới dạng data.params.*.
Kiểm thử làm trước tại máy (local-first) thông qua newton-cli simulate, sau đó là RPC cho newt_simulatePolicyData.
Các con số từ phần thiết lập: phản hồi HTTP được giới hạn ở mức hợp lý, tải xuống IPFS cho các proof TLSNotary lên tới 5 MiB, và toàn bộ chạy theo từng lượt đánh giá (mỗi task). Nhờ vậy chi phí dễ dự đoán hơn so với các indexer chạy liên tục.
Một điểm căng thẳng thực dụngTension $BEAT
Ma sát thực sự nằm ở quyền sở hữu. Bạn quyết định chính xác dữ liệu chính sách của bạn lấy giá từ endpoint nào, yield của treasury, trạng thái vault trên on-chain, bất cứ thứ gì. Nhưng giờ bạn cũng phải tự sở hữu logic fetch, xử lý lỗi và nhịp cập nhật.
Nếu hôm mai API bên ngoài thay đổi cấu trúc phản hồi, oracle của bạn sẽ âm thầm hỏng cho đến khi bạn biên dịch lại và triển khai lại WASM. Các chính sách phụ thuộc vào nó sẽ hoặc fail closed, hoặc dự phòng. Điều đó khác với việc tin vào một nguồn oracle feed tập trung mà người khác duy trì.
Điều gì đang hoạt động tốt ngay bây giờ:
Prototype nhanh: phân tích một object args, gọi một endpoint công khai, rồi trả về các trường có cấu trúc. Ví dụ JS trong tài liệu làm đúng điều này cho một price feed.
Đường dẫn TLSNotary để đảm bảo cao hơn: verify-from-cid cho phép host xử lý việc tải xuống và xác minh, rồi bạn sẽ nhận được server-name, timestamp, transcripts, và dấu vân tay notary.
Xác thực schema ngay từ đầu: wasm_args bị lỗi sẽ bị từ chối trước khi tốn gas.
Những rủi ro đáng liệt kê:
Rủi ro hợp đồng/thành phần: WASM chạy trong mạng của operator, nhưng lỗi trong quá trình chạy (run), function có thể đưa dữ liệu sai vào chính sách Rego. Các cuộc kiểm toán chính bản thân oracle là do bạn chịu.
Tính bền vững và rủi ro thay đổi: các nguồn dữ liệu bên ngoài có thể thay đổi điều khoản, ngừng (deprecate) endpoint, hoặc bóp nghẹt băng thông (throttle). Độ tin cậy kiểu APY của oracle bạn (tần suất nó thành công) phụ thuộc vào những thứ bạn không kiểm soát. Điều kiện rút tiền hoặc cập nhật chính sách trở nên quan trọng khi tính “tươi” của dữ liệu là yếu tố then chốt.
Checklist nhanh tôi sẽ xác minh trước khi dựa vào một hệ duy nhất
Nguồn của yield/dữ liệu: đó là một API hay nhiều API? Ai là người cuối cùng trả tiền hoặc lưu trữ nó?
Cơ chế cập nhật: bạn cập nhật WASM mới bằng cách nào? Có versioning trên chuỗi không, hay chỉ là IPFS thay thế?
Tham số có thể thay đổi ngay lập tức không: ngưỡng chính sách so với logic oracle.
Rút tiền / cơ chế thất bại: điều gì xảy ra với các task đang chờ nếu oracle trả về err?
Kiểm toán và khả năng tái lập: thành phần đã được xem xét chưa? Người khác có thể biên dịch lại từ mã nguồn không?
Newton cung cấp cho bạn các công cụ: hợp đồng WIT, các hàm host, kiểm thử bằng CLI, nhưng không loại bỏ gánh nặng bảo trì. Điều này có vẻ trung thực. Nhiều hệ thống oracle giấu phần đó phía sau câu “chỉ cần gọi feed của chúng tôi”. Ở đây, tính minh bạch được tích hợp sẵn: bạn thấy đúng đoạn mã nào chạy vì bạn đã tự viết (hoặc đã rà soát) WASM.
Quan sát sâu hơn về việc tách Chính sách + Dữ liệu
Việc tách phần fetch dữ liệu (WASM) khỏi logic quyết định (Rego) là gọn gàng trên giấy. Rego giữ nguyên tính thuần và có thể kiểm toán; oracle xử lý thế giới lộn xộn. Trong thực tế, nó buộc suy nghĩ rõ hơn: chính sách của tôi thực sự cần những input nào? Những trường nào là tùy chọn?
Mình thích việc secrets được giới hạn phạm vi và được fetch ngay trong oracle, không truyền theo dạng bản rõ. Và các phần mới của TLSNotary giải quyết câu hỏi “làm sao để tôi tin vào phản hồi web này” mà mọi oracle tùy chỉnh cuối cùng cũng phải đối mặt.
Dẫu vậy, vẫn còn một “biên” chưa trọn vẹn. Nếu use case của bạn cần cập nhật thường xuyên hoặc nhiều nguồn dữ liệu, bạn sẽ phải thường xuyên xây dựng và kiểm thử các thành phần WASM. Tài liệu cũng nói đến các lựa chọn Rust và Python, có thể giúp cho hiệu năng hoặc khả năng truy cập thư viện, nhưng bề mặt triển khai vẫn như cũ.
Kết luận: oracle dữ liệu của Newton đổi niềm tin tập trung lấy trách nhiệm cá nhân. Quyền lực là thật nếu bạn giữ component nhỏ và được kiểm thử tốt.
Mâu thuẫn vẫn còn đó về việc liệu có bao nhiêu đội thực sự sẽ tự duy trì oracle của mình lâu dài hay chuyển sang dựa vào các oracle dùng chung. Đáng theo dõi mô hình nào thắng khi thêm nhiều dự án phát hành chính sách.