如何建设更好的 Layer 2?_ROLL:SYNC币

背景介绍

以太坊扩容在社区中的讨论如火如荼,多个解决方案正在加紧开发,并有望在今年全部上线主网。在整个以太坊 Layer2 方案爆发的前夕,imToken 联合 ETHPlanet、EthFans、ECN、上海前沿技术研讨会和 HiBlock 等多家优秀的以太坊生态社区与公司,共同策划一场以太坊扩容主题系列活动。

4 月 23 日举办了第一场活动:Rollup - 以太坊 L2 扩容新范式杭州线下 Meetup。

Panel 分享现场视频

以下是本次 Meetup「如何建设更好的 Layer2」的圆桌讨论文字版本,由上海前沿技术研讨会 -?沙漏时间整理。

AMA 实录

主持人:姚翔

嘉宾:

Celer 开发者 - Michael

imToken 产品经理 - 阿树

安比实验室负责人 - 郭宇

Loopring CTO - Steve

姚翔:非常荣幸邀请大家来到这里,一般来说都是要大家自我介绍一下,但是我今天给每位准备了一个问题,在回答问题之前,你可以做一下自我介绍,我们先从 Celer 开始。

我先提一下我的问题,祝贺 Layer2.finance 的主网今天早上上线了,能不能介绍一下你们的主网的情况,包括在之前的测试竞赛当中,竞赛的情况是怎么样的,有没有出现什么样的技术或者是产品上的一些问题,或者说你们的发现。

Michael:大家好,我先介绍一下自己,我是 Michael,是 Celer 比较早期加入的开发者,我在 Celer 主要就是一直在做以太坊和支持 EVM 的所有链的这些扩容,我们最早做的是 State Channel,就是状态通道的技术。我们在 18 年在以太坊主网上已经上线了通用状态通道,不仅是转账,还可以支持链下的合约在链上进行仲裁这样的一个功能。

之后我们就发现状态通道好像使用场景比较有限,而且对用户进出通道的体验并不是那么好,所以说我们也在看别的方向,正好那个时候就出了 Rollup 的技术方向,然后我们觉得这个可能是未来会比较有希望的一个方向。

在 19 年的时候,我们首先提出了一个混合式 Rollup,把侧链和 Rollup 的安全性结合起来,用户可以选择是 Rollup 的安全性还是只用侧链的安全性,就有点像 zkPorter 和 zkSync 的概念。

在 2020 年整个 DeFi 非常火的时候,我们在想怎么去解决 Layer2 的流动性的问题。在大家都在想 Layer2 之后会不会成为一个孤岛的时候,我们就想是不是有一种反过来的思路,把 DeFi 协议暂时还是留在 Layer1,我们在 Layer2 只是去聚合用户的操作,但是所有的流动性还是在 Layer1,所有的资金都还是在 Layer1 的原来的协议里面,至少短期或者说甚至中期都有可能是这样的。而且换一个角度, Layer2 必然会有一些安全性上的牺牲,即使没有安全性上牺牲,也会有一些资金利用率和资金可用性的问题。所以可能对于最大体量的资金,他们还是会比较倾向于把资金留在 Layer1 的协议,所以说我们会去反向兼容他们,这就是 Layer2.finance 的起源。

其实当时也有像 StarkWare 提出了类似的概念,我们差不多是殊途同归,我们算是第一个把产品做上线的一个项目。

我们在两周前上了测试网,还搞了一些活动,让大家来体验,其实数据还是不错的。差不多 10 多天有大概 1900 多个用户累计进行了 40 万笔左右的 Layer2 转账,具体的能省多少 gas 我没算过,但是大家稍微算一下,可以知道我们为用户省下了非常多的 gas。我们部署了大概二十多个模拟的 DeFi 协议,然后大家不断地将资产进入协议,再退出协议,一共发生了 40 多万笔 Layer2 上的转账。

Euler Finance社区就如何将追回的被盗资金分配给用户进行投票:Euler Finance社区就如何将追回的被盗资金分配给用户进行投票

金色财经报道,DeFi借贷协议Euler Finance背后社区正在就如何将追回的被盗资金分配给用户进行投票,如果该计划获得批准,Euler将使用协议因黑客攻击而被禁用时的价格来计算用户资产和负债的价值。

