最后再纠结一下Tendermint。读了Informal Systems一篇分析它的小短文以及一些博客。 我最后在Tendermint文档里找到的提交后超时大概是一种工程优化，并不是协议保证一致性所必要的。在这之前我的理解基本是没错的。在主复制是好人的快速路径上，大家都没有超时，设计上也都差不多。在大家决定切换主复制的慢速路径上，PBFT是立刻交换大量信息，迅速将参与者都带到最新的视角；H...

没有什么创新，就是读stringleton的介绍文章的时候在想把经典的低延迟技术用在字符串驻留上面，会不会还没人做过。 字符串驻留的接口一般是输入一个字符串，如果它已经被驻留过了（或者说，曾经有跟它完全一样的字符串被驻留过），就返回那个以前驻留的字符串地址；否则记录它的地址并原样返回。 显然，「如果它已经被驻留过」是一次读共享可变状态，「记录它的地址」是一次写共享可变状态，因此需要给状态...

依赖地狱。不同的包在摆放依赖的时候要遵守同一套规矩（即共享系统目录），所以它们的行为对对方是可见的可能产生冲突。 自持（self-contained）打包。Vendor（这怎么翻译）全部的依赖。极端做法如Go，全静态链接的编译。大部分厂商会以单独文件的形式存放在可执行入口的路径附近。造成很多重复的通用依赖（如Electron）。比消耗存储更糟糕的是消耗内存：操作系统无法获知不同软件的同一（...

今天首先把givre集成进了bft代码库的门限签名模块。它的性能很不错，验证开销和普通的ecdsa没有区别（感觉完全是因为k256没有secp256k1实现高效），感觉可能真的应该用它来搭HotStuff。 性能测试构建依赖已经接近300个了。有点恐怖了，不过想想其中同时包含了0.7、0.8和0.9版本的rand就有点绷不住。 Suri-Payer, Florian, et a...

又狂写了几天代码。还有文档。 这次的短期目标是很明确的：写出一个让自己满意的HotStuff。满意的定义可能有待商榷，但是一个在primary上都跑不满100%CPU的实现一定是不满意的。 至于我现在是不是做这个的时候，嘛我只能尽量让它是。比方说，把中期目标制定为「使各种各样的BFT协议可以支持PB级别状态大小的状态机」，那么先写出各种各样的BFT就是很有必要的了。 总之，被海量的工程...

狂写了几天PBFT。 虽然再写一遍PBFT是所有编程工作中最没意义的一种了，但是在当下这个很久没动手写过代码，也丧失了很多能写出代码的信心的节骨眼，写一个让自己满意的BFT协议实验平台大概是恢复信心最好的选择。 打破心魔还是有必要的，就算已经焦头烂额了。 不过我也不敢说这次写的代码就比以往所有设计都要好。这次的代码至今都没有什么大规模的范型，让我感到有点奇怪。但是我已经不会因为这个而怀...

DHT事实意义上只保证最终一致性。现有的方案可以防止数据不可用/不耐久/被篡改，但是作恶节点可以轻易导致停滞（stalled）的返回结果。 借助可验证随机函数（verifiable random function）来保证非作恶节点高概率参与到操作当中（或者反过来说，操作不会在接触到非作恶节点之前结束），从而实现一致性语义的保证。

互联网带宽是珍惜资源，本地（如国内）带宽显著比全局（如跨洲）带宽实惠和资源充足。 通过众包的方式，绕过互联网，以物理方式将数据长距离传递（如通过越洋航班上的移动设备携带）到目的地附近的本地网络下，然后进行收集。 使用无码率擦除码（rateless erasure code）来应对有损传递。