
Đừng dừng lại ở bề mặt của câu chuyện ý định: thiếu bộ giải (Solver), chỉ khiến ý định ngày càng trở nên tập trung hơn
Tuyển chọn TechFlowTuyển chọn TechFlow

Đừng dừng lại ở bề mặt của câu chuyện ý định: thiếu bộ giải (Solver), chỉ khiến ý định ngày càng trở nên tập trung hơn
Nếu chúng ta muốn bước vào kỷ nguyên ý định của tiền mã hóa, chúng ta sẽ cần thêm nhiều bộ giải hơn.
Tác giả: Arjun Chand
Biên dịch: TechFlow

Tại LI.FI, chúng tôi từng thảo luận rằng mặc dù các cầu nối dựa trên ý định có thể cải thiện trải nghiệm người dùng, nhưng do thiếu solver (bộ giải), chúng có nguy cơ trở thành giải pháp tập trung.
Việc không đủ solver để thực hiện ý định người dùng là một vấn đề nổi tiếng. Dù nghe có vẻ đơn giản khi chỉ cần thêm nhiều solver hơn, thực tế thì vấn đề này vẫn chưa được giải quyết.
Chúng tôi nhận ra rằng với ý định, solver chính là chìa khóa. Nếu không giải quyết được bài toán thu hút thêm solver, tương lai chúng ta xây dựng có thể rất giống ngành tài chính truyền thống – một tương lai nơi dòng lệnh tập trung vào tay một vài thực thể.
Trong bài viết này, chúng tôi sẽ định nghĩa cấu trúc giao thức dựa trên ý định và khám phá các giải pháp mới nổi trên thị trường, những giải pháp có tiềm năng giải quyết tình trạng khan hiếm solver bằng cách xử lý điểm nghẽn của solver.
Hãy cùng tìm hiểu!
Giới thiệu về Ý định
Lưu ý: Nếu bạn đã quen thuộc với khái niệm ý định hoặc đã đọc bài viết trước đây của chúng tôi, vui lòng bỏ qua phần này.
Ý định thay đổi cách hoạt động của giao dịch, tập trung vào mục tiêu cuối cùng hay “ý định” của người dùng thay vì các bước cụ thể để đạt được mục tiêu đó (sẽ nói rõ hơn sau). Thiết kế dựa trên ý định mang lại hai lợi ích chính:
-
Trải nghiệm người dùng — Trải nghiệm cảm giác liền mạch và thường rất nhanh. Người dùng đưa ra một ý định, solver xử lý phần còn lại. Việc trừ phí gas tự động và các tính năng khác giúp trải nghiệm mượt mà hơn nhiều so với giao dịch thông thường. Tính thanh khoản tức thời (JIT) có nghĩa là không còn phải chờ đợi vài phút cho giao dịch hoàn tất. Nhìn chung, trải nghiệm dựa trên ý định ít phức tạp hơn đối với người dùng, mang đến trải nghiệm "một cú nhấp chuột" mà hầu hết ứng dụng Web2 đều cung cấp.
-
Hiệu quả thực thi — Solver thường là các nhà tạo lập thị trường chuyên nghiệp hoặc đội ngũ giao thức, xử lý việc thực thi giao dịch cho người dùng. Quan điểm ở đây là các solver chuyên nghiệp có thể xây dựng giao dịch hiệu quả nhất trên chuỗi tốt hơn hợp đồng AMM (thị trường tự động) cơ bản hoặc người dùng cuối vận hành trên nhiều ứng dụng. Gom nhóm giao dịch và các tính năng khác như khớp lệnh làm cho việc thực thi ý định hiệu quả hơn về mặt vốn. Đối với người dùng: không còn lỗi ngu ngốc, lãng phí tài nguyên và trải nghiệm chuỗi khó chịu. Đối với ứng dụng: không còn phụ thuộc vào các hợp đồng đơn giản, kém hiệu quả về gas để xử lý các đường đi giao dịch phức tạp. Đối với các nhà cung cấp thanh khoản (LP): không còn thanh khoản bị bỏ hoang trong các hợp đồng chuỗi lỗi thời.
Thiết kế dựa trên ý định là nền tảng cốt lõi để đạt được trừu tượng hóa chuỗi — tức là xây dựng các ứng dụng tương tác với nhiều chuỗi nhưng cảm giác như một trải nghiệm "tiền mã hóa" duy nhất, liên kết.
Với ý định, solver là yếu tố then chốt
Các giao thức dựa trên ý định có ba thành phần chính:
-
Diễn đạt ý định — Người dùng xác định kết quả mong muốn trên ứng dụng. Ví dụ, trong một ứng dụng cầu nối, người dùng có thể nói họ muốn chuyển 1 ETH từ Arbitrum sang Optimism.
-
Thực thi ý định — Các solver cạnh tranh trong cuộc đấu giá để xác định phương pháp hiệu quả nhất nhằm thực hiện ý định người dùng. Người chiến thắng (ví dụ Relayer trong Across) hoàn tất yêu cầu (gửi 1 ETH tới người dùng trên Optimism).
-
Thanh toán ý định — Solver được trả công cho dịch vụ của họ (ví dụ, nhận 1 ETH của người dùng trên Arbitrum cộng thêm một khoản phí nhỏ). Giao thức ý định chứng minh rằng ý định đã được đáp ứng. Tuy nhiên, đây chỉ là một khía cạnh của việc thanh toán. Toàn cảnh lớn hơn là việc thanh toán ý định cũng thúc đẩy quá trình tái cân bằng vốn giữa các solver qua các chuỗi và tài sản.

