这些可能出现的问题在 radius 目前给出的方案中都没有见到明确的解决方案。
作者：魏文侯
简介：radius 使用 PVDE（时间锁 + zk) 的方式来加密交易池，来削弱 MEV 攻击的可能性。即，破解出时间锁之前是看不到交易内容的，便无法进行 MEV 攻击。
Radius 接收到加密交易的时候即会做出排序承诺 (order commitment)，同时开始解密时间锁。在承诺用户排序之后，时间锁被破解完成，radius 拿到交易内容按照承诺的顺序打包并执行。
在这个过程中，zk 的作用是防止用户对 sequencer 发起攻击的，如果用户发起一个无效加密交易，则 sequencer 花费时间和算力破解出的是个无效交易，那么系统便相当于被 DOS 攻击， zk 保证的是在不透露具体交易内容的情况下，sequencer 可以花费极少的成本验证这是一笔有效交易 (通过 zk verify)
时间锁性能的影响
时间设置之两难
正常情况下，一次点对点的公网传输的延迟差不多是几十 ms 到百 ms 左右，在去中心化网络中，网络传输次数的复杂度基本可以表示为 O(logN)。
在这种情况下， 时间锁设置交易被破解的时间 T 基本不可以低于公网传输的延迟，否则时间锁将不具备抗 MEV 特性：
举个例子，如果时间锁的延迟设置的是必须经过 10ms 才能破解出交易内容，那么在公网环境下，节点很可能直接花 10ms 破解然后传输出去，而传输的延迟是 50ms。
作为用户而言， 可能 100ms 以内的延迟都算正常的，也就是说，当 T 过小的情况下，它完全可以先破解出来再作 order comitment，这对用户而言根本看不出来他已经破解了交易内容了。
那么，当 T 大一些， 比如几百毫秒~几秒这个级别的话，那么定序器的吞吐量便会出现问题，假使时间锁设置为 200 毫秒才能破解交易，那么加上 radius 的 PVDE zk proof verify（官方博客说验证这个 zk proof 恒定小于 1 秒）， 那么 radius 光是验证+破解一笔交易的耗时很可能就已经接近秒级了，这种情况下 radius 的吞吐量可能会非常低，并不适合承载更多的 dapp。
注意：以上还没有考虑到公网本身就有极大的不稳定性，如果因为公网的不稳定或者节点掉线之类的问题导致公网实际延迟比理论值还高，那么时间锁更有被先破解再 order comitment 的可能。届时，交易被 MEV 的风险会更大
功耗不利于去中心化
时间锁虽然无法通过多核的方式来加速破解速度，但是却可以通过升级单核处理器性能而加速破解时间锁的。对于 CPU 机器而言，GPU 机器可能会更快破解时间锁，对于 GPU 而言， FPGA 可能更快破解；到后面可能还会有 asic 芯片。
这就意味着，MEV 攻击者/可以更高配的机器来比 radius 更快的破解时间锁 从而完成 MEV 攻击。 在中心化的情况下，radius 可以不断提高自己的机器配置来预防这种事情发生。但是一旦 radius 去中心化后，这个问题就会变得很难解决：
如果一个网络里有一些节点的硬件比较普通，那么它破解时间锁的时间很可能就会比 MEV 攻击者要慢，从而导致 radius 网路依然有被 MEV 攻击的风险，在这样的去中心化定序器网络中，它的 MEV 抗性不是由网络中最强的那个机器保证的，而是由最弱的那个机器来保证的，这意味着参与 radius 去中心化网络的节点是需要一定的硬件门槛。 众所周知，参与门槛的增高本身就不利于去中心化。
时间锁解决不了的问题
对于一个区块链而言（去中心化 sequencer 也是区块链）总是从交易池中打包交易并排序的，因为每个区块的容量是有限制的，定序器交易池并不可能接收到多少交易就全部打包在本次出块的区块中； 并且由于区块链一般都会按照 tx nonce 的顺序进行打包，如果交易池中某个账户的一批交易出现了 nonce 断层，即这批交易里 5 笔交易的 Nonce 分别为 1,2,3,5,6。 那么本次打包将只会打包 nonce=1,2,3 的这三笔交易，那么 5,6 这两笔交易会被挂起，等到 nonce=4 的交易抵达交易池之后才会被接着一起打包。
那么，如果在该区块高度上，这一部分交易没被定序打包，则会延迟到下一个区块或者更晚的区块上被打包， 在这个过程中，加密交易很可能就已经被破解了，被破解后再 order comitment，则依然会被 MEV 攻击。
以上，这些可能出现的问题在 radius 目前给出的方案中都没有见到明确的解决方案。
免责声明：作为区块链信息平台，本站所发布文章仅代表作者及嘉宾个人观点，与 Web3Caff 立场无关。文章内的信息仅供参考，均不构成任何投资建议及要约，并请您遵守所在国家或地区的相关法律法规。
