公共内存池的两难
一条交易在被打包之前，内容对全网可见。这带来两个老问题：其一，任何人看到待处理的兑换单都可以抢先买入再卖出，夹单与抢跑因此成了产业；其二，用户为了防夹，把交易交给私密中继、订单流拍卖这类场外通道，公共内存池被抽干，抗审查性也随之从协议层滑向几个中介的商业条款。EIP-7805 的包含列表本来是为抗审查兜底的——只要交易公开广播，验证者就得把它塞进某个槽位；可一旦某类交易因为暴露内容而必然亏损，理性的用户根本不会走公开通道，兜底也就落空。EIP-8184（2026年3月起草，Draft 状态）提出的 LUCID 想在协议层解开这个死结：交易以加密形态走公共管道，排序决定锁定之后才允许拆开。
三步走的结构
第一步是提交与密封。用户发布的不是明文交易，而是一个密封承诺——对密文的承诺值。承诺先进入包含列表与区块的报价结构，此时任何人（包括出块者）都不知道内容，也就无法针对性地插队；同时承诺的存在本身就是可追责的”收据”。第二步是密钥或明文延迟发布。提案把可解密材料挂在一个延迟发布的键消息上，出块者在排定交易顺序后必须公开这些键；一旦公开，先前加密的交易内容对所有人同时可见，信息优势被压缩到”揭示之后”这个时间点。第三步是扩展执行：区块负载里同时携带密封交易与揭示后的展开形式，客户端按承诺核对展开是否属实，属实才按明文执行，否则整块无效。
承诺先于揭示为什么关键
排序决定先定、内容后见，意味着抢跑从”必然有利可图”退化为”赌概率”。提案把这叫概率性抢跑的最小化：出块者可以试着猜内容，但在承诺锁定之前下注没有意义，在之后下注已经没有先后手优势。对普通用户，这改变了选择结构——不必再在”防夹”与”公共可包含”之间二选一。
快速问答
问：这等于以太坊内置了某种加密方案吗？ 答：提案刻意不绑定单一密码构造，解密路线可以对接链上的各种方案（包括无信任的自解密），协议只规定承诺、包含与揭示的时序。
问：出块者拒绝发布密钥怎么办？ 答：提案给出了被拒负载下的恢复路径，并要求密钥时效性与区块有效性挂钩，具体条款仍在讨论中。
一个边界提醒
加密内存池改变的是”内容何时可见”，不改变”必须被包含”的义务边界，也不保证任何交易盈利。涉及交易通道选择时，理解各方案的信任假设比追逐速度更重要。
一次提交的完整旅程
把 LUCID 的用户视角串成一条时间线最能看清时序的作用。用户在本地生成交易明文和一把解密键，把明文加密成密文、对密文做承诺，先广播承诺；此时内存池里流动的是一条谁也读不懂的条目，包含列表照常为它保留被包含的权利，夹单者想抄也没有内容可抄。出块者收集承诺、排定顺序、把顺序连同承诺写进区块报价；过了这个决策点，密钥发布义务被触发，揭示材料随扩展负载公开。全节点先验证”展开的明文确实对应先前承诺”，再执行明文。整条链路上，任何环节的绑定失败——密钥与密文对不上、展开与承诺对不上——都让区块直接无效，而不是静默丢交易。
它和既有私密通道的分工
需要区分的是：LUCID 不想拆掉所有私密设施，而是给公共通道补上”内容保密”这一块短板。私密中继与订单流拍卖在协议外做的承诺，换成协议内可验证的承诺后，用户多出一种不必让渡对抗争权的选择：交易被审查时，包含列表的证据链仍然成立，因为加密交易也在公共管道里广播过。对协议而言，这条设计边界比密码学选型更关键——协议管时序和承诺，密码学方案留在链下竞争。
风险提示：本文为协议提案的科普介绍，EIP-8184 截至撰写时未在主网激活，机制细节与参数以提案原文为准；不构成投资建议，亦不构成对任何交易通道的推荐。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。