Table 1. Projects’ statistics.
Table 1 shows statistics for each project made at the lab. These statistics were extracted from the available documentation of each project, usually a thesis document, and by analyzing each project’s code.
For code related metrics, each project’s code was manually divided in three parts: code for smart contracts; code for frontends, that executed on browsers or mobile devices; and backend code, that included web servers and servers to handle events. Other types of code, such as scripts were not considered. These parts were then analyzed with vscode-counter , a tool to count the number of lines of code.
To count the number of smart contracts, frontends and backends required a manual search. In addition, because different technologies have different concepts the following definitions were used to compare projects. 1 smart contract was counted as either 1 Ethereum smart contract, 1 Hyperledger Fabric chain code, 1 Hyperledger Sawtooth transaction processor or 1 DAML Template. The number of frontends was counted as the number of distinct user interfaces. The number of backends was counted as the number of subprojects, not including smart contracts and UIs, that are deployed with the solution and that were developed by the development team.
The values for latency and throughput should be taken with care, most experiments were done in small blockchain networks with about 4 blockchain nodes, with relatively small machines, and without optimizations. This means that those values might not be representative for production networks. Some of these values have question marks (?) meaning that corresponding experiments were not carried out. The value of transaction per second for the ToDoApp has an asterisk, because it used some optimizations (https://sawtooth.hyperledger.org/faq/validator.html ) at the cost of more complexity.
The “Was the DLA module implemented” column talks about a DLA module, it is a module that is intended to ease development by providing a blockchain agnostic API that hides the blockchain being used. In the “Reference Architecture Version” column, 0 means no reference architecture was explicitly used in the project, 1, 2 and 3 refer to version 1, 2 and 3 of the Andes Blockchain Reference Architecture being used.
Table 2. Correlation matrix for projects with prototypes.
Table 2 shows a correlation matrix for the projects. It only includes projects that produced a prototype with blockchain. To be more amenable for analysis, categorical variables with n categories were converted to n – 1 numerical variables with values of either 0 or 1, as recommended in [11]. In particular, the Blockchain variable with values: None, Sawtooth, Fabric, Ethereum and DAML was replaced with binary variables: Blockchain_Fabric, Blockchain_Sawtooth, Blockchain_Ethereum, Blockchain_DAML. Each of which had a 1 if it was of that category or 0 otherwise. In the same manner from the Reference Architecture, Version 2 binary variables were derived: Reference Architecture_v2 and Reference Architecture_v3.