脉波开发者文档
  • 脉波开发者文档
  • 基础主題
    • 脉波简介
    • 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
  • 什么是 atlas 治理
  • 提案流程
  • 阶段概述
  • 提案
  • 批准
  • 公投
  • 执行
  1. 基础主題
  2. 中继链(atlas)
  3. 节点架构
  4. 协议

治理

什么是 atlas 治理

atlas 使用正式的链上治理机制来管理和升级协议,例如升级智能合约、添加新的稳定货币或修改储备目标资产配置。所有变更必须得到 MAPO 持有者的同意。法定人数阈值模型用于确定提案通过所需的票数。

提案流程

更改通过 Atlas Governance 智能合约进行管理。该合约充当“所有者”,对其他协议智能合约进行修改。此类智能合约被称为可治理的。 Governance 合约本身是可治理的,并归其自身所有。

变更过程分以下几个阶段进行:

  1. 提议 (Proposal)

  2. 审批 (Approval)

  3. 公投 (Referendum)

  4. 执行 (Execution)

阶段概述

每个提案都从提案队列开始,在那里它可能会收到赞成票,以便相对于其他排队的提案在队列中向前移动。提案作者应该努力寻找社区成员来投票支持 他们的提案(提案者也可以投票支持他们的提案)。每天最多有来自队列顶部的三个提案自动出队并提升到审批阶段。任何在队列中保留 4 周的提案都将过期。

  • 审批持续 1 天(24 小时),在此期间提案必须得到审批人的批准。获得批准的提案将进入公投阶段。

  • 公投持续 5 天,在此期间,Locked MAPO 的所有者对该提案投赞成票或反对票。满足必要法定人数的提案将被提升到执行阶段。

  • 执行最多持续 3 天,在此期间任何人都可以触发提案的执行。

提案

任何用户都可以向 Governance 智能合约提交提案以及少量 MAPO 押金。这笔押金是为了避免垃圾提案而需要的,如果提案进入批准阶段, 押金将退还给提案人。提案由交易列表和描述 URL 组成,选民可以在其中获取有关提案的更多信息。提案中的交易数据包括目标地址、数据和价值。 如果提案通过,包含的交易将由 Governance 合约执行。

提交的提案将添加到提案队列中。当提案在此队列中时,选民可以使用其锁定的 MAPO 来投票支持该提案。每天一次,根据支持它们的锁定 MAPO 的权重,排名前三的提案将出列并进入审批阶段。请注意,如果队列中的提案少于三个,则即使没有赞成票,所有提案也可能会出列。 如果提案排队时间超过 4 周,提案就会过期并且押金将被没收。

批准

每天排在队列前面的前三名提案都会被弹出并进入审批阶段。此时,原始提议者有资格收回其锁定的 MAPO 押金。在此阶段,提案需要得到审批人的批准。 审批阶段持续 1 天,如果提案在此窗口内未获得批准,则视为已过期,不会进入“公投”阶段。

公投

批准阶段结束后,批准的提案将进入公投阶段。任何用户都可以对这些提案投赞成、反对或弃权票。他们投票的权重由他们锁定的 MAPO 的权重决定。 持续五天的公投阶段结束后,每个提案都会根据得票数和相应的传递函数参数标记为通过或失败。

为了使提案获得通过,它必须满足参与和同意的最低门槛:

  • 参与度(Participation)是支持一项提案通过的需要最少锁定的 MAPO。它的存在是为了防止提案在参与度很低的情况下通过。参与度( Participation)要求是根据参与度基线的可治理部分计算的,参与度基线是过去治理提案的最终参与度的指数移动平均值。

  • 一致度(Agreement)是指投票中必须投“赞成”票才能通过提案的部分。每个合约和功能都可以定义所需的一致度级别,并且提案所需的一致度是其组成交易中的最大要求。

执行

从公投阶段进入到执行阶段的提案可以由任何人执行,触发一个带有在提案中定义的参数的 call 操作码,调用来自于 governance 合约。这个阶段的提案在三天后会过期。

Previous奖励Next部署节点 - 包括公共RPC节点

Last updated 1 year ago