Conflux网络升级内容细则

Conflux 计划在下一次系统升级中激活并实施包括 CIP-43、CIP-64、CIP-71、CIP-72、CIP-76、CIP-78 等 6 个不同的 CIP（改进提案）的更改。本文是整理的一份升级清单的摘要，供大家交流讨论。

以下是上述 6 个 CIP 的详细介绍：

CIP-43

详情链接：https://github.com/Conflux-Chain/CIPs/blob/master/CIPs/cip-43.md

简介

CIP-43 提议将交易最终性 (finality) 引入 Conflux 网络。最终性由 CFX 持有人通过质押投票产生。这一 CIP 将避免 PoW 潜在的 51% 算力攻击，并提高 Conflux 网络上的高价值交易确认安全性。

摘要

CIP-43 提议引入一条独立的 PoS 链，用于监控 PoW 链(树图结构)的过程，对根据 PoW 确认规则已确认的主链区块达成共识。一旦 PoS 链认为一个主链区块已被确认，所有 PoW 链的矿工应该跟随其后产生新的区块。此举将有效保护 Conflux 链免受来自 PoW 机制的51%远程攻击。

CFX 持有人可以将持有的 CFX 存入特定的合约，以此来成为一个 PoS 节点。PoS 节点通过一个可验证随机函数(VRF)来产生参与 PoS 链共识的委员会。委员身份是临时的，将以六小时为周期进行轮转。委员会的选举类似美国参议院，其成员的任期是交错的，每小时将选举大约六分之一的委员会席位（此项 CIP 的设计比较复杂，后续可能会有参数的调整）。

只有对 PoS 链的抵押才能产生利息，更多关于经济模型的细节仍在讨论中。

动机

在一条公链生态发展早期，算力总量相对不足。这导致可以低成本发起 51% 攻击并通过双花(double-spending)来窃取链上资产。以太经典，grin 和 verge 在去年相继遭到51%攻击。为了减轻来自攻击者的威胁，Conflux 引入 PoS finality，通过质押 CFX 产生一个委员会来推荐已确认的主链区块，所有 PoW 链节点应跟随此区块来打包产生新的区块。

注意事项

众所周知，在攻击者控制的算力小于50%的时候，采用PoW共识协议的链是安全的。对于激活CIP-43之后可能发生的情况，我们考虑了如下场景。

51%攻击：在攻击者拥有超过51%算力的情况下，只要PoS链运行良好，那么在攻击发生前已经由PoS决定的主链区块就依然是安全的(由攻击者分叉产生的链将不被承认)。然而，由于PoS节点无法再确认新的PoW区块，PoW可能因此失去活性。如果攻击者消失了，共识协议将恢复正常运行。

17%质押攻击：若攻击者控制了超过17%的委员会成员，PoS将失去活性，但PoW链将继续运行，就像没有CIP-43一样。如果攻击者消失了，共识协议将恢复正常运行。

84%质押攻击：若攻击者控制了超过84%的委员会成员，则可以产生冲突的PoS区块。PoW链将从此离散，即使攻击者停止作恶也无法恢复。

远程攻击(long-range attack)：与84%质押攻击不同，在远程攻击中，造成一个PoS节点变得恶意的原因并非是其有意破坏共识，而是因为丢失了私钥。所以我们假设攻击者只能在非常早期的阶段控制委员会的大多数席位，若此时攻击者控制了超过51%的算力，就能够回滚PoW链并造成双花攻击。除此以外的情况下共识协议都将照常运行。

CIP-64

详情链接：https://github.com/Conflux-Chain/CIPs/blob/master/CIPs/cip-64.md

简介

目前，Conflux 网络上部署的智能合约无法在执行时获得即时 epoch 信息。

为了维护 EVM 的兼容性，CIP-64 引入了新的内部合约，使 epoch 信息能被 Conflux 网络上的智能合约即时访问。

摘要

在 DApp 开发中，一个常用的技术是将事件所对应的区块数存储在合约中，然后使用此区块数信息来查询合约。举例而言，某人也许希望从合约的创建开始来查询日志。然而 Conflux 的查询 APIs 只支持查询 epoch 数，不支持查询区块数，这使上述通过区块数查询的技术无法被应用在 Conflux 上。此次 CIP 引入了一个新的内部合约，使其他合约可以访问执行(指定交易的) epoch 数。