Dù thiết kế theo ý định mượt mà, nhanh chóng, hiệu quả và đơn giản, nhưng nó có một vấn đề: thiếu solver.
Rủi ro tập trung của ý định
Solver là cốt lõi của các giao thức dựa trên ý định. Chúng là các thực thể thực sự thực hiện ý định người dùng, ví dụ như chuyển tài sản từ chuỗi A sang chuỗi B.
Trong một thế giới lý tưởng, việc giải là môi trường cạnh tranh, nơi các solver cạnh tranh để đáp ứng ý định với mức giá thấp nhất. Tuy nhiên, việc trở thành một solver không hề dễ dàng và tồn tại một số rào cản gia nhập:
-
Yêu cầu đặt cược: Một số giao thức dựa trên ý định yêu cầu các solver phải đặt cược để tham gia đấu giá dòng lệnh. Ví dụ, trong 1inch Fusion, 10 solver hàng đầu (gọi là resolver) được phép tham gia đấu giá. Những solver này được xếp hạng và đưa vào danh sách trắng dựa trên lượng token 1inch đã đặt cược (do chính solver hoặc đại diện đặt cược) và "sức mạnh kỳ lân" theo thời gian đặt cược. Yêu cầu đặt cược nhằm ngăn chặn hành vi độc hại, nhưng vấn đề là những yêu cầu này có thể là rào cản lớn đối với những người chơi nhỏ không có đủ vốn ban đầu.
-
Hệ thống cấp phép: Nhiều giao thức dựa trên ý định là hệ thống được cấp phép, có nghĩa là chúng có người ra quyết định chọn ai được tham gia. Ví dụ, trong 1inch Fusion, quyền truy cập dựa trên sức mạnh kỳ lân, trong khi ở các hệ thống khác (như UniswapX Beta), việc tham gia có thể cần được giao thức điều hành phiên đấu giá đưa vào danh sách trắng. Những hệ thống này ưu tiên chất lượng thực thi, đảm bảo chỉ có những solver đáng tin cậy mới được phép tham gia. Cách tiếp cận này giúp giao thức cung cấp trải nghiệm người dùng mượt mà và đáng tin cậy, nhưng cũng hạn chế việc thu hút thêm nhiều solver.
-
Chi phí phức tạp: Solver cần liên tục tái cân bằng để đáp ứng các ý định xuyên chuỗi. Ngoài ra, số lượng chuỗi đang tăng lên, khiến việc solver duy trì hàng tồn kho, tái cân bằng giữa các chuỗi và nắm giữ đúng tài sản trong hệ sinh thái trở nên khó khăn. Ví dụ, một L3 có thể trở nên phổ biến trong một đêm, hoặc một L2 có thể đóng cửa bất cứ lúc nào. Các giao thức dựa trên ý định là các giải pháp mới trên thị trường và phát triển liên tục khi xuất hiện tình huống mới, điều này đòi hỏi solver phải cập nhật thường xuyên, làm tăng độ phức tạp.
-
Chi phí cố định cao: Viết mã phức tạp, quản lý tích hợp tùy chỉnh cho mỗi giao thức dựa trên ý định, duy trì hàng tồn kho tài sản xuyên chuỗi, xử lý chi phí RPC, duy trì phần cứng chuyên dụng để giành chiến thắng trong cuộc đua tốc độ — tất cả đều là những rào cản làm tăng độ phức tạp và chi phí cho solver.
-
Thiếu động lực và dòng lệnh: Solver hoạt động như các tác nhân hợp lý, cần thấy được lợi nhuận đầu tư mới tham gia. Việc gánh chịu rủi ro (chi phí, độ phức tạp và vốn) cần được đền bù bằng lợi nhuận cao hơn, nếu không giá trị kỳ vọng có thể không đủ để biện minh cho nỗ lực. Hiện tại, lĩnh vực ý định chỉ có một vài ứng dụng có đủ dòng lệnh để khiến nỗ lực của solver xứng đáng (xét về khối lượng giao dịch và lợi nhuận tiềm năng so với sự phiền toái khi tích hợp). Đây là lý do tại sao mặc dù các ứng dụng có dòng lệnh đáng kể (như 1inch, CoWswap, UniswapX, Across) thấy đủ sự tham gia và cạnh tranh từ solver, nhưng các ứng dụng khác lại khó thu hút đủ solver do dòng lệnh ít hơn.
Kết quả là, ngày nay chúng ta rơi vào một tình thế đối lập rõ rệt: sự tham gia của solver ở một vài ứng dụng hàng đầu so với toàn bộ hệ sinh thái.
Ví dụ, hãy xem xét hai chuẩn mực cho các giao thức dựa trên ý định: Cowswap cho ý định hoán đổi và Across cho ý định xuyên chuỗi:
Cowswap có một phiên đấu giá cạnh tranh với 16 solver độc lập cạnh tranh cho đơn hàng của người dùng. Không có solver nào chiếm ưu thế, và không có solver nào do đội ngũ CoWswap vận hành.
Across có hơn 15 solver (gọi là relayers) tích cực cạnh tranh để đáp ứng ý định xuyên chuỗi của người dùng. Mặc dù Risk Labs tiếp tục vận hành solver riêng, dữ liệu cho thấy trái ngược với dữ liệu ban đầu trong nghiên cứu của chúng tôi, không còn solver nào chiếm ưu thế trong phiên đấu giá. Có đủ cạnh tranh giữa các solver.

