原始文献 / 论坛帖 / Re: Protocol Buffers for Bitcoin
Re: Protocol Buffers for Bitcoin
Bitcointalk · 2010-08-02 20:22:08 UTC
我没用 protocol buffers 或 boost serialization，是因为它们看起来太复杂，无法做到绝对严密和安全。它们的代码量太大，读完也无法确信不存在某种能引发意外行为的输入构造方式。
我讨厌重复造轮子，是很不情愿才自己写序列化例程的。我们的序列化格式尽可能地简单扁平。输入流的构造方式没有任何多余的自由度。在每一处，接收方期待的就是数据结构中的下一个字段。给出的选择只有接收方预期的那些。有版本机制，所以升级是可行的。
CAddress 是唯一有可观预留空间的对象。（标志位约 7 字节，未来 IPv6 扩展约 12 字节）
像区块和交易这样的大对象在体积上已经没多少优化空间。它们的大部分数据是哈希、密钥和签名，这些都不可压缩。序列化开销非常小，长度字段通常只有 1 字节。
关于 Gavin 提到的现有 P2P 广播基础设施的想法，我怀疑根本不存在。只需要广播的 P2P 系统很少。有些库比如 Chord 试图提供分布式哈希表基础设施，但那是个我们不需要也不想要的巨大难题。那些库的安装难度也比我们自己大得多。
英文原文
The reason I didn't use protocol buffers or boost serialization is because they looked too complex to make absolutely airtight and secure. Their code is too large to read and be sure that there's no way to form an input that would do something unexpected.
I hate reinventing the wheel and only resorted to writing my own serialization routines reluctantly. The serialization format we have is as dead simple and flat as possible. There is no extra freedom in the way the input stream is formed. At each point, the next field in the data structure is expected. The only choices given are those that the receiver is expecting. There is versioning so upgrades are possible.
CAddress is about the only object with significant reserved space in it. (about 7 bytes for flags and 12 bytes for possible future IPv6 expansion)
The larger things we have like blocks and transactions can't be optimized much more for size. The bulk of their data is hashes and keys and signatures, which are uncompressible. The serialization overhead is very small, usually 1 byte for size fields.
On Gavin's idea about an existing P2P broadcast infrastructure, I doubt one exists. There are few P2P systems that only need broadcast. There are some libraries like Chord that try to provide a distributed hash table infrastructure, but that's a huge difficult problem that we don't need or want. Those libraries are also much harder to install than ourselves.