ROLL:路印 CTO Steve Guo:什么样的二层网络才是真正的未来?_TROLLER

来源:BeWaterCommunity?

9月4日的BeWaterDevCon2021全球开发者大会上,路印CTOSteveGuo,他曾任Intel高级研发工程师,猎豹移动高级研发总监,15岁考入科大少年班,博士学位。与现场的开发者,分享了“未来真正的二层网络是什么样?”的主题演讲。

分享内容概括如下:

1)真正意义上定义的二层网络,应该是安全性要靠主网来保证。

2)二层网络从状态通道到Plasma,再演进到了Rollup,并分成了两个分支:OptimisticRollup和zkRollup。

3)二层网络的最终形态是zkEVM,大家不用改代码,直接能把原有合约运行在zkEVM中。

大家好,我是路印协议的CTOSteveGuo,很高兴这次受邀参加BeWater的开发者大会。我今天想和大家探讨的主题是什么样的二层网络才是真正的未来。

一、什么是二层网络?

我们先从这一页开始,就是定义什么是二层网络。在我看来像Polygon、xDai、BSC这样的侧链,严格意义上不算二层网络。真正意义上定义的二层网络,应该是他的安全性要靠主网来保证。

从技术角度、演化的角度来看,最早的二层网络的技术叫状态通道,之后演进到Plasma,然后到最近很火的Rollup技术,然后Rollup又分为两个分支,一个叫乐观汇总——OptimismRollup,一条道叫zkRollup。

我接下来的演讲围绕这几个技术的演化来带着大家走一遍目前二层网络发展的整个历史。

1、状态通道

接下来我们先看第一种二层网络技术,叫状态通道。

状态通道最早的起源应该是比特币里面的闪电网络,然后在以太坊上,我印象中间最早的一个项目叫「雷电网络」,它试图去复制比特币上闪电网络这样的技术。

整个状态通道核心的思想是,比如说Alice和Bob经常要在线下转账的话,Alice和Bob就约定好,大家互相冲一笔钱到一个合约里面,比如说A充5个B也充5个,之后在链下A和B就可以互转,比如这张幻灯片里面演示的,我可以B先转给A一个,A就有6个币,B是4个币,之后A又转三个币给A,最后大家发现A只有3个币,B有7个币。

路印协议 Steve Guo:短期Optimistic 或胜出,中长期ZK Rollup将胜出:3月11日,在以《Layer2百花齐放, DeFi 们如何“站队”?》为主题的AMA中,路印协议CTO Steve Guo、Synthetix大中华区负责人Dorothy、Huobi Global商业战略总监哲叔、Starks Network联合创始人张晓关于即将到来的Layer2展开了精彩的对话。

Steve Guo表示,路印协议的设计考量最重视安全性。zkRollup相比于Optimistic Rollup来说,最大的好处就是在于能保证用户资产结算的最终确定性时间比较短,能做到分钟级别,而Optimistic Rollup则需要1周以上的时间。

Steve Guo认为“在短期内,对于通用EVM计算而言,Optimistic Rollup可能会胜出,随着ZK-SNARK技术的改进,在中长期而言,ZK Rollup将在所有用例中胜出。”在接下来2年左右的时间,会多个Layer2共存。一些严重受限于Layer1资源的一些应用场景会在Layer2上得到更大的爆发,比如DEX,去中心化的永续合约,去中心化的期权等项目。[2021/3/11 18:36:52]

最终要到链上去结算的时候,才把最终的一个状态到链上,这样最后大家再分别退出,就比如最终大家能在图上看到,A只有3个币,B只有7个币。

其核心就是在链下之后大家可以互相只用签名确认的方式,就可以直接进行链下无限次的转账这样一个思路。

他最大的缺点在于什么?就是A和B一定要互相之间,先在主网上有一个确定的合约去部署。

之后其实像雷电网络和CelerNetwork这样的项目做了些扩展,把A和B之间的互相结算,推进成比如A跟一个Hub,然后B也跟这个Hub,C也跟这个Hub,有一个中心的类似于Hub的方式,来把点对点的转账推进成点对网络的转账。

但是这还是具有局限性,首先,需要提前抵押资金进智能合约,其次因为他整套技术只是围绕「转账支付」这个角度来解决的。但是大家也都知道,区块链最大的意义在于可编程的应用,而不仅仅是支付,之后的二层网络技术就自然发展到了第二代Plasma。

Google Cloud 在客户用例中新增路印协议 Loopring 的 zkRollup 扩容方案:Google Cloud 在客户和案例研究中新增路印协议 Loopring 的 zkRollup 扩容方案。根据该案例专页的描述,路印协议 Loopring 选择 Google Cloud 的可扩展性和速度来减少交易时间,为 zkRollup 客户提供更好体验,可将用户资金释放等待时间缩短 40%。Google Cloud 计算引擎通过自定义 VM 解决方案可节省 15%的计算成本,从而为用户降低了交易费用,此外还可将部署时间从几分钟缩短到几秒钟,以提高员工效率,最终增强交易计算性能并改善客户服务。[2020/12/19 15:47:42]

