APE:一文了解以太坊接下来的上海 /Capella 升级

原文来自:以太坊核心开发者TimBeiko

编译:DeFi之道

欢迎阅读有关AllCoreDevs在2022年的最后一次更新。

长话短说:

上海/Capella升级的内容已经敲定:提款,EOF,还有一些小改动……只要不耽误提款即可?

Blobspace即将到来:EIP-4844将成为以太坊下一次升级的中心,其召唤仪式即将开始

开发者们正在努力协调执行客户端和共识客户端升级过程的技术方面。我们还看到了关于更好地将社区的意见纳入流程的积极讨论

上海/Capella升级?

在最近一次AllCoreDevs电话会议上,客户端团队就上海/Capella升级的最终范围达成了共识。虽然升级的名称可能仍有争议,但团队们已经清楚了升级的范围,这次升级的主要任务是为质押者引入信标链提款。尽快解决这个问题是客户端团队的目标,因此升级中的其他功能需要同时准备好,或者有可能会被移除。

上海EL规范列出了所有包含的EIP:

EIP-3540:EVM对象格式(EOF)v1

EIP-3651:WarmCOINBASE?

EIP-3670:EOF-代码验证?

EIP-3855:PUSH0指令?

EIP-3860:限制和计量initcode?

EIP-4200:EOF-静态相对jumps?

EIP-4750:EOF-函数?

EIP-4895:信标链推送提款操作?

EIP-5450:EOF-堆栈验证?

a16z crypto引入Lasso和Jolt工具来增强零知识证明:金色财经报道,风险投资公司 Andreessen Horowitz 的加密货币部门 a16z crypto 推出了 Lasso 和 Jolt,这是一对基于简洁非交互式知识论证(SNARK)的新工具。SNARK 是一种零知识证明,有可能促进第 2 层空间中的可扩展 ZK Rollup,这通常被视为计算密集型。Lasso 是 a16z 两篇研究论文的主要创新,它采用了“查找参数”机制,有利于更快的零知识证明。它将特定的输入与相应的输出相匹配,而不泄露额外的信息。该团队指出,Lasso 引入了一种简化的方法来验证 SNARK,通过对大量结构化表执行查找来避免繁琐的手动优化电路。[2023/8/11 16:18:58]

虽然列表很长,但我们可以将它们分为三个不同的部分:小改进、EVM对象格式以及提款。让我们来逐一分析:

小改进

EIP-3651:WarmCOINBASE

该EIP修复了EIP-2929中的一个疏忽,该疏忽根据客户端是否已将数据字段存储在内存中或需要从磁盘中检索它们来更改访问某些数据字段的gas成本。

EIP-2929在每个事务开始时,将客户端内存中的两段数据设置为WARM:发送地址和接收地址。EIP-3651在这个列表中添加了第三个地址,即COINBASE地址,因为它也是客户端在处理区块交易时在内存中的地址。

EIP-3855:PUSH0指令

顾名思义,EIP-3855引入了一个将值0推入堆栈的操作码。Pushing0经常用于填充EVM中的值,此操作码将提供一种更有效、更便宜的方法来实现这一点。

区块链网络Neutron将在Cosmos的Replicated Security上启动:金色财经报道,区块链网络 Neutron 已获得 Cosmos 链间服务提供商 Cosmos Hub 的批准,在 Replicated Security (RS) 上启动,该提案以 61% 的投票率获得通过。Neutron 旨在通过使用 CosmWasm (Cosmos WebAssembly) 将智能合约引入 Cosmos 网络。(Blockworks)[2023/5/9 14:50:54]

EIP-3860:限制和计量initcode

该EIP增加了initcode的最大大小,并引入了基于其长度的gas计量。大小限制为EVM添加了一个不变量,这将使推理和提出更改变得更容易。

引入了一个2gas/32字节的initcode开销,以说明客户端在执行之前必须执行的jumpdest分析,这在以前的gas计划中并没有被考虑到。

