A Blockchain Network Communication Architecture Based on Information-Centric Networking

Abstract

Blockchain technology, as a distributed ledger technology, is becoming increasingly popular in various fields. However, the performance limitations of blockchain networks hinder their further development. Existing research on optimizing blockchain communication mechanisms based on P2P networks is constrained by the end-to-end transmission principles of TCP/IP networks, which lead to network congestion and bandwidth wastage during large-scale blockchain content distribution. Meanwhile, studies on ICN-based blockchain systems primarily focus on blockchain communication protocol implementation and compatibility within ICN/NDN networks. However, research on blockchain communication mechanisms in hybrid IP/ICN networking environments remains limited, failing to fully leverage ICN’s advantages to enhance the communication efficiency of existing blockchain P2P networks. To address this issue, this paper proposes BLOCK-ICN, an ICN-based blockchain network communication architecture compatible with IP networks. BLOCK-ICN enables ICN nodes with computing and storage capabilities to deploy blockchain applications, while maintaining compatibility with P2P networks. By leveraging ICN multicast technology, the architecture provides relay acceleration services for blockchain data dissemination. Specifically, in terms of network topology, BLOCK-ICN classifies network domains based on delay information provided by an enhanced resolution system and establishes select domain gateways based on data flow forwarding dependencies, thereby constructing a hierarchical and structured relay network topology. Regarding the broadcast protocol, ICN nodes perform parallel broadcasting via ICN multicast, and upon receiving messages, they further disseminate them to P2P nodes, reducing the overall network broadcast latency and bandwidth consumption. We extended SimBlock to implement and evaluate BLOCK-ICN. Simulation results demonstrated that, in a Bitcoin network with 16,000 nodes and an ICN node ratio of 1%, the broadcast delays for propagating blockchain data to 90% and 50% of the network were reduced by 25% and 33.2%, respectively, compared to Bitcoin.

1. Introduction

As a type of distributed ledger technology, blockchain technology has been widely applied in fields such as finance [1], Internet of Things [2], and healthcare [3], due to its characteristics of decentralization and immutability. However, existing mainstream blockchain systems face significant performance issues and cannot fully meet user demands. For example, the average transaction rate of Bitcoin is seven transactions per second (tps), while that of Ethereum is 15 tps, which is much lower than the average transaction rate of Visa (1700 tps) [4].

The performance of a blockchain system is mainly affected by the broadcast delay of the peer-to-peer (P2P) network and the network bandwidth [5,6]. In a blockchain system, transactions and blocks must be broadcast to all nodes in the network, which requires a certain amount of time to ensure that all nodes have received the transaction or block. Otherwise, network forks may occur, leading to system failure [7]. In the Bitcoin system, the system needs to maintain a block interval of 10 min to ensure that the fork probability is less than 10% [4,6]. At the same time, the process of broadcasting transactions and blocks among P2P nodes through a flooding protocol results in a large amount of redundant data transmissions, causing bandwidth waste and easily leading to network congestion. Lengthy broadcast delays and network congestion significantly increase the block interval, thereby reducing the performance of the blockchain system. Therefore, in order to improve the performance of a blockchain system, it is necessary to reduce the broadcast delay and bandwidth consumption in a blockchain network.

Current research on blockchain network communication mechanisms primarily focuses on optimizing the network topology and broadcast protocols in P2P-based networks. For instance, Kadcast [8] employs the structured network topology of Kademlia [9] to implement hierarchical broadcasting, effectively reducing redundant messages and improving propagation efficiency. Additionally, relay networks such as Falcon [10] and FIBRE [11] have been deployed in blockchain systems to accelerate block and transaction dissemination. The high-performance blockchain platform Solana [12] adopts the Turbine block propagation protocol, which fragments blocks into smaller data packets and disseminates them in a tree-structured manner. This approach alleviates network bandwidth pressure, enhances propagation speed, and improves system scalability.

However, these studies remain constrained by the end-to-end transmission design principles of TCP/IP networks. In large-scale blockchain content distribution scenarios, point-to-point unicast transmission leads to network congestion and bandwidth inefficiency [13,14].

Information-Centric Networking (ICN) [15] is an emerging network architecture that decouples content identifiers from locators by prioritizing information-centric communication. Features such as name-based addressing and routing, in-network caching, and multicast support [14,15] enable ICN nodes to participate in content caching and distribution, thereby enhancing content dissemination efficiency. This provides new opportunities for optimizing blockchain network communication.

Existing research on ICN-based blockchain communication [13,14,16] has primarily focused on the implementation and compatibility of blockchain communication protocols within ICN/NDN networks. However, research on blockchain network communication mechanisms in hybrid IP/ICN environments remains limited. Consequently, existing blockchain P2P networks have yet to fully exploit ICN’s advantages to improve communication efficiency.

To address this gap, this paper proposes BLOCK-ICN, an ICN-based blockchain network communication architecture compatible with IP networks. BLOCK-ICN enables the deployment of blockchain applications on ICN nodes equipped with computing and storage capabilities. While maintaining compatibility with P2P networks, it leverages ICN multicast techniques to provide relay acceleration services. Compared to prior studies, ICN nodes hosting blockchain applications can fully utilize their network node capabilities to optimize network topology and broadcast protocols using the delay information of the enhanced resolution system and leveraging ICN multicast capabilities.

Specifically, in terms of network topology, ICN nodes classify network domains based on the delay information provided by the enhanced resolution system, and establish the domain gateway based on data flow forwarding dependencies. This approach facilitates the construction of a hierarchical and structured relay network topology. Regarding the broadcast protocol, ICN nodes employ ICN multicast to achieve parallel broadcasting. Upon receiving a message, an ICN node rebroadcasts it to P2P nodes, thereby reducing the overall broadcast latency and bandwidth consumption in the network.

The main contributions of this paper are as follows:

• We propose BLOCK-ICN, an ICN-based blockchain network communication architecture compatible with IP networks that enables the deployment of blockchain applications on ICN nodes with computing and storage capabilities. While ensuring compatibility with existing P2P networks, BLOCK-ICN utilizes ICN multicast to provide relay acceleration services.
• We construct a hierarchical structured ICN relay network topology based on BLOCK-ICN. It utilizes delay information provided by the enhanced resolution system to partition network domains, and selects a domain gateway based on data flow forwarding dependencies, to optimize network topology alignment. Based on this topology, a parallel tree-based broadcast method leveraging ICN multicast is proposed, to reduce network broadcast latency and bandwidth consumption.
• We implemented a simulation of BLOCK-ICN using SimBlock. Experimental results demonstrated that, in a network with 16,000 nodes, compared to the Bitcoin network, when ICN nodes constituted $1\%$ of the total nodes, the broadcast latency for blocks to reach $90\%$ and $50\%$ of the network was reduced by $25\%$ and $33.2\%$, respectively, while maintaining good network scalability.

The remainder of this paper is structured as follows: Section 2 reviews existing blockchain network communication approaches and ICN-based blockchain research. Section 4 presents the design of the proposed BLOCK-ICN architecture. Section 5 provides a theoretical analysis of the proposed approach. Section 6 details the simulation experiments. Section 7 discusses future research directions. Finally, Section 8 summarizes the conclusions of this study.

2. Related Works

Blockchain Network Communication Process

The communication process between nodes in a blockchain network is shown in Figure 1. The blockchain nodes form a P2P network for communication, consisting of two phases: the network topology construction phase, marked by the black circle, and the message transmission phase, marked by the blue circle.

The construction of the network topology mainly includes node discovery, node connection, and neighbor detection and maintenance. The different connection methods between blockchain nodes result in different network topology structures, which have different impacts on the broadcast delay and can be measured by the network connectivity and network diameter. Currently, mainstream blockchain network topologies are classified into unstructured network topologies, such as the Bitcoin network [1], and structured network topologies, such as the Kademlia network topology of Ethereum [9] and the Chord network topology of NKN [17]. In unstructured network topologies, nodes are randomly connected [18], resulting in a larger network diameter. To reduce the network diameter, the BCBPT protocol uses a proximity clustering algorithm based on network hops between nodes to connect physically close nodes [7]. However, the BCBPT algorithm has a high complexity, as each node needs to calculate the network hops to all other nodes. Compared to unstructured topologies, structured topologies have better network connectivity and can reduce bandwidth waste. However, they also have a larger network diameter, because the network latency between nodes is not considered when nodes attempt to establish connections. Swift [19] uses unsupervised learning and greedy algorithms to optimize the P2P network topology and broadcast algorithm based on a structured network. However, nodes need to perform a large amount of data processing and analysis using unsupervised learning, which introduces significant computational complexity and node overhead. In addition, creating a structured network topology for a large-scale blockchain network (e.g., Ethereum with a node count of 10k) incurs significant computational costs. As the network size grows further, these costs will increase significantly, and the network latency will also increase.

