脉波开发者文档
  • 脉波开发者文档
  • 基础主題
    • 脉波简介
    • MAPO币
    • 全链去中心化应用
    • 全链应用与单链或多链应用的区别
    • 第三方信任跨链与点对点跨链方案区别
    • 比特币二层
      • brc-201
    • 预言机 Oracle
      • Supra: MAP Protocol 上的去中心化预言机
    • 帐户
    • 交易
    • 区块
    • MPT树
    • RLP编码
    • Gas费用
    • 消息跨链
    • 轻客户端
      • MAPO轻客户端
    • 全链开发组件层MOS
      • MOS接口和功能
      • MOS的部署
      • Messenger
    • 中继链(atlas)
      • 节点架构
        • 中继链(atlas)架构 - 区块和交易结构
        • 创世
          • 创世配置 - 介绍创世配置文件
          • 创世合约
            • ABI
              • Accounts
              • Election
              • EpochRewards
              • LockedGold
              • Validators
            • 地址
            • 部署
        • 预编译合约 - 支持的预编译合约
        • 协议
          • Proof of Stake
          • 共识
          • 选举
          • 奖励
          • 治理
      • 部署节点 - 包括公共RPC节点
        • 运行节点(中继链)
        • 归档节点(中继链)
        • 引导节点(中继链)
        • 验证节点 (中继链)
        • RPC节点(中继链)
      • Marker工具 - atlas的简易客户端工具
        • Genesis
        • Validator
        • Vote
        • Common
      • 搭建私有网络
      • 公共网络服务信息
        • 公共网络
      • 示例
        • 如何成为一个 Validator 并加入到 Atlas 网络中
        • 如何成为一个 Validator 并加入到 Atlas 网络中[高级]
    • Compass(maintainer,messenger)
      • Compass - 架构及模块说明
      • Compass配置参数
      • Compass环境与部署
      • Compass二次开发 - 基于compass定义自己的路由服务
  • MAPO技术堆栈
    • 堆栈
      • 接入的链
    • EVM兼容
      • 智能合约语言
      • 智能合约结构
      • 智能合约库
      • 编译智能合约
      • 测试智能合约
      • 部署智能合约
      • 可组合性
      • 智能合约安全性
      • 智能合约形式化验证
      • 开发框架
      • 开发网络
    • 实现跨链互通
      • EVM兼容链的跨链互通
        • 轻客户端验证
        • 轻客户端状态更新
        • MOS层
      • 非EVM兼容链的跨链互通
        • 轻客户端验证
        • 轻客户端状态更新
        • MOS层
    • 如何开发全链应用
    • 轻客户端信息
    • SDK/API - mapo支持的API
      • MOS接口
      • 轻客户端接口
      • 中继链RPC
        • json-rpc
          • atlas json rpc
          • atlas consensus rpc
        • javaScript sdk
        • go-sdk
      • 后端API
        • 浏览器API
        • 数据统计与分析API
  • 零知识证明(zk)
    • 零知识证明
Powered by GitBook
On this page
  • 什么是 epoch 奖励?
  • 奖励发放
  • 奖励&赎回
  • 扩展
  • 执行
  • 相关主题
  1. 基础主題
  2. 中继链(atlas)
  3. 节点架构
  4. 协议

奖励

什么是 epoch 奖励?

Epoch Rewards 类似于其他区块链中常见的区块奖励概念,在区块产生时铸造和分配新的 MAPO ,以创建多种激励措施。

Epoch 奖励在该 epoch 的最后一个区块中支付,用于:

  1. 为验证者分配奖励

  2. 向投票选出验证人的验证人的锁定 MAP 持有者分发奖励

  3. 向社区基金支付协议基础设施补助金

每个 epoch 都会获得固定的奖励。前 2 年, EpochReward = 833,333 MAP 。

奖励发放

支付金额是在每个时期结束时通过三步过程确定的。

第一步

第一步,社区基金将获得固定比例的奖励 CommunityFundReward = CommunityFundMultiplier*EpochReward CommunityFundMultiplier 默认值 = 0。

第二步

