應用控制執行：取消優先級案例研究

應用控制執行：取消優先級案例研究

作者： maryam和mike – 2026 年 1 月 29 日。

簡而言之，應用控制執行（簡稱 ACE）是一種賦予應用程序交易排序控制權的機制。Hyperliquid 的取消優先級機制是目前 ACE 最顯著的例子，它證明了 ACE 可以顯著提升鏈上交易效率。本文分析了四種已提出的 ACE 實現機制，以及它們各自如何實現取消優先級。我們還探討了一種更通用、更規範的 ACE 形式，這種形式可以用智能合約語言實現，並由 L1 共識機制強制執行。在這種模式下，我們通過實例展示了增加區塊構建複雜性和降低可組合性的具體弊端。本文旨在提煉關於不同 ACE 形式的討論。我們希望它能表明這些設計有很多共同之處，並且像取消優先級這樣強大的機制也可以在不增加過多複雜性的情況下實現。

內容

（1）引言
（2）現有設計
\quad （2.1）應用鏈
\quad （2.2）通用鏈條上的批量生產
\quad （2.3）鏈下各方的批量處理
\quad （2.4）協議強制執行的提案人承諾
（3） 共識強制執行的應用程序指定排序
\quad （3.1）積木搭建的複雜性
\quad （3.2）可組合性
\quad （3.3）交易元數據
（4）結論

相關文章

（1）引言

本文研究應用控制執行（簡稱ACE），在這種執行模式下，應用程序可以指定與其交互的事務的順序約束。為了便於討論，我們將採用以下ACE定義。

應用程序控制的執行方式對與其交互的大量事務強制執行排序規則。

應用程序可以自行定義批次的概念，但目前我們將重點關注每個區塊一個批次，這是最自然的選擇。ACE 是一個非常寬泛的概念和定義，因此我們將通過具體關注 Hyperliquid 實現的取消優先級來使其更加具體。我們將使用以下取消優先級定義。

取消優先級機制確保在每個批次中，取消訂單優先於接受訂單。

請注意，根據 Hyperliquid 的說法，“取消訂單和僅發佈訂單的優先級高於 GTC 訂單和 IOC 訂單”（請參閱此處的訂單類型說明）。為簡便起見，我們將“取消訂單”定義為從交易場所移除流動性而不執行交易的訂單，“執行訂單”定義為執行交易的訂單。我們忽略交易所的大部分具體細節（例如，去中心化交易所 (DEX) 與鏈上 CLOB），但如有必要，將在示例中進行說明。

第二部分探討了四種現有的ACE實現方案，並分析了每種方案的優缺點。為了更好地統一這些方案，我們專門研究了取消優先級排序這一任務，即使最初的提案並非針對此用例。
第 3 節考慮了一種更通用的協議內 ACE 實現方式，其中智能合約指定函數順序，共識機制在狀態轉換函數處強制執行該順序。這種“內嵌式”解決方案有兩個直接的缺點：區塊構建複雜度增加和可組合性降低；我們構建了一些小示例來演示這兩個缺點。

（2）現有設計

以下四個小節概述了實現ACE的不同機制，並介紹了每種機制如何實現取消優先級排序。我們分析了每種設計的主要優缺點，但並未窮盡所有方案。

（2.1）應用鏈

Hyperliquid 是首個實現取消優先級機制的加密貨幣項目；Jeff 在這裡闡述了他的動機，並指出此舉有助於確保用戶獲得更低的價差，儘管這會犧牲交易所的交易量（交易量通常被視為虛榮指標）。由於 Hyperliquid 是一個專為交易而設計的應用程序級 L1 服務，因此他們在協議層面實現了這一設計決策：

“這種排序規則由L1鏈上自身強制執行。節點在Hyperliquid L1鏈上執行區塊的唯一正確方法是先對取消訂單和僅發佈訂單進行排序。”
– Hyperliquid 的設計。