Node failure detection refers to the use of a heartbeat mechanism [20] by the blockchain system to detect the existence of nodes when faults occur in the blockchain network. Here, the heartbeat mechanism refers to the keep-alive mechanism at the application layer. An application-layer heartbeat mechanism requires additional development, and users need to build a complex application logic to ensure the normal operation of the blockchain P2P network. Therefore, an application-layer heartbeat detection mechanism causes a significant amount of network bandwidth consumption, which affects the performance of the blockchain network.

The process of message transmission mainly includes transaction and block broadcasting, block synchronization, and network routing. The gossip algorithm [6,21] is a mainstream transaction and block broadcasting algorithm in blockchain networks. In a blockchain network, transactions and blocks are broadcast to neighboring nodes through an asynchronous and broadcast-based gossip algorithm. However, the multi-round broadcast of the gossip algorithm leads to a significant delay in block message broadcasting and redundant bandwidth waste. In order to accelerate blockchain broadcasting efficiency, some improved gossip broadcasting protocols [22,23] have been proposed. Currently, Bitcoin adopts the flood algorithm [24] to broadcast data, while Ethereum adopts a gossip-based broadcasting algorithm [25]. However, these broadcasting protocols send redundant data multiple times before the end condition is reached, resulting in significant bandwidth waste. Moreover, the transmission of multiple messages in the broadcasting protocols reduces the efficiency of message broadcasting [21]. Decker and Wattenhofer [6] attempted to optimize the Bitcoin network by removing the verification process and block propagation pipeline. However, their ideas need to be to proven with further experimentation.

The modern high-performance blockchain network platform Solana [12] optimizes peer-to-peer communication and broadcasting mechanisms across multiple layers. In addition to integrating the QUIC protocol at the transport layer to enhance data transmission efficiency, Solana employs the Turbine block propagation protocol. This protocol partitions blocks into smaller data packets and disseminates them in a tree-structured manner, thereby reducing the network bandwidth overhead, improving data distribution efficiency, and enhancing system scalability. However, constrained by the end-to-end transmission principles of TCP/IP networks, these optimizations can still result in network congestion and bandwidth inefficiencies during large-scale blockchain content distribution.

3. Blockchain Based on ICN

3.1. Introduction to ICN Networks

The challenges posed by the semantic overloading of IP addresses in traditional Internet protocols, particularly in terms of scalability, mobility, and security, have rendered existing network architectures insufficient to meet the demands of emerging applications and services. To address these limitations, the content-centric ICN architecture [15,26,27] has been proposed. By leveraging content naming and caching mechanisms, ICN enhances data transmission efficiency and aims to overcome the inefficiencies of conventional IP-based networks.

ICN can be categorized into two types based on name resolution and content routing mechanisms: Name-Based Routing (NBR) and Separate-Name-Resolution (SNR)-based routing. Representative NBR approaches include Named Data Networking (NDN) [26] and Content-Centric Networking (CCN) [28], whereas SNR-based solutions include MobilityFirst [29], PURSUIT [30], and SEANet [31]. As the SNR mechanism facilitates integration with existing Distributed Hash Tables (DHTs), IP networks, and network infrastructures, it enhances ICN’s compatibility with the current TCP/IP architecture. Therefore, this study focuses on ICN utilizing the SNR-based routing paradigm.

SEANet further developed an enhanced resolution system [32] to meet the requirements for deterministic resolution latency within a constrained domain. Figure 2 illustrates the architecture of this enhanced resolution system, where the lower layer represents the physical network, and the upper layer depicts the hierarchical resolution system. Black dots denote resolution nodes, white dots represent ICN nodes, and circles indicate different levels of resolution service domains. The system adopts a multi-tiered tree-like organizational structure, wherein resolution nodes at different levels provide hierarchical resolution services with deterministic latency enhancements for their respective resolution service domains. Higher-tier resolution nodes offer longer maximum resolvable latencies and extend their coverage over broader resolution service domains. As shown in the figure, let the maximum resolution latency of a level-i resolution node be $T_{ms}$. When an ICN node within the service area submits a resolution request to this resolution node, the query resolution latency remains below $T_{ms}$.

With continuous advancements in hardware capabilities, network devices have evolved beyond mere routing and forwarding functions to incorporate computational and storage capabilities. ICN nodes equipped with these capabilities leverage Software-Defined Networking (SDN) techniques in the control plane, on-the-fly forwarding capabilities in the data plane, and autonomous resolution services. These features enable support for a diverse range of applications, including network-layer multicast, computational offloading, storage, and resolution services, thereby providing more flexible and enriched network functionalities [31].

Blockchain Research Based on ICN

The integration of blockchain and ICN has been widely applied in domains such as the Internet of Things (IoT) and 5G/6G networks, effectively addressing critical challenges, including large-scale content distribution, data privacy protection, and identity authentication.

Among existing research on ICN-based blockchain systems, BlockNDN [13] implements a Bitcoin-like application on NDN, leveraging NDN’s in-network multicast and content-based routing to enhance blockchain efficiency. BoNDN, proposed by Guo et al. [16], facilitates blockchain applications on NDN by broadcasting transaction messages in the form of Interest packets and disseminating block data through a publish–subscribe mechanism. DIBN [33] introduced a Distributed Information-Centric Blockchain Network that assigns namespaces to different categories of data traffic and establishes a Connected Dominating Set (CDS) for full-mesh multicast, thereby improving network scalability and efficiency. Additionally, the study in [14] designed and implemented an Ethereum network operating on NDN.

However, existing research on ICN-based blockchain systems [13,14,16,33] has primarily focused on the implementation and compatibility of blockchain communication protocols within ICN/NDN networks. Limited studies have explored blockchain communication mechanisms in hybrid IP/ICN networks, leaving room for further optimization of blockchain P2P communication by leveraging ICN’s inherent advantages. Therefore, in the context of hybrid IP/ICN networking, optimizing blockchain communication mechanisms to harness ICN’s efficient content distribution capabilities remains an open research challenge.

4. Design

Focusing on the issues of broadcast delay and bandwidth consumption in blockchain networks, BLOCK-ICN deploys blockchain applications on ICN nodes with computational and storage capabilities, and optimizes the communication of the blockchain network in two stages.

In the stage of network topology construction, ICN nodes are deployed in existing P2P networks and the ICN blockchain network is partitioned with the help of an enhanced resolution system. Furthermore, in the ICN blockchain network, an algorithm for electing domain gateway nodes is proposed based on data flow forwarding dependencies between ICN nodes. At the same time, the failure detection protocol between domain gateway nodes and ICN nodes is improved to reduce bandwidth consumption.

In the stage of network message transmission, based on the ICN blockchain network topology, a parallel tree broadcasting mechanism based on ICN multicast is implemented. ICN nodes multicast messages intra-domain and inter-domain in parallel through the ICN multicast, and broadcast messages to overlay P2P neighbor nodes through unicast, ensuring network robustness and improving the broadcasting efficiency.

Figure 3 shows an overview of the BLOCK-ICN network topology. For simplicity, the ICN nodes in the figure are all full nodes, and it is assumed that SPV nodes are connected to full nodes as leaf nodes. The BLOCK-ICN network topology consists of an overlay P2P network layer and an underlay ICN network layer. The upper layer is the existing P2P network topology (such as Bitcoin, Kademlia, etc.), and the lower layer is the ICN blockchain network topology constructed based on network partitioning and domain gateway nodes. The routing table of the blockchain nodes in the P2P network only stores the neighbor node information of the overlay P2P network, while the routing table of ICN nodes not only stores the neighbor information of the overlay P2P network, but also stores the address information of intra-domain ICN nodes and the multicast service information of the underlay ICN network. The specific node descriptions are as follows:

• P2P node: Consists of full nodes in the P2P network, establishes neighbor relationships with ICN nodes and other P2P nodes, and is responsible for receiving unicast messages from neighboring nodes and forwarding them to other P2P nodes.
• ICN node: Consists of blockchain nodes deployed in the ICN network. In addition to storing the address information of overlay P2P neighbors, ICN nodes obtain and store the address information of intra-domain ICN nodes and the multicast service information of the intra-domain through the enhanced resolution system. As gateway nodes, they are responsible for forwarding multicast messages from domain gateway nodes to P2P nodes.
• ICN domain gateway node: Generated through the election of intra-domain ICN nodes, domain gateway nodes not only store the address information of overlay P2P neighbors, intra-domain ICN node address information, and intra-domain multicast information, but also update the multicast group service information and multicast group member information within the intra-domain and inter-domain through the enhanced resolution system. Acting as multicast sources, they broadcast messages to the multicast groups within the intra-domain and inter-domain.

4.1. Network Topology Improvement

4.1.1. Domain Partition Based on Enhanced Resolution System Delay

