Có điều gì đó trong hướng dẫn quickstart làm tôi băn khoăn trước khi tôi có thể gọi tên cho nó. Chỉ mất năm phút, không cần ví, không cần testnet đã được nạp, và một chính sách đã chạy hoàn chỉnh từ đầu đến cuối.
Điểm bắt đầu để kiểm thử bất kỳ chính sách nào trên Newton là một hàm có tên là simulateTask. Hãy chạy nó và script của bạn sẽ nói chuyện với cổng Newton thực, nơi sẽ chuyển ý định đến một nhà điều hành (operator) hiện có. Nhà điều hành đó sẽ đánh giá chính sách so với dữ liệu trực tiếp—cho dù chính sách đó là một chiến lược giao dịch quyết định khi nào cần tái cân bằng hay là một bước kiểm tra sàng lọc đối với một đối tác (counterparty)—và gửi lại kết quả. Không có ví nào kết nối, không có ETH testnet nào được chi tiêu, và không có gì được ghi lên chuỗi (on-chain). Tài liệu gọi nó là một lần chạy thử (dry run) theo ngôn ngữ đơn giản, và đối với hầu hết những người đang xây dựng trên Newton, đây là phiên bản kiểm thử duy nhất mà họ từng thấy trước khi phát hành.
Đây là phần đáng để ngồi với. Câu trả lời của toán tử đơn lẻ đó là thực, không phải một bản mô phỏng chạy trong chân không. Điều còn thiếu chỉ xuất hiện khi có hơn một toán tử ở trong phòng. Trong môi trường vận hành, một tập hợp các toán tử sẽ độc lập tự kéo cùng dữ liệu, đánh giá nó, và phải đồng ý đủ chặt chẽ để một xác nhận BLS hình thành trước khi bất cứ thứ gì được đưa đến hợp đồng thông minh. simulateTask không bao giờ đặt hai toán tử đứng trước cùng một đầu vào cùng lúc, nên nó không thể tạo ra bất đồng dù bạn chạy bao nhiêu lần. Một chính sách vượt qua năm mươi lần gọi simulateTask đã chứng minh logic của nó đúng trước bất cứ điều gì một toán tử đơn lẻ tình cờ nhìn thấy. Nó chưa chứng minh được điều gì xảy ra khi nhiều toán tử thấy những con số hơi khác nhau và phải đối chiếu chúng—và đó chính là lý do trong pipeline thực tế tồn tại cơ chế tính median và kiểm tra ngưỡng dung sai.
Tôi cứ quay lại điểm này: năm mươi lần chạy kiểm tra và không có bất đồng nào thì lại là cùng một con số, trong khi chỉ có duy nhất bạn hỏi một toán tử. Thật trớ trêu, các lần chạy càng mượt mà thì thực tế nó càng chưa kiểm tra được nhiều.
Khoảng trống đó có lợi cho Newton nhiều hơn là Newton phải trả giá gì. Một phễu onboarding năm phút là một con số thực sự tốt cho chính giao thức, và mỗi nhà phát triển đưa ra một simulateTask chạy được và tiếp tục sang bước khác là một bằng chứng nhỏ rằng giao thức dễ xây dựng. Bằng chứng đó được cộng dồn trên một thị trường cần những người xây dựng xuất hiện với quy mô lớn. Trong khi đó, phần “phơi bày” nằm hoàn toàn ở nơi khác: nơi có người cuối cùng triển khai một chính sách mà chưa bao giờ kích hoạt lỗi ToleranceExceeded, chưa bao giờ phải xử lý việc hai toán tử bất đồng về một điểm dữ liệu, và sắp lần đầu tiên gặp phải bất đồng đó với dòng vốn thực bám theo kết quả.
Thành thật mà nói, đó không phải là một khoảng trống giả định. Đó là chính là khoảng trống mà simulateTask được xây để để ngỏ, vì việc kiểm thử nó cho đúng cách sẽ đồng nghĩa phải hy sinh năm phút mà khiến quickstart trở nên đáng làm.
Khi đủ nhiều người xây dựng dựa trên một công cụ như thế này, vòng phản hồi nhanh bắt đầu định hình hành vi dù ai đó có ý định hay không, vì vòng lặp lặp lại luôn trôi về phía con đường vừa trống sẵn vừa chạy ngay lập tức. Một nhà phát triển có thể chạy simulateTask năm mươi lần khi đang định hình một chính sách và chỉ chạm một lần vào toàn bộ pipeline quorum, ngay trước khi phát hành—nếu có. Điều đó không phải vì lười biếng, chỉ là vật lý: một nhánh không tốn gì, còn nhánh kia cần một ví có nạp vốn, một testnet và một mạng lưới các toán tử thực sự sẵn sàng bất đồng với nhau.
Những gì được tinh chỉnh trong năm mươi lần chạy đó là logic chính sách. Những gì không bao giờ bị ép kiểm tra áp lực là lớp quyết định liệu chính sách có sống sót khi va chạm với một mạng lưới vận hành thực sự hay không.
Ai mà nghĩ rằng phần thân thiện nhất của tài liệu lại rốt cuộc dạy cho nhà phát triển ít nhất về đúng một kiểu lỗi mà thực sự quan trọng trong sản xuất. Sự tách lớp này không phải là ác ý. Nó chỉ là thứ mà bất kỳ hệ thống nào cũng có xu hướng hướng tới khi một bên của quyết định được đo đạc liên tục, còn bên kia được đo đạc thỉnh thoảng, nếu có. Việc onboarding nhanh trở thành chỉ số nhìn thấy được—con số mà Newton có thể trỏ tới. Tính sẵn sàng của quorum lại là chỉ số vô hình, được kiểm tra sau, kiểm tra ít hơn, và chủ yếu chỉ được kiểm tra bởi ai đủ cẩn thận để với tới một ví đã được nạp vốn sau khi phiên bản cục bộ đã chạy ổn.
Không cái gì trong đó làm thiết kế sai. Hoặc có lẽ nó chỉ có nghĩa là đa số lỗi trong chính sách thực sự là lỗi logic, và tôi nghĩ điều đó đúng thường xuyên hơn ta tưởng. Khi đó, một vòng lặp năm phút bắt được chúng trước khi ai kịp tốn gas là một món quà thực sự đối với một người xây dựng, không phải mánh khóe. Yêu cầu kết nối ví chỉ để kiểm tra xem một ngưỡng có được ghi đúng hay không sẽ là một kiểu thiết kế tệ khác—chậm vì không có lý do và tốn kém vì không có lý do. Thực ra, tôi cũng không chắc có nên gọi đó là một “trade-off” không. Có thể chỉ là một sự sắp xếp thứ tự công việc tốt hơn.
Newton không hề che giấu simulateTask làm gì. Tài liệu nêu rõ ràng rằng nó không gửi bất cứ thứ gì lên chuỗi, và khoảng cách giữa câu trả lời của một toán tử với câu trả lời của một quorum được ghi nhận trong tài liệu—chỉ là không nhất thiết ở cùng hơi thở như phần quickstart mà hầu hết mọi người đọc trước tiên.
simulateTask rõ ràng là một công cụ tốt. Có lẽ câu hỏi thật sự lại khác: liệu việc cho phép nó “trải nghiệm” trong năm phút đôi khi có nên được coi như đích đến, thay vì là điểm bắt đầu của phần thực sự quan trọng không?