# 共识引擎

尽管工作量证明（PoW）已被公认为实现去中心化网络的实用机制，但它对环境不友好，并且需要大量参与者来维护安全性。

以太坊和其他一些区块链网络，如[MATIC Bor](https://github.com/maticnetwork/bor)、[TOMOChain](https://tomochain.com/)、[GoChain](https://gochain.io/)、[xDAI](https://xdai.io/)，确实在不同的场景中使用[权威证明（PoA）](https://en.wikipedia.org/wiki/Proof_of_authority)或其变体，包括测试网和主网。PoA 为 51% 攻击提供了一些防御，提高了效率和对某些级别的拜占庭玩家（恶意或被黑客攻击）的容忍度。它可以作为选择基础的简单选择。

同时，PoA 协议最受诟病的地方在于它不像 PoW 那样去中心化，因为验证者，即轮流出块的节点，拥有所有权限，容易受到腐败和安全攻击。其他区块链，例如 EOS 和 Lisk，都引入了不同类型的[委托权益证明 (DPoS)](https://en.bitcoinwiki.org/wiki/DPoS)，以允许代币持有者投票并选举验证者集。它增加了权力下放并有利于社区治理。

FSC在此提出将DPoS和PoA结合起来进行共识，这样：

1. 块由一组有限的验证器生成
2. 验证者以 PoA 方式轮流出块，类似于[以太坊的 Clique](https://eips.ethereum.org/EIPS/eip-225)共识设计
3. 验证者集是根据基于抵押的治理选入和选出的

FSC 的共识协议实现了以下目标：

1. 阻塞时间短，主网上 3 秒。
2. 确认交易的最终性需要有限的时间，主网大约需要 45 秒。
3. 原生代币FON不存在通胀，区块奖励从交易手续费中收取，以FON支付。
4. 它与以太坊系统 100% 兼容。
5. 它允许现代权益证明区块链网络治理。

### 验证者法定人数 <a href="#validator-quorum" id="validator-quorum"></a>

在创世阶段，一些可信节点将作为初始验证者集运行。封锁开始后，任何人都可以竞争加入成为候选人来选举验证人。质押状态决定前 21 个最受质押的节点成为下一个验证者集，这样的选举将每 3 小时重复一次。

FON 是用于为 FSC 抵押的代币。

为了保持与以太坊的兼容性并可升级到未来要开发的共识协议，FSC 这些规则全部写入了创世合约。FSC上有一个专门用于 Dapp 的质押模块。

### 帕利亚 <a href="#parlia" id="parlia"></a>

共识引擎的实现被命名为**Parlia**，类似于[clique](https://ethereum-magicians.org/t/eip-225-clique-proof-of-authority-consensus-protocol/1853)。本文档将更多地关注差异而忽略共同的细节。

#### 轻客户端安全 <a href="#light-client-security" id="light-client-security"></a>

验证者集更改发生在 (epoch+N/2) 个区块。（N 是 epoch 块之前验证器集的大小）。考虑到轻客户端的安全性，我们延迟 N/2 块让 validatorSet 发生变化。

每一个epoch块，验证器都会从合约中查询验证器集，并将其填充到块头的extra\_data字段中。全节点将根据合约中的验证器集对其进行验证。轻客户端将使用它作为下一个 epoch 块的 validatorSet，但是，它不能根据合约验证它，它必须相信 epoch 块的签名者。如果 epoch 块的签名者写入了错误的 extra\_data，轻客户端可能会转到错误的链上。如果我们延迟 N/2 个块让 validatorSet 发生变化，错误的 epoch 块将不会得到其他 N/2 个由其他验证器签名的后续块，这样轻客户端就不会受到这种攻击。

#### 系统交易 <a href="#system-transaction" id="system-transaction"></a>

共识引擎可能会调用系统合约，这样的交易称为系统交易。系统交易由生产区块的验证者签名。对于见证节点，会根据其内在逻辑生成系统交易（不带签名），并与区块中的系统交易进行比对，然后再应用。

#### 强制退避 <a href="#enforce-backoff" id="enforce-backoff"></a>

在 Clique 共识协议中，乱序验证者必须等待一段随机的时间才能封块。它在客户端节点软件中实现，并假设验证器将运行规范版本。然而，考虑到验证者在经济上会受到激励以尽快密封区块，验证者可能会运行节点软件的修改版本来忽略这种延迟。为防止验证者仓促封块，每个轮到的验证者都会获得一个指定的时间段来封块。任何出块时间较早的出块验证者产生的块都将被其他见证节点丢弃。

#### 通过临时审查 <a href="#extending-the-ruling-of-the-current-validator-set-via-temporary-censorship" id="extending-the-ruling-of-the-current-validator-set-via-temporary-censorship"></a>

如果更新验证器的交易在 epoch 期间被发送到 FSC，那么验证器可能会审查交易并且不更改该 epoch 的验证器集。虽然如果没有其他 n/2 个验证者的帮助，一笔交易不可能永远被审查，但它可以延长当前验证者集的时间并获得一些奖励。一般来说，这个方案的概率可以通过与其他验证者串通来增加。这是一个相对良性的问题，一个块可能大约是 3 秒，一个纪元是 200 个块，即 20 分钟，因此验证器只能再延长 10 分钟。

### 安全性和最终性 <a href="#security-and-finality" id="security-and-finality"></a>

假设有超过 ½ \* N+1 个验证者是诚实的，基于 PoA 的网络通常可以安全和正确地工作。然而，在某些情况下，一定数量的拜占庭验证器仍可能设法攻击网络，例如通过[克隆攻击](https://arxiv.org/pdf/1902.10244.pdf)。为了与 FC 一样安全，鼓励 FSC 用户等到收到由超过 ⅔\*N+1 个不同验证者密封的块。这样，FSC 可以在与 FC 类似的安全级别上受到信任，并且可以容忍少于 ⅓ \* N 的拜占庭验证器。有 50 个验证者，如果出块时间为 3 秒，则 ⅔ \* N+1 个不同的验证者印章将需要 (⅔ \* 21+1) \*的时间段3 = 45 秒。FSC 的任何关键应用程序可能必须等待 ⅔ \* N+1 以确保相对安全的最终性。然而，除了这样的安排，FSC 确实引入了 Slashing 逻辑来惩罚拜占庭验证者的双重签名或不可用。这种 Slashing 逻辑将在很短的时间内暴露恶意验证者，并使“克隆攻击”非常难以执行或执行起来极其无益。有了这个增强，½ \* N+1 甚至更少的块就足以作为大多数交易的确认。