2、第二代Plasma

上图这种二层网络技术叫Plasma,在我看来他其实就是去尝试着解决我刚刚提到的「状态通道」解决方案中的资金要提前锁定的问题。

他的解决思路是什么呢?其实它的思路很简单,链上还是要有个智能合约,但是任意的人都可以往这个链上的合约去充值也好、提现也好,都是和这个合约打交道。

对应在链下有一个叫PlasmaChain的概念,一旦资金进了这个合约之后,就可以在链下发起转账,PlasmaChain他在不停的把大家在链下所发生的交易汇集打包到一起之后,把最终的状态Merkle根递交到主链合约上去保存记录。

如果在一段时间内没有人有异议的话,比如7天内大家都没有异议,历史记录就不能再被更改。如果随意一个人对7天内的转账有异议的话,他可以递交challenge,证明说某一笔转账是错误处理了,从而把资产最终给取出来。这样一个思路就能解决状态通道需要提前抵押资金的问题。

他最早的方案同样也只支持转账支付这个场景,比如最早的PlasmaMVP,然后演进到PlasmaCash、PlasmaDebit,这几个诸如此类的项目。最终大家发现下来Plasma还是很难用。

首先第一个他有类似于七天或者两周的退出挑战期。

路印COO Jay:路印将AMM交易模式带到了zkRollup二层:据官方消息,币赢CoinW《共识52》第十一期《ETH2.0的扩容之路——Layer2能否突破DeFi的局限?》主题AMA中,路印COO Jay讲到:DeFI其实就在把现实金融世界里面的各种场景在区块链世界里面再造出来,比如?Compound 就对应传统银行借贷,MakerDAO 有点像央行铸币,各种?DEX 实现的是交易需求。一个很明显的趋势就是DeFI项目都在往二层迁移,就是因为以太坊主网实在太拥堵了,而路印协议绝对是二层解决方案中的派头兵,Loopring 是世界上首个基于?zkRollup 的DEX,也是世界上首个基于zkRollup 的AMM, 并且已在以太坊主网上平稳运行快1年左右的时间了。

路印再次创造了历史,将AMM这种交易模式带到了zkRollup二层。路印的新技术甚至可以把一个订单拆解到AMM和订单本做局部成交,用以寻找到最有的成交价。这将有可能改变交易所的竞争格局, 我们期待AMM和挂单交易的结合能给用户崭新的体验。[2020/12/3 23:01:03]

第二个它的安全性取决于什么?PlasmaChain往主链上递交的仅仅只是一个Merkle根,所有发生在PlasmaChain上的交易信息都是记录在链下的,这说明什么?这说明我必须依赖于提交这个Merkle根的这些Relayer是如实的在干活的。

3、OptimisticRollup

如何能解决Plasma的问题,自然的一个演进,就会演进到现在比较火的,叫OptimisticRollup。

大家看这张图OptimisticRollup,其实他跟上面Plasma唯一的区别,在我看来,就是他递交到主链上的不仅仅是世界状态的Merkle根,而且他是把所有在链下发生的交易数据也同时上链了,然后允许任何的人在链上根据这些公开的区块链上记录的信息来做挑战。

比如例子举到的S2状态切换到S3状态的时候,如果有人有挑战,他就能根据区块链记录的一些历史信息说你处理的不对。

路印协议Loopring发布Loopring Wallet的beta版本:据官方消息,路印协议Loopring已于近期发布Loopring Wallet的beta版本,成为首款具备zkRollup扩展功能的以太坊L2智能钱包。此外,Loopring v3.6版本正在推进中,目前尚未启用所有特性。[2020/11/30 22:34:27]

所以Plasma演进到OptimisticRollup,他的安全性依赖于「退出挑战机制」这个是不变的,但是它解决了一个数据可用性问题,让人直接能在链上根据已有的数据就去做这个挑战,而不是要再结合链下的数据来做一笔挑战,这是它最大的改进。

除此之外,OptimisticRollup同时还能支持转账之外的场景,他可以支持通用编程。

这样的一个思想其实目前已经有两个项目在朝着这条道走,一个叫Optimism,还有一个叫Arbitrum。

4、Optimism

我先说Optimism,因为Optimism是最早出来说要做OptimisticRollup的,这个团队本身也跟Plasma一脉相承,所以像Uniswap最早也是说会最先部署在Optimism上面。

他的核心思想其实就在于怎么样解决挑战,就是说如果有一个人发现你在二层网络上没有如实的处理一笔交易,我该怎么来挑战这件事情,他把这个挑战抽象成一个什么?

