# A Cryptography-Powered Infrastructure to Ensure the Integrity of Robot Workflows
## 4 Application and Evaluation in a Real Robot System
### Results
#### 4.3.2 Benchmarks  
In order to evaluate the signature generation and the signature verification process, we measured the average time consumption and the allocated memory by running benchmark tests using the BenchmarkDotNet library. For our measurements, we also varied the workflow queue size in order to get a relation between queue size and average time consumption. Table 3 contains the results for the generation process, whereas the results for the verification process are shown in Table 4. As before, the base unit for measuring the queue size is a MoveBase workflow followed by a pick-and-place sequence. \begin{table}
\begin{tabular}{l l l} \hline \hline
**Queue Size** & **Request Data [Byte]** & **Response Data [Byte]** \\ \hline
1 & 5154 & 515 \\
2 (Use Case) & 10,308 & 515 \\
4 & 20,616 & 515 \\
8 & 41,232 & 515 \\
16 & 82,464 & 515 \\
32 & 164,928 & 515 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: GRPC signing service—Transmitted data depending on the queue size. \begin{table}
\begin{tabular}{l l l} \hline \hline
**Queue Size** & **Mean Time Consumption [μs]** & **Allocated Memory [KB]** \\ \hline
1 & 111 & 16.59 \\
2 (Use Case) & 135 & 32.97 \\
4 & 178 & 65.77 \\
8 & 265 & 131.42 \\
16 & 451 & 262.86 \\
32 & 796 & 525.98 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Benchmark results of the workflow queue signature generation process. The first observation we make is that the signature verification process runs faster on average than the signature generation process and that the offset between the mean values is more or less constant regardless of the workflow size. The offset can be explained by the fact, that verifying a RSA signature is in general faster than generating it, due to the significantly smaller exponent usually chosen for the RSA-public-key. Since we generate the signature from the root hash of the Merkle tree, which has a fixed length of 256 bits, the offset does not depend on the queue size as well. Second, both processes allocate almost the same amount of memory and the memory consumption grows linearly with the queue size. The third observation relates to the correspondence between the queue size and the average time consumption over the corresponding benchmark iterations. Since the generation and verification of the RSA signature do not depend on the workflow queue size and thus cause a constant overhead, we only need to further investigate the generation of the Merkle tree. For that we look at the number of hashes which need to be generated in order to build up the tree. In the following, we suppose that our queue size \(n\) equals a power of two. This means that the final Merkle tree is a complete binary tree, which requires the maximum amount of hashing operations in order to build it up. First, the hashes of the queue elements need to be calculated. After that, the resulting hashes are paired up, concatenated and hashed again. Since this procedure is repeated until the root hash is generated, we can describe the overall number of hashing operations \(N\) with the following term:  
\[N=n+\frac{n}{2}+\frac{n}{4}+\cdots=\sum_{i=0}^{log_{2}(n)}\frac{n}{2^{i}}=n \cdot\sum_{i=0}^{log_{2}(n)}\frac{1}{2^{i}}\]  
The fact that  
\[n=2^{k},k\in\mathbb{N}_{0}\]  
implies  
\[log_{2}(n)\in\mathbb{N}_{0}\]  
Further we know that  
\[log_{2}(n)<log_{2}(n+1),\forall n>0\]  
and  
\[\sum_{i=0}^{\infty}\frac{1}{2^{i}}=2\]  
Finally we get  
\[N=n\cdot\sum_{i=0}^{log(n)}\frac{1}{2^{i}}<n\cdot\sum_{i=0}^{\infty}\frac{1}{2 ^{i}}=2n\]  
which results in a linear relation between the size of the workflow queue and the number of hashing operations necessary to build the Merkle tree. The scatter plot shown in Figure 10 summarizes our findings. \begin{table}
\begin{tabular}{l l l} \hline \hline
**Queue Size** & **Mean Time Consumption [\(\mu\)s]** & **Allocated Memory [KB]** \\ \hline
1 & 20 & 18.13 \\
2 (Use Case) & 44 & 34.52 \\
4 & 91 & 67.3 \\
8 & 175 & 132.95 \\
16 & 257 & 264.39 \\
32 & 708 & 527.51 \\ \hline \hline \end{tabular}
\end{table}