Best Practice: Role of EOS Node

in blockchain •  4 months ago


When EOS9CAT prepared the EOS nodes before the EOS main net launch day, we noticed that the EOS node probably could be separated into different roles not only on the main net but also in the on-premise infrastructure.

From the EOS main net perspective, the role of the node is divided into "Producing Node" and "Non-Producing Node".

Do a simple search, below is the definition of the Non-Producing Node from the EOSIO Wiki Page - Glossary.

Non-Producing Node

A full node running nodeos that is only watching and verifying for itself each block, and maintaining its own local full copy of the blockchain. A non-producing node that is in the "standby pool" can, through the process of being voted in, become a producing node. A producing node, if voted out, will become a non-producing node. Most non-producing nodes are not in the "standby pool".

So the Producing Node is the opposite of the Non-Producing Node. The Producing Node definitely is voted in and producing the blocks. However, it doesn't mean the Non-Producing Node is not capable of producing the blocks. It means that the Non-Producing Node is a full node and is capable of doing so on demand. Whenever the chain needs to replace an existing Block Producer with a new one, the new one is drawn from the standby pool.

As you may notice that we have another terminology - full node. What does "full node" mean? Obviously, it means the node has the full functionality. Then what is the "full functionality"? This is what we are going to talk about today.


EOS9CAT has run the nodes on the main net and the jungle net (testing environment) since Day One. With the block logs file is growing bigger and bigger and more and more transactions are signed into the blocks, maintaining all the nodes as the full node isn't a good idea. A Huge amount of P2P synchronization traffic and API visit traffic together will cause the nodes corrupted unexpectedly and make the node to take lots of time to re-sync or replay.

Let's dive deeper. Simply, a full node has such functionality as below:

  • Networking (p2p/bnet)
  • Block Produce

Each functionality is implemented by a bunch of the plugins.

Plugin NameDescriptionFunctionalityDependency
chain_pluginThe chain_plugin is a core plugin required to process and aggregate chain data on an EOSIO node.Networknone
chain_api_pluginThe chain_api_plugin exposes functionality from the chain_plugin to the RPC API interface managed by the http_pluginRPC APIchain_plugin
bnet_pluginThe bnet_plugin provides an p2p protocol to persistently synchronize two blockchainsNetworknone
history_pluginThe history_plugin provides a cache layer for blockchain objects that are useful for obtaining historical data.RPC APIchain_plugin
history_api_pluginThe history_api_plugin exposes functionality from the history_plugin to the RPC API interface managed by the http_pluginRPC APIhistory_plugin and chain_plugin
producer_pluginThe producer_plugin loads functionality required to for a node to produce blocks.Block Producechain_plugin

Thus, let's go back to the first paragraph of the article.

From the on-promise perspective, what EOS9CAT is doing now is playing a full node with several different minor nodes.

Node RoleDescriptionEnabled PluginConnectivity
NetworkingSynchronize the chainbnet_plugin and chain_pluginExpose p2p/bnet ports
RPC APIProvide the RPC API for the history and chainchain_plugin, history_plugin, chain_api_plugin and history_api_pluginExpose API (http) port
Block ProduceProduce the blockschain_plugin, producer_pluginNone


Learning Notes

  1. Networking Node is available to both external and internal.
  2. RPC API Node and Block Produce Node only need to connect to the Networking Node internally, NOT necessarily to expose the p2p/bnet port externally.
  3. The snapshot from different roles of the nodes may NOT be used for each other. (need more verification)
  4. Moreover, each role of the node could be a cluster or replicas which is able to help the node runner to achieve the maximal high availability.
  5. chain/history API reference - EOS RPC API


Since EOS Release v1.1.0, we could start using the mongo_db_plugin, although the documentation about it is not much.

MongoDB Plugin

The MongoDB Plugin (eosio::mongo_db_plugin) is an optional plugin that provides archiving of blockchain data into a MongoDB. This creates a read-only copy of the data in the blockchain that enables highly-scalable and convenient queries on that data.

After first glance, we are so excited that it's really a good plugin to use and will improve the EOS node to be more reliable. So EOS9CAT will do some testing with this plugin and keep you posted. Please stay tuned and see you in the next article.

Contact/About us

If you are an advanced blockchain user, feel free to use any of those tools that you are comfortable with.

If you like what we do and believe in [EOS9CAT](www.eos9cat.com0, vote for eosninecatbp! Waiting for your support. Have a question, send an email to us or visit our website.

FOLLOW US on Facebook, Telegram, Medium, SteemIt, Github, Meetup E0S9CAT, Reddit, Twitter, and LinkedIn.

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!