与PoW不同的是，BFT出块候选是一个协作的过程，期间至少涉及O(n^2)的通讯复杂度，而PoW在出块竞争过程中无须任何通讯代价。基于BFT的协作过程将不会导致分叉，也不需要消耗稀缺资源(算力或者CoinAge)，但是由于这个协作的过程涉及到相当多的数据通讯，所以这个过程无法在全网候选，验证并签名的过程无法在全网展开。这就是为什么BFT类算法一定会涉及到一个委员会的构建过程，并且验证签名只在一个小范围里面发生，剩下的人相信他们就好了。最近出现的很多基于BFT的公链项目，比如Algorand，在如何安全公平的选出这个委员会方面做了很多工作，虽然这些工作对系统性能的提升没有直接关系。) F1 [, u- M! X( V; e5 `
$ }, b* Z) ?$ K
    BFT类算法的投票通常是有权重的，以规避女巫攻击(SybilAttack)。而这个权重多与参与者的权益相关，和PoS的精神类似，进而现在很多人将BFT的这类投票算法称为了PoS算法。而事实上，BFT类共识算法和一开始提出的PoS算法(例如Peercoin)是本质不同的机制。; g6 w" W. e5 r$ s5 P+ L

8 A! i1 s+ k* |& \6 P, p" u2 i* U/ C    上面我们提到，不同的BFT类算法其具体选定出块节点以及委员会成员的过程和系统的性能关系不大。和PoW/PoS类似，其吞吐性能同样决定于每次出块的大小，以及出块的周期。在BFT系统中，如果想要允许每次出块比较大，就需要出块的周期也比较大，从而大概率保证新出的块及其委员会的签名数据在委员会内部完全传播。如果这个传播不充分，将可能导致委员会成员无法达成2/3以上的投票，进而使得委员会内部验证并签名过程超时，最终在本出块的周期内出块失败。-王嘉平
: u% I# s; u8 a+ O9 F6 `6 t
' m. D& D6 z3 e% ~  W* U4 }! l    如果把共识节点都部署在云服务器上，那么如果云服务商出了网络故障，那么区块链网络就会受到影响。这个异步网络是有一定的时间限制的，故障导致通信超过这个时间就容易无法出块。因此对于区块链节点的部署最好是物理上分布式的，即便选择云服务器也要选择不同区域，不同品牌的，确保足够的冗余度。