Developer Resources
Block ExplorerGitHubRun a NodeMigration GuideETN Testnet Faucet
  • Overview
  • Foundational topics
    • Intro to the Electroneum Smart Chain
    • Intro to ETN
    • Intro to dapps
    • Web2 vs Web3
    • Accounts
    • Transactions
    • Blocks
    • Electroneum Virtual Machine (EVM)
      • Opcodes
    • Gas and Fees
    • Nodes and clients
    • Networks
    • Consensus mechanisms
      • IBFT
  • Electroneum Stack
    • Intro to the stack
    • Smart contracts
    • Development networks
    • Development frameworks
    • Electroneum client APIs
      • JavaScript APIs
      • JSON-RPC
    • Storage
    • Integrated Development Environments (IDEs)
    • Metamask
  • Advanced
    • Bridges
    • Standards
      • Token standards
        • ERC-20 Fungible Tokens
        • ERC-721 NFTs
    • Oracles
    • Networking layer
      • Network addresses
    • Data structures and encoding
      • Patricia Merkle Trie
      • Recursive-length prefix (RLP)
      • Web3 secret storage definition
  • Design fundamentals
    • Intro to design and UX
  • ETN-SC Client
    • Getting started
      • Introduction
      • Hardware requirements
      • Instaling ETN-SC
    • Fundamentals
      • Command-line options
      • Security
      • Sync-modes
      • Account management
      • Databases
      • Backup & restore
      • Logs
      • Connecting to peers
      • Pruning
      • Private networks
      • Config files
      • Light client
    • Interacting with ETN-SC
      • JSON-RPC Server
        • Batch requests
        • Real-time events
      • JSON-RPC Namespaces
        • admin
        • clique
        • debug
        • eth
        • istanbul
        • les
        • miner
        • net
        • personal
        • txpool
      • JS Console
      • JS Console 2: Contracts
      • GraphQL Server
    • Developers
      • Introduction
      • Dapp developers
        • Dev mode
        • Go API
        • Go Account Management
        • Go Contract Bindings
      • EVM tracing
        • Introduction
        • Basic traces
        • Built-in tracers
        • Custom EVM tracer
        • Tutorial for JavaScript tracing
      • ETN-SC developer
        • Developer guide
        • Disclosures
        • DNS discovery setup guide
        • Code review guidelines
      • Contributing
    • Monitoring
      • Creating Dashboards
      • Understanding Dashboards
      • Ethstats
      • Metrics
    • Tools
      • Clef
        • Introduction
        • APIs
        • Rules
        • Setup
        • Datatypes
        • Tutorial
        • Clique-signing
      • abigen
      • devp2p
    • FAQs
  • Migration to Smart Chain
    • Overview
    • How to Migrate
      • ETN Online Wallets
      • Paper Wallets
      • CLI Wallet Users
      • Exchange Holders
      • Exchanges
    • Bridge Smart Contract
  • Misc. Guides
    • Set up Ledger + Metamask
  • MY.ELECTRONEUM.COM
    • Vendor API
Powered by GitBook
On this page
  • Finding peers
  • Connectivity problems
  • Checking Connectivity
  • Custom Networks
  • Static nodes
  • Peer limit
  • Trusted nodes
  • Summary

Was this helpful?

  1. ETN-SC Client
  2. Fundamentals

Connecting to peers

PreviousLogsNextPruning

Last updated 1 year ago

Was this helpful?

The default behaviour for Etn-sc is to connect to Electroneum Mainnet. However, Etn-sc can also connect to public testnets, and . For convenience, the the public testnet with long term support have their own command line flag. Etn-sc can connect to the testnet simply by passing:

  • --testnet

Note: Network selection is not persisted from a config file. To connect to a pre-defined network you must always enable it explicitly, even when using the --config flag to load other configuration values. For example:

# Generate desired config file. You must specify testnet here.
etn-sc --testnet --syncmode "full" ... dumpconfig > testnet.toml

# Start etn-sc with given config file. Here too the testnet must be specified.
etn-sc --testnet --config testnet.toml

Finding peers

Etn-sc continuously attempts to connect to other nodes on the network until it has enough peers. If UPnP (Universal Plug and Play) is enabled at the router or Electroneum is run on an Internet-facing server, it will also accept connections from other nodes. Etn-sc finds peers using the . In the discovery protocol, nodes exchange connectivity details and then establish sessions (). If the nodes support compatible sub-protocols they can start exchanging Electroneum data .

A new node entering the network for the first time gets introduced to a set of peers by a bootstrap node ("bootnode") whose sole purpose is to connect new nodes to peers. The endpoints for these bootnodes are hardcoded into Etn-sc, but they can also be specified by providing the --bootnode flag along with comma-separated bootnode addresses in the form of on startup. For example:

etn-sc --bootnodes enode://pubkey1@ip1:port1,enode://pubkey2@ip2:port2,enode://pubkey3@ip3:port3

