Tác giả: Zack Pokorny, nghiên cứu viên trợ lý tại Galaxy Digital; Nguồn: Galaxy Digital; Biên dịch: Shaw Tin tức Tài chính Kim sắc

Lời mở đầu

Các kịch bản ứng dụng và năng lực của AI Agent (tác nhân AI) đã bắt đầu từng bước tiến hóa. Chúng đang dần thực hiện việc tự chủ hoàn thành nhiệm vụ; các hoạt động R&D liên quan cũng đang được triển khai để tác nhân nắm giữ và cấu hình vốn, phát hiện các chiến lược giao dịch và lợi nhuận, v.v. Mặc dù sự chuyển đổi mang tính thử nghiệm này vẫn ở giai đoạn cực kỳ sớm, hướng phát triển của nó đã khác hẳn so với quá khứ — trước đây, đa số tác nhân chủ yếu chỉ được dùng như công cụ xã hội và phân tích.

Blockchain đang cung cấp một môi trường thử nghiệm tự nhiên cho quá trình tiến hóa này. Blockchain có tính không cần cấp phép, khả năng kết hợp (tức là cùng một khung thực thi có thể gánh nhiều ứng dụng thành phần cơ sở tài chính khác nhau), hệ sinh thái ứng dụng mã nguồn mở, dữ liệu mở bình đẳng cho mọi người tham gia, và mọi tài sản trên chuỗi mặc định đều hỗ trợ lập trình hóa.

Từ đó nảy sinh một vấn đề mang tính cấu trúc: nếu blockchain có thể lập trình và không cần cấp phép, vì sao các tác nhân thông minh tự chủ vẫn gặp trở ngại trong vận hành? Câu trả lời không nằm ở việc việc thực thi có khả thi hay không, mà nằm ở việc tầng thực thi cần phải gánh chi phí bao nhiêu cho hiểu biết ngữ nghĩa và điều phối phối hợp. Blockchain có thể đảm bảo tính chính xác của các chuyển trạng thái, nhưng thường không cung cấp các năng lực trừu tượng như diễn giải kinh tế nguyên sinh của giao thức, định danh chuẩn hoặc điều phối theo cấp bậc mục tiêu.

Một phần trở ngại xuất phát từ đặc tính kiến trúc của hệ thống không cần cấp phép; phần khác đến từ thực trạng phát triển của các công cụ hiện tại, việc lọc thông tin và cơ sở hạ tầng thị trường. Trong ứng dụng thực tế, nhiều chức năng cấp cao vẫn phải dựa vào các phần mềm và quy trình làm việc được thiết kế với con người là trung tâm thao tác.

Kiến trúc blockchain và các tác nhân AI

Trọng tâm thiết kế của blockchain xoay quanh cơ chế đồng thuận và thực thi xác định (deterministic execution), chứ không phải diễn giải ngữ nghĩa. Thứ blockchain cung cấp ra bên ngoài là các thành phần cơ sở cấp thấp như slot lưu trữ, nhật ký sự kiện, truy vết lời gọi, chứ không phải các đối tượng kinh tế được tiêu chuẩn hóa. Vì vậy, các khái niệm trừu tượng như vị thế nắm giữ, lợi nhuận, hệ số sức khỏe, độ sâu thanh khoản… thường cần được chỉ số hóa (index), lớp phân tích, giao diện người dùng (front-end) và các API ứng dụng tái cấu trúc ngoài chuỗi (off-chain), nhằm chuyển đổi trạng thái riêng của từng giao thức thành dạng dễ sử dụng hơn.

Nhiều quy trình vận hành DeFi phi tập trung phổ biến, đặc biệt là các thao tác hướng tới người dùng phổ thông và các quyết định mang tính chủ quan, vẫn lấy tương tác của người dùng với giao diện là lõi: người dùng tương tác qua front-end, xác nhận bằng chữ ký cho từng giao dịch. Mô hình lấy giao diện người dùng làm trung tâm này, đi cùng sự phổ biến của người dùng phổ thông, đã tạo điều kiện cho ứng dụng được mở rộng theo quy mô. Dù một phần đáng kể hoạt động trên chuỗi hiện nay đã do máy móc điều khiển, logic tương tác phổ biến của người dùng vẫn là: ý định thao tác → giao diện người dùng → khởi tạo giao dịch → xác nhận hoàn tất. Dù thao tác lập trình có đường đi khác, nó cũng có các giới hạn riêng: nhà phát triển phải chọn trước hợp đồng và phạm vi tài sản ngay trong giai đoạn xây dựng, sau đó chạy thuật toán dựa trên phạm vi cố định đó. Hai mô hình này đều không thích ứng với những hệ thống cần tự phát hiện, đánh giá và kết hợp hành vi thao tác trong quá trình chạy, theo các mục tiêu động.

Khi một hệ thống được tối ưu cho xác thực giao dịch, đồng thời được dùng trong các hệ thống cần diễn giải trạng thái kinh tế, đánh giá tín nhiệm và tối ưu hành vi xung quanh mục tiêu rõ ràng, thì trở ngại trong vận hành bắt đầu lộ diện. Một phần chênh lệch này đến từ đặc tính thiết kế không cần cấp phép và tính dị cấu trúc của blockchain; phần khác đến từ việc các công cụ hiện có vẫn gói quy trình tương tác blockchain xoay quanh kiểm duyệt thủ công và trung gian front-end.

Quy trình thao tác của tác nhân và chiến lược thuật toán truyền thống

Trước khi phân tích sự chênh lệch giữa cơ sở hạ tầng blockchain và hệ thống tác nhân, cần làm rõ sự khác biệt giữa quy trình thao tác của tác nhân ở mức cao hơn và lõi khác biệt so với các hệ thống thuật toán chuỗi truyền thống.

Sự khác nhau không phải là mức độ tự động hóa, độ phức tạp kỹ thuật, cấu hình tham số, thậm chí cũng không phải là khả năng thích ứng động. Các hệ thống thuật toán truyền thống có thể đạt mức tham số hóa cao: tự phát hiện hợp đồng và token mới, phân bổ vốn giữa nhiều loại chiến lược và thực hiện tái cân bằng dựa trên hiệu suất. Điểm khác biệt cốt lõi nằm ở việc hệ thống có thể xử lý các tình huống chưa từng được dự kiến trước trong giai đoạn xây dựng hay không.

Dù phức tạp đến đâu, các hệ thống thuật toán truyền thống cũng chỉ có thể thực thi logic đã được xác định trước, hướng tới các mẫu (modes) được lập trình ở giai đoạn phát triển. Những hệ thống này cần cấu hình các bộ phân tích (parsers) giao diện dự kiến cho từng loại giao thức, các logic đánh giá được định sẵn để chuyển trạng thái hợp đồng thành ý nghĩa kinh tế, các quy tắc rõ ràng để xác định tín nhiệm và chuẩn mực; và mọi nhánh quyết định đều phải được viết theo luật cứng (hard-coded rules) (dù bản thân thuật toán có thể động và linh hoạt đến đâu). Khi xuất hiện tình huống không khớp với mẫu đã định sẵn, hệ thống sẽ hoặc bỏ qua tình huống đó, hoặc chạy và thất bại ngay. Nó không thể suy luận và ra quyết định trước tình huống lạ; chỉ có thể kiểm tra liệu tình huống hiện tại có phù hợp với một mẫu đã biết hay không.

