MAPO Developer Docs
  • MAPO Developer Docs
  • Base
    • MAPO Introduction
    • MAPO token
    • Omnichain DAPP
    • Differences Between Omnichain Applications and Single or Multi-Chain Applications
    • Differences Between Third-Party Trusted Cross-Chain and Peer-to-Peer Cross-Chain Solutions
    • BTC layer2
      • brc-201
    • Oracle
      • Supra: Decentralized Oracle on MAP Protocol
    • Account
    • Transactions
    • block
    • MPT tree
    • RLP
    • Gas fee
    • Cross Chain Message
    • light client
      • MAPO light client
    • MOS
      • MOS interface and functions
      • deploy MOS
      • Messenger
    • map-relay-chain(atlas)
      • atlas architecture
        • atlas architecture
        • atlas genesis
          • genesis config
          • genesis contract
            • ABI
              • Accounts
              • Election
              • EpochRewards
              • LockedGold
              • Validators
            • address
            • deploy
        • precompile-contract
        • protocol
          • Proof of Stake
          • consensus
          • election
          • rewards
          • governance
      • deploy atlas
        • run atlas
        • run atlas(archive)
        • run atlas(bootnodes)
        • run atlas(validator)
        • run atlas(RPC)
      • Marker tool
        • Genesis
        • Validator
        • Vote
        • Common
      • make private network(atlas)
      • public service
        • public network
      • example
        • how-to-vote
        • how-to-withdraw
        • how-to-become-a-new-validator
        • how-to-become-a-new-validator(advanced)
    • Compass(maintainer,messenger)
      • Compass - arch and model
      • Compass - config
      • Compass - deploy
      • Compass secondary development - define your own routing service based on compass
  • MAPO Stack
    • stack
      • Connected Chains and Corresponding Addresses
    • Compatible-EVM
      • Smart Contracts Language
      • Smart Contracts Anatomy
      • Smart Contracts Libraries
      • Smart Contracts Compile
      • Smart Contracts Testing
      • Smart Contracts Deploy
      • Smart Contracts Composability
      • Smart Contracts Security
      • Formal-Verification
      • Frameworks
      • dev-network
    • MAPO Implement Cross-chain Interoperability
      • integration of MAP with EVM-Compatible Chains
        • light client verify
        • light client update state
        • MOS
      • integration of MAP with TON Network
      • integration of MAP with Non-EVM-Compatible Chains
        • light client verify
        • light client update state
        • MOS
    • How to develop cross-chain applications
    • light client address
    • SDK/API
      • MOS interface
      • Light client interface
      • Atlas RPC
        • json-rpc
          • atlas json rpc
          • atlas consensus rpc
        • javaScript sdk
        • go-sdk
      • Backend API
        • SCAN API
  • Zero-Knowledge Proof
    • zk proof
Powered by GitBook
On this page
  • connect to a bootnode
  • run a bootnode
  • available bootnodes
  1. Base
  2. map-relay-chain(atlas)
  3. deploy atlas

run atlas(bootnodes)

Previousrun atlas(archive)Nextrun atlas(validator)

Last updated 1 year ago

When a new node joins the Atlas network it needs to connect to nodes that are already on the network in order to then discover new peers. These entry points into the Ethereum network are called bootnodes. Clients usually have a list of bootnodes hardcoded into them. These bootnodes are typically run by the Ethereum Foundation's devops team or client teams themselves. Note that bootnodes are not the same as static nodes. Static nodes are called over and over again, whereas bootnodes are only called upon if there are not enough peers to connect to and a node needs to bootstrap some new connections.

connect to a bootnode

Atlas clients have a list of bootnodes build in, but you might also want to run your own bootnode, or use one that is not part of the client's hardcoded list. In this case, you can specify them when starting your client, as follows:

atlas --bootnodes "enode://<node ID>@<IP address>:<port>

run a bootnode

Bootnodes are full nodes that are not behind a NAT (Network Address Translation(opens in a new tab)). Every full node can act as a bootnode as long as it is publicly available.

When you start up a node it should log your enode, which is a public identifier that others can use to connect to your node.

The enode is usually regenerated on every restart, so make sure to look at your client's documentation on how to generate a persistent enode for your bootnode.

In order to be a good bootnode it's a good idea to increase the maximum number of peers that can connect to it. Running a bootnode with many peers will increase the bandwidth requirement significantly.

available bootnodes

A list of builtin bootnodes within atlas client can be found

There are other lists of bootnodes maintained by volunteers available. Please make sure to always include at least one official bootnode, otherwise you could be eclipse attacked.

here