這是強制執行應用程序特定排序規則的最簡單、最可靠的方法。下面的時序圖展示了這一流程。“共識階段的強制執行”發生在“驗證區塊”階段，驗證者通過檢查“取消”操作是否在“接受”操作之前來確定區塊的有效性。

upload_ebca492ec3e2ad44731712d27495d28c 1070×1276 76.8 KB

應用鏈在取消優先級排序方面的優勢：

• 精細化控制：作為應用鏈，應用程序對其執行環境擁有最大程度的控制權。賦予每個應用鏈對區塊構建和驗證方式的控制權一直是 Cosmos 生態系統的長期理念（儘管這些獨立域之間的互操作性尚未實現）。應用鏈還可以通過其他一些特定的方式來生成區塊空間。例如， Injective以與區塊生成速度相同的速度運行頻繁的批量拍賣。每個交易不是按順序處理，而是作為一個批次併發執行。類似地， dYdX使用投票擴展來限制區塊提議者的權力，方法是限制提議者可以排除的交易集合（這與FOCIL的設計非常相似）。

應用鏈在取消優先級方面的缺點：

• 抗審查性： Hyperliquid排序規則（以及一般的應用鏈承諾）的穩健性僅取決於鏈及其驗證者集合的抗審查性。提議者始終可以通過完全排除取消操作來執行接受操作，而不是取消操作。雖然這會放棄取消操作的交易費收入，但如果market maker 1願意賄賂提議者，那麼這種做法可能是合理的。
• “僅橋接”結算：在本分析中，我們將“結算”定義為交易被納入通用 L1 區塊鏈到交易輸出可在通用 L1 區塊鏈上的其他應用程序中使用之間的延遲時間。雖然這對 Hyperliquid 和其他應用鏈來說似乎不公平，但它們確實與加密貨幣市場的其他部分隔離，而且大多數已存在於主流公鏈上的資產的網絡效應非常頑固。為了與以太坊 L1 區塊鏈上的 Hyperliquid 交易輸出進行交互，資產必須首先進行橋接，這會引入顯著的延遲（可能長達幾個區塊）。尤其值得注意的是，Hyperliquid 與任何其他區塊鏈之間都不存在有效的原子結算。

Hyperliquid 已經證明，如果一個應用程序能夠完全控制其排序，那麼它應該根據應用程序的具體用例做出有針對性的決策。Atlas 團隊也提出了類似的觀點，認為他們在“DeFi 專用 L2”框架下所做的決策也應如此。

然而，由於構建的是獨立鏈，應用鏈也面臨著與以太坊 L2 層相同的碎片化問題。為了應對這種碎片化，一些應用會選擇直接構建在以太坊和 Solana 等通用區塊鏈上，以利用其他運行在同一狀態的應用所實現的原子性。這些應用無法控制共識規則，必須通過公鏈上的智能合約代碼以及任何必要的協議外基礎設施來實現。以下兩節將探討一些針對這些應用的擬議設計，並與我們之前看到的案例進行比較。

（2.2）通用鏈條上的批量生產

Cavey、Jakob 和 Max 提出了“異步消息隊列”（簡稱 AMQ），作為一種使應用程序能夠在 Solana 上實現取消優先級機制的方法。該機制的工作原理如下：

1. 在區塊 N 中，異步交易會被放入隊列，但不會執行。該隊列作為智能合約的狀態保存，並用作批次。
2. 在區塊 N+1 中，排隊的交易將作為一個批次執行。 “執行”本身也是一個交易，它按照應用程序指定的優先級順序觸發交易。

下圖展示了分兩個模塊進行的這一過程。

upload_08c603422b911a7eed4b9f0ac5f4684a 1010×1356 86 KB

使用 AMQ 進行取消優先級排序的優點：

• 共識機制無需改變：通過使用 L1 狀態和時間戳，目前可以在 Solana（或以太坊）上使用智能合約實現 AMQ，而無需對核心協議進行任何更改。

AMQ 取消優先級設置的缺點：