“Thiết bị cơ khí nuốt vịt” như con này có thể bắt chước hành vi trông như thật, nhưng mọi cử động đều được cài đặt trước.（《Nhà khoa học Mỹ》, tháng 1 năm 1899）

Thuật toán truyền thống khi quét thị trường vay mượn mới có thể nhận diện các hợp đồng triển khai phát ra sự kiện quen thuộc, hoặc khớp với các mẫu nhà máy (factory) đã biết. Nhưng nếu xuất hiện một loại thành phần cơ sở vay mượn mới với giao diện xa lạ, hệ thống sẽ không thể đánh giá nó. Bắt buộc con người phải kiểm tra hợp đồng, hiểu cơ chế vận hành của nó, đánh giá xem liệu nó có nằm trong “cơ hội pool” (tập hợp cơ hội) hay không, và viết logic tích hợp. Chỉ sau khi hoàn tất các bước này, thuật toán mới có thể tương tác với nó. Con người chịu trách nhiệm diễn giải, còn thuật toán chịu trách nhiệm thực thi. Và hệ thống tác nhân dựa trên mô hình cơ sở phá vỡ ranh giới này. Chúng có thể đạt được điều đó thông qua năng lực suy luận đã học:

• Diễn giải các mục tiêu mơ hồ hoặc chưa được chỉ định rõ. Những chỉ lệnh như “tối đa hóa lợi nhuận nhưng tránh rủi ro quá mức” đòi hỏi phải diễn giải: mức nào được xem là rủi ro quá mức? Lợi nhuận và rủi ro nên cân bằng ra sao? Thuật toán truyền thống cần định nghĩa chính xác trước các điều kiện này, trong khi mô hình cơ sở có thể diễn giải ý định, đưa ra phán đoán và tối ưu hóa cách hiểu của chính nó dựa trên phản hồi.

• Khái quát để thích ứng với giao diện mới. Tác nhân có thể đọc mã hợp đồng xa lạ, phân tích tài liệu, hoặc kiểm tra ABI của các giao diện nhị phân ứng dụng chưa từng thấy, rồi suy luận chức năng kinh tế của hệ thống đó. Nó không cần phải xây dựng trước các parser cho từng loại giao thức. Hiện năng lực này vẫn chưa hoàn thiện; tác nhân có thể phán đoán sai, nhưng nó có thể thử tương tác với các hệ thống mà ở giai đoạn phát triển chưa từng được dự kiến.

• Suy luận về mức độ tin cậy và tính chuẩn mực trong điều kiện không chắc chắn. Khi tín hiệu tin cậy mờ nhạt hoặc không đầy đủ, mô hình cơ sở có thể cân nhắc theo xác suất, thay vì áp dụng đơn thuần các quy tắc nhị phân. Hợp đồng thông minh này có phải bản chính thức hay không? Với các bằng chứng hiện có, token này có khả năng cao là hợp pháp không? Thuật toán truyền thống chỉ có hai trạng thái “có quy tắc” hoặc “không có quy tắc”, trong khi tác nhân có thể suy luận dựa trên mức độ tin cậy (confidence).

• Diễn giải sai và tự điều chỉnh thích nghi. Khi gặp tình huống bất ngờ (ví dụ: giao dịch bị revert, đầu ra không khớp kỳ vọng, trạng thái thay đổi giữa mô phỏng và thực thi), tác nhân có thể suy luận nguyên nhân và quyết định cách ứng phó. Ngược lại, thuật toán truyền thống chỉ chạy các khối mã bắt ngoại lệ, phân luồng xử lý cho các ngoại lệ mà không diễn giải ngoại lệ.

Những năng lực này là có thật, nhưng hiện vẫn chưa hoàn thiện. Mô hình cơ sở có thể tạo “ảo giác” (hallucination), diễn giải sai thông tin và đưa ra những phán đoán sai lầm trông có vẻ tự tin. Trong môi trường đối kháng và có liên quan đến tiền (tức là mã có thể kiểm soát hoặc nhận tài sản), “thử tương tác với hệ thống chưa được dự kiến” có thể đồng nghĩa với việc thua lỗ trực tiếp. Điểm cốt lõi của bài viết không phải là các tác nhân hiện đã có thể thực hiện đáng tin cậy các chức năng này, mà là chúng có thể thử theo những cách mà hệ thống truyền thống không thể làm; và trong tương lai, cơ sở hạ tầng có hy vọng làm cho các thử nghiệm này an toàn và đáng tin hơn. Xem hai thứ này như một phổ liên tục thay vì phân loại tuyệt đối sẽ dễ hiểu hơn: một số hệ thống truyền thống đã tích hợp suy luận kiểu học; một số tác nhân cũng có thể dựa vào các quy tắc hard-code ở các nhánh quan trọng. Sự khác nhau của hai bên mang tính định hướng, không phải đối lập nhị phân. Hệ thống tác nhân chuyển nhiều hơn công việc diễn giải, đánh giá và thích nghi vào suy luận khi chạy (runtime), thay vì dự kiến sẵn ở giai đoạn phát triển. Điều này liên quan chặt chẽ đến lập luận về các trở ngại ở phần trước, vì chính thứ tác nhân đang cố gắng làm là điều mà thuật toán truyền thống hoàn toàn né tránh. Thuật toán truyền thống né chi phí khám phá bằng cách do con người chọn tập hợp hợp đồng ở giai đoạn phát triển; né chi phí lớp kiểm soát bằng “white list” do nhà vận hành duy trì; né chi phí dữ liệu bằng cách có parser được đặt sẵn cho các giao thức đã biết; và né chi phí thực thi bằng cách chạy trong phạm vi bảo mật được dự kiến. Con người hoàn thành trước công việc ở mức ngữ nghĩa, tín nhiệm và chiến lược; thuật toán chỉ thực thi trong phạm vi ranh giới đó. Phiên bản sớm của quy trình thao tác tác nhân trên chuỗi có thể tiếp tục mô hình này, nhưng logic cốt lõi là chuyển việc khám phá, đánh giá tín nhiệm và đánh giá chiến lược sang suy luận runtime, thay vì dự kiến sẵn ở giai đoạn phát triển.

Tác nhân có thể sẽ thử khám phá và đánh giá các cơ hội xa lạ, đánh giá tính chuẩn mực của hợp đồng mà không có các quy tắc hard-code, phân tích trạng thái dị cấu trúc mà không có các parser được cài sẵn, và thực thi chiến lược cho các mục tiêu có thể mơ hồ. Và chính tại những bước này, điểm yếu của cơ sở hạ tầng bắt đầu lộ rõ. Trở ngại tồn tại không phải vì tác nhân đang làm việc giống thuật toán nhưng khó hơn, mà vì chúng đang cố làm những việc hoàn toàn khác: vận hành trong một không gian hành vi mở và có thể diễn giải linh hoạt, thay vì trong một không gian đóng kín và đã tích hợp sẵn.

