蜂巢研习社丨区块链的可扩展，Layer2能否脱颖而出？

6月23日，HashKey Capital投资经理Rui在万向区块链B站直播间蜂巢研习社，对话Nervos架构师Jan、路印协议CEO Steve Guo、Celer Network核心开发工程师Michael以及OffchainLabs亚太区商务生态负责人Nina，基于各自在行业内多年来的积累，从技术、管理、生态等多个角度，围绕区块链的可扩展性，探索Layer2的破局路径。

下文根据速记整理，略有不影响原意的删改。仅代表嘉宾个人观点，不代表万向区块链立场。

Rui（主持人）：大家好！我是HashKey Capital的Rui，很高兴邀请到市场上最热门的公链、Layer2、跨链非常强的技术型项目，非常荣幸作为这一次的主持。这次的主题是Layer2，但我觉得我们能聊的东西还是挺多的，从公链的底层到中间件，再到市场上一些比较新、比较热的东西。首先请大家做个自我介绍，从路印的郭老师开始。

Steve Guo：大家好！我是路印协议的CEO Steve Guo。大家都知道，路印协议是2017年8月份开始筹划创建的，最早目标是做基于订单本的链下撮合等。2018年做出来第一版，发现不太可能商用，尤其是基于订单本。之后就在想解决方案到底是怎么样的，那时候以太坊社区都还没有ZK Rollup这样的名词，只是隐隐约约看到零知识证明这个方向，所以我们2018年底开始做第一代基于零知识证明的系统。

记得2019年在DevCon上才刚开始在以太坊社区有ZK Rollup的概念，但其实那时候我们已做出了第一版，路印第一版的ZK Rollup系统是在2019年底正式上线主网，算是以太坊上第一个ZK Rollup的系统，而且已经稳定运行两年多，一直没有出过任何问题，中间也迭代了好几个版本。这大概就是整个路印协议的简单介绍，谢谢大家！

Rui（主持人）：按照顺序来，下面Arbitrum的Nina能做做自我介绍以及对项目的介绍吗？

Nina：我是Nina，是Arbitrum亚太区的生态和商务负责人，Arbitrum是Layer2市值排名第一的协议。我们一家就占了Layer2赛道TBL的50%，并且从我们上线以来基本一直保持在这个数值以上。

自去年8月31日上线以来，Arbitrum生态里已经有大概400个项目可以开放供大家交互，生态发展一直比较繁荣。Steve老师刚刚讲了他们项目的历史，其实我们项目在以太坊白皮书还没有出来的时候就已经在做扩容方面的研究，创始人是2015年在普林斯顿大学对比特币扩容方案做了Prototype原型，一直到2017年把它变成了商业项目，最终成为了今天的Arbitrum One这样的Rollup。

未来很快将迎来Arbitrum Natural的技术升级，会专注于让Gas费变得更便宜，链上的throughput变得更高，很快也会上线一条新的链叫Any Trust，它是专门为Metaverse、GameFi、SocialFi而设计的，期待大家在L2 summer跟我们一起关注Arbitrum新的动态。

Rui（主持人）：下一位请Michael来聊聊你跟Celer。

Michael：我们Celer是比较早的项目，2018年正式开始。一开始做的是基于以太坊的状态通道Status Channel扩容解决方案，当时2018年做出了第一个以太坊上的通用状态通道，当时做了一个五子棋的Demo，在以太坊主网上开了一个状态通道，双方可以下五子棋。

但是我们后来发现状态通道这个东西应用比较局限，特别是2019年Uniswap起来之后，我们发现没有办法用状态通道为它建模，也没有办法用状态通道为像Uniswap这样的应用去扩容的。

就像Steve老师说的，Rollup逐渐开始起来了，所以我们在Rollup上也做了一些研究。配合2019年后半年和2020年DeFi的兴起，做了Layer2 Finance的Demo，主要是让用户在Laye2上操作Layer1的DeFi协议，等于做了定制化的Rollup。但是这个东西比较有意思的是响应速度比我们想象中更快一些，所以这个东西也并没有做得特别大。

后来我们发现整个区块链，特别是以太坊生态逐渐进入了多EVM的格局，无论是一层还是二层，大家都把EVM在各条链上复制了一遍，各个生态等于在各条链上都有自己一整套的DeFi基础设施，我们抓住了跨链桥赛道。

本来有自己的一条链，但一直没有做很大的应用，之后把这条自己的链和跨链桥结合起来，做了相对去中心化的跨链桥——cBridge。我们认为这个做到现在是比较成功的，无论从用户量，还是支持的链来说，都是在这个行业内属于比较领先的。大致就是这样的情况，今年会继续拓展资产跨链、消息跨链。

Rui（主持人）：最后请Nervos的Jan跟我们讲讲您跟Nervos的故事。

Jan：大家好！我是Nervos的架构师Jan，大家可能听说过，Nervos是一个比较有想法的项目，它是一个公链，但是当大部分公链项目在做PoS的时候，我们在做PoW，大部分人在走账户模型路线的时候，我们在做UTXO，大部分链在做Sharding和Layer1扩容的时候，我们说分层才是正确的路。很高兴今天能参加Panel，聊一聊分层Layer2的东西。

今年Nervos有几个比较重要的里程碑，这个月月底Nervos上Rollup项目Godwoken会上线新版本V1和EVM完全兼容，有很好的互操作性，对用户来说使用的感觉会非常像以太坊的Rollup，甚至你就感觉它是以太坊上的Rollup，你感觉不到它的Layer1是Nervos CKB。在Q3的时候计划会发布另外一个Layer2框架Axon，其实是一个Sidechain或者说Appchain，这是今年的一些计划。

Rui（主持人）：无论是跨链桥、公链还是Layer2，请问一下大家怎么理解？像Nervos一层用PoW机制，二层也是用类似于证明的方式保护用户的数据安全。想请大家聊一下，包括我理解中Steve在安全这块儿做了很多工作。请大家聊一下关于安全上的部分，通过什么样的机制保护用户安全，以及这其中潜在的风险点。从Jan开始。

Jan：说到安全这个事儿，Layer2基本上可以分成两个思路，一个是我们说的乐观执行或者Fraud Proof，一般情况下我假设没有问题，但是有问题的时候我可以寻求Layer1的帮助，把作恶的证据提交到Layer1上。无论是Channel Network还是Optimistic Rollup里都有挑战的机制。

另外一种是零知识证明，ZKP发展起来以后，我们可以利用零知识证明的技术验证Layer2上的计算执行过程结果是对的。所以我觉得基本上所有的Layer2都是利用到Layer1的基本性质，利用Layer1来做最后的仲裁角色，就很像我们日常生活里的法院，日常活动发生在日常的地方，但是出问题的时候就找法院，Layer1就是那个法院。

