MAPO Developer Docs
LearnDevelopRunWhitePaperBRC-201
English
English
  • Overview
  • Learn
    • About MAP Protocol
      • Background
      • Introduction of MAP Protocol
      • History of MAP Protocol
    • Comparison with other cross-chain models
      • MAP Protocol vs Cosmos & Polkadot
      • MAP vs other cross-chain solutions without relay chain
    • Technical Mechanism
      • MAP Protocol's Technical Mechanism
      • Three-layer Architecture
      • MAP Protocol Layer
        • Concept
        • Isomorphism with All Chains
        • Verification & Maintenance Network
      • MAP Omnichain Service (MOS) Layer
      • MAPO Application Layer
      • Peer-to-Peer Cross-chain Technology with ZK-enabled Light Clients
      • Interact with Bitcoin
    • Gas Fee Model
    • DAO
    • Construction of MAP Protocol
      • Developers
      • Validators
      • Maintainers
      • Messengers
      • Liquidity providers
      • End users
    • Tokenomics
    • Purchase $MAP
  • Develop
    • MAP Relay Chain
      • Getting Started
        • Build
        • Make Private Chain
        • How To Vote
        • How To Withdraw
        • Integrate an Exchange
        • Integrate MAP Relay Chain with EVM-Compatible Chains
      • Consensus
        • Overview
        • Proof-of-Stake
        • Validator
          • Validator
          • Locked MAP
        • Election
        • Rewards
        • Aggregated Seal
      • Contracts
        • Precompiled Contracts
        • Genesis Contracts
          • ABI
            • AccountsABI
            • ElectionABI
            • EpochRewardsABI
            • LockedGoldABI
            • ValidatorsABI
          • Deploy
      • Marker
        • Genesis
        • Validator
        • Vote
        • ContractOwner
        • Common
      • Account-Abstraction
    • Light Client
      • Verification based on Light Client
      • MAPO Light Client
        • EVM Chains
        • Near
      • Light Clients
        • Client Manager
        • BNB Smart Chain
        • Near Protocol
        • Polygon(Matic)
        • Ethereum 2.0
        • Klaytn
        • Conflux)
      • Maintainer
    • MAP Omnichain Service (MOS)
      • MOS Message Guides
        • How It Works
        • How To Use
        • EVM Chains Contract
      • MCS Guides
        • How It Works
        • How To Use
          • How To On Evm Chains
          • How To On Near Protocol
        • Relay Chain Contract
        • EVM Chains Contract
        • Near Protocol Contract
      • Messenger
      • API
    • OmniChain Examples
      • OmniApp
      • OmniDictionary
    • API & SDK
      • Butter SDK
      • Atlas JSON RPC
      • Atlas Consensus API
      • MAP Scan API
    • Connected Chains and Corresponding Addresses
  • Run
    • How To Become A New Validator
    • How To Become A New Validator[advanced]
    • Withdraw
Powered by GitBook
On this page
  • Proof-of-Stake
  • Validators
  • Staking Requirements
  • About election
  • Validator number and Reward

Was this helpful?

  1. Develop
  2. MAP Relay Chain
  3. Consensus

Proof-of-Stake

Proof-of-Stake

MAP Relay Chain(Atlas) is a proof-of-stake blockchain. In comparison to Proof of Work systems like Bitcoin and Ethereum, this eliminates the negative environmental impact and means that users can make transactions that are cheaper, faster, and whose outcome cannot be changed once complete.

MAP Relay Chain implements a Istanbul Byzantine Fault Tolerant (IBFT) consensus algorithm in which a well-defined set of validator nodes broadcast signed messages between themselves in a sequence of steps to reach agreement even when up to a third of the total nodes are offline, faulty or malicious. When a quorum of validators have reached agreement, that decision is final.

Validators

Validators gather transactions received from other nodes and execute any associated smart contracts to form new blocks, then participate in a Byzantine Fault Tolerant (BFT) consensus protocol to advance the state of the network. Since BFT protocols can scale only to a few hundred participants, and can tolerate at most a third of the participants acting maliciously, a proof-of-stake mechanism admits only a limited set of nodes to this role.

Staking Requirements

Atlas uses a proof-of-stake consensus mechanism, which requires Validators to have locked MAPO to participate in block production. The current requirement is 1,000,000 MAPO to register a Validator.

About election

The Election contract is called from the IBFT block finalization code to select the validators for the following epoch. The contract maintains a sorted list of the Locked MAPO voting (either pending or activated) for each Validator. The active validator set is updated by running an election in the final block of each epoch, after processing transactions and Epoch Rewards.

There is a minimum target and a maximum cap on the number of active validators that may be selected. If the minimum target is not reached, the election aborts and no change is made to the validator set this epoch.

Validator number and Reward

The participators make these decisions by locking MAPO and voting for Validator. Validator elections are held every epoch (approximately once per three day). The protocol elects a maximum of 100 Validators. At each epoch, every elected Validator must be re-elected to continue. Validators are selected in proportion to votes received for each Validator.

If you hold MAPO, or are a beneficiary of a ReleaseMAPO contract that allows voting, you can vote for validator. A single account can split their LockedMAPO balance to have outstanding votes between 3 validator and 10 validator. MAPO that you lock and use to vote for a validator receives epoch rewards every epoch (approximately every day) once the community passes a governance proposal enabling rewards.

PreviousOverviewNextValidator

Last updated 2 years ago

Was this helpful?