Một người bạn làm nghề lên kế hoạch đám cưới cho biết phần khó thực sự không phải là việc đặt bất kỳ một nhà cung cấp riêng lẻ nào. Hoa sĩ, đơn vị tổ chức tiệc, địa điểm—mỗi bên riêng ra thì đều dễ để phối hợp. Phần khó nằm ở “chuỗi” liên kết: đảm bảo việc giao hàng của hoa sĩ không xung đột với khung thời gian chuẩn bị của địa điểm; kế hoạch thời gian của bên tiệc lại phải dựa trên đúng số khách dự kiến từ danh sách mời—mà đến tận tuần trước vẫn còn thay đổi. Chỉ cần một mắt xích trong chuỗi bị hỏng—kể cả một nhà cung cấp vốn riêng lẻ đáng tin cậy hoàn hảo—cũng có thể lan thành một mớ hỗn độn mà chẳng ai đã lên kế hoạch cho, vì việc phối hợp giữa các phần đáng tin cậy lại chính là một nguồn rủi ro riêng.

Rủi ro phối hợp tương tự đó nằm ngay dưới bộ điều phối thực thi của Newton—thành phần được tạo ra để hỗ trợ tự động hóa trải dài nhiều nhà cung cấp và nhiều chuỗi, bằng cách xâu chuỗi các hành động tự động thay vì buộc con người phải tự nối (bridge) và tự triển khai lại vốn (re-deploy) theo cách thủ công. Lời chào hàng (pitch) thực sự rất hấp dẫn: triển khai các chiến lược tinh vi trải dài qua nhiều chuỗi, tự động tái cân bằng (rebalance) trên nhiều giao thức tạo lợi nhuận (yield protocols), thực thi cơ hội arbitrage mà không cần can thiệp thủ công, tất cả kèm theo xác minh đúng đắn bằng mật mã (cryptographic verification) trong suốt quá trình. Mỗi mảnh ghép riêng lẻ của chuỗi đó—một hành động đã được xác minh trên một chuỗi, một hành động đã được xác minh trên chuỗi khác—đều là năng lực có thật và đã được chứng minh. Khoảng trống cần được xem xét là điều gì xảy ra một cách cụ thể tại các “đường nối” (seams): những khoảnh khắc nơi hành động của một nhà cung cấp cần phải bàn giao trơn tru sang nhà cung cấp tiếp theo trong một chuỗi mà người dùng định nghĩa như một chiến lược liên tục duy nhất.

Việc chia nhỏ vấn đề thành các chi tiết cụ thể giúp khoảng trống trở nên rõ ràng thay vì trừu tượng. Thứ nhất, tính cuối cùng của trạng thái giữa các chuỗi (cross-chain state finality) phụ thuộc vào việc rollup Keystore theo dõi đúng quyền hạn và các chuyển trạng thái trên nhiều chuỗi, nghĩa là một chiến lược nhiều bước chỉ đáng tin cậy như phần chậm nhất hoặc ít trưởng thành nhất trong quá trình theo dõi giữa các chuỗi đó, chứ không chỉ dựa vào từng chuỗi riêng lẻ. Thứ hai, mỗi nhà cung cấp và giao thức nền tảng mà bộ điều phối (orchestrator) kết nối lại đều có thời gian hoạt động (uptime), độ trễ (latency) và đặc tính lỗi riêng mà Newton không thể kiểm soát, nghĩa là một chiến lược trải qua ba giao thức khác nhau sẽ kế thừa rủi ro độ tin cậy tổng hợp của cả ba, không chỉ cơ sở hạ tầng của Newton. Thứ ba, TEE và xác minh bằng zero-knowledge đảm bảo rằng mỗi bước riêng lẻ được thực thi đúng theo các quy tắc của chính nó, nhưng một chuỗi các bước lại đặt ra một câu hỏi khác biệt: điều gì xảy ra khi bước hai phụ thuộc vào đúng kết quả cụ thể của bước một và thời điểm hoặc kết quả của bước một lại nằm ngoài những gì logic của bước hai đã dự kiến—một lỗi phối hợp (coordination failure) mang tính chất khác hẳn so với việc chỉ có một bước nào đó đơn giản là hoạt động sai. Thứ tư, trọng tâm của lộ trình vào các cải tiến khả năng mở rộng và xác minh bằng chứng tổng hợp cho thấy hệ thống hiện tại có lẽ ban đầu chưa được xây dựng với giả định sẽ xử lý khối lượng lớn dạng chuỗi, đa nhà cung cấp; nghĩa là việc điều phối hiện nay có khả năng chỉ đã được chứng minh ở quy mô nhỏ hơn so với tầm nhìn đa chuỗi trong tương lai cần. Thứ năm, nhu cầu tự động hóa tương quan (correlated automated demand), nơi nhiều tác nhân (agents) có thể kích hoạt các hành động chuỗi tương tự trong cùng điều kiện thị trường, có thể làm căng các điểm bàn giao giữa các nhà cung cấp—những chỗ vốn khó khăn nhất—bởi vì tắc nghẽn hoặc độ trễ ở một mắt xích trong chuỗi sẽ lan truyền tiếp vào mọi bước sau đó, các bước sau phải chờ mắt xích đó.