Nơi phát sinh ma sát

Xét về mặt cấu trúc, mâu thuẫn này không xuất phát từ khiếm khuyết của đồng thuận blockchain, mà do cách mà toàn bộ “stack” tương tác xây dựng quanh nó tiến hóa.

Blockchain đảm bảo chuyển trạng thái xác định, đồng thuận về trạng thái cuối cùng và tính xác định cuối cùng. Nhưng nó không mã hóa diễn giải kinh tế, kiểm tra ý định hoặc theo dõi mục tiêu ở cấp giao thức. Các trách nhiệm này từ lâu được đảm nhiệm bởi front-end, ví, indexer và các lớp phối hợp off-chain khác, và trong quy trình luôn có sự tham gia của con người.

Các mô hình tương tác chủ đạo cũng phản ánh thiết kế này, ngay cả với người tham gia chuyên nghiệp: người dùng phổ thông diễn giải trạng thái qua bảng điều khiển (panel), chọn thao tác qua giao diện, ký giao dịch bằng ví — chứ không xác thực kết quả một cách chính thức; các tổ chức giao dịch thuật toán thực hiện tự động hóa thực thi, nhưng vẫn dựa vào việc con người lọc tập hợp giao thức, kiểm tra bất thường và cập nhật logic tích hợp khi giao diện thay đổi. Trong cả hai bối cảnh, giao thức chỉ đảm bảo tính đúng đắn của việc thực thi; còn việc diễn giải ý định, xử lý ngoại lệ và thích ứng cơ hội mới vẫn do con người hoàn thành.

Hệ thống tác nhân nén thậm chí loại bỏ sự phân công này. Chúng bắt buộc phải tái cấu trúc bằng chương trình trạng thái mang ý nghĩa kinh tế, đánh giá liệu mục tiêu có được thúc đẩy hay không và kiểm tra kết quả ngoài việc chỉ ghi các giao dịch đơn giản lên chuỗi. Các gánh nặng này nổi bật hơn trên blockchain, vì tác nhân chạy trong môi trường mở, đối kháng và thay đổi nhanh; các hợp đồng mới, tài sản và đường đi thực thi có thể xuất hiện mà không cần duyệt tập trung. Giao thức chỉ đảm bảo giao dịch được thực thi đúng, không đảm bảo trạng thái kinh tế dễ diễn giải, hợp đồng là bản chính thức, đường đi thực thi khớp với ý định người dùng, hoặc các cơ hội liên quan có thể được phát hiện một cách lập trình.

Chương tiếp theo sẽ phân tích từng giai đoạn của vòng lặp vận hành tác nhân đối với các trở ngại như: phát hiện các hợp đồng và cơ hội hiện có, xác minh tính hợp lệ của chúng, lấy trạng thái có ý nghĩa kinh tế, và thực thi theo mục tiêu.

Chi phí khám phá

Chi phí khám phá phát sinh vì không gian hành vi DeFi liên tục mở rộng trong môi trường mở và không cần cấp phép, trong khi mức liên quan và tính hợp lệ cần được con người lọc thủ công thông qua các lớp xã hội trên chuỗi, thị trường và công cụ. Các giao thức mới được lọc qua thông báo và công bố nghiên cứu; đồng thời cũng được lọc qua các lớp tích hợp front-end, danh sách token, nền tảng phân tích, hình thành thanh khoản, v.v. Qua thời gian, các tín hiệu này thường hình thành một bộ tiêu chuẩn đánh giá có thể vận hành để nhận diện phần nào trong không gian hành vi có giá trị kinh tế và đủ tin cậy, dù quy trình này thường mang tính phi chính thức, không cân bằng và một phần phụ thuộc bên thứ ba cũng như sàng lọc thủ công.

Dù tác nhân có thể lấy dữ liệu đã được lọc và các tín hiệu tin cậy, chúng không có “đường tắt” tự nhiên như khi con người diễn giải các tín hiệu đó. Xét từ góc nhìn trên chuỗi, mọi hợp đồng đã triển khai đều có khả năng được phát hiện là như nhau. Các giao thức hợp lệ, các nhánh rẽ độc hại, triển khai thử nghiệm và dự án bị bỏ rơi — tất cả đều tồn tại dưới dạng bytecode có thể gọi được. Trên chuỗi không gắn nhãn hợp đồng nào là quan trọng hay an toàn.

Xét từ góc nhìn trên chuỗi, mọi hợp đồng đã triển khai đều có khả năng được phát hiện tương đương nhau. Hợp đồng giao thức hợp lệ, hợp đồng nhánh rẽ độc hại, hợp đồng triển khai thử nghiệm và dự án bị bỏ rơi — tất cả đều hiển thị dưới dạng bytecode có thể gọi.

Do đó, tác nhân phải tự xây dựng cơ chế khám phá: quét sự kiện triển khai, nhận diện mô hình giao diện, theo dõi các hợp đồng factory (hợp đồng triển khai hợp đồng khác theo chương trình) và giám sát việc hình thành thanh khoản để xác định hợp đồng nào nên được đưa vào phạm vi ra quyết định. Quá trình này không chỉ là tìm hợp đồng, mà còn là đánh giá liệu nó có đáng được đưa vào không gian hành vi của tác nhân hay không.

Nhận diện hợp đồng ứng viên chỉ là bước đầu tiên. Sau khi được sàng lọc qua khám phá ban đầu, hợp đồng còn cần trải qua quá trình xác minh tính chuẩn mực và tính xác thực được mô tả ở phần tiếp theo. Tác nhân phải xác nhận rằng hợp đồng được phát hiện phù hợp với những gì nó tuyên bố, thì mới có thể đưa nó vào không gian ra quyết định.

Khám phá bị giới hạn bởi chiến lược khác với khám phá mở

Chi phí khám phá không đồng nghĩa với việc chỉ “phát hiện triển khai mới”. Các hệ thống thuật toán đã trưởng thành đã có thể làm điều này trong phạm vi chiến lược của chính chúng. Ví dụ: một “searcher” giám sát sự kiện Uniswap factory và tự động đưa vào các pool thanh khoản mới chính là đang thực hiện khám phá động. Trở ngại nằm ở hai lớp cao hơn: đánh giá hợp đồng được phát hiện có hợp lệ hay không (vấn đề tính chuẩn mực sẽ được thảo luận ở phần tiếp theo); và đánh giá xem nó có phục vụ mục tiêu mở hay không, chứ không chỉ phù hợp với một kiểu chiến lược đã định trước.