There are scenarios where disabling the discovery process is useful, for example for running a local test node or an experimental test network with known, fixed nodes. This can be achieved by passing the --nodiscover flag to Etn-sc at startup.

Connectivity problems

There are occasions when Etn-sc simply fails to connect to peers. The common reasons for this are:

  • Local time might be incorrect. An accurate clock is required to participate in the Electroneum network. The local clock can be resynchronized using commands such as sudo ntpdate -s time.nist.gov (this will vary depending on operating system).

  • Some firewall configurations can prohibit UDP traffic. The static nodes feature or admin.addPeer() on the console can be used to configure connections manually.

  • Running Etn-sc in often leads to connectivity issues because there are few nodes running light servers. There is no easy fix for this except to switch Etn-sc out of light mode.

  • The public test network Etn-sc is connecting to might be deprecated or have a low number of active nodes that are hard to find. In this case, the best action is to switch to an alternative test network.

Checking Connectivity

> net.listening
true

> net.peerCount
4

Functions in the admin module provide more information about the connected peers, including their IP address, port number, supported protocols etc. Calling admin.peers returns this information for all connected peers.

> admin.peers
[{
    caps: ["etn/66", "etn-istanbul/100", "etn-snap/1"],
    enode: "enode://619bf86ec25c3193b44f4ba2653f2d14edfef95157d4ab460e2896be2a43656236c7bf9b16b9d9c09d73400da487c3dd819a7a4a2629fc3bf634dddd2450f335@13.215.184.67:30303",
    id: "200f0c20d2b1d6ce11a6f7a74aa8ae5a37a4c52b345b82b816d380740992b10e",
    name: "etn-sc/v0.1.0-unstable-3bc1d078-20230105/linux-amd64/go1.20.4",
    network: {
      inbound: false,
      localAddress: "192.168.3.4:56831",
      remoteAddress: "13.215.184.67:30303",
      static: false,
      trusted: false
    },
    protocols: {
      etn: {
        difficulty: 2741015,
        head: "0xe22ca92c0724e9fa86f9d3b8d0aa07651d8dc24f194dc708271e965295d9b5cf",
        version: 66
      },
      etn-istanbul: "handshake",
      etn-snap: {
        version: 1
      }
    }
}, {
    caps: ["etn/66", "etn-istanbul/100", "etn-snap/1"],
    enode: "enode://50b9f7d46e4c84a1b76be778eadd69f7d969ce45772fcbaaf264be8f7f986d030fc26e113b138980727b8c134b5e08321917e07fa6245ae357e23d51db0678bf@13.250.53.55:30303",
    id: "2682531c8401443ad9ffe472c21ee98b5a90a6a45aba37fa5eddf90f5e8e1816",
    name: "etn-sc/v0.1.0-unstable-7af82b5d-20221209/linux-amd64/go1.19.2",
    network: {
      inbound: false,
      localAddress: "192.168.3.4:56843",
      remoteAddress: "13.250.53.55:30303",
      static: false,
      trusted: false
    },
    protocols: {
      etn: {
        difficulty: 2741016,
        head: "0xe1b396807e2d72dc605961c4e5da3d415fe67b301d652249784b487b8d9fa09c",
        version: 66
      },
      etn-istanbul: "handshake",
      etn-snap: {
        version: 1
      }
    }
}]

The admin module also includes functions for gathering information about the local node rather than its peers. For example, admin.nodeInfo returns the name and connectivity details for the local node.