就是在以太坊一层上他布了一个合约,这个合约接受什么?接受他定义的叫OVM的指令集运行,你可以利用他递交到主链上的公开信息,然后去驱动这个OVM的执行,如果这个OVM执行判定这些值不对,那你挑战就成功了。

基本上Optimism的思路是OVM的指令集尽量的跟EVM是完全一致的,但其实他没有做到百分之百的兼容,他有一部分的指令是修改了。

正是因为这些指令需要修改,所以导致他其实很难百分之百兼容EVM,这可能也是他为什么一直在延期,还没最终主网上线的原因之一。

5、Arbitrum

路印Loopring:已经开放二层以太坊DEX交易:去中心化交易协议路印Loopring今日发推表示,用户已经可以在其二层以太坊DEX上进行交易,该DEX也采用zkRollup扩容技术,免gas费用,代币交换界面简单,增加了订单簿,做到对用户更友好。[2020/9/14]

Arbitrum我觉得他正是看到了这样的机会,就是说我在一层的智能合约里面我再去执行类似于EVM指令集其实是很困难的一件事情。

我是不是能重新把EVM给改成我自己的VM指令,他叫Arbitrum的指令集,就是AVM,所以在一层智能合约里面执行的其实是AVM指令集,这样的一个思路本质上是能更比OVM的方式可能做到更高效一些。

同时他解决了OVM的Optimism挑战机制里面的一个比较大的问题,就是Gas消耗,挑战一次的Gas消耗太高的问题,他的解决思路其实就是用分片挑战,类似于二分法。

我先让你说证明执行到一千步是正确的,然后我再缩小到512,然后再256,逐步的让你分片的去执行一系列的指令序列,最终来做一个挑战的输出,成功还是失败。

Arbitrum主网是8月31号正式上线,陆续已经有好些项目迁移到Arbitrum上面,比如Sushi、MCDex等。

但是大家实际发现下来还是有些问题,就是原来大家以为这样的二层网络会极大的降低费用,但实际情况却是Arbitrum的主网上一笔交易大概降低到主网上的1/5到1/10,这还是远远低于我们的预期。我觉得可能要再提高一个量级,这样才是真正的二层网络。

二、zkRollup

我们接下来讲第二个大分支zkRollup。

1、什么是ZKP?

讲到zkRollup就要先给大家讲一讲什么叫ZKP,ZKP其实顾名思义就是零知证明,零知证明在干一件什么事情?

如果举f(X)=Y这个例子为例,那就是我能证明说我知道一个X值,通过函数f计算能输出Y,但是我又不能告诉你X是什么,然后我要让你相信这件事情,这就叫一个零知识证明。其中函数f是公开,运算的结果Y也是公开的,但是我的X是私有的,不让你知道。

我再举个更直观一点的例子大家来理解零知识证明,这张图其实叫“寻找沃尔多”,问题是想在这张大图里面试图找到上面小人的位置在哪。

我要做一个零知识证明,就是我要让你知道我在这张大图里面,这个小人的位置我是知道的,但是我又不能让你知道这个小人的具体位置在哪。

大体的解决思路就要转换问题,零知证明本质上就在转换问题,我把A问题转换成同等等价的,在另外一个域上B问题的证明,针对这个寻找沃尔多零知识问题的解决,比如说我用一块很大很大的黑布,我用黑布把沃尔多小人提前剪出来。

然后把这块大黑布盖在这块画面上,只透出小人,这样我是不是就向你做了一个零知识证明,我能找到这个图上小人在哪,但是你其实还是不知道这个小人具体在画中的位置,因为被整个黑布给盖着的。

2、zkRollup介绍

再接下来我讲一个ZKRollup的思想,ZKRollup其实是一个技术的统称。它的核心思想就是像我这里面这张图所表示的,世界状态抽象成所有账号组成的Merkle树,账号里面有一些自己账号相关的信息,这样的Merkle树有一个唯一的根就代表了当前世界状态。

我在链下对账号所做的改动,比如说可以是任意一笔交易去改一些账号的信息,这叫交易Tx信息,我有在链下收集到所有的Tx信息之后,我可以针对每个Tx的处理引起的世界状态的转换做一个零知识证明。

我首先第一个要证明这个Tx是真实的,然后证明Tx能由前一个世界状态变到下一个世界状态,最终的世界状态信息是记录在链上的。

所以一旦某一个历史状态被在链上确认之后,永远是不能改的,我就能根据不能更改的历史记录然后再加上之后的一系列Tx,然后再证明推导出下一个新的世界状态,然后最终一直不停的往链上更新最新的世界状态,这样一套系统叫ZKRollup的解决方案。

3、路印协议

我们路印协议是世界上第一个ZKRollup应用到主网上的实例。我们把ZKRollup这套思想扩展到了Dex交易上面。

