## MIN: Co-Governing Multi-Identifier Network Architecture and Its Prototype on Operator's Network

Wai-Ho9 , Zefeng Zheng'0, Peng Yi? , Xinsheng Ji? , Qinrang Liu? , Wei Lis , Kaiyan Tian" Zhu' Huang' Kaixuan Xing' Yeung Jiang Ting

'Shenzhen Graduate School, Peking University; P. R. China

2National Digital Switching System Engineering and Technological Research Center, PR China 3Tsinghua University; PR. China 'China United Network Communications Limited, PR China China Telecom Corporation Limited, PR China Guangdong Communications &amp; Networks Institute, PR. China 7South China University of Technology; PR. China The University of Science and Technology; PR. China Chinese University of Hong Kong, PR. China University of Science and Technology; PR. China "Kingsoft Cloud Network Technology Co., Ltd. PR China 12 Guangdong University of Technology; PR. China China Academy of Information and Communications Technology; PR China Hong Kong IMacau 13 The

Corresponding author. E-mail: lih64@pkuszedu.cn, huilihuge@163.com

## ABSTRACT

IP protocol is the core of TCP/IP network layer. However, since IP address and its Domain Name are allocated and managed by a single agency, there are risks of centralization. The semantic overload of IP address also reduces its scalability and mobility, which further hinders the security.

This paper proposes a co-governing Multi-Identifier Network (MIN) architecture that constructs a network layer with parallel coexistence of multiple identifiers, including identity, content, geographic information, and IP address. On the management plane, we develop an efficient management system using consortium blockchain with voting consensus, so the network can simultaneously manage and support by

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org.

Conference'17, Washington, DC, USA

© 2016 ACM.

978-x-xxxx-xxxx-x/YY/MM...$15.00

DOI: 10.1145/nnnnnnn.nnnnnnn

hundreds or thousands of nodes with high throughput. On the data plane, we propose an algorithm merging hash table and prefix tree (HTP) for FIB, which avoids the false-negative error and can inter-translate different identifiers with tens of billions of entries. Further, we propose a scheme to transport IP packets using CCN as a tunnel for supporting progressive deployment. We deployed the prototype of MIN to the largest operators' network in Mainland China, Hongkong and Macao, and demonstrated that the network can register identifier under co-governing consensus algorithm, support VoD service very well.

## KEYWORDS

Network Architecture, Consortium Blockchain, HTP-FIB, APoV, MIN, MIS, MIR

## ACMReference format:

. 2016. MIN: Co-Governing Multi-Identifier Network Architecture and Its Prototype on Operator's Network. In Proceedings of ACM Conference, Washington, DC, USA, July 2017 (Conference'17), 13 pages. DOI: 10.1145/nnnnnnn.nnnnnnn

## 1 INTRODUCTION

The Internet architecture based on IP has continuously evolved during the last decades. Its end-to-end transmission mode accelerated its deployment worldwide. However, in IP based network, the allocation and management of IP addresses are controlled by a single agency. Such centralization brings risks. On the other hand, IP addresses represent both the location and the identity information of nodes, causing semantic overload. These problems hinder the scalability of routing and its adaptation to mobile devices. The lack of identity tracking and managing also reduce the security of IP-based networks [5, 15, 16]. The defects in security and tractability make the IP network unsuitable for supporting emerging scenarios, such as Content-Centered Network (CCN), highspeed mobile network, Internet of Things, and Industrial Internet. The situation poses urgent demand for a new generation of future network architectures.

To decentralize the management of the network architecture, blockchain [14] and other solutions [3, 4, 8, 9, 17] have recently been applied to build a future network under cogoverning. Namecoin [13] and Blockstack [1] first applied blockchain to decentralize the management of domain name system. However, its underlying system based on public blockchain creates bottleneck for its performance. To solve the problem, Benshoof et al. proposed an alternative solution of DNS system based on blockchain and distributed hash table named D NS 3 [2], which provides solutions to current DNS vulnerabilities such as DDoS attacks. However, it risks leaking users' IP information and increases the difficulty to deploy in large-scale. To mitigate the problem, HyperPubSub system [22] uses the passive publish/subscribe receiving mode to reduce the traffic load and the delay caused by blockchain.

To improve the performance of IP-based networks, European Union launched the first phase of Future Internet Research and Experimentation (FIRE) program [6] to explore future network and service mechanisms. The project focused on exploring the self-adapting management mechanism in the future network to increase its level of intelligence. However, this study did not produce a new network architecture design. The NDN project [21] backed by the National Science Foundation (NSF) aims to develop a network architecture based on content. The MobilityFirst project [18] prioritizes the identity of nodes and efficiently manage the movement of nodes. It uses the General Delay-Tolerant Network (GDTN) to enhance the robustness and availability of network.

The above methods improve performance of network and level of decentralization, respectively, but are unable to meet both requirements[20] simultaneously. This paper proposes a Multi-Identifier Network (MIN) architecture that constructs a network layer with parallel coexistence of multiple identifiers, including identity, content, geographic information, and IP address. To solve the two major defects of the traditional network, we decentralize the management of postIP identifier using consortium blockchain, address or intertranslate identifiers with tens of billions of entries using HPT for FIB. We also enhance the progressive deployment through novel IP-CCN-IP tunnel scheme. As part of the work, we implement the generation, management, and resolution in MIN and ensure it compatible with the traditional IP network, to support progressive deployment.

Ascontributions, this paper proposes a novel Multi-Identifier Network. Specifically,

We experimented and verified MIN in operators' network deploy from Beijing to Guangzhou, Shenzhen, Hongkong and Macao for streaming high-definition video. We also tested the transmission including IP to CCN to IP, IP to CCN, CCN to IP, and CCN to IP to CCN. The results demonstrate that the network achieves excellent performance and can support real-world applications with further development.

1) On the management plane, we design an efficient consensus mechanism of consortium blockchain to achieve decentralized management of identifiers, which is the multiidentifier system(MIS). MIS takes the same role as DNS in IP, actually the function of DNS is only a subset of MIS.

3) We also introduce a scheme to transport IP packets using CCN as a tunnel to support progressive deployment of the data plane (being compatible with IP-based network). We implemented various transmission scenarios, such as IP-CCN-IP, IP-CCN, CCN-IP, and CCN-IP-CCN.

