Chapter 7: An Efficient Verifiable Data Registry for Identity and Trust Management in IoT

Intoday’sworld,IoTdevicesplayanintegralroleinvariousaspectsofourdailylives, ranging from smart home appliances to healthcare systems and industrial applications, offering innovative services. However, the inherent diversity and heterogeneity of IoT networks introduce new challenges, particularly in managing devices. This diversity also opens vulnerabilities that malicious actors may exploit, compromising the security of IoT ecosystems. In this chapter, we present a verifiable data registry (VDR) solution designed for decentralized identity and trust management in IoT environments. Our approach leverages Blockchain and gRPC technologies, utilizing HyperLedger Fabric as the underlying blockchain infrastructure. We extend this with a novel hybrid consensus algorithm tailored to the specific needs of IoT networks. Additionally, we expose the VDR’s identity and trust management capabilities through gRPC services. The proposed solution emphasizes both security and scalability, enhancing its relevance and effectiveness in IoT applications.

Modern IoT networks consist of a wide range of heterogeneous devices that vary in nature, technical specifications, and are designed to fulfil different objectives across diverse domains [1, 2]. This heterogeneity introduces challenges in terms ofmanagement, deployment, maintenance, commissioning, inter-communication, and overall lifecycle management. Additionally, the subtle differences among IoT devices make security concerns more evident [3]. For example, the absence of common trust mechanisms and standardized security frameworks makes IoT devices particularly attractive targets for attackers. Unfortunately, there are currently no comprehensive solutions that can securely manage IoT devices while simultaneously addressing decentralization and privacy concerns. As noted in [4, 5], most existing IoT trust management frameworks focus only on specific aspects, such as security, flexibility, or privacy, while others are limited to particular domains, like smart mobility [6] and healthcare [8], where the heterogeneity of IoT devices is more controlled.

To address these challenges, the ERATOSTHENES research project proposes an innovative decentralized solution for the holistic lifecycle management of IoT devices. Specifically, ERATOSTHENES aims to achieve this through: (a) secure and privacy-preserving identity management for IoT devices, enabling decentralized enrolment, discovery, and overall management across various domains, (b) reliable communication and network operation via a trust mechanism that assesses the trustworthiness ofnodes, and (c) sharing cyber-threat intelligence (CTI) information to strengthen the network and its devices against ongoing attacks. The ERATOSTHENES Trust Framework is designed to be versatile and applicable across multiple domains, such as smart mobility, remote healthcare, and Industry 4.0. Thus, the proposed solutions are intended to be flexible and efficient, accommodating heterogeneous and resource-constrained devices (e.g., IoT) without compromising security. Further details on the requirements are discussed in [9].

In this context, the current chapter introduces anewsolution to enable the secure storage, retrieval, management, and sharing ofidentity data (i.e., DID Docs) alongside additional information, such as trust scores linked to IoT devices and CTI data. This solution enhances the resilience ofthe entire ERATOSTHENES IoT ecosystem, where various architectural components leverage the services provided by this approach. The solution is built upon the W3C Decentralized Identifiers (DIDs) standard,¹implementing the concept of Self-Sovereign Identities (SSIs) for verifiable and decentralized identity management. In particular, we propose a secure and efficient Verifiable Document Registry (VDR) for decentralized identity and trust management. To achieve this, we utilize the Hyperledger Fabric (HLF) blockchain framework for storing information and create scalable and secure gRPC services to expose its functionality. Additionally, we extend HLF with a novel, fair, and lightweight consensus algorithm to meet the specific needs of the IoT ecosystem and the ERATOSTHENES project.

The remainder of this chapter is structured as follows: The next section introduces the preliminary knowledge required to understand the contributions of this work. Section 7.3 presents the proposed VDR solution and its design. Section 7.4 details the creation of an efficient and secure VDR using gRPC services and a hybrid consensus algorithm. Lastly, Section 7.5 provides an experimental evaluation ofthe proposed innovations, and Section 7.6 concludes the chapter.

In this section we introduce the fundamental concepts necessary for understanding the work presented in this chapter.

Self-Sovereign Identity (SSI) is a digital identity model that empowers individuals to control their personal data.² Unlike traditional systems where third parties manage and store identity information, SSI allows users to own, manage, and securely share their credentials through decentralized technologies like blockchain. This reduces dependency on centralized authorities, enhances privacy, and gives users the ability to decide what information to share and with whom, promoting greater autonomy and data security.

