EOS区块链技术代码分析——独股一箭独家分析

本文由独股一箭V微信公众号独家分析：

EOS 用了 Graphene 引擎，看过代码后发现，实际上 Steem 基本是复制了 Graphene 然后在上面修改，而 EOS 复制了 Steem ，然后在上面修改，几者是演进关系。

所以整体架构上 EOS 和 Steem 很像，插件体系也类似，最关键的区别看起来就是支持了 WASM 智能合约以及性能上的优化。

另外就是 Steem 的业务逻辑都是写在链代码上的，比如创建账号，发表文章，评论等。EOS 想做成通用的 DApp 链，所以把数据模型抽象了一下。

智能合约 ABI 描述文件，里面定义了数据类型，类型的字段，表结构以及索引（EOS 支持主索引和二级索引）。EOS 相当于接管了数据的存储和查询，DApp 在智能合约中对定义的数据类型进行处理就行。

所以它的 Block 账本上记录的并不只是交易，而是 Message。Block，Transaction，Message 之间的关系。

Message 记录的就是智能合约 ABI 文件中描述的 action 以及数据对象（data 字段）。

举例来说，如果要用 EOS 来实现 Steem，保存用户发布的文章。那就先创建一个 Article 数据结构，把字段属性，表结构索引，以及支持的 action（比如 create） 在 ABI 文件中描述清楚。然后写智能合约，实现它的 apply 方法，apply 方法的参数会有 action，根据不同的 action 实现不同的校验以及业务逻辑校验。然后客户端只需要构造 Article 数据结构，然后通过 EOS 接口发送 Message 即可。

EOS 的智能合约在 DApp 上的支持上确实比以太坊要强一些，只是 WASM 当前支持的语言还有限，当前只支持 c/c++ ，其他的语言还在开发中。

EOS 的 Block 上只存了 Merkle root，并没有存整个 tree。这个问题 Vitalik Buterin 和 Dan 辩论过一次，V 认为 EOS 这是投机取巧，Dan 认为 Merkle tree 的存在是为了校验状态（交易是否存在），而状态应该是区块链上的记录回放的结果，不应该属于共识的一部分，也不用记录在区块上，并且 EOS 也是支持利用 Merkle 做轻客户端证明的。但具体 EOS 怎么存这个，我自己还没看太明白。

另外 EOS 和 Steem 都依赖一个 chainbase 的数据库实现，EOS 中的数据库索引就是依赖 chainbase 实现的，这个数据库的实现比较简单，主要是用内存映射文件（memory mapped

file)。它认为 LevelDB 这种数据库，性能不行，也不方便做多级索引，对区块链来说，状态数据库只是账本日志的快照，对持久化要求没那么高，所以可以更激进的利用内存。

所以整体看来，EOS 通过 DPoS 超级节点方式，可以将性能提高到一个量级，然后运行一些轻量的 DApp 应用是没问题的，至少不会像 Ethereum 那样，跑个猫就给弄堵了。但我对当前公链上支撑众多上规模的 DApp 还是不太乐观。