又狂写了几天代码。还有文档。
这次的短期目标是很明确的：写出一个让自己满意的HotStuff。满意的定义可能有待商榷，但是一个在primary上都跑不满100%CPU的实现一定是不满意的。
至于我现在是不是做这个的时候，嘛我只能尽量让它是。比方说，把中期目标制定为「使各种各样的BFT协议可以支持PB级别状态大小的状态机」，那么先写出各种各样的BFT就是很有必要的了。
总之，被海量的工程细节淹没，有种永远都到达不了完工的胜利彼岸的幻觉。但是我知道那是幻觉，因为我到达过，或者起码看到过曙光，只是那时写的代码有点不太聪明的样子。
那么这次的就很聪明了吗？越写越觉得眼熟了。希望我还是有一些长进的吧。
总之先来看看这次的料肉比。
不甚理想。
Wang, Stephanie, et al. “Lineage stash: fault tolerance off the critical path.” Proceedings of the 27th ACM Symposium on Operating Systems Principles. 2019.
一篇跟我的阅读主题无关的工作，拖拖拉拉看了好久。其中用到了因果日志（causal logging），是个说不定对第三个工作有帮助的概念。
Giridharan, Neil, et al. “Autobahn: Seamless high speed BFT.” Proceedings of the ACM SIGOPS 30th Symposium on Operating Systems Principles. 2024.
因为昨天的组会上讲了这篇所以提前看了。把数据分发和共识解耦的思想在Narwhal and Tusk中就有所体现，但是这篇工作提出分发应当仅仅承担保证可用性的责任，从而更轻量的分发可以带来目标场景下的更理想的性能。
查询Narwhal and Tusk名字怎么拼的过程中发现这个工作的代码是（前）Facebook实现的。浏览实现仓库的过程中发现了Fabric。感觉已经没必要自己发明跑实验脚本了。
前一阵子在那篇PhD读后感还是什么文章里读到，读PhD最重要的就是能接受自己的无知（ignorance）。嘛，我觉得这还不够，还要接受自己总是错失摆脱无知的机会。
小读了一下论文然后又跑去写了一大会代码。测试了门限签名（threshold signature）库的性能。全方面慢于用签名向量模拟的方案。确实可以常数时间验证多签，但是哪怕增加到100参与者（门限为66）签名向量也没有比它慢。
忽然想起另一个关键字多方（multiparty）签名，然后搜到了cggmp21，看起来是最前沿理论成果的一个很扎实的实现。包括它在内的所有多方签名都需要进行多轮消息交换才能完成一次签名，但是cggmp21可以提前做完所有的消息交换，得到一组预签名，然后把它当成私钥用在每个参与者的本地完成剩余操作，和采用签名向量的使用方式是一样的。所以可以构建一个背景任务，维护一个预签名池，但是首先还是要测下性能。
同一个组织还出品了givre，是另一个基于Schnorr签名的门限签名方案，但是它的接口略有不同，需要把消息送进协议状态机来获得签名“股”（share），并不完全符合HotStuff的场景。
又看了一下，这俩算法都要提前选定参与签名的人，并且参与的人都得是好人。这显然是不能放在共识协议的语境下的。
又想了一下，也不能说完全不行，反正就用作happy path的话做类似于「我选中的人全都是好人」的理想化设定也不是不行，大不了回兜底路线。哎呀。
他们还有一个round-based库，是以上这些库的基础框架库，对按轮进行的分布式协议进行了抽象，抽象是基于异步但是可以封装成同步的。
这个我前两天才刚学到一个很像的奇技淫巧，如果真是同一个东西那他们可真是有点东西。
我思考了一下它这个分布式协议抽象的取舍，感觉对于我要实现的不怎么按轮走的协议还是太死板了些，不过确实有点东西。
Zhang, Yunhao, et al. “Byzantine ordered consensus without byzantine oligarchy.” 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20). 2020.
之前我自己在组会上讲过的，但是已经完全记不得它的方案了。居然是用实时时间来做的，挺鸡贼的。当然，这篇主要的贡献还是提出了拜占庭语境下的公平性分析框架，还指出了一些不可能性（impossiblilties），作为领域内深入分析的基础。