ERC-6787：订单簿交易所的两步强制取款，防的是谁

中心化撮合被诟病的核心是资产托管，去中心化交易所于是把资产放在链上合约里。但链上订单簿很快遇到自己的难题：交易所为了效率做 1 比 1 储备、让用户随时可取，可亏损的用户也可能利用“随时可取”在违约边缘抢跑。ERC-6787 在 2023 年 3 月 27 日给订单簿 DEX 定了一套四函数接口，核心发明是一个分两步走的强制取款。按 ercs 仓库记录，这份提案状态为 Draft，讨论页挂在 ethereum-magicians。

四个函数的分工

接口由 deposit 与 withdraw 管普通存取——参数是代币合约地址和数量，资产存放在交易所合约账户里，原文强调这套设计配合 1 比 1 储备证明。真正的新东西是两个：prepareForceWithdraw 让用户声明“我要强制取出这么多”，并返回一个唯一的 requestID；commitForceWithdraw 在条件满足后凭这个 ID 执行取款。配套的 PrepareForceWithdraw 事件要求每次成功发起必须发出。一个账户可以并行发起多笔两步取款，所以每笔都要有独立编号——这两个细节说明接口是按多品种、多仓位的真实交易所场景设计的。

检查期里发生什么

两步之间发生了什么，是理解这套机制的钥匙。原文写得直白：prepare 之后的超时检查期内，交易所需要确认用户的订单状态符合预期，把该撤的单撤掉、该结的结算完，然后用户才能在第二期提交 commit 完成强取。换句话说，常规取款走快速通道，强制取款走一条故意慢下来的通道——慢是给清算流程留出时间，防的场景是持有亏损永续仓位的用户绕过风险清算直接抽走保证金，把窟窿留给交易所以及全体用户。这套设计借鉴的是分布式系统里的两阶段提交协议，提案把它翻译成了资金安全的语言。

对读者的两面读法

评估任何“链上资产、随时可取”的交易所类协议，这份 Draft 是一面好镜子。第一面照用户：你的可取性到底由哪个函数保证？普通 withdraw 依赖交易所按规矩清算，prepareForceWithdraw 依赖你肯等检查期；协议如果连强制通道都没有，所谓自托管就只是把托管换了个名字。第二面照平台：储备是否 1 比 1 可验证、订单簿撮合是否上链、检查期内清算是自动还是人治。也要看到这份提案的未完成度——标准的安全考虑一节原文只有“Needs discussion”一句占位，接口细节（超时多长、requestID 如何防碰撞）都留给实现。链上订单簿是个仍在竞争的赛道，一份 Draft 编号不背书任何产品，读到相关宣传时，回到这四个函数问一句“强取通道在哪、等待期里谁做主”，比读白皮书摘要有效得多。

把两步取款放进更长的历史里

交易所资产安全的叙事其实年年在转圈：托管换交易所、储备金证明换透明幻觉、链上结算换回性能瓶颈。这份 Draft 的两步取款之所以值得写，是它罕见地把一对矛盾写进了接口本身——快与可安全，不可兼得时选择让强取变慢、并明说慢给谁看。读者可以把这套结构当作鉴别器：一个自称资产安全的交易协议，其强制退出路径的等待期内必须有可自动执行的清算与储备检查，否则慢只是拖延而非防线。同样值得记的是那份未完成度，安全考虑一节的占位文字说明提案作者清楚自己没解决的问题，这种诚实远好过把风险藏在细节里。评估任何在跑的订单簿产品时，先读它的链上退出脚本与检查期逻辑，再读融资新闻，顺序不能反。

对读者还有一个视角值得保留：这套两步机制本质是把清算排进了等待期，谁在等待期里按下暂停、依据什么规则判定订单状态，标准未做规定，实现差异会非常悬殊。同一接口下，检查期里的清算可以是全自动合约逻辑，也可以是一个团队的手工操作，两者对用户主张了同样的安全感，法律与技术含义却完全不同。读接口只完成了一半功课，读等待期里的执行者是谁，才是另一半。

本文为机制说明，不构成任何投资建议。