2) On the data plane, we improve HPT-FIB by combining hash table and prefix tree, which is integrated into the multi-identifier router (MIR) of MIN as a key part. Such improvement enables identity-centered forwarding and intertranslation between different kind of identifiers in a magnitude of tens of billions of entries.

The rest of this paper is organized as follows. Section 2 describes the proposed Multi-Identifier Network. Section 3 demonstrates the key technologies. Section 4 presents the quantitative results of the prototype, and section 5 provides some concluding remarks and discusses ongoing and future research directions.

## 2 MULTI-IDENTIFIER NETWORK

For the co-governing Multi-Identifier Network, its decentralized management and large resolution capability enable a progressive transition from the existing network architecture to a new one.

## 2.1 Network Architecture

MIN supports the coexistence of Network Identifiers including identity, content, geographic information, and IP address. Identifiers in the network are identity-centric. For example,

the content identifiers of all resources are bound to the identity identifiers of their publishers. The protocol architecture of MIN is shown in Figure.1.

Figure 1: Protocol Architecture of MIN

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00418v1-figure-4573b3fd-b1db-43b3-ad0a-ca3bdbbe707d.jpg)

The network hierarchy of MIN is shown in Figure. 2. It divides the whole network into hierarchical domains from top to bottom. The nodes in the top-level domain belong to the organizations of the major countries which jointly maintain a consortium blockchain. The respective regional organizations govern the other domains. Among them, the registration and management mode of identifiers and the specific implementation details can vary. This low coupling guarantees the security of the network and enables customization of each domain [10] [11].

Figure 2: Network hierarchy of MIN

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00418v1-figure-95553724-70d7-458a-8d9f-db4d525ccc42.jpg)

The function of a complete node in the network is to participate in the intra-domain management of users and the registration process of identifiers on the blockchain, as well as provide inter-translation and resolution services (in this case called Multi-Identifier Router, MIR). Also, there are supervisory nodes, individual users, and enterprise users. Supervisory nodes are set up as the data access interfaces between the upper and lower domains. Each supervisory node has multiple identifiers.

The architecture of MIN includes a management plane and a data plane. The management plane is responsible for generation and management of identifiers. After the supervisory nodes verify the identifier and reach a consensus through the consensus algorithm, it records the relevant attribution information and operation information on the blockchain, to make the data in the whole network unified, tamper-resistant and traceable. The reason for storing only the important data on-chain is to ensure efficiency, while all the information of the identifiers are stored off-chain. The data plane provides the resolution for identity, content, geographic information and other identifiers, and is also responsible for packet forwarding and filtering.

## 2.2 Operation Flow

In MIN, all resources are required to register an identifier with a regulatory organization within the domain. Devices can only access a resource in the network after its identifier has been approved by most organizations and successfully written on the blockchain. The registration process is as follows.

S2: After receiving the user's request, MIR transmits the registration data to its corresponding domain according to a specific routing protocol.

S1: The user who owns the resource submits a request for identifier registration to the node of a regulatory organization.

S3: The blockchain node of the corresponding domain reviews the compliance of the resource after receiving its identifier registration request. If so, the resource's identifier is then voted by all the blockchain nodes in the domain to reach consensus.

MIR's process to resolve the identifier is as follows.

S4: The blockchain node then returns the registration result to the original requesting node. Since the complete identifier information is stored in the off-chain database rather than the on-chain block, all databases are synchronized frequently throughout the network to ensure consistency.

S1: MIR judges that the identifier is (1) IP address, then query in HPT-FIB. If it exists, it will be resolved. Otherwise, access the traditional IP network through proxies; (2) identity, content and other identifiers, then query in the cache and HPT-FIB. If it exists, it will be resolved. Otherwise, go to S2.

S2: If MIR cannot find the identifier, recursively query the upper domain until acquiring it.

S3: If the identifier is not found up to the top-level domain, then query the lower domain according to the information carried by the identifier until the lowest. If it exists, MIR will return the resolved result. Otherwise, return an error message.

In MIN, users' behaviors of publishing and accessing are protected and managed, and the blockchain undeniably records illegal actions. Therefore, MIN will keep the cyberspace in an orderly and secure state, which will direct traffic to the post-IP multi-identifier network tied to the user's identity.

## 3 KEY TECHNOLOGIES

As mentioned above, we use consortium blockchain, HPT for FIB, and tunnel algorithm to improve the security, performance, and scalability. In this section, we introduce those technologies.

## 3.1 Consensus Algorithm for Consortium Blockchain

On the management plane of the MIN architecture, we come up with the APoV (Advanced Proof of Vote) consensus based on our self-designed PoV (Proof of Vote) [12], a non-forking consensus algorithm for consortium blockchain. The core lies in the separation of voting rights and bookkeeping rights. The bookkeeping nodes work in a joint effort to conduct decentralized arbitration according to the votes of the consortium nodes.

## (1)Concept Description

The APoV consensus divides the blockchain nodes into three identities: consortium node, bookkeeping node, and leader node.

APoV defines that data on the blockchain is stored in block groups. A block group consists of a block group header and a block group body. Each block group header contains the height and voting result. The block group body includes blocks approved by the majority of consortium nodes. Where, each block consists of the hash value of the previous block group, the Merkle root, the public key of the bookkeeping node, the timestamp, and the set of transactions.

- GLYPH&lt;15&gt; The consortium node is responsible for voting on the generated blocks and potential bookkeeping nodes. The number of consortium nodes in each round is a fixed constant, denoted as n c . Based on the principle of 'the minority is subordinate to the majority', the voting results are regarded as proof of the validity of the block and the identity of the bookkeeping node.
- GLYPH&lt;15&gt; The bookkeeping node is responsible for generating blocks in the current consensus round. The number of bookkeeping nodes is n b . At the end of the term, the consortium nodes vote on the potential
- bookkeeping nodes to produce the next bookkeeping nodes.
- GLYPH&lt;15&gt; The leader node is responsible for counting votes and writing the voting result into the block group header as proof. Each consensus round has a different leader node, whose number is recorded in the previous block group header.

There are two types of voting messages in APoV for the transactions of identifiers and election: confidence vote and verification vote.