我们针对Dex交易在之前刚刚介绍的ZKRollupAccount模型上做了更进一步的抽象,比如我们抽象出在Account下面挂Balance,Balance下面再挂TradeHistory,但本质上还是大的Merkle树,然后不停的把整个Merkle树代表的世界状态不停的更新到链上。

之后大家熟知的还有MatterLabs出的ZKSync方案,ZKSync方案目前演进到2.0。1.0跟我们路印协议很类似,只解决了转账、交易、支付这几个场景,在ZKRollup的技术上其实大家是一样的,但只是大家选用的零知证明的算法不一样。

我们路印协议选的是Groth16的算法,而ZKSync用的是Plonk的零知证明算法,之后ZKSync发布了ZKPorter,ZKPorter叫ZKSync2.0,

他的区别在哪呢??ZKSync1.0,大家记住,所有交易的数据都上链的。但是ZKPorter里面,他为了提高TPS,所有链下的交易信息是不上链的,而链下的交易信息类似于由一个PoA的这种小组,来帮你如实的保存链下交易数据。

ZKPorter的方案我觉得不能完全说是ZKRollup,ZKRollup的思路一定是要把所有的Tx信息也都递交到链上,ZKPorter其实他就跟我接下来要说的StarkEx的方案是有点像的。

回到StarkWare推出来的StarkEx的方案,这张图是StarkEx整体的介绍,其实他内部的最核心的也还是组织成一个Merkle树,用ZKRollup的思路来不停的更新世界状态。

但它一上来就定义了自己的编程语言Cairo,大家得用他的这套语言来写,他再为用Cario语言生成的程序执行生成零知证明。但是StarkWare和路印和ZKSync的区别又在于他选用的零知证明的算法叫zkStark。

这三个零知识证明算法的核心区别在于…Groth16是每个电路有任何改变都需要运行一次可信设置,这样可编程性会相对差一些。但是他的优势在于证明的大小是最小的,链上的证明验证工作量也很小,所以他具有很大的成本优势。

Plonk他支持一种叫通用设置,就是我全局只要运行一次可信设置,以后你再改什么电路就不用再运行可性设置。

ZKStark就更进一步了,他就完全都不需要可信设置,我可以随时的去更改电路,但他带来一定的代价,就是他的证明的大小是最大的,链上的证明验证工作量也是偏大的。

这可能也是StarkWare一开始推出来的时候不把交易数据放到链上的原因,否则他的上链成本还是挺高的。

这就是目前所有的二层解决方案的汇总,但我认为这远远还没到我设想中的最终的二层网络。

4、zkEVM

最终的一个二层网络我觉得是叫通用的zk虚拟机,我定义叫zkEVM。zkEVM有几家也开始在做了,像Hermez在做,MatterLabs也是想做通用的zkEVM,StarkWare的Cairo他本质上支持可编程,也算是一种zkEVM。

但最终我觉得在以太坊生态上最好的一个方案还是让大家直接不用改代码,直接把智能合约编译后的代码运行在zkEVM虚拟机上,这样的思路可能会是最终的一个未来。

以太坊基金会正好也在做这么一个项目,我这张图里就是试图总结以太坊基金会的zkEVM思路。

大家看这张图里面的右上角,这是一个经典的冯洛伊曼的计算机模型。计算机会包括CPU处理器,然后处理器之外有存储器,有内存,有你的硬盘,有你的外设这种。

存储CPU和外设内存之间都通过总线来通信,取数据、存数据,这样的一个思路,这叫冯洛伊曼经典计算机模型。

zkEVM借鉴了这个模型,zkEVM虚拟机里面的指令集直接就是EVM定义的指令集,每段程序代码执行完之后就会有一段trace,我针对所有的trace来做一个证明,我证明这些trace是如实的按照程序代码的指令执行而出的。

这里面就涉及:

第一个我要证明每个EVM的指令执行是正确的,而且执行序列是正确的,这叫EVMProof;

第二个EVM的执行过程中间就会涉及,比如说我要去存取storage的值,我要在memory中间甚至Stack中间去访问变量,这三个——storage、memory、stack统一叫state,针对这些state的存和取也都是要做相应的零知识证明,我去证明我这个存取的动作是对的。

EVMProof和StateProof之间有一个桥梁BusMapping,这是总线的概念,就是表述EVM的指令要去访问哪些具体的state,并证明这些访问是正确的。

这样的一套系统一旦部署之后,所有的智能合约都能无缝的迁移过来,我觉得这可能才是真正最终的一个二层网络的终极形态。

好,谢谢大家,有任何问题欢迎大家随时跟我联系,大家如果对路印的代码感兴趣也可以直接访问github。也可以通过邮件跟我联系,谢谢。

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

区块博客

[0:0ms0-3:622ms