• 交易延遲：交易發起和結算之間至少存在一個區塊的延遲。雖然取消交易的優先級設置可以提升流動性和執行速度，但用戶體驗顯然會受到影響，因為用戶需要等待額外的區塊才能完成交易（儘管由於區塊時間限制，這對於以太坊來說可能比 Solana 更為嚴重）。目前有兩種可能的解決方案，但都需要修改共識規則。首先，區塊鏈可以允許“定時交易”，即在每個區塊末尾執行一批交易。其次，區塊鏈可以允許合約內省每筆交易在區塊中的位置。有了這種信息，合約就能知道最後一筆交易的時間，並可以在其後立即觸發該批交易的執行（這種“回調”機制類似於UniV4 的鉤子）。
• “下一區塊”結算：由於交易延遲，正如AMQ 帖子中指出的，交易執行的異步特性導致無法與同一區塊內的其他 Solana 交易進行原子結算。即使區塊 N 中不再有 AMQ 交易（因此批量執行的結果確定無疑），交易結算也要到區塊 N+1 才會發生，因此區塊 N 中的任何交易都無法與這些輸出進行交互（例如，償還閃電貸）。
• 審查：與上述應用鏈設計類似，AMQ機制的可信度很大程度上取決於底層鏈的抗審查能力。Solana驗證者可以簡單地審查區塊N中所有傳入的取消請求，從而使優先級隊列失效。作者已直接承認這一點。

  “與所有其他不涉及多個提議者的 ACE 形式類似，驗證者仍然可以通過審查和延遲在協議強制執行的 tick 邊界內繞過 AMQ。”
  – 執行 ACE 。

AMQ 依賴 Solana 驗證器來執行 ACE 協議。一些應用程序可能會選擇鏈下批量處理方案，以便將信任轉移給與其應用程序更契合的第三方。

（2.3）鏈下各方的批量處理

另一種實現應用特定排序規則的方法是將排序權委託給鏈下實體。Sorella 在以太坊上實現了一個混合鏈上鍊下去中心化交易所 (DEX)。他們的設計利用了一種獨立的共識機制來確定要針對以太坊 L1 持有的流動性頭寸執行的交易批次。

注1 ：在Uniswap術語中，取消（cancel）是指“移除流動性頭寸”。同樣，接受（take）就是指“互換”。

注2 ：正如之前所提議的，Sorella並未實施取消優先級機制。他們目前專注於捆綁包頂部拍賣和批量清算交易。然而，取消優先級機制在他們的模型下很容易實現，因此我們以此為例來闡明不同設計之間的共性。

下圖顯示了 Sorella 上一個假設的取消優先級流程。

upload_0b068c9d53c36619ed691c39cfeced44 946×1048 62.1 KB

鏈下批量處理取消優先級排序的優勢：

• 共識機制不變：與 AMQ 一樣，鏈下批處理目前可以在通用 L1 上完全實現，無需修改核心協議。

鏈下批量處理取消優先級排序的缺點：

• 實時性：由於 Sorella 依賴於與以太坊不同的共識機制，因此承擔了額外的實時性風險。如果 Sorella 的共識機制停滯或出現惡意行為，交易者和流動性提供者將無法與該應用程序進行交互。作者特別提到了這一點：

  “因此，[ACE] 不可避免地會引入外部各方，從而引入額外的活性和信任假設。”
  –活性和信任假設。

• 審查：應用鏈和鏈上批處理帶來的審查問題依然存在。特別是，排序規則無法防止 Sorella 提議者忽略即將到來的取消操作，而選擇執行已有的提議。另一方面，由於 Sorella 共識參與者是 Sorella 的主要利益相關者，因此可以認為，與通用 L1 驗證者相比，驗證者的激勵機制與項目的長期成功更為緊密相關。
• “捆綁後”結算： Sorella 無法直接與以太坊交易組合，因為所有 Sorella 交易都被捆綁成一個原子單元，該單元以原子方式與 L1 池進行交易。然而，一旦 Sorella 捆綁包被放入區塊，交易即完全結算，任何後續交易（即使在同一個以太坊區塊內）都可以使用結算後的狀態。

