# 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
* Step 2: The RLp selects the previously generated subset of IP addresses (RandIPSet) and asks them to execute the Validate procedure passing the actual parameters (certificate, domain name, IP address), executing the first part of the CONS procedure. * Step 3: Each selected peer (blockchain node) runs the Validate procedure. * Step 4: RLp receives M answers and sends the result to the target peer and to the whole blockchain (second part of the CONS procedure). We added functionality to the standard consensus algorithm to speed up the certificate check in our context and particularly, to avoid blockchain sharing time. The RLp first sends the result to the TP (to update its local blockchain) and then shares the same result in the blockchain (following standard blockchain protocol). The TP receives the same result twice, but this is not a problem. * Step 5: the TP reads the validation of the target certificate from its copy of the blockchain. Using a packet sniffer (Wireshark) positioned in the same subnet of each target peer, we measured, on the network, the time from Step 1 to Step 5 for each trial. In particular, we developed a program to read the output file of Wireshark and to update database records opportunely. To be more realistic and consider the fact that all of our clients are identical in their hardware and network configuration, we added a random component to each trial:

TimeLen = Time length of a trial(in seconds) = time measured by the sniffer + NormalDistr(1,1). NormalDistr(1,1) means a number selected randomly from a normal distribution with parameters (\(\mu\) = 0, \(\sigma\) = 1). With this decision, we considered the effects of clients with heterogeneous CPUs, other PC components, and network traffic. At this point, we adopted a cost function called CF(TimeLen). Considering that the final user cannot wait a lot of time for a response, CF has to be an increasing, always positive function:

\[\text{CF = (TimeLen - \tau)^{\tau}3+\tau^{\tau}3}\]

For TimeLen less than \(\tau\), CF is concave. For TimeLen greater than \(\tau\), CF is convex. Then, \(\tau\) represents a time beyond which waiting becomes quickly hard to accept. In our experiments, we used \(\tau\) = 3. The last field in the table is the RelativeSparsityIndex:

RelativeSparsityIndex = AbsoluteSparsityIndex/CF

**Results**

We submitted the following query to select the best M value (the sample size):

Select M, avg(RelativeSparsityIndex), avg(Time)

From ExperimentTrials

Group by M.

Table 13 shows the output (main results) of the query. \begin{table}
\begin{tabular}{c c c} \hline \hline \(M\) & avg(RelativeSparsityIndex) & Avg(Time) \\ \hline
20 & 30,434.78 & 5.66 \\
21 & 31,533.55 & 5.65 \\
22 & 29,675.02 & 5.92 \\
23 & 30,298.61 & 5.93 \\
24 & 31,341.9 & 5.94 \\
25 & 32,194.41 & 5.99 \\
26 & 31,380.52 & 6.01 \\
27 & 33,372.6 & 6.1 \\
28 & 39,412.3 & 5.98 \\
29 & 38,401.43 & 5.8 \\
30 & 39,532.11 & 6.04 \\
31 & 36,978.64 & 6.16 \\
32 & 34,779.43 & 6.12 \\ \hline \hline \end{tabular}
\end{table} 
Table 13: Summary of the most significant tests, where M represents the sample size (number of the selected peers), the second column represents the randomness index of the sample and the third column represents the average amount of time spent by the blockchain to obtain an answer. Using these data, Figure 2 was obtained. ## References

* [PERSON] (2008) [PERSON] Internet X.509 public key infrastructure certificate and certificate revocation list (crl) profile. _RFC_**2008**, _5280_, 1-151. * [PERSON] and [PERSON] (2011) [PERSON]; [PERSON], B.U. Diginotar certificate authority breach operation black tulip. _Fax-IT Interim Rep._**2011**. [CrossRef]
* [PERSON] and [PERSON] (2018) [PERSON]; [PERSON] Proof of Delivery of Digital Assets using Blockchain and Smart Contracts. _IEEE Access_**2018**, \(6\), 65439-65448. [CrossRef]
* [PERSON] et al. (2017) [PERSON]; [PERSON]; [PERSON] Performance Analysis of Private Blockchain Platforms in Varying Workloads.