Rui（主持人）：我们刚才聊到一些比较偏密码学的机制，我了解中你们也是乐观主义的方式，但是可能会加入密码学的机制，因为我确实没有看过CKB上的Layer2架构。

Jan：如果具体到Nervos的话，Godwoken是一个Rollup框架，我们其实想做的是框架，所谓框架就是说它可以通过定制变成一个Optimistic Rollup，或者说变成ZK Rollup，我们希望它都可以做。但是现在第一步是从Optimistic Rollup做起，6月底会上线的版本是Optimistic Rollup。

Rui（主持人）：说到乐观卷，也请Nina来聊聊Arbitrum包括Arbitrum上的验证器，其实OP上链之后大家对中心化验证器还是会有一些想法的，安全是一方面，所谓的MEV方面也是一个方面，想请Nina来聊聊Arbitrum在设计上怎么样考虑用户资产的安全性，以及其中会不会出现一些潜在的风险点？

Nina：我想问一下Jan，所以咱们开放出来的架构一层只支持Nervos的网络吗？还是也可以在别的网络作为一层？

Jan：Godwoken一层只支持CKB，因为以太坊已经有Arbitrum这么好的项目在做了，我们就另外走一条路。

Nina：感谢感谢，谢谢你把这个机会留给我们。

回到Rui的问题，刚刚Jan已经把开心卷讲得很详细了，我就不再复述了。比较特别的是我们选择了多轮价值证明方式，但这其实跟安全没有关系，这是针对于开发者的。当一笔交易发生了争议，我们不会把交易交给法院仲裁，可能会让他们两个先打一架，看具体争议卡在哪里，之后具体到一个指令，把指令交给法院进行裁决就可以了，这样会让价值证明更加安全，这是Arbitrum独创的多轮交互展示证明。当我们落地之后发现竞争对手也开始使用这个设计，所以这是我们跟竞争对手一开始不太一样的地方。

另外回到安全的问题，我觉得开心卷比较特殊的机制是只需要一个是诚实的就可以了，如果是挑战机制的话，哪怕你有100个里面99个都是在作恶，但只要有1个是诚实的，他就可以出来挑战，如果他真的是诚实的，那法院一定会判他胜诉，所以他其实不太需要像别的机制那样需要大部分诚实的也可以，这也是安全上的保障。

回答Sequence的问题，Sequence设计叫序列器，所以Arbitrum的序列器不能裁决交易是不是正确，它只能进行排序，所以它不会导致用户资产被盗或者丢失，它只能导致有一些MEV的问题。现在Arbitrum确实序列器在中心化，Arbitrum本身在跑，但是下一步我们将序列器的去中心化作为第一要务，论文已经发布出来了，会以Steve撰稿的论文作为原型进行设计序列器去中心化，同时我们也在跟ChainLink合作，研究如何更好地将序列器去中心化。

大家可以抱着开放的眼光去看这件事情，Layer2还是很新的技术，我们需要行业里各方各样的人跟我们一起去推动这个技术的发展。现在确实有MEV，如果大家担心序列器安全性的话，它不会威胁到你的账户信息和数据，只会威胁到MEV的问题，现在我们在跟行业里各个技术方进行协调，看怎么样将序列器更好去中心化。

Rui（主持人）：感谢分享，确实序列器这个问题我之前看过挺多文章的，感觉未来序列器去中心化还是Layer2更大规模让大家觉得更舒服的基础。接下来再问一下Michael，Celer cBridge作为跨链桥，托管还是基于智能合约、基于多签这些方式，在这个基础下，你们有什么特别的提升安全的方式吗？

Michael：刚才两位对Rollup的安全性讲得非常透彻，确实Rollup相对于目前多签的跨越桥，用Rollup的话可能会更加安全，因为它有底层Layer1的安全性。最根本上来说cBridge也不具备以太坊Layer1等同的安全性，只是说我们的多签会比其他的多签跨链桥相对更安全一些。

首先我们是更去中心化的。我们的跨链桥是基于一条PoS链的，这条链目前大概有20多个节点，需要三分之二以上的Stake，所以并没有那么容易把这条链给攻击掉，首先这方面是比较安全的。另外智能合约这层也做了很多监控和限流的措施，比如说我们有一套独立的监控系统，如果说哪一条链可能产生异常的话，我们就可以把智能合约暂时暂停掉。

我想讲一个我们做的比别人更多一步的地方，大部分的跨链桥会假设接入的每条链本身是安全的，但这个「假设」相对来说非常不靠谱，特别是现在一些比较小的链会出现问题，比如大规模重组，甚至这条链有的时候会产生回滚。我们并没有做这个假设，而是会在系统内对一些比较小、比较新的链监控和限流做的比较严格一些，特别是限流。这样即使发生了底层的问题也无大碍，接入链本身出现安全问题的话，也可以把损失控制在很低的范围内。

我们分析之前的跨链桥被黑的案例，感觉非常震惊和不可思议，这些在cBridge里都是不会发生的。cBridge主要就是依靠这样的一些安全手段，在各个层面都做了很多防范，做了非常多的努力。当然像常规的代码审计，包括一些bounty program都是比较常规的做法。

另外，我们之后可能对于Rollup的一些Layer2接入采用更高级的安全措施，把Layer2本身的安全性能集成下来，不把它当做一般的Layer1来处理，基于Rollup对其安全性进行延伸，通过类似Rollup提现的做法，把Layer1的安全性也给集成下来，这是之后大概率会进行的措施。

Rui（主持人）：明白，我一直觉得你们提的那一套有点像互联网产品里实时监控的这套逻辑，我一直还是挺Respect的，在公测能力上，在产品思路上，确实比很多出事情的项目，不一定是代码层面，更多的是机制，更多的是设计层面上会有很多不一样的地方。最后再问一下路印的郭老师，我理解当中ZK系的可能对安全性更依赖于零知识证明本身，想问一下您可能觉得ZK系上对于安全的保护、潜在的风险点。我理解零知识证明本身加密曲线、加密方式可能没有那么需要项目方本身自己去担心这方面的问题，不知道我的理解对不对。

Steve Guo：正好可以解答一下大家的误区。

首先，ZK Rollup的体系最基础的安全架构基于的假设是底层的密码学理论是安全的，基于椭圆曲线的计算底层是不可攻破的，大家都是基于这个假设来做这套系统。但在这之上，除密码学角度之外的安全性也还是要考虑蛮多的。路印是第一个ZK Rollup系统，上线时我们做了蛮多安全上的考虑，比如说现在大家都知道的二层都需要ecdsa的私钥、公链，但其实这也是我们开创出来的。比如说在二层的公私钥都是从一层的私钥通过签名方式生成出来的，而且二层的公私钥是能在一层上随时能换的，这样保证二层账号级别的安全性也是继承Layer1的。