Rủi ro tập trung do thiếu solver
Phân bố dòng lệnh của relayer Across. Lưu ý: Các solver do Risk Labs vận hành được đánh dấu màu xanh lá và xám đậm trong biểu đồ. Nguồn: Dữ liệu nội bộ của Across.
Hiện tại, phần lớn các giao thức dựa trên ý định khác chỉ có các nhà tạo lập thị trường giàu vốn (như Wintermute) hoặc chính đội ngũ giao thức (những bên có lợi ích trong việc thực hiện ý định người dùng được thu thập trên ứng dụng của họ).
Có một số lý do dẫn đến sự khác biệt này, nhưng rốt cuộc là do không có đủ solver. Điều này có vẻ là một vấn đề nhỏ, nhưng thực tế là một quả bom hẹn giờ tập trung.
Điều đáng lo ngại là: Thiếu solver dẫn đến các vấn đề tập trung. Điều này có nghĩa là điểm thất bại đơn lẻ, rủi ro kiểm duyệt và khả năng solver tăng phí.
Đây không phải là tương lai mở, không cần cấp phép mà chúng ta hình dung, đúng không? Về cơ bản, chúng ta đang dán một giao diện người dùng bóng bẩy lên một hệ thống tập trung — điều này hoàn toàn trái ngược với cuộc cách mạng tài chính mở mà chúng ta đang theo đuổi, chúng ta đang lặp lại các hệ thống truyền thống mà chúng ta cố gắng lật đổ.
Chúng ta cần giải quyết nút thắt solver này càng sớm càng tốt. Nhiều solver hơn, nhanh hơn, là chìa khóa để giải phóng tiềm năng thực sự của các hệ thống dựa trên ý định.

Tin tốt là đã có dấu hiệu cải thiện. Các dự án mới đang khởi động, các đội ngũ hiện tại đang hợp tác để giúp việc tham gia của nhiều solver trở nên dễ dàng hơn.
Ở phần tiếp theo, chúng tôi sẽ đi sâu vào một số giải pháp mới nhằm giúp việc tham gia của solver trong mọi bước của hệ thống dựa trên ý định trở nên dễ dàng hơn. Nhiều solver hơn, vui vẻ hơn, đúng không?

Chuẩn hóa diễn đạt ý định — ERC-7683
Hiện tại chưa có phương pháp xác định rõ ràng để các giao thức dựa trên ý định thu thập ý định người dùng và phát sóng cho các solver. Điều này có nghĩa là mỗi ứng dụng dựa trên ý định đều tự tạo quy trình và khuôn khổ riêng để xác định ý định nên chứa thông tin gì và cách xử lý.
Sự thiếu chuẩn hóa này có nghĩa là solver phải dành nhiều thời gian hơn để làm quen với cách hoạt động của từng giao thức dựa trên ý định (có thể nói là sự phân mảnh lan rộng). Solver phải dành thời gian và nguồn lực để hiểu từng hệ thống cụ thể và viết mã tùy chỉnh để hỗ trợ nó.
Khi số lượng giao thức dựa trên ý định trên thị trường tăng lên, cách tiếp cận này là không bền vững đối với các solver. Sự phân mảnh dẫn đến từng ứng dụng có mạng lưới solver biệt lập, làm suy yếu vòng xoáy hiệu ứng mạng của ý định, bởi vì chúng ta vẫn đang xây dựng trong các khu vườn được rào kín.
Để giải quyết những vấn đề này, Uniswap Labs và Across đã đề xuất ERC-7683, một định dạng chuẩn cho ý định xuyên chuỗi. Tiêu chuẩn này mang lại một số lợi ích:
-
Đơn giản hóa tích hợp: Solver chỉ cần hiểu một định dạng để có thể đáp ứng bất kỳ ý định nào tuân thủ ERC-7683. Điều này giảm đáng kể rào cản gia nhập cho các solver mới.
-
Mạng lưới solver chung cho solver hiện tại: Các ứng dụng có thể truy cập mạng lưới solver sẵn có, không cần xây dựng và duy trì mạng lưới riêng. Điều này cũng làm tăng cạnh tranh giữa các solver để đáp ứng ý định, từ đó có thể dẫn đến giảm phí cho người dùng.

