Accelerating Blockchain Applications on IoT Architecture Models—Solutions and Drawbacks

The second row of Table 1 shows the results determined from the call graph of a valid transaction creation for Hyperledger Sawtooth, with a transaction payload of 32 bytes. For interacting with the Transaction Processor (smart contract), the IntKey transaction processor officially provided by Hyperledger Sawtooth was slightly modified to allow to initialize a variable of 32 bytes size.

The first row of the table contains the main functions that are required for a valid transaction creation in both Hyperledger Sawtooth and Ethereum blockchain. In reality, the build_signature function takes 99.37% of the main function, representing 100% of the total execution time of the API. As the build_signature function occupies almost the totality of the main function, we selected it as the father function (blue column), taking the totality of the API’s execution time. The results show that almost 91% of the total API execution is occupied by the SignTx function calling the ecdsa_sign_digest function of trezor-crypto² open-source C library. The ecdsa_sign_digest function realizes the digital signature of the transaction (first signature) and the batch (second signature). This two signatures procedure is specific to Hyperledger Sawtooth, and the secp256k1 elliptic curve is applied. The results also show that the sha512Data function corresponding to the SHA-512 cryptographic hash function computation takes 4.52% of the total execution time. This hash algorithm is used to calculate the payload’s hash value and create the address encoding needed to access the ledger state variables (address encoding can also be performed by using SHA-256). The sha256Data function realizes an SHA-256 hash function computation and is called for performing the hash value of the transaction and the batch. These hash values are one of the main components of the digital signature (i.e., the hash value of the data that is signed not the data itself). The two SHA hash functions above are implemented in Crypto++³ free and open-source C++ library.

Table 1 summarizes the results of the call graph for a single Ethereum valid transaction creation process when the transaction’s payload size is 32 bytes. The payload calls a smart contract function to set the value of a 32-byte variable in the ledger state. The API was tested with the Ganache⁵ tool providing a one-click Ethereum blockchain.

The main function of Ethereum API takes 100% of the API’s total execution time. All the functions taking less than 2% of the execution time are not presented. The main function is divided into two branches. The first branch starts with the SetupContractData function (5.25% of the total execution time), in which the payload will be ABI encoded for the smart contract calling. The second, consists of the createTransaction function taking 91.93% of the total execution time. This latter function is composed of three other functions. First, the RLPEncode (4%) is called to RLP encode all of the transaction components (nonce, payload, gas price, gas limit, etc.); this function is not presented in the table. After the RLP encoding, the keccak_256 function (Keccak cryptographic hash function) is called to hash the RLP encoded elements. This function takes around 2% of the total execution time. Contrarily to Hyperledger Sawtooth, for Ethereum transaction signature, the Keccak hash function is applied instead of SHA-256. The third sub-function is the SignTrezor, which signs the hash value of the transaction. This function uses the ecdsa_sign_digest function of the trezor-crypro library to perform the signature, such as the case in Hyperledger Sawtooth. This signature procedure takes more than 79% of the total execution time, which is a significant portion of the total execution.

We can note that in the case of Ethereum transaction creation, the digital signature procedure takes less time of the total execution compared to the Hyperledger Sawtooth API. However, in Hyperledger Sawtooth API, a double signature is created, one for the batch and one for the transaction contained by the batch.

In this part of this study, we analyzed the proposed IoT APIs, and we could observe that the most resource-intensive part of the APIs is due to the digital signature algorithm. We also highlighted that elliptic curve point multiplication is the core operation of the digital signature algorithm. To achieve better performance, this operation should be optimized by using a software or hardware approach.

In the following section, we collect the existing ECPM hardware accelerators found in the literature, which can eventually be applied in new IoT hardware architectures. We also compare them and select the most optimal hardware accelerator for ECPM. The selected design will be used in our proposed IoT hardware model.

The call graph analysis also highlighted that the hash functions take a small portion of the total execution time. However, it should be noted that the time taken by the hash function can be different when the payload size increases (it was also demonstrated in Reference [17]). The following section also lists some of the existing hardware accelerators for hash function families that can be embedded in new hardware architectures. Our proposed IoT hardware model also contains hardware acceleration for hash functions.