This paper partitions the network based on an enhanced resolution system, ensuring the maximum resolution delay at each resolution node. Figure 4 shows the network partition based on the enhanced resolution system, where the ICN network is divided into multiple regions according to the delay information of the distributed enhanced resolution system. $C_1$–$C_3$ represents ICN nodes, while R1-1, R1-2, and R1-3 act as first-level resolution nodes, providing intra-domain resolution services. R functions as the highest-level resolution node, providing inter-domain resolution services. There is a deterministic delay of Tms between the resolution nodes and the intra-domain ICN node; that is, $\forall v\in C_i,T_{(v,C_i)}\le T$. Under normal network conditions and without considering unexpected factors such as node failures, the delay between intra-domain ICN nodes is related to the deterministic delay T. It can be assumed that the physical locations of the intra-domain ICN nodes are close to each other. “Inter-BC-cluster” and “intra-BC-cluster” represent inter-domain and intra-domain blockchain service identifiers, respectively, indicating ICN nodes and ICN domain gateway intra-domain ICN nodes. All nodes register the mapping relationship between the service identifier and their own IP address with the enhanced resolution system. By querying the blockchain service identifier from the enhanced resolution system, nodes can obtain the address list of intra-domain ICN nodes, thus completing the partitioning of the ICN blockchain network. $iMGI{D}_i$ and $MGI{D}_i$ represent intra-domain and inter-domain multicast service identifiers, respectively. Domain gateway nodes can register intra-domain and inter-domain multicast services. For example, $iMGI{D}_3$ and $MGI{D}_3$ are the intra-domain and inter-domain multicast service identifiers registered by domain gateway node $v_3$. Other nodes join multicast groups and receive multicast messages from this domain gateway node by using multicast service identifiers.

Enhanced resolution nodes are responsible for maintaining the mapping relationship between the node list and the service identifier and providing registration, query, and deregistration services for nodes. When a node needs to leave a domain, it needs to send a deregistration message to the intra-domain resolution node. The intra-domain resolution node will delete the node’s address information from the registration list and send a successful deregistration message to the node.

The steps for a intra-domain ICN node to register a partition using the enhanced resolution system are as follows:

• Step 1: The intra-domain ICN node sends a registration message to the intra-domain resolution node R1-i, including the node’s address information and the intra-domain service identifier information (inter-BC-cluster).
• Step 2: After receiving the registration message, the intra-domain resolution node R1-i adds the node’s address information to the registration list of the corresponding service identifier and sends a registration success message.
• Step 3: The elected domain gateway node in the domain sends a registration message to the highest-level resolution node R, including the domain gateway node’s address information and the inter-domain service identifier information (intra-BC-cluster).
• Step 4: After receiving the registration message, the highest-level resolution node R adds the domain gateway node’s address information to the registration list of the corresponding service identifier and sends a registration success message.

In the process of partitioning the time-delay domain based on the enhanced resolution system, it is necessary to control the number of nodes in each region. On the one hand, having too many nodes in the region will increase the communication delay between nodes in the domain. On the other hand, having too few nodes will result in a large number of clusters, thus increasing the cost of inter-domain communication. According to previous studies [20,34], the optimization setting for the number of nodes in a cluster is a logarithmic function of $logN$, where N is the number of nodes in the entire network, and this quantity can be estimated. Nodes can control the granularity of the partition by selecting the service level of the enhanced resolution system, so that the number of nodes in the region remains around $O\left(logN\right)$.

4.1.2. Domain Gateway Node Election

We propose an algorithm for selecting domain gateway nodes in intra-domain ICN networks. This algorithm prioritizes nodes with higher local betweenness centrality as domain gateway nodes. The fundamental principle is to leverage packet forwarding information among ICN nodes to infer data flow dependencies and subsequently elect the nodes with higher local betweenness centrality as domain gateway nodes using the Byzantine fault-tolerant PBFT consensus protocol. Specifically, this algorithm consists of two parts: node local betweenness centrality evaluation and PBFT-based domain gateway node election.

Figure 5 illustrates the process of evaluating node local betweenness centrality within the domain. To facilitate the selection of matching packet messages, we utilize blockchain heartbeat messages transmitted by ICN nodes both within and outside the domain. To enable upstream intra-domain ICN nodes to accurately match packet information, a specific identifier must be embedded in the heartbeat message.

To ensure the security and reliability of the node local betweenness centrality evaluation, we employ a short signature $SI{G}_{ij}$, which is mutually negotiated between nodes and serves as the packet identifier. The following information must be maintained by intra-domain ICN nodes:

• intra-domain ICN node address information: ICN nodes acquire the address information of other intra-domain ICN nodes through the enhanced resolution system.
• Identity authentication information of intra-domain ICN nodes: Public key information $P{K}_{ij}$, exchanged between intra-domain ICN nodes, is used for identity authentication.
• data flow forwarding dependencies table: This table records data flow forwarding dependencies among intra-domain ICN nodes. If a node serves as an upstream node, it is marked as1; otherwise, it is marked as 0. This information is essential for evaluating the node local betweenness centrality within the domain. The score life cycle is defined as T ms. If an upstream node fails to transmit the next round of proxy request information packets within T ms, its data flow forwarding dependency status is reset to 0. The dependency relationship is formally expressed as

  $$\begin{array}{c}\hfill \forall G\in C,Scor{e}_G=[s_{G,1},s_{G,2},\dots ,s_{G,n}]\end{array}$$

  (1)

  $$\begin{array}{c}\hfill \forall s\in [s_{G,1},s_{G,2},\dots ,s_{G,n}],s\in \{0,1\}\end{array}$$

  (2)

  where C denotes the set of intra-domain ICN nodes, and $Scor{e}_G$ represents the data flow forwarding dependency list of node G.

The specific process for evaluating node local betweenness centrality is as follows:

• Step 1: The intra-domain ICN node G transmits blockchain heartbeat messages to inter-domain ICN nodes. These heartbeat messages randomly incorporate various co-signed information (e.g., $SI{G}_{GA}$, $SI{G}_{GB}$, $SI{G}_{GC}$), with each signature being included with a probability $p_G$ ($p\in (0,1)$), as negotiated with other nodes.
• Step 2: An upstream ICN node (e.g., node A) verifies whether the signature information corresponds to that of internal nodes by matching the predefined fields in the forwarded data packets. If a match is found and the associated IP address remains consistent, this confirms that the upstream node has received the heartbeat packet originating from the downstream node. The upstream node then sends a gateway request message to the downstream node and confirms its upstream status by signing the request with its private key.
• Step 3: Upon receiving the gateway request message, the downstream node verifies its legitimacy. If the request is deemed valid, the data flow forwarding dependency table is updated, and the relationship between the upstream node and downstream node is recorded.

During the domain gateway node election phase, intra-domain ICN nodes employ the PBFT consensus protocol to collectively derive a data flow forwarding dependency evaluation matrix $[Scor{e}_1,Scor{e}_2,\dots ,Scor{e}_n]$. The specific $n\times n$ evaluation matrix is illustrated in Figure 3.

$$\begin{array}{c}\hfill \left[\begin{array}{cccc}{s}_{1,1}& s_{1,2}& \cdots & s_{1,n}\\ s_{2,1}& s_{2,2}& \cdots & s_{2,n}\\ ⋮& ⋮& \ddots & ⋮\\ s_{n,1}& s_{n,2}& \cdots & s_{n,n}\end{array}\right]\end{array}$$

(3)

where $s_{i,j}$ represents the data flow forwarding dependency between node i and node j, taking a value of 1 if node j is an upstream node of i, and 0 otherwise. The weight of each node’s score is denoted by $\omega$. After normalization, the local betweenness centrality score of each node is computed as follows:

$$\left[\begin{array}{c}{s}_1\\ ⋮\\ s_n\end{array}\right]={\displaystyle \frac{1}{n}}·\left[\begin{array}{ccc}{s}_{11}& \cdots & s_{1n}\\ ⋮& \ddots & ⋮\\ s_{n1}& \cdots & s_{nn}\end{array}\right]\left[\begin{array}{c}{\omega }_1\\ ⋮\\ {\omega }_n\end{array}\right]$$

(4)

$$s_i={\displaystyle \frac{1}{n}}\sum _{j=1}^n{s}_{i,j}·{\omega }_j={\displaystyle \frac{1}{n}}\sum _{j=1}^n{s}_{i,j}$$

(5)

The candidate node with the highest local betweenness centrality score is selected as the domain gateway node based on the node local betweenness centrality evaluation table $[s_1,s_2,\dots ,s_n]$.

For a single round of elections, the specific algorithm is illustrated in Algorithm 1, where f represents the maximum number of Byzantine nodes, satisfying $f\le {\displaystyle \frac{n}{3}}$, with n being the total number of nodes. The election process consists of the following phases:

• Proposal phase: The candidate node p broadcasts a proposal message $\mathrm{PROPOSAL}$ along with its local betweenness centrality evaluation table ${\mathrm{Score}}_{\mathrm{p}}$ to other intra-domain ICN nodes.
• Voting phase: Upon receiving the proposal, each node verifies the proposal and multicasts the vote message $\mathrm{PREVOTE}$ and its own local betweenness centrality evaluation table ${\mathrm{Score}}_{\mathrm{r}}$ to other nodes.
• Proposal confirmation phase: After receiving at least $2f$ $\mathrm{PREVOTE}$ messages, each node constructs the local betweenness centrality evaluation table $[s_1,s_2,\dots ,s_n]$ based on the local betweenness centrality evaluation matrices of other nodes. The candidate node with the highest local betweenness centrality score is then selected and a new voting message $\mathrm{PRECOMMIT}$, along with the updated local betweenness centrality evaluation table, is multicast to other nodes.
• Election submission phase: After receiving at least $2f$ $\mathrm{PRECOMMIT}$ messages, the candidate node in the proposal is confirmed as the domain gateway node. The new domain gateway node information $\mathrm{COMMIT}$ is then multicast to all nodes.

Algorithm 1 Domain gateway node election algorithm

Input: Set of replicas R, fault tolerance parameter f, $f<{\displaystyle \frac{n}{3}}$     $[s_1,s_2,\dots ,s_n]$: node local betweenness centrality evaluation list     n: number of intra-domain ICN nodes     f: fault tolerance parameter, $f<{\displaystyle \frac{n}{3}}$ Output:     $v_{center}$: domain gateway node     $v_{center}\leftarrow \varnothing$     Proposer:     for each proposer request $<PROPOSAL,Scor{e}_p>$ do          Broadcast $<PROPOSAL,Scor{e}_p>$ to all replicas          Wait for $f+1$ matching prevote messages          Send prevote message to all replicas          Wait for $2f$ matching PreCommit messages          Send commit message to all replicas          Wait for $2f$ matching commit messages          Add $proposer$ to $Output$     end for     Replica:     upon receiving proposer request $<PROPOSAL,s_r>$     Validate $<PROPOSAL,s_r>$     Broadcast prevote message $<PREVOTE,Scor{e}_r>$ to all replicas     upon receiving $f+1$ matching prevote messages     Validate prevote messages     Broadcast PreCommit message $<PRECOMMIT,s>$ to all replicas     upon receiving $2f$ matching PreCommit messages     Validate PreCommit messages     Broadcast commit message $<COMMIT>$ to all replicas     upon receiving $2f$ matching commit messages     Validate commit messages     Add $proposer$ to $Output$

4.1.3. Optimization of the Liveness Protocol Between Domain Gateway Nodes and Intra-Domain ICN Nodes

By leveraging the historical heartbeat protocol information exchanged between ICN nodes during the local betweenness centrality evaluation phase, the liveness status of both domain gateway nodes and intra-domain ICN nodes can be indirectly determined. This optimization reduces the network communication overhead associated with the conventional heartbeat protocol, thereby enhancing the efficiency of the liveness protocol between domain gateway nodes and intra-domain ICN nodes.

Figure 6 illustrates a flowchart of the optimized heartbeat protocol. Domain gateway nodes determine the liveness of intra-domain ICN nodes indirectly by matching heartbeat messages exchanged between ICN nodes and other inter-domain nodes. Conversely, intra-domain ICN nodes infer the liveness of domain gateway nodes by receiving proxy requests from them. When a domain gateway node A sends a slow heartbeat request to an ICN node G and receives a reply, both parties transition to the slow heartbeat protocol. By reducing the frequency of direct heartbeat messages exchanged between domain gateway nodes and intra-domain ICN nodes, this optimization effectively minimizes network communication overhead while maintaining liveness detection reliability.

4.1.4. Fault Tolerance Strategy

To ensure the continuous operation of the network in the event of a domain gateway node failure, the candidate node with the second-highest local betweenness centrality score is selected as the backup domain gateway node. The backup domain gateway node is responsible for maintaining a backup of the routing information and multicast group information of the primary domain gateway node. In the event of a failure, the backup domain gateway node seamlessly takes over the functions of the primary domain gateway node, ensuring uninterrupted network operation.

4.2. Optimization of the Broadcast Protocol

Message Broadcast Protocol Based on ICN Multicast

In BLOCK-ICN, ICN nodes broadcast messages in parallel within and across domains using multicast. Upon receiving a message, an ICN node further propagates it to P2P nodes via the gossip protocol. Figure 7 presents a schematic diagram of the broadcast protocol based on ICN multicast. In this protocol, domain gateway nodes act as multicast sources, transmitting multicast messages to intra-domain and inter-domain ICN nodes for further dissemination. The specific message broadcasting process is as follows:

For domain gateway nodes,

• If the message originates from an intra-domain ICN node or a P2P node, the gateway node multicasts the message to both intra-domain and inter-domain multicast groups.
• If the message originates from an inter-domain gateway node via multicast, this indicates that the message has already been propagated across domains. In this case, the gateway node only needs to multicast the message to the intra-domain multicast group.

For regular ICN nodes,

• If the received message originates from a domain gateway node, the ICN node broadcasts the message to P2P nodes.
• If the message originates from an intra-domain regular ICN node or a P2P node, the ICN node first sends the message to the domain gateway node and then propagates it to the P2P nodes.

Figure 8 shows the architecture of the broadcast protocol based on ICN multicast and introduces the message broadcasting process of BLOCK-ICN when miner nodes come from the P2P network.

Firstly, P2P network miner nodes, as the message source, send block messages to their surrounding neighbor nodes. When the messages are forwarded to the ICN nodes, the ICN nodes broadcast block messages to other ICN nodes in the intra-domain and inter-domain multicast groups through ICN multicast, and forward the block messages to P2P network blockchain nodes. Finally, the block messages are broadcast throughout the entire network. The ICN blockchain network acts as a relay network, accelerating the global broadcast efficiency of block messages.

5. Method Analysis

In this section, we analyze the time complexity, security, and feasibility of the network partitioning method and domain gateway node selection algorithm in BLOCK-ICN.

5.1. Blockchain Partitioning Method Based on Enhanced Resolution System

To cluster based on geographical location and latency, existing research methods use community partitioning algorithms such as the K-Means algorithm [35,36], but these algorithms require a large amount of computational complexity and bandwidth consumption for clustering partitioning. The BCBPT protocol [37] recommends the closest available nodes to each other based on the physical geographical proximity of the DNS service nodes. However, partitioning based on the round-trip latency of $ping$ values between nodes also leads to significant bandwidth consumption and a high time complexity of $O\left(N^2\right)$. Compared to existing community partitioning algorithms, the partitioning method based on the distributed enhanced resolution system in this paper has the following advantages:

• Time Complexity: By using the latency information of the existing infrastructure enhanced resolution system as prior conditions, the additional probing and calculation of $ping$ value latency between nodes is reduced. Nodes only need to query the enhanced resolution system to obtain the addresses of other intra-domain ICN nodes, resulting in a time complexity of $O\left(1\right)$, thus reducing time complexity and bandwidth consumption.
• Security: The enhanced resolution system in the network acts as an independent third-party trusted infrastructure, similarly to the $DNS$ service in the $IP$ network. It only provides deterministic latency resolution services and does not participate in data transmission in the network. Therefore, a certain level of security in the network partitioning process can be ensured.
• Feasibility: When a new node joins or leaves the resolution domain, it only needs to send registration or deregistration message information to the enhanced resolution system nodes. The enhanced resolution system nodes update the registration information, without the need for a large-scale recalculation of the entire network. This reduces the computational complexity and improves scalability.

5.2. Domain Gateway Node Selection Algorithm

Existing domain gateway node selection methods include the K-Means algorithm, PageRank algorithm, LeaderRank algorithm, etc. These methods require continuous iterative calculation, which results in significant computational costs. Comparing with existing domain gateway node selection algorithms, we summarize the characteristics and advantages of the domain gateway node selection algorithm based on BLOCK-ICN.

5.2.1. Time Complexity Analysis

We evaluated the communication overhead of the domain gateway node selection algorithm for different types of actual network topologies, which is also reflected in the time complexity of the algorithm. The communication overhead of the algorithm mainly comes from the upstream and downstream message information between nodes (gateway request messages and proxy confirmation messages), as well as the communication overhead of the PBFT algorithm. Assuming there are n nodes in the domain network, for the PBFT algorithm, each node needs to send $n-1$ messages to other nodes. In the absence of Byzantine faults, the algorithm’s time complexity of PBFT is $O\left(n^2\right)$. Based on the support of ICN multicast technology among intra-domain ICN nodes, unicast between nodes can be optimized through multicast, reducing communication overhead and making the time complexity $O\left(n\right)$.

For star-shaped network topology, there is only one core layer node, and the communication cost for upstream and downstream message exchange is $2(n-1)$. The time complexity is $O\left(1\right)$. Adding the time complexity of the PBFT algorithm, the total time complexity is $O\left(n\right)$.

For a tree-shaped network topology, assuming the height of the tree is H and the width of each layer of the tree is $W_h$, where $h=1,2,\dots ,H$, the relationship with the number of network nodes n is $n=1+{\sum }_{h=1}^{H-1}{W}_h$. For convenience, we assume that the width of the tree under a specific height h is the same, denoted as $W_h$. The total number of upstream and downstream message exchanges that each layer of nodes needs to send to the downstream nodes is as follows:

$$\begin{array}{c}\hfill \mathrm{Layer}0:MS{G}_0=n-1\end{array}$$

$$\begin{array}{c}\hfill \begin{array}{cc}\hfill \mathrm{Layer}1:MS{G}_1& =w_1·{\displaystyle \frac{n-1-w_1}{w_1}}\hfill \\ \hfill & =n-1-w_1\hfill \end{array}\end{array}$$

$$\begin{array}{c}\hfill ⋮\end{array}$$

$$\begin{array}{c}\hfill \begin{array}{cc}\hfill \mathrm{Layer}h:MS{G}_h& =n-1-w_1-w_2-\dots -w_h\hfill \\ \hfill & =n-1-\sum _{h=1}^{H-1}{w}_h\hfill \end{array}\end{array}$$

Therefore, the total communication cost for upstream and downstream messages is

$$\begin{array}{c}\hfill \begin{array}{cc}\hfill MS{G}_{\mathrm{all}}& =MS{G}_0+MS{G}_1+\dots +MS{G}_{H-1}\hfill \\ \hfill & =(n-1)+\sum _{h=1}^{H-1}(n-1-\sum _{h=1}^{H-1}{w}_h)\hfill \\ \hfill & =H·(n-1)-\sum _{h=1}^{H-1}(\sum _{h=1}^{H-1}{w}_h)\hfill \end{array}\end{array}$$

furthermore,

$$\begin{array}{c}\hfill H·(n-1)-\sum _{h=1}^{H-1}(\sum _{h=1}^{H-1}{w}_h)\le H·(n-1)\le H·n\end{array}$$

Therefore, the communication cost between intra-domain ICN nodes does not exceed $2H·n$. Since H represents the maximum depth of the tree-like network, and the depth of tree-like networks in real networks is generally small, the time complexity of the local betweenness centrality evaluation algorithm for domain gateway nodes is $O\left(n\right)$. The overall time complexity is $O(n\ast m)$, which is $O\left(N\right)$, where m is the number of partitions in the network and N is the total number of nodes in the network. Compared to the $O\left(N^2\right)$ time complexity of the BCBPT algorithm [37] for partition selection in other blockchain networks and the $O(K·N)$ time complexity of the GPSC algorithm [36] improved by K-means, the time complexity of the domain gateway node election algorithm is lower, requiring smaller communication costs.

Although the algorithm has a lower time complexity and communication overhead, it is more suitable for layered network topologies such as star and tree topologies. In the case of a ring network topology, there may be a situation where domain gateway nodes cannot be selected in the early stage, because voting based on the PBFT algorithm provides a fault tolerance of $(n-1)/3$. The relationship between the total number of nodes n and the number of malicious nodes f is $n>3f$, so more than $2f+1$ nodes are required to vote, in order to select a domain gateway node. This means that if the number of downstream nodes of a candidate node does not exceed $2f+1$, a consensus cannot be reached to select a domain gateway node. For tree-shaped and star-shaped network topologies, due to their hierarchical nature, the core layer or the root node of the tree are more likely to obtain more than $2f+1$ votes, making it easier to select domain gateway nodes. However, for a ring network topology, there may be multiple boundary network nodes, and in the case of low data packet forwarding in the early stage, none of these boundary network nodes may have more than $2f+1$ downstream nodes, requiring multiple rounds of elections to select domain gateway nodes. In the face of the shortcomings of this algorithm, a certain amount of security can be sacrificed for improvements, such as reducing the number of nodes required to achieve consensus in the PBFT algorithm. However, even so, since most real-world physical network topologies are layered network topologies, such as tree-shaped and star-shaped topologies, this algorithm can still adapt to the majority of network topology scenarios.

In addition, compared to overlay P2P topologies, the link-layer network topology is more stable and does not experience frequent changes. The overall overhead of the domain selection algorithm can be reduced by extending the life cycle T of upstream and downstream relationships.

5.2.2. Security Analysis

In terms of security, we consider two types of attack approaches in the process of evaluating the local betweenness centrality between nodes, and analyze the defensive ability of our local betweenness centrality evaluation protocol against these two attack approaches.

The first type is a Sybil attack (witch attack), where malicious nodes intercept the heartbeat information of other nodes and forge their own upstream identity to obtain higher local betweenness centrality scores, thus affecting the election results of the domain gateway nodes. In our algorithm, downstream nodes can verify the identity of upstream nodes based on the corresponding private key signature information in the gateway request message, by carrying the negotiated signature information between nodes in the heartbeat message. Since malicious nodes cannot forge the signature information of other nodes, they cannot forge the upstream identity of other nodes, thus they cannot influence the election results of domain gateway nodes through Sybil attacks.

The second type is an Eclipse attack, where malicious nodes intercept the heartbeat information containing public key information of the targeted nodes, making the nodes upstream of the targeted nodes unable to match the heartbeat information, thus affecting the election results of the domain gateway nodes. In our algorithm, by randomly including public key information in the heartbeat message, only a part of the heartbeat message can be intercepted, which does not affect the privacy security between nodes. Moreover, the heartbeat message itself does not contain block and transaction information, so malicious nodes cannot obtain more valid information. The targeted nodes can judge whether they are under eclipse attacks based on the reply messages of the heartbeat messages. If no reply message is received, it can be considered that they are under eclipse attacks. At this time, the targeted nodes can choose to re-elect domain gateway nodes or choose not to elect domain gateway nodes until the attack is over. It should be noted that it is meaningless for malicious nodes to intercept all packet messages of the targeted nodes, because this can only block the targeted nodes from sending and receiving messages, but cannot control the access the targeted nodes have to the information.

5.2.3. Feasibility Analysis

The domain gateway nodes elected through the local betweenness centrality evaluation protocol only play a role in accelerating broadcasting through multicast, similarly to relay network nodes. This is different from the super nodes in the consortium chain. Domain gateway nodes have no additional privileges compared to other normal nodes. Therefore, we analyzed from the perspective of game theory and concluded that this it the optimal choice for core layer nodes to serve as domain gateway nodes for both core layer nodes and edge nodes, reducing the possibility of edge nodes competing for domain gateway nodes and nodes behaving maliciously, which proves the feasibility of the algorithm.

In order to analyze the benefits and costs of core layer nodes and edge nodes competing for domain gateway nodes, we designed a non-cooperative complete information static game model between core layer nodes and edge nodes:

$$G=(\{P_1,P_2\},\{S_1,S_2\},\{u_1,u_2\})$$

In this model, edge nodes can also represent intermediate layer nodes, but the parameters need to be adjusted accordingly.

Where $P_1$ and $P_2$ represent core layer nodes and edge nodes, respectively, and both types of nodes have the same two strategy sets, namely competing for domain gateway nodes and not competing for domain gateway nodes. Therefore, the strategy sets are

$$S_1=\{\mathrm{Compete},\mathrm{Not}\mathrm{Compete}\}$$

$$S_2=\{\mathrm{Compete},\mathrm{Not}\mathrm{Compete}\}$$

$u_1$ and $u_2$ represent the profit functions of the core layer node and the edge node, respectively. The profit function is defined as “profit-cost”. For the core layer node $u_1$, the profit function is