Logic khám phá của searcher gắn chặt với chiến lược của họ; nó biết phải tìm mô hình giao diện nào vì chiến lược đã được định nghĩa trước. Còn một tác nhân đảm nhiệm nhiệm vụ rộng hơn như “cơ hội tối ưu theo điều chỉnh rủi ro” không thể chỉ dựa vào bộ lọc suy ra từ chiến lược. Nó phải đối chiếu với chính mục tiêu để đánh giá cơ hội mới gặp: việc này cần phân tích giao diện xa lạ, suy luận chức năng kinh tế và xác định liệu cơ hội đó có nên được đưa vào không gian ra quyết định hay không. Phần này thuộc vấn đề tính tự chủ phổ quát, nhưng blockchain khuếch đại độ khó: mã xa lạ có thể được thực thi trực tiếp, mang theo dòng tiền, và chỉ dựa vào tín hiệu nguyên sinh của giao thức thì khó phân loại.

Ma sát ở lớp kiểm soát

Chi phí ở lớp kiểm soát phát sinh vì danh tính và tính hợp lệ thường được xác định ở ngoài giao thức thông qua sàng lọc, quản trị, tài liệu, giao diện và phán đoán của người vận hành. Trong đa số quy trình hiện tại, con người vẫn là một phần quan trọng của quá trình phán định này. Blockchain đảm bảo thực thi xác định và tính xác định cuối cùng, nhưng không đảm bảo rằng người gọi đang tương tác với hợp đồng mục tiêu đúng như dự định. Việc phán định ý định được “thuê ngoài” cho bối cảnh xã hội, website và sàng lọc thủ công.

Trong quy trình hiện tại, con người dùng lớp niềm tin trên web như một công cụ xác thực không chính thức: tìm tên miền chính thức bằng các nền tảng tổng hợp như DeFiLlama hoặc các tài khoản mạng xã hội đã được dự án chứng nhận, và coi website đó như bản đồ chính thức giữa “khái niệm con người” và địa chỉ hợp đồng. Sau đó, front-end sẽ mã hóa một bộ nguồn chân lý (source of truth) hợp lệ, đánh dấu địa chỉ nào là chính thức, dùng token nào để biểu diễn và những cổng vào nào an toàn.

1789 của người Thổ Nhĩ Kỳ cơ khí (Mechanical Turk) là một cỗ máy chơi cờ; bề ngoài trông như tự vận hành, nhưng thực tế phụ thuộc vào một người điều khiển thủ công giấu bên trong. (Thư viện Đại học Humboldt)

Mặc định, tác nhân sẽ không diễn giải nhãn nhận diện thương hiệu, tín hiệu xã hội đã được xác thực hoặc khái niệm “tính chính thức” thông qua bối cảnh xã hội. Chúng ta có thể cung cấp cho tác nhân dữ liệu đầu vào đã được lọc từ các tín hiệu đó, nhưng để chuyển nó thành các giả định tin cậy ổn định, có thể thực thi được bằng máy, thì cần một danh bạ (registry), luật chiến lược hoặc logic xác minh rõ ràng. Người vận hành có thể cấu hình cho tác nhân danh sách trắng được chọn lọc, địa chỉ đã xác thực và chính sách tin cậy. Vấn đề không phải là bối cảnh xã hội hoàn toàn không thể lấy được, mà là việc duy trì liên tục các “tấm chắn” bảo vệ đó trong một không gian hành vi đang mở rộng động sẽ tạo ra gánh nặng vận hành rất lớn; hơn nữa khi các tấm chắn này bị thiếu hoặc không hoàn thiện thì tác nhân thiếu các cơ chế xác thực dự phòng mà con người vẫn dùng vô thức.

Hệ quả thực tế của việc thiếu năng lực phán định tin cậy đã thể hiện trong các hệ thống tác nhân điều khiển trên chuỗi. YouTube influencer Orangie (blogger mã hóa kiêm người nổi tiếng) từng gặp trường hợp tác nhân chuyển tiền vào một hợp đồng “bẫy mật ong” (honey pot). Trong một sự kiện khác, một tác nhân tên Lobstar Wilde do lỗi trạng thái hoặc ngữ cảnh đã diễn giải sai trạng thái địa chỉ, rồi chuyển lượng lớn token dư sang một địa chỉ “xin tiền” (demanding address) trên mạng. Những ví dụ này không phải luận cứ cốt lõi của bài viết, nhưng chúng minh họa trực quan rằng sai lầm trong phán định tin cậy, diễn giải trạng thái và chiến lược thực thi có thể dẫn trực tiếp đến thiệt hại tài chính.

Nhận diện hợp đồng chính thức không phải là chức năng nguyên sinh của giao thức

Vấn đề không phải vì hợp đồng khó được phát hiện, mà vì trên chuỗi thường không tồn tại khái niệm nguyên sinh “đây là hợp đồng chính thức của một ứng dụng X”. Sự thiếu hụt này là một phần đặc tính của hệ thống không cần cấp phép, chứ không hẳn là lỗi thiết kế; nhưng nó vẫn tạo ra bài toán phối hợp khó khăn cho các hệ thống tự chủ. Phần của vấn đề đến từ đặc tính kiến trúc của hệ thống mở với danh tính chuẩn yếu; phần khác đến từ việc danh bạ, tiêu chuẩn và cơ chế phân phối tín nhiệm vẫn chưa trưởng thành. Nếu một tác nhân muốn tương tác với Aave v3, nó phải phán định những địa chỉ nào là bản chính thức (pool vốn, bộ cấu hình/configurator, bên cung cấp dữ liệu, v.v.), và các địa chỉ đó là hợp đồng bất biến, hợp đồng có thể nâng cấp qua proxy hay đang ở trạng thái chờ thực thi thay đổi theo đề xuất quản trị.

Con người giải quyết vấn đề này thông qua tài liệu, giao diện front-end và mạng xã hội, còn tác nhân phải xác minh thông tin sau để phán định:

• Chế độ proxy và hợp đồng triển khai tương ứng (implementation)

• Quyền quản trị và hợp đồng time-lock

• Cụm module cập nhật tham số do quản trị điều khiển

• Mức độ khớp bytecode / ABI giữa các hợp đồng triển khai đã biết

Khi thiếu danh bạ chính thức, “tính chính thức” trở thành một bài toán suy luận. Điều đó đồng nghĩa tác nhân không thể coi địa chỉ hợp đồng là cấu hình tĩnh. Chúng phải hoặc tiếp tục duy trì danh sách trắng đã được xác thực; hoặc trong lúc chạy, suy luận lại chuẩn mực hợp đồng bằng cách kiểm tra proxy và giám sát quản trị; hoặc gánh rủi ro tương tác với các hợp đồng bị bỏ rơi, bị tấn công hoặc hợp đồng giả mạo. Trong phần mềm truyền thống và cơ sở hạ tầng thị trường, danh tính dịch vụ thường được neo vào không gian tên, chứng chỉ và cơ chế kiểm soát truy cập do tổ chức duy trì. Ngược lại, trên chuỗi, một hợp đồng có thể gọi được, chức năng hoạt động đúng, nhưng từ góc nhìn của bên gọi, về phương diện kinh tế hoặc nghiệp vụ thì nó không nhất thiết là bản chính thức.

