Thực thi do ứng dụng điều khiển: Nghiên cứu trường hợp về ưu tiên hủy bỏ

Thực thi do ứng dụng điều khiển: Nghiên cứu trường hợp về ưu tiên hủy bỏ

Bài viết của Maryam và Mike – ngày 29 tháng 1 năm 2026.

Tóm lại: Cơ chế thực thi do ứng dụng điều khiển (viết tắt là ACE) là một cơ chế trao quyền kiểm soát trình tự giao dịch cho các ứng dụng. Việc Hyperliquid sử dụng ưu tiên hủy là ví dụ nổi bật nhất về ACE hiện nay, và nó chứng minh rằng ACE có thể được sử dụng để cải thiện đáng kể giao dịch trên chuỗi. Bài viết này phân tích bốn cơ chế được đề xuất để triển khai ACE và cách mỗi cơ chế có thể hiện thực hóa ưu tiên hủy. Chúng ta cũng xem xét một hình thức ACE tổng quát hơn, được quy định rõ ràng, có thể được triển khai trong ngôn ngữ hợp đồng thông minh và được thực thi bởi cơ chế đồng thuận L1. Trong khuôn khổ đó, chúng ta sử dụng các ví dụ để chứng minh những nhược điểm cụ thể của việc tăng độ phức tạp trong việc xây dựng khối và giảm khả năng kết hợp. Mục tiêu chính của bài viết này là tóm tắt cuộc thảo luận xung quanh các hình thức ACE khác nhau. Chúng tôi hy vọng nó cho thấy rằng các thiết kế này có nhiều điểm chung và một thứ mạnh mẽ như ưu tiên hủy có thể được triển khai mà không quá phức tạp.

Nội dung

(1) Giới thiệu
(2) Thiết kế hiện có
\quad (2.1) Chuỗi ứng dụng
\quad (2.2) Gom hàng trên dây chuyền đa dụng
\quad (2.3) Phân nhóm bởi các bên ngoài chuỗi
\quad (2.4)Cam kết của người đề xuất được thực thi theo giao thức
(3) Đặt hàng do ứng dụng chỉ định được thực thi bằng sự đồng thuận
\quad (3.1) Độ phức tạp của việc xây dựng khối
\quad (3.2) Khả năng kết hợp
\quad (3.3) Siêu dữ liệu giao dịch
(4) Kết luận

Các bài viết liên quan

(1) Giới thiệu

Bài viết này nghiên cứu về thực thi do ứng dụng điều khiển (viết tắt là ACE), trong đó các ứng dụng có thể chỉ định các ràng buộc về thứ tự các giao dịch tương tác với chúng. Để phục vụ mục đích của chúng ta, chúng ta sẽ sử dụng định nghĩa ACE sau đây.

Việc thực thi do ứng dụng điều khiển sẽ áp đặt các quy tắc về thứ tự thực hiện lên các lô giao dịch tương tác với chúng.

Ứng dụng sẽ tự quyết định thế nào là một lô, nhưng hiện tại, chúng ta sẽ tập trung vào một lô trên mỗi khối, đây là lựa chọn tự nhiên nhất. ACE là một khái niệm và định nghĩa rất rộng, vì vậy chúng ta sẽ làm rõ nó bằng cách tập trung cụ thể vào ưu tiên hủy, điều mà Hyperliquid đã triển khai. Chúng ta sẽ sử dụng định nghĩa sau về ưu tiên hủy.

Nguyên tắc ưu tiên hủy lệnh đảm bảo rằng trong mỗi lô lệnh, các lệnh bị hủy sẽ được xử lý trước các lệnh được chấp nhận.

Lưu ý rằng, theo cách diễn đạt của Hyperliquid, “các lệnh hủy và lệnh chỉ thực hiện giao dịch được ưu tiên hơn các lệnh GTC và IOC” (xem mô tả loại lệnh của họ tại đây ). Để đơn giản, chúng ta sẽ định nghĩa một cách không chính thức “lệnh hủy” là các lệnh rút thanh khoản khỏi sàn giao dịch mà không thực hiện giao dịch, và “lệnh nhận” là các lệnh thực hiện giao dịch. Chúng ta bỏ qua hầu hết các chi tiết cụ thể của sàn giao dịch (ví dụ: DEX so với CLOB trên chuỗi), nhưng sẽ làm rõ trong các ví dụ nếu cần thiết.

Phần 2 khám phá bốn thiết kế hiện có để triển khai ACE và phân tích những sự đánh đổi mà mỗi thiết kế mang lại. Để giúp thống nhất các thiết kế khác nhau, chúng tôi nghiên cứu cụ thể nhiệm vụ ưu tiên hủy bỏ, ngay cả khi đề xuất ban đầu không dành riêng cho trường hợp sử dụng này.
Phần 3 xem xét một cách triển khai tổng quát hơn của ACE trong giao thức, trong đó các hợp đồng thông minh chỉ định thứ tự thực thi hàm và cơ chế đồng thuận thực thi thứ tự đó tại hàm chuyển trạng thái. Giải pháp "được quy định" này có hai nhược điểm ngay lập tức: tăng độ phức tạp khi xây dựng khối và giảm khả năng kết hợp; chúng tôi sẽ xây dựng các ví dụ nhỏ để minh họa từng nhược điểm này.

(2) Thiết kế hiện có

Bốn phần phụ sau đây phác thảo các cơ chế được đề xuất khác nhau để triển khai ACE và trình bày cách mỗi cơ chế có thể hiện thực hóa việc ưu tiên hủy bỏ. Không đi sâu vào chi tiết, chúng tôi phân tích những ưu điểm và nhược điểm chính của mỗi thiết kế.

(2.1) Chuỗi ứng dụng

Dự án tiền điện tử đầu tiên triển khai ưu tiên hủy lệnh là Hyperliquid; Jeff đã trình bày động cơ của mình ở đây và lập luận rằng quyết định này giúp đảm bảo chênh lệch giá mua bán hẹp hơn cho người dùng, mặc dù phải hy sinh khối lượng giao dịch của sàn, vốn thường được coi là một chỉ số phù phiếm. Vì Hyperliquid là một sàn giao dịch L1 chuyên dụng cho giao dịch, nên họ triển khai quyết định thiết kế này ở cấp độ giao thức:

“Thứ tự thực thi này được thực hiện trên chuỗi bởi chính L1. Cách duy nhất chính xác để một node thực hiện một khối trên Hyperliquid L1 là ưu tiên xử lý các lệnh hủy và lệnh chỉ đăng trước.”
– Thiết kế của Hyperliquid .