此前报道,Euler Finance在3月份遭受了2亿美元的黑客攻击,该团队上周表示,它已经收回了在黑客攻击中被盗的所有“可追回资金”。根据Euler治理论坛的提议,收回的资金总额超过95,556个ETH和4300万个DAI稳定币。未追回的资金包括发送到Tornado Cash的1,100ETH和发送到与Lazarus Group相关地址的100ETH,Lazarus Group是一个据称与朝鲜有关的黑客组织。[2023/4/11 13:55:39]

刚才姚翔问有什么问题,我们发现以太坊的 Ropsten 测试网实在是不好用,它作为唯一的 PoW 的测试网,但是出块非常不稳定,而且经常给你来一个八十几个区块的回滚 。所以说我们遇到了回滚的问题,但我们在遇到回滚后协议也是正确处理的,即把 Layer2 的 Rollup 的链暂时停下来了。我们 CTO 花了一天的时间将 Layer1 上所有 calldata 重放,再把 calldata 在 Layer2 上重新生成一遍,这样能保证它的安全性,我们算是第一个做到了这样的项目。

这也是我们觉得把 Layer2 数据可用性在 Layer1 上得到保留是非常重要的一个原因。因为 Layer2 可能会出现各种各样的问题,如果 Layer1 有一个确定性的历史的话,你随时可以把它重放,再在 Layer2 上还原这个状态。我们确实也做了,这个也是非常有意思的一件事情。

今天早上我们在以太坊主网上正式上线了,我们 Layer2.finance 的第一个版本我们叫它 v0.1,因为其实很多设计都还没有完全定下来,现在只是说让大家没有手续费地去体验一下。

我们第一次兼容的是这三个 DeFi:Compound、AAVE 和 Curve,都是非常保守的策略,全是稳定币,所以收益不会太高,就可能在稳定币的一般的年化 10% 左右,大家有兴趣的可以体验一下。前 500 名会有一些奖励,而且我们会覆盖你的充进 Layer2 的手续费。我们的充值不是太贵,是一笔和 Uniswap 兑换差不多的手续费。一旦你进入这个 Layer2,你就可以在各个协议之间零手续费地进出。

产品目前只支持 MetaMask 桌面,之后会出手机的适配,也会尽快上架各大钱包,这样大家都在手机上也可以体验 Layer2.Finance。除了等待时间会受限于 Optimistic Rollup 的等待时间以外,其他的体验还是不错的。现阶段是零手续费,之后的话手续费应该还是会非常低的。等下一版本的大的更新之后,我们会把它结合 Celer 代币的这一些经济模型,包括可能会有一些流动性挖矿的活动,到时候也会欢迎大家体验。

姚翔:谢谢 Michael,也欢迎大家去体验 Celer 的产品,我也听到一个很有趣的点,其实 Ropsten 测试网的不稳定性反而帮助 Celer 去做了一个边界条件下的测试。

接下来我想请问一下阿树:最近也是看到 imToken 集成了 zkSync,我想去了解一下在集成过程当中你们有没有遇到什么挑战。如果说别的钱包想去集成 zkSync,你会给出哪些建议。

阿树:谢谢姚老师,我介绍一下我自己:我目前主要负责 imToken 钱包的产品,我叫阿树。像刚才姚老师提到的,我们在 17、18 年的时候就已经开始关注到以太坊的一个扩容工作发展,但为什么到我们才去开始去做集成和相关实施工作。是因为在过去的几年中以太坊扩容方案,它是一个不断演化的过程,从最早像 Celer 们做状态通道,或者像 OmiseGo、Plasma 到现在的 Rollup 方案,它有一个比较大的进展,然后 Rollup 方案应该是目前我们整个社区会认为它最具备可行性和落实的一个方案。

掌柜调查署 | 当前环境下交易所如何“转正”?:4月15日16:00,金色财经「掌柜调查署」邀请到ChainUP大客户项目负责人针对交易所如何拥抱合规的问题进行解答,带领大家全面了解当前环境下,交易所如何“转正”!更多内容点击原文链接查看。[2020/4/15]

另外,去年大家其实能感受到 DeFi 的一个发展。刚才像 Changwu 老师也说到了,整个的发展让以太坊网络拥堵,导致正常用户进行转账和 DeFi 操作的费用非常高昂,但这个事情其实是跟 imToken 的愿景是有冲突的。我们希望钱包可以服务到更多的用户,迎合以太坊普惠金融的愿景。

