​

治理

​

概述

​

仅限验证者的治理

1. AfterProposalSubmission：只有授权验证者可以提交提案
2. AfterProposalDeposit：只有授权验证者可以为提案存入押金
3. AfterProposalVote：只有授权验证者可以投票

• 在 PoA 模块中已注册
• Power > 0
• 拥有有效的 operator address

• 如果非验证者尝试执行治理操作 → 交易失败
• 如果验证者的 power = 0 → 交易失败
• 错误：“voter X is not an active PoA validator”

​

投票权重

1. 收集投票：系统遍历某个提案上的全部投票
2. 验证者检查：对每一票，验证投票者是否为活跃的 PoA 验证者
3. 权重计算：使用验证者的 power 作为投票权重
4. 加权选项：支持拆分投票，与传统 POS 治理中的 x/staking 完全一致（例如 70% Yes，30% Abstain）
5. 汇总结果：按选项累加加权投票结果

​

计票算法

• $V_i$ = 验证者 $i$ 的投票权重
• $P_i$ = 验证者权重（共识权重）

• $W_{i,o}$ = 验证者 $i$ 对选项 $o$ 的投票权重
• $w_{i,o}$ = 验证者 $i$ 分配给选项 $o$ 的权重（其中 $\sum_{o} w_{i,o} = 1$）

• $T_o$ = 选项 $o$ 的总票数
• 对所有已投票的验证者求和

​

示例

• $W_{A,Yes} = 100 \times 1.0 = 100$

• $W_{B,Yes} = 50 \times 0.6 = 30$
• $W_{B,No} = 50 \times 0.4 = 20$

• $T_{Yes} = 130$
• $T_{No} = 20$

​

提案生命周期

​

1. 提案提交

1. 标准治理先校验提案内容
2. 调用 AfterProposalSubmission 钩子
3. PoA 模块检查提案提交者是否为授权验证者：
   • 通过 operator address 查找提案提交者
   • 验证该验证者存在且满足 $P > 0$
   • 如果不是活跃验证者，则返回错误并拒绝
4. 如果校验通过，提案进入押金期

​

2. 押金期

1. 标准治理处理该押金
2. 调用 AfterProposalDeposit 钩子
3. PoA 模块检查存入者是否为授权验证者
4. 如果达到押金门槛，提案进入投票期

​

3. 投票期

1. 标准治理记录该投票
2. 调用 AfterProposalVote 钩子
3. PoA 模块校验投票者是否为授权验证者
4. 如果校验失败，交易失败

• Yes：支持提案
• No：反对提案
• NoWithVeto：反对并否决（若达到阈值可销毁押金）
• Abstain：参与法定人数统计但不表达立场

​

4. 计票

1. 遍历提案上的全部投票
2. 对每一票，根据投票者地址查找对应验证者
3. 如果验证者不是活跃状态（$P \leq 0$），则跳过该票
4. 否则，使用验证者权重作为投票权重
5. 对于加权投票，将权重分配到各个选项
6. 按选项汇总所有加权投票
7. 应用标准治理阈值：
   • Quorum：最低参与比例
   • Threshold：提案通过所需的最低 Yes 比例
   • Veto：触发否决前允许的最高 NoWithVeto 比例

​

实现细节

​

治理钩子

type GovHooks interface {
    AfterProposalSubmission(ctx, proposalID, depositorAddr)
    AfterProposalDeposit(ctx, proposalID, depositorAddr)
    AfterProposalVote(ctx, proposalID, voterAddr)
    // ... other hooks
}

1. 从上下文中提取 operator address
2. 通过 operator address 查找验证者
3. 检查验证者是否存在且 power > 0
4. 如果校验失败则返回错误

​

自定义计票函数

func NewPoACalculateVoteResultsAndVotingPowerFn(keeper) TallyFn {
    return func(ctx, proposal) (totalVotingPower, results) {
        // Iterate votes
        for vote in votes(proposal) {
            validator = keeper.GetValidatorByOperator(vote.voter)
            if validator == nil || validator.Power <= 0 {
                continue // Skip non-authorized validators
            }

            // Add validator power to total
            totalVotingPower += validator.Power

            // Apply vote weights
            for option, weight in vote.options {
                results[option] += validator.Power * weight
            }
        }
        return totalVotingPower, results
    }
}