动机

在智能合约中，有两种使用区块数 (block.number) 的常见用例。

第一种用例是计时。因为区块数的增长速率相对稳定且很难被影响，所以适合时间锁等应用。

第二种用例是查询。例如，一个合约可以保存其自身被创建时的区块数，用户可以通过读取此信息来确认需要从哪个区块开始查询合约事件。

第二种用例在 Conflux 不可用，因为我们的查询 APIs(RPC) 仅支持通过  epoch 数来查询，而不支持通过区块数查询。

规格参数

从 epoch XXX 开始，一个新的内部合约将被部署在地址0x0888000000000000000000000000000000000003(cfx:type.builtin:aaejuaaaaaaaaaaaaaaaaaaaaaaaaaaaapx8thaezf)。此合约具有如下接口。

pragma solidity >=0.4.15;




contract Context {
    /*** Query Functions ***/
    /**
     * @dev get the current epoch number
     */
    function epochNumber() public view returns (uint64) {}
}

当交易执行触发对 epochNumber() 的调用时，内部合约对于此函数的实现，必须根据交易执行的上下文，返回其当前所处的 epoch 数。

与 NUMBER 操作码类似，调用此内部合约的gas成本应为 2。

安全方面的考虑因素

此提议是功能补充，不涉及安全问题。

CIP-71

详情链接：https://github.com/Conflux-Chain/CIPs/blob/master/CIPs/cip-71.md

简介

CIP-71 允许合约开发人员关闭合约的抗重入(anti-reentrancy)机制。

摘要

当前，Conflux 智能合约虚拟机拥有抗重入机制。当单个合约在调用栈内出现两次时，Conflux 将禁止在后续执行诸如 SSTORE 、LOG0 至 LOG4 以及余额非零的 CALL 等写入操作。此 CIP 旨在令此功能可配置。我们将引入一个新的内部合约，此合约将允许合约自身或其管理者开启或关闭抗重入功能。

动机

Conflux 引入抗重入机制来避免某些来自 DEFI 应用的攻击。然而此机制也会禁用一些合法操作。举例来说，如果某借方合约调用了一个闪电贷合约，然后此闪电贷合约又调用了借方合约的“callback”函数，那么借方合约就会在调用栈内出现两次，接下来的所有写入操作都将被禁止。尽管开发人员可以通过改变合约间的交互逻辑来避免出现这类问题，但是这会给合约迁移带来额外的任务量。

规格参数

Internal contract

Conflux将引入一个新的内部合约。

pragma solidity >=0.4.15;