- GLYPH&lt;15&gt; The validation vote is a validation of the block group. The consortium node votes for the blocks they agree to generate. Each block must obtain more than half of the votes to be considered as a legal block. Similarly, to correct a result, more than half of the consortium nodes must agree.
- GLYPH&lt;15&gt; The confidence vote is a successful proof for the next bookkeeping nodes. Before the end of the current bookkeeping nodes' term, each potential bookkeeping node proposes a transaction of election and receives votes from consortium nodes. The voting result indicates the trust of consortium nodes in these nodes competing for bookkeeping rights, thus can also be considered as the reliability of them. The nodes with higher reliability ranking are deemed successful in the election, with bookkeeping rights from the next consensus round until the end of their term.

## (2)Process of Consensus

The consensus process is shown in Figure. 3.

Figure 3: Consensus Process of APoV

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00418v1-figure-218c28bf-b494-4bff-9bdf-0dbd96de20c4.jpg)

Each round of the APoV consensus consists of the following steps.

S1: Each bookkeeping node generates a block and publishes it to the network. Each blockchain node collects all the blocks in this step.

S2: When the consortium node collects all the block generated in S1, it votes for each block and sends a total voting message to the leader node. The voting message contains the hash value of each block, as well as the agreed opinion and signature.

S4: When the blockchain node receives the block generated by the bookkeeping nodes and the block group header generated by the leader node, it will store them in the database as a block group.

S3: The leader node collects the voting messages sent in S2 and counts the voting results. Statistical results and all voting messages will be stored in the block group header when the approval or disapproval of each block is more than half of the number of consortium nodes. The leader node then generates a random number as the number of the next leader node and writes it into the block group header. Finally, the leader node publishes the block group header to the network.

## 3.2 Improved FIB

There are multiple identifiers including identity, content, geographic information, and IP address on the data plane of MIN. However, in the traditional FIB, the length of content names leads to a too large table and reduces lookup speed. On the one hand, we design the inter-translating algorithm with multiple identifiers. On the other hand, by building hash tables and prefix trees, we optimize the FIB algorithm to improve the lookup speed at massive scale.

Figure 4: The HPT-FIB Combining Hash Table and Prefix Tree

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00418v1-figure-67bef4ed-e5fa-459a-8404-b80f5ae94d27.jpg)

## (1)Reconstructing HPT-FIB

To support binary search, every true prefix of the content name stored in the table must also have corresponding entries. The process of checking whether prefixes exist and adding corresponding non-real entries is known as FIB reconstruction. Typically, in a reconstructed FIB, table entries can be divided into two categories: real entry and non-real entry. To avoid the false-negative error in traditional binary search, we subdivide non-real entry into the virtual entry and the semi-virtual entry.

## Algorithm 1 Insertion Algorithm

## Input:

H : HT and trie-based FIB

n n : = ' GLYPH&lt;157&gt; c 1 GLYPH&lt;157&gt; c 2 GLYPH&lt;157&gt; ::: GLYPH&lt;157&gt; c N ' is the content name to insert

f

:

The corresponding forwarding information of

n

## Output:

H : HT and trie-based FIB, with n inserted

1: lookup n in HT

2: if n is the name of a real entry ' n e ; ' then

3: update e 's forwarding information with f

4: else if n is the name of a non-real entry ' n e ; ' then

5: set e 's type to real, e 's forwarding information to f

6: for each virtual entry 'GLYPH&lt;24&gt; ; e GLYPH&lt;3&gt; ' in e 's subtree do

7:

set e GLYPH&lt;3&gt; 's type to semi-virtual

8:

end for

9: else

10:

create entry ' n e ; N ' and insert it to HT

11:

set e N 's type to real, e N 's forwarding information to f

12:

for i = N GLYPH&lt;0&gt; 1 to 1 do

13:

lookup n i = ' GLYPH&lt;157&gt; c 1 GLYPH&lt;157&gt; c 2 GLYPH&lt;157&gt; ::: GLYPH&lt;157&gt; c i ' in HT

14:

if n i is the name of an entry ' n i ; e ' then

15:

add e i + 1 to e 's child list, set e i + 1 's parent to e

16:

if e is virtual then

17:

set e j ' i &lt; j &lt; N ' 's type to virtual

18:

else

19:

set e j ' i &lt; j &lt; N ' 's type to semi-virtual

20:

end if

21:

return

22:

else

23:

create entry ' n i ; e i ' and insert it to HT

24:

add e i + 1 to e i 's child list, set e i + 1 's parent to e i

25:

end if

26:

end for

27:

add e i to root 's child list, set e i 's parent to root

28: j

set e ' 0 &lt; j &lt; N ' 's type to virtual

29:

end if

The content names in the real entries referred to the actual data are used to forward Interest packets. All of the table entries are real before FIB reconstruction. Content names in non-real entries do not refer to data or guide the forwarding of Interest packets but are only used to support the binary search algorithm. A non-real entry is called a virtual entry if it has no real prefix. If the non-real entry has a real prefix, the table entry is called semi-virtual entry and requires backtracking before the end. We present the semi-virtual entry to avoid the false-negative error in HPT-FIB when the binary search process ends with a virtual entry.

The HPT-FIB is shown in Figure.4. In the hash table, each content name (such as GLYPH&lt;157&gt; c 1 GLYPH&lt;157&gt; c 4 GLYPH&lt;157&gt; c 5) is calculated as the key, and its value points to the node in the prefix tree. Edges in the prefix tree represent a content name component (such as GLYPH&lt;157&gt; c 1). Each node represents a content name, which splices all the components on the path from this node to the root. In a tree node, there are five pieces of information: state, parent node pointer, child node pointer, brother node pointer, forward pointer, which maintain the structure of the tree.

## Algorithm 2 Deletion Algorithm

## Input:

H : HT and trie-based FIB

n n : = ' GLYPH&lt;157&gt; c 1 GLYPH&lt;157&gt; c 2 GLYPH&lt;157&gt; ::: GLYPH&lt;157&gt; c N ' is the content name to delete

## Output:

H : HT and trie-based FIB, with n deleted

1: lookup n in HT

2: if n is not the name of a real entry ' n e ; ' then

3:

return

4: end if

5: if for n 's entry ' n e ; ' , if e is not a leaf then

6:

set e 's forwarding information to N/A

7:

if e 's parent is semi-virtual or real then

8:

set e 's type to semi-virtual

9:

else

10:

create an empty queue q and insert e into it

11:

while q is not empty do

12:

e GLYPH&lt;3&gt; = q .pop()

13:

set e GLYPH&lt;3&gt; 's type to virtual

14:

insert all e GLYPH&lt;3&gt; 's semi-virtual child nodes into q

15:

end while

16:

end if

17:

else

18:

remove e from its parent's child list

19:

delete entry ' n e ; ' in HT

20:

for i = N GLYPH&lt;0&gt; 1 to 1 do

21:

for n i = ' GLYPH&lt;157&gt; c 1 GLYPH&lt;157&gt; c 2 GLYPH&lt;157&gt; ::: GLYPH&lt;157&gt; c i ' and its entry ' n i ; e i '

22:

if e i is non-real and e i is a leaf then

23:

remove e i from its parent's child list delete entry ' n i ; e i ' in HT

24:

25:

else

26:

return

27:

end if

28:

end for

29:

end if

Establishing HPT-FIB includes two basic operations: insertion and deletion, whose algorithms are shown in Algorithm. 1 and Algorithm. 2 respectively.

## (2)The Inter-translating Scheme

When users register and publish content resources on MIN, the bounded identifiers are stored in the prefix tree whose array header is maintained by forwarding pointer ( P Forward ). When users query with content name, it routes without translation. When users query with another identifier, the network searches the P Forward of the content, then selects the corresponding content name for routing.

In the network, routers in each domain maintain the HPTFIB of multiple identifiers. This table records various identifiers of resources. The identifier inter-translating scheme is used to provide translation between different identifiers when users query resources.

## (3)The Lookup Algorithm

In order to meet MIN's requirement of large-scale and fast routing, we design a high-speed lookup algorithm of HPTFIB. It adopts binary search under the longest prefix matching (LPM) principle. As introducing semi-virtual entries, the return values for different HITs are different from traditional binary searches. Specifically, there are three patterns based on the category of the last HIT entry.

- GLYPH&lt;15&gt; If it is a real entry, the search for LPM is successful, and return the corresponding information.
- GLYPH&lt;15&gt; If it is a semi-virtual entry, there is at least one matching real prefix in the table. We can backtrack in the prefix tree to find the matching real prefix out and return it. Since backtracking in the prefix tree does not involve searching, this process has a minimal time overhead.
- GLYPH&lt;15&gt; If it is a virtual entry, it is sure that there is no matching real prefix in the table, so return with no match.

So, there are two kinds of lookup results. One is HIT, which means that there is a corresponding real entry in HPTFIB (i.e., the last HIT entry is real entry or semi-virtual entry). The other is MISS, which means that the corresponding real entry does not exist (i.e., the last HIT entry is virtual). We test these two application scenarios in Section 4.2.

## 3.3 Tunnel Transmission

To promote the progressive deployment of MIN, we propose a tunnel scheme based on the new typed networks. Taking CCN as an example, this section describes the process of using it as a tunnel to transport IP packets.

## (1)Problem Description

CCN [7] has revolutionized the address-centric transport architecture based on TCP/IP protocol. To realize the progressive deployment, TCP and CCN need to communicate mutually. There are many difficulties with this process. First, TCP is an end-to-end protocol that communicates through IP addresses and port numbers, which contradicts CCN's content-based philosophy. Second, in CCN, communication is a user-initiated process of 'pulling' the required data. However, in TCP, it is a 'push' process in which the sender sends data, and the receiver replies the acknowledgment message. The two are fundamentally different in semantics. Third, TCP ensures reliable end-to-end transmission, which CCN does not address.

## (2)Tunnel Scheme

In the scheme, CCN is directly deployed on the MAC layer of Ethernet to get rid of the dependence on IP completely. The architecture of combining Ethernet transmission, TCP transmission, and UDP transmission is shown in Figure.5.

Figure 5: The Schematic Diagram of IP-CCN-IP Transmission

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00418v1-figure-c47327e1-6ebb-478c-92a7-66bb7f9dabf4.jpg)

To enable the two TCP ends to communicate through CCN, the scheme sets a pair of conversion nodes at the boundary between the IP network and the CCN. The transformation between identifiers and encapsulation of packets are carried out in MIR. Each MIR has a name mapped to its IP address as the routing prefix on the CCN, allowing CCN packets to flow smoothly to the designated multi-identifier router for further processing.

Connection Establishment: In this scheme, the threeway handshake to establish a connection between two TCP ends of IP networks is modified into the three-way Interest packet switches, as shown in Figure.6. The TCP end sends SYN, SYN + ACK, and ACK control signaling to MIR. The CCN transports the TCP control signaling by encapsulating it into the Interest packet header. Finally, the receiving MIR forwards the control signaling to the other TCP end, thus completing the connection establishment of IP-CCN-IP transmission.

Figure 6: Connection Establishment of IP-CCN-IP Transmission

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00418v1-figure-52cf2ec7-2174-41f5-87de-109a67419dfb.jpg)

Connection Termination: The four-way handshake of connection termination between the two TCP ends is modified to the four-way Interest packet switches. The logic of Interest packets switching in this process is similar to that of the connection establishment.

## 4 PROTOTYPE AND EXPERIMENT

We developed a prototype of MIN and deployed it on the actual operators' network. This section tests and analyzes its ability on generation, management, and resolution, including the performances of the consensus algorithm, HPT-FIB query, and VoD service.

## 4.1 Advanced Proof of Vote

This section calculates the throughput of the blockchain consensus algorithm on the management plane of MIN. In APoV, since a new round of consensus can start only after the end of the current one, we calculate throuдhput through the time spent on each round of consensus. Consensus time consists of computation time and transmission time, that is,

$$t _ { c o n s } = t _ { c o m p } + t _ { t r a n } \quad \quad \quad ( 1 )$$

## (1)Calculation of the Transmission Time t tran

According to the consensus steps in Section 3.1, in S1, the communication traffic of each bookkeeping node is the sum of block messages sent by it, and the communication traffic of each consortium node is all the block messages it receives. The communication pressure of the bookkeeping node is higher than that of the consortium node, so the transmission time in S1 is the communication time of the bookkeeping node,

$$\mathbb { r } _ { \mathfrak t } \quad \ t _ { t r a n } ^ { 1 } = ( n _ { b } + n _ { c } - n _ { b c } - 1 ) \cdot ( M + H + T \cdot K ) / b a n d \quad ( 2 )$$

where n b , n c and n bc are the number of bookkeeping nodes, consortium nodes and nodes concurrently holding these two identities respectively. M H , and T are the size of the message header, the block header, and the transaction, respectively. K is the maximum number of transactions that can be placed within each block. band is the bandwidth of each node (assuming the same uplink and downlink bandwidth).

