# BGPcoin: Blockchain-Based Internet Number Resource Authority and BGP Security Solution
## 5 BGPcoin Architecture for BGP Security
### BGPcoin_ROAServer  
We design a sub-contract to register and audit the binding from the ASN to the IP block for their owner. Every resource user maintains an Ethereum client for the contract, whose AS resource and IP address resource have been announced by the BGPcoin_Client contract. A legal binding operation changes the state of the IP address resource from \"assigned\" to \"bound\" and adds an ROA to the ROAServer contract. ROASever checks the operation validity according to the usuftract of resources and then updates the ROA repository. **Route origin advertisement. ** A valid ROA has the structure:  
\[(<\pi,\mathit{stime},\mathit{period}>;a)\]  
which means the AS \(a\) originates the IP block \(\pi\) in the time period from \(\mathit{stime}\) to \(\mathit{stime}+\mathit{period}\). A valid ROA represents that the bound IP block is leased to the AS owner and had not been bound before. Otherwise, the binding operation fails, and the corresponding ROA would not be generated. This approach to submitting and recording ROAs gives a simple and clear way to publish and attest to the route origin data. Compared with the method of downloading the validated ROAs from RPs in RPKI, ours allows an edge router to directly request IP address resource bindings from the Ethereum client in its own AS. Besides, the Multiple Origin Autonomous System (MOAS) conflicts never appear in BGPcoin. **Aggregated ROA or minimal ROAs? ** Aggregation of prefix information reduces the number of entries BGP has to carry and store. Sometimes, for traffic engineering, an AS announces subprefixes of its larger prefix, which is called de-aggregation. We avoid simply exploiting the harmful maxlength attribute in RPKI [32], which was originally designed for de-aggregation in ROAs. According to the longest-prefix-match principal, a forged-origin subprefix hijack is able to act successfully by de-aggregating a subprefix from a valid ROA with its maxlength attribute and trigger a misleading BGP route update. Moreover, BGPcoin supports the \"compressing minimal ROAs\". By realizing three origin advertisement/authentication modes, we deal with the three different types of origin advertisement situations and forbid the subprefix hijack. For a valid ROA \((\pi;a)\), where \(\pi=(IP_{\pi},len_{\pi})\),  
1. **Aggregated ROA mode:** If ROA \((\pi;a)\) has its maxlength\(l_{\pi}^{\prime}(len_{\pi}^{\prime}-len_{\pi}>0)\), that means a set of sub-ROAs with the amount of \(\sum_{i=0}^{len^{\prime}>len}2^{i}\). The \(a\)'s owner adds the ROA \((\pi;a)\) by sending an addAggrROA transaction to the address of the BGPcoin_ROAserver contract, who adds ROA \((\pi;a)\) to the BGPcoin storage and then changes the prefixlimit of \(IP_{\pi}\) to \(len_{\pi}^{\prime}\), which means: \[BGPcoin\_IPchain\_keys[IP_{\pi}].prefixlimit=len_{\pi}^{\prime};\]
2. **Minimal ROA mode:** If only ROA \((\pi;a)\) and some of its subROA \((\pi^{\prime};a)\) are valid, where \(\pi^{\prime}\subset\pi\), the \(a\)'s owner adds \((\pi;a)\) as usual, and then, it sends an addMinROA transaction of \((\pi^{\prime};a)\), which adds ROA \((\pi^{\prime};a)\) to the BGPcoin storage, and then changes the prefixlimit of \(IP_{\pi^{\prime}}\) to \(len_{\pi^{\prime}}\), and the default nonexistence flag is false, which means: \[BGPcoin\_IPchain\_keys[IP_{\pi^{\prime}}].prefixlimit=len_{\pi^{\prime}};\] \[BGPcoin\_IPchain\_keys[IP_{\pi^{\prime}}].deleted=false;\]
3. **Compressing minimal ROA mode:** If ROA \((\pi;a)\) has its sub-ROAs \((\pi_{i};a),i=1\cdots k\) where \(\pi_{1}+\cdots+\pi_{k}=\pi\), the \(a\)'s owner adds \((\pi;a)\) as usual and then divides \(\pi\) into \(k\) subprefixes. We gives three examples to explain that different ROAs are suitable for what kinds of modes.