In the previous section, we demonstrated that the execution of the elliptic curve digital signature can take almost at least 80% of the total execution time of the given blockchain API. We also demonstrated that the elliptic curve point multiplication operation takes 85% of the signature’s execution time. However, we did not detail how the elliptic curve multiplication appears in the signature algorithm. In the following, a brief description is given about the main steps of the ECDSA. We assume that the description of ECDSA is illustrated similarly as in References [23, 34, 46] and RFC-6979 standard is detailed in Reference [38].

The following algorithm demonstrates the ECDSA. The message that has to be signed is denoted as msg.

The first step of the algorithm is the computation of the hash of the message to sign (e.g., the SHA-256 hash algorithm). The second step is the secret integer generation (k) derived from the hmac (hash-based algorithm) [26] of the message digest and the private key of the message signer. The private key is also an integer in the range of \([0, \dots , n-1]\) with n, the order of the generator point G (with x, y coordinates) lying on the given elliptic curve E.

This integer is used in the third step for calculating a random point on the given elliptic curve (E). The random point calculation is performed by the elliptic curve point multiplication of the generator point by the secret integer (k). This operation corresponds to adding the point G to itself k times.

Ethereum and Hyperledger Sawtooth apply secp256k1 curve, a Weierstrass form curve that can be defined over the finite field or prime field \(\mathbb {F}_{p}\), with \(p \gt 3,\) and can be described by the following equation:with an imaginary point of infinity \(\vartheta\), and with \(a,b \in \mathbb {F}_{p}\), and a condition to respect: \(4 a^{3} + 27 b^{2} \ne 0 \pmod p\). The fourth step uses the x coordinate of the random point (\(R(x,y)\)) calculated in the previous step to determine the signature proof (s). The final step represents the signature composed by the x coordinate of the random point (\(R(x,y)\)) and the signature proof (s). When using the secp256k1 curve, the signature is 64 bytes long.

This subsection presents the ECPM designs that we can find in related works. We also provide a Table 3 summarizing the designs’ features regarding the type of the implementation, operation latency, the frequency at the design works, and the speedup that can be achieved against the ECPM executed on BCM2837 (Raspberry Pi 3 B+) ARM-based architecture.⁶

It must be specified that the ECPM hardware accelerator designs must allow working with the secp256k1 curve (required by Ethereum and Hyperledger Sawtooth). This requirement also implies that the given design must operate over 256-bits prime field \(\mathbb {F}_{p}\) (\(p\le 256\)) and not over the binary field \(\mathbb {F}_{2^{n}}\). The 256-bits prime field is required because the secp256k1 curve is designed to be used with 256-bits operands. Hence, the goal is to find designs compatible with the secp256k1 curve and eventually with other Weierstrass form curves. It must also be noted that secp256k1 is not a NIST-recommended curve, which implies that hardware accelerator designs for NIST-recommended curves cannot be an option in our research.

Most of the related works present FPGA implementations of the accelerator designs, which can also achieve significant speedup and low latency. However, the ECPM hardware accelerators should be implemented in ASIC in future IoT hardware architectures. The design implementation in ASIC will provide at least the same latency and, theoretically, even lower than the FPGA implementation can provide.

Shah et al. [42] mention that the major part of today’s designs can work only with NIST-recommended curves, which is a significant drawback. To address this problem, the authors propose an architecture compatible with any of the Weierstrass form curves defined over the general prime field of 256 or 512-bits (\(\mathbb {F}_{p}\) with \(256 \le p \le 512\)). The design implementation on Virtex-6 FPGA operating on curves defined over 256-bits prime field can achieve a significant 0.65 ms of latency at a relatively low frequency of 144.5 MHz (see Design 1 in Table 3).

The authors of Reference [4] propose an ECC processor for accelerating the ECPM operation. This design is programmable and can be used with any Weierstrass curves (the secp256k1 curve is included) defined over the prime field of 256 bits. The design includes a pipelined Montgomery Modular Multiplier (pMMM) to accelerate the operations and a BRAM to store the given curve’s parameters. As the curve’s parameters can be stored, only the k random integer (see Algorithm 1) must be set before the point multiplication operation. The authors implemented the design on Virtex-7 and XC72020 FPGA boards. The Virtex-7 implementation provides a latency of 0.158 ms at 204.2 MHz. The implementation on XC72020 can achieve a slightly higher latency of 0.206 ms but at a less high frequency of 156.8 MHz (see Design 2 in Table 3).