第二，Layer2一直有一个中心化的，类似于Arbitrum刚才说的定序器，或者叫交易撮合器、中继节点。假设万一中继节点开始不干活儿，用户的数据怎么办？这个问题是一定要解决的，从一开始我们就设计了这样的一套机制，叫最终的“逃逸模式”，也是系统最初的时候就考虑的这一点。

假设路印当前的Layer2在两周之后中继完全没有响应用户的请求，整个系统就会被shutdown。一旦进入shutdown模式，所有的用户可以直接跟一层的智能合约去交互，这叫最终的“逃逸模式”。

刚刚Michael说了，比如说常规的智能合约审计、bug bounty，包括一层上的智能合约，目前路印的智能合约都是由多签控制的，而且我们也设了要有一定的时间限制之后才能去upgrade，给用户一定的时间去反映。这些都是从安全机制上来考虑的，我大概就讲这么多，安全是很重要的话题，一定是第一考虑的，任何一个DeFi协议第一优先级考虑的就是安全性怎么设计。

Rui（主持人）：说完安全，再就是说开发者，这也是挺有意思的一个问题。我理解中公链和Layer2都需要大量的中间件，包括但不限于数据服务、预言机这些已经有的，还有很多包括虚拟机怎么让用户开发得更顺利的开发者工具。我们看到以太坊上的工具还是挺完善的，而且有一些是公司维持的，也有一些是社区维持的，他们能够把这些工具做得比较好，也看到Solana、Polygon都在往这上面走，做更好的工具层，让开发者更好的介入。

大家怎么看待这些基础设施？我理解中无论是Layer2还是Layer1还是蛮需要的，就算你做了EVM的链，但你可能因为底层架构对开发者各方面体验也是不一样的。这个问题先请路印的郭老师聊，我理解当中路印作为ZK Rollup，理论上来说构建这种底层工具会更难，请郭老师。

Steve Guo：我们要构建一整套系统需要蛮多模块组件，包括大家已知的Infura节点服务，ChainLink的预言机报价服务，Dune、The Graph这样的去中心化数据索引分析的平台来展示用户数据，这都是会基于现有以太坊上的工具来构建的。

除此之外，ZK Rollup还需要蛮多自己的工具链条。比如说我举个最简单的例子，ZK Rollup整套系统里大家熟知的有几个瓶颈点：第一个，你选的ZKP算法，有几个关键计算因子，比如说FFT的变换，multiexp会导致你计算的瓶颈有TPS的限制。你递交证明到一层上，最终取决于以太坊上一层数据的消耗成本，这也会有TPS的成本上限。除了这两个已知的上限外，去实现系统时会发现还会碰到一个哈希计算的瓶颈，就像路印当时就碰到了，就必须为之把哈希计算做整套并行化处理等一系列配套工具，包括把零知识证明的电路计算做并行化，做动态的处理，这一整套系统都要搭建出来，才能让这ZK Rollup系统一直安全地跑着。

Rui（主持人）：Nervos毕竟是异构链，又是UTXO，又是各种不同的架构，其实对于开发者来说，一个是开发者对链的理解能力，再一个是相关配套能让开发者更好用的模块。您应该是特别有发言权，想请您聊一下您是怎么看待这件事的，以及您觉得这些东西现在在Nervos上是什么样的情况。

Jan：工具链对于平台来说是非常非常重要的，尤其对于新平台来说，这点上我们踩了非常多的坑，吃了很多苦头。就像刚才Rui说的，Nervos从底层就是和以太坊异构的东西，所以在工具链层面是从零开始，从头到尾都要自己重新搭一套，这个感觉好像之前已经有IOS，现在我们要做安卓，光有安卓内核是不够的，不知道听众里有没有做移动开发的，Android有ADB、IDE各种各样的帮助你开发、帮助你Debug的工具。成熟的工具链是以太坊最强大的优势所在，因为以太坊从2016 年开始发展到现在积累了七八年的工具链，以太坊一开始做开发也非常难受，因为我是做过的，在以太坊上线之前我就用过Solidity，那时候用Solidity非常困难，和现在很多新的平台是一样的，其实比现在还要差，因为现在大部分公链比较重视开发者有资源投入，但是以太坊刚出来的时候以太坊非常小，更类似普通的开源项目，连文档也没有，你根本不知道Solidity的函数只能传16个参数，超过16个就爆掉，报错等各种都非常痛苦。

但是经过了这么多年的发展，大家已经觉得它挺好用的，大家现在进入以太坊，进入Solidity，进入Dapp开发相对来说已经比较容易了。但是如果你要重新做一个平台的话，你要把以太坊做过的事情全部做一遍，而且可能要把更短的时间内做一遍才能追上它。

这点是Nervos在发展中遇到的最大困难，缺乏这些工具链。所以一开始我们是自己做了非常非常多的工具，包括Mercury、Lumos、SDK等等。但后来发现这里面不光是工具本身的问题，还有用户习惯的问题或者开发者习惯的问题，如果对于一个新人来说可能是差不多好用的东西，但是对于已经接受以太坊，接受Solidity、Dapp这套思维设计模式，已经学习了这套东西的人来说，你让他转变过来，仅仅是一样好用还是不够，这点是新平台发展中最困难的。

对于Layer2来说，一部分以太坊的Layer2没有这个问题，因为以太坊的Layer2肯定都是用EVM。对于ZK Rollup可能会有这个问题，因为ZK Rollup可能会改虚拟机，可能会在Layer2上有不同的开发体验。其实我觉得这可能也是很大的问题，现在ZK Rollup如果要做General的Rollup的话，对开发者来说是很困难的，那一点点差异就很困难。

对于ZK EVM来说，可能有80%、90%都一样，但可能有5%甚至1%不一样，大家不要小看这一点点不一样，很多开发者、开发团队都会因为这一点点不一样就不来开发了，这个坑是Optimistic踩过，我们自己也踩过，因为我们去年就已经上过一个V0版本的Rollup，在Nervos上。这个版本可以认为95%和EVM兼容，就是因为剩下的5%导致很多开发者不愿意把他的代码迁移过来，因为他迁移过来可能需要花一些工作改现有的代码。

这个月底会上Godwoken V1的版本，做到了基本上百分之百的EVM兼容，其实花了很多精力去保证和EVM的兼容性，让开发者迁移的成本更低，剩下的那5%的兼容性可能花了80%的工作，所以它其实也是挺费力气的一件事情。

但是总体来看，对于Nervos来说，我们会觉得与其花更多时间去等待Layer1工具链慢慢成熟，还不如先在Layer2做一层EVM的兼容层，这样可以让开发者更快地onboarding，可以让开发者更快的上路。

