Blockchain nodes

A blockchain node is a computer program that maintains and verifies the integrity of a distributed ledger. A set of nodes forms a network, ensuring decentralized operations by synchronizing blockchain data and executing transactions. Nodes collectively validate and store information, making blockchains secure, transparent, and immutable.

EVM-based blockchains support both public and permissioned networks. Public EVM blockchains, such as Ethereum and Polygon, are open to anyone, allowing decentralized participation in transaction validation and smart contract execution. These networks rely on economic incentives and permissionless consensus mechanisms like Proof of Stake (PoS) to maintain security and decentralization. On the other hand, permissioned EVM blockchains, such as Quorum and Hyperledger Besu, restrict participation to authorized entities. These networks prioritize privacy, regulatory compliance, and efficiency, often using Proof of Authority (PoA) or Quorum Byzantine Fault Tolerance (QBFT) to validate transactions. Whether public or permissioned, all EVM-based blockchains rely on a distributed set of nodes to maintain state synchronization and network security.

Hyperledger Fabric is a permissioned blockchain framework built for enterprises requiring secure, controlled, and scalable blockchain solutions. Unlike EVM-based blockchains, which may be public or permissioned, Fabric networks are exclusively permissioned, ensuring that only pre-approved entities can operate nodes, validate transactions, and access network data. Fabric’s modular architecture allows organizations to define governance models, identity management policies, and consensus mechanisms tailored to their specific needs. Transactions in Fabric are endorsed by selected peers and then ordered into blocks using mechanisms like Raft or Byzantine Fault Tolerant (BFT) ordering, prioritizing efficiency and compliance over decentralization.

Types of nodes in evm-based blockchains

• Validator Nodes: Actively participate in consensus by proposing and finalizing new blocks. These nodes maintain ledger integrity by operating under consensus mechanisms like Proof of Authority (PoA) or Istanbul Byzantine Fault Tolerance (IBFT).
• Non-Validator Nodes (Observer Nodes): Do not take part in consensus but instead synchronize blockchain data, respond to queries, and facilitate smart contract execution. They maintain updated copies of the blockchain without finalizing blocks.

Among non-validator nodes:

• Full Nodes: Store the entire blockchain history and verify transactions without participating in block finalization.
• Archive Nodes: Extend full node functionality by retaining complete historical blockchain states, making them essential for querying past transactions.

Core components of an evm-based node

• Execution Layer (EVM): Processes smart contracts and updates the blockchain state.
• Networking Layer (devp2p Protocol): Facilitates peer-to-peer communication for efficient data propagation.
• Storage Layer: Manages blockchain data, including account states, logs, receipts, and the Merkle Patricia Trie for world-state management.
• JSON-RPC Interface: Provides an API for dApps, wallets, and external applications to interact with the blockchain.

Types of nodes in hyperledger fabric

• Peer Nodes: Maintain the ledger and execute smart contracts (Chaincode).
  • Endorsing Peers: Simulate transactions and provide endorsement signatures, ensuring compliance with business rules.
  • Committing Peers: Validate endorsed transactions and update the ledger.
• Ordering Nodes (Orderers): Handle transaction sequencing, package transactions into blocks, and distribute them to peers. These nodes ensure consensus across the network using mechanisms like Raft or Byzantine Fault Tolerant (BFT) ordering.
• Certificate Authority (CA) Nodes: Issue and authenticate identities using Public Key Infrastructure (PKI), enforcing security policies and access controls.

Unlike EVM-based blockchains, Fabric nodes do not store a global state in shared memory. Instead, they use separate key-value stores and dedicated ledgers, enhancing privacy and scalability.

Certificate authorities

Certificate Authorities play a key role in the network because they dispense X.509 certificates that can be used to identify components as belonging to an organization. Certificates issued by CAs can also be used to sign transactions to indicate that an organization endorses the transaction result - a precondition of it being accepted onto the ledger. Let's examine these two aspects of a CA in a little more detail.

Firstly, different components of the blockchain network use certificates to identify themselves to each other as being from a particular organization. CAs are so important that Hyperledger Fabric provides you with a built-in one (called the Fabric-CA) to help you get going.

The mapping of certificates to member organizations is achieved via a structure called a Membership Services Provider (MSP), which defines an organization by creating an MSP which is tied to a root CA certificate to identify that components and identities were created by the root CA.

The mapping of certificates to member organizations is achieved via a structure called a Membership Services Provider (MSP), which defines an organization by creating an MSP which is tied to a root CA certificate to identify that components and identities were created by the root CA. The channel configuration can then assign certain rights and permissions to the organization through a policy.