To support this, the World Wide Web Consortium (W3C) has standardized Decentralized Identifiers (DIDs), which enable verifiable and decentralized identity management.³As illustrated in Figure 7.1, DIDs refer to a subject and are managed by a DID controller (i.e., identity controller). Each DID is associated with a DID document that specifies the verification methods required to prove the authority of the DID controller over the DID, along with available interactions with the subject. This functionality is facilitated by a Verifiable Data Registry (VDR), which can be implemented as a blockchain network to store and manage information such as DIDs and DID documents. The VDR is a key component of SSI infrastructure, and its design and implementation significantly impact the achievement of SSI objectives. In particular, implementing a secure, and scalable VDR for identity management is an open challenge, especially in resource-constrained environments like IoT [9]. To this end, in this work we present an efficient VDR aimed to facilitate the management of identity and trust information.

In today’s interconnected world of IoT devices, security challenges in decentralized environments can be addressed using distributed ledger technology (DLT), which ensures secure and trustworthy access to records and data storage. The most widely recognized and mature DLT is blockchain. Originally developed to support Bitcoin in 2008 [10] as a verifiable append-only database for recording financial transactions, blockchain has since evolved into a powerful tool for decentralized data management.

A blockchain is essentially a chain of data blocks, each containing specific information and linked to the previous block through a cryptographic hash function. This structure guarantees the integrity and proper sequencing of data. Blockchain networks are designed for read-only traversal or the addition of new blocks, ensuring that data cannot be altered once recorded.

What sets blockchain apart from other distributed storage technologies is its decentralized and peer-to-peer nature. Each node in the blockchain network stores a local copy of the entire blockchain and collaborates with other nodes to add new blocks through consensus algorithms. These algorithms define the process for nodes to agree on the inclusion ofnew blocks, ensuring that all participants in the network maintain a shared and consistent view of the blockchain, even in a decentralized setup.

Blockchain networks can vary based on membership criteria. Public blockchains allow any node to join and access the chain, while private blockchains restrict participation to authorized nodes. Furthermore, blockchains can be permissioned, where only selected nodes can add new blocks, or permissionless, where any network participant can propose new blocks.

Another key feature ofblockchain technology is the introduction ofsmart contracts, which debuted with Ethereum [11]. Smart contracts are immutable pieces ofcode executed on the blockchain, allowing for automated processes while maintaining transparency and auditability. This high level of programmability enables the automation ofcomplex tasks with minimal human intervention.

Blockchain has a wide range ofapplications, including secure supply chain management, healthcare data management, and smart energy services. It is also seen as a foundational technology for Web 3.0, which aims to decentralize and democratize the internet. One significant example of this trend is Self-Sovereign Identity (SSI), which is discussed in this work.

HyperLedger Fabric (HLF) is one ofthe leading frameworks for building permissioned blockchain networks. In HLF, each network is structured into channels, which represent well-defined groups ofnodes (i.e., consortium) that may belong to different organizations. The nodes in an HLF network serve distinct functions and are classified as either Peers or Orderers. Peer nodes are responsible for hosting the ledger, executing chaincode (i.e., smart contracts), and providing services like the Fabric Gateway [12]. They play a key role in the smooth operation ofthe network by endorsing and validating transactions for inclusion in the blockchain. Transactions are submitted to the blockchain through the Fabric Gateway. Orderer nodes, on the other hand, are tasked with ordering these endorsed transactions into blocks and distributing them to Peer nodes. The collection of Orderer nodes across various organizations, all connected to the same channel, forms the network’s Ordering service.

Most blockchain networks follow an order-execute architecture, where the consensus protocol first validates and organizes transactions into blocks, which are then propagated to all peer nodes for sequential execution. HLF, however, introduces an innovative execute-order-validate architecture. In this model, transactions are first executed and endorsed by Peer nodes, then ordered into blocks by the Ordering service. Afterward, the Peers validate the transactions within the block based on the network’s endorsement policy before committing them to the ledger.

The transaction lifecycle in HLF begins with a client from one ofthe network’s organizations. The client application connects to the Fabric Gateway in a Peer node, and the transaction goes through three key phases before being added to the blockchain:

• Proposal phase: The client sends a transaction proposal to the network’s participating organizations. Each Peer executes the proposed transaction and signs it according to the network’s endorsement policy.

• Ordering phase: The Fabric Gateway submits the endorsed transaction to an Orderer node, based on the consensus mechanism in place. For example, in Raft consensus algorithm, the signed transaction is sent to a specific Orderer, whereas in SmartBFT, it is broadcast to all members of the Ordering service. The Ordering service organizes the transaction into a block and forwards it back to the Fabric Gateway.