Vấn đề tính xác thực của token và metadata là bản chất tương tự

Token dường như tự mô tả thông tin, nhưng metadata của nó lại không có thẩm quyền; nó chỉ là dữ liệu byte mà hợp đồng trả về từ mã hợp đồng. Ví dụ điển hình là Wrapped Ether (WETH). Trong các hợp đồng WETH được dùng rộng rãi, chúng xác định rõ:

Các thông tin này trông có vẻ đại diện cho danh tính, nhưng thực ra không phải. Bất kỳ hợp đồng nào cũng có thể trả về các nội dung sau:

• symbol() = “WETH”

• decimals() = 18

• name() = “Wrapped Ether”

Và triển khai đúng hoàn toàn cùng chuẩn giao diện token ERC-20. name(), symbol() và decimals() chỉ là các hàm public chỉ đọc (read-only) và nội dung trả về hoàn toàn do bên triển khai (deployer) thiết lập. Thực tế, trên Ethereum đã có gần 200 loại token có tên đều là “Wrapped Ether”, ký hiệu đều là “WETH”, độ chia đều là 18 chữ số thập phân. Nếu không tra CoinGecko hoặc Etherscan, bạn có phân biệt được đâu là “WETH” bản chính thức không? (Đáp án là mục thứ 78 trong danh sách.)

Trên Ethereum có gần 200 token có tên “Wrapped Ether” và ký hiệu là “WETH”. Nếu không dựa vào nền tảng bên thứ ba, bạn có thể biết đâu mới là WETH chính gốc không?

Đó là tình cảnh mà tác nhân phải đối mặt. Blockchain không xác thực tính duy nhất, cũng không đối chiếu với bất kỳ danh bạ nào để kiểm chứng và cũng chẳng quan tâm đến điều đó. Bạn hôm nay có thể triển khai 500 hợp đồng; tất cả đều trả về metadata y hệt. Trên chuỗi cũng tồn tại một vài cách phán đoán theo kinh nghiệm (ví dụ: so sánh số dư ETH và tổng cung, truy vấn độ sâu thanh khoản của các DEX phi tập trung phổ biến, kiểm tra xem nó có được giao thức cho vay mượn liệt kê làm tài sản thế chấp hay không), nhưng không có cách nào cung cấp bằng chứng tuyệt đối không thể chối cãi. Mỗi phương pháp thì hoặc dựa vào giả định theo ngưỡng (không ai có thể giả mạo thanh khoản cặp quy mô hàng tỷ), hoặc mang tính đệ quy: trước tiên cần xác thực tính chuẩn mực của các hợp đồng khác.

Như một mê cung, việc xác định “đường đi thật sự” trên chuỗi cần hướng dẫn từ bên ngoài; không có bất kỳ tín hiệu chuẩn mực nào. (Bảo tàng và phòng trưng bày Birmingham)

Đó là lý do token list và registry tồn tại như lớp lọc ngoài chuỗi. Chúng cung cấp một cơ chế để ánh xạ khái niệm “WETH” tới một địa chỉ cụ thể; đây cũng là lý do ví và front-end duy trì danh sách trắng hoặc dựa vào các bộ tổng hợp đáng tin. Đối với tác nhân, vấn đề cốt lõi không chỉ là metadata không đáng tin cậy, mà còn là danh tính chuẩn mực thường được xác lập ở tầng xã hội hoặc tổ chức, chứ không phải là dạng nguyên sinh của giao thức. Định danh duy nhất đáng tin cậy trên chuỗi là địa chỉ hợp đồng; tuy nhiên để ánh xạ ý định dễ hiểu của con người (như “đổi sang USDC”) tới đúng địa chỉ, vẫn phụ thuộc rất nhiều vào cơ chế lọc, danh bạ, danh sách trắng hoặc các lớp tin cậy khác ngoài giao thức.

Ma sát dữ liệu

Một tác nhân tối ưu giữa nhiều giao thức DeFi cần trừu tượng hóa từng cơ hội thành một đối tượng kinh tế thống nhất: lợi suất (yield), độ sâu thanh khoản, tham số rủi ro, cấu trúc phí, nguồn dữ liệu oracle, v.v. Xét từ một góc độ nào đó, đây là một bài toán tích hợp hệ thống thường gặp. Nhưng trên blockchain, gánh nặng này bị khuếch đại mạnh do sự dị cấu trúc của giao thức, rủi ro dòng tiền trực tiếp, việc ghép trạng thái từ nhiều lời gọi, và do tầng cơ sở thiếu một economic schema thống nhất. Và chính những thông tin này là điều cần thiết để so sánh cơ hội, cấu hình mô phỏng và giám sát rủi ro.

Ở cấp giao thức, blockchain thường không lộ ra các đối tượng kinh tế được tiêu chuẩn hóa; nó chỉ lộ ra các slot lưu trữ, nhật ký sự kiện và giá trị trả về của hàm. Vì vậy, đối tượng kinh tế phải được suy ra hoặc tái cấu trúc từ đó. Giao thức chỉ đảm bảo lời gọi hợp đồng trả về đúng giá trị trạng thái, nhưng không đảm bảo rằng giá trị đó ánh xạ rõ ràng đến các khái niệm kinh tế có thể hiểu được; cũng không đảm bảo cùng một khái niệm có thể truy cập qua các giao diện nhất quán giữa các giao thức khác nhau.

Do đó, các khái niệm trừu tượng như thị trường, vị thế, hệ số sức khỏe… không phải là các thành phần nguyên sinh của giao thức; chúng được các indexer, nền tảng phân tích, front-end và API tái cấu trúc ngoài chuỗi để chuẩn hóa trạng thái của các giao thức dị cấu trúc thành một lớp trừu tượng có thể sử dụng. Người dùng con người thường chỉ nhìn thấy lớp dữ liệu được chuẩn hóa này; tác nhân cũng có thể dùng nó, nhưng vì vậy sẽ kế thừa schema của bên thứ ba, giả định độ trễ và giả định tin cậy. Nếu không, tác nhân phải tự tái cấu trúc logic trừu tượng đó.

Vấn đề này càng trở nên trầm trọng hơn qua từng loại giao thức. Giá trị suất phần của quỹ vault (vault), hệ số thế chấp của thị trường cho vay, độ sâu thanh khoản của pool DEX, tỷ lệ phần thưởng cho staking hợp đồng… đều là các chỉ số nền tảng mang ý nghĩa kinh tế, nhưng không có cái nào được lộ ra thông qua một giao diện tiêu chuẩn. Mỗi hệ giao thức có cách đọc riêng, định dạng struct khác nhau và các quy ước về đơn vị; ngay cả cùng một loại, cách hiện thực cũng có thể khác nhau hoàn toàn.

Thị trường cho vay: ví dụ điển hình của việc đọc bị phân mảnh

