我当初没用 protocol buffers 或 boost 序列化，是因为它们看起来太复杂，没法做到绝对滴水不漏、绝对安全。它们的代码量太大，读不完，也就无法确保不存在某种能触发意外行为的输入。
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 差不多是唯一一个留有大量保留空间的对象。（约 7 字节用于标志，12 字节留给将来可能的 IPv6 扩展）
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)
区块和交易这类较大的东西已经没法再为体积优化多少了。它们的主体数据是哈希、密钥和签名，不可压缩。序列化开销非常小，长度字段通常只占 1 字节。
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.
关于 Gavin 说的现有的 P2P 广播基础设施，我怀疑那东西不存在。只需要广播的 P2P 系统很少。有些库（如 Chord）试图提供分布式哈希表基础设施，但那是个巨大而困难的问题，我们不需要也不想要。那些库装起来也比我们自己的难得多。
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.
当前版本尚未建立逐条校对状态记录。来源核验、历史审校与当前译文校对是不同事项。
译文内容版本：995058d1e45a。用于比对文本，不代表校对等级或更新时间。
请填写对应原文、现译文、建议译法和理由。复制后通过你联系本站作者的渠道提交；此处不会自动发送。
