网络安全检测|网络安全服务|网络安全扫描-香港墨客投资移动版

BOS致力于为用户提供方便进入并易于使用的区块链服务，为DApp运营提供更友好的基础设施，为支持更丰富的应用场景努力，为DApp大繁荣进行积极尝试。除了技术改进以外，BOS也会进行其他方面的尝试。比如，为了提高用户投票参与度，可以通过预言机技术来针对符合明确规则的账户进行激励；BOS上面的BP的奖励会根据链上DApp的数量、TPS、市值、流通量等指标进行调整，鼓励每个BP为生态提供更多资源；一项社区公投达成的决议将会尽量被代码化，减少人为的因素在里面，流程上链，保持公正透明。

BOS链的代码完全由社区贡献并维护，每个生态参与者都可以提交代码或者建议，相关的流程会参考已有开源软件来进行，比如PEP（Python Enhancement Proposals）。

为鼓励DApp在BOS的发展，BOS基金会将会为其上的DApp提供Token置换的低成本的资源抵押服务，降低DApp前期的运营成本；此外还会定期对做出贡献的开发者提供BOS激励，以便建立起一个相互促进的社区发展趋势。

共识机制

EOSIO采用的是基于流水线的拜占庭容错机制 （Pipelined Byzantine Fault Tolerance），对于一个Block需要经过Propose、Pre-Commit、Commit、Finalize ［1］ 几个步骤，最后不可更改的块范围由Last Irreversible Block （LIB） 标明；一笔交易基本上需要约3分钟 （理论最低为325个出块时间，即162.5秒） 才能进入LIB，虽然相比BTC、ETH等其他数字通证的交易可靠时间有很大提高，但是对于很多应用场景来说还是有很大限制。比如支付场景，由于不能立即确定该笔交易最后是否成功，需要等待一段的时间才可完成商品的交易，这就增加了很多限制。

造成交易需要较长确认时间的原因是在DPOS BFT共识算法中，所有块同步后的确认信息都只有轮到该节点出块的时候才会被广播出去。举个例子来说，在BP1出块（所出块为BLKn），BP1 ～ BP21轮流出块的情况下，BP2 ～ BP21会陆续收到并验证BLKn，但所有BP只能等到自己出块的时候才能发出对BLKn的确认信息。

在分析过EOSIO共识算法的问题以后，为了缩短一笔交易变成不可更改状态的时间，BOS将采用PBFT （Practical Byzantine Fault Tolerance［2］） 来替代Pipelined BFT，让BP之间实时地对当前正在生产的区块进行确认，能够使整个系统最终达到接近实时的共识速度。

BOS的共识算法是在 PBFT 理论基础上，结合EOSIO代码进行的改进，在保证实现拜占庭容错的前提下，会进行以下部分的改动：

1. 保留Pipelined BFT的BP 轮流出块的机制，并且和EOS一样对同步时钟和出块顺序进行强约束

2. 移除Pipelined BFT共识部分的逻辑，即去掉原本出块时的implicit confirm 和 （explict） confirm 部分，避免在极端情况下与PBFT的共识结果产生冲突

3. 共识的通讯机制使用现有p2p网络进行，将会使用PBFT机制广播prepare和commit信息，并保证通信成本在可接受范围内。

4. 采用批量共识替换PBFT中对每个块进行共识的要求，通过一次广播多个块的相关信息，以此来逼近实时BFT的理想状态并减轻网络负载。

BOS PBFT中状态描述如下：

· pre-prepare，指出块节点出块以后，广播给网络里的所有其他中继节点。可以类比为EOSIO中BP出块并广播至全网。

· prepare，指中继节点收到请求后向全网广播将要对此请求进行执行。可类比为EOSIO中所有节点收到块并验证成功后广播已收到的信息。

· commit，指中继节点收到足够多的对同一请求的prepare消息，向全网广播执行此请求。可以类比为EOSIO中节点收到足够多对同一个块的prepare消息，提出proposed lib消息

· committed-local，指中继节点收到足够多对同一请求的commit消息，完成了验证工作。 可以类比为EOSIO中的LIB提升。

· view change，指出块节点因为各种原因失去其他节点的信任，整个系统更改出块节点的过程。由于EOSIO采用了Pipelined BFT的算法，所有BP是通过投票的方式提前确定的，在一轮出块中整个系统的出块顺序是完全不变的。当网络情况良好并且出块节点没有发生改变的时候可以认为不存在view change状态。当引入PBFT后，为了避免分叉导致共识不前进的情况，加入view change机制，抛弃所有未达成共识的块进行replay，不断重试直到继续共识。

· checkpoint，指在某一个块高度记录共识证据，以此来提供安全性证明。当足够多的中继节点的checkpoint相同时，这个checkpoint被认为是stable的。checkpoint的生成包括两大类：一类是固定k个块生成，另一类是特殊的需要提供安全性证明的点，例如出块BP排名发生变更的块。