Nhiều giao thức hạ tầng solver như Khalani và Nomial đang nỗ lực tương thích với tiêu chuẩn ERC-7683. Triển vọng này rất tích cực và là tình huống đôi bên cùng có lợi cho tất cả các bên liên quan. Các ứng dụng dựa trên ý định như UniswapX sẽ hưởng lợi từ sự cạnh tranh của nhiều solver hơn, trong khi các solver trong các giao thức hạ tầng này cũng sẽ có được nhiều dòng lệnh hơn ngay từ ngày đầu tiên.
Sự tương thích này mang lại một số lợi ích đáng kể:
-
Các giao thức dựa trên ý định mới có thể khởi động mà không cần xây dựng mạng lưới solver riêng. Điều này tương tự như lợi ích mà EigenLayer cung cấp, cho phép các dự án thuê bảo mật kinh tế.
-
Các solver sẽ có cơ hội cạnh tranh cho dòng lệnh trong thị trường ý định lớn hơn, toàn cầu hơn, thay vì bị giới hạn trong các thị trường địa phương nhỏ hơn, từ đó tăng động lực và thu hút thêm nhiều solver tham gia.
Tuy nhiên, cũng tồn tại một số nhược điểm và hạn chế tiềm tàng có thể ảnh hưởng đến hiệu quả tổng thể và mức độ phổ biến của ERC-7683:
-
Khả năng xuất hiện tiêu chuẩn cạnh tranh: Vấn đề với tiêu chuẩn là rất khó quản lý động lực giữa tất cả các bên tham gia trong hệ sinh thái. Trừ khi tiêu chuẩn được tích hợp ở cấp giao thức bởi chính chuỗi, nếu không câu hỏi về việc liệu nó có thực sự là một sản phẩm công cộng mang lại lợi ích bình đẳng cho mọi người hay không sẽ vẫn tồn tại. Trong trường hợp ERC-7683, có thể nói Uniswap và Across hưởng lợi nhiều hơn từ việc áp dụng, cả về mặt tiếp thị lẫn tư cách là người tiên phong định nghĩa tiêu chuẩn. Chúng ta cũng đã thấy những rào cản tương tự trong các tiêu chuẩn cầu nối trước đây, ví dụ như tiêu chuẩn xERC-20 liên quan đến Connext hoặc tiêu chuẩn OFT liên quan đến LayerZero Labs, cho thấy những rào cản tương tự. Mặc dù nỗ lực định nghĩa tiêu chuẩn là trung lập đáng tin cậy, nhưng người ta vẫn nghi ngờ liệu một số bên có được hưởng lợi quá mức hay không. Sự nghi ngờ này thường dẫn đến việc tạo ra các tiêu chuẩn cạnh tranh, phá vỡ mục đích ban đầu là xây dựng một tiêu chuẩn thống nhất.

-
Động lực thị trường solver có thể xấu đi: ERC-7683 cần đảm bảo tạo ra một sân chơi công bằng, nơi cả solver mới và cũ đều có thể cạnh tranh công bằng. Nếu tiêu chuẩn cuối cùng dẫn đến việc các solver giàu vốn (như Wintermute) giành phần lớn dòng lệnh, thì cần đặt câu hỏi liệu điều này thực sự mang lại lợi ích hay không.
-
Tiêu chuẩn chỉ bao gồm Ethereum và hệ sinh thái EVM: Các ứng dụng dựa trên ý định không chỉ giới hạn ở Ethereum và hệ sinh thái EVM rộng lớn hơn. Ngày nay, khối lượng giao dịch trên Solana thường vượt quá Ethereum và các L2 của nó cả về hàng ngày và hàng tháng. Cần cân nhắc việc làm cho tiêu chuẩn độc lập với chuỗi và hệ sinh thái, mặc dù điều này sẽ khiến công việc phối hợp khó khăn hơn.
-
Tiêu chuẩn chỉ bao gồm chuyển tiền xuyên chuỗi và lệnh giới hạn: ERC-7683 chủ yếu tập trung vào ý định xuyên chuỗi. Sự tập trung này có thể hạn chế tính ứng dụng của nó trong các dạng ý định khác, có thể giới hạn phạm vi sử dụng rộng rãi hơn trong hệ sinh thái giao thức dựa trên ý định. Tuy nhiên, điều quan trọng là cần xem xét lập luận của Across: họ cho rằng phần lớn các thao tác xuyên chuỗi sẽ là chuyển tiền đơn giản chứ không phải các thao tác đa bước phức tạp. Các thao tác này thường liên quan đến việc chuyển tiền xuyên chuỗi ban đầu, sau đó thực hiện thêm trên chuỗi đích. Về cơ bản, tiêu chuẩn phục vụ cho trường hợp sử dụng xuyên chuỗi phổ biến nhất: chuyển tiền. Và nó có thể được kết hợp với các thao tác đơn chuỗi để đáp ứng nhiều ý định khác nhau, thay vì bản thân tiêu chuẩn bao gồm tất cả các ý định có thể xảy ra.
Solver hợp tác thực hiện ý định — Ví dụ về Khalani
Hiện tại, phần lớn các giao thức dựa trên ý định chỉ tập trung vào một số lượng nhỏ thao tác trên một số lượng hạn chế các chuỗi, như hoán đổi và cầu nối.
Để thực sự trở thành kiến trúc thiết kế thống trị, các hệ thống dựa trên ý định cần vượt xa hoán đổi và cầu nối, hỗ trợ một loạt thao tác rộng lớn hơn, bao gồm stake, vay mượn, nạp tiền fiat, v.v.
Một cách để hỗ trợ nhiều loại ý định hơn là giới thiệu các solver chuyên biệt. Bằng cách đưa vào các solver có chuyên môn trong các lĩnh vực cụ thể này, chúng ta có thể đảm bảo mỗi ý định được thực hiện với mức độ chuyên môn cao nhất, từ đó mang lại kết quả tối ưu hơn.
Những solver chuyên biệt này phải hợp tác thay vì hoạt động biệt lập. Sự hợp tác này sẽ cho phép các giao thức dựa trên ý định thực hiện một loạt ý định rộng lớn hơn, kết hợp nhiều thao tác để đáp ứng các ý định đa dạng hơn.
Các nền tảng như Khalani đưa ra giải pháp hỗ trợ sự hợp tác giữa các solver. Thay vì cạnh tranh, các solver hợp tác để tìm ra giải pháp tốt nhất cho từng ý định người dùng. Điều này cho phép nhiều solver nhỏ, chuyên biệt hợp tác hiệu quả.

