# BGPcoin: Blockchain-Based Internet Number Resource Authority and BGP Security Solution
## 7 Implementation and Deployment
### Experiments on a Simulated Network  
To demonstrate the scalability and performance of our design, we first construct a simulated Ethereum network locally, which is much like the real Ethereum environment initialized with the default configuration except for that the mining difficulty is set lower than the real Ethereum environment for processing the experiment quickly. This allows us to focus on the performance of the search part on smart contract, irrespective of the time-consuming mining process and complex network circumstances (e.g., broadcast latency, transaction mining delay) in Ethereum. We set up BGPcoin by importing the IP register and allocation information to the blockchain.  
**Results:** To illustrate the impact of the mining process on the efficiency, we record the block number of each transaction generated in our setup phase and the corresponding gas usage, as shown in Figure 7. Since we experiment with the setup phase in parts at several different times, we only show one part of our blockchain data as a sample. The average block time for mining is 25 s, and the number of blocks containing transactions is more than 8000, resulting in nearly six days to complete the entire  
Figure 6: Resource distribution in BGPcoin.  
setup phase. This again explains why the time cost of setup is dominated by the smart contract, instead of the data owner, like in existing centralized search schemes.  
We are faced with a difficult problem to accelerate further the processing of our setup phase. The resource transaction needs to be reproduced in chronological order. For example, an IP prefix 45.0.0.0/8 has to be registered by IANA and allocated to ARIN firstly, and then, ARIN delegates 45.5.212.0/22 to Brazil. Therefore, these transactions with the inter-dependence and a strict chronological order lead to the less concurrency of the setup phase of BGPcoin. In our analysis, this is the other reason why the reproducing took such a long time. However, if we sent one transaction after the time the previous transaction had been confirmed, it would contain only one transaction in a block since the confirm unit on the blockchain is one block. Therefore, we still try to send 10-30 transactions at one time to ensure the current block to assemble as much transactions within the block limit. The transactions that have not been recorded in the current block wait to be confirmed in the next block. Moreover, we periodically collect the failed transactions that may have inconsistency and conflict with the current state of the traded resource and resend them later. We notice the current gas limit of the real Ethereum has become 7,992,222 gases, which increases 70% the gas limit at the time when we performed the BGPcoin experiment. Every block has a larger capacity to contain more transactions if we reperform the experiment now.  
Furthermore, we demonstrate the performance of executing the two most expensive operations, IP register and IP allocate in Figure 8. We experiment with the cost performance on more than 70,000 transactions reporting the real-world allocations and assignments of IP numbers. From the top row of the subfigures, we can tell that the allocation of IP numbers from an aggregated IP block costs far more than the cost of registering an IP block for an entity. We observe from the middle row figures that the highest cost of an IP allocate operation is linear with the prefix length of the operated IP block, which just conforms with the principal illustrated in Figure 3. Obviously, we can infer that the highest cost of allocating an IP prefix is from the biggest IP block that covers it (i.e., with the shortest prefix length of eight).  
Figure 7: Block gas cost and number of transactions in each block.