To balance the computing power between nodes, we assume that the leader node does not concurrently serve as the consortium node. In this case, the transmission time in S2 is

$$t _ { t r a n } ^ { 2 } = n _ { c } \cdot ( M + H _ { v } + n _ { b } \cdot V _ { b } ) / b a n d \quad \ \ ( 3 )$$

where H v and V b are the size of the vote header and the single vote, respectively.

Similarly, the transmission time in S3 is

$$\overline { N - \text{IP} } \quad \ t _ { t r a n } ^ { 3 } = ( n _ { b } + n _ { c } - n _ { b c } - 1 ) [ M + H _ { r } + n _ { b } R _ { b } + n _ { c } ( H _ { v } + n _ { b } \cdot V _ { b } ) ] / b a n d$$

where H r and R b are respectively the size of the voting result header and the voting result of a single block.

According to Equation (2)-(4), the transmission time is

$$\mu _ { \mu } \quad t _ { t r a n } ^ { 1 } = t _ { t r a n } ^ { 1 } + t _ { t r a n } ^ { 2 } + t _ { t r a n } ^ { 3 } \quad \quad ( 5 )$$

(2)Calculation of the Computation Time t comp

Consider a simple network scenario of consortium blockchain with two servers, where Server A runs a blockchain node, and Server B runs multiple blockchain nodes. To reduce the waste of computing power, we set each node as both bookkeeping node and consortium node. We make the node on Server A the leader node.

The blockchain parameters of the prototype are K = 10000, M = 266 Byte , H = 692 Byte , T = 40 Byte , H v = 400 Byte , V b = 100 Byte H , r = 170 Byte R , b = 400 Byte band , = 1 Gbps = 125 MB s GLYPH&lt;157&gt; , and the CPU of the server is Intel Xeon Silver 4114@2.20GHz. From the perspective of Server A, the states of the single blockchain node and the whole blockchain network can be observed simultaneously. We run 10 rounds of consensus at different scales. The time consumption of each step and each round is measured on Server A and averaged, as shown in Table. 1.

Since the bandwidth in Server B is much larger than that between A and B, the transmission time of nodes on Server B can be regarded as 0, and the transmission time of Server A still follows the conclusion above. The advantage of this scenario is that it eliminates the impact of asynchronous transmission on performance in distributed networks, and only analyzes computational factors.

According to the consensus steps in Section 3.1, the relationship between the time consumption of S1, S2 and S4 and the number of nodes n is linear. In S3, when n increases, the number of blocks that each consortium node needs to vote increases, so its time consumption can be described by a quadratic function. The time consumption of each step in Table. 1 is fitted to

$$t _ { c o m p } ^ { 1 } & = 0. 0 0 4 1 n +$$

Further understanding of Equation (6) is that, t 1 comp is reflected in the computation of the bookkeeping node, t 2 comp in the computation of the consortium node, t 3 comp in the computation of the leader node, and t 4 comp in the computation of each node.

According to Equation (2)-(5), the transmission time t tran is a cubic function of the number of nodes n , so the consensus time t cons can be described by a cubic function. The consensus time in Table. 1 is fitted to