所以说，Layer2对于Nervos来说，不仅仅是一个扩容层，可能性能会更好。对于Nervos来说，更大的意义在于它是一个EVM的兼容层，可以让开发者更容易地进入到Nervos的生态里。总而言之一句话，工具链其实非常重要，如果你在做一个和以太坊异构的平台的话。除了自己把自己平台的工具链慢慢补齐以外，另外可以考虑要不要做一层和以太坊兼容的东西，这也是一个选项。

Rui（主持人）：完全理解，我特别理解你说的，因为我之前也跟一些EVM兼容的链开发者去聊。他们跟我说跟直接在以太坊上开发差蛮多的，因为底层架构的原因。所以导致他们会觉得有些点一定需要foundation来帮我做，可能对于游戏项目来说他对链底层的逻辑没有理解那么深刻，也会导致一些在游戏跟链交互、跟资产交互的体验不是那么好，这点特别重要。

这时候我特别想问Arbitrum的Nina，Arbitrum在构建开发者工具、开发者引用上会出现这种问题吗？还是说你们完全跟以太坊，跟所谓的底层是一模一样的？我大概读了你们的Paper，读了你们的白皮书，但我一直没有想过这个问题，我挺想问的，因为我觉得这个问题问会比自己想更好一些，很多朋友也会对这个事很感兴趣。在Arbitrum上开发，究竟跟在以太坊上开发是完全对等的吗？还是说会有些差异，还是会怎样？

Nina：其实Arbitrum可以说是兼容性做得非常非常好，我们是字节级别的兼容性，可能只有那么几个指令是不支持的。

其实Arbitrum上线以来，大家看到很多蓝筹项目在第一时间就迁移到Arbitrum上来了，原因很简单，因为他们不用改任何东西，他们迁移过来可能10分钟就完了，所以更多是资源上的分配问题，或者是市场上的问题，或者技术上的问题迁移到Arbitrum上，Arbitrum对这方面一直是非常非常重视，包括我们很快要做的Arbitrum Nitro升级，我们会支持WASM，这样让开发者开发起来更加顺手更加顺畅，现在开发者可以使用任何他们想要使用的语言，任何他们喜欢使用的工具，我们都是支持的，这是Arbitrum早期在战略上做的决定，我们也在之后的发展中一直非常为之受益。

另外在我们构建生态的过程中，去年5月份就开放了测试网，它就处于一个无需许可的状态，还是提交表单，然后给你发邀请。其实我们当时并没有做任何审核，并不是说必须要满足什么条件才能让你在Arbitrum上开发，而是我们想知道到底有谁在Arbitrum的生态里开发，这给了我们底层的Infrastructure、合作伙伴足够时间在Arbitrum上把他们的服务进行完善。

所以在8月份上线的时候，很多基础设施已经非常非常完善了，这时候可以吸引到更多的开发者来到我们的生态里。包括到现在我们是把开发者的交互体验放在第一位，因为我们始终认为公链服务的是开发者，是项目方，开发者和项目方服务的才是最终的终端用户。所以我们认为在开发者体验一定是最重要的使命之一。

Rui（主持人）：这点确实很有前瞻性，从最先开始构建整个网络的时候就会考虑这些问题，所以我觉得Arbitrum的很多思考，包括早期构建都特别有前瞻性，包括之前说整个验证方式在当时都是非常创新的，在现在来看也是非常适应现在的环境，这点特别厉害。

也请Michael聊一下这个问题，我理解中你们也有和BYC走得比较近，在你们角度上也有这么多EVM Convaluable开发经验，从开发者，从项目方的角度来说，你们怎么看待这些工具的完善？我知道你们接了很多很多条链，尤其很多小链，你们感觉怎么样？他们究竟差在哪儿？可能出现的问题在哪儿？

Michael：刚才几位都说得非常好，特别Jan老师说的，95%和100%的差别对于开发者来说是非常非常大的，我们也是深有体会。

比如说接一些EVM兼容的链，可能就那么一个地方不兼容，但为了它就必须把整个桥的合约做分叉，并维护分叉。因为在此之前合约都是审计过的，稍微改那么一行就可能出安全问题，需要再次审计一下保证没有出问题。之前有很多项目也是，合约在审计完之后改了一点点地方，结果就出现了安全问题，这是非常非常可惜的。如果能做到百分之百的完全兼容，确实对于开发者来说有非常大的帮助。

这是比较中立性的问题，无论是Optimism还有像刚才的Godwoken的V0，可能都有一些很前瞻性的设计，觉得以太坊本身做得不够好的地方可能会在Layer2上想做进步、进化，但有的时候走得过于超前了，对于开发者上就没有那么友好。

比如Uniswap接入Optimism第一个版本，他们改了很多代码，传说改了3000行，对我们来说这应该是非常大的改动。像账户抽象这些，包括很多原交易都是非常好的改进，但可能走得过于超前了，这是比较矛盾的问题。比如说Layer2可以在以太坊完全兼容的基础上加一些扩展的功能，用了WASM之后在百分之百兼容EVM的基础上，又可以对其他语言也提供一些支持，我相信之后的Layer2都应该有这样的考虑。像Nervos应该也是有，特别是Nervos密码学原语这一块儿非常非常灵活，所以肯定支持各种不同的VM，不仅仅是EVM，在VM层面都可以做很多扩展。

EVM本身确实有很多问题，特别是现在整个市场慢下来，EVM没有之前那么疯狂会把各个项目在各条链上复制一遍，这已经成为过去式了，大家可以更加静下心来想一下EVM的问题，包括渐进地做一些改进，这是我个人的一些观点。

从开发者工具来说，确实比较成熟，比较大的链开发者工具会做得相对完善。拿最基础的区块链浏览器来说，像Arbitrum这些Layer2可能直接用了Etherscan，当然这个服务是不给你的，让Etherscan帮你做浏览器，据我所知是百万美金级别的支出。对一些比较小的链来说是比较困难的。

还有一些链比如Nervos本身底层和EVM完全不一样的，会被迫做浏览器，但这可能需要比较长时间的打磨，而且最终的效果、用户体验对于开发者体验不如像Etherscan那么原生那么好，当然这是比较无奈的选择。

对于比较小的链，我们经常感觉基本上够用，但在系统设计上会做一些调整。比如说刚刚看的V0，我们觉得改动太大，所以暂时没有接入，等他们出了V1以后，我们第一时间进行了接入，发现兼容性方面进步很大，只有一点点不兼容性，通过自己的抽象层把它处理了一下，基本上能比较完美的接入，整个开发部署什么的都是没有问题的，这是我们在开发过程中遇到的一些感受。

我们自己也有开始做一些开发者生态，资产跨链已经完善和成熟的其他下，也做了Celer消息跨链（Celer IM），这部分也是属于中间件，可能不是底层，但属于中间件的项目，特别是在目前多链多层的环境下，对于多链的应用是必不可少的框架，通过消息跨链的框架，在不同链之间完成智能合约的调用。

