ECIP蓝图将把ETC引向何处?

  众所周知以太坊经典（ETC）生态系统没有指定的领导者，并且秉承着无需许可的精神进行运作，因此有时我们值得从核心发展的角度收集和总结网络中进行的活动。该生态系统至少有四个开发团队，他们积极致力于构建协议层。

  这些团队分别维护着四个客户端：

  ECIP即Ethereum Classic Improvement Proposal，代表“以太坊经典改进提案”，我们可以在来自以上团队的Github存储库中找到针对ETC协议的改进建议。一般而言，共识更改不会发生在未经过ECIP流程的情况下，这就是为什么开放的ECIP可以成为ETC的“隐含路线图”。

  需要注意的是这不是“官方”路线图，不是每个团队的计划路线图（例如ETC Labs Core的项目计划），也不是由EthereumClassic.org网站上发布的由ETCC汇总的大致路线图。这只是表示实时提案目前正处于分析讨论阶段，并且可能有助于更具象地了解ETC网络未来所踏出的每一步。

  另外，还要注意活跃的ECIP会经历从“草案”到“启用”这几个阶段 。过程中它们可能被拒绝、被撤回、被推迟或者被替换。这意味着我们将要提到的活跃ECIPs和隐含路线图只是一种迹象，依然可能会有所变化。以下是ECIP流程图：

  一般而言，ETC是一个保守的生态系统，在实施协议更改时，进程缓慢但保证了其安全性。许多开发者和参与者都参与了ECIP流程，其中包含了上面提到的核心开发人员、矿工、矿池、节点、钱包运行者以及其他独立的ETC生态系统参与者。

  ETC正在努力将中心化ECIP流程变得更加去中心化，因此一些ECIP位于原始社区存储库中，其他ECIP则位于相应的团队存储库中。

  以下是可以找到ECIP的一些存储库：

  ETC社区ECIP存储库

  ETC Labs Core ECIP存储库

  That World and Ethoxy Initiative ECIP网站

  以下是ETC的活跃ECIP清单及其发起人和现状，这些ECIP或将在短中期内执行于运作的区块链上。每个ECIP标题下都包括来自原始ECIP或其他来源的摘要（若适用）。

ECIP-1043——固定DAG最大限度

  此ECIP的目的是将DAG的最大大小设置为初始状态，并且在之后的epoch中都不会增加。

  DAG的最初愿景是为了抵制ASIC挖矿，以防止挖矿中心化，从而客观公平地分配通证。然而经过发展，ASIC能够匹配现有的GPU矿工，并且更加高效节能，这宣告了DAG的失败，它现在只能作为强大分销商大规模投资专用硬件的一种威慑。

ECIP-1046——NiPoPoWs-默克尔包含证明的预编译合同

  利用EVM字节码显然可以验证默克尔包含证明(Merkle Inclusion Proofs) 。然而这种操作的gas成本非常高。我们建议将此功能添加到ETC中作为预编译合同，以抵消此成本。

  非交互式工作证明证明（NiPoPoWs）是一种简短的独立字符串，它使您能够在不联机或不需要下载所有块头的情况下使用电脑程序验证基于PoW的区块链上发生的事件。例如这些证明可以验证加密货币支付交易的发生。

ECIP-1047——将Gas上限降至100万

  所有基于以太坊的链都面临着一个主要问题，即区块链膨胀有可能大幅增加同步时间，并使用户难以完全验证其ETC区块链副本。

  为了缓解这个问题，该ECIP是一项要求矿工将Gas限制为100万，这比目前的大约795万减少了8倍，但仍然远高于ETC链上区块的平均Gas大小。

ECIP-1049——Keccask 256 (SHA 3) 算法替代工作量证明

  建议用Keccak-256算法替换当前的ETC工作量证明算法，作为最近ETC受到双重支付攻击的一种应对机制。

  由于大多数算力是租用的或来自其他链，尤其是以太坊（ETH），单独的工作证明算法将鼓励开发专门的ETC采矿社区，并削弱攻击者在开放市场上购买雇佣算力的能力。

  第二个益处就是已部署的智能合约和链上运行的DApps目前能够在其代码中使用keccak256()。该ECIP为智能合约评估链的状态提供了可能性，并简化第二层（L2）开发。

ECIP-1053——在JSON-RPC服务中添加OpenRPC

  这项提议的主要内容是通过将rpc.discover方法添加到JSON-RPC API项目中，OpenRPC将对现在和未来的JSON-RPC服务提供支持，从而实现自动化和工具化。

  所述的OpenRPC规范定义了JSON-RPC 2.0 API的标准，使用无关编程语言的接口描述，允许人类和计算机发现和理解的服务的能力，而无需访问源代码，无需附加文档或网络检查。当通过OpenRPC正确定义，用户可以用最少的执行逻辑来理解远程服务并进行交互，并在用例之间共享这些逻辑模式。与低级编程的接口描述类似，OpenRPC规范消除了调用服务时的猜测。