​

治理参数

• MinDeposit：进入投票期所需的最小代币押金
• MaxDepositPeriod：达到最小押金要求的时间上限
• VotingPeriod：投票期时长
• Quorum：最低参与率（占总权重的比例）
• Threshold：提案通过所需的最低 Yes 比例（占非弃权票的比例）
• VetoThreshold：触发拒绝前允许的最高 NoWithVeto 比例

​

安全性考量

1. 验证者排他性：
   • 只有授权验证者（power > 0）可以参与
   • 防止未授权验证者通过垃圾注册发起女巫攻击
   • 确保治理真实代表共识参与者
2. 基于权重的投票：
   • 投票权重与共识权重绑定
   • 管理员控制权重分配，因此也会间接控制治理
3. 管理员对治理的控制：
   • 管理员可以随时修改验证者权重
   • 管理员可以通过调整权重有效控制治理结果
   • 应考虑使用多签管理员，或由治理来控制管理员变更
4. 防止提案垃圾信息：
   • 将提案提交限制为授权验证者可减少垃圾提案
   • 押金要求仍然适用
   • 验证者对提案质量承担声誉风险

​

与标准治理的对比

​

治理流程示例

1. 提交提案：
   • 验证者 A（power = 40）提交 MsgSubmitProposal
   • 钩子验证 A 是授权验证者
   • 提案进入押金期
2. 达到押金门槛：
   • 验证者 B（power = 30）存入押金
   • 验证者 C（power = 30）存入押金
   • 达到押金门槛 → 投票期开始
3. 投票：
   • 验证者 A：100% Yes（40 power → 40 张 Yes 票）
   • 验证者 B：60% Yes，40% No（30 power → 18 张 Yes，12 张 No）
   • 验证者 C：100% Abstain（30 power → 30 张 Abstain）
   • 总权重：100（全部授权验证者）
4. 计票：
   • 总投票权重：100（全部已投票）
   • Quorum：100/100 = 100% ✓（假设 Quorum 为 33%）
   • 结果：58 Yes，12 No，30 Abstain（非弃权票共 70）
   • Threshold：58/70 = 82.9% Yes ✓（假设 Threshold 为 50%）
   • 提案通过

​

Governance

​

Overview

​

Validator-Only Governance

1. AfterProposalSubmission: Only authorized validators can submit proposals
2. AfterProposalDeposit: Only authorized validators can deposit on proposals
3. AfterProposalVote: Only authorized validators can vote

• Registered in PoA module
• Power > 0
• Has valid operator address

• If non-validator attempts governance action → transaction fails
• If validator has power = 0 → transaction fails
• Error: “voter X is not an active PoA validator”

​

Voting Power

1. Vote Collection: System iterates all votes on a proposal
2. Validator Check: For each vote, verify voter is active PoA validator
3. Weight Calculation: Use validator’s power as voting weight
4. Weighted Options: Supports split votes, exactly like x/staking in traditional POS governance (e.g., 70% Yes, 30% Abstain)
5. Tally Results: Sum weighted votes by option

​

Vote Tallying Algorithm

• $V_i$ = voting power of validator $i$
• $P_i$ = validator power (consensus weight)

• $W_{i,o}$ = vote weight from validator $i$ for option $o$
• $w_{i,o}$ = weight assigned to option $o$ by validator $i$ (where $\sum_{o} w_{i,o} = 1$)

• $T_o$ = total votes for option $o$
• Sum over all validators who voted

​

Example

• $W_{A,Yes} = 100 \times 1.0 = 100$

• $W_{B,Yes} = 50 \times 0.6 = 30$
• $W_{B,No} = 50 \times 0.4 = 20$

• $T_{Yes} = 130$
• $T_{No} = 20$

​

Proposal Lifecycle

​

1. Proposal Submission

1. Standard governance validates the proposal content
2. AfterProposalSubmission hook is called
3. PoA module checks if proposer is authorized validator:
   • Look up proposer by operator address
   • Verify validator exists and has $P > 0$
   • If not active, reject with error
4. If valid, proposal enters deposit period

​

2. Deposit Period