现阶段这些网络只能服务到拥有几万美金以上的这些高净值的用户,所以我们开始关注到以太坊扩容的方案。关于方案的技术上其实选项有很多,我们现在主流看到有零知识证明的、乐观的。在这里我们的选择标准可能有几个,第一个,它是具备有社区共识的,也就是 Rollup 这一块,第二个它是经过时间,还有社区的一个实践的验证的。

我们可以看到像 zkSync 方案,首先它已经在主网运行过了蛮长的一段时间。第二,它跟 Gitcoin 合作,也是经过一个实践验证的。最近比如说 Gitcoin,它的捐助 85% 的交易都是通过 zkSync 去完成的。第三,zkSync 团队除了工程能力之外,产品能力也很强,他们对于开发者去集成的话,已经提供了一套非常完善的一个 SDK。集成 zkSync 之后,在很短时间内我们发现这个方案受到对于有转账需求用户的一个青睐。imToken 集成 zkSync 半个月之后,数据显示整个 zkSync 网络上接近 51% 以上的转账都是来自于 imToken,所以短期是解决了我们的一个问题。

第二个我们是更期待于说刚才 zkSync Alex 他们提到的,他们 5 月份会提供像 NFT 功能、swap 的功能,这个会不断地扩展 imToken 在 Layer2 的一个使用场景。当然我们更期待会有更多方案,我们可以以一种更具有开放性的方式去做适配。目前这个 zkSync 是在原生层面去做集成的。其次其实现在主流的 Layer2,我们都会以一个 DApp 的形式,无论是 Loopring、Celer 还是 Hermez 等等,这些 Layer2 方案都能这样通过 imToken 的浏览器访问。

另外一个问题是姚老师问到的有什么技术难点。其实这里面的话对于钱包来说,它并不是一个工程上的问题,它更多是一个外围依赖遇到的挑战。举个例子,现在 Layer2 主流的做法是目前的节点都是单节点的形式,所以我们看到只要 Layer2 方案的服务挂了,那么就会导致整个网络不可转账。这对一个面向千万用户的实际使用的钱包来说是比较不能接受的一个点。当然我们看到社区(的节点运营)会往 PoS 方向去发展。

第二个事情其实说 Layer2 网络它最重要一点就是要有资金的流转,目前我们遇到的问题是什么。用户的充值成本是非常高昂的。缺乏两块支持,一个是交易所支持,另外一块是 OTC 厂商的支持。目前在交易所这块我们没有看到比较新的进展,但是在 OTC 厂商这一块的话,海外几家服务商应该会在今年 5 月份或者年底都会提供相应的 Layer2 充值服务,这是我们目前作为钱包遇到的一些外围依赖的挑战。

最后老师提到一个问题就是说对于同行钱包想做 Layer2,有哪些建议。对钱包最关键是一个私钥的问题。现在所有的 Layer2 方案都有比较明显的痛点,Layer2 的签名密钥一般是通过 personal sign 去做签名生成的,personal sign,在大家使用 DApp 的时候经常会遇到,它会给一个文本让你去做签名,但文本签名其实是非常容易去被伪造的,所以这是作为钱包服务商去集成 Layer2 要非常注意的一点。

关于这一点,我们台北的 imToken Labs 团队会向社区去提供 Signer 的一个存储方案,减少钓鱼攻击的可能性。第二个事情钱包没法确定如此多的 Layer2 方案谁会在未来胜出,对钱包来说应该尽可能做到减少主观性。我们在 Layer2 方案里面尽可能找到他们的一个范式,尽可能支持这些早期的 Layer2 方案,让市场去做选择,谢谢姚老师。

动态 | 会计公司H&R Block推出新服务 就如何正确申报加密货币损益提供咨询:根据9月24日发布的一份新闻稿,美国会计公司H&R Block推出了一项针对从事加密货币交易的人士的新服务,专门就如何在纳税申报单上正确申报加密货币损益提供咨询。(Cointelegraph)[2019/9/25]

姚翔:谢谢阿树,听起来 Layer2 的集成不仅仅需要钱包的努力,还需要很多生态位的合作。接下来请问郭老师,郭老师在零知识证明领域的研究一直非常深入,非常前沿。最近我们也反复听到一个词叫递归零知识证明,也看到以太坊基金会跟 Mina 基金会发布了一个 grant ,关于能否让 EVM 去高效地验证一个叫 pickles 的这样一个零知识证明技术。我想问问郭老师的是,如果说递归零知识证明能够在 EVM 里面去高效地验证,对我们去设计 ZK Rollup 这个协议有没有什么启发?