> admin.nodeInfo
{
  enode: "enode://666e25ebd14912ab79dd9bdf547bdb17981ab328f79517b0f8191109daaeef7c54f4dead8fb7777726dd7a599cedc16cf006961716be181ee37efddb47ef0383@127.0.0.1:41300",
  enr: "enr:-Ke4QCFtS45WhyN1pDaOEevnapt1-vwQxMY41VFxe4CCJw_wdHZtQeNJTv4QicyHF2UkmVxtCHucKFQslwqn-VPRiDyGAYlqJvHyg2V0bsfGhDA3d5GAiGV0bi1zbmFwwIJpZIJ2NIJpcIR_AAABiXNlY3AyNTZrMaEDZm4l69FJEqt53ZvfVHvbF5gasyj3lRew-BkRCdqu73yDdGNwgqFUg3VkcIKhVA",
  id: "695cfb779e4be5821660f37aa71299ee4c91bf07d84a51620f54379de83a5ba5",
  ip: "127.0.0.1",
  listenAddr: "[::]:41300",
  name: "etn-sc/v1.0.0-stable-5be45479/darwin-arm64/go1.20.6",
  ports: {
    discovery: 41300,
    listener: 41300
  },
  protocols: {
    etn: {
      config: {
        berlinBlock: 0,
        byzantiumBlock: 0,
        chainId: 5201420,
        constantinopleBlock: 0,
        daoForkSupport: true,
        eip150Block: 0,
        eip150Hash: "0x0000000000000000000000000000000000000000000000000000000000000000",
        eip155Block: 0,
        eip158Block: 0,
        genesisETN: 2e+27,
        homesteadBlock: 0,
        ibft: {...},
        istanbulBlock: 0,
        londonBlock: 0,
        petersburgBlock: 0
      },
      difficulty: 2741028,
      genesis: "0xcf1b6615aa11a133442a21cc1bf9fbe935fd146f74123ba4f3f0e107362c3eb4",
      head: "0x8702ef01b6bb8ada23f193822246ba1f4f3a89c1e87027fda4df272e0f26452b",
      network: 5201420
    },
    etn-istanbul: {
      config: {
        berlinBlock: 0,
        byzantiumBlock: 0,
        chainId: 5201420,
        constantinopleBlock: 0,
        daoForkSupport: true,
        eip150Block: 0,
        eip150Hash: "0x0000000000000000000000000000000000000000000000000000000000000000",
        eip155Block: 0,
        eip158Block: 0,
        genesisETN: 2e+27,
        homesteadBlock: 0,
        ibft: {...},
        istanbulBlock: 0,
        londonBlock: 0,
        petersburgBlock: 0
      },
      consensus: "IBFT",
      difficulty: 2741028,
      genesis: "0xcf1b6615aa11a133442a21cc1bf9fbe935fd146f74123ba4f3f0e107362c3eb4",
      head: "0x8702ef01b6bb8ada23f193822246ba1f4f3a89c1e87027fda4df272e0f26452b",
      network: 5201420
    },
    etn-snap: {}
  }
}

Custom Networks

Static nodes

Etn-sc also supports static nodes. Static nodes are specific peers that are always connected to. Etn-sc reconnects to these peers automatically when it is restarted. Specific nodes are defined to be static nodes by adding their enode addresses to a config file. The easiest way to create this config file is to run:

etn-sc --datadir <datadir> dumpconfig > config.toml

This will create config.toml in the current directory. The enode addresses for static nodes can then be added as a list to the StaticNodes field of the Node.P2P section in config.toml. When Etn-sc is started, pass --config config.toml. The relevant line in config.toml looks as follows:

StaticNodes = ["enode://f4642fa65af50cfdea8fa7414a5def7bb7991478b768e296f5e4a54e8b995de102e0ceae2e826f293c481b5325f89be6d207b003382e18a8ecba66fbaf6416c0@33.4.2.1:30303"]

Static nodes can also be added at runtime in the Javascript console by passing an enode address to admin.addPeer():

admin.addPeer(
  'enode://f4642fa65af50cfdea8fa7414a5def7bb7991478b768e296f5e4a54e8b995de102e0ceae2e826f293c481b5325f89be6d207b003382e18a8ecba66fbaf6416c0@33.4.2.1:30303'
);

Peer limit

It is sometimes desirable to cap the number of peers Etn-sc will connect to in order to limit on the computational and bandwidth cost associated with running a node. By default, the limit is 50 peers, however, this can be updated by passing a value to --maxpeers:

etn-sc <otherflags> --maxpeers 15

Trusted nodes

Trusted nodes can be added to config.toml in the same way as for static nodes. Add the trusted node's enode address to the TrustedNodes field in config.toml before starting Etn-sc with --config config.toml.

Nodes can be added using the admin.addTrustedPeer() call in the Javascript console and removed using admin.removeTrustedPeer() call.

admin.addTrustedPeer(
  'enode://f4642fa65af50cfdea8fa7414a5def7bb7991478b768e296f5e4a54e8b995de102e0ceae2e826f293c481b5325f89be6d207b003382e18a8ecba66fbaf6416c0@33.4.2.1:30303'
);

Summary

Etn-sc connects to Electroneum Mainnet by default. However, this behaviour can be changed using combinations of command line flags and files. This page has described the various options available for connecting a Etn-sc node to the Electroneum Smart Chain, public testnet and private networks.

The net module has two attributes that enable checking node connectivity from the . These are net.listening which reports whether the Etn-sc node is listening for inbound requests, and peerCount which returns the number of active peers the node is connected to.

It is often useful for developers to connect to private test networks rather than public testnets or Electroneum mainnet. These sandbox environments allow block creation without competing against other miners, easy minting of test ether and give freedom to break things without real-world consequences. A private network is started by providing a value to --networkid that is not used by any other existing public network () and creating a custom genesis.json file. Detailed instructions for this are available on the .

Ensure the other lines in config.toml are also set correctly before starting Etn-sc, as passing --config instructs Etn-sc to get its configuration values from this file. An example of a complete config.toml file can be found .

interactive Javascript console
Chainlist
Private Networks page
here
private networks
local testnets
RLPx
light mode
enodes
discovery protocol
on the wire