Không có điều nào trong số này có nghĩa là tự động hóa liên giao thức theo chuỗi (chained cross-protocol automation) không hoạt động. Các mảnh ghép nền tảng là có thật và mô hình xác minh thực sự làm giảm rủi ro so với việc tin tưởng một bot dạng hộp đen (black-box) để xử lý cùng một quy trình đa bước. Khoảng trống trung thực nằm ở chỗ: một chiến lược hoạt động ổn định khi được kiểm thử riêng lẻ, từng bước một, trong điều kiện bình thường, và sau đó chiến lược đó vẫn giữ vững khi mọi bước trong chuỗi đều chịu áp lực đồng thời—đúng là kịch bản mà một người lên kế hoạch cho đám cưới lo lắng, và cũng chính là kịch bản mà hiện vẫn chưa được kiểm thử đầy đủ trên cơ sở hạ tầng đa chuỗi đang phát triển của Newton.

Bài học thực tiễn dành cho bất kỳ ai đang xây dựng hoặc sử dụng một chiến lược tự động hóa theo chuỗi trên Newton ngày nay là hãy cân nhắc độ phức tạp của chính chuỗi đó như một yếu tố rủi ro độc lập, tách biệt khỏi rủi ro của từng bước riêng lẻ. Lý do là: một chiến lược cross-chain gồm ba bước mang theo rủi ro phối hợp lớn hơn đáng kể so với ba chiến lược riêng lẻ, mỗi chiến lược chỉ một bước, ngay cả khi mọi bước riêng lẻ đều độc lập đã được xác minh và chứng minh là đúng theo các điều kiện của chính nó.

Bộ điều phối thực thi của Newton không bị hỏng, và tầm nhìn tự động hóa đa nhà cung cấp không phải là rỗng, nhưng khoảng cách giữa việc xâu chuỗi các hành động riêng lẻ đã được xác minh và việc đảm bảo một chuỗi hoàn chỉnh đã được xác minh, đáng tin cậy là có thật. Điều này không được giải quyết bởi bất kỳ tài liệu đơn lẻ nào, và xứng đáng được xem như một câu hỏi kỹ thuật còn bỏ ngỏ (open engineering question) thay vì một tính năng đã được giải sẵn, theo cách mà bạn tôi chưa bao giờ cho rằng chỉ cần có một tiệm hoa tốt và một nhà cung cấp đồ ăn tốt thì tự động ngày cưới sẽ đúng lịch.

@NewtonProtocol $NEWT #Newt $PALU $VELVET