Secondly, certificates issued by CAs are at the heart of the transaction generation and validation process. Specifically, X.509 certificates are used in client application transaction proposals and smart contract transaction responses to digitally sign transactions. Subsequently the network nodes who host copies of the ledger verify that transaction signatures are valid before accepting transactions onto the ledger.

More information about the Fabric-CA can be found on the official Hyperledger Fabric-CA documentation website.

Identities

The different actors in a blockchain network include peers, orderers, client applications, administrators and more. Each of these actors , active elements inside or outside a network able to consume services , has a digital identity encapsulated in an X.509 digital certificate. These identities really matter because they determine the exact permissions over resources and access to information that actors have in a blockchain network.

A digital identity furthermore has some additional attributes that Fabric uses to determine permissions, and it gives the union of an identity and the associated attributes a special name , principal. Principals are just like userIDs or groupIDs, but a little more flexible because they can include a wide range of properties of an actor's identity, such as the actor's organization, organizational unit, role or even the actor's specific identity. When we talk about principals, they are the properties which determine their permissions.

For an identity to be verifiable, it must come from a trusted authority. A membership service provider (MSP) is that trusted authority in Fabric. More specifically, an MSP is a component that defines the rules that govern the valid identities for this organization. The default MSP implementation in Fabric uses X.509 certificates as identities, adopting a traditional Public Key Infrastructure (PKI) hierarchical model.

More information about identities can be found on the official Hyperledger Fabric documentation website.

SettleMint's platform uses the Fabric-CA to create a root CA, this CA acts as a dual-headed CA, meaning that it is used for issuing MSP and TLS certificates. This CA must be used to issue all certificates for the network, orderers, peers, administrators, and client applications.

Peers

Peers are a fundamental element of the network because they host ledgers and chaincode (which contain smart contracts) and are therefore one of the physical points at which organizations that transact on a channel connect to the channel (the other being an application). A peer can belong to as many channels as an organizations deems appropriate (depending on factors like the processing limitations of the peer pod and data residency rules that exist in a particular country).

More information about peers can be found on the official Hyperledger Fabric documentation website.

Orderers

An orderer (also known as an "ordering node") does transaction ordering, which along with other orderer nodes forms an ordering service. Because Fabric's design relies on deterministic consensus algorithms, any block validated by the peer is guaranteed to be final and correct. Orderers also enforce basic access control for channels, restricting who can read and write data to them, and who can configure them.

The ordering service gathers endorsed transactions from applications and orders them into transaction blocks, which are subsequently distributed to every peer node in the channel. At each of these committing peers, transactions are recorded and the local copy of the ledger updated appropriately. An ordering service is unique to a particular channel, with the nodes servicing that channel also known as a "consenter set". Even if a node (or group of nodes) services multiple channels, each channel's ordering service is considered to be a distinct instance of the ordering service.

More information about orderers and the ordering service can be found on the official Hyperledger Fabric documentation website.

Application channels, or simply channels SettleMint's platform creates by default an application channel called "default-channel" which is used to create an initial ledger for the network.

