阅读提示
在深入阅读本文之前,建议您对MEV有基本的了解。同时,熟悉以太坊交易机制,包括交易内容构成及区块打包过程也十分必要。此外,了解Merkle Tree和零知识证明的作用将有助于更好地理解本文内容。您也可以先阅读MEV(五):更公平的MEV生态系(上)作为背景知识。
在前文中,我们探讨了两种MEV解决方案:一是通过可信硬件提升区块构建者公正性的Flashbot SGX Builder设计,二是通过去中心化交易排序角色来防范MEV的Chainlink FSS设计。本文将重点介绍第三种方案——通过密码学技术为交易提供隐私保护的Encrypted Mempools设计。
Encrypted Mempools
该方案旨在实现双重目标:MEV保护和抗审查能力。当用户能够将交易加密后再广播,直到被打包进区块才解密时,MEV搜索者将无法窥探交易内容,从而避免被榨取MEV。同时,这种机制也能防止提案者因个人偏好或政府制裁而拒绝打包某些交易。实现这一目标的核心技术就是密码学。
Encrypted Mempools运用密码学技术实现两个关键功能:一是加密用户交易内容以保护隐私,二是在加密状态下验证交易有效性。这种双重保障既能保护用户,又能防止攻击者通过发送大量无效加密交易对网络发起DoS攻击,避免提案者浪费区块空间打包无效交易。
需要注意的是,单纯的加密并不能完全保证抗审查性。有意实施审查的提案者仍可能拒绝打包所有加密交易。加密技术主要是通过让提案者放弃加密交易的手续费来提高审查成本。要实现更强的抗审查保障,通常需要与PBS的Inclusion List等机制配合使用。
确保交易能被解密
加密交易必须确保最终能够被解密,否则可能成为DoS攻击的漏洞。攻击者可能持续发送无法解密的交易,导致节点必须保存这些交易直至过期,最终使交易池被垃圾数据塞满。
目前有五种主要方式确保交易可解密(中文翻译可能不够精确):
– 纯信任(In-flight)
– 可信硬件(Trusted Hardware/Enclave)
– 门限加密/解密(Threshold Encryption/Decryption)
– 延迟加密/解密(Delay Encryption/Decryption)
– 见证加密/解密(Witness Encryption/Decryption)
△ 不同解密方式的复杂度对比,从左至右依次递增。图源:https://www.youtube.com/watch?v=XRM0CpGY3sw
Commit-reveal机制
有人可能会问,Commit-reveal机制是否能达到相同目的?用户先将交易内容哈希得到Commitment,待提案者承诺打包后,再揭示完整交易内容。
△ 提案者承诺打包Alice交易的Commitment
虽然Commit-reveal和加密都能隐藏交易内容,防止MEV榨取和审查,但Commit-reveal无法保证解密。因为揭示权掌握在用户手中,用户可能选择不揭示交易(无论有意或无意)。虽然可以通过押金机制惩罚不揭示行为,但这会进一步恶化本就不佳的用户体验。
△ Alice可以选择不揭示她的交易
五种解密方式详解
1. 纯信任(In-flight)
用户将加密交易发送给中心化角色,由其解密并确保交易在打包前不会泄露。虽然中心化角色收到交易后会立即解密,但用户仍相信交易在被打包前都处于加密状态。这种中心化角色可能是PBS的Builder、Proposer或Rollup的Sequencer/Operator。
2. 可信硬件(Trusted Hardware/Enclave)
运作方式与纯信任类似,但用户信任的是硬件及其执行的代码,而非特定个人或组织,安全性更高。
3. 门限加密/解密(Threshold Encryption/Decryption)
Chainlink FSS也采用此技术,区别在于钥匙管理者是Chainlink Oracle。在Encrypted Mempools中,管理者(称为Keyper)可能是L1或L2的验证者。这种方式有几个缺点:需要假设多数Keyper诚实;缺乏追责机制;过多Keyper离线可能导致链停滞。由于改动较大,L2比L1更适合采用此方案。Shutter Network正在试验相关设计。
4. 延迟加密/解密(Delay Encryption/Decryption)
这种技术能保证密文经过特定时间后自动解密。解密需要持续运算,类似Verifiable Delay Function(VDF)。Ethereum Foundation和Protocol Labs正在合作研发VDF专用芯片,以防止硬件优势带来的提前解密风险。优点是无需依赖Keyper,缺点是固定的解密延迟时间和潜在的硬件竞赛。
5. 见证加密/解密(Witness Encryption/Decryption)
这种创新的加密方式允许在特定条件满足时解密,如”等式被解出”或”密文被打包”。它不仅能实现前几种技术的效果,还能组合使用。但目前技术成熟度不足,尚无法实际应用。
△ 不同加密技术的成熟度对比。图源:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_591
同态加密的应用
前面讨论了确保交易解密的方法,但交易何时解密?答案是在被打包确定排序后。那么区块构建者如何从加密交易中组建高效区块?同态加密(Homomorphic Encryption)就是解决方案。
△ 同态加密在投票中的应用示例。图源:https://twitter.com/khushii_w/status/1660278622291210242
通过同态加密,无需解密就能对密文进行运算,构建合法区块。当区块解密后,将得到一个完整合法的区块,交易按加密前的顺序排列。同态加密分为部分同态加密(仅支持加法或乘法)和完全同态加密(支持任意运算)。
△ 不同加密技术对完全同态加密的支持情况。图源:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_620
元数据隐私保护
即使交易内容被加密,相关元数据如发起人、手续费、签名、IP地址等仍可能泄露隐私。这些元数据也需要保护。
△ 可能泄露隐私的交易元数据。图源:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_709
零知识证明的应用
通过零知识证明,可以在不泄露隐私信息的前提下验证交易有效性。例如证明地址余额足够支付手续费,而无需透露具体金额。这种证明由公开信息、私人信息和待证明陈述组成。
△ 零知识证明组成要素示意图。图源:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g19ee04031ad_0_391
交易大小保护
某些加密方式会保持加密前后数据大小一致,这可能通过大小推测交易类型。解决方案包括填充数据到固定大小,或利用同态加密移除填充。
△ 通过填充使交易大小一致。图源:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_860
区块构建优化
即使使用同态加密,区块构建仍面临两个问题:交易状态冲突和手续费排序。理想方案是在同态加密环境中运行EVM,但技术复杂度太高。替代方案是交易附带加密手续费和访问列表,用同态加密验证有效性,帮助构建者优化区块。
△ 通过手续费和访问列表优化交易排序。图源:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_1133
总结
Encrypted Mempools通过加密交易实现MEV保护和抗审查,但要完全实现抗审查需要结合其他机制。验证加密交易有效性需要多个零知识证明,同时要防止元数据泄露隐私。五种解密方式各有利弊,需要根据场景选择。这项技术代表了密码学在解决MEV问题上的重要应用。
参考资料
- Encrypted Mempools介绍视频:https://www.youtube.com/watch?v=XRM0CpGY3sw
- 技术演示文档:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_639
- 密码学解决MEV问题讨论:https://youtu.be/jLHf6yw7b5Y?t=4139
特别感谢Steven Wu、Kimi Wu、Kevin Mai-Hsuan Chia和Anton Cheng对本文的审阅和改进。
声明:文章不代表CHAINTT观点及立场,不构成本平台任何投资建议。投资决策需建立在独立思考之上,本文内容仅供参考,风险 自担!转载请注明出处:https://www.chaintt.cn/11012.html