$$t _ { c o n s } = \frac { 0. 0 3 1 2 n ^ { 3$$

Substitute the parameter value of the prototype into Equation (2)-(5) to get the transmission time is

$$\iint \sqrt { \nu } \forall \, \log e \, \L$$

According to Equation (1), the computation time is

$$\begin{array} {$$

According to Equation (5) and (10), the minimum consensus time in the network is

Consider the further understanding of Equation (6). Take the computing power of the servers in the prototype as the standard. For a blockchain network with computing power a , that is, the maximum computing power used by all nodes for consensus is a times of the standard computing power, then the minimum computation time is shown in Equation (10).

$$t _ { c o n s } ^ { \prime } = t _ { c o m p }$$

To sum up, the upper limit of throughput within the blockchain network is shown in Equation (12).

When the number of nodes is small (generally less than 10), the computing power used for consensus is not fully utilized, so the number of nodes is the main factor affecting the throughput. When the number of nodes increases, the performance can be approximately increased with the improvement of computing power and bandwidth.

Based on Equation (12), it is possible to estimate the upper limit of performance in the real blockchain network composed of servers and switches using APoV consensus algorithm. In the consortium blockchain network, each server typically runs only one node. Assuming that the other configurations of nodes are the same, when their CPUs are Intel Xeon Silver 4114@2.20GHz, Intel Xeon Silver 4116@2.10GHz, and Intel Xeon Gold 5118@2.30GHz respectively 1 , the upper limit of throughput is affected by n and band , as shown in Figure.7 (1)-(3). When the bandwidth of nodes is set as 1Gbps, 8Gbps and 10Gbps respectively, the influence of n and a on the upper limit of throughput is shown in Figure.7 (4)-(6).

At present, the throughput of most blockchain consensus algorithms is less than 100 thousand transactions per second[19]. We measure the prototype consisting of 20 blockchain nodes, each of which is responsible for both voting and bookkeeping. The APoV consensus can achieve a stable throughput of more than 300 thousand transactions per second. Although the actual value is much lower than the theoretical value in Figure. 7, it greatly exceeds other

1 Data Sources: http://cdn.malu.me/cpu/

Table 1: Average Time of the Node on Server A in 10 Rounds of Consensus

| Number of Nodes n   | Time Consumption (s)   | Time Consumption (s)   | Time Consumption (s)   | Time Consumption (s)   | Time Consumption (s)   | Throughput (tx/s)   |
|---------------------|------------------------|------------------------|------------------------|------------------------|------------------------|---------------------|
| Number of Nodes n   | S1                     | S2                     | S3                     | S4                     | A Round of Consensus   | Throughput (tx/s)   |
| 3                   | 0.0311                 | 0.0642                 | 0.0255                 | 0.0217                 | 0.132                  | 223706              |
| 4                   | 0.0326                 | 0.0750                 | 0.0323                 | 0.0268                 | 0.150                  | 263583              |
| 5                   | 0.0377                 | 0.0861                 | 0.0295                 | 0.0319                 | 0.163                  | 302719              |
| 6                   | 0.0416                 | 0.0986                 | 0.0367                 | 0.0377                 | 0.189                  | 315861              |
| 7                   | 0.0470                 | 0.113                  | 0.0392                 | 0.0419                 | 0.217                  | 322992              |
| 8                   | 0.0505                 | 0.130                  | 0.0552                 | 0.0477                 | 0.252                  | 314743              |

$$t _ { c o m p } ^ { \prime } & = \frac { t _ { c o m p } } { a } \cdot [ 1 + \frac { ( 0. 0 1 2 n ^ { 2 } + 0. 0 1 4 1 n + 0. 0 8 8 0 ) } { n ( 0. 0 2 2 3 n + 0. 0 4 6 5 ) } ] = \frac { ( 0. 0 2 3 5 n ^ { 2 } + 0. 0 6 0 6 n + 0. 0 8 8 0 ) ( 0. 0 3 1 1 n ^ { 3 } - 0. 1 9 2 8 n ^ { 2 } + 1. 7 5 0 1 n + 1 1. 5 7 1 4 ) } { a ( 2. 7 8 7 5 n ^ { 2 } + 5. 8 1 2 5 n ) }$$

throuдhput = k GLYPH&lt;1&gt; n t GLYPH&lt;157&gt; 0 cons

$$\dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \delta = & 1 \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \dots \delta = & 1 \dots \dots \dots \dots \dots \dots \delta = & 1 \dots \dots \dots \dots \delta = & 1 \dots \dots \dots \dots \delta = & 1 \dots \dots \dots \delta = & 1 \dots \dots \delta = & 1 \dots \dots \delta = & 1 \dots \dots \delta = & 1 \dots \dots \delta = & 1 \dots \dots \delta = & 1 \dots \dots \delta = & 1 \dots \dots \delta = & 1 \dots \dots \delta = & 1 \dots \dots \delta = & 1 \dots \dots \delta = & 1 \dots \dots \delta = & 1 \dots \dots \delta = & 1 \dots \dots \delta = & 1 \dots \dots \delta = & 1 \dots \dots \delta = & 1 \dots \dots \delta = & 1 \dots \delta = & 1 \dots \dots \delta = & 1 \dots \delta = & 1 \dots \dots \delta = & 1 \dots \dots \delta = & 1 \dots \delta = & 1 \dots \dots \delta = & 1 \dots \delta = & 1 \dots \dots \delta = & 1 \dots \delta = & 1 \dots \dots \delta = & 1 \dots \dots \delta = & 1 \dots \delta = & 1 \dots \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \ dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots 0 = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = & 1 \dots \delta = \\ = & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & \\ & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & - & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & &  & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & + & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & ( & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & 0 & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & ; & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & } & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & &. & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & &
 & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & &, & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & \ & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & &$$

Table 2: The Time for Generating HPT-FIB Entries

Table 3: The Throughput of Name Search with all MISS

| Size of FIB (billion)        |    0.1 |     1.0 |     2.0 |     2.5 |     3.0 |     3.5 |
|------------------------------|--------|---------|---------|---------|---------|---------|
| Run Time(s)                  | 187.58 | 1649.75 | 3723.98 | 4925.64 | 6271.49 | 7760.69 |
| Actual Size of FIB (billion) |   0.1  |    1    |    2    |    2.5  |    3    |    3.5  |

consensus algorithms. We will continue optimizing the algorithm code of APoV to utilize the computing power and bandwidth in the network entirely.

## 4.2 FIB Combining Hash Table and Prefix Tree

This section calculates the scale and throughput of HPT-FIB algorithm on the data plane of MIN.

## (1)Scalability

The test result indicates that the HPT-FIB in this scheme can support large-scale prefix of content names storage.

The data source of the experiment is the self-generated CCN content names. As CCN has not deployed on a large scale, it is difficult to obtain large-scale CCN dataset from the real network. Therefore, we extract statistical features from the current network flow and obtain a large number of random URL-like names through simulation to generate a large-scale HPT-FIB. The test of building time for HPT-FIB is shown in Table. 2.

## (2)Lookup Performance

| N   | Linear Search          | Linear Search   | Binary Search          | Binary Search             | Binary Search        |
|-----|------------------------|-----------------|------------------------|---------------------------|----------------------|
| N   | Average Searching Time | Throughput      | Average Searching Time | Throughput (No Backtrack) | Throughput (HPT-FIB) |
| 6   | 6                      | 100%            | 2.34                   | 236%                      | 235%                 |
| 7   | 7                      | 100%            | 2.54                   | 250%                      | 247%                 |
| 8   | 8                      | 100%            | 2.70                   | 267%                      | 266%                 |
| 9   | 9                      | 100%            | 2.85                   | 280%                      | 279%                 |
| 10  | 10                     | 100%            | 2.96                   | 301%                      | 299%                 |

In this section, we test the lookup speed of HPT-FIB. The contrast algorithm includes LPM-based linear search and LPM-based binary search without backtracking in the prefix tree. As mentioned above, there are two kinds of lookup results: HIT and MISS. We test these two application scenarios.

When the average length of the content names to be searched is N , and the result is all MISS, which means that none inquired content name correspond to a real entry in HPT-FIB, the performances are shown in Table. 3.

For every testing, we lookup 500,000 times in HPT-FIB, which contains 5 million real entries. The above experiments are carried out ten times, and we count up their average values for evaluation and analysis. For the sake of comparison, the measurement is set to Operation Throughput, which is inversely proportional to the average operating time. Also, the throughput rate for linear search is set to 1 as a benchmark.

When lookup does not HIT, the linear search needs to traverse all prefixes of content names. The time cost is proportional to the length of content names, causing problems

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00418v1-figure-bced3faf-9136-4a2c-95a6-5c5848e97ac0.jpg)

Figure 7: The Influence of Node Number n , Computing Power a and Bandwidth band on the Upper Limit of Throughput in the APoV Blockchain

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00418v1-figure-c6eaf6ed-f4bb-45e1-a434-2e66cacdb72e.jpg)

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00418v1-figure-c63f64d0-135f-4656-8102-eb2b29a1102a.jpg)

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00418v1-figure-75308ed3-b8f8-48cc-b2a7-30ec0426043f.jpg)

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00418v1-figure-76923022-597b-4927-8594-e6bd396ebc53.jpg)

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00418v1-figure-3543cc5d-14d4-4a18-9262-7e63c7159a7e.jpg)