Hình:Giới thiệu nền tảng Khalani, Nguồn: Introducing Khalani
Như đồng sáng lập Khalani Kevin Wang mô tả: Khalani là một nền tảng điểm đến cho các "cơ hội trùng hợp" giữa các solver theo kiểu ngang hàng. Hợp tác cho phép chia nhỏ các ý định phức tạp thành các ý định chuyên biệt nhỏ hơn (hoặc các ý định có thể kết hợp), các phần nhỏ này có thể được xử lý bởi từng solver riêng lẻ.
Khalani cung cấp một nền tảng nơi các solver có thể kết hợp nguồn lực và chuyên môn của họ để xử lý các ý định người dùng một cách hiệu quả hơn. Bạn có thể coi điều này giống như một bể staking dành cho solver — bằng cách gộp nguồn lực, các bên tham gia có thể đạt được kết quả nhất quán và tiềm năng cao hơn so với khi hành động riêng lẻ.
Để hiểu cách Khalani thực hiện sự hợp tác giữa các solver, hãy xem xét một ví dụ.
Giả sử Bob là một người dùng Ethereum sở hữu USDC và anh ta muốn có ETH trên Arbitrum, sử dụng cầu nối dựa trên ý định.
Dưới đây là cách các solver sử dụng Khalani để thực hiện ý định này:
-
Bob gửi ý định của mình: “Tôi muốn đổi USDC trên Ethereum lấy ETH trên Arbitrum”.
-
Cầu nối dựa trên ý định chọn một solver độc quyền để đáp ứng ý định của Bob, chúng ta gọi solver này là solver A — người được chọn.
Tuy nhiên, solver A không có đủ hàng tồn kho trên Arbitrum để đáp ứng ý định của Bob, nên quyết định tận dụng bể solver của Khalani để cung cấp vốn cần thiết.
-
Solver A gửi một ý định đến Khalani, yêu cầu các solver khác (hoặc tổ hợp solver) cung cấp vốn trên Arbitrum để đổi lấy tiền bị khóa của Bob trên Ethereum.
-
Một solver khác, solver B (cá voi Arbitrum) sở hữu hàng tồn kho trên Arbitrum, cung cấp tài sản cần thiết cho Bob.
-
Thanh toán người dùng - solver — Ngay khi solver B hoàn tất yêu cầu của Bob, solver A cung cấp bằng chứng cho nền tảng thanh toán (trong trường hợp này là cầu nối dựa trên ý định) để thanh toán với người dùng. Kết quả là, solver A nhận được USDC của Bob trên Ethereum.
-
Thanh toán solver - solver — Solver A cung cấp bằng chứng thực thi cho chuỗi Khalani để thanh toán với solver B.
Mặc dù đây là một ví dụ đơn giản hóa minh họa cách các solver hợp tác trên Khalani để đáp ứng ý định, Khalani có thể sử dụng quy trình tương tự để thực hiện các ý định phức tạp hơn.
Ví dụ, Bob là một người dùng Ethereum sở hữu USDC và anh ta muốn gửi ETH vào một nền tảng cho vay trên Arbitrum.
Trong trường hợp này, solver được chọn có thể hợp tác với nhiều solver chuyên biệt trên Khalani dựa trên chuyên môn cần thiết:
-
Solver A (chuyên gia định giá) — Chạy phần mềm chuyên dụng để tìm ra mức giá chính xác nhất cho cặp giao dịch trên cùng chuỗi hoặc xuyên chuỗi. Nó có thể định giá thanh khoản USDC/ETH dựa trên thông tin trên chuỗi và ngoài chuỗi.
-
Solver B (cá voi Arbitrum) — Sở hữu hàng tồn kho trên Arbitrum, có thể được sử dụng để cung cấp số lượng ETH cần thiết trên Arbitrum.
-
Solver C (người thực thi Ethereum) — Chuyên thực hiện các thao tác tối ưu nhất trên Ethereum, cung cấp các lựa chọn đánh đổi giữa giá và độ trễ cho người dùng. Nó có thể được sử dụng để thực hiện giao dịch nhằm lấy tiền gửi của người dùng trên Ethereum.
-
Solver D (người thực thi Arbitrum) — Chuyên thực hiện giao dịch trên Arbitrum. Nó có thể được sử dụng để thực hiện giao dịch cục bộ, gửi ETH vào nền tảng cho vay trên Arbitrum.
Tương tự, các solver chuyên biệt khác trên Khalani cũng có thể được huy động, chia nhỏ ý định phức tạp thành các nhiệm vụ đơn giản hóa được thực hiện bởi nhiều solver, thay vì phụ thuộc vào một solver duy nhất thực hiện mọi thứ.

