# 共识引擎

尽管工作量证明（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 甚至更少的块就足以作为大多数交易的确认。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.fonscan.io/zh_cn/coreidea/consensusengine.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.