Đây là cách đơn giản và mạnh mẽ nhất để thực thi các quy tắc sắp xếp cụ thể cho ứng dụng. Sơ đồ trình tự bên dưới thể hiện luồng này. Việc “thực thi dựa trên sự đồng thuận” diễn ra ở giai đoạn Xác minh Khối , nơi các bên chứng thực xác định tính hợp lệ của một khối bằng cách kiểm tra xem các thao tác Hủy có đứng trước các thao tác Nhận hay không.

upload_ebca492ec3e2ad44731712d27495d28c 1070×1276 76.8 KB

Ưu điểm của chuỗi ứng dụng trong việc ưu tiên hủy đơn hàng:

• Kiểm soát chi tiết: Do bản chất là một chuỗi ứng dụng, ứng dụng có được quyền kiểm soát tối đa đối với môi trường thực thi của nó. Việc trao cho mỗi chuỗi ứng dụng quyền kiểm soát cách thức xây dựng và xác thực các khối là một luận điểm lâu đời của hệ sinh thái Cosmos (mặc dù khả năng tương tác giữa các miền độc lập này vẫn chưa được chứng minh). Có những cách khác, mang tính chủ quan, mà các chuỗi ứng dụng có thể tạo ra không gian khối. Ví dụ, Injective chạy một phiên đấu giá theo lô thường xuyên với tốc độ sản xuất khối. Thay vì mỗi giao dịch được xử lý tuần tự, chúng được thực thi đồng thời theo lô. Tương tự, dYdX sử dụng các phần mở rộng bỏ phiếu để hạn chế quyền lực của người đề xuất khối bằng cách giới hạn tập hợp các giao dịch mà người đề xuất có thể loại trừ (một thiết kế rất giống với FOCIL ).

Nhược điểm của chuỗi ứng dụng trong việc ưu tiên hủy:

• Khả năng chống kiểm duyệt: Độ bền vững của quy tắc đặt lệnh Hyperliquid (và các cam kết chuỗi ứng dụng nói chung) chỉ mạnh mẽ bằng khả năng chống kiểm duyệt của chuỗi và tập hợp các trình xác thực của nó. Người đề xuất luôn có thể thực hiện lệnh "nhận" chứ không phải lệnh "hủy" bằng cách đơn giản là loại bỏ hoàn toàn lệnh "hủy" khỏi khối của họ. Mặc dù điều này làm mất đi doanh thu phí giao dịch từ lệnh "hủy", nhưng nó có thể hợp lý nếu market maker 1 sẵn sàng hối lộ người đề xuất để làm như vậy.
• Thanh toán “chỉ thông qua cầu nối”: Trong phân tích này, chúng tôi định nghĩa “thanh toán” là khoảng thời gian chậm trễ giữa thời điểm giao dịch được đưa vào và thời điểm mà kết quả của giao dịch có thể được sử dụng trong các ứng dụng khác trên máy chủ L1 đa năng. Mặc dù điều này có vẻ không công bằng đối với Hyperliquid và các chuỗi ứng dụng khác, nhưng chúng hoạt động độc lập với phần còn lại của thị trường tiền điện tử, và hiệu ứng mạng lưới của hầu hết các tài sản đã tồn tại trên các chuỗi công khai lớn là cực kỳ bền vững. Để tương tác với kết quả của giao dịch Hyperliquid trên Ethereum L1, các tài sản trước tiên phải được cầu nối, gây ra sự chậm trễ đáng kể (có thể lên đến vài khối). Đặc biệt, không có sự thanh toán nguyên tử thực sự nào giữa Hyperliquid và bất kỳ chuỗi nào khác.

Hyperliquid đã chứng minh rằng nếu một ứng dụng có thể kiểm soát hoàn toàn trình tự thực thi của nó, thì nó nên đưa ra các quyết định dựa trên quan điểm riêng biệt về trường hợp sử dụng cụ thể của ứng dụng đó. Nhóm Atlas cũng đưa ra lập luận tương tự về các quyết định mà họ đưa ra trong bối cảnh "L2 dành riêng cho DeFi".

Tuy nhiên, bằng cách xây dựng một chuỗi độc lập, các chuỗi ứng dụng (app-chain) phải đối mặt với các vấn đề phân mảnh tương tự như Ethereum L2. Để giải quyết vấn đề phân mảnh này, một số ứng dụng sẽ chọn xây dựng trực tiếp trên các blockchain đa năng như Ethereum và Solana để tận dụng khả năng kết hợp nguyên tử được hỗ trợ bởi các ứng dụng khác cùng tồn tại trên cùng một trạng thái. Các ứng dụng này không thể kiểm soát các quy tắc đồng thuận và phải được triển khai dưới dạng kết hợp mã hợp đồng thông minh trên các chuỗi công khai, cùng với bất kỳ cơ sở hạ tầng nào nằm ngoài giao thức cần thiết để hỗ trợ ứng dụng. Hai phần tiếp theo sẽ khám phá một số thiết kế được đề xuất cho các ứng dụng này và so sánh với những gì chúng ta đã thấy.

(2.2) Gom hàng trên dây chuyền đa dụng

Cavey, Jakob và Max đã đề xuất "Hàng đợi tin nhắn bất đồng bộ" (viết tắt là AMQ) như một cơ chế cho phép các ứng dụng triển khai ưu tiên hủy trên Solana hiện nay. Cơ chế này hoạt động như sau:

1. Trong khối N, các giao dịch bất đồng bộ được xếp vào hàng đợi nhưng không được thực thi. Hàng đợi này được lưu giữ dưới dạng trạng thái trong hợp đồng thông minh và đóng vai trò như một lô xử lý.
2. Trong khối N+1, các giao dịch được xếp hàng chờ sẽ được thực hiện theo lô. Bản thân thao tác "thực thi" cũng là một giao dịch, kích hoạt các giao dịch theo thứ tự ưu tiên do ứng dụng chỉ định.

Sơ đồ bên dưới minh họa quá trình này trên hai khối.

upload_08c603422b911a7eed4b9f0ac5f4684a 1010×1356 86 KB

Ưu điểm của AMQ trong việc ưu tiên hủy:

• Không thay đổi cơ chế đồng thuận: Bằng cách sử dụng trạng thái L1 và dấu thời gian, AMQ có thể được triển khai trên Solana (hoặc Ethereum) ngay hôm nay chỉ bằng hợp đồng thông minh mà không cần thay đổi bất cứ điều gì về giao thức cốt lõi.