ECIP-1054——Atlantis (亚特兰蒂斯) EVM及协议升级

  通过虚龙(Spurious Dragon)和拜占庭(Byzantium)硬分叉，为ETH网络中因协议影响而发生的变化提供[s]支持。

  ETC亚特兰蒂斯升级的更改建议包括：

1. 虚龙状态树清除。

2. 限制虚龙合约代码大小。

3. 增加拜占庭EVM操作码，即`REVERT`，`RETURNDATASIZE`，`RETURNDATACOPY`，和`STATICCALL`。

4. Byzantium EVM预编译合约，即椭圆曲线上`alt_bn128`的加法和标量乘法，椭圆曲线上`alt_bn128`上的最佳ate配对检查，以及BIGINT模幂运算。

5. 用合同返回状态替换交易收据中的中间状态根字段。

6. 将ETC的难度调整算法修改为包括叔块的“目标平均块时间”。

ECIP-1055——使用Merkle Mountain Ranges的简洁工作量证明

  此提案建议将Merkle-Mountain-Range（MMR）根添加到块头。

  区块链可以被解释为使用哈希指针将每个区块与其前区块相连的链表。Merkle-Mountain-Range是一种树型数据结构，它使得每个块都能回指所有之前的块。在每个块中仅使用一个哈希指针就能完成这项工作，也就是现有的MMR 根。添加此项将允许在O log(n)时间内证明整条链累积的工作，而不是现有的O(n)时间。以ETC为例，需要计算超过700万个区块，再加上一些缓冲时间，使用Merkle Mountain Ranges的简洁工作量证明将为轻量级客户端和数据验证带来无数的可能性。

ECIP-1056——支持ETH君士坦丁堡EVM及协议升级的Agharta硬分叉

  使用代号为Agharta的硬分叉在ETC网络上启用出色的ETH君士坦丁堡和圣彼得堡网络协议升级，以实现网络间的最大兼容性。

  ETH网络因协议升级而发生了一系列变化，这项提议旨在通过君士坦丁堡和圣彼得堡硬分叉为其提供支持。

  ETC Agharta升级的更改建议包括：

1. 君士坦丁堡按位移位指令—Constantinople skinny。

2. `CREATE2`操作码—君士坦丁堡`EXTCODEHASH`操作码。

  在硅谷和其他商业环境中，有一句口号是“雷厉风行，推陈出新”。然而ETC旨在成为安全的区块链以能够完全适应全球去中心化计算，并且在将来能胜任跨境结算层的角色，这句口号与ETC在进行网络升级时所做的截然不同。那么ETC的口号可以说是“欲速不达，守成保业”。

  若是花费时间和心思来分析整合ETH已经实施的变化，可以观察到上述情况。例如，ETC的Atlantis硬分叉预计发生在今年9月，但它目前正在进行的升级ETH在2016年和2017年业已完成。同样，今年2月已经在ETH实施的君士坦丁堡和圣彼得堡升级预计将在12月之前部署在ETC中。

  目前最迫切的ECIP-1054，它详述了Atlantis硬分叉。幸运的是，似乎其中所提出的六个变化在生态系统中几乎没有反对意见，如上所述，它们很可能会在ETC主网的第8,750,000块上实施。

  建议降低Gas上限的ECIP-1047是有意义的，因为它要求矿工缩小区块，从而ETC区块链可以最大限度地减少膨胀，使得新节点更容易同步。

  建议在第9,200,000块上启动Agharta硬分叉的ECIP1056同样很重要，因其要为ETC添加操作码并且符合兼容性政策。但是一些核心开发人员对`CREATE2`操作码怀有顾虑，因此硬分叉仍处在技术讨论阶段。

  ECIP-1049提议改变挖矿算法，这是一个非常结构性的改变，因此它正在由发起人进行测试，他将在2020年向生态系统展示结果。

  如上所述，预计2022年9月实施的ECIP-1049和ECIP-1055如果没有反对意见可以提前实施，但在社区中已经讨论到要尽可能将硬分叉频率降低到每年一次，因此它们暂时标记为该日期。

  上述活跃的ECIP所暗含的路线图可能会成为有助于整个区块链行业，尤其是ETC生态系统，去理解并追踪网络在短中期将要采取的具体策略。也许它能呈现ETC变革和创新的可见性，但ETC采取的是“欲速不达，守成保业”的保守策略。这保证了进行网络升级时的最佳安全实践，也符合ETC对安全性、不可篡改性和向后兼容的理念。