概述
x/evidence 是 Cosmos SDK 模块的一种实现,遵循 ADR 009,
允许提交并处理任意类型的作恶证据,
例如双重签名和反事实签名。
证据模块不同于标准的证据处理方式。标准方式通常依赖底层共识引擎(例如 CometBFT)在发现证据时自动提交;
而证据模块允许客户端和外部链直接提交更复杂的证据。
所有具体证据类型都必须实现 Evidence 接口约定。提交的
Evidence 会首先经过证据模块的 Router 路由,在此过程中它会尝试为该特定 Evidence 类型查找已注册的对应 Handler。
每种 Evidence 类型都必须在证据模块 keeper 中注册一个 Handler,
这样才能被成功路由并执行。
每个对应的处理器还必须满足 Handler 接口约定。给定 Evidence 类型的
Handler 可以执行任意状态转换,
例如削减质押、监禁以及墓碑标记。
概念
证据
提交到x/evidence 模块的任何具体证据类型都必须满足
下述 Evidence 约定。并非所有具体证据类型都会以相同方式满足
该约定,而且某些数据对于某些证据类型可能完全无关。
另外还创建了扩展 Evidence 的 ValidatorEvidence,
用于定义针对恶意验证者证据的约定。
注册与处理
x/evidence 模块必须首先了解它预期要处理的所有证据类型。
这是通过将 Evidence 约定中的 Route 方法注册到一个称为 Router 的组件上来实现的(定义如下)。Router 接收
Evidence,并通过 Route 方法为该 Evidence
尝试找到对应的 Handler。
Handler(定义如下)负责执行处理 Evidence 的全部
业务逻辑。这通常包括对证据进行校验,
既包括通过 ValidateBasic 的无状态校验,也包括借助提供给 Handler 的任意 keeper 进行有状态校验。
此外,Handler 还可以执行诸如削减质押和监禁验证者等能力。所有由
Handler 处理的 Evidence 都应被持久化。
状态
当前,x/evidence 模块只会在状态中存储已提交且有效的 Evidence。
证据状态也会存储并导出到 x/evidence 模块的 GenesisState 中。
Evidence 都通过前缀为 0x00(KeyPrefixEvidence)的前缀 KVStore 进行读取和存储。
消息
MsgSubmitEvidence
证据通过MsgSubmitEvidence 消息提交:
MsgSubmitEvidence 消息中的 Evidence 必须在
x/evidence 模块的 Router 中注册有对应的 Handler,才能被正确处理和路由。
如果该 Evidence 已注册对应的 Handler,其处理流程如下:
Evidence。
其次,Evidence 会被路由到对应的 Handler 并执行。最后,
如果处理 Evidence 时没有发生错误,则会发出一个事件,并将其持久化到状态中。
事件
x/evidence 模块会发出以下事件:
处理器
MsgSubmitEvidence
| 类型 | 属性键 | 属性值 |
|---|---|---|
| submit_evidence | evidence_hash | {evidenceHash} |
| message | module | evidence |
| message | sender | {senderAddress} |
| message | action | submit_evidence |
参数
证据模块不包含任何参数。BeginBlock
证据处理
CometBFT 区块可以包含 Evidence, 用于表明某个验证者是否实施了恶意行为。相关信息会作为abci.RequestBeginBlock 中的 ABCI Evidence 转发给应用,以便据此惩罚该验证者。
双重签名
Cosmos SDK 会在 ABCIBeginBlock 中处理两类证据:
DuplicateVoteEvidenceLightClientAttackEvidence
Evidence 接口,并使用 Equivocation 作为具体类型。
block 中提交的 Equivocation 若要有效,必须满足:
Evidence.Timestamp >= block.Timestamp - MaxEvidenceAge
其中:
Evidence.Timestamp是高度为Evidence.Height的区块中的时间戳block.Timestamp是当前区块时间戳。
Equivocation 证据,则验证者的质押会按违规发生时的质押数量,
依据 x/slashing 模块中定义的 SlashFractionDoubleSign 进行削减,
而不是按发现证据时的质押数量计算。
我们希望“跟随质押”,也就是说,导致此次违规的那部分质押
即使之后已被重新委托或开始解除绑定,也应被削减。
此外,该验证者会被永久监禁并打上墓碑标记,从而确保该
验证者永远无法重新进入验证者集合。
Equivocation 证据的处理方式如下:
x/slashing 模块委托执行,
该模块会发出说明性事件,并最终将调用委托给 x/staking 模块。参见
状态转换 中关于削减质押与监禁的文档。
客户端
CLI
用户可以使用 CLI 查询并与evidence 模块交互。
Query
query 命令允许用户查询 evidence 状态。
evidence
evidence 命令允许用户列出所有证据,或按哈希查询证据。
用法:
REST
用户可以使用 REST 端点查询evidence 模块。
Evidence
按哈希获取证据All evidence
获取所有证据gRPC
用户可以使用 gRPC 端点查询evidence 模块。
Evidence
按哈希获取证据All evidence
获取所有证据Abstract
x/evidence is an implementation of a Cosmos SDK module, per ADR 009,
that allows for the submission and handling of arbitrary evidence of misbehavior such
as equivocation and counterfactual signing.
The evidence module differs from standard evidence handling which typically expects the
underlying consensus engine, e.g. CometBFT, to automatically submit evidence when
it is discovered by allowing clients and foreign chains to submit more complex evidence
directly.
All concrete evidence types must implement the Evidence interface contract. Submitted
Evidence is first routed through the evidence module’s Router in which it attempts
to find a corresponding registered Handler for that specific Evidence type.
Each Evidence type must have a Handler registered with the evidence module’s
keeper in order for it to be successfully routed and executed.
Each corresponding handler must also fulfill the Handler interface contract. The
Handler for a given Evidence type can perform any arbitrary state transitions
such as slashing, jailing, and tombstoning.
Concepts
Evidence
Any concrete type of evidence submitted to thex/evidence module must fulfill the
Evidence contract outlined below. Not all concrete types of evidence will fulfill
this contract in the same way and some data may be entirely irrelevant to certain
types of evidence. An additional ValidatorEvidence, which extends Evidence,
has also been created to define a contract for evidence against malicious validators.
Registration & Handling
Thex/evidence module must first know about all types of evidence it is expected
to handle. This is accomplished by registering the Route method in the Evidence
contract with what is known as a Router (defined below). The Router accepts
Evidence and attempts to find the corresponding Handler for the Evidence
via the Route method.
Handler (defined below) is responsible for executing the entirety of the
business logic for handling Evidence. This typically includes validating the
evidence, both stateless checks via ValidateBasic and stateful checks via any
keepers provided to the Handler. In addition, the Handler may also perform
capabilities such as slashing and jailing a validator. All Evidence handled
by the Handler should be persisted.
State
Currently thex/evidence module only stores valid submitted Evidence in state.
The evidence state is also stored and exported in the x/evidence module’s GenesisState.
Evidence is retrieved and stored via a prefix KVStore using prefix 0x00 (KeyPrefixEvidence).
Messages
MsgSubmitEvidence
Evidence is submitted through aMsgSubmitEvidence message:
Evidence of a MsgSubmitEvidence message must have a corresponding
Handler registered with the x/evidence module’s Router in order to be processed
and routed correctly.
Given the Evidence is registered with a corresponding Handler, it is processed
as follows:
Evidence of the exact same
type. Secondly, the Evidence is routed to the Handler and executed. Finally,
if there is no error in handling the Evidence, an event is emitted and it is persisted to state.
Events
Thex/evidence module emits the following events:
Handlers
MsgSubmitEvidence
| Type | Attribute Key | Attribute Value |
|---|---|---|
| submit_evidence | evidence_hash | {evidenceHash} |
| message | module | evidence |
| message | sender | {senderAddress} |
| message | action | submit_evidence |
Parameters
The evidence module does not contain any parameters.BeginBlock
Evidence Handling
CometBFT blocks can include Evidence that indicates if a validator committed malicious behavior. The relevant information is forwarded to the application as ABCI Evidence inabci.RequestBeginBlock so that the validator can be punished accordingly.
Equivocation
The Cosmos SDK handles two types of evidence inside the ABCIBeginBlock:
DuplicateVoteEvidence,LightClientAttackEvidence.
Evidence interface using Equivocation as the concrete type.
Equivocation submitted in block to be valid, it must satisfy:
Evidence.Timestamp >= block.Timestamp - MaxEvidenceAge
Where:
Evidence.Timestampis the timestamp in the block at heightEvidence.Heightblock.Timestampis the current block timestamp.
Equivocation evidence is included in a block, the validator’s stake is
reduced (slashed) by SlashFractionDoubleSign as defined by the x/slashing module
of what their stake was when the infraction occurred, rather than when the evidence was discovered.
We want to “follow the stake”, i.e., the stake that contributed to the infraction
should be slashed, even if it has since been redelegated or started unbonding.
In addition, the validator is permanently jailed and tombstoned to make it impossible for that
validator to ever re-enter the validator set.
The Equivocation evidence is handled as follows:
x/slashing module
that emits informative events and finally delegates calls to the x/staking module. See documentation
on slashing and jailing in State Transitions.
Client
CLI
A user can query and interact with theevidence module using the CLI.
Query
Thequery command allows users to query evidence state.
evidence
Theevidence command allows users to list all evidence or evidence by hash.
Usage:
REST
A user can query theevidence module using REST endpoints.
Evidence
Get evidence by hashAll evidence
Get all evidencegRPC
A user can query theevidence module using gRPC endpoints.