郭宇:我们团队在苏州,大概六七个人,从 18 年初创立起在智能合约安全底层,还有零知识证明底层,一直在做很偏底层的研究。我们很少直接面对终端用户,但是我们跟很多项目团队在合作,帮他们解决一些底层基础设施方面遇到的一些问题。我们的工作目前来说比较偏科研,陆续还会发布一些最新的研究成果,其中有一部分能够有希望极大地改善 ZK Rollup 的证明和证明大小,可能达到一到两个数量级的提升。

接下来回答就是姚老师刚才这几个问题。递归零知识证明,我就给大家简单说一下历史,比较早研究递归零知识证明的是 Chiesa 与 Tromer,他们大概在 2010 年左右提出来一个概念叫 proof carrying data,能够把整个 proof 的验证也做到 proof 里面,这样的话一个 proof 可以跟随一个数据到处传播,这是非常前沿的一个概念。

当然这里面它需要用到一个很 tricky 的技术,就是它要找到两条非常稀有的曲线,能够让这两条曲线相互嵌入,之前找到的两条曲线计算非常慢,难以实用。

一个小突破大概发生在 2018 年,Zcash 团队的 Sean Bowe 和现在以太坊基金会的科学家 Mary Miller,他们合作了一篇文章叫 Sonic。他们在这篇文章中发现了一件非常神奇的事情,就是在传统的 Bulletproof 的后端里面有一部分运算可以被分摊,也就是说如果你有很多 proof 放在一起的话,可以用更有效的方式聚合在一起进行 verify。这个发现后来被 Sean Bowe 用来实现一种非常新颖的递归零知识证明算法 Halo,这个递归零知识证明不再需要找两条非常稀有而且性能差的曲线。这种递归证明技术可以用在很多的地方,只要能找到两条不需要支持 pairing 的普通曲线就可以做。这件事情直接打开了递归零知识证明的一个大门,研究成果非常激动人心,它可以让整个区块链上的应用充满各种新的想象力,Mina protocol 也努力在往这个方向拓展。

以太坊由于传统的设计上的一些缺陷,所以说它只能通过支持预编译合约的方式来有限地支持零知识证明。但我们现在已经很欣喜地看见以太坊 2.0 其实已经在努力地做工作,特别是 EVM384 的改进也许在今年就能支持。那上面会支持更多的曲线,能够非常灵活地支持递归零知识证明。只不过在目前的以太坊 1.0 基础上做相对就会麻烦一些。现在 Mina 基金会和以太坊基金会共同联合,征集在 EVM 高效验证 pickles 算法的方案,但是经过我们仔细分析,发现这件事情没有那么容易,还是挺困难的,因为这里的核心问题是椭圆曲线里面有一些非常耗时的操作,目前在以太坊上如果没有预编译合约的支持的话,基本上还是举步维艰,可能会有一些效果,但优化程度非常有限。

我们还是期待能够让以太坊早日支持 EVM384,然后能够释放递归零知识证明的威力。我最后谈一下,这对于 ZK Rollup 意味着什么?

ZK Rollup 里面现在会面临一个问题,不管是 zkPorter 还是 zkSync,如果用同一个状态根来实现在二层上的可组合性,你需要把状态空间做得非常大,这样你才能支持很多的 DeFi 应用,支持更多的用户。包括 Loopring 团队做的非常棒的这种转换的方案,可以直接让一层合约代理二层的资产到一层上去做操作,这都需要一个非常巨大的状态。这个状态会引入一个巨大的默克尔树,巨大的默克尔树会带来问题,就是在上面产生 proof 会非常地耗性能耗算力。像 Loopring 用的是 O(1) 复杂度的算法,然后 PLONK 用的 O(log n) 的验证算法,当 n 很大时,gas 消耗会很大。如果我们期待以太坊捕获更大的价值,那 PLONK 算法就会遇到很大的瓶颈,而 StarkWare 的算法会更严重一些。递归零知识证明就完全开启了另外一道门,ZK Rollup 有希望在这条路上优化得更彻底,能够让整个的以太坊上做零知识证明验证的 gas 消耗降到一个非常低的等级。

