本系列文章旨在总结核心协议开发的进展，以便以太坊社区更好地理解与消化。“AllCoreDevs 更新” 系列可以说是“核心开发者会议视频&文字记录” 以及我的推特总结的姐妹篇。

希望我的总结可以将核心开发者们正在讨论的问题分享给以太坊社区更广泛的人群中，因此更多人可以了解以太坊社区正在发生什么；并对其进行反馈；甚至贡献自己的解决方案。

摘要

柏林升级

柏林升级内容已经在所有主要测试网部署，并且将在 4 月 14 日，区块高度 12,244,000 上线主网。此次升级将提高以太坊的安全性，并为伦敦升级中的 EIP-1559 部署做好准备。如果读者正在运行一个节点并且还没更新客户端版本，尽快去更新！至于客户端更新的版本，《以太坊柏林升级公告》内有公布。

在安全方面，访问以太坊状态的操作码的 gas 费与其计算成本相比价格过低了，而 EIP-2929 可以解决该问题。利用操作码 gas 费过低这一点，恶意参与者可以创建重复调用这些操作码的区块，而这些区块的处理速度比普通区块慢几个数量级。EIP-2929 通过提供 gas 成本约 3 倍来缓解这一问题。还有客户端方面，改进了数据库管理。比如 Geth 客户端的快照数据库格式也有助于更有效地处理状态访问较多的区块。

然而为了减轻 EIP-2929 对用户的负面影响，柏林升级引进了与其配套的 EIP-2930。它允许用户在提交交易时指定一个“访问列表”，以使用低于 2929 规定的 gas 费。这其中 gas 费的计算方法有些复杂，但是，从高层次来看，如果客户端提前知道交易将涉及状态的哪一部分，他们就可以预加载，对这些访问收取更少的 gas 费。我鼓励大家参考这个 EIP 进行精确的计算。

对于想要体验生成“访问清单”功能的应用和钱包开发者，Geth 客户端很快就会上线相关的工具了? 可以点击这里查看开发进程：

更广泛地说，如果你是一名应用或钱包开发者，现在是时候在测试网上测试柏林升级的内容了！

关于 EIP-1559，柏林在两个方面提供帮助。首先，EIP-2929 解决了 EIP-1559 的最大风险：DoS 攻击会在比现在大两倍的区块上进行。这是客户端开发者们反对 EIP-1559 的首个原因，并且每次在核心开发者会议中讨论 1559 时都会讨论到这个问题。换句话说，如果没有 2929，我们就不能稳妥地上线 1559。

第二，柏林通过 EIP-2718 在协议级别引进了对多种交易类型的支持。EIP-2930 引进的“访问清单”创建功能需要一种新的交易类型，因此 EIP-2718 提供了一个全面的框架以支持多种交易类型。这意味着，在柏林中实现 2718 和 2930 允许客户端团队提前做架构基础工作，为支持 1559 类型的交易做好准备。

“状态数据膨胀” 问题的技术路径：无状态性

一. 引言

本文的目的在于向大家介绍一种解决 “状态数据膨胀” 问题的技术路径 —— “无状态性（statelessness）”。“状态数据膨胀” 是所有允许用户自主写入状态数据的公链都会面临的问题，指的是因为用户及合约的不断增加，在全节点处保存的状态数据会越来越多。不断增加的状态数据会带来一系列风险，包括：抬高全节点的运行门槛；使链上操作的定价失衡。

在本文中我主要拿以太坊区块链来举例，这是因为我对以太坊最熟悉，但状态数据膨胀问题是普遍的，不是以太坊独有的。我同样也会举出我所知的其他项目对这个问题的思考。

为使大家充分理解 “无状态性” 的意义，我少不了要在开篇交代一下问题的背景。然后我会介绍以太坊社区为此提出的几个概念，以及相关的 开放问题/权衡取舍。最后，我会再回到最初的问题，以期通过对问题的多样描述（以及引出来的解决方案思路），拓宽对该问题的思考。

二. 状态数据膨胀问题

可以把 “区块链协议” 理解为一种让不定数量的计算机的行为统一步调成一台计算机的协议。那么，其运行会在参与相关协议的计算机（即 “节点”）处产生两种数据：一种是区块数据，即我们常说的区块链，这部分数据记录了这个网络（这台计算机）在过去发生的所有事情；另一种是状态数据，即代表当前整个网络的状态的数据，对以太坊来说，“状态” 的内涵包括：哪个账户有多少余额、已经发出过多少笔事务（不包括曾经发出的事务的内容，那是区块数据）；哪个合约的代码是什么，其内部的哪个存储项的值是什么；还有一些与共识机制运行相关的数据。

欧易okex以太坊今日行情

#欧易OKEx##数字货币##以太坊#

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

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