这部分无论是合约、SDK、API这些相关的工作都是非常多的，我们也是在逐渐打磨开发者的框架，现在Celer IM生态也上线了不少应用并有自己的技术创新，比如一些跨链的算法、跨链Dex，基于Celer IM我们还搭建了NFT跨链基础设施。

目前合作伙伴反映相对开发体验还是比较好的，当然我们还在不断打磨整个开发者生态，希望有更多开发者来接入我们的消息跨链框架，做自己的多链Dapp应用。

Rui（主持人）：明白，我有看过Celer消息跨链、NFT跨链这一块儿，关于跨链的东西可以找个机会再细聊，因为今天主要聊的是Layer2，跨链、中间件也有非常多可以聊的话题。包括刚才各位说的很多都可以展开，时间有限，我们还是进入到下一个问题。

大家怎么看模块化区块链和定制化区块链，刚才我聊的EVM链百分之百兼容跟95%兼容我是挖了一个坑的，Michael已经填上了，刚才Michael说百分之百之后还可能105%，要加一些自己的东西进去，而不止是单纯的EVM Convaluable。

现在模块化区块链跟定制化链都还挺多的，我理解当中BYC也有这方面的打算，包括magic本身会有很多定制化链解决方案。在过程中看到了很多EV链是可能会出现的，这里面包括游戏，某种意义上来说，都是从应用走向协议的一种范式。对于这个游戏来说，用户对链的无感化也会越来越强。

下一个问题会比较偏哲学，偏意识形态的问题，公链在应用主导的生态体系下应该扮演什么样的位置？刚刚大家也说开发者很重要，但开发者做大了可能不给链交税了，这时候公链该如何自处呢？它可能想坐在和你平行的位置，这个问题也是我最近一直在思考的，公链未来无论是价值端还是用户端，跟APP究竟是什么样的关系？

这个问题Jan是最有这方面的回答权，像DAS也是基于CKB密码学原语后面扩展到其他链。CKB密码学原语的灵活性有很多可能性会出来，想请Jan先聊一下你怎么看待这个问题，未来更多的APP链对于公链是什么样的冲击？

Jan：之所以有Nervos这个项目，这个问题其实是一部分的原因。首先我觉得对于公链肯定会有冲击的，所以公链应该尽早为这个时代的来临做好准备。

“这个时代”是什么时代？这个时代是区块链技术真正流行起来被普遍应用的时代，很多Dapp已经进入了全世界80亿人的日常生活，大家可能像平常在用滴滴打车和支付宝、微信一样在用这些Dapp，大家不会再特别把它作为一个特殊的分类，这个是Dapp，那个是网页，那个是普通互联网应用，而是说它已经融为一体了。

这个时代一定会来的，至少今天参加Panel的所有嘉宾肯定相信这个时代一定会来。这个时代的特征是大家已经不在乎自己用的公链是什么了，或者已经没有意识到自己在用区块链的应用了，这个就像我们今天在做直播，没有人会关心我下面用的是TCP还是UDP，那不重要，不仅不重要，而且对于普通用户来说也搞不懂，对用户来说不了解TCP也不了解UDP是什么，他也不关心。

今天用户之所以关心区块链、Layer1、Layer2、PoW、PoS、UTXO这些名词，是因为我们还在非常早期，这其实不是正常的现象，这是只有在早期才会出现的现象，因为在早期这个行业的人还太少，在这个行业的人依然可以说是最狂热的一帮人，他们愿意比较各个技术之间的不同，我就是想用DeFi的应用，或者我就是想用一个随便什么应用，我还愿意去研究它下面用的是共识还是什么，我就想发一个NFT我还要关心它下面究竟是PoW还是PoS，它是不是环保。这个问题本身其实就很像我们买小米手机要研究小米手机到底材质是不是不锈钢一样，它是一小撮人才会去做的事情。

如果往未来看，公链一定是最下面那一层，不被大家关心的那一层，大家用就好。这时候的核心问题是公链如何捕获价值，这时候大家首先就不关心你了，你已经没有眼球的溢价了。其次很多活动已经转移到了Layer2、Layer3、Layer4，whatever，反正不在Layer1，Layer1上的交易也许没有那么多，这是一种推论。这时候Layer1的经济模型应该怎样才能捕获整个生态的价值？这是所有公链需要考虑的问题，包括比特币网络，包括以太坊，都会遇到现在的问题。

以太坊之前面临的问题是状态膨胀、全节点开销越来越大，以太坊手续费能不能支撑全节点的成本。现在因为已经要往2.0转，那么以太坊的问题可能会是经济活动都往Layer2更上层转，Layer1的手续费能不能支撑以太坊的节点成本，这个我们把它叫做Security Budget安全成本，这和一个国家维护自己的安全是很像的，你必须收税来维持自己的军队，这是最基本的道理。你的税收从什么地方来？现在以太坊上收的是交易税，交易越多收的税越多。但是当交易不再增加的时候，上层生态越来越繁荣，上层的经济体规模在增加的时候，你怎么办？是这个问题。

Nervos在这一块儿是有自己的想法的，Nervos的经济模型其实是土地税的模型，就好像一个城市，比如说以太坊是一个城市，这个城市的经济活动越繁荣，那么这个城市的交通就会越繁荣，我们给所有的车辆收过路费，是这样一种经济模型。

Nervos是说这个城市越繁荣，想要在这个城市拥有土地开展商业活动的企业就会越多，我们征收土地税，每年都要交税，是这样一种模型。这种模型的好处是即使未来这座城市大家都建高楼大厦，都往上层发展，在路上走的人已经很少了，大家都在天上开飞机，路上其实没有人了，但是你还会占用土地，这种两种不同的经济模型，一种经济模型只考虑平房，一种经济模型是为高楼大厦设计的，简单来说就是这样。

现在很多新的公链也吸收了这个事物，比如说Near以及一些其他的链，当时Near他们也来我们团队办公室聊，大家交流过这个问题，我觉得以太坊最后也会面临这个问题，即使有了ERP-1559，它还是消费税的模型，不是土地税的模型。这是我们觉得未来Crypto也好、Web3也好，整个生态成熟以后公链要考虑的问题。

再回到Nervos另外一点，Nervos一直在提互操作2.0的概念，其实想说的也是用户是不需要知道CKB的，如果大家用过“.Bit”这样的应用，或者尝试过Nervos上的NFT产品是能够感觉到，你在使用的时候不需要知道CKB，你可能没有意识到你在付手续费，你可能没有意识到你在用CKB。甚至像我刚才说的，你在用Godwoken的时候，你可能会觉得你在用ETHEREUM。这对于Nervos来说都是非常正常的现象，这是我们希望达到的目的，我们希望用户不需要知道CKB，但是在这个情况下CKB依然可以捕获价值。所以我觉得未来一定是这样。