动态 | ITAM Network发文 “DApps如何优化RAM使用率”:据IMEOS报道,ITAM Network在Medium上发表文章“DApps如何优化RAM使用率”。文中介绍DApps主要是在上传智能合约还有在使用智能合约Table保存数据的情况下使用RAM,并介绍如何通过在区块上运行数据达到RAM使用率最小化,还有DApps开发者应当考虑和准备的工作。文章最后ITAM Network表示这只是一种可供替代的方法,并不是唯一正确的途径。[2018/8/2]

这是我觉得非常激动人心的一个新的方向,也希望感兴趣的小伙伴可以跟我们一起去探讨这方面,探索未来充满想象力的天地。谢谢大家。

姚翔:谢谢郭宇老师,听起来如果递归零知识证明得到更广泛地应用,那么 ZK Rollup 可以发挥更大的功能,它的效率会有更大的提升。

话筒又给到了 Steve。刚才 Steve 做了一个演讲。我也观察到 Loopring 在一季度有很大的进展,比如说增加了一个快速提款的功能,包括去提高了在 AMM 上 gas 的效率。我想问的是,请问在这个过程当中,在工程实现零知识证明上还有多少的效率可以去提升,这里面主要的难度是什么?

Steve:其实 ZK Rollup 整个这套系统的搭建在工程角度来说还是蛮有挑战的。包括我演讲里面也说了,我们是 18 年下半年开始尝试这个方向,真正做出第一版原型系统是 19 年 3 月份,19 年底的时候才是真正的主网上线,这是第一个版本。第二个版本是在 20 年的六七月份上线,这也是半年多才迭代了一个大的版本,每前行一步,工程角度挑战都很大。

这里面尤其我可以说几个点。比如说,我们 19 年底的版本本质上还是一个不太可以商用的版本,还有很多限制,毕竟我们是第一个去尝试这条道的。比如说刚刚郭宇所提到的,默克尔树不能太大,我们当时其实就限定最多 100 万个 Layer2 的账户,那也是为了我们的默克尔树的层次不能太高,否则你去生成证明的时间开销会特别大。

第一版有很多这种工程上的权衡,但是我们后面会发现这些权衡应该要去掉。这只能从工程上去做,比如说我们在零知识证明的生成的优化上面有一篇论文,大概是提升了至少一个数量级,生成效率提高了十几倍。这之后我们就发现可以把默克尔树变得更大了,现在其实本质上是几亿个账户完全都能处理。

做完这样的一件事情之后,我们发现原来认为通过 ZK Rollup 生成零知识证明的那部分成本会很高,但是相反,现在其实生成零知识证明的成本是很低的,只是数据上链和数据在链上做验证的成本是比较高的。这部分成本怎么来进一步降低?我们其实做了很多尝试。第一个我们上传 calldata 前都是做过压缩的,甚至做了一种压缩算法,然后在 EVM 里面再解压,这样的 gas 消耗反而能更低一点。第二,我们所有二层上的交易,能节省 calldata,我们都一个字节一个字节地去抠,基本上我认为已经抠到了极致了。

所以同时就像郭宇说的,我们选了 O(1) 复杂度的 ZK-SNARK 的一个验证算法,它的验证时间不随着交易的大小增长而增长,这也是一个很大的好处。我们其实也很期待递归零知识证明最终在以太坊上能够得以实现,它能有效降低验证的时间。但是大家要记住一点,它其实不能提升整个 ZK Rollup 体系的 TPS,因为整个 ZK Rollup 最终的 TPS 限制是数据上链决定的,最大的 TPS 瓶颈就卡在这。除非你抛弃掉数据链上可用性,这是另外一条道。但我们觉得还是要保持数据上链,你的资产的安全性才得以保证。

姚翔:谢谢 Steve,我们也听到 Loopring 在工程上做了非常多的努力,包括最后他提到了 Loopring 认为数据的链上可用性非常重要。但与此同时我也看到一个倾向,因为我们今天刚才听了 Matter Labs 他们说发布了 zkSync 2.0,这里面其实是有两个部分,包括 ZK Rollup 和一个更像 Validium 的一个部分;包括 StarkWare,也是有 ZK Rollup 和 Validium 这两个部分。同时我也看到像 Arbitrum 这样的团队,他们也在尝试把零知识证明引入到 Optimistic Rollup 体系里面来。

韩国将于7日在国会召开‘虚拟货币制度化,该如何接近’研讨会:最近对虚拟货币的担忧和关注,虚拟货币相关学界及业界专家和政府核心相关人员将于韩国时间7日早上9点30分在韩国国会第二会议室中召开‘虚拟货币制度化,该如何接近’的研讨会。[2018/2/6]

