运行时与发布
运行时是拥有实时交易状态的单写入者引擎——持仓、净值、资金费率累计、成交、清算遍历。发布是将该实时状态转化为 Base 合约据以结算的已承诺根的规范。两者共同确保交易者历史、排行榜排名以及 90 / 10 支付金额无法被事后悄无声息地重写:每一次状态转换落在一个有序序列中,每一个根都绑定到产生它的序列、配置与预言机姿态,每一笔提款都根据任何使用区块浏览器的人都能验证的根来结算。
运行时校验来自网关的签名流、施加风控与市场状态规则、更新余额与持仓、推进资金费率(点对点,每 8h 窗口超过 $1,000 部分附带 1% 管理员切片),并执行强制例行任务——清算、ADL、50/50 维护者与保险残值分配。每一次状态转换都产生合约层稍后据以结算的引用。下表是每次提交所附带的内容;缺少这些绑定的根将被金库拒绝。
| 已发布项 | 所绑定的内容 |
|---|---|
| 状态根 | 在 Base 上为结算与提款证明锚定账户状态 |
| 根 ID 与时间戳 | 将状态置于明确的发布历史中;二者均单调递增 |
| 序列承诺 | 将事件排序绑定到已承诺状态——成交不可重新排序 |
| 预言机来源哈希 | 绑定状态推进期间所使用的价格源姿态 |
| 订单批次承诺 | 绑定围绕该状态准入的批次——订单不可插入或移除 |
| 配置哈希与版本 | 绑定生效的风控与平台规则——手续费表、保证金档位、市场清单 |
#单写入者交易状态
Dexter 运行一条写入路径。资金费率更新、清算遍历、不平衡例行任务、市场状态变化与发布全部经过一条有序的运行时流——绝不经过相互竞争的写入者。在衍生品平台中,错误排序与错误定价同样昂贵:一笔顺序错误的资金费率结算可以伪造净值,一笔与成交竞速的清算可以按错误的标记价结算。单写入者模型通过让一个运行时成为系统其余部分读取的状态转换序列的唯一作者,消除了这两类 Bug。
更新余额的同一运行时,准备了发布之后所锚定的材料。这就是为什么结算上下文与交易状态不会出现分歧——它们出自同一过程、同一顺序、同一承诺之后。
签名 IOC 订单
-> 准入与风控检查
-> 定价与成交决策
-> 账本、持仓、手续费与资金费率更新
-> 快照与读取模型写入
-> precommitSequencerCommitment(seqCommitment, oracleSourcesHash, orderBatchCommitment)
-> commitStateRootWithConfig(root, schemaVersion, configHash, configVersion)
-> 仅当发布守卫仍然满足时,金库才接受该根#作为结算上下文的发布
发布之所以存在,是为了让合约层永远不必信任运营方对运行时状态的含糊声明。当运行时将一个根与序列、预言机、批次和配置引用一并提交时,Base 上的金库收到平台在状态推进时刻所相信内容的具体描述。提款、争议、欺诈证明、对账与事后审查全都依托此描述。没有它,合约只知道某个链下进程声称了一个余额;有了它,合约可以锚定特定的运行时视角,将其保留在历史中,并要求每一次结算动作都指回某个具体物。
发布不被视为仅运行时的动作。在金库接受一个根之前,序列承诺、预言机来源哈希与订单批次承诺必须已通过 precommitSequencerCommitment(seqCommitment, oracleSourcesHash, orderBatchCommitment) 预承诺。随后通过 commitStateRootWithConfig(...) 提交根,后者将其绑定到生效的 configHash 与 configVersion。如果预承诺材料与根不一致,或合约侧治理锁未满足,发布将被拒绝,该根永远不会成为结算上下文。
生产姿态比单独的根提交更为严格。治理锁要求审计锚处于激活状态、setOrderCommitRequired(true) 处于生效,且发布路径维持至少一条持久化证据轨道——归档要求或 DA 见证人要求之一。孤立存在的根不是生产级;它必须保持与解释状态如何发布的审计链以及产生其订单流的同一准入规范相绑定。这正是让链下运行时能够安全地针对链上托管进行锚定的关键。