$$u_1=\left\{\begin{array}{cc}R·P\left(\alpha \right)(1+\delta ·P\left(c\right))(1+\tau \left(t_1\right))-C-O,\hfill & \mathrm{if}{P}_1\mathrm{competes}\mathrm{and}{P}_2\mathrm{competes}\hfill \\ R·P\left(\alpha \right)(1-\tau \left(t_2\right))-C-O,\hfill & \mathrm{if}\mathrm{only}{P}_2\mathrm{competes}\hfill \\ R·P\left(\alpha \right)(1+\delta )(1+\tau \left(t_1\right))-C-O,\hfill & \mathrm{if}\mathrm{only}{P}_1\mathrm{does}\mathrm{not}\mathrm{compete}\hfill \\ R·P\left(\alpha \right)-C-O,\hfill & \mathrm{if}{P}_1 \mathrm{and} P_2\mathrm{does}\mathrm{not}\mathrm{compete}\hfill \end{array}\right.$$

For the edge node $u_2$, the profit function is

$$u_2=\left\{\begin{array}{cc}R·P\left(\alpha \right)(1+\delta ·(1-P\left(c\right)))(1-\tau \left(t_2\right))-C-O,\hfill & \mathrm{if}{P}_1\mathrm{competes}\mathrm{and}{P}_2\mathrm{competes}\hfill \\ R·P\left(\alpha \right)(1+\delta )(1-\tau \left(t_2\right))-C-O,\hfill & \mathrm{if}\mathrm{only}{P}_2\mathrm{competes}\hfill \\ R·P\left(\alpha \right)(1+\tau \left(t_1\right))-C,\hfill & \mathrm{if}\mathrm{only}{P}_1\mathrm{competes}\hfill \\ R·P\left(\alpha \right)-C,\hfill & \mathrm{if}{P}_1 \mathrm{and} P_2\mathrm{does}\mathrm{not}\mathrm{compete}\hfill \end{array}\right.$$

Here, R represents the income from obtaining the right to bookkeeping, $P\left(\alpha \right)$ is the probability function of nodes mining blocks, and $\alpha$ is the computational power factor that represents the computational power of the node. C represents the computing cost required to mine blocks. In this game model, we assume that the income from obtaining the right to bookkeeping and the computational power are the same for both types of nodes; that is,

$${\alpha }_1={\alpha }_2=\alpha ,R_1=R_2=R$$

$\delta$ represents the profit coefficient obtained by the domain gateway node through priority block packaging after becoming a domain gateway node, $P\left(c\right)$ represents the probability of the core node becoming a domain gateway node when both types of nodes compete for the domain gateway node, and $1-P\left(c\right)$ represents the probability of the edge node becoming a domain gateway node. $\tau \left(t\right)$ represents the absolute value function of the difference in message broadcast delay after becoming a domain gateway node, where t represents the broadcast delay, and O represents the additional communication and bandwidth cost required after becoming a domain gateway node.

On the one hand, for the core-layer nodes, regardless of whether they become domain gateway nodes or not, they need to incur the same cost of bandwidth and communication expenses O. This is because whether the message is broadcast from outside the domain to the inside, or from inside the domain to outside, the data packets need to be forwarded by the core-layer nodes to other nodes within and between domains. For example, even if the edge node becomes a domain gateway node, the data packets of transactions and blocks still need to be forwarded by the core-layer node to the edge domain gateway node. Although the core-layer node cannot perceive the specific information of the data packet, it still needs to incur the cost of bandwidth and communication to forward the data packet. At the same time, after the core-layer node becomes a domain gateway node, based on the matching of the multicast tree topology and the underlying network topology, the broadcast delay can be reduced, and the profit from the accounting of intra-domain ICN nodes can be increased by $1+\tau \left(t_1\right)$. Therefore, by comparing the sizes of the profit functions, it can be concluded that the optimal strategy for core nodes is to compete for the domain gateway node.

On the other hand, for edge nodes, if they become domain gateway nodes, not only do they need to incur additional bandwidth and communication expenses O, but also the mismatch between the multicast tree topology, with themselves as the multicast source, and the underlying network topology will result in a greater broadcast delay. This may cause the blocks packaged by themselves to become orphaned and discarded, thereby reducing the profit of accountability brought by becoming a domain gateway node by $1-\tau \left(t_2\right)$. Since the delay of intra-domain ICN nodes is small, it can be assumed that the profit obtained by the domain gateway node from prioritizing block packaging is less than the additional bandwidth and communication expenses O. Furthermore, when both edge nodes and core nodes compete for the domain gateway node, the probability $P\left(c\right)$ of core nodes becoming the domain gateway node is much greater than the probability $1-P\left(c\right)$ of edge nodes becoming the domain gateway node. Therefore, by comparing the sizes of the profit functions of edge nodes, it can be concluded that the optimal strategy is for edge nodes to not compete for the domain gateway node.

Due to the fact that, in this game model, the optimal strategy for any player’s strategy set is the strategy combination $(P_1\mathrm{competing},P_2\mathrm{non}-\mathrm{competing})$, this game model possesses a Nash equilibrium point, which is the optimal strategy combination. Consequently, it can be concluded that the optimal strategy for core-layer nodes is to compete for the domain gateway node, and the optimal strategy for edge nodes is to not compete for the domain gateway node, which ensures the maximization of the profit for both core-layer and edge nodes.

6. Evaluation

In this section, we conducted several experiments to evaluate BLOCK-ICN. First, we introduce the experimental settings, including the platform configuration, implementation, and evaluation metrics. Then, we perform a comprehensive analysis of the experimental results and compare BLOCK-ICN with the Bitcoin network.

6.1. Experimental Settings

6.1.1. Implementation

Conducting experiments on an actual public blockchain network is challenging, because it is difficult to obtain complete information about the entire network in a large-scale public blockchain network. Additionally, in small-scale private blockchain networks, it is not possible to observe the block broadcasting behavior of real-scale networks. Therefore, evaluating new solutions in actual scenarios is not feasible. As an alternative approach, we chose to use a simulation to evaluate and validate the new solution, to ensure the experimental accuracy. We implemented a simulation of the BLOCK-ICN network architecture based on SimBlock [38,39] and simulated its performance. SimBlock is an event-driven simulator, where all nodes in the network can generate message and block events. We made improvements to the SimBlock simulator to perform the simulation of the BLOCK-ICN network architecture. Through the simulation experiments, we evaluated the performance of BLOCK-ICN in terms of broadcast delay, scalability, and bandwidth consumption in a scenario where the overlay P2P network topology was the Bitcoin network.

However, it is worth noting that SimBlock is a network simulator developed based on the P2P network layer. Its minimum simulation unit is the blockchain node, and it cannot simulate the routing units and network layer protocols in the ICN network. Therefore, we could not simulate the multicast and routing mechanisms of the ICN network realistically. Although existing simulation platforms such as NS2 and NS3 can simulate both the application layer and the network layer, it is difficult to simulate a compatible ICN network and Bitcoin network in NS3. The main reasons for this are as follows:

• The simulation parameters of the Bitcoin network are usually obtained from real-world blockchain network data, using tools like xblock or blocksci. These tools can provide node information in the blockchain network but cannot provide the topological information of routers in the blockchain network. Therefore, it is not possible to construct the underlying network topology of a real blockchain network. It is unreasonable to conduct simulation experiments on other networks or self-designed underlying network topologies, because it is not possible to acquire the node distribution in the blockchain network on other networks and this cannot ensure the authenticity of the simulation experiments.
• To implement simulations that are compatible with both the blockchain network and the ICN network layer, extensive code modifications to NS3 would be required. In simulation experiments, for a blockchain network with a blockchain node quantity in the order of 10,000, a larger-scale underlying network topology would need to be implemented in the underlay ICN network layer, which greatly increases the complexity of the experiments.

In addition, the simulation of ICN networks and their multicast protocols is not the main focus of this paper. The main research focus is to improve the SimBlock simulator to implement ICN nodes, ICN blockchain network topology, and broadcast protocols based on ICN multicast, in order to evaluate the performance under the BLOCK-ICN network architecture. Based on existing studies comparing the performance of multicast and unicast in IP networks and ICN networks, we introduced the bandwidth optimization brought by ICN multicast as a parameter into SimBlock for modeling. In the future, through comparing the simulation results of different ICN multicast algorithms and different underlying network topologies and protocols, we could evaluate the performance of the BLOCK-ICN network architecture. This will also be one of our future works. In this paper, we used a general ICN multicast algorithm [14] and basic underlying network topology and protocols as the basis for the simulation experiments, to evaluate the performance of the BLOCK-ICN network architecture.

6.1.2. Platform Configuration

We used a desktop computer with an Intel Core i5-10505 CPU@3.20GHz processor, 32 GB memory, and 1 TB hard drive as the experimental platform. In addition to using SimBlock for simulation, we also performed experimental data analysis and plotting using Python. Detailed information about the specifications of the experimental software and hardware is shown in

Table 1. Specifications of experimental software and hardware.

Software and Hardware	Versions/Models
Operating System	64-bit Windows 10
Processor	Intel Core i5-10505
CPU	3.20 GHz
RAM	32 GB DDR4
Hard Drive	1 TB SSD
Platform	SimBlock
IDE	PyCharm and IntelliJ
Programming Language	Python 3.10 and Java

.

6.1.3. Simulation Experiment Parameters

We used the network parameters from Aoki and Nagayama et al. [38,40]. The sources of the network parameters are listed in Table 2. The network parameters included node distribution, network latency, and bandwidth. The following are the sources and calculation methods for the network parameters:

Node Distribution

We used the node quantity data provided by Bitnodes [41] for each country. The SimBlock model involves six regions (North America, Europe, South America, Asia, Japan, and Australia). Therefore, the distribution of ICN nodes and Bitcoin nodes was allocated based on the quantity in each region, and ICN nodes and Bitcoin nodes were randomly deployed in each region.

Network Latency

We obtained network latency data between major cities in different regions from WonderNetwork [42] and used the weighted average of network latency as the network latency between regions. A 20% value for the dispersion of the Pareto distribution was considered as the propagation delay.

Bandwidth

We obtained the network bandwidth data between major cities in different regions from testmy.net [43] and used the weighted average of network bandwidth as the network bandwidth between regions.

Finally, we list the parameters used to simulate the BLOCK-ICN and Bitcoin networks using SimBlock in Table 2.

Table 2. Network simulation parameter settings.

Parameter	Bitcoin
Node Quantity	6000, 9000, 10,000, 13,000, 16,000 [41]
Block Generation Time	10 min [44]
Block Size	0.5 MB [44]
Node Neighbor Quantity	Distributed according to Miller et al. [18]
Node distribution	Bitnodes [41]
Network latency	WonderNetwork [42]
Network bandwidth	testmy.net [43]

Table 2. Network simulation parameter settings.

Parameter	Bitcoin
Node Quantity	6000, 9000, 10,000, 13,000, 16,000 [41]
Block Generation Time	10 min [44]
Block Size	0.5 MB [44]
Node Neighbor Quantity	Distributed according to Miller et al. [18]
Node distribution	Bitnodes [41]
Network latency	WonderNetwork [42]
Network bandwidth	testmy.net [43]

In addition, under the same network parameter conditions, we implemented the Kadcast protocol in SimBlock, following the parameters referenced in [8]. The network topology was based on Kademlia, which allowed us to conduct simulation experiments to evaluate BLOCK-ICN’s performance under different network topologies. During the BLOCK-ICN simulation, we set the election score weight of each ICN node to be $\omega =1$. And we used the traditional Legacy block broadcast protocol and compact block relay(CBR) protocol as the P2P layer broadcast protocol.

6.1.4. Simulation Evaluation Metrics

In order to observe the optimization effect of BLOCK-ICN compared to the bitcoin network, the variables of the experiment included the blockchain message broadcast coverage, blockchain network scale, proportion of ICN nodes, ratio of unicast neighbors of ICN nodes, bandwidth between ICN nodes, and positions of miner nodes. By controlling the above variables, we selected the following metrics to evaluate the optimization of the blockchain network:

• Broadcast delay: The broadcast delay of the blockchain network refers to the time required for transactions and blocks to be broadcast in the network. In the experiment, we selected the broadcast delay of blocks in the network as the main reference, and we fixed the number of blockchain network nodes to 16,000, which is the current scale of the actual Bitcoin network. We compared the changes in block broadcast time under different broadcast coverage rates between BLOCK-ICN and the Bitcoin network.
• Network scalability: Network scalability refers to the changes in network broadcast delay as the number of network nodes increases. According to data from bitnodes [41], the number of Bitcoin nodes was about 6000 in 2015, about 9000 in 2019, and was estimated to be about 16,000 in 2023. Therefore, in our experiment, network scalability refers to the changes in the time required to broadcast blocks to the entire network as the number of nodes increased from 2000 to 16,000.
• Network load: Since simulating ICN multicast in the P2P network is difficult, we based our analysis on the existing research on NDN multicast and IP unicast bandwidth utilization in blockchain networks [14], and we applied the bandwidth optimization parameters set in the simulation experiment. We compared the bandwidth consumption under different network scales.

6.2. Broadcast Delay Results

The block broadcast delay of BLOCK-ICN and the Bitcoin network varied with the change in broadcast coverage, as shown in Figure 9. The horizontal axis represents the broadcast coverage of network blocks, and the vertical axis represents the average broadcast time of a single block. With the network nodes fixed at 16,000, the unicast neighbor node ratio in the ICN blockchain was 1, and the miner position was set as the ICN domain gateway node. From the experimental results, it can be seen that the broadcast time of BLOCK-ICN network at different broadcast coverages was smaller than that of the Bitcoin network. Additionally, as the percentage of ICN nodes in BLOCK-ICN increased, the broadcast time of blocks at different broadcast coverages gradually decreased. From the left graph, it can be observed that the broadcast time for a broadcast coverage of 90–100% was significantly greater than the broadcast time for other stages. Therefore, we took the broadcast time at a broadcast coverage of 90%, which represented the time it takes for blocks to be broadcast to most nodes in the network, as the evaluation indicator. At a broadcast coverage of 90%, the block broadcast time for the Bitcoin network was 5336.0 ms, while for the ICN nodes with a ratio of 25% and 100%, the broadcast times were 1997 ms and 802 ms, respectively. Compared to the Bitcoin network, the BLOCK-ICN network reduced the broadcast time by 62.6% and 84.9% for ICN node ratios of 25% and 100%, respectively. In summary, BLOCK-ICN exhibited a better network broadcast delay performance than the Bitcoin network.

To evaluate the broadcast delay optimization of BLOCK-ICN across different network topologies and protocols, we conducted experiments with a fixed network size of 16,000 nodes. Figure 10 and Figure 11 illustrate the variation in broadcast coverage over time for ICN node ratios of 1% and 10%, respectively.

For a broadcast coverage of 90%, the results indicate that when the ICN node ratio was 1%, BLOCK-ICN achieved a broadcast delay reduction of 24% compared to Bitcoin, 13% compared to the CBR protocol, and 27% compared to Kadcast. These findings suggest that BLOCK-ICN provides significant optimization for both unstructured and structured P2P network topologies, while its improvement over the CBR protocol was relatively limited. The primary reason for this is that, under the same conditions, CBR transmits compressed blocks, reducing the potential for further broadcast delay optimization.

Furthermore, when the ICN node ratio increased to 10%, BLOCK-ICN exhibited an even greater improvement across different network topologies and protocols, demonstrating its enhanced effectiveness as the proportion of ICN nodes grew.

In the BLOCK-ICN network and bitcoin, the block broadcast delay varied with the broadcast coverage rate at different miner locations, as shown in Figure 12 and Figure 13. Under the conditions where the ICN node ratio was 25% and 100%, respectively, the miner nodes were set as ICN domain gateway nodes, ICN ICN nodes, and overlay P2P nodes, and the changes in broadcast time were compared. From the experimental results, it can be seen that when the miner nodes were in the ICN network, the block broadcast time was significantly lower than the broadcast time of the miner nodes in the P2P network. Specifically, when the broadcast coverage rate was 90%, with an ICN ratio of 25%, the block broadcast time of the ICN ICN nodes as miner nodes was reduced by 72% compared to with the nodes in the bitcoin network at the same location being miner nodes, while the block broadcast time of overlay P2P nodes as miner nodes in BLOCK-ICN network was only reduced by 32.9% compared to the bitcoin network. Moreover, when the ICN domain gateway nodes were used as miner nodes, the reduction in block broadcast time was only significant with lower broadcast coverage rates. When the network broadcast coverage rate was high, the location of miner nodes in the ICN network had little impact on the block broadcast time. In summary, in the BLOCK-ICN network, the broadcast delay of ICN nodes as miner nodes was significantly shorter than that of overlay P2P nodes as miner nodes, which indicates that ICN nodes are more suitable for deployment as miner nodes to improve broadcast efficiency. The comparison of broadcast efficiency between ICN domain gateway nodes and ICN ICN nodes as miner nodes, under the condition of block broadcast to the majority of nodes in the network, indirectly verified the feasibility of selecting network core nodes as domain gateway nodes, as stated in the algorithm analysis section.

Figure 14 shows the variation in the block broadcast delay of BLOCK-ICN and Bitcoin with respect to the unicast ratio of ICN nodes to neighboring nodes, with a network size of 16,000 nodes, 100% ICN node ratio, and miners located at domain gateway nodes. From the graph, it can be observed that, compared to the Bitcoin network, BLOCK-ICN had lower block broadcast delays when different ratios of neighboring nodes were selected for unicast. However, as shown in Figure 15, when the unicast ratio of ICN nodes to neighboring nodes was below 0.6, the block broadcast delay gradually decreased as the unicast ratio increased, but with a small reduction rate. However, when unicast was performed for all neighboring nodes, the broadcast delay actually increased. This is because, while performing multicast, unicast to all neighboring nodes results in duplicate block receptions, increasing the network load. Therefore, in practical applications, based on the network load, multicast can be used for broadcast, along with the selection of appropriate neighboring nodes for unicast to achieve the optimal broadcast delay.

Figure 16 shows the variation in the block propagation delay in BLOCK-ICN and the bitcoin network under different ratios of ICN nodes. The horizontal axis represents the percentage of deployed ICN nodes in BLOCK-ICN, with 0 indicating the bitcoin network. The vertical axis represents the block propagation time under different broadcast coverage rates. According to the experimental results, it can be observed that, as the ratio of ICN nodes increased, the block propagation time under different broadcast coverage rates gradually decreased, but the rate of decrease slowed down. When the percentage of ICN nodes was less than 25%, the deployment of ICN nodes had a significant impact on the block propagation time. However, when the percentage of ICN nodes exceeded 25%, the deployment of additional ICN nodes had a smaller impact on the block propagation time. Specifically, under a broadcast coverage rate of 90%, when the percentage of ICN nodes increased from 0 to 25%, the block propagation time decreased by 62.6%. However, when the percentage of ICN nodes increased from 75% to 100%, the block propagation time only decreased by 18.6% relatively. Therefore, by increasing the ratio of ICN nodes deployed in BLOCK-ICN, the block propagation time can be reduced, especially when the ratio of ICN nodes is low. However, when the ratio of ICN nodes is high, the improvement in block propagation time by deploying additional ICN nodes is limited.

We also analyzed the broadcasting efficiency of the ICN blockchain network as a relay network in the BLOCK-ICN network. In the actual Bitcoin network scenario, the relay network has a larger bandwidth. We referred to the settings in SimBlock [38], where the bandwidth between relay network nodes is ten times the usual network bandwidth. Taking into account the proportion of ICN nodes in the actual relay network in the Bitcoin network and the previous experimental results, we set the range of ICN node proportion from 0% to 25% and also considered the case with a small proportion of ICN nodes (such as 1%). Figure 17 shows the broadcast time of ICN relay nodes with broadcasting coverage of 50% and 90% under different ratios. Figure 18 compares the broadcast time of BLOCK-ICN with a proportion of ICN nodes of 1% and 10% in the relay network (high bandwidth) and the non-relay network (normal bandwidth) under different broadcasting coverage rates. It can be seen from Figure 17 that as the proportion of ICN relay nodes in the blockchain network increased, the block broadcasting time gradually decreased. In addition, it can be observed from Figure 18 that the reduction in broadcast time was more significant with ICN relay nodes under a broadcasting coverage rate of 50%, and when the broadcasting coverage rate was 90%, the broadcast time with the deployment of ICN relay nodes was basically the same as that without ICN relay nodes. We can also see that deploying a small number of ICN nodes in the blockchain network can significantly improve the blockchain broadcasting efficiency. For example, deploying only 1% of ICN relay nodes reduced the block broadcasting time by 26.8% and 37.5%, respectively, at broadcasting coverage rates of 90% and 50%, compared to the Bitcoin network. In addition, deploying only 1% of ICN non-relay nodes also reduced the broadcast time by 25% and 33.2%. In summary, in the BLOCK-ICN network architecture, deploying a small number of ICN nodes in the blockchain network can significantly improve the broadcasting efficiency of blocks. Deploying ICN nodes as high-bandwidth relay nodes can improve the broadcast efficiency under low broadcasting coverage rates, but under high broadcasting coverage rates, there is little difference in broadcast efficiency between deploying ICN nodes as relay nodes and non-relay nodes.

6.3. Network Scalability

In the case where the number of network nodes was increased from 2000 to 16,000, the variation in block broadcast time to the entire network for BLOCK-ICN and the bitcoin network was as shown in Figure 19. The horizontal axis represents the network size, while the vertical axis represents the average time for a single block to be broadcast to the entire network. Based on experimental results under the conditions of a 100% ICN node ratio, a unicast neighbor node ratio of 1 for ICN nodes, and miners located at domain gateway nodes, it can be observed that as the blockchain network size increased, both the BLOCK-ICN and bitcoin networks experienced an increase in block broadcast time. However, for the same network size, the block broadcast time for BLOCK-ICN was smaller than that of the bitcoin network. For example, when the network size was 16,000, the block broadcast time for the bitcoin network was 16,899.3 ms, while for BLOCK-ICN, it was 2385.4 ms, requiring less time for block broadcast. Furthermore, with an increased network size, BLOCK-ICN exhibited smaller variations in block broadcast time. For instance, when the network size increased from 6000 to 16,000, the block broadcast time for the bitcoin network required 3621.8 ms, while for BLOCK-ICN it was 640.1 ms. Therefore, it can be concluded that BLOCK-ICN had a better network scalability performance compared to the bitcoin network.

As illustrated in Figure 20, we evaluated the broadcast delay of BLOCK-ICN under an extreme scenario with 100,000 network nodes, maintaining an ICN node ratio of 1%. The broadcast delays in different network topologies were compared, and the results are further contrasted with those in Figure 21, which presents the case for 16,000 nodes.

In Figure 21, compared to the Bitcoin network, BLOCK-ICN reduced the broadcast delay for propagating blockchain data to 90% and 50% of the network by 25% and 33.2%, respectively.

Under the 100,000-node network scenario, BLOCK-ICN achieved improvements of 32% and 46% in broadcast delay reduction for the same propagation thresholds. Notably, this improvement was also applicable to Kademlia-based network topologies.

By evaluating broadcast coverage as a function of delay under an extreme network size (100,000 nodes), the results demonstrate the scalability of BLOCK-ICN across varying network sizes, reinforcing its ability to maintain efficient communication performance as network scale increases.

6.4. Network Load

In the case where the number of network nodes remained fixed at 16,000 and the block size stayed at 0.5 MB, we conducted simulation experiments based on the existing bandwidth utilization data of NDN multicast and IP unicast [14]. Due to the characteristic of ICN networks supporting network caching, the data flow (output traffic) from blockchain nodes in sending blocks to the entire network is much smaller than the data flow (input traffic) received by the entire network of blockchain nodes. Hence, we selected the data flow received by blockchain nodes as the evaluation metric. The variation in block broadcast bandwidth to the entire network for BLOCK-ICN and the bitcoin network with respect to network size is shown in Figure 22. The horizontal axis represents the network size, while the vertical axis represents the average flow of a single block being broadcast to the entire network. Based on experimental results with other parameters controlled, it can be observed that as the blockchain network size increased, the block network bandwidth consumption for both protocols gradually increased. However, for the same network size, the block broadcast bandwidth consumption for BLOCK-ICN was smaller than that of the bitcoin network. For instance, when the network size was 16,000, the block broadcast bandwidth consumption for the bitcoin network was 63,996 MB, while for BLOCK-ICN, it was 19,998 MB, resulting in a reduction in block broadcast traffic by 68.8%. In conclusion, BLOCK-ICN had a better network load performance compared to the bitcoin network.

Finally, we used the SimBlock visualization tool simblock-visualizer to demonstrate the propagation process of blocks in the experimental data. Figure 23 and Figure 24, respectively, show the communication between nodes in the Bitcoin network and the BLOCK-ICN network with $10\%$ ICN nodes using simblock-visualizer. In these screenshots, blockchain nodes are represented in blue, while the messages between nodes are represented in green. From the figures, it can be clearly seen that, at the same timestamp, the BLOCK-ICN network with deployed ICN nodes demonstrated significantly improved block broadcasting efficiency compared to the Bitcoin network.

7. Discussion

This paper mainly studied the optimization of broadcast delay and network bandwidth in a blockchain network based on ICN, aiming to address the performance challenges in blockchain networks. However, there are several unresolved issues for future work:

• While BLOCK-ICN enhances broadcast efficiency, it may also reduce network decentralization, due to the introduction of structured routing and domain gateway nodes in ICN. Thus, more research and experimentation are required to evaluate the performance and scalability of ICN in practical deployments.
• In BLOCK-ICN, ICN nodes typically rely on certification authorities for authentication to mitigate Sybil and Eclipse attacks. As part of our future work, we aim to design a reputation-based evaluation mechanism that utilizes network information to assess node credibility, further reducing the risk of such attacks.
• Regarding the gateway node election algorithm, our current theoretical evaluation considered only simple network topologies. We acknowledge the need for further theoretical validation and experimental analysis in more complex network environments, to comprehensively demonstrate its advantages.
• When BLOCK-ICN is deployed in large-scale networks, the number of multicast groups and members may increase significantly, posing performance challenges for gateway nodes. Since this issue is difficult to fully simulate in a network emulation environment, real-world deployment and testing are necessary for further verification and optimization.
• Although SimBlock provides a controlled environment for evaluating block propagation and communication efficiency, real-world blockchain networks involve dynamic node churn, diverse network topologies, and varying degrees of congestion, which were not fully captured in our simulations. To further validate our approach, future work will incorporate more comprehensive network models or real-world experimental deployments.

We will continue to delve into the optimization of blockchain networks based on ICN and combine blockchain technology with the underlying ICN network from multiple perspectives, in order to improve the performance of blockchain networks, as well as the security and usability of ICN networks, and prepare for future work.

8. Conclusions

This paper proposed BLOCK-ICN, a blockchain network communication architecture based on an IP-compatible ICN network. BLOCK-ICN enables the deployment of blockchain applications on ICN nodes with computing and storage capabilities, while maintaining compatibility with P2P networks. By leveraging ICN multicast technology, the architecture provides relay acceleration services to enhance communication efficiency.

In terms of network topology, ICN nodes classify network domains based on the delay information provided by the enhanced resolution system and establish domain gateway based on data flow forwarding dependencies. This approach facilitates the construction of a hierarchical and structured relay network topology. Regarding the broadcast protocol, ICN nodes employ ICN multicast to achieve parallel broadcasting. Upon receiving a message, an ICN node rebroadcasts it to P2P nodes, thereby reducing the overall broadcast latency and bandwidth consumption in the network.

We implemented a simulation of BLOCK-ICN using SimBlock. The simulation results show that, compared to the Bitcoin network, BLOCK-ICN demonstrated superior performance in terms of reducing broadcast latency and overall bandwidth consumption. However, despite its promising results in the simulation, several challenges remain for future research. These include the potential security and centralization risks introduced by ICN nodes, as well as challenges in integrating and deploying ICN within existing network infrastructures.

Moving forward, we aim to further explore the real-world deployment and implementation of BLOCK-ICN, facilitating its application in a broader range of practical scenarios.