• Validation phase: Each Peer validates the transactions within the block. Valid transactions are committed to the ledger, and the client receives a confirmation from each Peer, signalling that the transaction has been successfully appended to the blockchain.

In this work we leverage HLF advanced functionalities to create the basis of the proposed VDR. To this end, on the one hand we incorporate a new consensus algorithm to it. On the other hand we expose the implemented identity and trust management functionalities via a gRPC interface to boost efficiency and security. We elaborate on this in Section 7.3.

Consensus algorithms are fundamental to blockchain technology, ensuring the secure storage and integrity of data on the blockchain. These mechanisms provide the core process by which nodes in a decentralized network agree on adding new blocks to the chain. Consensus algorithms can be broadly categorized into two types [13-15]. The first category consists of voting-based or leader-based approaches, which originate from distributed systems and rely on agreement protocols that mimic human decision-making processes. In these algorithms, nodes use a voting system to elect a leader, who is then responsible for adding a block to the chain. These approaches are typically used in permissioned blockchains, and the algorithms supported by HyperLedger Fabric (HLF), such as Raft and smartBFT, fall into this category.

The second category includes modern consensus algorithms, commonly found in public blockchains, which use randomness and competition. For example, in Proof-of-Work (PoW) algorithms [10], nodes compete to solve a cryptographic puzzle, with the winner adding the next block. In Proof-of-Stake (PoS) algorithms [16], nodes are selected based on the amount of stake they hold in the network, with higher stakes increasing the likelihood of selection. As already mentioned, in this work we integrate a novel hybrid consensus algorithm to HLF. This algorithm draws inspiration from modern approaches consensus while incorporating elements of voting mechanisms.

In this section we present the design of the proposed VDR solution. First we discuss the overall architecture of our VDR and its components. Then we move forward presenting the W3C compliant DID method we defined to manage identities through our VDR.

Our goal is to create an efficient VDR to manage identities and trust information in a decentralized manner. The overall architecture of the proposed approach is depicted in Figure 7.2. At the core of the proposed VDR component lies the blockchain module, implemented using HLF, which is responsible for storing and managing DID documents and Trust information (i.e., trust scores). To facilitate the coordination of different nodes, the blockchain module utilizes different consensus algorithms, such as Raft, smartBFT and a novel hybrid consensus algorithm (see Section 4.2). Next to that, we create smart contracts, in the form of HLF chaincode, to manage the information stored in the blockchain infrastructure. In particular, we have implemented smart contracts to cover all the necessary CRUD (Create, Read, Update, Delete/Deactivate) operations for both DID Docs and Trust scores, and also share these data across multiple IoT networks (i.e., domains).

Despite their usefulness, interacting with the blockchain using smart contract in an IoT network can be challenging. That would require different services, such as the IdM and the TMB service, to implement their respective blockchain infrastructure and call the related smart contracts when needed to perform a particular operation. This can be proven to be a challenging task, both in terms of implementation and efficiency. Therefore, to facilitate the interaction with the VDR’s smart contracts, we have built and external facing interface utilizing the gRPC protocol.

gRPC is an open source, cross-platform Remote Procedure Call protocol, initially developed by Google, which aims at providing high performance. This interface is exposed by a gRPC server, which implements services for the subscription of a DID agent or Trust agent, and the CRUD of DID Documents and Trust Scores. Internally, the gRPC server employs the Fabric SDK Go for the management and communication with the HLF network, translating the received request to smart contract calls. Compared to existing approaches [9, 17-19], which typically employ other protocols like REST and, the integration ofgRPC enhances both security and scalability. We further discuss this aspect in Section 4.1. We note that our VDR also supports the management and sharing of Cyber Threat Intelligence (CTI) information, and to this end implements the related smart contracts and gRPC calls. A more comprehensive discussion on this matter can be found in Chapter 6.

To interact with our VDR solutions, the identity and trust agents need to implement gRPC clients that consume the functionality exposed by the VDR. Such communication requires a valid subscription to the respective service, by each component. Upon successful subscription, a DID or TMB agent can request the creation, resolution, update ofdeletion ofa particular DID Doc or Trust Score. We note that such DID and TMB agents, are responsible for the logic behind managing identity and trust information, while the proposed VDR is only responsible for providing an efficient infrastructure for their management. In the case ofthe IdM, the Hyperledger Aries Framework Go [17] was used as a baseline and was extended with the gRPC client.