1. Standard governance processes the deposit
2. AfterProposalDeposit hook is called
3. PoA module checks if depositor is authorized validator
4. If deposit threshold reached, proposal moves to voting period

​

3. Voting Period

1. Standard governance records the vote
2. AfterProposalVote hook is called
3. PoA module validates voter is authorized validator
4. If invalid, transaction fails

• Yes: Support the proposal
• No: Oppose the proposal
• NoWithVeto: Oppose and veto (can burn deposits if threshold met)
• Abstain: Participate in quorum without taking a position

​

4. Vote Tallying

1. Iterate all votes on the proposal
2. For each vote, look up the validator by voter address
3. If validator is not active ($P \leq 0$), skip the vote
4. Otherwise, use validator power as voting weight
5. For weighted votes, distribute power across options
6. Sum all weighted votes by option
7. Apply standard governance thresholds:
   • Quorum: Minimum participation percentage
   • Threshold: Minimum “Yes” percentage to pass
   • Veto: Maximum “NoWithVeto” percentage before rejection

​

Implementation Details

​

Governance Hooks

type GovHooks interface {
    AfterProposalSubmission(ctx, proposalID, depositorAddr)
    AfterProposalDeposit(ctx, proposalID, depositorAddr)
    AfterProposalVote(ctx, proposalID, voterAddr)
    // ... other hooks
}

1. Extracts the operator address from the context
2. Looks up the validator by operator address
3. Checks if validator exists and has power > 0
4. Returns error if validation fails

​

Custom Tally Function

func NewPoACalculateVoteResultsAndVotingPowerFn(keeper) TallyFn {
    return func(ctx, proposal) (totalVotingPower, results) {
        // Iterate votes
        for vote in votes(proposal) {
            validator = keeper.GetValidatorByOperator(vote.voter)
            if validator == nil || validator.Power <= 0 {
                continue // Skip non-authorized validators
            }

            // Add validator power to total
            totalVotingPower += validator.Power

            // Apply vote weights
            for option, weight in vote.options {
                results[option] += validator.Power * weight
            }
        }
        return totalVotingPower, results
    }
}

​

Governance Parameters

• MinDeposit: Minimum tokens required to enter voting period
• MaxDepositPeriod: Time limit for reaching minimum deposit
• VotingPeriod: Duration of the voting period
• Quorum: Minimum participation rate (fraction of total power)
• Threshold: Minimum “Yes” rate to pass (fraction of non-abstain votes)
• VetoThreshold: Maximum “NoWithVeto” rate before rejection

​

Security Considerations

1. Validator Exclusivity:
   • Only authorized validators (power > 0) can participate
   • Prevents sybil attacks through unauthorized validator spam
   • Ensures governance represents actual consensus participants
2. Power-Based Voting:
   • Voting weight tied to consensus power
   • Admin controls power distribution, thus controls governance indirectly
3. Admin Governance Control:
   • Admin can change validator power at any time
   • Admin can effectively control governance by adjusting power
   • Consider multi-sig admin or governance-controlled admin changes
4. Proposal Spam Prevention:
   • Restricting submissions to authorized validators reduces spam
   • Deposit requirements still apply
   • Validators have reputational stake in proposal quality

​

Comparison to Standard Governance

​

Example Governance Flow

1. Submit Proposal:
   • Validator A (power = 40) submits MsgSubmitProposal
   • Hook verifies A is authorized validator
   • Proposal enters deposit period
2. Reach Deposit:
   • Validator B (power = 30) deposits
   • Validator C (power = 30) deposits
   • Deposit threshold reached → voting period starts
3. Voting:
   • Validator A: 100% Yes (40 power → 40 Yes votes)
   • Validator B: 60% Yes, 40% No (30 power → 18 Yes, 12 No)
   • Validator C: 100% Abstain (30 power → 30 Abstain)
   • Total power: 100 (all authorized validators)
4. Tally:
   • Total voting power: 100 (all voted)
   • Quorum: 100/100 = 100% ✓ (assuming 33% quorum)
   • Results: 58 Yes, 12 No, 30 Abstain (out of 70 non-abstain)
   • Threshold: 58/70 = 82.9% Yes ✓ (assuming 50% threshold)
   • Proposal passes