注3 ：Sorella的共識機制很容易被其他交易排序機制所替代。例如， BuilderNet使用TEE以可驗證的方式運行區塊構建。Sorella可以進行修改，使其僅允許由委託的TEE簽名的交易包，而不是由Sorella共識的輸出簽名的交易包。在這種模型下，交易的活性、審查和結算機制與之前的模型類似，唯一的區別在於TEE的保證與拜占庭共識的保證在信任假設上的差異。

（2.4）協議強制執行的提案人承諾

Barnabé 概述了協議強制提案人承諾（簡稱PEPC），其提出源於共識職責的演變，尤其是在區塊構建外包給MEV-boost拍賣機制之後。在PEPC機制下，提案人可以承諾採取比承諾支持最終區塊構建者更為通用的行動。與依賴中繼作為可信第三方的MEV-boost機制不同，PEPC承諾將由以太坊共識機制本身強制執行。這種通用性還可以用於直接在以太坊中實現取消優先級機制。下圖展示了這一點。

上傳_c00da71ed53662ee25a7f67ddb26097c 1090×1434 79.5 KB

PEPC在取消優先級方面的優勢：

• 無需額外的信任假設：如果 PEPC 得到實施，提案者所作承諾的執行力度將與以太坊的共識保證一樣強。
• “原生”結算： PEPC 足夠強大，能夠確保取消操作先於獲取操作，同時又不破壞與以太坊其他交易的組合性。區塊構建和驗證過程會變得更加複雜（詳見3.1 節），但從用戶體驗的角度來看，原子結算機制將得到完整保留。

PEPC在取消優先級方面的缺點：

• 冷啟動問題： PEPC面臨的最大弱點在於其自願性。與預確認類似，PEPC強制執行的取消優先級需要相當數量的驗證者才能使其可用。為了獲得取消優先級，只有選擇加入的驗證者才有資格更新合約狀態。即使只有十分之一的以太坊驗證者（這仍然是一個龐大的數字！）承諾使用取消優先級，應用程序平均每10個區塊才會更新一次，這對於許多交易用例來說速度太慢，難以接受。
• 需要對共識機制進行更改：以太坊 L1 共識機制需要進行更改，以便區塊有效性條件可以取決於 PEPC 的承諾。

（3）共識強制執行的應用程序指定排序

PEPC實際上是一個應用開發者和驗證者之間自願參與的市場，旨在達成協議，但它也存在冷啟動問題。一個相對未被探索的方向是強制驗證者參與。這似乎是理想的場景：一個通用的L1層級，其去中心化的驗證者集合作為流動性和經濟活動的謝林點，使應用開發者能夠控制其交易的順序，而無需任何引導程序。但這真的可行嗎？

答案基本是肯定的，但細節卻出人意料地微妙。在本文的剩餘部分，我們將探討以太坊共識機制中最簡單的改動，該改動或許能夠實現 Hyperliquid 優先處理取消交易而非交易。我們想強調的是，設計空間遠比我們在此提出的方案豐富得多，值得進一步研究和探索。

考慮對智能合約語言進行簡單的修改，允許每個合約指定其函數在每個區塊中的執行順序。例如，我們可以將取消優先級編碼為

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

現在，在任何一個區塊中，調用 DEX 合約上任一函數的交易都需要遵循一定的順序，該區塊才能有效。下圖展示了一個包含兩個合約、四筆交易和一個區塊的示例。

upload_6293557cdc347eb3614eef9185df2c63-1 1038×1526 105 KB

關於該圖表的幾點說明：

