# BGPcoin: Blockchain-Based Internet Number Resource Authority and BGP Security Solution
## 5 BGPcoin Architecture for BGP Security
### BGPcoin_Checker  
**Origin authentication:** To achieve the origin authentication, every AS maintains a BGPcoin cache-client to cache the ROAs it learns from the blockchain. Different from the RPKI that downloads the validated ROAs from RPs, BGPcoin allows the border router to request ROA mappings from the cache-client in its own AS directly. There is two ways to update the cache:  
1. The cache client follows and syncs all the state transfer events related to ROAs that are derived from the increasing BGPcoin transaction event logs on the blockchain, to its current cache. The local cache, that is constructed like in RPKI, is pushed periodically to all border routers for origin authentication. 2. When a border router covering ROA queries a pair of IP prefixes and its claim to be the origin AS according to a new BGP update massage it receives, the cache client sends a SearchROA transaction to the BGPcoin_Checker contract to retrieve a corresponding ROA. We model simplistically a BGP route as an IP prefix \(\pi\) and an origin AS \(a\). A BGPcoin cache-client has a local cache of the complete set of valid ROAs, which are used to classify each route \((\pi;a)\) learned in BGP update massages into one of three route validation states:  
* **Valid:** A route \((\pi;a)\) is valid if there exists a matching ROA, which meets three requirements: (1) a matching origin AS \(a\); (2) a prefix \(P\) that covers prefix \(\pi\); and (3) according to the three ROA modes, one of the conditions should be satisfied: (a) if there exists a specified maxlength, then it is no shorter than the length of \(\pi\); (b) else, if the prefix \(P\) exists in \(BGPcoin\_IPchain.IPB\), then the prefix \(\pi\) should exist in \(BGPcoin\_IPchain.keys\); (c) else, if the prefix \(P\) has been divided into subprefixes, then the prefix \(\pi\) should be in \(BGPcoin\_IPchain.IPB\). * **Unknown:**\((\pi;a)\) is unknown if one of the conditions below happens: (1) the prefix \(\pi\) or the AS \(a\) has not been registered in BGPcoin; (2) the prefix \(\pi\) has been allocated or assigned to the AS \(a\)'s owner, and there is no valid covering ROA that contains a bound prefix that covers \(\pi\). * **Invalid:**\((\pi;a)\) is invalid if neither of the conditions required in the valid validation state and unknown validation state are satisfied. **Path_end authentication:** The cache-client periodically syncs records of adjacent ASes from the ASlist storage in BGPcoin and pushes the resulting AS relation white list to BGP routers. Through checking from which ASes an origin AS can be reached, routers discard BGP advertisements on whose advertised path the end hop AS before the origin AS does not appear in the list specified by the origin AS. This filter enables BGPcoin to eliminate not only prefix/subprefix hijackings, but also next-hop AS attacks. The BGPcoin_Checker contract not only serves for the border gateway routers and their cache-client to retrieve the ROA records and the adjacent AS information, but also incentives any volunteer as the detector towards the anomalies of BGPcoin. In other words, anyone is allowed to send a query transaction to check the ROA records, and if he/she discovers some anomaly in ROA records, he/she can report it to this contract and get a reward. **Checker incentivization:** Network operators and registries have few incentives to remove obsolete registry objects like expired ASNs and ROAs. Though it has no effect of enlarging the attack surface toward the BGP routing, the increasing volumes make the resource searching execution cost more gas. Furthermore, it frustrates the initiative of the autonomous domain to deploy BGPcoin. Therefore, BGPcoin considers an incentive checking mechanism to encourage any auditors reporting the obsolete objects and potential inconsistent ROA caused by the situation that the bound AS is updated by changing its owner, but the owner of the bound IP block is not changed in-step. We follow the report-and-reward design in [33].