Nhược điểm của AMQ trong việc ưu tiên hủy:

• Trễ giao dịch: Có độ trễ ít nhất một slot giữa thời điểm giao dịch được khởi tạo và thời điểm chúng được thanh toán. Mặc dù người dùng có thể hưởng lợi từ tính thanh khoản và khả năng thực thi tốt hơn nhờ ưu tiên hủy lệnh, nhưng trải nghiệm người dùng rõ ràng sẽ bị ảnh hưởng khi phải chờ thêm một block để giao dịch hoàn tất (mặc dù đây có thể là vấn đề lớn hơn đối với Ethereum so với Solana do thời gian slot). Có hai giải pháp tiềm năng ngay lập tức, cả hai đều yêu cầu thay đổi các quy tắc đồng thuận. Thứ nhất, chuỗi có thể cho phép "giao dịch theo lịch trình", thực thi theo lô vào cuối mỗi block. Hoặc, chuỗi có thể cho phép các hợp đồng tự xem xét vị trí của mỗi giao dịch trong block. Với thông tin này, hợp đồng biết khi nào giao dịch cuối cùng và có thể kích hoạt việc thực thi lô ngay sau đó (loại cơ chế "gọi lại" này tương tự như hook của UniV4 ).
• Thanh toán "ở khối tiếp theo": Do sự chậm trễ trong giao dịch và như đã được chỉ ra trong bài đăng về AMQ , bản chất bất đồng bộ của việc thực thi giao dịch loại bỏ việc thanh toán nguyên tử với các giao dịch Solana khác trong cùng một khối. Ngay cả khi không còn giao dịch AMQ nào trong khối N (và do đó kết quả của việc thực thi theo lô được biết trước một cách chắc chắn), việc thanh toán giao dịch sẽ không diễn ra cho đến khối N+1, và do đó không có giao dịch nào trong khối N có thể tương tác với các đầu ra đó (ví dụ: bằng cách trả lại khoản vay nhanh).
• Kiểm duyệt: Cũng như thiết kế chuỗi ứng dụng ở trên, độ tin cậy của cơ chế AMQ phụ thuộc rất nhiều vào khả năng chống kiểm duyệt của chuỗi cơ sở. Một trình xác thực Solana có thể dễ dàng kiểm duyệt bất kỳ yêu cầu hủy nào đến trong khối N để làm cho hàng đợi ưu tiên trở nên không hiệu quả. Các tác giả đã trực tiếp thừa nhận điều này.

  “Tương tự như tất cả các hình thức ACE khác không liên quan đến nhiều người đề xuất, AMQ vẫn có thể bị trình xác thực bỏ qua trong phạm vi thời gian xử lý do giao thức quy định thông qua việc kiểm duyệt và trì hoãn.”
  – Thực thi ACE .

AMQ dựa vào các trình xác thực Solana để thực thi ACE. Một số ứng dụng có thể chọn các giải pháp xử lý hàng loạt ngoài chuỗi để chuyển sự tin tưởng của họ sang các bên phù hợp hơn với ứng dụng của họ.

(2.3) Phân nhóm bởi các bên ngoài chuỗi

Một cách khác để triển khai các quy tắc sắp xếp cụ thể cho ứng dụng là bằng cách ủy quyền quyền sắp xếp thứ tự cho các thực thể ngoài chuỗi. Sorella triển khai một sàn giao dịch phi tập trung (DEX) lai giữa chuỗi và ngoài chuỗi trên Ethereum. Thiết kế của họ tận dụng một cơ chế đồng thuận riêng biệt để xác định nhóm giao dịch cần thực hiện đối với các vị thế thanh khoản được nắm giữ trên Ethereum L1.

Lưu ý #1 : Theo thuật ngữ của Uniswap, "cancel" có nghĩa là "loại bỏ một vị thế thanh khoản". Tương tự, "take" chỉ đơn giản là một "giao dịch hoán đổi".

Lưu ý #2 : Theo đề xuất, Sorella không triển khai tính năng ưu tiên hủy lệnh. Thay vào đó, họ tập trung vào các phiên đấu giá Top-of-Bundle và các giao dịch thanh toán theo lô. Tuy nhiên, tính năng ưu tiên hủy lệnh hoàn toàn có thể được triển khai theo mô hình của họ, vì vậy chúng tôi sử dụng ví dụ này để giúp làm rõ sự khác biệt giữa các thiết kế khác nhau.

Sơ đồ bên dưới minh họa quy trình ưu tiên hủy giả định trên Sorella.

upload_0b068c9d53c36619ed691c39cfeced44 946×1048 62.1 KB

Ưu điểm của việc xử lý theo lô ngoài chuỗi để ưu tiên hủy:

• Không có thay đổi nào đối với sự đồng thuận: Giống như với AMQ, việc xử lý hàng loạt ngoài chuỗi hoàn toàn có thể được triển khai trên các L1 đa năng hiện nay, mà không cần sửa đổi giao thức cốt lõi.

Nhược điểm của việc gom nhóm yêu cầu hủy ngoài chuỗi:

• Tính khả dụng: Bằng cách dựa vào một cơ chế đồng thuận riêng biệt với Ethereum, Sorella phải gánh thêm rủi ro về tính khả dụng. Nếu cơ chế đồng thuận của Sorella bị đình trệ hoặc trở nên độc hại, các nhà giao dịch và nhà cung cấp thanh khoản sẽ không thể tương tác với ứng dụng. Các tác giả đã đề cập cụ thể đến điều này:

  “Do đó, [ACE] chắc chắn sẽ liên quan đến các bên ngoài, những bên này sẽ đưa ra thêm các giả định về tính khả thi và sự tin cậy.”
  – Giả định về tính sống động và sự tin cậy .

• Kiểm duyệt: Các mối lo ngại về kiểm duyệt của chuỗi ứng dụng và việc xử lý hàng loạt trên chuỗi vẫn còn tồn tại. Cụ thể, quy tắc sắp xếp không thể bảo vệ chống lại việc người đề xuất Sorella bỏ qua yêu cầu hủy bỏ đến để ưu tiên cho yêu cầu chấp nhận hiện có. Mặt khác, vì những người tham gia cơ chế đồng thuận Sorella là các bên liên quan chính trong Sorella, nên có thể lập luận rằng các động lực của người xác thực gắn bó chặt chẽ hơn với sự thành công lâu dài của dự án (so với người xác thực của một L1 đa năng).
• Thanh toán "sau khi gom nhóm": Sorella không thể kết hợp trực tiếp với các giao dịch Ethereum, vì tất cả các giao dịch Sorella được gom nhóm thành một đơn vị nguyên tử và giao dịch với nhóm L1 một cách nguyên tử. Tuy nhiên, một khi gói Sorella được đưa vào trong một khối, các giao dịch sẽ được thanh toán đầy đủ và bất kỳ giao dịch nào tiếp theo (ngay cả trong cùng một khối Ethereum) đều có thể sử dụng trạng thái kết quả.