Users can create additional application channels using the binaries provided by Hyperledger Fabric (install them locally and download the node's certificates) or by creating a Smart contract set which is a configured web IDE with all the necessary files and binaries to interact with your peer node and orderers.

Core components of a hyperledger fabric node

• Chaincode Layer: Executes smart contract logic and enforces business rules.
• Ledger Layer: Stores transactional data using LevelDB or CouchDB as key-value state databases.
• Communication Layer: Manages gRPC-based interactions between nodes.
• Membership Service Provider (MSP): Governs identity verification, access policies, and network governance.

Settlemint platform’s node manager

The SettleMint Node Manager simplifies blockchain node deployment and management, offering a user-friendly interface to configure, monitor, and maintain nodes on different blockchain networks. It enables businesses and developers to:

• Deploy nodes in a few clicks without complex configurations.
• Monitor network health and performance with real-time statistics.
• Pause and resume nodes to optimize resource usage and costs.
• Interact with blockchain APIs through JSON-RPC, WebSockets, and GraphQL.
• Manage security and identity credentials via cryptographic key management.

Node types on SettleMint platform

For Ethereum, SettleMint provides support for the Geth client. This means that when you add an Ethereum node, you get a Geth node by default. All nodes running in SettleMint are configured to be archive nodes, meaning they all include all previous states of a given blockchain since its origin.

For hyperledger besu, SettleMint provides the option between Validator and Non-validator nodes. All nodes are configured to be archive nodes.

For hypelerledger fabric, SettleMint offers options between peer and orderer nodes.

1. Hyperledger Besu node overview

The Besu Node Dashboard serves as a comprehensive interface for managing and monitoring a Hyperledger Besu node. It provides insights into node status, network connectivity, blockchain interactions, and system performance.

Consensus mechanisms

A consensus mechanism defines the rules for the nodes in a blockchain network to reach an agreement on the current state of the blockchain ledger.

Besu comes with several consensus mechanisms. As an Ethereum implementation, Proof of Work (PoW) is a given, but the Proof of Authority (PoA) options are more suitable for enterprise projects. These can be used when participants know each other and there is a level of trust between them, e.g. in a permissioned consortium network.

PoA is a light and practical consensus mechanism that gives a small and designated number of blockchain actors the power to validate transactions within the network and to create new blocks. This results in faster block times and a much greater transaction throughput.

SettleMint's Enterprise Ethereum networks always use QBFT

In IBFT 2.0 networks, a group of nodes are selected to form the pool of validators. These nodes will be in charge of determining if a proposed block is suitable for addition to the chain. One of these validator nodes will be arbitrarily selected as the proposer. This single proposer, having received messages from the pool of validators, will decide what to add to the chain. This is presented as a proposed block to the other validators. Only if a majority (66% or more) of the validators deems the block valid will it be added to the ledger. At the end of each consensus round, the validators select a new proposer and the process is repeated. IBFT 2.0 has immediate finality. There are no forks and all valid blocks are included in the main chain.

When you deploy a Hyperledger Besu blockchain network on SettleMint, it should be Byzantine fault tolerant.

More information on Hyperledger Besu can be found in the official Hyperledger Besu documentation.

1.1 Details tab

The Details tab provides key deployment information, including:

• Node Name & Status – Identifies the instance and operational state.
• Deployment Location – Specifies where the node is hosted.
• Blockchain Network & Protocol – Indicates network participation and protocol in use.
• Node Type – Determines whether the node is a validator or other roles.

Node identity (evm chains)

The Node Identity section holds cryptographic keys and credentials that establish the node’s uniqueness within the network.

• Mnemonic – A set of words that generate the private key.
• Derivation Path – Defines how keys are generated from the mnemonic.
• Private Key – The secret key used for signing transactions.
• Public Key – The public identifier associated with the node.
• Blockchain Address – The node’s address on the Ethereum network.
• Enode URL – A unique identifier for node-to-node communication.

The node identity plays a vital role in establishing trust, securing transactions, and enabling peer-to-peer connectivity.

1.2 Connect with node

This tab provides the API endpoints to interact with the node via different protocols:

• JSON-RPC Endpoint – Used for blockchain interactions and queries.
• WebSocket (JSON-WS) Endpoint – Enables real-time event streaming.
• GraphQL Endpoint – Allows structured data querying.

For a software application to interact with a blockchain (e.g. by sending transactions/data to the network, or even just by reading data), it must connect to a node.

This section describes how to connect to your Besu node.

Backend APIs

Once a node has been deployed on an EVM (Ethereum Virtual Machine) compatible network, it can be accessed by different endpoints such as JSON-RPC, JSON-WS or GraphQL. You can connect to your already deployed node using these 3 most common endpoints.

JSON-RPC

JSON-RPC, is a stateless, light-weight remote procedure call (RPC) protocol. Primarily, the specification defines several data structures and the rules around their processing. By default, the version of the JSON-RPC protocol needs to be 2.0, and you need to provide the node ID as well as a method and parameters.

There are different kinds of methods that can be used: ADMIN methods, DEBUG methods, ETH methods etc. The entire list of methods that can be used can be found in the Besu official documentation.

If you want to correctly connect to your node, you need to respect the right structure for the request, which is always the same:

{
"jsonrpc":"2.0"
"Id": nodeId
"method":"methodName"
"params":{
}
}

If you want to connect to a node deployed on the SettleMint platform, go to the Connect tab on the Node detail page in the Blockchain nodes section of your application. Select JSON-RPC or any other endpoint and click Try it out. You will then be redirected to a new tab where you will be able to test different methods as well as the related Curl command line.

JSON-WS

To make RPC requests over WebSockets, you can use wscat, which is by definition a Node.js based command-line tool. First you will need to connect to your node's WebSocket server using wscat, as follows: "wscat -c ws://<JSON-RPC-ws-endpoint:port>" . All the credentials are provided in the Connect tab on the Node detail page in the Blockchain nodes section of your application. After you have established a connection, the terminal should display a ">" prompt. You will then be able to send individual requests as a JSON data package, as above, for instance:

{
"jsonrpc":"2.0"
"Id": 1
"method":"eth_blockNumber"
"params":{
}
}

GraphQL

GraphQL is a query language and server-side runtime for API's. It is designed to make APIs fast, flexible, and developer-friendly. We have a GraphQL interface that can be used with many different queries. These queries can be tested out in our GraphQL playground. You can also test out the different graphql queries with cURL, those request would look like this:

curl -X POST -H "Content-Type: application/json" -H "x-auth-token: <AUTH_TOKEN>" --data
'{ "query": "{syncing{startingBlock currentBlock highestBlock}}"}' http://<DOMAIN>.settlemint.com/graphql

If you want to connect to a node deployed on the SettleMint platform, go to the Connect tab on the Node detail page in the Blockchain nodes section of your application. Select Graphql and click Try it out. This will bring you to the GraphQL playground where you can use all the different queries.

Javascript API

If you do not want to use the above endpoints to connect to your node, it is possible to use plain Javascript. Several convenience libraries exist within the different ecosystem which makes connection much easier. With these libraries, developers around the world can write one-line methods to easily initiate requests (still under the hood) that interact with Ethereum or any other EVM compliant network. Note that some libraries might be available for Ethereum but not for the other networks.

These libraries are very helpful and abstract away much of the complexity of interacting directly with your node. Most also provide useful and straightforward functions such as converting ETH to Gwei, so that you can spend less time dealing with decimal issues and more time on the functionality of your underlying application.

One of the most commonly used libraries, Ethers, is extremely easy to use for signing transactions, sending tokens etc. For example:

// If you don't specify a //url//, Ethers connects to the default
// (i.e. ``http:/\/localhost:8545``)
const provider = new ethers.providers.JsonRpcProvider();
 
// The provider also allows signing transactions to
// send ether and pay to change state within the blockchain.
// For this, we need the account signer...
const signer = provider.getSigner();

1.3 JSON-rpc

The JSON-RPC interface enables blockchain queries, transactions, and debugging.

Key features:

• Querying blockchain information (blocks, transactions, accounts).
• Sending transactions and interacting with smart contracts.
• Debugging and tracing blockchain activities.

Json-rpc methods (grouped by category):

Transaction & gas management

Transaction pool

Blockchain data

Mining & network

Debug & trace

1.4 GraphQL

GraphQL provides an efficient querying method for blockchain data.

Benefits:

• Fetch specific blockchain details, such as transaction history.
• Optimize data retrieval for dApps and front-end applications.

1.5 Resources

Monitors CPU, memory, disk usage, and network connections to optimize performance.

Capabilities:

• Prevent system overload by tracking hardware usage.
• Ensure proper network connectivity and peer synchronization.

1.6 Logs

Real-time logs provide visibility into node operations, including:

• Peer connections and network status.
• Transaction processing and block synchronization.
• Debugging and security auditing.

2. Hyperledger Fabric node overview

The Hyperledger Fabric Node Dashboard is designed to monitor and manage Fabric nodes, focusing on consensus, network identity, and operational metrics.

2.1 Details tab

The Details tab provides:

• Node Name & Deployment Location – Identifies the instance.
• Blockchain Network & Protocol – Hyperledger Fabric-specific details.
• Node Type – Defines the node as an Orderer or Peer.
• Version – Displays the running Hyperledger Fabric version.

2.2 Node stats

Provides critical consensus and participation metrics, including:

• Consensus Leader Status – Indicates if the node is leading consensus.
• Consensus Relation – Defines the node’s role (e.g., Consenter).
• Participation Status – Specifies whether the node is actively participating.
• Ledger Height – Displays the blockchain height.
• Proposal Metrics – Tracks transaction proposals received per time interval.

2.3 Node identity & security

This section contains cryptographic details for network security:

• Administrator’s TLS Certificates & Keys – Ensures secure communication.
• Node’s TLS Certificates & Public Keys – Verifies node identity.
• Private Keys & Certificates – Used for authentication and encryption.

Capabilities:

• Secure Network Communication – TLS encryption for data integrity.
• Node Authentication – Ensures trusted interactions within Fabric.
• Certificate Management – Maintains cryptographic security.

2.4 Resources tab

Similar to Besu, this tab provides:

• CPU & Memory Monitoring – Optimizes resource allocation.
• Storage Usage – Ensures sufficient disk space for operations.
• Peer & Orderer Connectivity – Maintains network stability.

2.5 Logs tab

Displays Fabric-specific logs related to:

• Orderer operations & consensus messages.
• Transaction validation & endorsement events.
• Network health & debugging information.

Node connections

For an application to interact with a blockchain (e.g. by sending transactions/data to the network, or even just by reading data), it must connect to a node.

To connect to a node, you use an endpoint, which is a URL that enables an API to gain access to the node. You interact with the node by sending requests to, and receiving responses from it via an API.

You can find the endpoints on the node detail page, in the Connect tab, together with node interaction tools with playgrounds for real-time tryouts (e.g. JSON-RPC, GraphQL, etc.).

Connection details

Connection examples

const Web3 = require('web3');
const web3 = new Web3('https://your-node-url/token');