contract AntiReentrancy {
    /**
     * @dev the contract turns on/off the anti-reentrancy. 
     * @param allow A boolean variable to indicate if the reentrancy is allowed in this contract.
     */
    function allowReentrancy(bool allow) external {}




    /**
     * @dev a contract admin turns on/off the anti-reentrancy for the contract. 
     * @param contractAddr The address of the contract. 
     * @param allow A boolean variable to indicate if the reentrancy is allowed in this contract.
     */
    function allowReentrancyByAdmin(address contractAddr, bool allow) external {}








    /**
     * @dev get whether the reentrancy is allowed for a contract. vote power staking balance at given blockNumber
     * @param contractAddr The address of the contract. 
     */
    function isReentrancyAllowed(address contractAddr) external returns (bool) {

Change for the anti-reentrancy mechanism

只有在一个不允许重入(抗重入功能开启)的合约地址在调用栈内出现两次时，Conflux才会禁止写入操作(触发抗重入机制)。

Activation plan

参数: BLOCK_NUMBER_CIP71A，BLOCK_NUMBER_CIP71B。

a. 启用新的内部合约，对于Conflux上允许重入的合约，关闭其抗重入功能。此内部合约将从 block_numer >= BLOCK_NUMBER_CIP71A 开始激活。

b. 对于当前抗重入机制的实现，将从 block_number >= BLOCK_NUMBER_CIP71B 开始修复其错误行为。

安全方面的考虑因素

目前，一些经过充分审计的合约模版允许开发人员在 Solidity 代码中检测合约是否发生重入，并禁止恶意利用重入的操作，所以没有必要在虚拟机层面保留抗重入机制。然而，已经部署在 Conflux 的合约可能将继续依赖此机制，所以我们将抗重入机制改为可配置的，而非将其删除。

CIP-72

详情链接：https://github.com/Conflux-Chain/CIPs/blob/master/CIPs/cip-72.md

简介

CIP-72 可使 Conflux 网络接受来自以太坊钱包 (如 Metamask) 签名产生的交易。

摘要

Conflux 的交易格式与以太坊不同，所以无法接受由 Metamask 钱包产生的交易签名。此 CIP 计划让 Conflux 将目标 epoch (target epoch) 为 u64::MAX 的交易视同以太坊类型的交易，并根据以太坊的规则验证交易签名。

动机

此 CIP 将允许用户使用诸如 Metamask 的以太坊钱包与 Conflux 链上的智能合约交互。我们相信此举能吸引更多用户来体验 Conflux。

规格参数

若交易的目标 epoch 为 u64::MAX，Conflux将视其为以太坊类型的交易。应遵循以下步骤来验证以太坊类型交易。

    ·交易的存储限制为 u64::MAX

    ·交易签名是为rlp(nonce, price, gas_limit, recipient, value, data, chain_id, ε, ε 的哈希值而产生的。此处 ε 表示 Conflux 规范中定义的 "empty string"。

对于以太坊类型的交易，Conflux 不要求发送者有足够余额来支付存储抵押。

RPC 在收到一个以太坊类型的交易时，如果发送者的地址不是以 0x1 开头，则拒绝此类交易。

安全方面的考虑因素

如果一个恶意中继器尝试篡改以太坊类型交易，它无法在将此交易修改为其他类型后，还能使其通过签名验证。

CIP-76

详情链接：https://github.com/Conflux-Chain/CIPs/blob/master/CIPs/cip-76.md

简介

CIP-76 激活后，将删除同步区块时与虚拟机相关的检查规则，如要求给交易设置足够的 gas limit。这样可确保共识协议不受后续虚拟机相关升级的影响。

摘要

当前，当收到一个邻居节点发来新区块时，我们要检查这个区块是否满足一些约束条件。其中一条约束要求交易的 gas limit 超过一个最低阈值。然而，这个阈值的大小依赖于虚拟机的 gas 收费方案。这个方案可能会在未来的升级中被改变。此 CIP 提议删除同步块时与虚拟机相关的约束条件检查，并避免在将来引入类似检查规则。

动机

将共识组件与执行组件解耦对于后续的升级计划至关重要。共识协议应对执行组件保持透明。

然而，如果在同步和检查新接收区块的合法性时，需要读取虚拟机相关参数，那么任何虚拟机层面的改变都有可能导致共识协议意料之外的硬分叉。

另一方面，当前对于交易 gas limit 的约束检查并不能阻止恶意矿工使用无意义的交易来填满一个区块，因为我们不检查交易发送者是否有足够余额来支付 gas fee。恶意的矿工可以将大量发送者余额为0的交易打包进区块。所以将这一检查去掉不会引入更多的安全问题。

参数规格

经过一个指定的 epoch 高度之后，共识协议将不再检查交易的 gas limit。

安全方面的考虑因素

如动机部分所述，关于 gas limit 的检查无法阻止恶意矿工用无意义交易来填充区块，所以删除此项检查不会造成安全问题。

但是更多有关此次变动的安全性讨论是必要的。

CIP-78

详情链接：https://github.com/Conflux-Chain/CIPs/blob/master/CIPs/cip-76.md

简介

CIP-78 可修复交易收据中的错误字段。

摘要

目前，当交易执行失败的时候，交易收据将显示此次交易未被赞助，即使赞助商实际上已经代付了gas fee。此外，若赞助商没有足够的余额来支付存储抵押时，将由交易发送者来承担该笔交易的存储抵押。然而，交易收据上的记录将显示此次交易是被赞助的。这个 CIP 将修复这些错误。

动机

在任何情况下，交易收据中的"is_sponsed"相关的字段都应始终与赞助商是否代付的实际情况保持一致。

无论发生什么，交易收据中的"is_sponsed"字段都应始终与赞助商是否付款保持一致。

参数规格

此次 CIP 之前。

此次 CIP 之后。

安全方面的考虑因素

这一 CIP 修正了交易的执行结果，不引入新的安全性问题。

END

了解最新动态