我的问题是面向这四位嘉宾,这样一种混合的设计有没有可能成为将来的协议设计的趋势,因为混合本身可能给用户不同的选择的权利。

Steve:这种混合模式我是这么来看的。路印协议从第一版支持 ZK Rollup 的时候,我们协议本身就支持两种模式,其实就对应数据可用性和不可用。本质上其实就是一个取舍,你要 TPS 还是要安全性,这就是协商妥协的一个过程。至于刚刚提到的比如说 Arbitrum,我们当时甚至都讨论过,路印是不是可以在别的 Layer2 上面再部署一套,把我们变成 Layer3。

其实大家可以想象一下,我一直也提一个概念,就是盗梦空间,层层的梦,梦的叠加,就可以类似于无限的扩张 TPS,这也是有可能的。这是我对这种融合的一个看法。

郭宇:首先我想表达一个观点,零知识证明实际上是更底层的非常基础的小工具,它到处可以用。ZK Rollup 和 Optimistic Rollup 的一个核心区别就是大家如何处理这个状态空间。像签名验签,像继续去挑战的动作的时候也可以生成证明,就是说这样的证明可以到处使用,只是我们平时说的 ZK Rollup 可能特指的就是零知识证明处理巨大的默克尔树。

所以说我觉得所谓的混合方案,目前我看到 Optimistic Rollup 在大量地使用零知识证明,我相信未来很多的部件会逐步被零知识证明替换。反过来混的情况我现在还没看到,就说 ZK Rollup 是不是有必要引入 Optimistic Rollup 里面的一些组件,例如把挑战窗口这种基于经济学的方法拿过来用,我目前还没有看到有这个必要。我觉得必然很多的方案会逐步地用大量的零知识证明,因为马上以太坊会支持更先进更复杂的这样一个证明的应用场景。

我觉得所谓的混合方案可能是一种更好的 Rollup 方案,我更喜欢用 Rollup 这个词。至于是不是强调基于零知识的,我觉得可能没那么特别重要,反正最后大家会共同往一个方向走。这里面有一个核心的问题是,基于密码经济学和零知识证明的占比会有些不同,可能跟不同场景有关系,DeFi 和游戏可能会采用不同的策略,这是我的一点看法。

阿树:关于混合,当然我看到 ZK Rollup 和 zkPorter 这两者结合的方案,会觉得它其实并不是一个混合的想法,混合可能更多是一个短期内大家看到的东西。zkSync 的 Alex 在去年 8 月份就已经提到 zkPorter 的一个设计思路,它其实更像我们现在能看到以太坊 2.0 分片的一个想法,所以我的观点是什么?支持,同时这只是一个短暂的阶段,未来的话肯定是他们各自找到范式,就像郭宇老师说的 Rollup 的范式,而他们按自己的需求去做不同的应用。

Michael:我的看法和阿树有不同,我觉得混合式的会是比较长期的一个方案,提供不同级别的安全性。就像 Celer 曾提出侧链和 Rollup 其实也是可以混合的。像 Matic 上的一些应用,它的安全性就是侧链的要求就可以了,它的用户也不会特别在意一个游戏一定要具有数据可用性或者保留整个完整的历史,所以说我个人觉得未来会看到更多不同的混合式的方案。

在 Layer2 的角度来说,也还有一个问题没有很好解决,比如 Optimistic Rollup,谁去提交这个区块,其实现在并没有一个很好的解决方案,现在大部分项目都是一个中心化的方式去提交。

我个人觉得在这个问题上通过 PoW 的算法来决定出块者都是可以的,反而可能比用质押的方式解决会更好。甚至未来有一天我猜想会看到二层上的算力会大于一层上的算力,这是有一天我的突发思想,就是大家为了挖矿去提交数据可用性,这件事情会用一个 PoW 的方式去解决,我觉得也是一个可行的思路。未来设计空间还是非常大的,然后也不能说一定会朝着哪个方向走,还是需要一定时间的观察和实践。等项目上了主网,可能真的出一两次这种安全性的事情之后才会有比较好的定论。