about efficiency and security. In contrast, binary search reduces the computational overhead of the LPM algorithm to the logarithmic level, which significantly improves the throughput. Also, since our algorithm needs no backtracking when lookup ends without HIT, the time cost is close to the original binary search. As a result, we solve the false negative error with acceptable costs.

When lookup ends with HIT, the average time cost of the linear search is proportional to ' N GLYPH&lt;0&gt; M + 1 . The time of binary ' search is almost not affected by M and is approximately proportional to loд N ' ' . For the scenarios with long content

Table 4: The Throughput of Name Search with all HIT

For the lookup test of all HIT which means that every inquired content name corresponds to a real entry in HPTFIB, we assume that the average length of content names is M with distribution ρ N ' ; ¯ λ ' . Since the average length of domain names is 2 or 3 and CCN content names are generally longer than URL requests in HTTP, we use M = 4 5 as the ; test parameter. The performances of all HIT are shown in Table. 4.

| M   | N   | Linear Search          | Linear Search   | Binary Search          | Binary Search               | Binary Search           |
|-----|-----|------------------------|-----------------|------------------------|-----------------------------|-------------------------|
| M   | N   | Average Searching Time | Through- put    | Average Searching Time | Through- put (No Backtrack) | Through- put (HPT- FIB) |
| 3   | 6   | 3.98                   | 100%            | 2.84                   | 126%                        | 123%                    |
| 3   | 7   | 4.99                   | 100%            | 3.02                   | 131%                        | 130%                    |
| 3   | 8   | 6.02                   | 100%            | 3.17                   | 151%                        | 150%                    |
| 3   | 9   | 7.00                   | 100%            | 3.31                   | 168%                        | 167%                    |
| 3   | 10  | 8.01                   | 100%            | 3.45                   | 185%                        | 183%                    |
| 4   | 6   | 3.03                   | 100%            | 2.90                   | 85%                         | 85%                     |
| 4   | 7   | 4.00                   | 100%            | 3.06                   | 104%                        | 101%                    |
| 4   | 8   | 5.02                   | 100%            | 3.21                   | 123%                        | 124%                    |
| 4   | 9   | 6.02                   | 100%            | 3.35                   | 141%                        | 139%                    |
| 4   | 10  | 7.03                   | 100%            | 3.47                   | 159%                        | 159%                    |

names to be searched and short table entries, the HPT-FIB lookup is faster.

According to the test results, the backtracking does not affect lookup speed because of no string searching. Therefore, the proposed algorithm solves the false negative error in random search with minimal efficiency loss.

## 4.3 Tunnel Transmission

The prototype realizes tunnel transmission under various network scenarios, including IP-CCN-IP, IP-CCN, CCN-IP, and CCN-IP-CCN. The topology is shown in Figure.8. Based on this, the prototype can provide High Definition Video on Demand (HDVoD) service with multiple transmission channels.

The exporting bandwidth of the servers in Peking University Shenzhen Graduate School (PKUSZ) is 100M special broadband, and that of other institutions is also more than 50M. On top of the bandwidth constraint, the network environment differences between operators and between mainland China, Hong Kong, and Macao may limit the transmission rates. The following are the experimental results of our prototype under four scenarios.

## (1)IP-CCN-IP Transmission

Wethen pull the video resource from pkusz 3 to node 9. The detailed topology and the experimental result are shown in Figure.10, where the transmission rate is 2.44MB/s.

Video resources are uploaded on the node pkusz 1 of China Telecom Futian and the node pkusz 3 of China Telecom Nanshan. We first use node 10 of PKUSZ as MIR and node 9 of PKUSZ as the IP node to pull the video from pkusz 1 to node 9. Figure.9 shows the detailed topology and the experimental result. It can be seen that the transmission rate reaches 2.65MB/s.

When video resources on pkusz 1 and pkusz 3 are pulled to node 9 simultaneously, the rates of the two transmission channels are 1.18MB/s and 1.71MB/s respectively, as shown in Figure.11. The transmission rate is lower than before when pulling from a single node, but the total transmission rate remains the same. The main reason is that the access bandwidth of node 9 is limited, resulting in the performance bottleneck.

## (2)IP-CCN Transmission

The video resource is uploaded on the node host 2 of China Unicom Tongle in CCN. As with the IP-CCN-IP transmission, we get the video from host 2 to node 9 through node 10. The tested transmission rate is 0.65MB/s.

## (3)CCN-IP Transmission

The video resource is uploaded on the node дdcni 1 of Guangdong Communications &amp; Networks Institute (DGCNI) in the IP network. Similarly, we pull the video from дdcni 1 to the node host 1 of Kingsoft. The tested transmission rate is 1MB/s.

## (4)CCN-IP-CCN Transmission

We have also implemented the CCN-IP-CCN transmission in the prototype of MIN. In this experiment, we place the video resource on the node host 2 of China Unicom Yuandong, and pull it to the node SCUT of South China University of Technology (SCUT). The tested transmission rate is 2.65MB/s.

## 5 CONCLUSION AND FUTURE WORK

A future network should be decentralized, secure and compatible with the existing IP-based network. In this paper, we propose a Multi-Identifier Network that constructs a network layer with parallel coexistence of multiple identifiers, including identity, content, geographic information, and IP address. The network provides the generation, management, and resolution services of identifiers and use consortium blockchain to enable decentralized management. To further accelerate the forwarding process, we improve HPT for FIB by combining hash table and prefix tree. In addition, we propose a scheme of transporting IP packet using CCN as a tunnel to support progressive deployment. Finally, we develop the prototype to operators' networks and verify its performances of the consensus algorithm, FIB query, and VoD service. The test results illustrate that the network achieves excellent performance and can support real-world applications after further development.

## REFERENCES