Rui（主持人）：我这个问题也是搭着之前的问题，这些开发者工具做到最后的点在哪儿。我个人觉得可能除了刚才您说的CKB上的便捷性以及优质使用体验、开发者体验之外，还有一点是公链上会有很强的可组合性，这是Crypto 里最美妙的地方。等一下也想问一下Michael应用层面APP链的可组合性究竟能做到的效果有多好。

在这之前想问一下Arbitrum的Nina，我理解当中Arbitrum也有一些原生的生态，包括像GMX等，GMX后面选择迁移到了Avalanche的Snowman上，如果没记错的话。你们怎么看待自家的孩子被别人拐跑了，我也不知道这个形容词对不对。你们怎么看待自己的生态后面选择了别的一条链，自己收税，自己做一条子链了，我还蛮好奇这一点的，包括你们也提出过Layer3的点，包括在Layer2上再做一层Layer3，你们是怎么看待这个问题的？

Nina：这个问题问得非常好，首先因为我们跟GMX团队关系都非常好，包括现在我们也是非常紧密的和他们合作，马上上线的奥德赛的活动他们也有参加，所以我并不认为GMX是自己家的孩子被拐跑了，而是自己家孩子长大了，有一些新的朋友，他们在Avalanche生态社区还是非常活跃的。

另外有说到关于不可避免的多链、多层的未来，我觉得现在基本上所有的协议，除了游戏协议不太会要多链，因为这比较难，NFT项目也比较难去多链，但像DeFi协议大家都在走多链的战略，所以我觉得这是不可避免的。对于公链来说，我们更看重的是他们会把资源放在哪里，因为所有的DeFi协议资源都是有限的，每家公链都各自有各自的招数把资源吸引到自己的生态里。

对于DeFi协议来说，你选择建一个自己的子链，还是选择在一个生态里，其实它的问题在于他想不想占用公链生态里的资源，如果你在像Arbitrum这样的general的链上，你可以得到的是Arbitrum生态里的用户，你可以得到的是非常完善的底层架构，你可以得到的是安全性的保障，你可以得到的是生态里其他项目的可组合性。如果你选择自己做一条链的话，可能很多这些东西需要做取舍的。

这其实就是在链与链之间信息的沟通还没有特别完善的时候必然会产生的问题，也许有一天消息跨链等各种跨链基础设施做得特别好，包括连协议方都不太能感受到链与链之间区别的时候，也许那时候不太会成为一个问题，那时候可能我们会考虑不一样的东西。但现在可组合性的取舍性还是比较大的问题，如果你要自己做条子链的话，必然要放弃一些在大的公链生态里可能会得到的一些机会。这是我对这件事情的看法。

Rui（主持人）：明白，Michael到你了，你自己也说你们做消息跨链，我想问现在消息跨链到底能到什么样的级别，我理解当中消息跨链也要好几分钟。还没有办法到公链内的可组合性、链间的可组合性，APP的链越来越多，你们怎么看待这个事？我理解当中很多游戏还好，因为他们会做，但对于DeFi以及其他的来说很难抛弃可组合性。我想问现在技术开发进展到什么阶段了？以及你们怎么看待APP链的盛行。

Michael：首先是时间，4、5分钟更多是安全性的考虑，我们可以把它提高得更快，比如说两条都是头部的EVM，而且都是知道它的安全性的情况下，我们可以把时间做缩短，可以调整的，并不是严格的时间。目前以太坊是PoW的情况下，是等更多的确认数才能做到比较安全，这个时间并不是严格的一定是4、5分钟。这个问题倒不用担心，可能可以做到IBC那个程度。

整个EVM这一块儿缺跨链的标准，本来以太坊就很去中心化，从一开始并不是为了跨链而设计的，像V神或者其他人并没有推标准，没有像做到像Cosmos、IBC这样的标准。也可能是好事吧，大家更多的时间去探索，我个人觉得最终还是会有一些标准出来。像Jan老师说的TCP/IP的标准会慢慢形成，但我感觉还需要一些时间。

刚才说到业务链，这两天也是很大的新闻，dYdX从Starkware迁移到自己做基于Cosmos的应用链，对以太坊社区是比较大的打击。其实我个人不是那么感觉，我个人感觉整个公链、Layer2基础设施发展和半导体发展有点像，大家的需求会在定制化和标准化之间互相摇摆，大概是十年还是多少年一个周期。这个很有意思，大家最早有CPU，后来大家发现CPU的图形显示性能不够用搞了GPU，之后又开始做ASIC，ASIC之后大家又把它从专业化往通用化方面发展，像苹果M1芯片做了很高程度的集成，所以会有周期在。大家一会儿会想做EVM，一会儿又想做应用链，说不定过几年之后大家又会做更进化的EVM，所以也是摇摆的周期，我感觉区块链行业和半导体真的还挺像的。

应用链最有代表性的目前是Cosmos是比较火的，它的跨链、链间可组合性做得非常好，特别是into-account，可以做到原生消息跨链。我相信这个东西在EVM，特别是以太坊转PoS以后也是可以做的，因为它转了PoS可以在共识级别做消息区块头的验证，它是可以有能力把这个东西做到共识层面，并且做得更标准化一些。所以说我不是太担心。

但是它和同一条链上的可组合性，或者是同构可组合性是没法比的，我个人并不感觉这个东西特别特别不可或缺，因为这个东西一旦有的话绝大部分也是被矿工、节点把这个东西给套利套走了，对普通用户来说并不觉得同步可组合性是非常有意义的事情，所谓DeFi的可组合性可能并没有大家想象的那么重要，如果你在不同链上有套利机会，就有点像不同交易所之间的分账，其实也是有利润空间，也是有可玩性在里面的。所以我还是比较乐观的，觉得无论是应用链还是EVM之间，都可以通过Celer消息跨链框架把EVM的链都打通，当然我们也已经在接一些非EVM的链。

目前通过跨链桥做消息跨链，可以把它做到比较好的打通，并且让用户无感知在一条链做，对另外一条链的账户和合约进行操作，其实是非常低感知，甚至是无感知的，这是可以做到的。如果之后把整个东西在这些链之间把跨链往更底层去做，更底层形成协议和标准的话，可以把体验做得更好。我大概就是这些观点。

Rui（主持人）：你刚刚提的两个点都挺能深度发散去聊的，但今天确实没时间，一个是关于标准，其实区块链里的协议怎么成为标准，共识多了就是标准，大家都认这个协议，那这个协议就成了标准。再就是MEV，不同的公链、不同的Layer2 MEV的话题经久不衰，说实话，我没有想今天去聊MEV，我觉得这还是挺专业性的问题，聊MEV可以聊一整期，但今天更多聊一些市场上更多看到的Big names，这些names里背后所蕴含的观点。