Example: We assume that a particular IdM agent is already subscribed to the gRPC service and wants to create a new DID document for an IoT device. The IdM agent constructs the DID Document using the public key related to the IoT device and sends it to the gRPC Server by calling the createDoc() gRPC service. The request is validated and authenticated by the gRPC server which then forwards it to the corresponding smart contract function that handles the storage of the DID Document in the Blockchain. This action triggers the emission of the docResolution event which, through the gRPC server reaches the DID agent and verifies the creation of the new identity in the Blockchain. We note that a similar process is followed for the other supported operation for both identity and trust information. It is worth mentioning, however, that in the case ofidentity information the agent must follow a standardized approach, complying to the W3C conformant erat DID method, which is described in the following section.

A DID method defines how designers and developers should materialise the features described by the W3C DID method specification [20] in association with a particular VDR. In this work, we have created the erat DID method, to define the DID scheme used in the context of the ERATOSTHENES project. The erat DID method has been published as an official DID method in the list of known DID Methods by W3C https://www.w3.org/TR/did-extensions-methods/#did-methods.

As the DID method specification suggests, each DID is described by a unique DID URI that is conformant with the Uniform Resource Identifier (URI) generic syntax. In our system we have defined the erat DID method to describe DIDs. The rules and decisions to produce DID URIs that belong to the erat method and the DID Syntax ABNF Rules are presented in Table 7.1.

An erat DID URI consists of four key components. It starts with the prefix “did:”, which is a universal identifier required by all DID URIs to conform to the official DID standard. According to RFC 3986[RFC] this “did:” prefix is followed by the method name—in this case, erat—which defines the ERATOSTHENES namespace. The remaining segments are specific to the method and must be globally unique within the ecosystem. The third segment is a globally unique identifier, which is the SHA-256 hash of the genesis block of the VDR ledger that the DID is associated with. Since each ledger has a unique genesis block, this hash allows a DID agent to identify a specific VDR. The final segment is an identifier linking to a specific entity. It is calculated as the SHA-256 hash of a combination of a random nonce, the genesis block hash, and the public key of the DID controller. The inclusionofarandomnonceenhancesprivacyandpreventslinkability,addingextra randomness to the identifier. This design prevents malicious actors from tracking a DID controller across networks by using its public key, ensuring that the identifier remains globally unique due to the nonce.

For the erat DID method specification, we have also defined key operations, including authorization mechanisms (e.g., cryptographic keys) and standard CRUD operations. The creation process is initiated by the DID agent via a service provided by the gRPC server, where the agent sends the controller’s public key, the ledger’s genesis hash, and the cryptographic details necessary for verification (as per W3C standards) to request the creation of a DID by the VDR. To resolve (i.e., read) a DID, the agent submits the DID URI to the VDR, which then returns the corresponding DID Document. For updates, the agent must provide the DID URI along with the requested changes, such as adding a new verification method. Finally, for deletion, the agent sends a deactivation request to the VDR using the DID and the associated public key. For both update and deactivation operations, the VDR ensures that the requester is the controller of the DID in question. The authentication method defined in the DID Document is used to verify the controller’s identity before performing these operations.

The most defining property ofthe proposed VDRsolution is its focus on efficiency. Towards this direction our contribution is twofold; on the one hand we increase the communication efficiency and scalability of blockchain-based VDR by integrating gRPC technology and on the other hand we integrate a novel hybrid consensus algorithm to HLF. In the remainder of this section, we elaborate on our key contributions.

As already mentioned, creating efficient and scalable VDR solutions is an open challenge. To expose their services in a user-friendly manner, most of the existing solutions [9, 17-19] rely on different protocols such as REST and WebSockets. However, compared to these approaches, research shows that gRPC technology can provide increased throughput and security [21]. This performance gain is largely attributed to its use of the HTTP/2.0 protocol, which allows for faster and more efficient bidirectional data transmission compared to the older HTTP/1.1.

