今天首先把givre集成进了bft代码库的门限签名模块。它的性能很不错，验证开销和普通的ecdsa没有区别（感觉完全是因为k256没有secp256k1实现高效），感觉可能真的应该用它来搭HotStuff。
性能测试构建依赖已经接近300个了。有点恐怖了，不过想想其中同时包含了0.7、0.8和0.9版本的rand就有点绷不住。
Suri-Payer, Florian, et al. “Basil: Breaking up BFT with ACID (transactions).” Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles. 2021.
打破了传统的「底层复制上层分片+事务并发控制」的分层思想，一体成型的BFT事务存储（store）。规避全局排序，借助乐观并发控制做并发。
对比了TAPIR和基于BFT-SMART和HotStuff的事务存储。感觉整个实验方案是个分布式协议开会，于是去把「评估工件」（evaluation artifact）找来看了看。
好小众的翻译。
然后发现非常混乱并且全部三个别人的协议都是利用现成的实现。好吧。
论文里有一行脚注说去联系了以前工作的作者确认点事，结果对方无法「定位」一份可以工作的实现，给人笑死了。这事一定要往论文里写吗。
顺着TAPIR去翻了翻Irene的网站。读了她关于怎么写SOSP的博客，很有道理。
Zhang, Irene, et al. “Building consistent transactions with inconsistent replication.” ACM Transactions on Computer Systems (TOCS) 35.4 (2018): 1-37.
又是一篇居然才读的工作，在组里的代码库里已经久闻大名了。感觉上有点和Autobahn神似：把复制层打薄，只负责可用性，然后共识由上层的事务协议保证。不同的是Autobahn是对原本一层的复制协议分层成分发层和共识层，共识层本身就能完成整个复制协议的功能（只是特定场景下的性能不好），所以设计比较简单；而TAPIR所针对的容错事务存储场景本来两层就是各管各的，只是一致性的职责两层各做一部分有冗余交集。所以如果把一致性完全集中到事务层了就要对两层都做彻底地重新设计，复制层提供的接口也要改变（这也是TAPIR的核心思想），整体很复杂，没有完全看懂。
Qi, Ji, et al. “Bidl: A high-throughput, low-latency permissioned blockchain framework for datacenter networks.” Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles. 2021.
突然垮掉的一篇，不知道是不是作者机构里的华为给我带来的刻板印象（。但是总感觉真的有种华为发布会那个故弄玄虚的劲是怎么回事。
给BFT加一个用于投机执行的快速路径。基于假设：一个好的主（primary）复制所出的块大概率会以主复制所决定的排序位置最终提交，因此可以在出块的同时投机执行。这么来说其实就是早期preconfirmation。
另外这个投机执行的路径还可以支持在不额外增加延迟的情况下让执行客户端（投机）执行完对一下答案，从而支持非确定性执行。
我还是没太搞懂它是怎么比排序执行式的协议吞吐更高的，只是提前投机执行和不提前不投机执行的区别啊，开销没有差别。它也不和这种工作比，麻了。感觉它的意思是它觉得排序执行的协议天生不支持并行执行，所以压根不做考虑。
感觉它也可以算是Neo的以前工作，我论文里有没有管它啊（冷汗）。这不禁让人想起我讲完Neo以后就有华为的人来找我聊，糟了。（
Androulaki, Elli, et al. “Hyperledger fabric: a distributed operating system for permissioned blockchains.” Proceedings of the thirteenth EuroSys conference. 2018.
复习了一下。我把Fabric的执行排序证实（execute-order-validate）和Eve的执行验证（execute-verify）记混了，或者说一直把它们当作是一样的。执行验证是投机执行完直接比较状态，状态一致就提交。执行排序证实是执行完对执行的副作用排序，然后按顺序将副作用提交并中止冲突的副作用。两者都要求灰盒的，键值存储形式的状态，但是Eve是对状态构建高效的一致性检查（Merkle树），对更新是完全黑盒不管的，Fabric还要求灰盒的、可以用读写集合表示出来的更新。Eve的目标主要就是黑盒执行过程，而Fabric则几乎没有这个目标。
那么问题来了，以太坊到底算什么呢？可能只能算要求投机执行的排序执行吧，或者说，执行排序提交。
Buchman, Ethan, Jae Kwon, and Zarko Milosevic. “The latest gossip on BFT consensus.” arXiv preprint arXiv:1807.04938 (2018).
Tendermint早就已经有自己论文了，但是人们好像总是在引用它的网站。很难描述的一种BFT协议。基于轮的模式有点像异步网络模型下的BFT，但是它又有超时。像是一种把一对多+多对一改成多对多的HotStuff。
又读了一篇Decentralized Thoughts的文章有点似懂非懂了。它跟PBFT的原理是类似的，只是表述成了任意多轮的形式来兼容view change。它和PBFT的主要区别是PBFT在view change的时候交换大量的有可能过时的信息，而Tendermint先等一个强制性的超时，然后假设每个人都有新鲜的信息了，从而减少要交换的信息量。
我觉得好像还行。毕竟本来view change的触发机制就是超时。从工程的角度超多超少都还好。
然后居然还给我找到一个PBFT的官方实现。居然还有这种东西，太可怕了。
又去读了一下Tendermint文档。这个好懂多了。
Kuhring, Lucas, et al. “Streamchain: Rethinking blockchain for datacenters.” arXiv preprint arXiv:1808.08406 (2018).
一个纯堆工程的性能优化工作。去掉批处理换取低延迟，然后再尽量优化来保持住吞吐。
看完了OSDI20和SOSP21。坏消息从这里开始OSDI一年一届。好消息OSDI24已经没有什么BFT了（真的是好消息吗）。今天先看到这里吧。
感到不安心又去读了Tendermint另外的文档。果然在每次出块之间都要有强制的超时。论文里完全不写，很坏。算了不管他了。