而非共识的部分，我认为以太坊还背负着很多「债务」——包括技术债、认知债，甚至是品牌债。就是说当它要进行大改革时，很多时候不能直接否定自己。历史上也有这种情况，比如中国改革开放和苏联某些领导交接时期，我们可以看到，缓慢但坚定地改革比彻底推翻过去更有效。举个例子，现在以太坊采用多客户端路线图。在执行层和共识层都有四、五种不同语言写的客户端。而我们历史上看到那些特别成功的基础设施软件，比如 Solana 本身、Linux 操作系统、HDFS 等，基本上都是用一套语言、一套测试框架来实现的。他们追求的是工程效率。而以太坊因为经历过 DAO 的攻击事件，预测到可能使用一个语言，会因为这个语言的漏洞引入了一些机制，会导致宕机。因为以太坊现在还是变化非常快的，不像比特币基本上很多的功能已经比较固化了。所以他们宁愿花十倍的工程量来预防这种风险。但是这么做的话，以太坊需要五倍到是十倍的工程力才能跟上 Solana 的节奏。这也是为什么以太坊每次升级都那么慢。我们亲身参与过以太坊的升级过程，包括 EIP 制定、DevNet、TestNet，会发现协调不同客户端之间的实现要花大量的力气。例如这次 Pectra 升级中，发现 Geth 与其他客户端配置不一致，导致不同步，必须马上修，最后发现问题出在 Geth 上。这是一个权衡问题，工程上需要花很大力气。那这里我就在思考一个问题：像以太坊这样快速变化的软件是否一定不能宕机？Solana 曾多次宕机，其他项目也一样。也许我们可以允许宕机，但恢复速度很快。同时只维护一个客户端，就能更快迭代。这其实是一个软件工程方面的问题。我看到以太坊最近也在招募比如首席性能开发师，更多关注从工程角度出发，更有效率地解决进度问题。我在大厂待过，知道宕机其实是常态。即便有钱、有工程师，也经常出问题。每次培训时都要讲我们系统宕机多少次，比如 Meta 或 Google 系统都曾在一小时内完全无法访问，这种情况不少见。所以如何克服这些问题，是一个非常值得深入讨论的问题，也是目前仍未达成共识的一个方面。
Lawrence：我理解目前大家的共识应该是过去聚焦 Layer2 的这个策略是要转向。因为这一点，我看到以太坊基金会最近确实提了一系列动作，社区其实之前就一直对这个事情有怀疑。当然这里面还有一些不太确定的部分，比如以太坊基金会对这件事的字眼，他们使用的是「优先级再定义」，也就是 Reprioritization，这听起来比较缓和。但大部分人会觉得这个应该被称为 Pivot，是一个转折，意味着需要承认过去是错误的。不过至少从目前的实际动作来看，我认为聚焦 Layer1、放弃过去 Rollup Centric 的策略是目前最有共识的一点。