以太坊 2.0「权益证明」硬分叉的历史是复杂的。它始于向现有执行层添加信标层，在信标层启动权益证明共识的同时，执行层仍然维持工作量证明（phase0 和 altair 硬分叉）。随后，在 bellatrix 硬分叉中完全激活 pos（尽管未启用提款）。接着，capella 硬分叉允许提款，完成了验证者生命周期。最近的硬分叉 deneb（dencun（deneb/cancun）升级的一部分）对信标链参数进行了小幅修订，例如包含证明的时间窗口、处理自愿退出和验证者更换限制。dencun 中的主要变化发生在执行层，推出了 blob 交易、blob gas、用于 blob 的 kzg 承诺，并废弃了 selfdestruct 操作。
现在，Prague/Electra （即 Pectra）硬分叉为执行和共识层引入了重要的升级。作为 Lido 项目的审计员，我们主要关注此硬分叉中的共识和质押相关的变化。不过，我们无法忽视 Prague 中的执行层变化，因为它们包括影响以太坊网络及验证者的重要特性。让我们深入这些变化的细节。
Pectra 的更高层次概述
Electra 为信标层引入了众多功能。主要更新包括：
允许验证者的有效余额在 32 至 2048 ETH 之间变化（而不是固定的 32 ETH）。
允许验证者通过二级「提款」凭证发起退出（不再需要活跃验证者密钥）。
更改信标层处理 Eth1 存款的方式（不再从存款合约解析事件）。
为在信标层上处理来自常规 Eth1 合约的请求添加新的通用框架（类似于 Electra 前存款的管理方式）。
与此同时，Prague 对执行层引入了以下变化：
一个新的预编译合约，支持 BLS12-381 曲线以验证 zkSNARK 证据（除了流行的 BN254 曲线）。
一个新的系统合约，用于存储和访问多达 8192 个历史区块哈希（对无状态客户端非常有用）。
增加 calldata gas 成本，以减少区块大小并鼓励项目将 calldata 密集型操作（如 rollup）迁移到 Dencun 中引入的 blobs。
支持每个 Eth1 区块数量更多的 blobs，并提供 API 以读取这些数量。
允许 EOA（外部拥有账户）拥有自己的账户代码，极大地扩展了 EOA 可以执行的操作，如执行 multicalls 或将执行委托给其他地址。
让我们参考相关的以太坊改进提案 (EIP)，以便进一步讨论：
EIP-7251: 增加 MAX_EFFECTIVE_BALANCE
EIP-7002: 执行层可触发的退出
EIP-6110: 链上提供验证者存款
EIP-7549: 将委员会索引移出证明
EIP-7685: 通用执行层请求
EIP-2537: BLS12-381 曲线操作的预编译
EIP-2935: 在状态中保存历史区块哈希
EIP-7623: 增加 calldata 成本
EIP-7691: blob 吞吐量增加
EIP-7840: 向 EL 配置文件添加 blob 调度
EIP-7702: 设置 EOA 账户代码
这些 EIP 中有些主要涉及共识（信标）层，而其他与执行层有关。有些跨越两个层，因为某些操作（如存款和提款）需要在共识和执行层之间进行同步变化。由于这种相互依赖性，将 Electra 和 Prague 分开是不切实际的，因此我们将依次回顾每个 EIP，并指定每种情况下受影响的以太坊组件。
EIP-7251: 增加 MAX_EFFECTIVE_BALANCE
参考: EIP-7251
自第一次 Phase0 硬分叉以来，为了准备以太坊的权益证明，直到 Electra 之前，验证者的最大有效余额固定为 32 ETH。激活验证者 要求 至少为 spec.min_activation_balance（32 ETH）。激活后，验证者从这个最大有效余额开始，但可以将其有效余额减少到 spec.ejection_balance（16 ETH），并在达到该阈值时 被驱逐。这种「最小」逻辑在 Electra 中保持不变，但现在 spec.max_effective_balance 已增加到 2048 ETH。因此，验证者可以在 32 到 2048 ETH 之间存款以激活，所有这些金额都将贡献其有效余额。这一转变标志着从「32ETH- 权益证明」转向「权益证明」 :)
这个可变的有效余额现在将被用于：
增加 成为区块提议者的概率，与有效余额成正比
增加 成为同步委员会成员的概率，与有效余额成正比
作为计算相对削减和不活跃处罚金额的基础
前两个活动是验证者最有回报的操作。因此，在 Electra 之后，大额质押的验证者将更频繁地参与区块提议和同步委员会，其频率与他们的有效余额成正比。
另一个影响与削减有关。所有削减罚金与验证者的有效余额成正比：
「立即」和「延迟」的削减罚金对高额质押的验证者来说更大。
与有高额质押的被削减验证者一起的「延迟」削减罚金也更大，因为总质押中的「被削减」部分变得 更大。
报告有效余额较高的验证者的举报者 获得 更大比例的被削减的质押。
Electra 还提出了对削减比例的更改，定义了被削减的验证者余额的一部分，并由举报者接收。
接下来是无效性影响。当验证者在活跃时（证明或提议）离线时，无效性分数会累积，导致每个周期施加无效性惩罚。这些惩罚也与验证者的有效余额成比例关系。
由于有效余额的增加，验证者的「更换限制」也发生了变化。在「Electra 之前」的以太坊中，验证者通常具有相同的有效余额，退出更换限制定义为「在一个周期内，最多不能有 1/65536（spec.churn_limit_quotient）的总质押可以退出。」这创建了一个「固定」的具有相同质押的验证者退出数量。然而，在「Electra 之后」，可能出现只有少数「鲸鱼」退出的情况，因为它们代表了总质押的一个重要部分。
另一个考虑是单个验证者实例上许多验证者密钥的轮换。大型验证者目前被迫在一个实例上运行数千个验证者密钥，以适应大额质押，将其拆分为 32 ETH 部分。随着 Electra，这种行为不再是强制性的。从财务角度来看，这一变化影响不大，因为奖励和概率与质押金额线性缩放。因此，100 个每个 32 ETH 的验证者等同于一个 3200 ETH 的验证者。此外，多个活跃的验证者密钥可以具有相同的 Eth1 取款凭证，允许所有奖励提取到单个 ETH 地址，从而避免与奖励合并相关的 gas 成本。然而，管理大量密钥会产生额外的管理成本。
聚合验证者的余额的能力增加了一种新的执行层请求类型。之前，我们有存款和取款。现在，将会有另一种类型：聚合请求。它将两个验证者合并为一个。该操作请求将包括源验证者的公钥和目标公钥，并将类似于存款和取款进行处理。聚合也将有待处理的请求和余额更换限制，就像存款和取款一样。
总结如下：
对于小型的独立验证者，Electra 引入了自动增加其有效余额（和奖励）的能力。之前，任何超出 32 ETH 的盈余只能提取，但在 Electra 之后，这一盈余最终将贡献于其有效余额。然而，有效余额只能按照 spec.effective_balance_increment（1 ETH）的倍数增加，这意味着增加仅在达到下一个「1 ETH 界限」后发生。
对于大型独立验证者，Electra 通过允许将多个活跃验证者密钥整合为一个，提供了显著的管理简化。虽然这并不会改变游戏规则，但经营一个 1x2048 质押无疑比管理 64x32 质押要简单得多。
对于流动质押提供者，他们从用户那里收集小额质押并在验证者之间分配，Electra 在质押分配方案中增加了更多灵活性，但同时也需要对基于固定 32 ETH 有效余额的验证者会计进行严重重构。
另一个重要话题是验证者的历史数据和利润估算，对新参与者尤其相关，他们试图评估风险和回报。在 Electra 之前（截至本文撰写时），32 ETH 上限（无论是最小还是最大，实际上）在历史数据中创造了均匀性。所有验证者的有效余额、奖励、个体削减惩罚、区块提议频率和其他指标都相同。这种均匀性使以太坊能够在没有统计异常值的情况下测试其共识机制，从而收集有价值的网络行为数据。
在 Electra 之后，质押的分布将发生重大变化。大型验证者在区块提议和同步委员会中的参与将更频繁，在削减事件中将面临更大的惩罚，并对延迟削减、激活队列和退出队列有更大的影响。虽然这可能在数据聚合中造成挑战，但以太坊的共识确保非线性计算是最小的。唯一的非线性组件使用 sqrt(total_effective_balance) 来计算基本奖励，这适用于所有验证者。这意味着验证者奖励和削减仍然可以在「每 1 ETH」基础上（或更准确地说，根据 spec.effective_balance_increment，这可能在未来发生变化）进行估算。
有关更多详细信息，请参阅我们之前关于验证者行为的文章 。
EIP-7002：可触发的执行层退出
参考：EIP-7002
以太坊中的每个验证者都有两个密钥对：一个活跃密钥和一个取款密钥。活跃的公共 BLS 密钥作为验证者在信标链中的主要身份，该密钥对用于签署区块、证明、削减、同步委员会聚合，以及（在此 EIP 之前）自愿退出（以在延迟后启动验证者的共识退出）。第二个密钥对（「取款凭证」）可以是另一个 BLS 密钥对或常规的 Eth1 账户（私钥和地址）。现在，提取到 ETH 地址需要由活跃 BLS 私钥签名的取款消息。这一 EIP 进行了更改。
实际上，这两个（活跃和取款）密钥对的所有者可以是不同的。验证者的活跃密钥负责验证职责：运行服务器、保持其正常运行等，而取款凭证通常由质押所有者控制，质押所有者接收奖励并负责资金。目前，只有控制取款凭证的质押所有者无法启动验证者的退出，只能提取奖励。这种情况允许验证者的活跃密钥所有者有效地将验证者的余额作为「人质」握在手中。验证者可以「预签」退出消息并将其交给质押所有者，但这种变通方法并不理想。此外，目前提取和退出都需要通过专门的 API 与信标层验证者进行交互。
最佳解决方案是允许质押所有者通过常规智能合约调用同时执行退出和取款操作。这涉及标准的 Eth1 签名检查，大大简化了操作。
这一 EIP 允许质押所有者通过从他们的 ETH 地址向专用智能合约发送标准交易来触发取款和退出（类似于现有的使用「存款」合约的存款过程）。提取（或在移除足够质押时进行的退出）过程如下：
质押者向系统的「取款」合约发送取款请求（「in」请求）。
合约收取特定的费用（以 ETH 计）以减轻潜在的恶意攻击，并类似于 EIP-1559，在请求队列繁忙时费用会增加。
合约将「in」取款 / 退出请求保存到其存储中。
当一个区块被提议到信标层时，队列中的「in」取款 / 退出请求会从存储中检索。
信标层处理「in」请求，与活跃验证者的余额交互，安排验证者退出，并形成「out」取款请求。
「out」取款请求在执行层处理，质押者接收他们的 ETH。
虽然存款是在 Eth1 区块中触发的操作，然后通过「待处理」存款队列「移动」到信标层，但取款则遵循了不同的方案。它们在信标层（通过 CLI）上触发，然后「移动」到 Eth1 区块。现在，两种方案将通过相同的通用框架（如下所述）进行操作：在 Eth1 层创建请求，处理「待处理」存款 / 取款 / 合并队列，并在信标层处理。对于像取款这样的「输出」操作，输出队列也会被处理，结果将在 Eth1 区块中「结算」。
通过此 EIP，质押者可以使用常规 ETH 交易提取并退出他们的验证者，而无需直接与验证者 CLI 交互或访问验证者的基础设施。这大大简化了质押操作，特别是对于大型质押提供者。验证者的基础设施现在几乎可以完全隔离，因为只需维护活跃验证者的密钥，而所有质押操作可以在其他地方处理。它消除了独立质押者等待活跃验证者动作的需求，并显著简化了像 Community Staking Module 这样的 Lido 服务的链外部分。
因此，此 EIP 「完成」了质押操作，完全将其迁移到 Eth1 层，显著降低了基础设施安全风险，并增强了独立质押倡议的去中心化。
EIP-6110：在链上供应验证者存款
参考：EIP-6110
目前，存款是通过系统「存款」合约中的事件实现的（如在之前的文章中详细讨论）。合约接受 ETH 和验证者凭证，发出「Deposit()」事件，这些事件随后被解析并转换为信标层上的存款请求。该系统有许多缺点：它要求对信标链层的 eth1data 进行投票，这增加了显著的延迟。此外，信标层需要查询执行层，进一步增加了复杂性。这些问题在 EIP 中进行了详细讨论。一种更简单的方法，无需处理许多这些问题，是直接在指定位置将存款请求包括在 Eth1 区块中。该机制类似于在之前 EIP 中描述的取款处理流程。
此 EIP 中提出的变化很有前景。eth1data 处理现在可以完全移除，不再需要在 Eth1 侧的事件与信标层上存款包含之间进行投票或长时间延迟（当前大约为 12 小时）。它还移除了存款合约快照的逻辑。此 EIP 简化了存款处理，并使其与上述取款处理方案对齐。
对于质押者和验证者来说，这些变化显著减少了存款与验证者激活之间的延迟。当验证者被削减时，必要的补充也会更快。
关于此 EIP 没有什么更多要说的，除了它移除了过时的逻辑，简化了流程并为所有相关人员创造了更好的结果。
EIP-7685：通用执行层请求
参考：EIP-7685
这个 EIP 本应在前三个与存款 / 取款 / 合并相关的 EIP 之前提出，因为它为这些 EIP 打下了基础。然而，在此处介绍是为了强调在 Eth1（执行）和信标（共识）链块（层）之间一致性移动专用数据的日益增长的需求。此 EIP 影响两个层，使通过常规 ETH 交易触发的请求处理更高效。目前，我们观察到：
Eth1 区块中的存款事件被「移动」到信标块进行处理。
信标块中的取款请求（使用 CLI）被「移动」到 Eth1 块进行处理。
需要处理验证者合并，这也是 Eth1->信标请求。
这三项操作表明了在执行层与信标层之间转换时，各种类型请求的一致处理的必要性。此外，我们需要仅使用 Eth1 层触发这些操作的能力，因为这将使我们能够将验证者的基础设施与质押管理基础设施隔离，从而提高安全性。因此，管理此类请求的通用解决方案既是实际的也是必要的。
此 EIP 为至少三种主要情况建立了框架：存款、取款和合并。这就是为什么早期 EIP 引入了像 WITHDRAWAL_REQUEST_TYPE 和 DEPOSIT_REQUEST_TYPE 这样的字段，现在合并将添加另一个字段，CONSOLIDATION_REQUEST_TYPE。此外，此 EIP 还可能包括处理此类请求的限制的通用机制（参考常量：PENDING_DEPOSITS_LIMIT，PENDING_PARTIAL_WITHDRAWALS_LIMIT，PENDING_CONSOLIDATIONS_LIMIT）。
虽然此框架的详细实施细节仍不可用，但它肯定将包括关键请求类型、完整性机制（例如，哈希和默克尔化请求）以及待处理队列处理和速率限制。
此 EIP 具有架构意义，使 Eth1 能够通过统一框架触发信标层中的关键操作。对于最终用户和项目来说，这意味着在 Eth1 层触发的所有请求将在信标层上更高效地传递和处理。
EIP-2537：BLS12-381 曲线操作的预编译
参考：EIP-2537
如果你不想深入了解，可以将 BLS12-381 的预编译视为一种复杂的加密「哈希」操作，现在可以在智能合约中使用。对于那些感兴趣的人，让我们进一步探讨。
对椭圆曲线如 BLS12-381（及其对应的 BN-254）进行的数学运算目前主要用于两个目的：
BLS 签名，其中使用一种特殊操作称为「配对」来验证这些签名。BLS 签名被验证者广泛使用，因为它们使多个签名聚合为一个。验证者依赖基于 BLS12-381 曲线的 BLS 签名（尽管它们也可以使用任何支持配对的曲线实现，如 BN254）。
zkSNARK 证明的验证，其中配对用于验证证明。此外，由 Dencun 硬分叉引入的对大块的 KZG 承诺也使用配对来验证块承诺。
如果你想在智能合约中验证 BLS 签名或 zkSNARK 证明，你必须计算这些「配对」，这在计算上是非常昂贵的。以太坊已经有一个用于 BN254 曲线操作的预编译合约（EIP-196 和 EIP-197）。然而，BLS12-381 曲线（现在被认为更安全且在今天更广泛使用）尚未实现为预编译。在没有这样的预编译的情况下，在智能合约中实现配对和其他曲线操作需要大量计算，如 这里 所示，并消耗巨大的 gas（约 ~10^5 到 10^6 gas）。
这个 EIP 为许多潜在应用打开了大门，特别是在基于 BLS12-381 曲线的便宜的 BLS 签名验证中。这使得实现各种目的的门限方案成为可能。如前所述，以太坊验证者已经使用基于 BLS12-381 的签名。通过这个 EIP，标准智能合约现在可以高效地验证聚合的验证者签名。这可以简化共识证明和跨网络资产的桥接，因为 BLS 签名在区块链中被广泛使用。门限 BLS 签名本身允许构建许多高效的门限方案，用于投票、去中心化随机数生成、多签等。
更便宜的 zkSNARK 证明验证反过来将解锁大量应用。许多基于 zkSNARK 的解决方案目前受到高证明验证成本的阻碍，这使得某些项目几乎变得不切实际。这个 EIP 有潜力改变这一点。
EIP-2935：在状态中保存历史区块哈希
参考：EIP-2935
这个 EIP 提议在区块链状态中存储 8192 个（约 27.3 小时）历史区块哈希，为无状态客户端（如 rollup）和智能合约提供扩展历史。它建议保留 BLOCKHASH 操作码的当前行为，维持对 256 个区块的限制，同时引入一个专门设计用于存储和检索历史哈希的新系统合约。这个合约在执行层处理区块时执行 set() 操作。其 get() 方法可供任何人访问，从环形缓冲区中检索所需的区块哈希。
目前，在 EVM 中引用历史区块哈希是可能的，但访问限制在最近的 256 个区块（约 50 分钟）。然而，有些情况下访问较旧的区块数据是至关重要的，特别是对于跨链应用（需要证明先前区块的数据）和无状态客户端，它们定期需要访问早期区块哈希。
这个 EIP 扩展了 rollup 和跨链应用可用的时间范围，允许它们在 EVM 中直接访问历史数据，而无需在外部收集。因此，这些解决方案变得更加稳健和可持续。
EIP-7623：增加 calldata 成本
参考：EIP-7623
calldata 成本调节了交易有效负载的可用大小，在某些情况下可能很大（例如，当作为参数传递大型数组或二进制缓冲区时）。显著的 calldata 使用主要归因于 rollup，它们通过包含当前 rollup 状态的 calldata 发送有效负载。
将大型、可证明的二进制数据引入区块链对 rollup 至关重要。Dencun（Deneb-Cancun）升级为此类用例引入了一项重要创新——blob 交易（EIP-4844）。blob 交易有自己专门的「blob」gas 费用，虽然其主体是暂时存储的，但其加密证明（KZG 承诺）连同其哈希被整合到共识层中。因此，与使用 calldata 存储数据相比，blob 为 rollup 提供了更好的解决方案。
鼓励 rollup 将其数据转移到 blob 可以通过「胡萝卜加大棒」的方式实现。降低的 blob gas 费用作为「胡萝卜」，而这个 EIP 通过增加 calldata 成本作为「杠杆」，从而抑制交易中过度的数据存储。这个 EIP 补充了下一个 EIP-7691（Blob 吞吐量增加），后者提高了每个区块允许的 blob 最大数量。
EIP-7691：blob 吞吐量增加
参考：EIP-7691
在之前的 Dencun 硬分叉中引入了 blob，且「每区块」blob 的最大和目标数量的初始值是保守的估计。这是由于预测 p2p 网络将如何处理大型二进制对象在验证者节点之间传播的复杂性。先前的配置已证明良好，这使得这是测试新值的合适时机。之前，每个区块的目标 / 最大 blob 数量设置为 3/6。这些限制现在分别提高到 6/9。
结合之前的 EIP-7623（增加 calldata 成本），这一调整进一步激励了 rollup 将其数据从 calldata 转移到 blobs。寻找最佳 blob 参数的工作仍在继续。
EIP-7840：将 blob 调度添加到 EL 配置文件
参考：EIP-7840
这个 EIP 提议将目标和最大「每区块」blob 数量（前面讨论过）以及 baseFeeUpdateFraction 值添加到以太坊执行层（EL）配置文件中。它还使客户端能够通过节点 API 检索这些值。此功能对于估算 blob gas 费用等任务特别有用。
EIP-7702：设置 EOA 账户代码
参考：EIP-7702
这是一个非常重要的 EIP，将为以太坊用户带来重大变化。如我们所知，EOA（外部拥有账户）不能有任何代码，但可以提供交易签名（tx.origin）。相比之下，智能合约有字节码，但不能主动提出「它」的直接签名。任何需要额外、自动和可验证逻辑的用户交互目前只能通过调用外部合约来执行所需的操作。然而，在这种情况下，外部合约成为后续合约的 msg.sender，使得调用「来自合约的调用，而不是用户」。
这个 EIP 引入了一种新的 SET_CODE_TX_TYPE=0x04 交易类型（我们之前有旧的 0x1 交易、来自柏林和 EIP-1559 升级的新 0x02 交易，以及在 Dencun 中引入的 0x03 blob 交易）。这种新交易类型允许为 EOA 账户设置代码。实际上，它允许 EOA 「在其自己 EOA 账户的上下文中」执行外部代码。从外部视角看，在交易过程中，EOA 好像「借用」来自外部合约的代码并执行它。技术上，这通过将特殊授权数据元组添加到 EOA 地址的「代码」存储中实现（在这个 EIP 之前，这个「代码」存储对 EOA 始终是空的）。
目前，这个 EIP 提议的新 0x04 交易类型包含一个数组：
authorization_list=[[chain_id,address,nonce,y_parity,r,s],...]
每个元素允许账户使用来自指定地址的代码（来自最后一个有效授权项）。处理此类交易时，将给定的 EOA 的代码设置为特殊的 0xef0100 || 地址值（23 字节），其中地址指向具有所需代码的合约，|| 表示连接，0xef0100 表示常规智能合约无法包含的特殊魔法值（根据 EIP-3541）。这个魔法值确保这个 EOA 不能被视为常规合约，也不能像常规合约一样进行调用。
当这个 EOA 发起交易时，指定的地址将被用于在该 EOA 的上下文中调用相应的代码。虽然这个 EIP 的完整实现细节尚不清楚，但可以确定它将带来重大变化。
一个主要影响是能够直接从 EOA 进行多重调用（multicall）。多重调用是 DeFi 中的一种持续趋势，许多协议提供了这一特性作为强大的工具（例如 Uniswap V4、Balancer V3 或 Euler V2）。有了这个 EIP，现在可以直接从 EOA 发起多重调用。
例如，这一新特性解决了 DeFi 中一个常见问题：approve() + anything() 需要两笔独立交易的低效率。这个 EIP 允许通用的「预授权」逻辑，使得像 approve(X) + deposit(X) 可以在单笔交易中完成。
能够「代表」 EOA 委托交易执行的另一个优势是赞助的概念。赞助是经常讨论和高度渴望的特性，以帮助新用户进入以太坊。
与 EOA 关联的可编程逻辑解锁了许多可能性，例如实施安全限制、设置支出上限、强制 KYC 要求等。
当然，这一转变也提出了许多设计问题。一个问题是 chain_id 的使用，它决定了同一签名是否可以在多个网络之间有效，具体取决于其包含或不包含在签名中。另一个复杂的问题是使用目标代码的地址与嵌入实际字节码之间的选择。这两种方法各有独特的特点和局限性。此外，nonce 的使用在定义权限是「多用途」还是「单一用途」方面发挥了关键作用。这些元素影响功能和安全问题，包括批量失效签名和易用性等方面。Vitalik 在一个讨论中提出了这些问题（ 这里 ），值得进一步探索。
值得注意的是，这一变化将影响以太坊的一个安全机制，tx.origin。关于此 EIP 实施的更多细节是必要的，但看起来 require(tx.origin == msg.sender) 的行为将会改变。这个检查一直是确保 msg.sender 是 EOA，而不是合约的最可靠方法。其他方法，例如检查 EXTCODESIZE（以检查它是否是一个合约），通常会失败并且可以被规避（例如，通过调用构造函数或在交易后在预定义地址部署代码）。这些检查用于防止重入和闪电贷攻击，但远非理想，因为它们还妨碍与外部协议的集成。在这个 EIP 之后，即使是可靠的 require(tx.origin == msg.sender) 检查似乎也变得过时。协议必须通过移除这些检查来适应，因为「EOA」和「合约」之间的区别将不再适用——现在每个地址都可能有相关代码。
传统的 EOA 和智能合约的分离继续模糊。这一 EIP 使以太坊更接近于像 TON 这样的设计，在那里每个账户本质上都是可执行代码。随着与协议的交互变得越来越复杂，使用可编程逻辑来改善最终用户体验是这一演进的自然过程。
以上就是解读以太坊即将到来的硬分叉 Pectra 升级的详细内容，更多请关注天气宝其它相关文章！