EVM对象格式?

上海升级包括的大多数EIP都是单一功能的一部分:EVM对象格式(EOF)。这项升级工作被分解为5个不同的EIP,以帮助客户端开发人员单独地解释每个更改,但为了提供更高层次的概述,本周发布了一个统一的规范。这5个EOFEIP分别是:

1、EIP-3540:EVM对象格式(EOF)v1

2、EIP-3670:EOF-代码验证

3、EIP-4200:EOF-静态相对跳转

4、EIP-4750:EOF-函数

5、EIP-5450:EOF-堆栈验证

值得注意的是,EOF的第一步是在伦敦升级中使用EIP-3541,它为EOF合约保留了0xEF00前缀。在过去的几个月里,上海EOF升级的范围也发生了变化。

美联储将加息至16年高点并讨论暂停加息:5月1日消息,“美联储传声筒”Nick Timiraos撰文称,美联储将在本周再次加息25个基点,同时讨论本次加息后的利率水平是否足以让美联储暂停本次加息周期。在本周利率决定前,美联储可能会密切关注投资者对摩根大通-第一共和银行交易的反应。尽管分析师认为,这一交易可能能够进一步缓和潜在的银行业压力,但如果在FOMC会议前出现严重的金融方面的意外,官员们可能不得不重新考虑加息计划。此外,美国经济已经显示出降温的迹象,包括消费者支出和工厂活动更加疲软。但稳定的就业和快速的工资增长可能会将通胀维持在高位。但本周会议过后,美联储官员们可能需要看到经济增长、就业和通胀强于预期的迹象,才能继续加息。[2023/5/1 14:37:23]

2月份,客户端团队同意为上海升级考虑两个最小的EOFEIP:EIP3540和EIP3670。它们将充当构建块,但如果不引入EIP4200、EIP4750以及EIP5450将无法提供全部功能。虽然有可能扩展EOF,但向后不兼容的扩展可能需要一次版本升级。由于具有特定版本的前EOF或EOF合约必须始终可执行,因此每个新的EOF版本都意味着客户端开发人员必须维护一组与旧规则并行的新EVM执行规则。

在EOF之前,客户端一次只维护一组EVM规则。代码库还支持历史EVM规则,这些规则可以改变每次网络升级,但一旦它们到达链的顶端,就只能应用最新的规则。而使用EOF,客户端将维护两个并行的EVM规则集,因此它们可以在EOF和非EOF合约中执行代码。换句话说,EOF版本bumps增加了并行的数量,而不是顺序的,必须维护的EVM规则集。

出于这个原因,在过去的几个月里,客户端团队开始更喜欢一种“大EOF”方法。这样,虽然他们必须实施更大的变更集,但EOF版本将保持更长时间,从而减少要维护的“并行EVM”的数量。因此,“大EOF”被考虑并最终纳入到接下来的上海升级中。

星巴克Web3平台Starbucks Odyssey将于12月8号上线测试版:12月6日消息,星巴克Web3平台Starbucks Odyssey将于12月8号面向候补名单成员上线测试版本,收到邀请的用户将有3天的时间注册,注册用户可通过参与娱乐互动活动以赚取可收藏的数字“旅程印章”(Journey Stamp)和Odyssey积分。此外,Starbucks Odyssey每个月都将开放更多注册资格。[2022/12/6 21:26:09]

也就是说,更大的功能显然更难以实施和测试,而客户端团队们并不希望看到EOF显着延迟信标链提款。因此,客户端团队们同意,如果到明年1月,EOF实施不完整且相互之间无法快速互操作,则将EOF从上海移除。

在这个背景下,现在让我们简单地介绍一下各种EOFEIP:

EIP-3540:EVM对象格式(EOF)v1

该EIP为EOF合约引入了“容器”。它在合约中添加了区分代码和数据部分的标记,并防止部署不符合格式的EOF合约。这保证了任何链上EOF合约都将遵循有效的布局,从而简化了与这些合约的交互以及对它们的静态分析。