Lưu ý #3 : Cơ chế đồng thuận của Sorella có thể dễ dàng được thay thế bằng một cơ chế sắp xếp giao dịch khác. Ví dụ, BuilderNet sử dụng TEE để thực hiện việc xây dựng khối theo cách có thể kiểm chứng được. Sorella có thể được sửa đổi để chỉ cho phép các gói được ký bởi các TEE được ủy quyền, thay vì từ kết quả đầu ra của cơ chế đồng thuận Sorella. Các vấn đề về tính khả thi, kiểm duyệt và thanh toán đều tương tự nhau trong mô hình này, với sự khác biệt duy nhất về giả định độ tin cậy phát sinh từ sự đảm bảo của TEE so với sự đảm bảo của cơ chế đồng thuận Byzantine.

(2.4) Cam kết của người đề xuất được thực thi theo giao thức

Barnabé đã phác thảo các cam kết của người đề xuất được thực thi bởi giao thức (viết tắt là PEPC), được thúc đẩy bởi sự phát triển của các nhiệm vụ đồng thuận, đặc biệt là trong bối cảnh việc xây dựng khối được giao cho phiên đấu giá MEV-boost. Trong một thế giới PEPC, người đề xuất có thể cam kết thực hiện một tập hợp các hành động tổng quát hơn là chỉ cam kết với người xây dựng khối chiến thắng. Không giống như MEV-boost, dựa vào các máy chuyển tiếp như các bên thứ ba đáng tin cậy, các cam kết PEPC sẽ được thực thi bởi chính cơ chế đồng thuận của Ethereum. Tính tổng quát này cũng có thể được sử dụng để triển khai ưu tiên hủy bỏ trực tiếp trong Ethereum. Sơ đồ bên dưới minh họa điều này.

upload_c00da71ed53662ee25a7f67ddb26097c 1090×1434 79,5 KB

Ưu điểm của PEPC trong việc ưu tiên hủy đơn hàng:

• Không cần thêm giả định về độ tin cậy: Nếu PEPC được triển khai, việc thực thi các cam kết do những người đề xuất đưa ra sẽ mạnh mẽ như các đảm bảo đồng thuận của Ethereum.
• Giải quyết giao dịch “nguyên bản”: PEPC đủ linh hoạt để đảm bảo rằng các lệnh hủy phải được thực thi trước các lệnh nhận mà không phá vỡ tính tương thích với các giao dịch Ethereum khác. Quá trình xây dựng và xác thực khối sẽ trở nên phức tạp hơn (chi tiết hơn ở Mục 3.1 ), nhưng từ góc độ trải nghiệm người dùng, việc giải quyết giao dịch nguyên tử sẽ được duy trì đầy đủ.

Nhược điểm của PEPC trong việc ưu tiên hủy:

• Vấn đề khởi động nguội: Điểm yếu lớn nhất của PEPC là tính tự nguyện của nó. Tương tự như xác nhận trước, việc ưu tiên hủy được thực thi bởi PEPC sẽ yêu cầu một số lượng lớn người xác thực để có thể sử dụng được. Để có được quyền ưu tiên hủy, chỉ những người xác thực đã chọn tham gia mới đủ điều kiện cập nhật trạng thái của hợp đồng. Nếu chỉ 1/10 số người xác thực Ethereum (vẫn là một con số khổng lồ!) cam kết ưu tiên hủy, ứng dụng sẽ chỉ được cập nhật trung bình một lần mỗi 10 khối, điều này quá chậm đối với nhiều trường hợp giao dịch.
• Cần thay đổi cơ chế đồng thuận: Cơ chế L1 của Ethereum cần được thay đổi để các điều kiện về tính hợp lệ của khối có thể phụ thuộc vào các cam kết của PEPC.

(3) Đặt hàng do ứng dụng chỉ định được thực thi bằng sự đồng thuận

PEPC thực chất là một thị trường tự nguyện giữa các nhà thiết kế ứng dụng và các trình xác thực để đạt được thỏa thuận, và gặp phải vấn đề khởi đầu chậm (cold-start problem). Một hướng đi tương đối chưa được khám phá là bắt buộc sự tham gia đối với các trình xác thực. Điều này dường như là kịch bản lý tưởng: một máy chủ L1 đa năng với một tập hợp các trình xác thực phi tập trung hoạt động như một điểm Schelling cho tính thanh khoản và hoạt động kinh tế, cho phép các nhà phát triển ứng dụng kiểm soát thứ tự các giao dịch của họ mà không cần khởi tạo ban đầu. Nhưng liệu điều đó có khả thi?

Câu trả lời phần lớn là có, mặc dù các chi tiết lại khá phức tạp. Trong phần còn lại của bài viết này, chúng ta sẽ xem xét thay đổi đơn giản nhất đối với cơ chế đồng thuận của Ethereum có thể cho phép Hyperliquid ưu tiên các yêu cầu hủy trước các yêu cầu thực hiện giao dịch. Chúng tôi muốn nhấn mạnh rằng phạm vi thiết kế phong phú hơn nhiều so với giải pháp mà chúng tôi đã đề xuất ở đây và cần được nghiên cứu thêm để khám phá một cách đầy đủ.

Hãy xem xét một sự sửa đổi đơn giản của ngôn ngữ hợp đồng thông minh cho phép mỗi hợp đồng chỉ định thứ tự thực hiện các chức năng của nó trong từng khối. Ví dụ, chúng ta có thể mã hóa ưu tiên hủy bỏ như sau:

 DEX contract func Take ; func Cancel ; order = [Cancel, Take]

Hiện tại, trong bất kỳ khối nào, các giao dịch gọi một trong hai hàm trên hợp đồng DEX đều cần tuân thủ thứ tự thực hiện để khối đó được coi là hợp lệ. Hình dưới đây minh họa một ví dụ với hai hợp đồng, bốn giao dịch và một khối duy nhất.

upload_6293557cdc347eb3614eef9185df2c63-1 1038×1526 105 KB

