Github

本文档列出了对开发计划的一个高度概括的大纲,软件完成1.0版本的进度后,该文档会更新. 需要注意,这份路线图只适用于区块链软件,对于其他的工具和应用,如钱包软件,和区块链浏览器,并不适用. 在阶段一完成之后,其他这些软件和工具会有其各自具体的路线图文档.

本文档中,所有内容均为草案形式,且随时可能变更,仅供参考. block.one不保证本路线图文件中信息的准确性,所有的信息"按照原样"提供,不存在任何声明或保证,明示或暗示.

阶段一 - 最小可行的测试环境 - 2017 夏季

本阶段目标是创建API, 满足开发人员在EOS.IO上开始构建和测试应用的需要. 为了让开发人员可以着手测试他们所开发的软件,需要完成如下的部分:

独立节点 (Dan & Nathan)

在一个独立节点上,运行一个测试区块链,提供了API, 产生区块. 这一节点没有与P2P网络相关的代码.

本地合约 (Nathan)

EOS.IO软件有若干本地合约.这些合约用于管理区块链的核心操作,存在于Web Assembly接口之外.这些合约包括:

  1. @eos - 管理EOS token的转移
  2. @stake - 管理锁定的EOS,投票,和生产者选举
  3. @system - 管理权限,信息,和合约代码更新

虚拟机 API (Dan)

合约会被编译为WebAssembly(WASM), WASM必须通过定义好的API才能与区块链交互. 开发人员开发应用需要依赖虚拟机 API, 所以在开发人员真正着手在EOS上构建程序前,该API需要达到相对稳定的状态.

RPC 接口 (Arhag, Nathan)

我们会提供一个简单的 JSON RPC HTTP接口,以便开发人员能够广播交易信息,查询应用的状态. 对广播信息和与测试程序交互而言,该接口都很关键.

命令行工具 (Arhag)

我们提供命令行工具,方便开发人员将RPC接口集成到应用的构建环境之中.

基础开发文档 (Josh)

指导开发人员开始在EOS.IO区块链上构建程序的文档.包含了WASM API, RPC接口以及命令行工具的文档.

阶段二 - 最小可行的测试网络 - 2017年秋季

在阶段一中, 所有的工作都假设了一个可靠的环境, 在这个环境之中,开发人员只运行自己的代码.部署一个可行的测试网络之前,有一些额外的特性需要完成开发和测试

P2P 网络代码 (Phil)

这是一个插件,用于在两个独立的节点之间同步区块链的状态.

WASM 清理 & CPU 沙盒化 (Brian)

WASM代码需要进行清洁处理, 以便检查异常行为,如浮点数运算异常,和无限循环等.

资源使用情况跟踪 & 限速 (Arhag)

为了防止滥用,根据已有EOS,资源监控和使用情况追踪,对用户进行限制.

Genesis 导入测试 (DappHub)

需要开发工具,用于从EOS Token发布状态导入数据,并创建一个创世设置文件 (genesis configuration file). 这可以让参与Token众筹发布的人们获得一些初始的测试EOS (TEOS).

区块链内通讯 (Nathan)

这一特性包括,验证交易的Merkl哈希值是否有效.

阶段三 - 测试 & 安全审计 - 2017年冬季,2018年春季

在这一阶段, 会对平台进行大量测试,找出安全问题和程序bug. 在第三阶段结束时,会对软件打上版本 1.0 的标签.

开发示例应用

为了验证平台是否提供了真实开发者所需要的功能,示例程序的开发非常关键.

对成功的网络攻击给予奖励

使用垃圾信息,虚拟机滥用, 错误崩溃,非正常的操作来实施网络攻击,是一个很复杂的过程,但是,为了确保软件 1.0 可以稳定使用,又是很必要的.

编程语言支持

增加对其他可以编译为WASM的编程语言的支持:C++, Rust等等.

文档 & 教程

阶段四 - 并行优化 2018 年夏季/秋季

在 1.0 的稳定版发布后,我们会继续优化代码,提升并行执行性能.

阶段五 - 实现集群 未来

 

 

原文链接