第二步,我们将统计每个验证人的签名数量,并将其转换为分数(0 <= Score <= 1),最终参与奖励的计算。 如果验证人未能履行职责,将通过惩罚机制进行惩罚。 因此每个验证者将获得奖励:

  • ValidatorReceived = ( EpochReward - CommunityFundReward ) * StakingWeight * OwnActiveVotes / TotalActiveVotes +

  • WorkWeight * OwnScore / TotalScores 。

  • StakingWeight 验证人的质押权重(0 < StakeWeight <= 1,默认值为1)

  • WorkWeight 验证人的工作权重(WorkWeight = 1 - StakeWeight)。

  • OwnActiveVotes 当前验证人激活的投票数。

  • TotalActiveVotes 所有验证者收到的活跃投票。

  • OwnScore 当前验证者获得的分数。你的节点在线时间会直接影响这个参数。如果您的此参数小于其他验证器,您将受到惩罚,这将大幅削减您的奖励。 ( 0 <= OwnScore <= 1)

  • TotalScores 所有验证者的分数总和。

分数由以下公式计算:

  • NewScore = UptimeScore * AdjustmentSpeed + OldScore * (1 - AdjustmentSpeed )

  • UptimeScore 这是 TotalMonitoredBlocks 完成的工作分数。

    • TotalMonitoredBlocks 是我们监控纪元正常运行时间的区块总数。

    • TotalMonitoredBlocks 取值范围为 [EpochFirstBlock + lookbackWindowSize(defult = 12) -1,EpochLastBlock - BlocksToSkipAtEpochEnd(defult = 2)]

    • lookbackWindowSize 关于lookbackWindow的固定值,检查验证器是否在固定间隔内签名。

    • 如果您成功登录 [NowBlockNumber-lookbackWindow ,NowBlockNumber] ,我们将认为您当前的区块工作成功。

    • BlocksToSkipAtEpochEnd 表示从纪元结束开始在监控窗口上跳过的块数。目前我们跳过区块:

      • lastBlock => parentSeal 位于下一个 epoch 的 firstBlock 上

      • lastBlock - 1 =>parentSeal 位于 lastBlockOfEpoch 上,但 validatorScore 是在更新分数之前使用 lastBlockOfEpoch 计算的 (lastBlock-1可以算,但是实现起来比较困难)

    • 关于要监视的第一个块: 当前的 lookbackWindow 跨越 epoch 边界时,我们无法监控正常运行时间。 因此,要监视的第一个块是从 firstBlockOfEpoch 开始的回溯窗口的最后一个块。 所以 UptimeScore = SignedBlocks / TotalMonitoredBlocks 。 SignedBlocks 验证者签名的区块数量,每次生成区块时都会检查该数量。 首先,检查当前块是否在 BlocksToSkipAtEpochEnd 中。 其次,检查当前区块审核期是否签署。如果存在则视为签名成功 如果第一步和第二步成功 SignedBlocks 将加 1。 AdjustmentSpeed 调整因子。这种方式将鼓励验证器稳定。('AdjustmentSpeed' 默认值为 0.2)。 OldScore 这是该验证人最后一个epoch的得分。(第一个分配epoch奖励OldScore为0)

第三步

第三步,由于验证者会将奖励分发给投票者,因此实际上验证者将收到奖励:

ValidatorActualReceived = ValidatorReceived * Commission * OwnScore 。 Commission 是验证者按比例从 ValidatorReceived 中提取的比例值。

验证者的投票者将收到:

  • VotersReward = ValidatorReceived - ValidatorActualReceived 。 这些奖励( VotersReward )将返回投票池。这个操作相当于增加了每个选民的票数。投票者从投票池中抽取选票并获得相应奖励。 每个投票者的奖励将根据投票者与验证者的投票比例获得。

奖励&赎回

扩展

案例一:验证人在服务期间被注销。

在这种情况下,我们在奖励时不会考虑他,其余验证者将平均分享他的奖励。

案例二:验证者重新注册。

当验证人被注销后,投票者仍然可以根据自己的意愿取消对注销验证人的投票。 如果选民不撤回选票,选民的选票将保留在投票区,等待验证人再次登记,这些票将再次返回给验证人。

执行

相关主题

Previous选举Next治理

Last updated 1 year ago

目前每一个 epoch 的最后一个区块都会计算并发放奖励,奖励会直接增加到你对某个 validator 的活跃投票数量上。 如果你想将发放的奖励提取到你的账号,你需要进行赎回,有关赎回的具体步骤请参考

合约管理计算 epoch 奖励。

这里
EpochRewards
选举