• 有兩種合約：DEX 和 Oracle，每種合約分別具有兩個功能。
• 對於 DEX 來說，任何 Cancel 操作都必須位於代碼塊內的任何 Take 操作之前。
• 對於 Oracle 來說，在代碼塊內，任何 Update 操作都必須先於任何 Read 操作。
• 有四筆交易涉及對 DEX 和 Oracle 合約的各種函數調用。
• 最後一個塊包含序列[TX2, TX1, TX3] ，其函數調用順序如下： [DEX::Cancel, DEX::Take, Oracle::Update, DEX::Take] 。
• 最終的訂購順序遵循兩份合同的當地訂購規則。
• TX3和TX4是互斥的，因為[TX3, TX4]和[TX4, TX3]兩種排序方式都違反了合約排序規則。更多內容請參見第 3.1 節。

沒有根本原因阻止我們通過修改智能合約語言並在共識階段強制執行來賦予應用程序這種控制權（Hyperliquid 實際上就是通過取消優先級機制來實現的）。在許多方面，協議內執行 ACE 比前面提到的四種替代方案更簡潔（例如，它實際上就是 PEPC，其中提議者必須遵守應用程序指定的排序約束）。特別是，它具有原生結算功能，擁有與 L1 共識相同的保證，無需額外的信任假設，並且通過要求驗證者參與解決了冷啟動問題。

然而，以太坊也存在一些明顯的缺點，尤其是在考慮到L1區塊構建的複雜性有限（這是以太坊的明確目標）以及同一條鏈上應用程序的可組合性（這是智能合約平臺的普遍特徵）時。以下各小節將通過具體示例探討這些問題。

（3.1）積木搭建的複雜性

允許合約指定排序約束會增加構建有效區塊的複雜性。為了更好地說明這一點，我們可以考慮一下以太坊當前的區塊構建方式。雖然大多數區塊是由經驗豐富的區塊構建者通過 PBS 構建的，但仍有大約 8% 的區塊是由提議者直接構建的（參見mevboost.pics ）。儘管將優先級最高的交易費最大化的區塊打包到 gas 限制內是 NP 完全問題（0/1 揹包問題），但大多數區塊遠低於最大容量，因此通常只需將所有有效且支付基本交易費的交易都包含在內存池中即可。如果內存池中的交易數量超過了區塊 gas 限制，那麼對於那些希望以簡單方式構建區塊的人來說，只需運行按優先級交易費排序的貪婪算法即可提供一個很好的啟發式方法。即使某些交易被撤銷，將它們包含在區塊中仍然有效，並且它們會支付在撤銷之前處理所需的單位 gas。本地建造者可以繼續添加小費最高的交易，直到區塊填滿為止，並確保生成的區塊有效，且其小費收入至少達到最優值的 1/2。

如果我們允許智能合約指定每個區塊的排序規則（如上所述），那麼即使只是從待處理交易列表中找到一個有效的區塊（並保證合理的手續費收入），也會變得非常複雜。以下示例對此進行了說明。我們考慮兩種交易類型，並使用 UniswapV2 風格的函數名稱。

1. SWAP 將資產池中的一種資產交換為另一種資產（“換取”）。
2. REMOVE 以特定價格從資金池中移除流動性（“取消”）。

我們讓智能合約規定，在每個區塊中，所有 REMOVE 調用必須先於所有 SWAP 調用（取消優先級）。在我們的示例中，REMOVE 和 SWAP 都會改變價格的平價。對於 REMOVE 操作，您可以想象流動性提供者 (LP) 可以從資金池中移除特定代幣並改變價格。對於 SWAP 操作，交換的大小決定了價格的平價是改變還是保持不變。

考慮三個假設的交易，它們的行為取決於它們開始執行時資金池價格的平價性，括號表示該操作對價格平價性的影響。

所有交易都可能是 REMOVE 或 SWAP，具體取決於奇偶校驗。考慮候選區塊[TX1, TX2, TX3] ；讓我們看看當池子處於偶數狀態時會發生什麼。

1. TX1 首先執行並進行互換，將價格的平價變為奇數。
2. TX2 發現池價格異常，因此嘗試執行 REMOVE 操作。

