ECIP蓝图将把ETC引向何处?

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

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

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

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

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

图源：Github

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

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

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

ETC社区ECIP存储库：

https：//github.com/ethereumclassic/ECIPs/tree/master/ECIPs

ETC Labs Core ECIP存储库：

https：//github.com/etclabscore/ECIPs/tree/master/ECIPs

That World and Ethoxy Initiative ECIP网站：

https：//ecips.that.world/

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

固定DAG最大限度

发起人: Cody Burns

现状: 草案

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

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

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

发起人: Kostis Karantias and Dionysis Zindros
现状: 草案

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

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

将Gas上限降至100万

发起人: Anthony Lusardi
现状: 草案

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

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

Keccask 256 (SHA 3) 算法替代工作量证明
发起人: Alexander Tsankov
现状: 草案

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

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

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

在JSON-RPC服务中添加OpenRPC
发起人: Shane Jonas and Zachary Belford
现状: 草案

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

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

Atlantis (亚特兰蒂斯) EVM及协议升级
发起人: Isaac Ardis
现状: 草案

通过虚龙(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的难度调整算法修改为包括叔块的“目标平均块时间”。

使用Merkle Mountain Ranges的简洁工作量证明
发起人: Zac Mitton
现状: 草案

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

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

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

发起人: Isaac Ardis
现状: 草案

使用代号为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中。