The hardware design proposed by the authors of Reference [22] allows the ECPM operation on all of the “secure elliptic curves” [9] (including the secp256k1 curve) studied and tested by the team of Bernstein. The design implementation on the Virtex-6 FPGA board can provide a latency of 2.01 ms at 95 MHz. Compared to the two previous designs, this design is slower and its latency is higher (see Design 3 in Table 3).

The authors of Reference [30] propose a secp256k1 curve-specific ECPM design, which means that the design can operate only on this curve. This design is intended to operate on Residue Number System (RNS), which also means that the secret integer (k) and the result (coordinates of the random point R) are in RNS format. Moreover, the coordinates are Jacobian (x,y,z) and not finite coordinates (x,y). The authors also adapted the RNS architecture to multiple methods of ECPM and found that GLV (Gallant-Lambert-Vanstone) method of computing scalar multiplication can provide the fastest operation. The design implementation on Virtex-7 FPGA achieves 0.25 ms of latency at 125 MHz of frequency. The design on a more recent board Virtex-UltraScale+ provides a latency of 0.176 ms at 181.8 MHz of frequency (see Design 4 in Table 3).

Only one ASIC implementation was found among the recent related works. This design was proposed in Reference [37]. This EC co-processor allows using the curves defined over the general field. The latency of this design is high: 23.06 ms at a clock frequency of 100 MHz, which is almost 100 times higher than the other recent FPGA implementations presented above. This high latency is due to the architecture design being resistant against Side-channel attacks. However, another recent work [24] achieved a successful Side-channel attack on the mentioned design (see Design 5 in Table 3).

In less recent works, the only ASIC design found was published in Reference [11]. The design has a latency of 1.01 ms at a significant 556 MHz. That high frequency cannot be considered useful in IoT architectures (see Design 6 in Table 3). Table 3 represents the ECPM hardware accelerator designs we found in related works presented above.

The table also contains the possible speedup that can be achieved against the execution of ECPM on BCM2837 (Raspberry Pi 3 B+) ARM-based architecture. The digital signature execution time of ECDSA on the BCM2837 is 2.6 ms. Thanks to the analysis results (see Table 2), we know that 85% of the execution time of the digital signature (\(T_{total}\)) on the hash of the message to sign (ecdsa_sign_digest) is taken by the ECPM operation. The hardware accelerator is intended to accelerate this 85% of the ecdsa_sign_digest function, and its execution time (\(T_{HardwareAccelerator}\)) corresponds to the design’s latency. The 15% left is not accelerated. The speedup can be calculated, thanks to the equation below.with \(T_{total}\) the total execution time before the acceleration, and \(T_{total}^{\prime }\) the total execution time after acceleration.

The specifications of the listed designs demonstrate that most of the designs can provide a speedup against BCM2837 quad-core architecture. The design that we aim to use in the IoT architecture model that we present later (Section 6) should provide a high speedup at a relatively low frequency. Comparing these designs is not evident, because the designs are implemented on different FPGA boards and as ASIC. However, we can compare them according to the designs’ speedup, frequency, and other features.

We can state that Designs 5 and 6 (ASIC implementations) are slower than the other designs. It is also evident that Design 3 cannot be chosen because of its low speedup. It can also be declared that Design 2 and Design 4 beat Design 1 in terms of speedup (almost twice higher) and frequency usage (lower). We can observe that Design 4 Virtex-Ultrascale+ implementation can slightly beat Design 2 XC7Z020 implementation in terms of speedup and the Design 2 Virtex-7 implementation in terms of frequency usage. However, Design 4 has three drawbacks compared to Design 2. First, the design uses Jacobian coordinates. When a software aims to use these results, it must convert them to affine coordinates. Second, the coordinates must also be in RNS representation, which again must be converted on the software side and which can take some additive time. The last drawback is that this design can only be used with the secp256k1 curve. The Design 2 can be used with any Weierstrass form curve of 256 bits, and this feature can also be considered a significant advantage. In future IoT-Blockchain use cases where the given blockchain uses a different Weierstrass curve than the secp256k1, the design can still be used (only its reprogramming is needed). We chose to use the XC7Z020 implementation of Design 2 as an ECPM hardware accelerator in our IoT architecture model (see Section 6), because it uses almost 50 MHz less frequency than the Virtex-7 implementation but almost provides the same high speedup. In the following, we consider that this is Design 2, which will be used in the proposed IoT architecture model.