In our solution the gRPC protocol was chosen to facilitate the interaction with the VDR due to its superior performance and robust security features (e.g., TLS for data confidentiality and authenticity). We note that such a choice is further justified by gRPC widespread adoption in various other platforms and frameworks, such as HyperLedger Fabric,⁴ Dropbox,⁵and Uber.⁶ As outlined in Section 7.3, we developed a bidirectional gRPC server to expose the VDR’s functionalities. This server can manage multiple secure channels, with each channel corresponding to a distinct gRPC client, such as DID agents within an IoT network. This design significantly improves the scalability of the system. The gRPC server implements various essential methods, including Subscribe, CreateDoc, and CreateTrustScore, to effectively manage identity and trust information stored in the VDR. To minimize the overhead associated with multiple TLS handshakes and enhance performance, both the gRPC server and clients make use of “Keepalive Settings.” This configuration ensures that only a single TLS handshake occurs at the beginning of the connection, allowing the secure channel to remain open and available for event transmission with the blockchain without repeated handshakes.

Next to the above, gRPC protocol performance is closely tied to the serialization method employed for data transmission, particularly the codec used for encoding messages between the server and clients. Several serialization protocols are available for use over a gRPC channel, each offering specific advantages based on the use case. Among the most prominent are Protocol Buffers,⁷ Gob,⁸ and JSON. Gob is a serialization format unique to the Go programming language, optimized for encoding Go data types but lacking cross-language support. Protocol Buffers (protobufs), developed by Google, provide efficient serialization ofstructured data and support a variety of programming languages. JSON, a well-established and standardized format, remains a popular choice for structured data representation due to its broad compatibility. To select which encoding method is more suitable for our VDR implementation, we performed benchmarks to assess the performance of various codec implementations. We present our experiments and discuss their results in Section 7.5.

The second major novelty ofour efficient VDRsolution is the integration ofa novel hybrid consensus algorithm in HLF [27]. Below we discuss its fundamental design principles and we proceed with presenting it implementation in HLF.

As already discussed, consensus algorithms are one of the most critical components ofblockchain technology, defining its key properties. Traditional leader-based approaches, such as the ones found in HLF, rely solely on voting and leader elections. Although quite efficient, these approaches lack flexibility and are not designed to cope with networks with fluid membership, such as dynamic IoT networks where nodes (e.g., devices) are frequently introduced or disbanded. Next to that, simpler algorithms like Raft cannot handle malicious entities, while more sophisticated approaches (e.g. smartBFT) introduce significant communication complexity.

On the other hand, modern blockchain consensus algorithms address the limitations of traditional approaches, effectively cope with variable membership in the network (e.g., public networks) while showcasing increased tolerance to malicious nodes. Due to their design however, the most prominent algorithms of these cate-gorycannotbeappliedtoanIoTcontext.Inparticular,algorithmssuchasProof-of-Work require considerable resources (e.g., computational power, space, TEEs etc.) which are not available in the resource-constrained IoT ecosystem. Next to that, less heavy-weight approaches such as Proof-of-Stake (PoS) or Proof-of-Importance (PoI) [28] may give an unfair advantage to particular nodes of the network (e.g., favouring nodes with high monetary investments in the network) related to the block proposal, effectively demotivating newcomers or nodes with less involvement in the network.

To mitigate these challenges, we propose an innovative hybrid consensus algorithm designed specifically for IoT systems, with a focus on being lightweight and fair. As shown in Figure 7.3, the algorithm is structured into two main components: a decentralized lottery-based mechanism for block proposal and a reputation-driven voting process for block finalization. The lottery mechanism leverages Verifiable Random Functions (VRFs), which enable nodes to independently and securely generate a random lot in a decentralized and verifiable manner. In particular, a VRF [22] operates by taking a public/private key pair and a seed as inputs, and then generating a hash as its output. While only the holder of the private key can compute the VRF hash, anyone with access to the corresponding public key can independentlyverifyitscorrectness.TheVRFoutputisuniquelydeterminedbythe combination of the private key and seed, resulting in a uniformly distributed outcome that enhances the element of randomness and fairness in the block proposal phase [23]. Therefore, using VRFs nodes are able to compute a unique verifiable lot (i.e., hash) for a particular round defined by the corresponding seed. We note that VRFs have been widely adopted in various consensus algorithms, including Algorand’s Pure Proof of Stake (PoS) model [24].

In the voting phase, a consortium of trusted nodes votes on the best seen block proposal (i.e., with highest lotter number) for the given round. The trustworthiness of each node is evaluated through an external reputation system. It is important to note that our proposed approach is flexible and not limited to any [29] specific reputation model, however, in the context of ERATOSTHENES we leverage the Trust Score information produced by the TMB component. In this work, we refer to trusted Orderer nodes (i.e., nodes with high reputation) as reputable and we allow them to participate in the voting phase. On the other hand, non-trusted nodes are called non-reputable.

