Page 81 - RAC_CIAW_ a_I_n_01_2021.pdf

the possibility of tampering by an attack. Hence, these that meet good QoS levels. Moreover, the computa-
lighter devices don’t possess the same computational tional power of a server can be improved more easily
resources as the system servers. This is why the perfor- to support a bigger network with a larger number of
mance analysis is bold on the sensing nodes. sensing nodes.
In the server, we analyze the CPU and memory We emphasize that we choose low-cost hardware
usage in each blockchain entity as shown in Figure 5. to demonstrate that blockchain solutions for MMSs
We evaluate the performance of Smart Contract (it runs are suitable not only for resource-rich projects. Fur-
in a self container), Endorser, Committer, Orderer, and thermore, the robustness and reliability of blockchain
CouchDB (the local ledger), each one running isolated solutions primarily depend on the number of Peers that
on its Docker container. compose the network, demanding more resource re-
The Smart Contract has a low consumption in dundancy rather than individual hardware power.
CPU (3%) and memory (4.3 MB) due to, in our pro-
totype, it has only the function to process and verify CONCLUSIONS AND FUTURE WORK
the AIS entries. On the other hand, the Endorser alone
consumes an average of 11.7% of CPU and 102 MB Most naval systems operating nowadays, includ-
due to its transaction sign function, using asymmetric ing communication, navigation and monitoring sys-
cryptography algorithms. tems are poorly mature when it comes to cybersecurity.
Aiming to reduce vulnerabilities in naval systems, this
The Orderer has an consumption average of 5% paper presented a blockchain-based MMS model that
of CPU and 25.3 MB of memory, but this need will can leverage security, ensuring the integrity, authentic-
increase with the number of Peers in the blockchain ity, and availability of sensing data.
system, demanding more computational resources.
The Committer, which verifies the new blocks broad- To fulfill the proposed objectives, we successful-
cast by the Orderer and add it to the ledger, consumes ly developed a permissioned blockchain prototype on
an average of 7% of CPU and 31.7 MB of memory. HyperLedger Fabric platform and made it available in
Finally, CouchDB consumes an average of 102.7 MB a public repository to allow other researchers to rep-
due to its database function requires more memory licate our experiment. With the security analysis, we
and 7% of CPU. demonstrated how the blockchain could help mitigate
some MMS vulnerabilities. We integrated the block-
All containers on our server, however, consume chain prototype with a low-cost AIS receiver developed
an average of 224.2 MB, representing 11% of all 2048 by the Brazilian Navy and sent 1500 real AIS entries to
MB of the server’s memory, and 34.4% of server’s simulate an MMS operation in a real environment. The
CPU. As mentioned before, this consumption of com- experiment allows us to quantitatively determine the
putational resources will increase with the blockchain overhead caused by the use of blockchain technology.
size. Still, Fabric’s blockchain delivers a performance
The results showed that despite the increase in CPU
and memory consumption, this overhead is at an ac-
ceptable QoS level and is justified by the data security
improvements.
As future work, we will continue to develop our
blockchain prototype to achieve scalability in a full-
scale MMS, capable of monitoring the whole coast of
a country. In our research, we integrate our prototype
with just one sensing system (AIS) and further devel-
opments are necessary to extrapolate this integration
to different sensing systems in a heterogeneous MMS.
Another subject of further study is the fusing of
the blockchain’s decentralization capabilities and the
data analysis/decision-making functionality of AI. The
symbioses of these two technologies could allow an
Fig. 5: Server Performance MMS to evolve to a Command and Control system

CIAW – EFICIÊNCIA, CULTURA E TRADIÇÃO 81