The hash function provides a fixed size output value (e.g., 256 bits), which is the unique representation of the input message. The hash function comprises two main components: Padding and Compression Function.

As the message (m) can have arbitrary size, it must be divided into chunks (\(m_{1}, m_{2} ... m_{n}\)) of fixed size (e.g., 512-bits chunks in case of SHA-256). The padding is needed to pad the chunks or last chunk with some additive information. Each of the message chunks is consumed by the Compression Function, one after the other. The Compression Function provides the internal hash (\(H_{i}\)) of the given message chunk; this hash value is used for producing the next chunk’s hash value (\(H_{i+1}\)). The hash of the last chunk corresponds to the hash of the message. The most resource-intensive part of the hash algorithms is the Compression Function. Therefore, the hash hardware accelerator designs realize this part of the algorithms.

In this part of our work, we list, compare, and choose the hash hardware accelerators that could be implemented in the proposed IoT architecture model. The following designs were found in the literature, and most of them are implemented as IPs in ASIC. The comparison of the designs is based on their latency, throughput, frequency, and speedup can be achieved against the execution time when the hash is computed on a BCM2837 ARM-based architecture (Raspberry Pi 3 B+).

These ASIC implementations are based on different CMOS transistor technologies, making it difficult to compare them. Therefore, the CMOS scaling estimation method is applied to estimate the latencies corresponding to the same designs but implemented on 40 nm CMOS technology [44].

The hardware accelerator proposed in Reference [19] allows accelerating the SHA-256, Keccak-256, and Blake hash functions on a single chip. The Verilog source code⁷ of the design is still open-source and can be synthesized as ASIC. The design provides a latency of 112.64 ns for one SHA-256 internal hash creation, which is 24.5 times faster (speedup) than the hash creation measured in the BCM2837 ARM-based quad-core architecture. This significant speedup can be achieved when the design works at 294.55 MHz of frequency (see Design 1 in Table 4).

The hardware accelerator design for SHA-256 hash function published in Reference [28] (Design 2) can achieve a significant 112.75 of speedup, which is more significant than the speedup of Design 1. However, this design works at 794 MHz, which cannot be considered an optimal solution for IoT architectures. It is worth noting that if the frequency of Design 1 was the same as Design 2, then its latency would have been only half that of Design 2. We can conclude that Design 1 provides a high enough acceleration (speedup) at an acceptable frequency.

The Design 2 can also accelerate the SHA-512 hash function by achieving a significant 293.18 times speedup against the ARM-based architecture’s execution time (9832 ns). However, a high 756 MHz of frequency is required for such a performance. The design (see Design 3 in Table 3) proposed in this article can provide a less significant speedup than Design 2. However, a speedup of 97.35 can still be considered a high enough speedup at the frequency of 250 MHz, almost three times less than the frequency required by Design 2. As Design 2 requires too significant frequency, its implementation in IoT architecture cannot be considered optimal.

Design 1 implements the Keccak hash function’s acceleration, and it provides a significant speedup of 890 at a relatively high frequency of 485.44 MHz (execution on ARM-based architecture takes 30,768 ns). Another design (see Design 4 in Table 4) found in Reference [43] also provide a significant speedup of 715 but at a lower (284 MHz) frequency than Design 1. Design 4 is chosen for our IoT hardware architecture model, thanks to its high performance at an acceptable frequency.

The latencies of the hash function executed on the ARM-based architecture are all implemented in CryptoPP C++ library. In the following parts of this article, we consider using Design 1 for accelerating the SHA-256 hash function, Design 3 for accelerating the SHA-512 hash function, and Design 4 for the Keccak hash function.

