In Hybrid-IoT, as per Section 7.3, light peer devices send transactions to full peer devices, and those will include them in the newly generated blocks. Hence, full peers need to process an heavy transactions load. Therefore, the first performance test for Hybrid-IoT is a stress test, in which, set of light peers repeatedly sends transactions to full peers (see Section 7.4.1). Then, we shift the focus to the different sized PoW sub-blockchains, where full peers take part in the consensus process. Sub-blockchains can be generated with different number of full peers, which affects the time required to achieve consensus and the way in which the full peer manages its resources. Hence, the second type of performance test is done by varying sub-blockchain sizes and measuring the time needed to achieve consensus and the full peers’ resource usage (see Section 7.4.2).
7.4.1 Performance Evaluation I: Stress test
We design a DDoS attack simulation for the stress test: 20 light peers take the role of attackers; a full peer takes the role of victim; the attack is conducted for 45 minutes. All the peers are are virtualized with LXC (Linux Containers)13
containers and have the following configurations: • Full peer: Ubuntu 14.04 (Trusty) O.S; 512 MB RAM memory, 10% of one Intel Core i7 2.70 GHz CPU; 5 mbit/s ingress and egress network interface limit; bitcoind version 14.02 Bitcoin protocol’s full node. We measure CPU utilization, memory usage, and Ethernet activity with nmon.14
13
linuxcontainers.org
14
CHAPTER 7. HYBRID BLOCKCHAIN ARCHITECTURE FOR IOT 107
• Light peer: Alpine Linux 3.6.0 O.S; 128 MB RAM memory, 2% of one Intel Core i7 2.70 GHz CPU, 1 mbit/s ingress and egress network interface limit; Java SE; JRE 8 update 131 environment; Bitcoin protocol’s thin client model developed with bitcoinj library. We monitor CPU usage, memory usage, and Ethernet activity with RRDtool.15
We use Bitcoin regtest16
(regression test) network to execute the stress test. The DDOS attack is executed as follows: a number of attackers, max 20, generate a load of identical and valid transactions of ca 225 bytes at varying frequency (from ca 2tx/s to ca 9tx/s); once the victim receives the load it checks the transactions validity add them to the transaction pool. A load of 108960 transactions was generated with an average of 5448 transactions per attacker. For the sake of brevity, in the figures, we show measurements only for the first 15 minutes and only for the CPU component (the other components have very similar trends).
Victim results. Figure 7.317
shows the CPU usage of the victim: 90% of its CPU is exhausted by processing the attackers’ load; a similar measurement and graph is observed for its Ethernet activity; memory usage is steady around 150 MBs. The victim manages to receive and process over 40 transactions per second from 20 attackers. We can conclude that the victim successfully manages to perform its blockchain duties without crashing or halting under the heavy load from the attack (here heavy is attributed to the fact that the attackers’ resources are exhausted).
Attacker results. Figure 7.2 shows the CPU usage of one of the attackers: nearly 100% of the attacker’s CPU is exhausted (it is capable of processing ca 300 bit/s); there is an increase in memory usage from 99 MB (before starting to attack) to 124 MB (during attack), utilizing all of its memory. When one light peer takes the role of attacker, it manages a maximum of 9 transactions per second without crashing. This should help to characterize the capabilities of a light peer to generate transaction loads, regardless of the DDoS simulation performed. 7.4.2 Performance evaluation II: Sub-blockchain size
In order to measure the sensitivity to sub-blockchain sizes, we design four sub-blockchain em- ulation scenarios (Emulation I,II,III and IV) by varying the number of full peers in the sub- blockchains. In Emulation I the number of full peers is 20, in Emulation II 40, in Emulation III 100, and in Emulation IV 200. Peers are connected to each other in a round-robin way. All the full peers are virtualized with LXC (Linux Containers)18
containers on an IBM Power 8 server19
and have the following configurations:
• Full peer: Ubuntu 14.04 (Trusty) O.S.; 512 MB RAM memory; 5% of a single Power8 3.5 GHz CPU; 5 mbit/s ingress and egress network interface limit; bitcoind version 14.02 Bitcoin protocol’s full node. We measure CPU utilization, memory usage, and Ethernet activity (traffic
15
oss.oetiker.ch/rrdtool
16
bitcoin.org/en/glossary/regression-test-mode
17
Legend for Figure 2; user: avg CPU utilization for Bitcoin client; system: avg CPU utilization for kernel mode; wait: avg CPU utilization for I/O wait mode.
18
linuxcontainers.org
19
CHAPTER 7. HYBRID BLOCKCHAIN ARCHITECTURE FOR IOT 108
Figure 7.2: CPU utilization of light peer devices in Performance Evaluation I and packets) with nmon.20
We use Bitcoin regtest (regression test) network to execute the emulations. The emulations are executed as follows: in each emulation we submit 11.000 identical transactions (225 bytes) to the network with one full peer; one peer submits to the remaining full peers the 5 blocks with 1 minute block generation interval; the full peers achieve consensus on the submitted blocks. We measure resources utilization at the last peer of the round-robin from the moment at which the submitting peer proposes the first block of the five, till the moment in which all the five blocks are recorded on the local blockchain copy of the last round-robin peer (we refer this as the consensus cycle in the rest of the chapter). We note that we do not employ light peers to generate loads. This is justified by the need of measuring consensus with heavy transactions loads. All measurements are in Table 7.6 or in the text below.
Results. We observe that the consensus cycle is longer with sub-blockchains with more full peers as block and transaction propagation takes longer. We show in Table 7.6, that on average, emulation scenarios with more full peers use less resources. This is because, with sub-blockchains with more full peers, resource utilization is averaged over longer consensus cycles.
20
CHAPTER 7. HYBRID BLOCKCHAIN ARCHITECTURE FOR IOT 109
Figure 7.3: CPU utilization of full peer devices in Performance Evaluation I Metrics 20 peers 40 peers 100 peers 200 peers
Avg CPU usage 6.7% 5.2% 2.8% 2.1%
Avg Memory usage 115 MB 109 MB 109.1 MB 108.7 MB Avg Ethernet traffic 7.9 KB/s 6.2 KB/s 3.6 KB/s 1.6 KB/s Avg Ethernet packets 9.4/s 8.5/s 5/s 3.6/s
Table 7.6: Perf Eva II: Performance Statistics