# A Blockchain Network Communication Architecture Based on Information-Centric Networking
## 4 Design
### Network Topology Improvement
#### 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\(SIG_{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. Figure 5: Evaluation process of node local betweenness centrality. * Identity authentication information of intra-domain ICN nodes: Public key information \(PK_{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 \[\forall G\in C,Score_{G}=[s_{G,1},s_{G,2},\ldots,s_{G,n}]\] (1) \[\forall s\in[s_{G,1},s_{G,2},\ldots,s_{G,n}],s\in\{0,1\}\] (2) where \(C\) denotes the set of intra-domain ICN nodes, and \(Score_{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., \(SIG_{GA}\), \(SIG_{GB}\), \(SIG_{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 \([Score_{1},Score_{2},\ldots,Score_{n}]\).