Bằng cách giải quyết vấn đề thông qua nền tảng Khalani, có thể thực hiện một loạt ý định rộng lớn, đây là một bước tiến lớn đối với mô hình dựa trên ý định. Tuy nhiên, tại mỗi bước của quy trình này có thể tồn tại các điểm nghẽn tiềm tàng, có thể ảnh hưởng đến việc thực thi ý định:
-
Lỗi của người dùng khi gửi ý định: Khi giao diện người dùng (UI) của ứng dụng được thiết kế để thu thập các ý định cụ thể (như hoán đổi hoặc cầu nối), phạm vi lỗi của người dùng là hạn chế vì người dùng có hướng dẫn rõ ràng khi gửi ý định. Tuy nhiên, UI được thiết kế để thu thập các ý định rộng rãi có thể khó hơn, dễ dẫn đến người dùng gửi ý định sai hoặc không đầy đủ, gây ra việc thực thi ý định thất bại hoặc sai lệch.
-
Rủi ro hoạt động: Trong hệ thống ý định, tồn tại rủi ro solver không khả dụng, điều này có thể khiến toàn bộ hệ thống đình trệ. Ngoài ra, solver có thể không thực hiện nhiệm vụ của mình một cách chính xác hoặc kịp thời, dẫn đến thất bại giao dịch.
-
Khả dụng solver hạn chế: Có thể chỉ có một số lượng hạn chế solver trong cơ sở hạ tầng Khalani cho các loại ý định khác nhau. Điều này có thể làm giảm khả năng thực thi ý định và hiệu quả tổng thể.
-
Độ phức tạp trong việc phối hợp giữa các solver: Phối hợp nhiều solver có thể rất phức tạp và dễ xảy ra lỗi do liên quan đến nhiều yếu tố như sự sẵn có của các solver chuyên biệt, điều kiện thị trường và các yếu tố liên quan đến chính ý định (như các chuỗi liên quan, quy mô vốn cần thiết, v.v.).
-
Rủi ro liên quan đến thực thi nguyên tử: Tất cả các thao tác của solver đều là nguyên tử và được thực hiện cùng nhau trên chuỗi Khalani. Điều này có nghĩa là solver trải nghiệm tính nguyên tử trên Khalani, tức là tất cả các phần của quy trình thành công trong một thao tác duy nhất hoặc toàn bộ thất bại. Nếu bất kỳ phần nào của giao dịch thất bại, toàn bộ giao dịch sẽ bị hoàn tác, điều này có thể dẫn đến tỷ lệ thất bại ý định cao hơn. Tuy nhiên, ở đây không có rủi ro tiền bị mắc kẹt hoặc mất mát.
-
Hợp tác solver làm tăng độ trễ: Mặc dù việc phát hiện hợp tác diễn ra ngoài chuỗi, gần như tức thì, nhưng sẽ tăng thêm một chút độ trễ do các yếu tố sau:
-
Phụ thuộc nhiệm vụ: Một số nhiệm vụ có thể phụ thuộc vào việc hoàn thành các nhiệm vụ khác. Việc phối hợp các phụ thuộc này và xử lý lỗi có thể gây ra độ trễ vì solver cần chờ nhiệm vụ trước đó hoàn tất.
-
Các bước kiểm tra an toàn và xác minh: Thực hiện các kiểm tra an toàn và các bước bổ sung để xác minh giao dịch nhằm ngăn chặn gian lận hoặc hành vi độc hại có thể làm tăng độ trễ.
Để đảm bảo độ tin cậy và chất lượng tổng thể của việc thực thi ý định, mặc dù có những độ trễ tiềm tàng này, một số giao thức dựa trên ý định vận hành phiên đấu giá được cấp phép và chọn chỉ hợp tác với các solver đáng tin cậy, nằm trong danh sách trắng.
Tuy nhiên, cần lưu ý rằng độ trễ này phụ thuộc vào nhiệm vụ và không thay đổi do nhiệm vụ được thực hiện bởi một solver hay nhiều solver hợp tác — điều này tương tự đối với tất cả các giao thức dựa trên ý định phụ thuộc vào solver để thực hiện.
Hiệu ứng vòng xoáy của ERC 7683 và Khalani
Các nền tảng hạ tầng solver sẽ tương thích với các tiêu chuẩn như ERC-7683 vì điều này mang lại lợi ích đôi bên. Mục tiêu chính của các dự án và sáng kiến này là thu hút thêm nhiều solver vào hệ sinh thái, và nếu chúng ta có thể làm được điều đó, sự tương thích giữa hai bên có thể khởi động hiệu ứng vòng xoáy cho mô hình dựa trên ý định:

Hình: Nhiều solver hơn — Khi số lượng solver tăng lên, số lượng loại ý định có thể thực hiện cũng tăng lên
-
Nhiều sự hợp tác solver hơn: Khi có nhiều solver chuyên biệt hơn, cơ hội hợp tác cũng tăng lên. Các solver có thể kết hợp kỹ năng chuyên biệt của họ để xử lý các ý định phức tạp hơn.
-
Khả năng biểu đạt ý định tăng lên: Sự hợp tác giữa các solver làm tăng khả năng biểu đạt và độ phức tạp của ý định người dùng. Người dùng có thể yêu cầu các thao tác phức tạp hơn cần nhiều bước và chuyên môn.
-
Cần một tiêu chuẩn chung: Khi khả năng biểu đạt ý định tăng lên, các ứng dụng dựa trên ý định cần một tiêu chuẩn chung để đảm bảo các solver có thể dễ dàng kết nối vào một giao diện chung và thu thập ý định từ các ứng dụng khác nhau.
Thanh toán ý định hiệu quả về vốn — Ví dụ về Everclear với lớp thanh lý
Trong quá trình thanh toán ý định, các solver sẽ nhận được khoản thanh toán trên chuỗi nguồn nơi người dùng tạo ra ý định. Điều này có nghĩa là vốn của họ bị phân tán trên nhiều chuỗi và cần liên tục tái cân bằng. Việc này không chỉ rắc rối khi quản lý mà còn khiến một lượng lớn vốn bị bỏ không. Và càng nhiều chuỗi, thanh khoản của mỗi solver càng bị phân tán.
Hiện tại, không có hệ thống chung nào để phối hợp dòng vốn xuyên chuỗi này. Mỗi solver đều như sói đơn độc, tự quản lý thanh khoản trong môi trường phân mảnh này. Everclear ra đời nhằm giải quyết vấn đề tái cân bằng cho các solver.
Everclear điều phối việc thanh toán thanh khoản toàn cầu xuyên chuỗi thông qua một "lớp thanh lý" — một mạng lưới phi tập trung chịu trách nhiệm điều phối việc bù trừ và thanh toán toàn cầu cho dòng vốn xuyên chuỗi.
Hạt nhân trong đề xuất giá trị của Everclear là khái niệm bù trừ (Netting).
Bù trừ là một cơ chế gộp nhiều khoản thanh toán giữa các bên khác nhau để giảm số lần thanh toán ròng. Nghĩa là thay vì xử lý từng giao dịch riêng lẻ, bù trừ tính toán tổng số nợ giữa các bên, chỉ cần thanh toán khoản chênh lệch. Điều này làm cho quá trình đơn giản hơn và giảm số lần thanh toán.

Đối với những ai quen thuộc với cuộc sống du mục mã hóa, chắc hẳn bạn biết Splitwise — một ứng dụng giúp nhóm theo dõi các chi phí chung, ví dụ như trong chuyến đi. Tính năng "thanh toán" trong Splitwise là ví dụ hoàn hảo về bù trừ:
-
Theo dõi chi phí: Mỗi thành viên trong nhóm ghi lại các chi phí của họ vào ứng dụng.
-
Tính toán số dư: Splitwise tính toán mỗi người nợ bao nhiêu hoặc được nợ bao nhiêu.
-
Thanh toán (bù trừ): Thay vì mỗi người thanh toán cho nhau nhiều lần, Splitwise tính toán cách đơn giản nhất để thanh toán tất cả các khoản nợ.
Khái niệm bù trừ này cũng được các công ty kiều hối như TransferWise sử dụng. Thay vì chuyển tiền xuyên biên giới, họ ghép nối người gửi và người nhận có nhu cầu tiền tệ ngược nhau và thanh toán lẫn nhau. Điều này làm giảm số lần chuyển tiền thực tế, giúp quá trình hiệu quả hơn và tiết kiệm chi phí.
Tương tự, Everclear cho phép các solver "thanh toán" lẫn nhau xuyên chuỗi, giảm đáng kể tổng số lần thanh toán cần thiết, từ đó giảm chi phí, hàng tồn kho và độ phức tạp tổng thể cho solver. Đối với những ai hiểu cách CowSwap hoạt động, bù trừ về cơ bản là việc ghép nối nhu cầu quy mô lớn giữa các solver trong một khoảng thời gian.