Một vài lưu ý về hình ảnh:

• Có hai loại hợp đồng: DEX và Oracle, mỗi loại có hai chức năng riêng biệt.
• Đối với DEX, bất kỳ lệnh Hủy nào cũng phải được thực hiện trước bất kỳ lệnh Nhận nào trong cùng một khối lệnh.
• Đối với Oracle, bất kỳ thao tác Cập nhật nào cũng phải được thực hiện trước bất kỳ thao tác Đọc nào trong cùng một khối.
• Có bốn giao dịch thực hiện các lệnh gọi hàm khác nhau đến các hợp đồng DEX và Oracle.
• Khối cuối cùng bao gồm chuỗi [TX2, TX1, TX3] , có thứ tự gọi hàm như sau: [DEX::Cancel, DEX::Take, Oracle::Update, DEX::Take] .
• Thứ tự đặt hàng cuối cùng tuân thủ các quy tắc đặt hàng địa phương của cả hai hợp đồng.
• TX3 và TX4 loại trừ lẫn nhau, vì cả hai thứ tự [TX3, TX4] và [TX4, TX3] đều vi phạm một trong các quy tắc sắp xếp hợp đồng. Chi tiết hơn về điều này trong Phần 3.1 .

Về cơ bản, không có lý do gì ngăn cản việc trao quyền kiểm soát này cho các ứng dụng bằng cách thay đổi ngôn ngữ hợp đồng thông minh và thực thi nó tại thời điểm đồng thuận (đây chính xác là những gì Hyperliquid đã làm với việc ưu tiên hủy bỏ). Xét về nhiều khía cạnh, việc thực hiện ACE trong giao thức là một giải pháp tối ưu hơn so với bốn phương án thay thế đã nêu ở trên (ví dụ: nó thực chất là PEPC, trong đó người đề xuất được yêu cầu tuân thủ các ràng buộc về thứ tự do các ứng dụng chỉ định). Đặc biệt, nó có cơ chế thanh toán gốc, có cùng các đảm bảo như cơ chế đồng thuận L1 mà không cần thêm giả định về độ tin cậy, và giải quyết vấn đề khởi động nguội bằng cách yêu cầu sự tham gia của người xác thực.

Tuy nhiên, cũng có một số nhược điểm rõ ràng, đặc biệt khi xem xét độ phức tạp hạn chế của việc xây dựng khối trên L1 (đây là mục tiêu rõ ràng của Ethereum) và khả năng kết hợp các ứng dụng trong cùng một chuỗi (đây là đặc điểm nổi bật của các nền tảng hợp đồng thông minh nói chung). Các phần tiếp theo sẽ khám phá từng vấn đề này với các ví dụ cụ thể.

(3.1) Độ phức tạp của việc xây dựng khối

Việc cho phép các hợp đồng chỉ định các ràng buộc về thứ tự thực hiện làm tăng độ phức tạp của việc xây dựng các khối hợp lệ. Để minh họa điều này, chúng ta nên xem xét việc xây dựng khối trong Ethereum hiện nay. Mặc dù hầu hết các khối được xây dựng thông qua PBS bởi những người xây dựng khối chuyên nghiệp, nhưng khoảng 8% khối vẫn được xây dựng trực tiếp bởi người đề xuất (xem mevboost.pics ). Mặc dù việc đóng gói khối tối đa hóa phí ưu tiên trong giới hạn gas là NP-complete (bài toán ba lô 0/1), hầu hết các khối đều nằm dưới dung lượng tối đa, và việc đơn giản là bao gồm tất cả các giao dịch hợp lệ và trả phí cơ bản trong mempool thường là khả thi. Nếu có nhiều giao dịch trong mempool hơn giới hạn gas của khối, việc chỉ cần chạy thuật toán tham lam theo phí ưu tiên sẽ cung cấp một phương pháp phỏng đoán tốt cho những người muốn xây dựng khối của họ theo cách đơn giản. Ngay cả khi một số giao dịch bị đảo ngược, việc bao gồm chúng trong khối vẫn hợp lệ và chúng trả phí gas trên mỗi đơn vị cần thiết để xử lý cho đến khi bị đảo ngược. Người xây dựng địa phương có thể tiếp tục thêm các giao dịch có tiền boa cao nhất cho đến khi khối đầy, và đảm bảo rằng khối đó hợp lệ và doanh thu tiền boa đạt ít nhất 1/2 mức tối ưu.

Nếu chúng ta cho phép các hợp đồng thông minh chỉ định các quy tắc sắp xếp cho từng khối (như trên), thì ngay cả việc tìm ra một khối hợp lệ duy nhất (với mức phí giao dịch hợp lý) trong một danh sách các giao dịch đang chờ xử lý cũng có thể trở nên phức tạp. Ví dụ sau đây minh họa điều này. Chúng ta xem xét hai loại giao dịch và sử dụng tên hàm theo kiểu UniswapV2.

1. SWAP là giao dịch trao đổi một tài sản trong nhóm tài sản lấy một tài sản khác (gọi là "giao dịch nhận").
2. Lệnh REMOVE rút thanh khoản khỏi nhóm ở một mức giá cụ thể (tức là "hủy bỏ").

Chúng tôi cho phép hợp đồng thông minh quy định rằng, trong mỗi khối, bất kỳ lệnh gọi REMOVE nào cũng phải được thực hiện trước bất kỳ lệnh gọi SWAP (hủy ưu tiên). Trong ví dụ này, cả REMOVE và SWAP đều có thể thay đổi tỷ giá. Đối với REMOVE, bạn có thể hình dung rằng LP có thể loại bỏ một token cụ thể khỏi pool và thay đổi giá. Đối với SWAP, quy mô của giao dịch hoán đổi sẽ quyết định tỷ giá có thay đổi hay giữ nguyên.

Hãy xem xét ba giao dịch giả định, hành vi của chúng phụ thuộc vào tính ngang giá của nhóm thanh toán khi chúng bắt đầu được thực hiện, và phần trong ngoặc đơn cho biết tác động của thao tác đó đến tính ngang giá của giá cả.

Tất cả các giao dịch đều có thể là REMOVE hoặc SWAP, tùy thuộc vào tính chẵn lẻ. Hãy xem xét một khối ứng cử viên [TX1, TX2, TX3] ; chúng ta hãy xem điều gì xảy ra khi nhóm bắt đầu ở trạng thái chẵn.