前两天 Arbitrum 的 Ed Felton 和 Matter Labs 的 Alex 从 Clubhouse 吵到推特,我也加入了。从安全性的角度来说,你不能说 zkPorter 或者说 Validium 有主网的安全性,这个事情是要打个很大的问号的。举个例子,比如说在 zkPorter 上玩 BitMEX(译者注:一个交易网站),然后我爆仓了,我跟 Arthur Hayes 说你赶快停了,把数据可用性的插头拔了,我这个爆仓到底发生了没有?我这个钱到底是丢了还是没有呢?

如果从 zkPorter 的角度来说,一旦这样他把链暂停以后,那么赚到我的钱的人是提不走钱的。对他来说这个钱是不是丢了,这个钱是不是和被盗了是一样的,我个人觉得是一样的,但可能 Alex 他们是有不同的意见。我想不同的应用可能会选择不同的扩容方式,需要非常高的安全性的 BitMEX 这种应用,最好的方式当然是得采用 ZK Rollup 才会比较好,但是它的 TPS 可能就只能降到几千的水平了,这也是我觉得是没有办法的一个事情。

所以说未来设计空间还是非常大的,然后我觉得大家会逐渐地去发现一个各自的需求和各自最适合的扩容方式吧,这是我的观点。

姚翔:好的,谢谢 Michael。在 Michael 的表达里我也听到一个词,就是现在的 Rollup 的验证者也好或者叫排序者也好,更多还是一个中心化的角色。我们也知道现在在 Layer1 上我们讨论一个问题叫 MEV(译者注:矿工可提取价值)。这个问题非常严重,如果能解决 MEV,对系统的可扩展性也是很有帮助的。那么在 Layer2 上面,如果说我们想要解决这个问题,它是不是面临更大的挑战,尤其在怎么打包和排序这个问题没有解决的基础上,我想听听大家的看法。尤其作为一个 Layer2 的设计者,你们对 MEV 这个问题怎么看的?你们有没有一个比较好的解决方案。

Michael:我觉得是非常好的一个问题。MEV 我觉得是 Layer2 在超前于 Layer1 在做的事情,就是尝试在 Layer2 先把这个问题解决了。我觉得这个同样没有定论,它有不同的解决方法,我看到过的有比较极端的就是 Proof of Burn(销毁证明)。比如说你要去提交一个 Rollup 区块,你要烧掉一部分代币,这样你是基本上不太可能去作恶的。

包括对于交易顺序的打包问题,如果你没有按照顺序来打包,比如说它规定必须是按交易费从高到低打包,你没有按照这个顺序打包,你也会被罚没资产,会有这样的一个惩罚性的设计。这是一个极端。

另外一个极端可能会相对乐观一些,就是说通过 PoS 的出块机制最简单,甚至跑一个 PoA 的轮流出块也是可以的,只要它可验证。只要你定一套规则,其实以太坊现在最大问题就是 Layer1 的交易排序是没有规则的,这个东西不在共识里面,我觉得这属于设计上的一个缺陷,或者说一个没有考虑周全的地方。

如果 Layer2 就可以把交易排序的方式写到规则里面,然后无论这个规则是强是弱,它是惩罚性的还是奖励性的,我觉得都是可以的。

阿树:有许多人在讨论说 MEV 到底是正义还是怎么样,这个是好事还是坏事。站在我们或者用户的角度来看,MEV 不管好坏,其实是一套激励机制,甚至通过竞争提高网络资金效率。但它也带来负面影响,用户在区块链网络上做交易是会受损的。

因为我们的区块链上的交易是一个资金池的形式,无论是做兑换还是借贷都是一个资金池的形式,这会存在滑点,所以就很容易形成现在常见的所谓三明治夹击的问题。

反过来我们更在意的是怎么解决用户受到的损害。有两个点,一个点是刚才 Michael 说的交易排序问题,当这个交易排序没有主观性的时候,它是平等公平的时候,是可能会被解决的。第二个是从 DeFi 协议设计的角度,我们怎么去设计 DeFi 方案,使它可以减少滑点,避免用户受损。

作为一个钱包方看待这个问题的时候,我们就看到几个点。譬如 DEX 采用 PMM 方案,用户的交易并不是直接上链,而是通过将签名提交到中继器,中继器进行订单上链。这个应该是目前能看到的比较理想的方式,可以保证用户没有滑点的受损。

相比 Uniswap,可能它 10 笔交易里面至少有三四笔是会失败的,PMM 这种机制的话基本能保证到 90% 以上的一个成功率,这是一块。

