如果智能合約能在“幣安”上交易會怎樣？為任何鏈上的 DeFi 引入可調用的智能合約交易基礎設施
太長不看
DeFi交易在結構上是分散的。智能合約無法直接調用像幣安這樣的高性能交易引擎或像Hyperliquid這樣的高級訂單簿平臺，表達性執行和鏈上可編程性從未真正融合在一起。
我們正在構建一個可調用的智能合約交易基礎設施，以彌合這一差距。任何鏈上的任何合約都可以通過可驗證的預言機網關調用交易所級別的交易，包括現貨市場、永續合約以及限價單和觸發單等高級訂單類型，而無需橋接資產或切換網絡。
交易頭寸和執行結果成為可組合的鏈上資產，使協議能夠進行交易、管理風險和分配資金，並實現真正的執行。
瞭解更多信息，請訪問https://www.128.trade 。
背景與動機
交易和DeFi從未真正融合
去中心化金融（DeFi）從設計之初就具備可編程性，而最佳交易場所的交易則兼具靈活性和高效性。然而，在過去的十年裡，這兩個系統並行發展，卻從未真正融合。
如今的智能合約可以進行借貸、交換、質押等操作，並構建日益複雜的金融邏輯。然而，它們卻無法直接在幣安等高性能市場或Hyperliquid等先進的鏈上交易平臺執行交易。與此同時，流動性最強、功能最豐富的交易引擎仍然是孤立的平臺，鏈上程序根本無法訪問。
這種分離通常被歸咎於用戶體驗、延遲或吞吐量。但實際上，它反映了一個更深層次的架構限制：交易功能最初並非設計為 DeFi 堆棧中可調用的組件。
核心限制在於可調用性，而非性能。
大多數關於DeFi交易的討論都集中在gas費用或流動性分散的問題上。這些問題固然重要，但它們並非主要問題。
根本的限制很簡單：智能合約無法調用交易引擎。高性能執行系統，包括中心化交易所和基於訂單簿的去中心化交易所（DEX），運行在DeFi的可編程環境之外。它們提供現貨和永續市場、高級訂單類型以及充足的流動性，但無法作為鏈上邏輯的一部分被調用。
因此，交易仍然是由用戶或鏈下機器人協調的外部活動，而不是協議可以直接依賴的原生構建模塊。
為什麼現有的去中心化交易所架構無法彌合差距
DeFi現有的交易架構只解決了一半的問題。
自動做市商雖然完全可編程且可組合，但其執行模型存在根本性的侷限性。它們無法原生實現槓桿、條件訂單或主動風險管理，而是依賴於被動的流動性曲線。
訂單簿式和永續式去中心化交易所（DEX）提供與中心化交易所相媲美的豐富執行語義，但它們的行為更像是應用程序而非基礎設施。它們通常是單鏈的，不能被任意智能合約直接調用，並且難以集成到更高級別的協議中。
這就造成了一種持續的權衡：一方面是缺乏表達力的可編程性，另一方面是缺乏表達力的執行能力。
一個重新定義問題的問題
如果這條界限不存在呢？如果智能合約可以直接調用高性能交易引擎，其執行語義可與中心化交易所相媲美呢？
在那個世界裡，金庫可以執行真正的交易而不是近似交易，借貸協議可以通過主動執行來管理風險，策略可以跨鏈自主運行，交易本身可以成為 DeFi 中的可組合原語。
這並非要建立另一個交易所，而是要將交易重新定義為基礎設施，一個協議可以直接調用的執行層，而不是用戶必須手動交互的場所。
系統架構：可調用交易的工作原理
讓智能合約能夠調用交易並非簡單的集成問題。它首先需要重新思考執行、正確性和跨鏈交互的建模方式。傳統交易系統被設計成獨立的交易場所，而智能合約則在確定性、可驗證的環境中運行。彌合這兩個世界需要一種不同的架構方法。
從宏觀層面上看，我們將交易分為兩個緊密耦合的層：確定性執行引擎和跨鏈訪問層，使得智能合約可以安全地調用此執行。
確定性交易引擎作為執行核心
該系統的核心是一個高性能交易引擎，它以確定性狀態機的形式運行。所有交易操作，包括下單和取消訂單、開倉和平倉、資金支付、保證金更新和清算，都通過單一的規範執行流程進行處理。
確定性是一項基礎屬性。在相同的先前狀態和相同的有序請求集下，引擎始終產生相同的結果。這使得執行過程可以被獨立地審計、重放和驗證。它還使得引擎能夠在共識機制下由多個節點運行，從而構成去中心化完整性和麵向未來的系統的基礎。
從引擎的角度來看，每個操作都只是一個請求。一旦請求進入執行隊列，無論它是來自低延遲 API 客戶端還是來自另一條鏈上的智能合約，都無關緊要。這種統一性確保所有消費者共享相同的流動性、相同的執行邏輯和相同的狀態轉換。
通過 Oracle 風格的網關使執行可調用
智能合約無法直接與鏈下高性能交易引擎交互。為了實現可調用的執行，我們引入了一個預言機式的網關，該網關專為執行而非數據傳輸而設計。
上圖展示了核心執行流程，從鏈上請求到驗證執行和鏈上結算。為了更直觀地瞭解該流程的完整端到端演示，包括合約、中繼器和交易引擎在實踐中的交互方式，我們提供了一個執行工作流程的 UI/UX 演示，網址為： https://www.128.trade/how-it-works
從總體上看，工作流程大致如下：
鏈上交易請求。
智能合約調用網關函數（例如下單、開倉、訂閱策略）。
這不會在鏈上執行交易。相反，它會發出一個規範的請求事件，其中包含執行意圖、參數、源鏈上下文以及唯一的請求 ID。請求轉發。
去中心化的中繼網絡監控網關事件，驗證其來源，並將經過認證的請求轉發給交易引擎。
從引擎的角度來看，這些請求與基於 API 的訂單沒有區別，並且會進入同一個確定性執行隊列。確定性執行。
交易引擎通過匹配訂單、更新保證金、應用資金或觸發清算來處理請求，然後產生確定性的執行結果。有證據支持的回調。
執行結果通過回調異步返回給原始鏈，並附帶加密證明包（例如Threshold簽名或執行證明）。
網關驗證證明，強制執行冪等性和重放保護，然後才將結果應用到鏈上。鏈上物化。
已驗證的結果將以鏈上狀態的形式體現：持有 NFT、金庫份額、餘額更新或合約回調。
這種架構允許任何受支持鏈上的任何智能合約調用交易所級別的交易，包括現貨市場、永續合約以及限價單和觸發單等高級訂單類型，而無需橋接資產、切換網絡或信任任何單一運營商。交易執行成為可調用的系統原語，其正確性直接在鏈上強制執行。
從構建者的角度來看，交易從外部依賴轉變為可調用的系統調用。智能合約表達執行意圖，交易引擎執行確定性執行，驗證後的結果通過回調返回鏈上。協議不再與交易場所集成；它們直接將執行功能集成到自身的邏輯中。
以下示例說明了其實際工作原理。智能合約可以通過調用placePerpOrder函數來下達永續合約訂單，該函數會通過預言機層向交易引擎提交執行請求。訂單執行完畢後，結果會異步返回，開發者可以通過實現相應的回調函數，在合約邏輯中處理該結果。
function placePerpOrder ( PerpOrderParams calldata params )external payable override returns (bytes32 requestId) { // submit a perpetual order request to the trading engine via the oracle requestId = oracle. submitRequest { value : value}(params); return requestId;} function onPlacePerpOrderResult ( ... ) external onlyOracle { // handle the execution result of the perpetual order // custom logic defined by the contract developer }一臺引擎，兩個世界
同一個交易引擎同時服務於兩個截然不同的用戶群體。一方面，交易員、做市商和自動化系統通過低延遲、性能優化的API進行交互；另一方面，智能合約和協議則通過一個最小化信任、有證據支持的網關訪問該引擎。
兩條訪問路徑最終匯聚到同一執行層。它們共享流動性、執行語義和狀態轉換。正是這一點將交易場所從孤立的交易環境轉變為共享的基礎設施。
這將為DeFi帶來什麼？
通過智能合約調用高性能交易，可以解鎖 DeFi 以前從未擁有過的一系列功能。
智能合約可直接進行交易所級別的交易。
合約可以進行現貨和永續合約交易，並具備幣安級別的執行語義，包括限價單、觸發單、槓桿和高級訂單邏輯。交易不再是用戶或機器人協調的鏈下活動，而是協議可以直接調用的可編程函數。交易狀態變為鏈上且可組合。
交易所原生對象，例如現貨餘額、永續持倉、子賬戶和策略組合，都可以表示為鏈上資產。持倉和子賬戶不再鎖定在交易場所內——它們可以被抵押、借貸、質押或嵌入到結構化產品中。協議獲得主動執行和新的設計空間。
金庫和基金可以直接交易，無需再依賴近似值。借貸協議可以通過條件執行而非僅僅依靠超額抵押來對沖和管理風險。與此同時，全新的協議類型也成為可能——包括完全鏈上基金、具有主動對沖功能的AMM以及擁有可驗證擔保的自主交易代理。
其結果並非又一個交易所，而是架構的轉變。交易不再是目的地，而是共享的基礎設施——一個由協議構成的核心執行層，就像數據和流動性一樣。
展望未來
128.trade 正在積極開發中，我們的測試網即將上線。隨著系統的不斷完善，我們將逐步向開發者開放智能合約接口和核心組件，同時開源合約代碼。
如需深入瞭解架構、信任模型和執行保證等技術細節，請訪問https://www.128.trade/pdf/whitepaper.pdf獲取完整白皮書。
我們認為交易應該是一個可編程的基本單元，而不是一個孤立的場所，而這是實現這一目標的第一步。
