Different Types of Nodes on Shardeum – A Deep Dive
Learn about the different types of nodes on Shardeum and how we're making it easy for anyone to run a node with simple button...
Learn about the different types of nodes on Shardeum and how we're making it easy for anyone to run a node with simple button...
One of the most unique and attractive things about blockchain is the fact that they’re designed to be highly decentralized. This decentralization is fueled by blockchain nodes. Nodes make up the foundation of a blockchain network to function.
In computer science, a ‘node’ typically denotes any device, be it a computer, smartphone, or other hardware, connected to and participating in a network. You can consider a node, in the context of blockchain, more or less similar but one that takes on a more specific role. While both involve participation in a network, in blockchain, nodes often carry the responsibility of validating and relaying transactions, ensuring the integrity and security of the entire system.
In a blockchain network, a node is a computer, server, or operator that runs the network’s client software, validating commercial transactions according to the established protocol, often in exchange for rewards. Blockchain nodes communicate with one another to maintain a decentralized network. Their interactions are built on a trustless and permissionless foundation. This means nodes do not need to trust individual participants, nor do they require permission to participate. Instead, they rely on cryptographic proofs and consensus mechanisms to validate transactions and ensure the network’s integrity. Typically, nodes are incentivized to act in the network’s best interest rather than engage in dishonest behavior.
Different types of nodes in blockchain networks narrow themselves to three main purposes: maintenance, validation, and accessibility.
In terms of maintenance, certain type of nodes would be responsible for keeping copies of the ledger in sync and storing encrypted data of past transactions. Some of these nodes serve as storage containers of the blockchain, allowing users and developers to access and retrieve information from the network. They are completely transparent and accessible to anyone.
When it comes to validation, another type of blockchain node use consensus mechanisms to ensure that all nodes remain in sync and that transactions are executed based on majority agreement. This means that nodes are algorithmically programmed to accept or reject proposals, with authenticated proposals being added to the blockchain, copied, and distributed network-wide, and unauthenticated proposals being rejected. By achieving consensus, all nodes are able to reflect the true state of the network. They also process new blocks (or batches of transactions) as they are added to the blockchain, allowing for scalable growth of the network.
Another set of blockchain node serve as a gateway between third-party applications and a blockchain network. It offers an interface for querying data, submitting transactions, and obtaining real-time updates. By providing this bridge, these nodes simplify blockchain interactions, making the technology more accessible to dapp developers, businesses, and other applications. Overall, the role of each type of nodes may slightly differ according to each network, but it cannot be overstated that all these nodes play a central role to establish the security, reliability, and accessibility of blockchains.
This blog explores 10 distinct nodes in blockchain networks. Dive into it for a thorough grasp of today's prevalent types.
As indicated above, there are more than a dozen nodes that operate on various blockchain networks today. These networks have the freedom to choose what type of nodes are best required for their blockchains. They can also come up with a brand new type of node(s) based on the developments in the embedded technology.
Shardeum is a novel EVM-based layer 1 blockchain that scales linearly to tackle the scalability trilemma and thus, ensuring low transaction fees forever. As many recent L1 platforms aim to balance security, decentralization, and scalability, they often end up scaling vertically—much like Web2 giants such as Twitter and Facebook— by increasing the power of their existing servers and by adding more powerful servers in response to traffic spikes.
This approach mirrors challenges faced by older blockchains like Bitcoin and Ethereum, where node operation demands extensive infrastructure. As node operation costs rise, network congestion intensifies during peak traffic, elevating transaction fees and jeopardizing user experience. If this experience falters, technology adoption might wane despite its promising vision. Layer 2’s and other scaling solutions built atop layer 1 networks enhance speed and reduce costs, but that often comes at the cost of low decentralization and/or security. Therefore, resolving the scalability trilemma at layer 1 is crucial, as the entire ecosystem—including layer 2 solutions—inherits its foundational attributes, paving way for a robust network.
Shardeum scales linearly, responding to traffic surges by incorporating more nodes rather than bolstering the capabilities of existing ones. Instead of relying on high-powered machines, the network expands by adding more modestly-equipped devices. This design ensures that an average user can feasibly run validator nodes, stregthening network security and decentralization in exchange for rewards. Each new node added, enhances the network’s throughput in direct proportion. Shardeum achieves this linear scalability through dynamic state sharding and transaction-level consensus among other innovations facilitated by its protocol. Consequently, Shardeum stands out as a pioneering smart contract platform, adeptly balancing speed, decentralization, and security.
Considering the protocol has a unique design-build, it is imperative (and isn’t merely an option) that its node architecture and reward policies are also unique. On the Shardeum network, three node types exist: validator nodes, standby nodes, and archive nodes. In this blog, we’ll also discuss the roles of relayers and connector nodes (which is similar to RPC nodes on Ethereum). They are not as directly engaged by the average end-user as the other three types of nodes, but they both play a crucial role in facilitating interoperability, network functionality and developer interaction.
While validator and archive nodes might sound familiar, the concept of standby nodes is particularly novel in a decentralized context. The comprehensive details about the node types and their roles will be presented in the whitepaper set for release on November 8th, 2023. However, the aim of this blog is to disseminate the essence of node types on Shardeum tailored for average computer users.
Over the years, validator nodes have been referred to by various names, such as validators, active nodes, staking nodes, and consensus nodes. To participate, these nodes must meet specific hardware and staking criteria set by the network. Thanks to dynamic state sharding and linear scalability, these requirements will be kept low, promoting broad user and community participation, thereby ensuring robust decentralization and security. What this effectively means is the validator nodes are only required to keep the current state of accounts within their designated shards. Historical transactions and states are offloaded to the network’s archive nodes enabling validators to run a node on Shardeum with minimal storage, CPU, and memory requirements.
For those interested in running a validator node on Shardeum’s current betanet, Sphinx, here’s the process along with the prescribed minimum hardware configuration. The term ‘staking requirements’ specifically pertains to Shardeum’s implementation of the Proof-of-Stake (PoS) consensus mechanism. Validators pledge, or ‘stake’, a predetermined amount of the native coin, SHM, as collateral to partake in the validation and consensus process. Misconduct by validators risk having their stakes slashed. The exact stipulations for both hardware and staking will be finalized as we near the mainnet launch in Q1 of 2024. Shardeum will reward them with SHM for honestly participating in the consensus and confirming transactions. As a side note, network rewards is expected to come from predefined SHM emissions, and the transaction fees earned.
Moreover, top L1 blockchains necessitate validators to manage their nodes using the CLI (Command Line Interface) — a technical barrier for the average individual. The high demands often associated with running a blockchain node have deterred many from actively participating in this crucial network function so far. Shardeum’s developers have recognized this challenge and chosen to introduce a GUI (Graphical User Interface). This user-friendly approach allows nodes to be operated with simple button clicks, making participation more accessible to all. After all, community reigns supreme on decentralized Web3 networks like Shardeum.
In a nutshell, validator nodes are active nodes currently participating in consensus, validating and confirming transactions in real-time.
Imagine a scenario where a group of users initiates 100 transactions simultaneously on the network. These transactions will be allocated chronologically to validator nodes based on a first-come-first-serve method. Validators will proceed to individually validate and achieve consensus for these transactions. Instead of broadcasting to every node on the network, verified transactions are only propagated within a specific consensus group. This helps to minimize latency and expedite finality times.
Through a trustless and leaderless electronic voting system, the network generates transaction receipts from validators in the respective consensus groups to determine their validity. Once over half (more than 50%) of the receipts for a specific transaction are received within the consensus groups, the transactions are processed with immediate finality on the network. And we are talking about a total turnaround time of very few seconds overall – from the moment a user initiates transaction to their final confirmation. These processed transactions are then grouped or batched into blocks before being transferred to archive nodes for storage. As you see, unlike other blockchain networks, consensus and processing is done at the transaction level instead of block level to enable parallel transaction execution and atomic composability.
Let’s now say, due to a surge in traffic on the network, transactions suddenly build-up in the network’s memory pool. Depending on the pending transactions and to maintain operational efficiency, the active validator network size (in the form of shards) grows and shrinks through Shardeum’s auto-scalability. But how exactly does Shardeum expand the number of validator nodes/shards? Keep reading 🙂
Standby nodes are widely in use among Web2 cloud and web infrastructure companies. Examples include Amazon’s AWS, and Google’s GCP. Blockchain’s emphasis has traditionally been on security and decentralization since Bitcoin’s inception. However, with the advent of smart contracts and decentralized virtual machines with the help of Ethereum, the blockchain sector have long begun to rival its Web2 counterparts across banking, trading, finance, supply chain, and payments domain. That makes scalability an indispensable feature for modern blockchain networks.
While Ethereum ushered in the era of smart contracts back in 2015, why haven’t blockchain networks widely adopted established mechanisms like standby nodes, load balancing, and autoscaling, despite their proven success in other domains to scale up? Beyond their inherent focus on decentralization and security, the primary challenge lies in the blockchain trilemma: the difficulty of achieving security, decentralization, and scalability all at once. To date, no blockchain has perfectly balanced these three pillars. At best, blockchains scale vertically with probabilistic or absolute finality eventually resulting in repeated congestions and high transaction fees especially when the traffic surges.
Shardeum dynamically and evenly shard its states, combined with transaction-level consensus, for horizontal and limitless scaling. Rather than amplifying the processing power of individual machines, Shardeum boosts throughput by incorporating additional machines, or node operators. As traffic surges, the network seamlessly expands its capacity by integrating nodes from its standby pool, ensuring proportional increase in its throughput.
Asides from helping Shardeum scale quicker as and when needed, standby nodes play an integral part in the network security. Remember, sharded blockchains like Shardeum divide the network into smaller groups of nodes, called shards and each shard is responsible for processing a subset of the transactions on the network improving its scalability. Industry experts widely say that shards are mini blockchains themselves that introduces additional levels of complexity. An epoch or session is referred to as “cycle” on Shardeum. At the end of every cycle, the oldest active validators in the network are (auto) rotated out for standby validators. If validators in a shard remain constant, an attacker can identify and potentially compromise these validators over time. Regularly rotating nodes makes it harder for any malicious actor to target specific nodes or predict which node will be in which shard next.
Further, by maintaining a pool of standby nodes, the network ensures high fairness and decentralization, as it provide node operators an equitable opportunity to contribute to different shards and actively participate in its daily operations. Standby nodes also help with balancing the workload among validator nodes on the network, ensuring no particular shard or set of validators is overwhelmed. They further provide redundancy and reliability in case some nodes fail or become unresponsive.
In a nutshell, standby nodes are validator nodes standing by in the network and not currently participating in consensus.
If haven’t yet got a chance to review the initial version of SHM coin issuance/emissions policy, you can check them out here. They offer valuable insights into the role of standby nodes and their integration within a decentralized and linearly scalable system like Shardeum vis-a-vis SHM’s price action. In this blog, we’ll highlight pertinent aspects to give you a clearer perspective on seamlessly incorporating standby nodes without hindering the network’s operational efficiency.
The S:A ratio is the number of standby nodes to the number of active nodes on the network at a give point in time. Nodes are rewarded only during their active phase. Once they’re rotated out and become inactive, they can then claim their rewards. Granting rewards to standby nodes could encourage them to claim benefits without actually participating in the network consensus. Thus, standby nodes do not receive a reward.
As we are working towards a final version of the reward policy across network resources, the following is an inference towards the unique proposition Shardeum offers. In the scenario of a bull market, a disproportionately high S:A ratio could lead to inefficient use of resources. Conversely, during bear market, an excessively low S:A ratio might jeopardize security and impair the network’s scalability potential. Shardeum will strive to strike a balanced S:A ratio, adjusting in response to SHM’s price fluctuations. Thanks to the fair and regular auto-rotation of nodes, users can look forward to operating a node on the network. Standby nodes/validators require staked SHM to become active.
Archive nodes, typically, are a type of nodes in blockchain that stores every transaction that has ever occurred on the chain. Unlike other blockchain nodes, archive nodes require significant storage and computational resources to maintain a complete copy of the blockchain’s history. However, their role is vital for ensuring the trustworthiness of the blockchain network and its applications. Archive nodes are, therefore, compensated with rewards like network coins for providing an immutable record of all transactions and their details.
It is important to distinguish between a full node and archive nodes in a typical blockchain setup. In blockchains, full nodes have a complete copy of the blockchain. Their primary use case is to tell you the current or most recent details of transactions and other activities sufficient enough to facilitate most regular operations in the network. Archive nodes, on the other hand, store a complete snapshot of the blockchain state at every block or cycle, which makes it extremely useful for detailed and complex historical queries.
Think of the blockchain like a book of transactions. Full nodes have the entire book, so they know every transaction that’s ever happened. But if you ask them about the details of an account or contract at a specific time in the past, their response would depend on how their book is organized – they might either not have the information or they’d need to “re-read” or replay transactions from the beginning to that specific point to provide the answer. On the other hand, archive nodes possess comprehensive version of that book. They not only know every transaction, but they’ve also made notes on each page about the details of every account and contract at any given time. So, if you ask them about an account’s details from any specific time in the past, they can tell you exactly without needing to replay every time making their answers relatively instant.
Examples of full node include Bitcoin Core, and Ethereum Geth. Examples of Archive node include OpenEthereum, Nethermind and of course Shardeum archive nodes. Do remember though, full nodes can transition to archive nodes, and vice-versa, by adjusting their data retention and configuration settings.
Archive nodes are useful for applications and protocols that require access to the history of the blockchain, for the purpose of performing auditing, compliance, analytics and settling arbitrary transactions. Here are some of the general features of archive nodes.
As mentioned previously, validator nodes on Shardeum will only store the current state of accounts they are involved in across shards to maintain horizontal scalability, while offloading the historical states to archive nodes. Therefore, they will require significant storage and processing resources. Archive nodes may or may not have to stake the network coin, SHM. The exact requirement and details to run an archive node along with incentive mechanism will be made available closer to the mainnet. In the current betanet phase of the project, we roughly estimated the hardware requirement to be – 32 core, 256GB RAM, 4TB SSD. In order to encourage and motivate the public to run archivers and store the historical data, the network will incentivize them with a portion of the network rewards. Upcoming whitepaper, again, will have more specific details around archive nodes on Shardeum.
In a nutshell, an archive node keeps a record of all the historical states of the network.
Once archivers have aggregated the essential data from validators, it is the responsibility of relayers to distribute this consolidated data to various services that require it, such as blockchain explorers, RPCs, exchanges and more. A service called the distributor running on the archiver can send the network data to downstream services. The distributor provides APIs to download historical data as well as stream the most current data. A service called a collector can connect to the distributor to get the network data and make a local copy. A relayer node runs both a collector and distributor on the same machine to fan out the network data. There can be multiple tiers of relayers helping to distribute the network data to the rest of the ecosystem. Relayers need to be supernodes with large amounts of storage, RAM, CPU and bandwidth.
As the complexity and demand of the Shardeum network evolve, both archivers and relayers are envisaged to scale vertically, ensuring that the pace of data dissemination is always in step with the network’s growth. Therefore, it is expected that relayers is run by professional node operators. Relayers are not a direct part of the Shardeum network and do not receive any reward. This stems from the understanding that these relayers will predominantly be operated by the very services that necessitate the data, such as the explorers. For the Shardeum network and its community, the proposed approach presents several benefits.
Firstly, by decoupling network compensation from relayer operation, it encourages service providers to optimize their infrastructure based on their specific needs, potentially leading to more efficient data distribution pathways. Additionally, the potential emergence of an economic ecosystem for data distribution fosters innovation and diversification in service offerings. For instance, this model lays the foundation for a novel economic dynamic: certain service providers, instead of operating their own relayers, might opt to subscribe and receive data from relayers managed by third parties.
In a nutshell, relayers or relayer nodes on Shardeum will be responsible to distribute the consolidated data from archivers on Shardeum to various services that require it such as blockchain explorers, RPCs, exchanges among others.
Connector nodes or connectors on Shardeum are similar to RPC nodes on Ethereum. They are primarily used by dapps building on a blockchain network to provide services and solutions to their end users in a decentralized way. Think of connector nodes as the search bar you use on Google. When you want to know something, you don’t browse the entire internet page by page; you simply type your question into Google’s search bar and get answers. Similarly, when you want information from a blockchain or wish to make a transaction, you don’t process the entire blockchain; you interact with connector node. Just as the search bar gives you quick and relevant results, the connector node fetches or submits the specific information you seek from/to the vast blockchain network.
But why do do we need RPC or connector nodes in the first place? One of the core tenets of blockchain is decentralization. Each node in the network operates autonomously, playing an integral role in the consensus process, transaction validation, and maintenance of the shared ledger. While nodes are more like ‘internal agents’ that ensure the blockchain functions correctly, dapps can be considered as ‘external agents’ that interact with the blockchain to render services like gaming, trading, RWA to end users without an intermediary. Unlike most centralized systems, such as Gmail, that can recognize and cater to external users/clients in a personal way, a blockchain doesn’t inherently “know” or “recognize” these external entities. Thus, there needs to be a bridge, like RPC nodes on the blockchain, to facilitate communication between the external agents and the blockchain network.
Furthermore, the intrinsic architecture of standard blockchain protocols, which doesn’t directly acknowledge external entities, bolsters another core tenet – security. External entities would have to access blockchain data through designated call functions, ensuring controlled and secure interactions. Similar to other nodes, RPC nodes can also be run by anyone in the public, including individuals and organizations. By acting as intermediaries, connector nodes alleviate the need for every application to run a full node, thereby reducing the overhead and fostering a more scalable ecosystem. Shardeum will encourage third parties to operate connector nodes on the network.
Connector nodes on Shardeum provide an interface through which decentralized applications, among others, can send requests and receive responses. This in turn allows external clients to interact with, access, and retrieve data from the blockchain network. For instance, a client like Metamask can send a transaction request to the network. This request is initially received by the connector node, which then forwards it to a specific set of network nodes, ensuring efficient retrieval of the required information.
Connector nodes within Shardeum, further, provide access to the EVM-compatible JSON RPC interface, enabling structured data communication through JSON for seamless interactions between dapps and Shardeum. Those acquainted with Ethereum’s RPC nodes will recognize the functionality and feel on Shardeum. For novice developers or users, the JSON interface, backed by Ethereum’s vast array of resources, tutorials, and documentation, eases your learning process and offers a familiar environment for troubleshooting and development.
In a nutshell, developers utilize connector nodes or RPC nodes to enable their dapps/services to interact with the blockchain, providing various utilities to end-users. Dapps and services such as wallets, exchanges, explorers among others rely on connector/RPC nodes extensively.
In the Shardeum network, connector nodes and relayer nodes serve distinct functions. Connector nodes act as the entry points for external wallets and clients to interact with the network, allowing them to query and submit transactions. They are similar to RPC servers in the Ethereum ecosystem. Relayer nodes, on the other hand, are responsible for communicating with archiver nodes or other relayer nodes to store and stream data produced by the network to downstream services, such as explorers. This function is similar to that of exit nodes in the Ethereum ecosystem, commonly utilized by exchanges and explorer services.
What role does end users play with respect to relayers and connector nodes? When an end-user interacts with a dapp or wallet, it’s often these nodes that processes the request and communicates with the blockchain to retrieve or send data. So, while end-users might not directly interact with or even be aware of relayers or connector nodes, their user experience is significantly influenced by the performance and reliability of these nodes. In essence, connector nodes and relayers serve a distinct role compared to the more publicly recognized and operated nodes such as archive nodes, validator nodes, and standby nodes.