EIP-3670:EOF-代码验证

EIP-3670建立在EIP-3540引入的容器之上,确保合约EOF中的代码有效,或阻止其部署。

这意味着未定义的操作码无法在EOF合约中部署,这具有减少所需的EOF版本更新数量的额外好处。如果添加了新的操作码,只需更改验证规则即可启用它,并且可以保证没有EOF部署的合约在其代码部分引用它。

EIP-4200:EOF-静态相对JUMPs

EIP-4200引入了第一个EOF专用操作码:RJUMP、RJUMPI和RJUMPV,它们将目标编码为带符号的即时值。编译器可以使用这些新的JUMP操作码来优化gas成本,因为它们消除了对现有JUMP和JUMPI操作码所需的运行时jumpdest分析的需要。

英国央行副行长:明年将就数字资产支付系统的监管框架进行磋商:金色财经报道,英国央行副行长Jon Cunliffe表示,并不认为金融的风险可以通过DeFi的代码进行有效管理,且无法得知谁在真正控制协议的治理。Jon Cunliffe称,明年将就数字资产支付系统的监管框架进行磋商。英国财政部还将就如何将投资者保护、市场诚信和其他涵盖金融产品推广和交易的监管框架扩展到涉及加密资产的活动和实体进行磋商。(The Block)[2022/11/21 7:52:18]

EIP-4750:EOF-函数

EIP-4750比EIP-4200的功能更进一步:它不允许JUMP和JUMPI操作码,并为RJUMP、RJUMPI和RJUMPV无法复制的函数添加了替代方案。它通过在EOF字节码中引入特定的函数部分来实现这一点,这些函数部分可以分别使用新的JUMPF、CALLF和RETF操作码跳转到、调用以及返回。

EIP-5450:EOF-堆栈验证

最后,EIP-5450为EOF合约添加了另一个验证检查,这次是围绕堆栈进行的。该EIP可防止EOF合约部署可能导致堆栈下溢,以及某些溢出情况的代码。有了这个,客户端可以减少它们在执行EOF合约期间进行的验证检查的数量,因为它们可以更好地保证与堆栈相关的异常。

作为一名非EVM专家,以上就是我能带你走的最远的地方!如果你想深入了解EOF,我推荐你们阅读Geth的lightclients或Solidity的Leo的帖子。

信标链提款?

最后但同样重要的是,“Shapella”的主要组成部分是信标链提款。这一变化在共识层规范以及EIP-4895中都有规定。现在稍微有点过时的元规范将这些联系在了一起。

下面简单说说提款的工作原理:

当提出一个区块时,验证器通过验证器索引线性扫描,找到前16个具有0x01凭据的验证器,这些验证器要么:

余额超过32ETH

可提款

根据这些,验证器将创建一个提款列表,以包含在他们的ExecutionPayload中。该列表中的每一项都包含以下内容:

WithdrawalIndex:所有提款中的索引——这有助于区分从同一验证器到同一地址的相同金额的提款;

ValidatorIndex:余额被提取的验证器的索引;

ExecutionAddress:需要发送提款的执行层ETH地址;

Amount:要发送到ExecutionAddress的金额,以gwei为单位;

在构建或处理区块时,EL客户端将在交易执行后应用这些提款。换句话说,处理提款类似于工作量证明奖励的记入方式,并且不会与用户交易争夺区块空间。

还有一些值得注意的细节:

在处理提款时,“全部”和“部分”提款在优先级/顺序方面没有区别。一旦验证器离开退出队列,就会发生完全提款,当对验证器集的线性扫描到达验证器的索引时,部分提款会定期发生。

为了处理提款,验证器必须使用0x01凭证,它代表一个ETH地址。在信标链启动时,只允许使用BLS密钥对的0x00凭据。为了启用提款,具有0x00凭证的验证器将需要签署BLSToExecutionChange消息。这些将作为Capella升级的一部分启用。验证者可以期待多种工具的支持和教程来签署此消息。