我們已經遇到問題了！我們的排序規則規定 REMOVE 操作必須先於 SWAP 操作執行，因此[TX1, TX2, TX3]不是有效的執行順序。事實上，在所有3! = 6種交易順序排列中，只有以 TX3 開頭的兩種是有效的。下面的列表顯示了每個候選順序及其對應的函數調用。請記住，資金池的價格平價一開始就是偶數。

• 123 : 1（交換：奇數）→ 2（移除：奇數）→ 3（交換：奇數）
  • 結果：SWAP，REMOVE，SWAP => 無效
• 132 : 1 (交換：奇數) → 3 (交換：奇數) → 2 (移除：奇數)
  • 結果：SWAP、SWAP、REMOVE => 無效
• 213 : 2 (交換：奇數) → 1 (移除：奇數) → 3 (交換：奇數)
  • 結果：SWAP，REMOVE，SWAP => 無效
• 231 : 2 (交換：奇數) → 3 (交換：奇數) → 1 (移除：奇數)
  • 結果：SWAP、SWAP、REMOVE => 無效
• 312 : 3 (移除：奇數) → 1 (移除：奇數) → 2 (移除：奇數)
  • 結果：刪除，刪除，刪除 => 有效
• 321 : 3 (移除：奇數) → 2 (移除：奇數) → 1 (移除：奇數)
  • 結果：刪除，刪除，刪除 => 有效

當然，區塊開始時池價格也可能是奇數。在這種情況下， [TX3, TX2, TX1]和[TX3, TX1, TX2]現在都是無效的訂單，唯一有效的訂單是[TX1, TX2, TX3]和[TX2, TX1, TX3] 。

即使僅使用我們這個簡單的示例和三個交易，我們也需要檢查大量的排列組合才能找到一個有效的排序。隨著交易數量、函數數量和約束條件的增加，尋找有效排序的問題在組合邏輯上會變得更加複雜。

（3.2）可組合性

除了區塊構建的複雜性之外，ACE 還削弱了智能合約和交易在同一區塊鏈上執行時通常享有的可組合性。假設兩個去中心化交易所（A 和 B）都遵循我們上面描述的相同排序規則，即 REMOVE 操作必須先於 SWAP 操作：

• 所有 REMOVE(A) 操作必須在所有 SWAP(A) 操作之前執行。
• 所有 REMOVE(B) 操作必須在所有 SWAP(B) 操作之前執行。

現在，假設內存池中有以下兩個交易：

• TX1：移除(A) + 交換(B)
• TX2：移除(B) + 交換(A)

雖然這些情況看起來可能很隨意，但考慮這樣一種情況：鏈下價格發生顯著波動，Alice 在資金池 A 中持有流動性提供者 (LP) 頭寸，Bob 在資金池 B 中持有流動性提供者 (LP) 頭寸。Alice 和 Bob 都試圖從各自的資金池中移除流動性（這兩個資金池的價格都已過時），並且他們還希望用移除的流動性提供者 (LP) 代幣來兌換另一個資金池中價格已過時的代幣。

請注意，由於任何一筆交易先於另一筆交易都會違反每個獨立去中心化交易所 (DEX) 強制執行的兩條排序規則之一，因此這些交易不能合併在一起。當然，Alice 和 Bob 可以將他們的 REMOVE 操作與相應的 SWAP 操作分開，但這會破壞他們操作的原子性，而且除非他們從自己的資金池中移除流動性，否則他們可能沒有足夠的資金在另一個資金池中進行 SWAP 操作。

再舉一個例子，考慮以下 Oracle 和 DEX 的排序規則。

• Oracle：UPDATE 操作必須先於 READ 操作。
• DEX：移除操作必須先於交換操作。

Oracle 希望確保所有讀取操作都能訪問最新數據，而 DEX 則繼續使用我們的取消優先級規則。現在考慮以下兩個交易：

• TX1：更新（ORACLE）+ 交換（DEX）
• TX2：讀取（ORACLE）+移除（DEX）

