Vì sao tôi muốn cả đường ống đầy đủ, không chỉ bản giới thiệu
Hầu hết các mô tả về Newton — của tôi cũng như vậy, trong các bài viết trước đó — đều mô tả vòng đời của chính sách một cách khái quát: viết một chính sách, triển khai nó, các giao dịch được kiểm tra dựa trên chính sách đó. Tôi muốn có chuỗi thực tế mà một nhà phát triển chạy, theo từng lệnh, vì đó thường là nơi khoảng cách giữa "như nó được giới thiệu" và "nó hoạt động như thế nào" thể hiện rõ nhất.
Chuỗi thực sự
Được trích dẫn trực tiếp từ tài liệu tham khảo của Newton's CLI, theo đúng thứ tự mà tài liệu trình bày:
1. Tạo CID. newton-cli policy-files generate-cids --directory policy-files --output policy-files/policy_cids.json --entrypoint "max_gas_price.allow". Các tệp policy Rego của bạn được tải lên IPFS thông qua Pinata và bạn sẽ nhận được các mã định danh nội dung. Hãy lưu ý entrypoint được nêu rõ ở đây — max_gas_price.allow không phải chỗ giữ chỗ, mà là cấu trúc của policy ví dụ trong chính tài liệu: một đường dẫn quy tắc cụ thể mà bộ đánh giá sẽ gọi.
2. Triển khai hợp đồng dữ liệu policy. Đây là hợp đồng riêng, tách biệt với chính policy và được liên kết với các CID đã tạo ở trên.
3. Triển khai hợp đồng policy. newton-cli policy deploy --policy-cids policy-files/policy_cids.json --policy-data-address 0x.... Đây là bước liên kết logic Rego và phần phụ thuộc dữ liệu của nó lên onchain.
4. Cấu hình policy client. Hợp đồng sử dụng policy trỏ đến policy đã triển khai và đăng ký các tham số riêng — đây là bước mà các báo cáo độc lập đã cảnh báo rất dễ bị bỏ qua, khiến client trông như đã kết nối nhưng thực tế không thể xác thực bất cứ thứ gì cho đến khi hoàn tất bước cấu hình.
5. Mô phỏng. newton-cli policy simulate --policy-client 0x... --intent-from 0x... --intent-to 0x... --intent-value 0x0 --intent-data 0x... --gateway-url https://gateway.testnet.newton.xyz. Chạy toàn bộ quá trình đánh giá Rego + WASM + secrets trên máy của bạn, với một giao dịch giả định cụ thể, trước khi bất cứ thứ gì chạm đến mạng thật.
6. Gửi yêu cầu thật. Chạy newton-cli task submit-evaluation-request với các trường intent tương tự. CLI chuẩn hóa intent (chuyển value và chainId sang dạng hex), ký task rồi gửi đến Newton Gateway. Phản hồi trả về bao gồm signature_data — payload thực tế mà hợp đồng thông minh cần để xác thực attestation onchain.
Bước Này Không Có Nghĩa Như Tên Gọi Gợi Ra
Bước 5 là bước đáng để dừng lại xem xét. “Mô phỏng” nghe như thể nó sẽ cho bạn biết policy có thực sự hoạt động khi chạy thật hay không. Nhưng không — ít nhất là không hoàn toàn.
Mô phỏng cục bộ sẽ chạy logic Rego của bạn, thực thi mọi thành phần cung cấp dữ liệu WASM và giải mã mọi secrets cần thiết — tất cả ngay trên máy của bạn, với một giao dịch giả định. Việc này xác minh được những điều thực sự hữu ích: logic policy của bạn đúng cú pháp, các nguồn dữ liệu được phân giải và quá trình đánh giá cho ra kết quả bạn mong đợi với đầu vào cụ thể đó. Một mức độ tin cậy thực chất và có giá trị.
Điều mà mô phỏng không thể kiểm thử là yếu tố thực sự khiến kết quả của Newton đáng tin cậy trong môi trường production: một quorum gồm các operator độc lập, mỗi bên tự chạy quá trình đánh giá và đồng thuận bằng mật mã về cùng một kết quả. Mô phỏng chỉ là một máy — có lẽ là máy của bạn — chạy logic một lần. Toàn bộ giá trị mà mạng thật mang lại dựa trên việc nhiều bên độc lập cùng đi đến một kết luận, được bảo đảm bằng vốn đã stake, cùng cơ chế khiếu nại nếu họ không đồng thuận. Không điều nào trong số đó tồn tại trong mô phỏng cục bộ, bởi một lần chạy đơn lẻ trên máy cục bộ thì chẳng có ai để bất đồng.
Vì Sao Cần Nêu Rõ Khoảng Cách Đó
Đây không phải lỗi của công cụ. Một lần chạy thử cục bộ có dựng lên một quorum nhiều operator giả lập sẽ là một phần mềm khác, phức tạp hơn nhiều, và có lẽ cũng chẳng cho bạn biết thêm điều gì hữu ích về logic policy thực tế của mình. Đây là một sự đánh đổi hợp lý về mặt kỹ thuật.
Nhưng điều đó cũng có nghĩa là câu “Tôi đã mô phỏng và nó chạy đạt” hàm ý hẹp hơn vẻ ngoài của nó đối với người chưa đọc tài liệu tham khảo lệnh. Nó cho biết policy hoạt động như bạn dự định trong các trường hợp bạn đã kiểm thử. Nó không cho bạn biết gì về khả năng hoạt động liên tục của operator, sự đồng thuận của quorum trong điều kiện mạng thực tế, hay cách policy xử lý những đầu vào bạn chưa nghĩ đến để mô phỏng. Đó mới là những thuộc tính thực sự làm nên khác biệt giữa mạng Newton đang hoạt động và “một trình kiểm tra cú pháp Rego với vài bước phụ” — và chính xác là những thuộc tính mà mô phỏng, vốn chỉ là công cụ chạy đơn lẻ trên máy cục bộ, không thể kiểm thử.
Điều Tôi Thực Sự Muốn Biết Trước Khi Tin Vào Tuyên Bố “Đã Mô Phỏng Và Chạy Đạt”
Nếu tôi đang đánh giá một vault hay policy client mà ai đó nói đã “mô phỏng rất kỹ”, câu hỏi tiếp theo của tôi không phải là họ có chạy lệnh simulate hay không. Tôi sẽ hỏi họ đã kiểm thử những loại đầu vào nào — các trường hợp biên, dữ liệu sai định dạng, các trường intent mang tính đối kháng — bởi mô phỏng chỉ phát hiện vấn đề trong những tình huống mà ai đó đã nghĩ đến để tạo ra. Một policy vượt qua mô phỏng với luồng xử lý thuận lợi nhất nhưng chưa bao giờ được kiểm thử áp lực với tình huống bất thường vẫn là một ẩn số khi các giao dịch thật, đôi lúc kỳ quặc, bắt đầu đổ về.
Tóm Lược Thẳng Thắn
Quy trình triển khai được chia thành các giai đoạn cẩn thận hơn nhiều công cụ onchain khác — tách riêng việc tải tệp lên, triển khai hợp đồng, cấu hình client, kiểm thử cục bộ và gửi yêu cầu lên mạng thật thành các bước riêng biệt, có thể kiểm tra từng bước, là một thực hành tốt. Nhưng bước “mô phỏng” trong quy trình đó đảm nhiệm một việc hẹp hơn tên gọi gợi ra: nó kiểm tra tính đúng đắn của logic, chứ không diễn tập cơ chế tạo nên niềm tin thực sự — quorum operator — vốn là lý do duy nhất để dùng Newton thay vì tự viết quy tắc onchain. Hãy nhớ sự khác biệt này trước khi xem một lần mô phỏng thành công là bằng chứng rằng mọi thứ đều ổn.