Summarizing, the proposed algorithm deviates from traditional leader-based consensus models in Hyperledger Fabric (HLF) by eliminating the need for a designated leader to propose blocks. Instead, block proposals can originate from any network node through a randomized lottery process, with the final decision being made through a voting mechanism among trusted nodes. This lightweight, hybrid design is particularly suited for resource-constrained environments, such as those found in IoT networks, as it avoids the need for energy-intensive operations. Next, we delve into the implementation details of our solution.

We implemented the proposed consensus algorithm using Go programming language and integrated in HLF. The consensus process consists of three distinct phases: Proposal, Voting, and Commit, which we present below.

The Proposal phase begins when an Orderer node within the HLF network receives and organizes a batch of transactions into a block. During this process, the transactions included in the block are removed from the Orderer’s transaction pool to prevent duplication. Each Orderer then proposes its block to be appended to the shared ledger. To ensure fairness and randomness, each Orderer computes a Verifiable Random Function (VRF) using its private key and a seed derived from the previous block’s header.

The seed for the VRF is extracted from the header of the last confirmed block in the ledger, allowing any network node to verifythe VRF hash using the seed and the corresponding public key of the Orderer. For consistency, the first block added to the ledger uses a VRF generated from a “genesis seed,” which is randomlygenerated for each system to serve as the initialization point for the consensus mechanism.

Once the blocks are prepared, each Orderer broadcasts its proposed block to other Orderers while simultaneously listening for block proposals from others. In parallel, each Orderer continues to listen for incoming transactions from Peers,which are stored in the transaction pool for future proposals. The steps of this process are outlined in Figure 7.4.

This approach ensures decentralization by enabling any node to participate in block proposals, reducing potential bottlenecks caused by leader-based models, while maintaining security and randomness through the use ofVRFs.

Followingly, the Voting Phase (see Figure 7.5) is responsible for determining which block will be appended to the shared ledger. A key requirement for participation in this phase is the reputation of the Orderer. Specifically, only nodes with established reputations are allowed to take part in the voting process. The steps involved in this phase are detailed in the algorithm provided below. By the end of the Voting Phase, each Orderer should have reached a consensus on the winning block to be committed to the ledger.

Lastly, in the Commit phase each Orderer commits the winning block to the shared ledger. Once the block is successfully validated, indicating that consensus has been reached across all Orderers, each node updates its state in preparation for the next round of consensus.

There are two scenarios that an Orderer must account for: (a) if the accepted block was self-proposed, and (b) if the accepted block was proposed by another Orderer. In the first case, the Orderer takes no further action. If there are any remaining transactions in the transaction pool, the Orderer moves on to the next round and proposes a new block. In the second case, where the block was proposed by another Orderer, the node must update its transaction pool by removing any transactions that were processed in the accepted block.For this, the Orderer cleans its self-proposed block, eliminating from its pool any transactions that overlap with those in the accepted block. The remaining transactions from the self-proposed block are returned to the pool. The Orderer also removes any transactions that appear in the accepted block from the transaction pool.

An important aspect of this phase is handling transactions that are not yet known to an Orderer but appear in the accepted block, which could result in duplicates in future blocks. To mitigate this risk, any unknown transaction from the accepted block is temporarily stored and later crosschecked to ensure it is not reprocessed in subsequent rounds. The Commit Phase process is shown in Figure 7.6.

In this section we present the experimental evaluation of the proposed VDR solution. First, we discuss the assessment of the different serialization methods for the gRPC service of the VDR. Then we present the experimental evaluation of our integrated consensus algorithm in HLF.

As discussed in Section 7.4, different serialization methods have significant impact on the performance of the gRPC service (in terms of communication overhead). This evaluation will allow us to select a suitable serialization method for identity and trust information.

Existing benchmarks⁹typically evaluate codecs based on their performance and correctness. However, many of these assessments include redundant initialization phases, which can negatively impact the performance of certain codecs. In our evaluation we followed a similar approach, however, to improve accuracy, we optimized the approach by eliminating unnecessary encoding and decoding steps and enhancing the overall implementation. This allowed for a more reliable evaluation of each codec’s performance, focusing on time efficiency and memory usage during the serialization and deserialization processes. Furthermore, in our benchmark we extended the test to assess various serialization methods using different data structures (e.g., DID Documents) specific to our use case.