同樣，這兩個交易都可以自然產生。第一個交易中，用戶從預言機更新價格，然後進行原子交換。第二個交易中，在移除流動性提供者 (LP) 頭寸之前讀取預言機價格。然而，這兩個交易不能包含在同一個區塊中，因為這會導致兩個合約中的一個出現順序衝突。雖然可以將這些操作拆分成單獨的交易進行重新排序，但這會破壞這兩個應用程序之間的可組合性。

在不同的排序規則和涉及眾多合約的大量交易的情況下，區塊構建的複雜性會進一步增加。考慮以下示例，其中每筆交易都會分別調用一次預言機合約和一次去中心化交易所（DEX）合約。

我們再來看看嘗試序列[TX1, TX2, TX3]會發生什麼。顯然，這行不通，因為 Oracle 和 DEX 的排序規則都被違反了。這裡，唯一能產生有效交易集合的序列是[TX3, TX2, TX1] 。下面的每個要點都展示了一種可能的排序方式。

• 123 : 1（讀取，交換） → 2 （讀取，刪除） → 3 （更新，刪除）
  • （讀取操作先於更新操作）且（交換操作先於移除操作）=> 無效
• 132 : 1（讀取，交換） → 3 （更新，刪除） → 2（讀取，刪除）
  • （讀取操作先於更新操作）且（交換操作先於移除操作）=> 無效
• 213 : 2（讀取，刪除） → 1（讀取，交換） → 3 （更新，刪除）
  • （讀取操作先於更新操作）且（交換操作先於移除操作）=> 無效
• 231 : 2（讀取，刪除） → 3 （更新，刪除） → 1 （讀取，交換）
  • （READ 先於 UPDATE）=> 無效
• 312 : 3（更新，刪除） → 1 （讀取，交換） → 2（讀取，刪除）
  • （SWAP 先於 REMOVE）=> 無效
• 321 : 3（更新，刪除） → 2 （讀取，刪除） → 1（讀取，交換）= >有效

在某些方面，本例中的區塊構建問題比前例中運行時檢查資金池奇偶性的問題更容易解決，因為可以在運行交易之前檢查函數的順序。然而，關鍵在於，找到所有三個交易的有效順序可能需要比簡單的按優先級費用排序的貪婪算法多得多的計算量。此外，還可以輕鬆構建更復雜的示例，其中交易在去中心化交易所 (DEX) 或預言機合約上調用的函數取決於資金池的價格和/或來自預言機的價格信息，而這些價格信息在運行時會發生變化。

（3.3）可能的適應和緩解措施

在前一節中，我們看到，只需對共識機制進行少量修改，即可將 ACE 集成到通用的 L1 區塊鏈中，但代價是區塊構建的複雜性會增加。區塊構建複雜性的增加會帶來一些弊端。首先，它可能會導致中心化，因為這會使本地構建者（那些自行構建區塊而非外包的非專業驗證者）更難甚至無法準確估算出最優的交易費收入。此外，或許更重要的是，用戶、錢包和前端都需要調整其交易費邏輯以及調用的函數集，以應對交易排序複雜性的增加。

例如，對交易及時性有強烈要求的用戶（例如，希望緊急取消交易以防止過期報價被搶購的用戶）可以儘可能簡化其交易邏輯，使其便於構建器進行靜態分析。這使得構建器能夠更好地預先預測交易行為，而無需在區塊的不同位置重新運行。然而，這種對簡潔性的追求可能會限制交易的可組合性。隨著交易變得越來越複雜，並與更多合約交互，構建器對其靜態預測交易將涉及哪些函數和合約的信心會降低。一個足夠複雜的交易很可能改變其行為，以至於構建器可能會直接將其排除（或者由於包含該複雜交易而排除許多其他交易）。因此，這需要在交易的表達能力和預期包含時間之間進行權衡。即使不與 ACE 序列合約交互的交易也與交互的交易共享區塊空間，這意味著它們也必須權衡這種利弊，因為在執行之前沒有完全可靠的方法來發出交易的確切行為信號。