对验证器集的扫描以每个区块为界。如果在扫描验证器集的一个子集后,没有16个提款需要处理,验证器将停止扫描,下一个将从上次扫描的验证器索引中提取。

与往常一样,将有几个开发者测试网和测试网供验证者运行整个过程,并在主网上线之前解决所有问题。

不过,上海/Capella升级并不是唯一取得进展的升级!开发团队们也一直在期待下一个升级。

Cancun升级??

上海升级的内容已定,但很多CFI的EIP没有被纳入,客户端团队开始讨论下一次Cancun升级应该考虑纳入什么??

在CL方面,EIP-4844已被指定为capella后的第一个升级?。EL尚未支持这种布局规范,但EL团队同意遵循类似的路径,并将下一次升级围绕EIP-4844进行。

按照使用devcon城市名称进行升级的惯例,开发者创建了cancun.md,并正式将EIP-4844包含在这次升级当中。

这个决定是在2022AllCoreDevs电话会议的最后几分钟做出的,所以没有时间讨论其他提案。那些在上海升级获得CFI,但没有入选的EIP,已被转移到Cancun的CFI名单上,以太坊魔术师论坛已创建了帖子?来讨论Cancun候选EIP。明年初,关于Cancun范围的讨论将正式开始。

KZG仪式

另一件与Cancun升级相关的事情是KZG仪式???,这是EIP-4844的一项要求。

仪式将生成验证blob数据有效性所需的随机性。要使它被认为是安全的,必须只有一个参与者诚实地参与。

从明年1月开始,这个仪式将向所有人开放几个月。目标是获得10,000名贡献者,这计划成为迄今为止规模最大的此类仪式!如果你想确保自己不错过它,请关注TrentVanEpps?!

合并后升级过程

正如之前的更新中提到的,合并后的一个大的待办事项是在EL和CL中协调以太坊的升级过程。EL使用黄皮书和EIP来指定更改,而CL使用可执行的Python规范。

EL流程的优势在于EIP被社区所熟知,并且其格式能够清楚地呈现提案背后的原因。大量数学的黄皮书与EIP相结合,并且需要将规范置于EIP的上下文中,这使得执行层规范既难以理解又难以扩展。

CL方面有相反的问题:它有一个清晰易懂的规范,存在于一个单一的存储库中,但是更改不能明确地识别,并且提案被隐藏在存储库中的其他开放PR中。

随着以太坊执行层规范的引入,我们有望弥合EL方面的差距。而且,通过一些流程争论,我们也许能够将EIP作为CL流程的一部分引入……!

也就是说,随着上海升级范围的讨论和最终确定,很明显这个过程中可能会缺少另一个“部分”:让社区表达他们对更改的相对偏好,参与关于升级整体范围的讨论(而不是单个EIP),并将其纳入AllCoreDevs和CL电话会议的决策中。

目前还不太清楚这是什么样子的——我很乐意提供建议!-但随着积极参与协议更改的利益相关者数量以及L1变更对两者影响的领域数量的增长,显然需要一些东西。

幸运的是,我们并不是从头开始:以太坊魔术师论坛已经存在多年,其IRL聚会以及临时分组讨论室或社区电话会议可能是扩展的良好起点。

期待2023年初,有关于这方面的更多更新!

下一步

2022年就这样结束了,多棒的一年啊!三个月前,我们甚至还没有合并!而现在,以太坊正在后台默默地运行权益证明,重点已经转移到即将发生的事情上。

随着一月份假期的结束,你可以期待:

上海/Capella开发者测试网和影子分叉

KZG仪式正在进行

围绕Cancun升级的讨论,以及网络升级过程应该如何演进以更好地捕捉社区的偏好

谢谢阅读!感谢在过去一年中花时间努力改进以太坊的每个人-我们做了很多工作。希望你们都有一个应得的假期。

2023年见

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

地球链

[0:31ms0-1:381ms