In more detail, we evaluated three codecs: Protocol Buffers, Gob, and JSON, as outlined in These were tested by sending a range of data structures—such as a basic struct, a DID Document, and an x509 Certificate—over the gRPC channel. The selection of these data structures reflected different levels of complexity, providing a comprehensive evaluation of each codec’s performance under diverse conditions. The experiments were conducted on aLinux system equipped with an Intel Core i7-9750H @2.6GHz and 16GB of RAM, ensuring a robust environment for testing.

To evaluate the performance of serialization (encoding) and deserialization (decoding), we conducted experiments using the aforementioned data structures.

We followed a similar approach to the existing benchmarks, and we evaluated the performance utilizing Go’s default benchmarking metrics such as the time per iteration, bytes allocated per operation, and the number ofdistinct memory allocations per iteration. The time per iteration captures overall performance and CPU usage, while the memory-related metrics focus on memory consumption during the operations. For each case 500 iterations were performed.

The serialization benchmark results are displayed in Table 7.2 while the deserialization results are presented in Table 7.3. Our findings reveal that Protocol Buffers (protobufs) consistently provide the fastest serialization times, outperforming the other codecs. In two exceptional instances, however, Gob surpasses Protocol Buffers in both memory consumption and CPU utilization. In particular, the better performance of Gob was shown when decoding simple structures and DID Document structures. The relatively poor performance of JSON when decoding DID Documents can be attributed to the nested nature of these structures, which requires JSON to handle multiple layers during the deserialization process, thereby increasing its complexity and processing time. Further information about the data structures, experimental setup, results, and the associated source code is available in our open-source repository.¹⁰ This repository provides additional insights into the performance of different codecs in serialization and deserialization operations.

The aim of this experiments is to evaluate the performance of our consensus algorithm implementation in HLF and determine how it compares with the existing algorithms in HLF, namely Raft and smartBFT. The primary objective of this evaluation was not only to assess the throughput and resource utilization of the new algorithm but also to observe its overall behaviour and stability under various workloads and network conditions. We designed the experiments to provide a robust comparison by employing a range of configurations and scenarios.

The experiments were conducted in a controlled virtual machine environment with the following hardware specifications:

• 24-core AMD EPYC 7452 x86-64 CPU

• 64GB of RAM

• SSD storage for improved data access speeds

To ensure the benchmarking process was standardized and the results were reproducible, we employed Hyperledger Caliper, a dedicated benchmarking tool developed by the Hyperledger Foundation to evaluate the performance of blockchain frameworks [25]. Caliper provides a comprehensive suite of metrics that allows users to measure various performance aspects, such as throughput, latency, and resource consumption, across different blockchain configurations.

In the experiments, Caliper was configured to generate a pool of 15,000 transactions, which were transmitted by a client application at a fixed rate of 1,500 transactions per second. This transaction rate was chosen to simulate realistic conditions, effectively stress-testing the consensus mechanisms. The transactions were distributed to each Orderer node by 24 concurrent worker processes. This setup provided a reliable framework to observe how the newly implemented consensus algorithm behaves under heavy workloads and how it compares to Raft and smartBFT in terms of performance.

We followed the benchmarking approach outlined in the smartBFT study [26], designing test scenarios with varying configurations of Orderers. These scenarios were structured to include clusters of different sizes and multiple transaction batch sizes. Specifically, for smartBFT, we used clusters composed of 4, 7, and 10 Orderers. In contrast, for the Raft and hybrid consensus algorithms, clusters of 5, 7, and 11 Orderers were employed. In each cluster configuration, transaction batch sizes of 250, 500, and 1000 transactions per block were tested to evaluate performance under differing workloads.

In our testing process, each configuration described above was subjected to six repetitions to ensure robust and consistent results. The performance metrics for the hybrid consensus algorithm, Raft, and smartBFT are presented in Figures 7.7, 7.8, and 7.9 respectively. Each figure presents the average value derived from the six iterations, providing a comprehensive overview of the system’s behaviour under different conditions.

By looking at the results, we see that Raft consistently demonstrated greater throughput compared to both smartBFT and the hybrid consensus approach. This performance advantage can largely be explained by Raft’s lower communication overhead. As a leader-based mechanism, Raft operates by electing a leader responsible for making decisions regarding which blocks to append to the ledger. Once this decision is made, the leader broadcasts the block to the other nodes (Orderers), thus significantlystreamlining the block addition process. This results in a reduced transaction lifecycle, as it requires only a single phase of communication between nodes, minimizing the amount of inter-node messaging required. In contrast, smartBFT, despite being leader-based, incurs additional communication overhead due to its multi-phase message validation process. Specifically, smartBFT required additional message exchanges during the Pre-prepare, Prepare, and Commit phases, adding complexity and slowing down the overall throughput. The hybrid consensus algorithm diverges from the leader-based paradigm, and although fairer in nature, it requires additional message exchanges between the nodes for proposing blocks and voting. In particular, in the hybrid consensus approach every node is expected to create a block proposal, while information dissemination is done using a gossip protocol.

