# A Blockchain Protocol for Authenticating Space Communications between Satellites Constellations
## 6 Discussion  
Prior studies that have noted the importance of using blockchain technology in the space industry are still little and immature. However, some reports have shown that Blockchain will be a base technology in developing the next generation of open-source satellites and spacecraft. In reviewing the literature, some research efforts discussed the adoption of blockchain to solve various challenges in the space industry and satellite communications. These challenges are the security and privacy of satellite communications [27; 28], and satellite data broadcasting [29]. An initial objective of the study was to propose a new concept called space digital tokens (SDT) to build a new blockchain protocol called Proof of Space Transactions (PoST). The first question in this study sought to determine the efficiency of PoST in managing satellite transactions in the same swarm. The answer to this question shaped various interesting results. Firstly, the impact of the number of satellites transitions (where the size of a transaction is 1049 bytes) on transaction latency of blockchain when PoST is applied is not significant as it did not increase transaction latency by more than 0.05 TPS although the read latency is in a variable relationship with the number of satellite transactions (as shown in Figure 4). This means that satellite \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**\#Satellites Trans** & **(RT)/RPS** & **(TT)/TPS** & **Gas** & **Size (BYTES)** \\ \hline
50 & 112.61 & 1.53 & 549,084 & 3049 \\ \hline
100 & 76.39 & 1.01 & 549,084 & 3049 \\ \hline
150 & 55.71 & 0.72 & 549,084 & 3049 \\ \hline
200 & 43.81 & 0.56 & 549,084 & 3049 \\ \hline
250 & 36.98 & 0.46 & 549,084 & 3049 \\ \hline
300 & 31.61 & 0.38 & 549,084 & 3049 \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Results of the impact of the transactional data size **3049** bytes on RT, and TT according to the number of satellite transactions. \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**\#Transactions** & **TP** & **TN** & **TPR** & **TNR** & **Accuracy** \\ \hline
100 & 50 & 50 & 100\% & 100\% & 100\% \\ \hline
200 & 100 & 100 & 100\% & 100\% & 100\% \\ \hline
300 & 150 & 150 & 100\% & 100\% & 100\% \\ \hline \hline \end{tabular}
\end{table} 
Table 7: TPR, TNR, and Accuracy of PoST protocol in verifying satellites transaction. transactions can be quickly processed even with the increasing number of satellite transactions and the variance of reading latency. Moreover, the results showed the impact of the number of transactions on the total read throughout (RT) and transaction throughput (TT) of blockchain is in a reverse relationship. This confirms also that the proposed PoST protocol can quickly process satellite transactions and confirm the efficiency of PoST in managing satellite transactions within a single swarm. The second question in this study sought to determine the efficiency of PoST in managing satellite transactions in different swarms. The answer to this question found that there is not a big impact of the number of satellite transitions (when a transaction size is 2049, and 3049 bytes) on transaction latency of blockchain when PoST is applied, as given in Figures 5 and 6. These results confirm that increasing the number of satellite transactions exchanged between different satellites between different swarms does not increase transaction latency by more than 0.05 TPS, hence, this proves the efficiency of the proposed PoST protocol in managing satellite transactions between different swarms of satellites whatever the number of transactions. Another important finding is the impact of transactional data size on reading throughput and transaction throughput. The obtained results proved that transactional data size (1049, 2049, and 3049 bytes) is in a reverse relationship with reading throughput and transaction throughput which interpret the efficiency of PoST in processing transactional data between satellites whatever its size in bytes.