1. TX1 thực hiện trước và thực hiện SWAP, đảo ngược tính ngang bằng của giá thành số lẻ.
2. TX2 nhận thấy giá trong nhóm là số lẻ, do đó cố gắng thực hiện lệnh REMOVE.

Chúng ta đã gặp vấn đề rồi! Quy tắc sắp xếp của chúng ta quy định rằng các lệnh REMOVE phải đứng trước các lệnh SWAP, vì vậy [TX1, TX2, TX3] không phải là thứ tự thực thi hợp lệ. Trên thực tế, trong tất cả 3 ! = 6 hoán vị của thứ tự giao dịch, chỉ có hai hoán vị bắt đầu bằng TX3 là hợp lệ. Danh sách bên dưới hiển thị thứ tự của từng ứng viên và các lệnh gọi hàm kết quả. Hãy nhớ rằng giá trị ngang bằng trong pool ban đầu là chẵn.

• 123 : 1 (ĐỔI: lẻ) → 2 (XÓA: lẻ) → 3 (ĐỔI: lẻ)
  • Kết quả: SWAP, REMOVE, SWAP => không hợp lệ
• 132 : 1 (ĐỔI: lẻ) → 3 (ĐỔI: lẻ) → 2 (LOẠI BỎ: lẻ)
  • Kết quả: SWAP, SWAP, REMOVE => không hợp lệ
• 213 : 2 (ĐỔI: lẻ) → 1 (XÓA: lẻ) → 3 (ĐỔI: lẻ)
  • Kết quả: SWAP, REMOVE, SWAP => không hợp lệ
• 231 : 2 (ĐỔI: lẻ) → 3 (ĐỔI: lẻ) → 1 (XÓA: lẻ)
  • Kết quả: SWAP, SWAP, REMOVE => không hợp lệ
• 312 : 3 (BỎ: lẻ) → 1 (BỎ: lẻ) → 2 (BỎ: lẻ)
  • Kết quả: XÓA, XÓA, XÓA => hợp lệ
• 321 : 3 (BỎ: lẻ) → 2 (BỎ: lẻ) → 1 (BỎ: lẻ)
  • Kết quả: XÓA, XÓA, XÓA => hợp lệ

Tất nhiên, giá của nhóm cũng có thể là số lẻ ở đầu khối. Trong trường hợp đó, [TX3, TX2, TX1] và [TX3, TX1, TX2] đều là các thứ tự không hợp lệ , và các thứ tự hợp lệ duy nhất là [TX1, TX2, TX3] và [TX2, TX1, TX3] .

Ngay cả với ví dụ đơn giản và ba giao dịch, chúng ta cũng phải kiểm tra rất nhiều hoán vị để tìm ra một thứ tự hợp lệ. Với nhiều giao dịch hơn, nhiều hàm hơn và nhiều ràng buộc hơn, bài toán tìm thứ tự hợp lệ trở nên phức tạp hơn về mặt tổ hợp.

(3.2) Khả năng kết hợp

Ngoài sự phức tạp trong việc xây dựng khối, ACE còn làm suy yếu khả năng kết hợp mà các hợp đồng thông minh và giao dịch thường có được khi thực thi trên cùng một blockchain. Hãy xem xét trường hợp hai DEX (A và B) đều có cùng quy tắc sắp xếp như chúng ta đã mô tả ở trên, trong đó các thao tác REMOVE phải được thực hiện trước các thao tác SWAP:

• Tất cả REMOVE(A) phải được thực hiện trước tất cả SWAP(A)
• Tất cả lệnh REMOVE(B) phải được thực hiện trước tất cả lệnh SWAP(B)

Bây giờ, hãy tưởng tượng hai giao dịch sau trong mempool:

• TX1: XÓA (A) + HOÁN ĐỔI (B)
• TX2: XÓA (B) + HOÁN ĐỔI (A)

Mặc dù những điều này có vẻ tùy tiện, hãy xem xét trường hợp giá ngoài chuỗi biến động đáng kể, và Alice có vị thế LP trong nhóm A, còn Bob có vị thế LP trong nhóm B. Cả Alice và Bob đều đang cố gắng rút thanh khoản của họ khỏi nhóm, nơi cả hai đều có giá cũ, và họ cũng muốn sử dụng các token LP đã rút để hoán đổi với giá cũ của nhóm kia.

Lưu ý rằng các giao dịch kết quả không thể được gộp chung vì bất kỳ giao dịch nào xảy ra trước giao dịch kia đều vi phạm một trong hai quy tắc sắp xếp được áp dụng trên mỗi DEX riêng biệt. Tất nhiên, Alice và Bob có thể tách các lệnh REMOVE của họ khỏi các lệnh SWAP tương ứng, nhưng khi đó tính nguyên tử trong hành động của họ không còn được bảo toàn, và họ có thể không có đủ vốn cần thiết để thực hiện lệnh SWAP trên pool khác trừ khi họ rút thanh khoản khỏi pool của mình.

Ví dụ khác, hãy xem xét các quy tắc sắp xếp sau đây cho Oracle và DEX.

• Oracle: Lệnh UPDATE phải được thực hiện trước lệnh READ.
• DEX: Lệnh REMOVE phải được thực hiện trước lệnh SWAP.

Oracle muốn đảm bảo rằng mọi thao tác đọc đều có quyền truy cập vào dữ liệu mới nhất, và DEX tiếp tục sử dụng quy tắc ưu tiên hủy bỏ của chúng ta. Bây giờ hãy xem xét hai giao dịch sau:

• TX1: CẬP NHẬT (ORACLE) + TRAO ĐỔI (DEX)
• TX2: ĐỌC (ORACLE) + XÓA (DEX)

Một lần nữa, cả hai giao dịch đều có thể phát sinh một cách tự nhiên. Trong giao dịch đầu tiên, người dùng cập nhật giá từ Oracle và thực hiện hoán đổi nguyên tử sau đó. Trong giao dịch thứ hai, giá Oracle được đọc trước khi vị thế LP bị xóa. Tuy nhiên, cả hai giao dịch không thể được đưa vào cùng một khối, vì điều đó sẽ dẫn đến vi phạm thứ tự trong một trong hai hợp đồng. Một lần nữa, các hành động có thể được tách thành các giao dịch riêng lẻ để được sắp xếp lại, nhưng khả năng kết hợp giữa hai ứng dụng này bắt đầu bị phá vỡ.

Độ phức tạp của việc xây dựng khối càng tăng lên dưới các quy tắc sắp xếp khác nhau và nhiều giao dịch tương tác với nhiều hợp đồng. Hãy xem xét ví dụ sau, trong đó mỗi giao dịch thực hiện một lệnh gọi đến hợp đồng Oracle và một lệnh gọi đến hợp đồng DEX.