Hình:Giới thiệu nền tảng Everclear, Nguồn: Introducing Everclear
Everclear cho rằng khoảng 80% lưu lượng vốn xuyên chuỗi hàng ngày có thể được xử lý thông qua bù trừ thanh toán. Điều này có nghĩa là cứ mỗi 1 đô la chảy vào một chuỗi mỗi ngày, thì 0,80 đô la sẽ chảy ra. Điều này cho thấy về tổng thể, lượng vốn gửi qua cầu nối chuỗi nhiều hơn gấp 5 lần so với nhu cầu thực tế, các solver tái cân bằng xuyên chuỗi thường xuyên hơn rất nhiều vì họ hoạt động biệt lập.
Hãy xem xét cách người dùng (như các giao thức dựa trên ý định, solver hoặc sàn giao dịch tập trung) có thể tận dụng ngăn xếp công nghệ của Everclear.
Xét ví dụ Alice, cô là một solver thích thanh toán trên Arbitrum. Alice cần hoàn tất một giao dịch 10 ETH từ Optimism sang Arbitrum. Dưới đây là quy trình có và không có Everclear:

Chúng ta có thể thấy lợi ích của lớp thanh lý như Everclear đối với người dùng của nó (như solver và nhà tạo lập thị trường) như Alice:
-
Ưu tiên thanh toán: Alice thích được thanh toán trên Arbitrum, Everclear đảm bảo cô nhận được khoản thanh toán trên Arbitrum, phù hợp với sở thích của cô.
-
Không cần tái cân bằng: Không có Everclear, Alice cần cầu nối 10 ETH từ Optimism sang Arbitrum để tái cân bằng. Với Everclear, bước này bị loại bỏ, tiết kiệm thời gian và tài nguyên. Việc xử lý tái cân bằng thông qua Everclear làm cho toàn bộ quy trình làm việc đơn giản hơn. Điều này đặc biệt hấp dẫn đối với những người tham gia mới vào bể solver.
-
Giảm chi phí vận hành: Bằng cách loại bỏ nhu cầu tái cân bằng thủ công, Everclear giảm chi phí vận hành cho Alice, giúp cô tập trung vào việc giải quyết nhiều giao dịch hơn.
-
Tiết kiệm chi phí: Tránh việc cầu nối vốn xuyên chuỗi có thể tiết kiệm phí giao dịch và trượt giá tiềm năng, khiến quá trình hiệu quả hơn về chi phí đối với Alice. Điều này cũng có thể dẫn đến công việc ổn định hơn và thu nhập tiềm năng cao hơn.
Bằng cách loại bỏ một điểm nghẽn chính của solver, Everclear có thể khuyến khích nhiều người tham gia hơn vào hệ sinh thái, cuối cùng thúc đẩy hiệu ứng vòng xoáy thu hút thêm nhiều solver.
Vị trí của Everclear trong ngăn xếp công nghệ ý định cho phép bất kỳ giao thức hoặc hạ tầng nào liên quan đến solver đều có thể tận dụng nó để giải quyết vấn đề tái cân bằng và giảm chi phí, độ phức tạp vận hành cho solver.
Ví dụ, các hạ tầng solver như Khalani sẽ tích hợp với Everclear, cho phép các solver hợp tác thông qua ngăn xếp công nghệ của nó tận dụng Everclear cho việc thanh toán hiệu quả về vốn. Do đó, có thể nói việc ra mắt Everclear là một bước phát triển tích cực đối với mô hình dựa trên ý định, vì nó cải thiện các dự án khác nhau trong hệ sinh thái này và mở rộng thị trường.
Để thực hiện điều này, Everclear được thiết kế là một rollup Arbitrum Orbit sử dụng công nghệ EigenDA và hợp tác với Gelato RaaS. Khi khởi chạy mainnet alpha (dự kiến vào đầu quý 3 năm 2024), Everclear sẽ hoạt động dưới một số hạn chế và biện pháp bảo vệ:
-
Tài sản và chuỗi được cấp phép: Ban đầu, chỉ hỗ trợ các chuỗi và tài sản trong danh sách trắng, điều này hạn chế tính mở và khả dụng của hệ thống. Tuy nhiên, kế hoạch trong tương lai là vô quyền.
-
Phụ thuộc vào Eigenlayer: Everclear phụ thuộc vào Eigenlayer để đảm bảo an toàn, nhưng hiện tại nó không hỗ trợ phạt cắt (slashing). Điều này hạn chế bảo mật kinh tế cho đến khi chức năng phạt cắt được triển khai. Người dùng phải tin tưởng rằng Eigenlayer sẽ triển khai phạt cắt trong tương lai để tăng cường bảo mật kinh tế. Trước đó, Everclear dự định sử dụng ISM tập hợp validator của Hyperlane để đảm bảo an toàn.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News