除了 DeFi 上的设计的话,我们也能看到整个社区也在这块上去想办法,一个是排序的公平性,然后还有一个比较有意思的想法就是 KeeperDAO。

大家想法是什么?MEV 的价值我们是可以拿来去再次分配的,而不是说只有矿池和套利者之间的一个利益,我们跟 MEV 的一个获利者去聊的时候,甚至提出说我们 MEV 的一个利润能否提供出来给到所有的用户。

举个例子,可能钱包里面有个按钮,你点一下就能参与 MEV 套利。MEV 现在有一个主流的解决方案是 Flashbots,它的做法是让套利者零成本竞价,这个方案有一定可行性,让社区去竞争,而不是只有套利者跟矿池之间的一个利益分配。所以我的看法是优先从 DeFi 协议上去解决这个问题,这远比从交易排序上去解决更快。如果要解决 MEV 的公平性,我们可以从分配角度去考虑。

姚翔:所以我们需要每一个 DeFi 协议设计者都要先去学习一下什么是 MEV,怎么在协议设计层面减少它的影响。

郭宇:我非常赞同阿树老师说的观点,就是我们可能很难从一层的共识协议来解决这个问题,可能真的需要额外的一个类似 DAO 或者是有治理的这种方式来分配利润。但是我想说的是,MEV 本身其实不是个问题,它是个现象,真正的问题是什么,是 front running,就是抢先交易。MEV 里面分成几大类,一部分来自很多交易机器人,现在我们都把以太坊称为黑暗森林,这里面有很多的机器人,每天非常忙碌。但其中一部分是非常善意的机器人,正因为有这些机器人存在,所以 Uniswap 的价格能够跟中心化交易所良好地同步。

每当用户有一笔兑换交易的时候,都会有机器人跟在用户后面把这个池子重新拉平,拉到跟中心化交易所一样,所以这些机器人实际上是为生态在贡献自己的能量,但是它从中也获取了目前来看还是比较大的利益,我觉得也是应得的。就是它为了生态的发展,包括像借贷协议的清算者,借贷协议就是需要有清算,当今年资产价格暴跌的时候,会有大量的机器人出动,而正是因为有大量的机器人,借贷协议才不会出现系统性坏账。

为了金融生态的稳定性,就需要这些机器人,需要 MEV 给它们提供动力,让它们来维护整个系统。但是这里面有些是恶意的,是非常有问题的,就是抢先交易,这会造成用户以最大的滑点买到想要的资产。很多事情他都可以抢先交易,包括三明治是很多用户讨厌的,imToken 应该是这个很大的受害者。

我觉得三明治就是很大的问题,现在社区似乎有着不好的风气,就是大家在讨论 MEV 问题的时候,过度关注了 MEV 的分配,而没有想办法说我们怎么去禁止抢先交易的出现。目前抢先交易没有好只有坏,正因为他们的出现,让很多用户体验不好。用户发一笔交易想完成一件事情,对不起,你发现的这个机会被别人的机器人抢去了,你就会失败,你额外消耗了手续费还没有成功。我觉得抢先交易是百害无一利,大量 MEV 的收益来源于抢先交易,我觉得社区要关注这些,区分哪些是好,哪些是坏的,让不好的现象被曝光,对好的那些 MEV,可以用 KeeperDAO 或者是 Flashbots 之类的方式把这个东西进行分配。

Steve:前面几位嘉宾的观点都很好,很明确。MEV 在一层上的确挺严重的,我估计大家只要跟 Uniswap 交互,应该多多少少都有体验。在二层本身,其实目前这个阶段,我认为对现在已经上线的这些二层项目还不存在这个问题,是因为大家的中继节点,当前阶段基本上都是中心化的方式实现。中心化的实现一定会按时间排序的方式设计,严格的按时间排序,否则用户一定会用脚投票。你在自己的 Rollup 里面经常去抢跑用户的话,用户一看就明白了,自然就用脚投票退出你这个 Rollup,我们不在你这玩。这样本质上是一种从经济博弈的角度来解决这个问题。

如果 Layer2 上面,后续大家把中继器改造变成去中心化的方式,肯定也会面临这个问题。但要想从共识机制上去解决,我觉得也不太可能。可能真的只能从协议层靠经济模型的博弈角度来彻底解决这个问题。这是我的看法。

姚翔:好,Steve 提到现在可能各个 Rollup 的信誉还是吸引用户的很重要的一个方面。

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

金宝趣谈

[0:78ms0-7:382ms