Một lần nữa, hãy xem điều gì xảy ra khi chúng ta thử chuỗi [TX1, TX2, TX3] . Rõ ràng điều này không hoạt động vì cả quy tắc sắp xếp của Oracle và DEX đều bị vi phạm. Ở đây, chuỗi duy nhất tạo ra một tập hợp giao dịch hợp lệ là [TX3, TX2, TX1] . Mỗi gạch đầu dòng bên dưới hiển thị một thứ tự ứng cử viên.

• 123 : 1 (ĐỌC, HOÁN ĐỔI) \to → 2 (ĐỌC, XÓA) \to → 3 (CẬP NHẬT, XÓA)
  • (READ đứng trước UPDATE) và (SWAP đứng trước REMOVE) => Không hợp lệ
• 132 : 1 (ĐỌC, HOÁN ĐỔI) \to → 3 (CẬP NHẬT, XÓA) \to → 2 (ĐỌC, XÓA)
  • (READ đứng trước UPDATE) và (SWAP đứng trước REMOVE) => Không hợp lệ
• 213 : 2 (ĐỌC, XÓA) \to → 1 (ĐỌC, HOÁN ĐỔI) \to → 3 (CẬP NHẬT, XÓA)
  • (READ đứng trước UPDATE) và (SWAP đứng trước REMOVE) => Không hợp lệ
• 231 : 2 (ĐỌC, XÓA) \to → 3 (CẬP NHẬT, XÓA) \to → 1 (ĐỌC, HOÁN ĐỔI)
  • (READ đứng trước UPDATE) => Không hợp lệ
• 312 : 3 (CẬP NHẬT, XÓA) \to → 1 (ĐỌC, HOÁN ĐỔI) \to → 2 (ĐỌC, XÓA)
  • (SWAP đứng trước REMOVE) => Không hợp lệ
• 321 : 3 (CẬP NHẬT, XÓA) \to → 2 (ĐỌC, XÓA) \to → 1 (ĐỌC, HOÁN ĐỔI) => Hợp lệ

Ở một khía cạnh nào đó, bài toán xây dựng khối trong ví dụ này dễ giải quyết hơn so với việc kiểm tra tính chẵn lẻ của nhóm trong ví dụ trước, bởi vì thứ tự thực hiện các hàm có thể được kiểm tra trước khi chạy các giao dịch. Tuy nhiên, vấn đề vẫn là cần nhiều phép tính hơn để tìm ra thứ tự hợp lệ của cả ba giao dịch so với việc sắp xếp tham lam đơn giản theo phí ưu tiên. Hơn nữa, các ví dụ phức tạp hơn có thể dễ dàng được xây dựng, trong đó hàm mà giao dịch gọi trên DEX hoặc hợp đồng Oracle phụ thuộc vào giá của nhóm và/hoặc nguồn cấp dữ liệu giá từ Oracle, và những giá trị này thay đổi trong quá trình thực thi.

(3.3) Các biện pháp thích ứng và giảm thiểu có thể

Trong phần trước, chúng ta đã thấy rằng việc đưa ACE vào một thuật toán L1 đa năng là khả thi với những thay đổi nhỏ về cơ chế đồng thuận, nhưng đổi lại là sự phức tạp tăng lên trong quá trình xây dựng khối. Sự phức tạp tăng lên trong quá trình xây dựng khối có một số nhược điểm. Nó có thể dẫn đến sự tập trung hóa vì nó khiến cho các nhà xây dựng khối địa phương (những người xác thực không chuyên nghiệp, tự xây dựng khối của riêng họ thay vì thuê ngoài) khó có thể đạt được mức doanh thu phí giao dịch tối ưu. Thêm vào đó, và có lẽ quan trọng hơn, người dùng, ví điện tử và giao diện người dùng sẽ phải điều chỉnh logic phí giao dịch và tập hợp các hàm mà họ chọn để gọi nhằm tính đến sự phức tạp gia tăng trong việc sắp xếp trình tự các giao dịch của họ.

Ví dụ, những người dùng có ưu tiên cao về tính kịp thời của việc đưa giao dịch vào (ví dụ: những người muốn hủy khẩn cấp để ngăn chặn các báo giá lỗi thời bị loại bỏ) có thể làm cho logic giao dịch của họ đơn giản nhất có thể và dễ phân tích tĩnh bởi trình xây dựng. Điều này cho phép trình xây dựng dự đoán tốt hơn hành vi giao dịch trước đó mà không cần phải chạy lại ở các vị trí khác nhau trong khối. Tuy nhiên, việc hướng đến sự đơn giản này có thể bị hạn chế và cản trở khả năng kết hợp. Khi các giao dịch trở nên phức tạp hơn và tương tác với nhiều hợp đồng hơn, sự tự tin của trình xây dựng vào dự đoán tĩnh của họ về các chức năng và hợp đồng mà một giao dịch sẽ tác động sẽ giảm xuống. Một giao dịch đủ phức tạp có thể dễ thay đổi hành vi đến mức trình xây dựng có thể đơn giản là loại bỏ nó (hoặc có thể loại bỏ nhiều giao dịch khác do việc đưa giao dịch phức tạp đó vào). Vì vậy, điều này đặt ra sự đánh đổi giữa khả năng biểu đạt và thời gian dự kiến để đưa giao dịch vào. Ngay cả các giao dịch không tương tác với các hợp đồng được sắp xếp theo ACE cũng chia sẻ không gian khối với các giao dịch có tương tác, có nghĩa là chúng cũng phải cân nhắc sự đánh đổi này, vì không có cách nào hoàn toàn đáng tin cậy để báo hiệu hành vi chính xác của giao dịch trước khi thực thi.

Xin lưu ý rằng chúng tôi không đưa ra những nhận định chính thức về nhiều vấn đề nêu trên. Ví dụ, chúng tôi không định lượng chính xác mức độ suy giảm tính khả thi của mô hình theo hàm số của khả năng biểu đạt. Chúng tôi cũng không mô hình hóa cách mà độ tin cậy của người xây dựng bị ảnh hưởng bởi độ phức tạp của giao dịch. Cả hai hướng nghiên cứu này đều rất thú vị và cần được tiếp tục. Ví dụ, hướng nghiên cứu thứ nhất đòi hỏi phải mô hình hóa rõ ràng các đảm bảo về độ chính xác của các thuật toán xây dựng khối khác nhau, và hướng nghiên cứu thứ hai đòi hỏi kiến thức chuyên môn về phân tích tĩnh/động trên EVM/SVM. Mục tiêu của chúng tôi ở đây là nêu bật những sự đánh đổi thú vị này một cách định tính, và hy vọng thuyết phục được các chuyên gia trong lĩnh vực này rằng đây là những câu hỏi hay đáng để khám phá.

