# A Blockchain based PKI Validation System based on Rare Events Management
## 4 A New Approach to X.509 Certificate Management Using Distributed Ledger Technology (DLT)
### The Smart Contract Structure and Its Relationships with the Consensus Algorithm
Due to the fact that all the peers of the chosen subset must give the same result, here it is possible to apply different strategies, bases on the ratio among FAKE and VALID results. When we say, \"The tuple is in the blockchain\", we intend it to be in the ledger of each peer in an architecture where each peer shares results with all other peers. An important aspect to be stressed is that our smart contracts do not look exclusively inside the blockchain nodes to complete their execution but also use information coming from the network. This could sound strange considering that in a blockchain application the only trusted information is that stored in the blockchain itself. In our case this \"strange\" behavior is acceptable, because the network itself is not trusted, but the result given to the smart contracts and shared among nodes by the Cons algorithm become trusted by its numerosity. ## 5 Experimental Results

The checking of X.509 certificates has to be done in the middle of the TLS session and has to be fast. The issue is crucial: one of the main weaknesses of blockchain solutions is the time delay between the execution of a smart contract and the consequent updating of the blockchain. To deal with this issue, and to check that the time delay introduced by our solution is acceptable (just few seconds; less than 6 s), we implemented a prototype of a blockchain in a network with five CAs, 100 web servers, and 100,000 users. Each user connects to the web server with a maximum frequency of 10 requests/minute. The goal of the experimental phase was to test the response times behind the approach. We had to measure the delay introduced by the blockchain to check the server certificate and to select blockchain parameters to obtain acceptable delays. The functional properties are described in the next paragraph. We implemented a prototype of the blockchain using the Go programming language (GOLANG). The communication channels were managed using the gRPC protocol (the same as hyperledger fabric). Each peer knew four to eight adjacent peers. We ran a simulation comprising five CAs, 100 web servers, and 100,000 users, where each one connects to the web servers with a frequency of 10 pages/minute. Client requests were serial: to start a new request, the client had to terminate the previous one. Each experiment, conducted in our lab, consisted of 5 min of all entities working. In one of the experiments, for example, we registered 4,102,728 trials (client requests with full responses). This means that, on average, each client made 41 requests, and each server received 41,027 requests. Figure 2 presents the results of the experiment, where the M (\(x\)-axis) is the minimum number of peers that checked an X.509 certificate, and RelativeAvgRandomness (\(y\)-axis) is a relative index showing the sparsity of IP addresses. We can suggest some reasons behind these numbers. * First, the distance function uses the IP addresses of peers and then has an upper bound related to the physical structure of the network. Two peers are far each other if randomly selected in the two different subnetworks. The sparsity index grows linearly with M.
* Secondly, network times increase with the growth of network traffic and the cost function. For high network times, growth is exponential. For these reasons, the ratio between the sparsity index and time costs grows initially and then decreases, reaching the maximum value for M = 30. The experimental results tell us that the optimal configuration of the Cons algorithm occurs when the value for N, the size of the subset of the peers that participate to the consensus, is 30. In this case, the blockchain delay is less than 6 s, a negligible delay for the first page during HTTPS web browsing. This is the first important result of our analysis--a delay of 6 s is introduced to the certificate validation procedure based on a distributed approach. A contains technical and numerical details about the experiment.