The hardware accelerators identified in the previous section are modeled in SystemC-TLM high-level description language. System-C is an open-source C++ library standardized by IEEE 1666. This tool is usually used in the industrial domain in the early phase development of hardware architectures. The main elements of SystemC are that modules are similar to C++ classes. The modules can be instantiated as objects in C++ language and can contain SC_THREADs or SC_METHODs. The SC_THREADs are executed only one time and can be triggered, thanks to events that are notified according to the logic that the user develops. The SC_METHODS are executed multiple times and triggered when a specific input signal is present. In SystemC, two different time domains are distinguished. The wall clock is the time taken on the host machine while the SystemC simulation is executing. The simulated time is the time viewed by the modules, which is modeled in the design. This also means that timed modeling is possible with SystemC. The time can be modeled by calling the wait() function accepting a femtosecond to second time quantity. In our model, we also used the Transaction Level Modeling (TLM) [18] blocking interface (“b_transport”) to enable communication between the modules. The TLM blocking interface (TLM LT or Loosely-Timed) is not the only one used in TLM; the other is the non-blocking interface (TLM AT or Approximate-Timed), which is more refined and adapted to some specific bus protocols like AXI, for example. This refinement from LT to AT could express the specific out-of-order execution or the sending of data in pipeline before receiving the responses.

QEMU or Quick EMUlator [7] is an open-source CPU architecture emulator including the emulation of peripherals and other components implemented near to the processor. Today, QEMU allows the emulation of more than 200 different architectures such as ARM, SPARK, x86, and many others. The emulation of an architecture (guest machine) is performed by the host machine by running one-by-one on the guest machine’s instructions. The “-icount n” option can set the time taken for emulating one instruction (\(2^{n}\) nanoseconds per instruction).

If we look at Figure 2, then we can see that QEMU emulates the ARM CPU architecture, and the hardware accelerators are modeled in SystemC-TLM. SystemC-TLM and QEMU work on different time environments, making it hard to establish communication between the SystemC-TLM and QEMU instances. These instances must be synchronized to achieve a joint simulation; for this purpose, a virtual platform can be used. We have summarized the different features of the three solutions that exist today in Table 5.

The Hiventive Platform [14] emulates a quad-core ARM Cortex-A53 CPU by a QEMU instance, and the peripherals (UART, etc.) are modeled in SystemC-TLM. This platform allows functional modeling; however, when a SystemC instance applies a wait() function, the QEMU instance cannot handle the synchronization of the wait time between QEMU and the SystemC instances, which makes the overall simulation stall. Because of this issue, this platform cannot provide the time modeling we were expected.

In QBox platform [6, 13, 15], the master is the SystemC kernel, and the QEMU is treated as a SystemC module. This also means that QEMU and SystemC modules are synchronized, thanks to the global quantum. A synchronization must occur after the initiator module local time reaches the multiple of the quantum value. Thanks to this feature, a wait time applied in a SystemC module can wait in the QEMU without stalling the overall simulation. Unfortunately, this platform is not open-source anymore.

SystemC-TLM 2.0 Co-Simulation (Xilinx) [2, 50] is an open-source project in which a Xilinx modified QEMU is the master of the simulation, but thanks to libSystemCTLM-SoC and the Remote-Ports, the QEMU instance can be treated as a SystemC module. The basic idea of this virtual platform is to emulate the Processing System (PS) of Xilinx boards (e.g., Zynq, Versal ACAP) and deploy architectures in the Programmable Logic (PL) by modules written in SystemC-TLM. The SystemC-TLM 2.0 wrapper encapsulates the PL to enable the Remote Port connection with the PS. When memory transactions or wire updates occur in QEMU, the emulator sends timestamps to the SystemC-TLM instance for synchronization. The periodic synchronizations also occur when the global quantum is achieved. This virtual platform allows the complete time modeling when using the icount options at the QEMU side by using the wait() function in SystemC modules. Note that the Xilinx QEMU guide recommends setting the ‘icount’ parameter to 7. According to our experiments, this parameter can significantly increase the boot time of a Linux operating system. When emulating the Zynq-7000 board running a Linux/arm 5.4.0 Kernel with the icount parameter set to 7, the boot time is around 15 minutes. Applying an icount equal to 1, the boot time will result in around 30 seconds.

In our opinion, this platform is the most optimal choice for modeling a high-level IoT architecture, because it enables time modeling, and it is an open-source platform with an active community. In the rest of our work, we consider using this virtual platform.