Elrond节点升级
## 简介
一旦一个新节点的二进制文件准备好被部署在一个网络(mainnet、testnet 或 devnet)上，节点操作员必须执行到最新版本的升级。这些发布总是在Elrond上宣布，验证者聊天 plus 通过其他沟通渠道，视情况而定。
升级类型
目前，我们有以下类型的升级:
A.- 所有节点都需要升级:升级涉及处理具有激活时期的变化(如下所述)，并且必须由所有节点运营商执行，以便在网络上保持相同的视图，并且不会导致服务中断。
B.- 可选升级:例如，简单地添加一个新的 Rest API 端点或改进 trie 同步计时的升级从处理的角度来看并不重要，它们是可选的。如果节点运营商认为新功能对他们有帮助，他们可以继续升级，而不会失去与网络的兼容性。
C.- 只有验证器需要升级:升级，例如，包括只触发验证器的新特性(评级变化、交易选择改进等等)。观察者(没有附加利害关系的节点)不需要执行升级(但是如果需要，仍然可以升级)。
激活纪元
为了使升级尽可能顺利，并确保每个节点在给定时刻在网络上具有相同的视图，Elrond具有所谓的激活时期机制，该机制允许节点实现协议的两种行为——旧的(当前的)行为和新的行为，计划在特定时期激活。这种机制确保，直到协议改变变得活跃，具有升级的代码库/二进制的节点保持与没有执行升级的节点兼容，并且保持一致。尽管在 99.9%的情况下会发生这种情况，但由于在执行第三方(Elrond区块链用户)生成的交易的同时升级代码库时会出现不可预见的后果，因此这并不能得到 100%的保证
用于升级的确定性时间/高度
与在特定块高度开始执行升级的其他协议相比，Elrond节点的版本不具有新更新生效的特定块高度，而是激活时期中的第一块将使节点继续进行组件的更新版本。
由于不能预先知道历元中第一个块的高度(由于可能的回滚)，所以不能计算特征变得有效的网络高度。
然而，一个 bugfix 的新特性生效的时间是可以计算的，因为历元有固定的循环长度。目前，Elrond Mainnet 有14,400轮的周期，一轮为6 sec。这导致了一个24h时代的到来。但是，由于纪元元块开始的回滚，可能会有几轮延迟。
激活纪元示例
例如，假设我们想要引入一个特性，以便智能合约可以接收一个PayableBySC元数据，该元数据将允许它们从其他智能合约接收 EGLD 或其他代币。
时间线示例
-
Elrond主网正处于
590时代。 -
目前，节点二进制不知道
PayableBySC元数据，所以如果有人想尝试它，就会返回类似invalid metadata的错误。 -
在纪元
600时，我们发布一个新的节点二进制文件，其中包含从纪元613开始生效的PayableBySC元数据。 -
所有节点操作员执行升级。
-
当纪元
613开始时，新特征被激活，并且新的元数据被识别和接受。 -
如果你想发布一个聪明的合约，它将会起作用。
-
没有执行升级的节点将产生不同的交易输出(与大多数节点相比),并且无法跟上链的其余部分。
向后兼容性解释 :
如果一个人想用发布的二进制文件处理自创世纪以来的所有块(通过full archive或import-db),它会这样做:
- 例如，如果在纪元
455中有一个交易试图设置PayableBySC元数据，它将把它作为invalid metadata来处理 - 对于比
613晚的时期中的交易，它将处理新的元数据。
| 纪元< 613 年 | 纪元> = 613 | |
|---|---|---|
| IsPayableBySC | invalid metadata |
successful |
