对SBFT算法的一点理解

欢迎关注一下我的 知乎账号，以后主要在知乎分享内容。感谢~
https://www.zhihu.com/people/ypjiang96/posts

看了好久的SBFT终于快看完了，然而有些细节还是没搞懂=_=||，接下来准备去看源码了
需要说明的是一下内容只是读完论文后的一些梳理，我并没有完全理解，可能存在错误，后续我会再进行修改。

SBFT可以说是PBFT的扩展，它解决了扩展性(scalabillity)的问题，可以支持世界范围内的209个replicas（其中64个拜占庭错误replica）正常运行，并且吞吐量可以达到PBFT的两倍，延迟也更低。

INTRODUCTION

中心化提供了好的性能，但存在一系列问题，比特币和以太坊的成功说明了去中心化巨大的潜在价值。但是研究表明，比特币和以太坊并没有先前想的那么去中心化，前20%的矿池控制了超过90%的算力。这一研究说明了BFT算法应用于区块链的可行性（由于PoW过于消耗资源），也促使了BFT相关算法的研究。近年来BFT相关算法有替换掉PoW或者与PoW组合应用于区块链的趋势。

SBFT：a Scalable Decentralized Trust Infrastructure for Blockchains

SBFT为了做到这些性能上的提升，基于PBFT增加了四点设计上的改进：

1. going from PBFT to linear PBFT
2. adding a fast path
3. using cryptography to allow a single message acknowledgement
4. adding redundant servers to improve resilience and performance

From PBFT to linear PBFT

很多之前的系统都使用了多对多(all-to-all)的消息模式来提交一个确认区块，SBFT提出了一个使用收集器(collector)的线性通信模式。这种模式下不再将消息发给每一个replica，而是发给collector，然后再由collector广播给所有replicas。同时通过使用门限签名(threshold signatures)可以将消息长度从线性降低到常数。

Zyzzyva也使用了collector，但是将collector的职责放到了client，而SBFT将collector的职责放到了replica。

adding a fast path

当所有replica都没有错误并且是同步(synchronous)时，SBFT允许使用快速共识机制。

SBFT实现了第一个正确且实用的双模式view change，可以在快速共识和正常共识之间无缝切换。

reducing client communication from f+1 to 1

在之前所有的解决方案中，client都需要收到$f+1$个来自replicas的一致的reply才可以确认自己发出的request是否被执行。当client和replicas增多时，通信负载压力会增大。在SBFT中，正常情况下，每一个client只需要收到一个reply就足够了，这使得SBFT可以支持非常多的瘦客户端。

SBFT通过使用execution collector来做到这一点，execution collector收集replicas的execution threshold signatures并将其组合起来发送给client。像公链(比如比特币和以太坊)一样，SBFT也使用了默克尔树(merkle tree)来认证从某一个replica读取的信息。

SBFT使用了BLS签名，相比RSA签名，BLS只需要33个bytes就可以达到2048个bit的RSA签名的安全性。(其实不太理解这里为什么论文作者不使用相同的单位，2048个bit也就是256个bytes，不过八倍还是很可观的，当然BLS还有很多其他很有用的性质)。

addding redundant servers to improve resilience and performance

SBFT是安全的当有$f$个拜占庭节点时，不过只有当所有的节点都没有错误且系统是同步的时候才可以使用标准的快速共识，因此即使一个节点的故障都会使系统从fast path切换到slow path。

SBFT借鉴了single-shot consensus algorithm中提出的理论，使得fast path可以在$3f+2c+1$个replicas的系统中容忍$c$个故障replicas。

Evaluating SBFT’s scalability

由于目前没有什么可以和SBFT比的，于是作者改进了已有的PBFT算法，称之为scale optimized PBFT，作为比较对象。

总之就是效果很好就是了:)

While our view change protocol is new, one could argue that the other ingredients mentioned have appeared in some form in previous work. Nevertheless, SBFT is the first to careful weave and implement all these ingredients into a highly efficient and scalable BFT system.

SYSTEM MODEL

论文中讨论了三种模型：

• 标准异步模型
  敌人最多控制网络中的$f$个拜占庭节点、可以造成整个网络的延迟。

  SBFT可以保证safety，也就是任何两个replicas都会按同样的顺序执行同一个block。

• 同步模型
  敌人最多控制网络中的$f$个拜占庭节点。

  SBFT可以保证liveness，也就是client的request都会得到reply

• 通用模型
  敌人最多控制网络中的$c$个节点（只能crash或者act slow）。

  SBFT可以保证linearity，就是说每提交一个block只需要固定数量的消息（大概是吧）

MODERN CRYPTOGRAPHY

SBFT还使用了门限签名(threshold signature)，对于$n$个replicas，只需要replicas的一个子集对block进行签名就可以验证。即子集中的replica分别使用自己的私钥签名之后再组合起来，最后可以只验证一次就可以了。

SBFT使用了比RSA签名算法更短更快的BLS签名算法，BLS基于椭圆曲线，有很多实用的性质，比如支持批量验证签名。

SERVICE PROPERTIES

SBFT提供了一个可扩展的通用复制服务的容错实现（也就是状态机复制服务），在这之上使用默克尔树实现了一个可认证的键值存储，之上又实现了可以执行EVM字节码的智能合约层。

Generic service

实现了确定的带状态的复制服务、确定的操作、只读的查询接口。

1. $val=execute(D,o)$：根据操作$o$修改状态$D$，并返回$val$.

2. $val=query(D,q)$：返回状态$D$下的查询$q$，不修改$D$.

3. 服务的状态由离散的block改变，每一个block包含一些request，论文中使用$D_j$表示执行完序号为$j$的block的状态，使用$re{q}_j$表示序号为$j$的block包含的request.

A authenticated key-value store

为了支持client高效地认证来自某个replica的消息，在键值存储中设计了一些数据认证接口。

1. $d=digest(D)$：返回状态为$D$的默克尔哈希根的值作为哈希值。
2. $P=proof(o,l,s,D,val)$：返回序号为$s$的block中第$l$个操作$o$执行后(state状态变为$D$)的结果$val$的证明
3. $P=proof(q,s,D,val)$： 和2一样，不过是查询$q$的证明。
4. $verify$