想问郭老师对应用类型的这部分有什么观点？我理解中路印更关注的是交易，可能更多要把以太坊上的交易部分，包括ZK Rollup去年还是交易为主，没有到ZK更广的应用。下一个问题我想问ZK EVM、ZK VM，也是您这边很理解一直在看的一些东西。

我想两个问题一起问，一个是这些APP链会对未来路印以及其他的ZK EVM、ZK VM，这块儿上您怎么看？如果ZK EVM、ZK VM这批生态出来了，会不会被APP链所冲击，再一个是你怎么看待现在ZK EVM、ZK VM到了什么程度，究竟什么时候能大规模商用，以及它是不是所谓的下一个大的趋势，上一个大的趋势是公链的拓展，下一个趋势就是往ZK上走？我也不知道。

Steve Guo：正好两个问题一起回答，先说第一个问题，也是当下的热点，今天大家看到dYdX说要做自己的APP Chain，其实dYdX做的这个选择我一点都不惊奇，因为路印在2019年同样也做了个选择，2018年底我们同时在开发一个基于Tendermint共识引擎的一条侧链，当时的想法是这条侧链兼容EVM，把路印当前版本的协议部署到侧链里作为这条链上的Dapp，专门做交易用的一条侧链，同时也在做目前ZK Rollup的这套方案，最终我们选了ZK Rollup的这套方案，是因为对我们所专注的高频交易转账场景下，我们最关心的是用户资产的安全性，如果你采用侧链、或者说APP Chain的思路，说白了用户的资产安全性由APP Chain来保证了，这一点是我们不能接受的，所以我们最终做了个决定，沿着ZK Rollup这条路一直走下去，但是那只是我们自己基于路印协议想达到的目标做的选择而已，不同的应用、不同的协议每个人想尝试解决的问题是不一样的。

比如说dYdX的选择，他想做高频的交互，1000TPS估计满足不了他，他可能要最终到上万的TPS，在以太坊的dan sharding、链上数据成本进一步降低的整套方案还没出来之前，如果它当下想达到，那只能自己搞一条APP Chain来实现当下想做的目标，这只是一个例子。像GameFi，如果它想把游戏的逻辑都要放到链上的话，自然也只能搞一条自己的APP Chain，才能做到满足自己的需求。所以说，是不是选择APP Chain，是不是选择Layer 2的各种方案，其实完全取决于应用想要实现达到的目标。所以我认为未来一定是多链、多层的架构体系。根据不同应用场景选不同的链或者层，APP Chain链也好，Layer 2也好，这是第一个问题，我是这样来理解的。

第二个问题是ZK EVM和ZK VM的区别，或者说大家当前进展到什么程度。我大概讲一些，ZK VM和ZK EVM就一个字的区别，区别在于Jan之前提到的是不是百分之百的byte code字节级别的兼容，要做到百分之百的EVM byte code兼容才能称之为ZK EVM。

比如说大家所熟知的ZK Sync以及Starkware支持二层通用计算，其实本质上它们两个的实现算是ZK VM，它们都还没能做到百分之百的兼容性，像以太坊基金会正在做的项目Applied ZKP项目才是百分之百的byte code兼容。这个兼容性非常重要，前面Jan、Michael、Nina都提到了，尤其对开发者来说，如果能百分之百兼容，那我10分钟就能部署，我就能任意切换、无缝使用，这对开发者是特别友好的一件事情。所以我是比较看好最终走到ZK EVM这条道，我们路印自己也在延着这条道上走，未来也可能会推出自己基于ZKEVM的通用二层。

至于像Optimistic Rollup这个方案，我觉得和ZK Rollup比完全是另外一个派系了，看大家的需求去怎么选择吧。毕竟Optimistic Rollup理论上能做到比ZK Rollup这样的方案更便宜一点，还是那句话，取决于你的应用场景来决定你会部署到哪个链、哪个层上，这是我的大观点。

Rui（主持人）：感谢郭老师，这个观点确实挺有意思的，您应该算是ZK领域特别资深的，一直在这方面去开发去研究，听到您这边的观点我学习到了很多。

接下来问一下Jan老师，Jan老师Nervos也做了CKB VM服务器，最近也上了，我理解您对于ZK VM、ZK EVM一直有研究，看他们怎么做，包括你们怎么做的，我还蛮好奇关于ZK EVM的一些事儿，包括您说的百分之百兼容，也想请教一下您怎么看待以太坊最近在推的ZK EVM、ZK VM，其实是以太坊最主流的一帮人在推的，您之前也是以太坊的核心开发，想问一下您是怎么看待这件事的。

Jan：首先我们也觉得ZKP是非常重要的方向，从我们自己的判断来说，可能还是有挺长的路要走吧，因为ZKP之前研究历史很长，但是蓬勃发展也就是近两年，肯定是受了很大的Crypto力量的推动，最近在蓬勃发展。

这两年ZKP方向的论文，各个环节的论文都在爆发，像zk-STARK就是Starkware这个团队比较著名的方向，但其实也有很多其他的，包括Nervos自己也有研究员做ZKP研究，但是我们在做的ZKP研究还比较偏理论层，更加偏数学，我们还没有走到能够把理论和工程实践相结合的地步，这可能和路印这样的前辈项目相比，还是有比较大的差距。但是现在我们也不是那么着急做结合，感觉还想再观望一下理论的发展，理论这块儿还是有非常多的可能性的。

从VM本身来说，CKB-VM是Layer1的VM，它和ZK VM、ZK EVM有角度的不同，因为ZK VM想要实现的目标是方便Proof的生产，Layer1的VM目标是尽可能支持更多的Proof的验证，因为一个在Layer1，一个在Layer2，Layer1和Layer2的关系一个是生存，一个是验证，一个是阴，一个是阳。

所以我觉得大家设计的目的不一样，角度是不一样的，对于CKB-VM来说，它关心的不是我们要怎么调整VM的结构和设计更方便的生产零知识证明，而是我们怎么样可以更好的支持密码学的原语，可以验证各种零知识证明算法产生的证明，甚至说有可能理想中的零知识证明的算法现在还不存在，因为这个领域在蓬勃发展，这个算法可能是五年之后、十年之后才出来，我们怎么样能够在今天做一个设计，能够很好的向未来兼容？这是CKB-VM的角度。

在这点上，CKB-VM和同样作为Layer1虚拟机的EVM或者WASM的想法是不同的。包括EVM在内，想要向未来兼容的方法实际上没有的，兼容的方法就是硬分叉，不停地加precompile，以太坊是直接加入了做零知识证明的precompile去支持上层的ZKP应用，这也是为什么在以太坊上很多ZK Rollup的路线已经可以做了，但是它的问题是，如果我们需要兼容一些新的算法，不是zkSNARK或者zk-STARK的话，我需要再做硬分叉加新的precompile。