Thị trường cho vay thể hiện rõ vấn đề này. Các khái niệm kinh tế nhìn chung tương tự và mang tính phổ quát, ví dụ: thanh khoản cung cấp và thanh khoản cho vay, lãi suất, hệ số thế chấp, trần hạn mức, ngưỡng thanh lý… nhưng đường đi để đọc dữ liệu lại hoàn toàn khác nhau.

Lấy Aave v3 làm ví dụ: quá trình liệt kê thị trường và đọc trạng thái tài sản dự trữ là tách rời thành các bước, quy trình điển hình như sau:

Thông qua các phương thức sau để liệt kê tài sản dự trữ

Hàm này sẽ trả về một mảng các địa chỉ token.

Đối với từng loại tài sản, thông qua các cách sau để lấy dữ liệu nền tảng về thanh khoản và lãi suất:

Lời gọi này sẽ trả về một struct; chỉ một lần gọi đã có thể lấy dữ liệu bao gồm tổng lượng thanh khoản, chỉ số lãi suất và dấu cấu hình, ví dụ như:

Ngược lại, trong Compound v3 (Comet), mỗi lần triển khai chỉ tương ứng với một thị trường duy nhất (như USDC, USDT, ETH, v.v.), và không tồn tại một struct dự trữ thống nhất. Vì vậy, cần nhiều lần gọi hàm để ghép thành dữ liệu snapshot thị trường đầy đủ:

Sử dụng nền tảng cơ bản

Tổng cộng

Lãi suất

Cấu hình tài sản thế chấp

Các tham số cấu hình toàn cục

Mỗi lần gọi chỉ trả về một đoạn khác nhau của trạng thái kinh tế. “Thị trường” không phải là đối tượng hạng nhất; nó là cấu trúc suy luận do bên gọi tự ghép lại.

Xét từ góc nhìn tác nhân, hai giao thức này đều thuộc loại thị trường cho vay. Nhưng xét từ góc nhìn tích hợp, hệ thống lấy dữ liệu của hai bên hoàn toàn khác nhau về cấu trúc. Không tồn tại một cấu trúc dữ liệu phổ quát như sau:

Ngược lại, tác nhân phải thực hiện theo các cách liệt kê tài sản khác nhau cho từng giao thức, ghép dữ liệu trạng thái qua nhiều lần gọi, thống nhất đơn vị đo và quy tắc quy đổi, đồng thời phối hợp giữa giá trị suy ra và dữ liệu nền lộ ra trực tiếp.

Phân mảnh gây trễ và rủi ro bất nhất

Ngoài sự không thống nhất về cấu trúc, sự phân mảnh này còn tạo ra rủi ro trễ và bất nhất. Do trạng thái kinh tế không được lộ ra dưới dạng một đối tượng “thị trường” đơn nguyên tử duy nhất, tác nhân phải gửi nhiều lần lời gọi thủ tục từ xa (RPC) đến nhiều hợp đồng để tái dựng một bản snapshot trạng thái. Mỗi lần gọi thêm sẽ làm tăng độ trễ, kích hoạt xác suất bị giới hạn bởi hạn mức giao diện (rate limiting) và tăng rủi ro bất nhất do block. Trong môi trường biến động thị trường, khi tính toán xong lãi suất theo cung, tỷ lệ sử dụng vốn có thể đã thay đổi; nếu không khóa theo độ cao block, tham số cấu hình và tổng lượng thanh khoản có thể không đến từ cùng một block. Người dùng con người giải quyết vấn đề này một cách ngầm nhờ lớp cache front-end và backend tổng hợp; còn tác nhân gọi trực tiếp các RPC nguyên gốc thì phải xử lý tường minh vấn đề đồng bộ dữ liệu, yêu cầu theo lô (batch) và tính nhất quán theo thời gian. Vì vậy, dữ liệu không chuẩn hóa không chỉ là bất tiện khi tích hợp, mà còn là ràng buộc đối với hiệu năng, cơ chế đồng bộ và tính đúng đắn của việc thực thi.

Thiếu một chuẩn quy định cách truy cập dữ liệu kinh tế thống nhất có nghĩa là, dù các giao thức khác nhau có thể thực hiện gần như tương tự chức năng tài chính nền tảng, cách lộ trạng thái vẫn riêng biệt cho từng hợp đồng và phụ thuộc vào logic kết hợp. Chính sự khác biệt cấu trúc này là nguyên nhân cốt lõi của ma sát dữ liệu.

Dòng dữ liệu tiềm năng không khớp

Truy cập trạng thái kinh tế trên blockchain về bản chất là kiểu “kéo” (pull), ngay cả khi tín hiệu thực thi có thể được đẩy theo luồng (streaming). Hệ thống bên ngoài cần chủ động truy vấn node để lấy trạng thái cần thiết, thay vì nhận những bản cập nhật liên tục và được cấu trúc hóa. Mô hình này phản ánh chức năng cốt lõi của blockchain — xác thực theo nhu cầu (on-demand verification), chứ không phải duy trì một cái nhìn liên tục ở cấp ứng dụng.

Trên chuỗi cũng có các thành phần nền tảng theo kiểu “đẩy” (push). WebSocket subscription có thể đẩy realtime các block mới và nhật ký sự kiện, nhưng chúng không bao gồm trạng thái lưu trữ mang phần lớn ý nghĩa kinh tế, trừ khi giao thức chủ động chọn ghi những thông tin đó như nhật ký dư thừa. Tác nhân không thể trực tiếp lấy tỷ lệ sử dụng thị trường cho vay, dự trữ pool hoặc hệ số sức khỏe vị thế thông qua subscription trên chuỗi. Những giá trị này được lưu trong không gian lưu trữ của hợp đồng, và hầu hết giao thức không cung cấp cơ chế nguyên sinh để đẩy thay đổi lưu trữ đến người dùng hạ nguồn. Cách khả thi nhất hiện nay là subscribe header của các block mới và truy vấn lại trạng thái lưu trữ ở mỗi block — dù được kích hoạt bởi sự kiện streaming, việc truy cập trạng thái vẫn về bản chất là kiểu pull. Nhật ký chỉ cho biết dữ liệu có thể đã thay đổi, nhưng không mã hóa trạng thái kinh tế cuối cùng; việc tái cấu trúc trạng thái vẫn cần phải đọc và truy cập rõ ràng các trạng thái lịch sử.

Hệ thống tác nhân lại phù hợp hơn với luồng dữ liệu theo hướng ngược lại. Tác nhân không cần polling hàng trăm hợp đồng; thay vào đó, nó có thể nhận các bản cập nhật trạng thái được cấu trúc hóa và đã được tính toán trước, rồi đẩy trực tiếp vào môi trường runtime của nó (ví dụ: cập nhật tỷ lệ sử dụng, hệ số sức khỏe hoặc biến động vị thế). Kiến trúc đẩy có thể giảm truy vấn dư thừa, hạ độ trễ từ thời điểm trạng thái thay đổi đến khi tác nhân nhận biết, và cho phép lớp trung gian đóng gói trạng thái thành các bản cập nhật có ngữ nghĩa rõ ràng, thay vì bắt tác nhân tự diễn giải ý nghĩa từ lưu trữ nguyên thủy.

