回复：将 Protocol Buffers 用于比特币
原始发布页
打开来源页面查看 1 个交叉存档
我没有使用 protocol buffers 或 boost serialization，是因为它们看起来太复杂，很难做到绝对严密和安全。它们的代码太庞大了，无法通读并确信不存在某种输入方式会导致意外行为。
我讨厌重复造轮子，只是迫不得已才自己编写序列化例程。我们现有的序列化格式尽可能地简单、扁平。输入流的构成方式没有额外的自由度。在每一个位置，都会期待数据结构中的下一个字段。允许出现的选择只有接收方所预期的那些。它带有版本机制，因此可以进行升级。
CAddress 差不多是唯一一个预留空间较多的对象。（大约 7 字节用于标志，12 字节用于未来可能的 IPv6 扩展）
我们拥有的较大对象，例如区块和交易，在大小方面已经没有多少进一步优化的空间。它们的数据主体是哈希、密钥和签名，这些都无法压缩。序列化开销非常小，大小字段通常只占 1 字节。
至于加文提出的现成 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.