CKB的思路是尽可能保持虚拟机的抽象，不要依赖人为的硬编码去增加ZKP原语的支持，而是说希望可以做到大家用写智能合约的方式去写ZKP verification的合约，它不需要底层任何特殊的支持。CKB-VM做到这点的方式也是我们选择RISC-V，而不是选择直接用EVM的原因。选择RISC-V是因为RISC-V是为硬件设计的指令集，在工业界有非常成熟的工具链，TCC、LLV、VM、C、Rust的语言都可以直接编译在RISC-V上跑。之前大部分密码学算法都是C实现的，现在很多新的密码学算法都是Rust实现的，这些都可以在CKB-VM上很好的运行。

但有这里边也有非常大的技术挑战，虽然能够运行，但是效率可能不高，这是为什么CKB-VM会去尝试加入新的指令集，比如说向量指令集，比如说大数指令集，希望通过这些指令集配合编译器优化的技术，让所有的密码学算法在编译之后能够高效运行在VM上。这个思路和EVM支持ZKP的思路是完全不一样的，一个是更加通用的思路，一个是更加practical的思路，也不是说EVM不好，大家的思路不一样，EVM 想的是我现在只能做这个，那我就加一条precompile进去，我也不管那么多了。能够看到，以太坊是在走这些路。

但我觉得，可能到某个时间点，如果确实有必要的话，CKB-VM可能也会有precompile这样的东西加入，前提是如果我们自己对VM的优化速度赶不上行业发展的话，那也没办法。但是现在来看CKB-VM还有时间去优化，这是为什么我们现在在做向量指令集，计划明年把向量指令集加进去，看能够给密码学原语带来多大的计算空间，这里面还需要有不少的工作来做。总的来说，大家的思路非常不一样，EVM、CKB VM、ZK VM，大家的角度都是不一样。

Rui（主持人）：明白明白，您这段说了很多有价值的，我可能还需要回头看CKB VM，再去学习，确实很多很有意思的东西。站在投资角度，我本身做一级市场投资，我觉得更多是建立标准，CK BVM作为未来团队最接近做Layer1标准的点，这是我非常respect的，像刚才说的应用层关于开发者的开发工具，包括CKB VM，包括您这边这一套和EVM兼容的Layer2，区块链链上部分最重要的就是公链，我们看到公链这个点上您和您团队做出来的努力，这点非常厉害。

下一个想问一下Arbitrum的Nina，我理解当中Arbitrum用的是乐观卷Optimistic Rollup，我理解中以太坊基金会也在推ZK EVM这套体系，我也有听朋友说未来Arbitrum、Optimism都会引入ZK EVM，让整个体系变得更便捷。想问一下听以及Arbitrum是怎么看这件事的，你们会去拥抱潮流吗？还是说你们会是什么样的态度。

Nina：在几个月前我们有专门写过一篇文章，解释了我们为什么选择了开心卷这个技术，而没有选择零知识证明这个技术。现在大家说ZK是未来的趋势，是拿ZK EVM两年之后的成果跟开心卷今天的成果做比较，技术上是有时间差的，不能这么做比较，出去你要说ZK EVM是两年之后，那你同时也要考虑开心卷两年之后会是什么样，我们来说未来哪个是以太坊二层的未来。当然不是说一定要二选一，只是说现在大家在认知上有些偏差。

我特别喜欢刚才郭老师的观点，其实没有任何一个技术是适用于所有应用场景的，包括链上的数据可用性、包括安全性、包括交易费，都是有光谱的，没有人把技能点点在了所有点上，大家都是自己点自己的技能点，肯定是根据你的应用场景选择一个适合你的选择方案，这就是为什么我们是Arbitrum One，因为我们还会有Arbitrum Two、Arbitrum Three，包括我刚才说的我们很快会有Any Trust类似于侧链的解决方案上线。

另外ZK链上的部分现在看起来比较便宜，但它要生成零知识证明是非常非常贵的，如果大家现在看一下Starkware的区块浏览器的话，他们上一次向Layer1提交数据已经是差不多17个小时之前的事情了，原因就是他们生成零知识证明需要非常非常长的时间，非常昂贵，所以他们没有办法像今天的开心卷一样，像今天的Arbitrum一样，基本上每几分钟就会上传一下我们的数据。虽然Starkware安全性有以太坊一层保证，但是他们在过去的17个小时是没有被保证的，这也是ZK EVM现在技术的局限性。

刚刚问到会不会拥抱这项技术，我们当然是拥抱这项技术的，我们内部团队一直有同事在非常紧密的研究ZK方面技术的进展，如果有一天确实ZK技术进展到一定程度，它的可用性、经济效应、技术成熟度都达到了，都超越了开心卷的话，那我们没有必要在一条链上磕死，我们要做的事情是服务更多的项目、服务更多的用户，而不是死磕开心卷这一件事情，如果真的有一天到了那一步的话，我们当然会考虑再做这样的技术方案服务更多的生态合作伙伴。

Rui（主持人）：其实关于Starkware的新版本我也一直有在跟，包括新的验证形式还挺复杂的，现在也有团队在往更新的方向走，没有办法，因为ZK只能通过硬件来加速打包的过程，这也是ZK系统的局限性。这方面郭老师还会有很多话聊，但说实话今天确实时间有限，我们已经超了半个小时了。最后问一下Michael，未来Celer有没有加一些ZK Celer的打散？

Michael：在Optimistic Rollup方面我们做了一些尝试，说实话ZK更多处于理论研究和调研状态，当然对于跨链桥来说，如果有ZK证明的话，它对安全性肯定可以大大增加的，所以Celer目前短期内没有计划，但是我们也在持续关注这一块儿。

比如说像跨链这一块儿是属于特定的应用，相比起ZK，现在已经有比较成熟的解决方案了，如果需要将ZK VM套用到跨链桥上，还是有比较大的工程量和比较未知的技术难度，但如果用来做特定的应用对ZK还是相对比较容易能够兼容的。所以我们会保持open的心态，是有可能的，但是短期内没有这样的计划。

Rui（主持人）：今天也聊了挺多，都是很有意思的内容，中间有挺多点都还蛮有继续沟通的空间，希望下一次万向区块链还有机会再组织我们针对新的品类再聊一些更有趣更深的内容，包括安全性，这是公链Layer2大家最关心的东西，包括开发者最关心的工具，怎么样有更好的工具，现在公链上能够给到大家什么样的工具，聊了关于ZK EVM这些很新的话题，我自己也需要消化一下，今天先这样，未来有时间可以再做一些新话题的更深讨论。感谢四位的时间，谢谢大家！