如果智能合约能在“币安”上交易会怎样？为任何链上的 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获取完整白皮书。
我们认为交易应该是一个可编程的基本单元，而不是一个孤立的场所，而这是实现这一目标的第一步。
