与 RLP 具有相同功能的方案是 protobuf 或 BSON，它们是一直被使用的算法。然而，以太坊中，我们更偏向于使用 RLP，因为：（1）它易于实现；（2）绝对保证字节的一致性。

　　许多语言的键值对集合没有明确的排序，并且浮点格式有很多特殊情况，这可能造成相同数据却产生不同编码和不同哈希值。通过内部开发协议，我们能确保它是带着这些目标设计的（这是一般原则，也适用于代码的其他部分，如虚拟机）。BitTorrent 使用的编码方式 bencode 也许可以替代 RLP。不过它采用的是十进制的编码方式，与采用二进制的 RLP 相比，稍微逊色了点。

　　压缩算法

　　网络协议和数据库都采用了一个自定义的压缩算法来存储数据。该算法可描述为：对 0 使用行程编码 4 并同时保留其他值（除了一些特殊情况如 sha3(' ') ），举例如下：

　　压缩算法存在之前，以太坊协议的许多地方都有一些特殊情况，例如，sha3 经常被重定义使得 sha3(' ')=' '，这样不需要在账户中存储代码，可以节省 64 字节。然而，最近所有这些使得以太坊数据结构变得臃肿的特殊情况都被删除了，取而代之的是将数据保存函数添加到区块链协议之外的层，也就是将其放入网络协议以及将其插入用户数据库实现。这样增加了模块化能力，简化了共识层，使得对压缩算法的持续更新部署起来相对简单（例如：可通过网络协议的版本号来区别、部署）。

　　树（trie）的使用

　　提醒：理解这部分的知识需要读者了解布隆过滤器 5 的原理。简介可见：https://en.wikipedia.org/wiki/Bloom_filter

　　以太坊区块链中每个区块头都包含指向三个树的指针：状态树、交易树、收据树。

• 　　状态树代表处理完该区块后的整个状态；

• 　　交易树代表区块中所有交易，这些交易由 index 索引作为key；（例如，k0：第一个执行的交易，k1：第二个执行的交易）

• 　　收据树代表每笔交易相应的收据。

　　交易的收据是一个 RLP 编码的数据结构：

• 　　其中：

• 　　medstate：交易处理后，状态树的根；

• 　　gas_used：交易处理后，gas 的使用量；

• 　　logs：是许多 [address, [topic1, topic2...], data] 元素的列表。这些元素由交易执行期间调用的操作码 LOG0 ... LOG4 生成（包含主调用和子调用）；address 是生成日志的合约的地址；topics 是最多 4 个 32 字节的值；data 是任意大小的字节数组；

• 　　logbloom：交易中所有 logs 的 address 和 topics 组成的布隆过滤器。

　　区块头中也存在一个布隆过滤器，它是区块中交易的所有布隆过滤器的或运算（OR）结果。这样的构造使得以太坊协议对轻客户端友好得无以复加。 (责任编辑：admin)