Việc chuyển đổi sang mô hình này không hề dễ dàng. Nó đòi hỏi hạ tầng subscription, logic lọc mức liên quan, và quy chuẩn hóa các sự kiện kinh tế khi trạng thái lưu trữ thay đổi sao cho có thể chuyển đổi thành các thao tác mà tác nhân thực thi được. Nhưng khi tác nhân trở thành một người tham gia online liên tục thay vì chỉ truy vấn gián đoạn, những vấn đề kém hiệu quả của mô hình pull — như giới hạn giao diện, chi phí đồng bộ và truy vấn lặp giữa các tác nhân khác nhau — sẽ ngày càng trở nên nghiêm trọng. Việc coi hạ tầng như dành cho các “người tiêu dùng liên tục” thay vì “khách hàng ngắt quãng” có lẽ sẽ phù hợp hơn với cách vận hành của các hệ thống tự chủ.

Liệu hạ tầng đẩy có thực sự tốt hơn hay không, vẫn chưa có kết luận. Luồng dữ liệu thay đổi toàn lượng sẽ mang theo bài toán lọc; tác nhân vẫn cần quyết định thông tin nào liên quan, qua đó lại tái tạo logic pull ở một lớp khác. Điểm cốt lõi không phải là pull-scheme vốn sai, mà là thiết kế hiện tại chưa cân nhắc nhu cầu sử dụng máy móc mang tính bền vững (persistent machine users). Khi quy mô dùng tác nhân tăng lên, các phương án thay thế đáng được khám phá.

Ma sát khi thực thi

Ma sát khi thực thi phát sinh vì hiện nay nhiều tầng tương tác đóng gói việc chuyển đổi ý định, phê duyệt giao dịch và kiểm tra kết quả trong một quy trình lấy front-end, ví và giám sát thủ công làm trung tâm. Với bối cảnh người dùng phổ thông và quyết định mang tính chủ quan, cơ chế giám sát này thường do con người thực hiện. Còn đối với hệ thống tự chủ, các chức năng này phải được hình thức hóa và mã hóa trực tiếp. Blockchain có thể đảm bảo thực thi xác định theo logic hợp đồng, nhưng không đảm bảo giao dịch khớp ý định người dùng, tuân thủ ràng buộc rủi ro hoặc đạt kết quả kinh tế kỳ vọng. Trong quy trình hiện tại, front-end và con người đã bù đắp vào khoảng trống đó.

Front-end sẽ điều phối chuỗi thao tác (đổi, cấp phép/ủy quyền, nạp vào, vay mượn), ví cung cấp điểm kiểm tra cuối cùng “duyệt rồi gửi”. Người dùng hoặc người thao tác thường thực hiện đánh giá chiến lược một cách không chính thức ở bước cuối. Họ thường đưa ra quyết định khi thông tin còn chưa đầy đủ: giao dịch có an toàn không, kết quả báo giá có chấp nhận được không. Nếu giao dịch thất bại hoặc xuất hiện kết quả bất ngờ, người dùng sẽ thử lại, điều chỉnh slippage, đổi đường đi hoặc thậm chí từ bỏ thao tác. Hệ thống tác nhân loại bỏ con người khỏi vòng lặp thực thi này, nghĩa là hệ thống phải thay thế ba nhóm chức năng của con người bằng logic nguyên sinh của máy:

1. Biên dịch ý định (intent compilation). Những mục tiêu của con người như “cấu hình stablecoin của tôi vào kênh lợi nhuận tối ưu sau điều chỉnh theo rủi ro” phải được biên dịch thành một kế hoạch hành động cụ thể: chọn giao thức nào, thị trường nào, đường đi của token nào, quy mô thao tác, cách cấp phép và thứ tự thực thi. Với con người, quá trình này được front-end thực hiện ngầm; với tác nhân, quá trình đó phải được thực hiện tường minh bằng hình thức hóa.

2. Thực thi chiến lược. Bấm “gửi giao dịch” không chỉ là hành động ký, mà còn là kiểm tra ngầm rằng giao dịch phù hợp với các ràng buộc: mức chịu slippage, trần đòn bẩy, hệ số sức khỏe tối thiểu, hợp đồng trong whitelist hoặc “cấm hợp đồng có thể nâng cấp”, v.v. Tác nhân cần mã hóa các ràng buộc chiến lược thành các quy tắc có thể được máy kiểm chứng:

Hệ thống thực thi phải xác minh rằng đồ thị quan hệ lời gọi (call graph) dự kiến sẽ thực thi phù hợp với các quy tắc này trước khi phát/broadcast giao dịch.

1. Xác minh kết quả. Giao dịch được ghi lên chuỗi không đồng nghĩa với việc nhiệm vụ đã hoàn thành. Một giao dịch dù thực thi thành công vẫn có thể không đạt mục tiêu: slippage có thể vượt quá mức dung nạp; hoặc do giới hạn hạn mức mà không đạt được quy mô vị thế theo mục tiêu; hoặc lãi suất có thể thay đổi giữa mô phỏng và lúc lên chuỗi. Con người sẽ kiểm tra một cách không chính thức sau giao dịch qua giao diện front-end; còn tác nhân phải đánh giá điều kiện trạng thái sau thực thi theo cách có thể chương trình hóa:

Điều này đặt ra yêu cầu cao hơn đối với việc kiểm tra mức độ hoàn thành (completeness check); không thể chỉ dừng ở việc xác nhận giao dịch đã được lên chuỗi. Kiến trúc lấy ý định làm trung tâm có thể cung cấp một phần giải pháp, chuyển nhiều gánh nặng về “cách thực thi” từ tác nhân sang cho một bộ giải (solver) chuyên nghiệp. Tác nhân không còn gửi dữ liệu lời gọi thô; thay vào đó, nó broadcast “ý định thực thi đã được ký” và chỉ định các ràng buộc dựa trên kết quả; bộ giải hoặc cơ chế ở tầng giao thức phải thỏa các ràng buộc này thì việc thực thi mới được coi là hợp lệ.

Workflow nhiều bước và các dạng lỗi

Một phần lớn quá trình thực thi trong DeFi vốn dĩ là nhiều bước. Một thao tác cấu hình lợi suất (yield configuration) có thể cần thực hiện tuần tự: cấp phép → đổi → nạp vào → vay mượn → staking. Một số bước có thể là giao dịch độc lập, còn các bước khác có thể được đóng gói thực thi qua batch call hoặc thông qua route contract. Con người có thể chấp nhận việc quy trình chưa hoàn tất, rồi quay lại thao tác trên giao diện; còn tác nhân cần một điều phối quy trình có tính xác định: nếu bất kỳ bước nào thất bại, tác nhân phải quyết định là thử lại, đổi đường đi, hoàn tác (rollback) hay tạm dừng thực thi.

Điều này tạo ra các dạng lỗi mới thường bị che giấu trong workflow thao tác của con người:

• Trôi trạng thái giữa lúc quyết định và lúc lên chuỗi: Trong thời gian mô phỏng và thực tế khi chờ lên chuỗi, lãi suất, mức sử dụng hoặc thanh khoản có thể thay đổi. Con người có thể chấp nhận dao động này, còn tác nhân phải thiết lập phạm vi chấp nhận được và thực thi nghiêm ngặt trong phạm vi đó.

• Thực thi không nguyên tử và khớp một phần: Một số thao tác có thể trải dài trên nhiều giao dịch, hoặc chỉ tạo ra một phần kết quả kỳ vọng. Tác nhân phải theo dõi trạng thái trung gian và xác nhận trạng thái cuối cùng có khớp với mục tiêu hay không.

• Rủi ro ủy quyền额度 và phê duyệt: Con người thường ký cấp phép thông qua thao tác quen thuộc trên giao diện; còn tác nhân phải đưa phạm vi ủy quyền (hạn mức, bên chi tiêu, thời hạn hiệu lực) vào chính sách an toàn để suy luận, chứ không xử lý như chỉ một bước thao tác giao diện.

• Chọn đường đi và chi phí thực thi ngầm: Con người dựa vào công cụ route và cấu hình mặc định của giao diện; tác nhân phải đưa slippage, rủi ro MEV (giá trị trích xuất bởi miner) , Gas fee và độ “giật giá” (price impact) vào mô hình hóa hàm mục tiêu.

Thực thi: một bài toán điều khiển “nguyên sinh của máy”

Luận điểm cốt lõi của ma sát khi thực thi là: tầng tương tác DeFi lấy chữ ký ví của con người làm vòng kiểm soát cuối cùng. Hiện tại, việc kiểm tra ý định, đánh giá mức dung nạp rủi ro và các kiểm tra không chính thức kiểu “có vẻ hợp lý không” đều tập trung ở bước này. Khi loại bỏ sự tham gia của con người, việc thực thi trở thành một bài toán điều khiển: tác nhân phải chuyển mục tiêu thành một chuỗi thao tác, tự động thực thi ràng buộc chiến lược, và kiểm tra kết quả trong điều kiện bất định. Thử thách này tồn tại trong nhiều hệ thống tự chủ, nhưng trong môi trường blockchain nó đặc biệt khắc nghiệt vì việc thực thi trực tiếp liên quan đến tiền, có thể gọi các hợp đồng xa lạ theo kiểu composable, và phải đối mặt với biến đổi trạng thái mang tính đối kháng. Con người đưa ra quyết định dựa trên kinh nghiệm và sửa sai bằng thử nghiệm; còn tác nhân phải hoàn thành công việc tương tự ở tốc độ của máy theo cách chương trình hóa, thường phải đối diện với không gian thao tác biến động. Vì vậy, quan điểm cho rằng tác nhân “chỉ cần gửi giao dịch” đã đánh giá thấp độ khó rất nhiều. Gửi giao dịch bản thân chỉ là một phần đơn giản; thứ thật sự thiếu là toàn bộ công việc do giao diện và con người đảm nhiệm: biên dịch ý định, đảm bảo an toàn và kiểm tra mức độ hoàn thành mục tiêu.

Kết luận

Blockchain ngay từ khi được thiết kế đã không cung cấp sẵn lớp ngữ nghĩa và lớp phối hợp cần thiết cho các tác nhân thông minh tự chủ. Mục tiêu thiết kế của nó là đảm bảo thực thi xác định và đồng thuận chuyển đổi trạng thái trong môi trường đối kháng. Các tầng tương tác phát triển dựa trên nền tảng này luôn xoay quanh người dùng con người: diễn giải trạng thái qua giao diện, chọn thao tác qua front-end, và kiểm tra thủ công để xác nhận kết quả.

Hệ thống tác nhân đã đảo lộn kiến trúc này. Chúng loại bỏ vai trò của người diễn giải, người phê duyệt và người kiểm nghiệm khỏi quy trình, đồng thời yêu cầu các chức năng này phải được “nguyên sinh hóa” cho máy móc. Sự chuyển đổi này phơi bày ma sát mang tính cấu trúc ở bốn chiều: khám phá, phán định tin cậy, thu thập dữ liệu và điều phối thực thi. Những ma sát này không phát sinh vì việc thực thi là không thể, mà vì cơ sở hạ tầng xung quanh blockchain trong đa số tình huống vẫn mặc định có sự tham gia của con người ở các khâu diễn giải trạng thái và gửi giao dịch.

Việc lấp các khoảng trống này có thể cần xây dựng cơ sở hạ tầng mới trong nhiều tầng kỹ thuật: tạo middleware chuẩn hóa trạng thái kinh tế xuyên giao thức thành định dạng có thể đọc bởi máy; cung cấp các thành phần ngữ nghĩa cơ bản như vị thế, hệ số sức khỏe, tập hợp cơ hội… thay vì chỉ dữ liệu lưu trữ nguyên thủy; các dịch vụ index hoặc mở rộng RPC đóng vai trò lập chỉ mục và trả về dữ liệu theo ngữ nghĩa; xây registry để ánh xạ hợp đồng chính thức và xác thực tính xác thực của token; và một framework thực thi có thể mã hóa ràng buộc chiến lược, xử lý workflow nhiều bước và kiểm tra mục tiêu hoàn thành theo kiểu chương trình hóa. Một phần khoảng trống bắt nguồn từ đặc tính cấu trúc của hệ thống không cần cấp phép: triển khai mở, danh tính chuẩn yếu và các giao diện dị cấu trúc; phần khác lại bị giới hạn bởi các công cụ, tiêu chuẩn và thiết kế động lực hiện có. Khi quy mô sử dụng tác nhân tăng lên, các giao thức cạnh tranh để tối ưu sự tiện lợi cho việc tích hợp hệ thống tự chủ, do đó các vấn đề này có thể được giảm nhẹ.

Khi các hệ thống tự chủ bắt đầu quản lý vốn, thực thi chiến lược và tương tác trực tiếp với các ứng dụng trên chuỗi, các giả định kiến trúc được nhúng sẵn trong tầng tương tác hiện tại ngày càng trở nên nổi bật. Phần lớn các ma sát được mô tả trong bài viết xuất phát từ việc các công cụ blockchain và mô hình tương tác phát triển quanh workflow trung gian con người; một phần khác là kết quả tự nhiên của tính mở, tính dị cấu trúc và môi trường đối kháng trong hệ thống không cần cấp phép; và một số khác là các vấn đề phổ quát mà hệ thống tự chủ thường đối mặt trong môi trường phức tạp.

Thách thức cốt lõi không phải là khiến tác nhân thực hiện chữ ký giao dịch, mà là cung cấp cho nó một lộ trình đáng tin cậy: tức là cung cấp các chức năng liên quan đến ngữ nghĩa, tin cậy và chiến lược — vốn trước đây được hoàn thành cùng nhau bởi phần mềm và đánh giá của con người — giữa trạng thái blockchain gốc và thực tế vận hành.