Interestingly, despite smartBFT better performance compared to our implementation, a deeper analysis of the results revealed several critical insights:

• Reliability Concerns: One of the most significant findings was the issue of transaction failures observed with smartBFT, particularly as the number of Orderers increased. For instance, in the 7-Orderer configuration, transaction failures ranged from 0 to 17, while in the 11-Orderer setup, failures increased and varied between 0 and 226, representing approximately 1.5% of total transactions. In extreme cases, transaction failures exceeded 2000, accounting for roughly 13% of all transactions. We, however, excluded such edge cases in our final analysis as we did not consider them representative of smartBFT average behavior. In contrast, both Raft and the hybrid consensus demonstrated strong reliability, with no reported transaction failures.

• Duplicate Transactions: Another observation was the significantly higher number of duplicate transactions generated by smartBFT when compared to Raft and the hybrid consensus. In scenarios involving 11 Orderers, smartBFT recorded over 200 duplicate transactions, indicating inefficiencies in transaction handling and network synchronization, which could further complicate system performance under heavy loads.

• Handling of Batch Sizes: While the batch size (the number of transactions per block) was explicitly configured to specific values (e.g., 1000 transactions per block), smartBFT frequently committed blocks containing far fewer transactions than the specified batch size limit. This suggests that smartBFT

treats the batch size as a theoretical maximum, rather than a strict guideline, likely optimizing for other factors, such as network latency or node synchronization. This practice potentially gives smartBFT a throughput advantage, but it complicates direct comparisons with Raft and the hybrid consensus, both of which adhere strictly to the configured batch size. The lack of such optimizations in the hybrid consensus implementation means that while smartBFT may appear to outperform in some scenarios, the comparison is not entirely fair, as the two systems are optimized differently.

The impact ofbatch size on algorithm throughput was another key area of investigation. Increasing the block size from 250 to 500 transactions generally resulted in improved performance across all the tested configurations. However, the hybrid consensus displayed a unique pattern: its throughput continued to increase even with batch sizes of 1000 transactions, whereas smartBFT exhibited a slight decline, and Raft experienced a more severe drop in performance. This suggests that the hybrid consensus can better handle larger batch sizes without sacrificing throughput, while Raft and smartBFT might encounter bottlenecks or inefficiencies as the batch size grows. Moreover, our analysis revealed that increasing the number of Orderers (i.e., cluster size) generally had a negative impact on throughput across all algorithms. This decline in performance is primarily attributed to the additional communication overhead that comes with managing larger networks, as more nodes need to be coordinated, increasing the time and resources required to achieve consensus. However, one notable exception was Raft, which showed improved performance with a batch size of 500 transactions and 7 Orderers, suggesting that under certain conditions, Raft can manage increased network size more efficiently than the other algorithms.

In conclusion, while our implementation demonstrated promising results, particularly in terms of its ability to scale without transaction failures, further optimization is needed. Our current implementation, although functional, is still in the proof-of-concept stage and is not yet ready for production deployment. Future work will focus on reducing communication costs by optimizing message sizes and streamlining inter-node interactions. Additionally, we plan to enhance the robustness of the algorithm by incorporating features to handle node failures and dynamic network changes post-initialization.

In this chapter, we introduced a secure and efficient solution for managing identities and trust information in decentralized IoT environments. Unlike existing methods, our approach capitalizes on the robust security features of Blockchain technology while enhancing scalability through a fine-tuned gRPC implementation. To meet the increased decentralization demands of IoT networks, we integrated a novel hybrid consensus algorithm into the chosen blockchain infrastructure, specifically HyperLedger Fabric (HLF). We provided a detailed explanation of our design and presented evaluation results of the proposed Verifiable Data Registry (VDR) within the scope of the ERATOSTHENES project. As part of our ongoing efforts, we are currently working on validating these solutions in the project’s pilot implementations to further support and refine their functionality.

This work has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement no 101020416. The authors acknowledge the research outcomes of this publication belonging to the ERATOSTHENES (101020416) project consortium.