- [1] Muneeb Ali, Jude Nelson, Ryan Shea, and Michael J Freedman. 2016. Blockstack: A global naming and storage system secured by blockchains. In USENIX Annual Technical Conference . 181-194.
- [3] Christian Cachin. 2016. Architecture of the hyperledger blockchain fabric. In Workshop on distributed cryptocurrencies and consensus ledgers , Vol. 310. 4.
- [2] Brendan Benshoof, Andrew Rosen, Anu G Bourgeois, and Robert W Harrison. 2016. Distributed decentralized domain name service. In IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW) . 1279-1287.
- [4] Miguel Castro, Barbara Liskov, et al. 1999. Practical Byzantine fault tolerance. In OSDI , Vol. 99. 173-186.
- [6] Anastasius Gavras, Arto Karila, Serge Fdida, Martin May, and Martin Potts. 2007. Future internet research and experimentation: the FIRE initiative. ACM SIGCOMM Computer Communication Review (2007), 89-92.
- [5] Weihua Cheng. 2015. Attack Mode and Defense Strategy of DNS Cache Pollution. TELECOMMUNICATIONS INFORMATION 9 (2015), 16-21.
- [7] Van Jacobson, Diana K Smetters, James D Thornton, Michael F Plass, Nicholas H Briggs, and Rebecca L Braynard. 2009. Networking named content. In Proceedings of the 5th international conference on Emerging networking experiments and technologies . ACM, 1-12.
- [9] Sunny King and Scott Nadal. 2012. Ppcoin: Peer-to-peer cryptocurrency with proof-of-stake. self-published paper, August 19 (2012).
- [8] Aggelos Kiayias, Alexander Russell, Bernardo David, and Roman Oliynykov. 2017. Ouroboros: A provably secure proof-of-stake blockchain protocol. In Annual International Cryptology Conference . Springer, 357-388.
- [10] Hui Li, Kejiao Li, Yongle Chen, Jiawei Cai, Peng Yi, Zhihao Huang, Beini Zhou, Xin Li, and Jiyang Zhang. 2018. Determining consensus in a decentralized domain name system. US Patent App. 15/997,710.

Figure 8: Topology of the Prototype

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00418v1-figure-7c53d6d9-1e57-40a2-8a1e-a3642d0974a4.jpg)

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00418v1-figure-666a6a11-691c-4674-b7ea-2f1c49e0e604.jpg)

Figure 9: The Detailed Topology and the Experimental Result (Pull from pkusz 1 to node 9 )

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00418v1-figure-7c1cf85d-7f3e-4a13-a7bc-94b84720a396.jpg)

- [11] Hui Li, Xiangui Wang, Zhili Lin, Jiangxing Wu, Xueming Si, Kedan Li, Xin Yang, and Han Wang. 2019. Systems and methods for managing top-level domain names using consortium blockchain. US10178069B2.
- [13] Andreas Loibl and J Naab. 2014. Namecoin. namecoin. info (2014). https://Namecoin.info
- [12] Kejiao Li, Hui Li, Hanxu Hou, Kedan Li, and Yongle Chen. 2017. Proof of vote: A high-performance consensus protocol based on vote mechanism &amp; consortium blockchain. In IEEE 19th International Conference on High Performance Computing and Communications (HPCC) . 466473.
- [14] Satoshi Nakamoto et al. 2008. Bitcoin: A peer-to-peer electronic cash system. (2008).

Figure 10: The Detailed Topology and the Experimental Result (Pull from pkusz 3 to node 9 )

- [15] Lily Hay Newman. 2016. What we know about Friday's massive east coast internet outage. Wired Magazine 21 (2016).
- [17] David Schwartz, Noah Youngs, Arthur Britto, et al. 2014. The ripple protocol consensus algorithm. Ripple Labs Inc White Paper 5 (2014), 8.
- [16] S Rosenblatt. 2013. Fake turkish site certs create threat of bogus google sites. http://cnet.co/2oArU6O
- [18] Ivan Seskar, Kiran Nagaraja, Sam Nelson, and Dipankar Raychaudhuri. 2011. Mobilityfirst future internet architecture project. In Proceedings of the 7th Asian Internet Engineering Conference . ACM, 1-3.
- [19] Marko Vukolifj. 2015. The Quest for Scalable Blockchain Fabric: Proofof-Work vs. BFT Replication .

Figure 11: The Experimental Result (Pull to node 9 from pkusz 1 and pkusz 3 Simultaneously)

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00418v1-figure-81a6bde2-5ab8-4ef7-93a1-6dba4d645adc.jpg)

- [20] Hequan Wu. 2019. Reflections on the Reform of Network Architecture. ZTE TECHNOLOGY JOURNAL 25, 1 (2019).
- [22] Nejc Zupan, Kaiwen Zhang, and Hans-Arno Jacobsen. 2017. Hyperpubsub: a decentralized, permissioned, publish/subscribe service using blockchains. In Proceedings of the 18th ACM/IFIP/USENIX Middleware Conference: Posters and Demos . ACM, 15-16.
- [21] Lixia Zhang, Deborah Estrin, Jeffrey Burke, Van Jacobson, James D Thornton, Diana K Smetters, Beichuan Zhang, Gene Tsudik, Dan Massey, Christos Papadopoulos, et al. 2014. Named data networking (NDN). Acm Sigcomm Computer Communication Review 44 (2014), 66-73.
Hui Li Jiangxing Wu Xin Yang Han Wang Julong Lan Ke Xu Yunyong Zhang Jinwu Wei Shisheng Chen Wei Liang Fusheng Zhu Yiqin Lu Wai Ho Mow Yeung Wai-Ho Zefeng Zheng Peng Yi Xinsheng Ji Qinrang Liu Wei Li Kaiyan Tian Jiang Zhu Jiaxing Song Yijun Liu Junfeng Ma Jiawei Hu Rui Xu Jiansen Huang Guohua Wei Jiuhua Qi Ting Huang Kaixuan Xing
MIN: Co-Governing Multi-Identifier Network Architecture and its Prototype on Operator's Network
IP protocol is the core of TCP/IP network layer. However, since IP address
and its Domain Name are allocated and managed by a single agency, there are
risks of centralization. The semantic overload of IP address also reduces its
scalability and mobility, which further hinders the security.
  This paper proposes a co-governing Multi-Identifier Network (MIN)
architecture that constructs a network layer with parallel coexistence of
multiple identifiers, including identity, content, geographic information, and
IP address. On the management plane, we develop an efficient management system
using consortium blockchain with voting consensus, so the network can
simultaneously manage and support by hundreds or thousands of nodes with high
throughput. On the data plane, we propose an algorithm merging hash table and
prefix tree (HTP) for FIB, which avoids the false-negative error and can
inter-translate different identifiers with tens of billions of entries.
Further, we propose a scheme to transport IP packets using CCN as a tunnel for
supporting progressive deployment. We deployed the prototype of MIN to the
largest operators' network in Mainland China, Hongkong and Macao, and
demonstrated that the network can register identifier under co-governing
consensus algorithm, support VoD service very well.