請注意，我們並未對上述許多論斷進行正式的論證。例如，我們並未精確量化活性下降程度與表達能力之間的關係。我們也未對構建器的置信度如何受事務複雜度影響進行建模。這兩個方向都值得進一步研究。例如，前者需要顯式地對不同區塊構建算法的近似保證進行建模，後者則需要具備EVM/SVM靜態/動態分析的領域知識。我們在此的目標是定性地指出這些有趣的權衡，並希望能夠說服領域專家，這些都是值得探索的有趣問題。

顯式信號

與其要求區塊構建者承擔完整的交易排序分析，該協議可以通過添加元數據來支持或要求更明確的信號傳遞，以便交易能夠主動證明其將要調用的函數。在以太坊中，這種交易預承諾類似於區塊訪問列表（BALL） ，後者目前正在考慮納入下一次硬分叉。在 Solana 中，交易已經承諾到賬戶地址，但在這兩種情況下，添加函數級元數據對於提高區塊構建者在不直接執行交易的情況下啟動排序過程的能力都至關重要。

在這種結構下，只有準確聲明瞭函數簽名的交易才會被視為有效；如果交易調用了未聲明的函數，則會被撤銷但仍需支付 gas 費用。這種機制有助於確保區塊創建者能夠收到 gas，並且意味著交易可以任意複雜而不會影響其活性。當然，這種改變會將分析負擔轉移到交易發起者身上。雖然錢包和前端應該能夠指定其函數調用，這似乎符合直覺，但在某些狀態相關的情況下，交易可能無法事先知道它將調用哪些函數（例如，鏈上路由交易在搜索最佳價格時，不希望預先決定在每個探測到的 DEX 上調用 swap 函數）。再次強調，從非執行層專家的角度來看，這種設計空間似乎很豐富，並且具有潛在的應用前景。

值得注意的是，在ACE中，區塊構建的複雜度遠高於區塊驗證的複雜度。在驗證區塊時（例如，作為驗證者決定如何投票），所涉及的合約列表和交易順序可以在運行時動態檢查，任何違反合約設定的排序規則的行為都會立即導致狀態轉換函數返回無效狀態，而不會顯著增加區塊驗證的複雜度。

（4）結論

本文從取消優先級的角度探討了ACE的多種候選設計方案。每種設計方案都存在一些權衡取捨，我們已在上文中重點闡述。我們還探討了將ACE以基本形式融入L1機制的可能性，即合約可以指定其函數的順序，該順序必須在單個區塊內得到遵守。可啟用的排序規則設計空間非常廣闊，值得深入探索。例如，您可以設想更具表現力的排序規則，例如當去中心化交易所（DEX）的價格波動過大時觸發規則。此外，排序規則可以比僅僅指定合約內函數的順序更加複雜。

ACE 協議就是一個例子，它對區塊施加了額外的有效性約束。這些約束來自應用程序開發者，他們負責指定函數調用的順序。Hyperliquid 已經證明，這種約束對最終用戶很有用，尤其是在專門圍繞交易構建的應用程序鏈環境中。這一理念似乎指向一個更廣闊的協議設計空間，其中主要問題將是：

1. 可行性：通用區塊鏈可以實施哪些限制（而不至於過於複雜）？
2. 合理性：哪些限制有利於最終用戶或整個生態系統的福祉？

這與《分析去中心化對用戶的經濟影響》一文的思路類似，該文分析了協議對供應約束的承諾如何影響最終用戶的定價。我們認為，將這項工作擴展到協議可以做出的特定於應用程序的承諾，具有重要價值。

希望本文通過取消優先級示例，幫助統一不同的ACE機制；通過提供具體示例，闡明ACE的一些微妙之處，展示區塊構建的複雜性和可組合性問題；並探討在以太坊環境中應用內置ACE的潛力。我們相信這是一個很有前景的想法，值得繼續深入研究和探索。