本文梳理自以太坊核心开发者PeterSzilagyi在个人社交媒体平台上的观点，律动BlockBeats对其整理翻译如下：
复杂程度是一个系统中经常被忽视的一面，因为通常不是创造它的人在为它付出代价，而是其他人。但不要搞错了，有人在付出代价——无论是金钱、时间还是精力。他们可能不愿意或不可能永远这样做。
第165次以太坊核心开发者执行会议：EIP-6466和EIP-6406是代码更改，不影响升级:金色财经报道，7月6日，在ACDE #165上，以太坊开发人员讨论了：对EIP-6466和6406的影响分析；Cancun/Deneb测试工作的进展；将构建器覆盖标志包含到引擎API中；以及EIP-4788规范中包含两个环形缓冲区。
首先，EIP-6466和EIP-6406是代码更改，将两个区块头字段transactions_root和receipts_root中的数据编码从RLP更新到SSZ。安全审计公司Dedaub对EIP-6466与EIP-6406的影响分析是为了确定这些代码更改对以太坊上已部署和积极使用的智能合约的影响。分析发现，SSZ更新将影响三个主要项目：LayerZero、zkBridge（跨链桥）和预言机。尽管这些应用程序受到影响，Dedaub总监Neville Grech表示，所有三个应用程序都可以升级，以适应通过EIP-6466和6406实施的代码更改。
关于Cancun/Deneb测试，以太坊基金会的DevOps工程师Parithosh Jayanthi表示，Devnet #7Cancun/Deneb升级已于6月30日星期五成功启动。测试网络正在顺利完成，并且已经发现了客户端实施中的一些问题。Jayanthi表示，一旦客户团队修复了未解决的问题，他将尝试在更长的时间内向网络发送Blob交易，以了解网络如何处理3个目标Blob/块的负载（从2个Blob的目标增加） /block在最后一个测试网期间。
关于将构建器覆盖标志包含到引擎API中，Teku (CL) 开发人员Mikhail Kalinin询问EL客户团队是否愿意接受坎昆升级中引擎API的更改。Kalinin要求客户团队在GitHub上审查构建器标志Engine API更改，如果他们反对在7月10日星期一之前将其纳入坎昆，请大声说出来。如果没有人反对这一更改，Kalinin表示他将合并必要的更改纳入引擎API规范，以便包含在Cancun/Deneb升级中，对引擎API的更改不会记录为EIP。
此外，EIP-4788引入一种新的预编译，这是一种具有成本效益的智能合约操作，它将在EL上公开有关CL的信息，以防止通过代码更改过度使用存储空间。此功能将解锁去中心化应用程序的许多用例，例如质押池和重新质押协议，这些应用程序将受益于对CL状态的信任最小化访问。以太坊基金会研究员Alex Stokes表示，该修改将合并到最终的EIP-4788规范中，以便在坎昆尽快实施。[2023/7/9 22:27:15]
与可扩展性一样，复杂程度也会在看不到的情况下不断累积至失控点。那个时候，已经无法挽回。复杂程度还具有导致级联故障的不良影响。超负荷的人太多，丧失行动能力，导致更大的工作过载。
YFI核心开发者：ShibaSwap目前是最小可行的版本，所有流动性都可以通过一个地址轻松窃取:yearn.finance（YFI）核心开发者banteg表示，ShibaSwap目前是最小可行的版本，所有流动性都可以通过一个地址轻松窃取，并质疑为什么人们在其中投入了超过1.2亿美元？[2021/7/6 0:31:23]
在以太坊的历史上，复杂程度从未降低过。每一个EIP都堆在更上面。每一个重大变化都是一个更多的钉子。当一个研究计划书说「一切都弄明白了，现在只剩下工程了」时，我感到非常沮丧。
ins3.finance核心开发者Gavin：现有DeFi保险不够去中心化:3月15日19:00，一站式DeFi门户DeFiBox在线上举办DeFi Demo Day第二期——Heco专场， 去中心化保险与信用衍生品发行平台ins3.finance受邀参与了本次圆桌讨论环节。
ins3.finance核心开发者Gavin在圆桌中介绍到，ins3.finance是去中心化保险与信用衍生品发行平台，可以满足加密数字资产行业各种尾部极端风险的对冲需求，为各种加密数字资产场景提供保障服务。
Gavin认为当前DeFi保险赛道都无法解决一个问题：目前的DeFi保险不够去中心化，偿付使用治理代币投票决定是否偿付，缺少公正性。 在传统金融，交易（证券）、借贷（银行）、风险管理（保险）是现代金融的三驾马车，但是在DeFi领域，交易、借贷各方面的市值远超保险，出现这种情况的原因是目前DeFi保险不如交易和借贷赛道去中心化。[2021/3/15 18:46:55]
尽管感觉我们正在接近以太坊合并，但我必须强调以太坊没有朝一个简洁的方向发展。从本质上说，它正在取得成果，但它也正在堆积复杂程度，好像不用为以后发愁一样。如果协议不变得更精简，就不会成功。
我觉得根本原因在于研究人员和开发团队之间的脱节。前者「只」用想出优雅且独立的想法。后者则需要兼顾每一个曾经被引入的想法，同时想方设法把它们揉在一起。
已经有工程试图降低复杂程度。然而，从来没有降低协议复杂程度的尝试。
没有人能对系统有一个全面的了解，这很糟糕。
我说不出来解决方案是什么，但我的观点是停止增加功能并开始删减，即使这样会造成破坏。
知道并愿意拼凑一个破碎的网络的人越来越少。而每一个变化都会让更多的人离开。
原文作者：PeterSzilagyi
原文编译：0x9F，律动BlockBeats
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。