Tín hiệu rõ ràng

Thay vì yêu cầu các nhà xây dựng khối phải gánh vác toàn bộ việc phân tích trình tự giao dịch, giao thức có thể hỗ trợ hoặc yêu cầu tín hiệu rõ ràng hơn bằng cách thêm siêu dữ liệu cho các giao dịch để xác nhận trước các chức năng mà chúng sẽ gọi. Trong Ethereum, cam kết trước cho các giao dịch này tương tự như Danh sách truy cập khối (Block-Access Lists ), hiện đang được xem xét để đưa vào đợt phân nhánh cứng tiếp theo. Trong Solana, các giao dịch đã được cam kết với địa chỉ tài khoản , nhưng trong cả hai trường hợp, việc thêm siêu dữ liệu cấp chức năng cũng rất quan trọng để cải thiện khả năng của các nhà xây dựng khối trong việc bắt đầu quá trình sắp xếp mà không cần thực thi trực tiếp các giao dịch.

Với cấu trúc này, các giao dịch chỉ được coi là hợp lệ nếu chúng khai báo chính xác chữ ký hàm của mình, và một giao dịch sẽ bị hủy bỏ nhưng vẫn phải trả phí gas nếu nó gọi một hàm không được khai báo. Cơ chế này sẽ giúp đảm bảo cho những người xây dựng khối rằng họ sẽ nhận được phí gas của mình, và có nghĩa là các giao dịch có thể phức tạp tùy ý mà không gây rủi ro cho tính khả dụng. Tất nhiên, sự thay đổi này sẽ chuyển gánh nặng phân tích sang phía người khởi tạo giao dịch. Mặc dù có vẻ đúng một cách trực quan rằng ví và giao diện người dùng nên có khả năng chỉ định các lệnh gọi hàm của chúng, nhưng có thể có những tình huống phụ thuộc vào trạng thái mà giao dịch không thể biết trước những hàm nào nó sẽ gọi (ví dụ: một giao dịch định tuyến trên chuỗi sẽ không muốn cam kết trước việc gọi hàm hoán đổi trên mỗi DEX mà nó thăm dò khi tìm kiếm giá tốt nhất). Một lần nữa, từ góc nhìn của người không chuyên về lớp thực thi, không gian thiết kế này có vẻ phong phú và đầy hứa hẹn.

Cũng cần lưu ý rằng độ phức tạp của việc xây dựng khối vượt xa độ phức tạp của việc xác thực khối trong ACE. Khi xác thực một khối (ví dụ: với tư cách là người chứng thực quyết định cách bỏ phiếu), danh sách các hợp đồng được truy cập và thứ tự giao dịch có thể được kiểm tra động trong thời gian chạy, và bất kỳ vi phạm nào đối với các quy tắc thứ tự do các hợp đồng đặt ra đều có thể ngay lập tức khiến hàm chuyển trạng thái trả về giá trị không hợp lệ, mà không làm tăng đáng kể độ phức tạp của việc xác minh khối.

(4) Kết luận

Bài viết này khám phá nhiều thiết kế ứng cử viên khác nhau cho ACE thông qua lăng kính ưu tiên hủy. Mỗi thiết kế này đều có những sự đánh đổi khác nhau mà chúng tôi đã nêu bật ở trên. Chúng tôi cũng xem xét việc đưa ACE vào L1 có thể trông như thế nào ở dạng cơ bản, trong đó các hợp đồng có thể chỉ định thứ tự thực hiện các chức năng của chúng mà phải được tuân thủ trong ngữ cảnh của một khối duy nhất. Không gian thiết kế của các quy tắc sắp xếp khả thi mà người ta có thể kích hoạt là rất rộng và đáng để khám phá. Ví dụ, bạn có thể hình dung các quy tắc sắp xếp biểu cảm hơn sẽ được kích hoạt nếu giá trên DEX biến động quá mạnh. Hơn nữa, các quy tắc sắp xếp trình tự có thể phức tạp hơn việc chỉ đơn thuần chỉ định thứ tự thực hiện các chức năng trong một hợp đồng.

ACE là một ví dụ về giao thức áp đặt các ràng buộc về tính hợp lệ bổ sung lên các khối. Những hạn chế này được đưa ra từ các nhà phát triển ứng dụng, những người chỉ định thứ tự các lệnh gọi hàm. Hyperliquid đã chứng minh rằng loại hạn chế này có thể hữu ích cho người dùng cuối, đặc biệt là trong môi trường chuỗi ứng dụng được xây dựng dành riêng cho giao dịch. Ý tưởng này dường như đang hướng đến một không gian thiết kế lớn hơn cho các giao thức, nơi các câu hỏi chính sẽ là

1. Tính khả thi: Những hạn chế nào có thể được áp dụng cho một blockchain đa năng (mà không làm tăng độ phức tạp)?
2. Tính khả thi: những hạn chế nào là tốt cho phúc lợi của người dùng cuối hoặc toàn bộ hệ sinh thái?

Về mặt tinh thần, điều này tương tự như bài báo “ Phân tích tác động kinh tế của việc phân quyền đối với người dùng ”, bài báo này phân tích cách thức việc giao thức cam kết tuân thủ các ràng buộc về nguồn cung ảnh hưởng đến giá cả đối với người dùng cuối. Chúng tôi tin rằng việc mở rộng công trình này sang các cam kết cụ thể cho từng ứng dụng mà giao thức có thể đưa ra là rất có giá trị.

Hy vọng rằng bài viết này đã giúp thống nhất các cơ chế ACE khác nhau thông qua ví dụ về ưu tiên hủy bỏ, làm sáng tỏ một số điểm tinh tế xung quanh ACE bằng cách cung cấp các ví dụ cụ thể minh họa sự phức tạp trong việc xây dựng khối và các vấn đề về khả năng kết hợp, và khám phá tiềm năng của ACE được ghi nhận trong bối cảnh Ethereum. Chúng tôi tin rằng đây là một ý tưởng mạnh mẽ và tiếp tục cần được nghiên cứu và khám phá thêm trong tương lai.