Data redundancy can be measured as the ratio of the total data volume of a ledger system (or say, a database system) to the original file size uploaded to the system (Huang et al., 2015). For example, when a file with an initial data volume (s) is uploaded to a database system, its data volume is increased to a certain size (P) due to the redundant process of the system. The data redundancy (R) can be calculated as R = P/s.

Data redundancy should not be treated as entirely negative and maybe unintentional or intentional. On one hand, unintentional data redundancy occurs owing to inefficient coding or overcomplicated data storing processes (Fan et al., 2018) that increase the size and complexity of the database in terms of data storage, writing, reading, transmission, or processing. Organizations may have to spend extra time and resources to store, process, and maintain such databases (Najafabadi and Azar, 2019). Data redundancy can also lead to data inconsistency, with the same data existing in multiple locations in different formats (Bakr and Lee, 2017). This may result in unreliable or meaningless data.

On the other hand, deliberate data redundancy strategies are often adopted. When data is replicated in multiple places, organizations can benefit from fast access and updates as the data may be available in a closer geographic location (Verma and Singh, 2018). In addition, storing the same data in two or more places can protect an organization from a single point of failure (SPOF) problem caused by events such as cyberattacks or electricity failure (Chervyakov et al., 2019). Organizations can also use data redundancy to check the accuracy and completeness of data by comparison so that relevant parties (e.g., customers, vendors) can have high data reliability (Verma and Singh, 2018).

In general, distributed systems adopt two types of data redundancy: replication and erasure code (Weatherspoon and Kubiatowicz, 2002). In replication, the distributed system replicates each data block into n copies and then distributes them to different network peers (Huang et al., 2015). Even if the n-1 copies are damaged, users can still recover the data. Erasure code transforms a message of k symbols into a longer message (code word) with n symbols such that the original message can be recovered from a subset of the n symbols. Some systems adopt both redundancy schemes simultaneously.

While a database usually organizes data into tables, a blockchain structures data into blocks that are strung together (Beck et al., 2017). Figure 1 shows a typical blockchain. The structure of a block consists of three sections, from top to bottom: block header, block data, and block metadata (Lu et al., 2021b). Block metadata contains the certificate and signature of the block creator. Block data contains a list of transactions arranged in order (Li et al., 2021). A transaction is the smallest unit of a work process involving one or more sequences of actions, e.g., revising, adding, or deleting something in a file (International Organization for Standardization, 2020). The block header comprises three fields written when a block is created (Hyperledger, 2020). The block number is an integer starting at 0 (the first, or genesis, block) and increasing by one for every new block appended to the blockchain. It also includes a hash value of all the transactions contained in the current block. This hash value is unique for each input, so if someone alters the transactions, the corresponding hash value will also change (Wu et al., 2022a). Each block also contains the hash value from the previous block header. Blocks are thereby linked to form an immutable ledger (Perera et al., 2020).

To form a blockchain system, blockchain copies need to be stored by different peers connected in a network, as shown in Figure 2. Blockchain systems may, according to network centralization levels, be public, private, or consortium (Wu et al., 2022a). Specifically, public blockchain is accessible to the public for use, while private blockchain has just one owner organization, and only preauthorized participants can perform particular activities (Lu et al., 2021c). Besides, consortium blockchain operates under a selected set of organizations (Hijazi et al., 2021). A distributed network like blockchain can help to avoid the SPOF problem, where the failure of one component of a system will make the entire system unable to perform its primary functions (International Organization for Standardization, 2020). The SPOF could be caused by electricity failure, Internet connection disruption, cyberattack, bad actors, or force majeure.

Blockchain operation involves several steps, as illustrated in Figure 3. First, a blockchain user proposes a transaction through an application (see Figure 3A). This transaction is then broadcast to the whole network for validation (see Figure 3B). This involves, among other things, checking whether the proposer is appropriate. Upon consensus of the network, validation is achieved, and the hashed transaction is included in a ‘block’, creating a tamper-proof record (see Figure 3C) (Lu et al., 2021b). Next, the block is sent to peers in the network (see Figure 3D) so that they can approve the order and correctness of the block (see Figure 3E). After that, the blockchain is updated with the new block (see Figure 3F), and in this way, the whole distributed peer network has its up-to-date copy of the blockchain (see Figure 3G). Finally, the operation is concluded, and the completion notification is sent to the network (see Figure 3H).

Several factors can influence the data redundancy of blockchain. Firstly, file size plays a crucial role as larger files can impact storage and retrieval efficiency (Xue and Lu, 2020). Secondly, the number of peers and organizations involved in the blockchain network can affect data redundancy. More peers and organizations can enhance data availability and collaboration but may also increase network traffic (Tao et al., 2021). Additionally, block size, which determines the number of transactions included in a block, can impact data redundancy (Perera et al., 2020). A larger block size allows more transactions but can slow down the network. Lastly, the operation frequency of transactions in a project can influence data redundancy. Higher transaction frequency can increase network traffic and reduce performance but may improve data transparency and collaboration (Zhong et al., 2023). These factors must be carefully considered to optimize data redundancy and ensure efficient operations within the blockchain networks.

There are potential tools can address data redundancy in blockchain networks. One such tool is InterPlanetary File System (IPFS) (Tao et al., 2021), which enables decentralized storage and distribution of large files associated with blockchain transactions. IPFS reduces data redundancy by eliminating the need for centralized storage infrastructure and improving data availability. Another tool is Distributed Hash Tables (DHT), which stores and retrieves data in a peer-to-peer network (Byers et al., 2003), distributing blockchain data across multiple nodes to enhance availability and reduce redundancy. Data compression techniques can also be employed to reduce the size of data (Jayasankar et al., 2021), reducing data redundancy and improving storage efficiency for blockchain. This can help optimize the use of storage resources and improve the overall performance of the blockchain network.

In construction, the blockchain literature has grown dramatically in the past few years. Blockchain was first discussed in the context of Building Information Modelling (BIM) (Turk and Klinc, 2017) and smart cities (Coyne and Onabolu, 2017). Researchers have since provided sketches of potential use cases for blockchain in construction. For example, Das et al. (2021) point out the promise of blockchain as a complementary technology to BIM and the Internet of Things (IoT), which are constrained by trust and liability issues. Ye et al. (2018) propose the use of blockchain to store IoT-generated data in a transparent and secure environment and BIM as a tool for digitally processing construction project data. In a 2018 report, meanwhile, ICE comprehensively envisions the applications of blockchain in construction (Penzes et al., 2018).

The construction industry has become increasingly interested in blockchain technology (Xu et al., 2023). It is exciting to observe in construction the emergence of diverse and innovative blockchain applications, e.g., in operation management (Ye et al., 2018), decentralized organizations (Perera et al., 2020), smart cities (Chen et al., 2020), trust-building in the supply chain (Qian and Papadonikolaki, 2021), construction supply chain traceability (Lu et al., 2021a), procurement (Tezel et al., 2021), secure BIM and blockchain-based collaborative design (Tao et al., 2021), carbon footprint (Rodrigo et al., 2021), privacy protection of modular housing production (Li et al., 2021), and confidentiality-minded design in digital collaborative environments (Tao et al., 2022). Other applications include supervision of offsite modular housing production (Wu et al., 2022a), accurate information sharing (Wu et al., 2022b), decentralized tendering (Ahmadisheykhsarmast et al., 2023), combined applications with internet of things (IoT), BIM, and edge computing (Zhong et al., 2023), on-site activity management (Wu et al., 2023), collaboration for fit-out operations (Jiang et al., 2023), and among many others. These studies are of great significance to blockchain research in the construction industry.

However, little research, if any, has considered the data redundancy of blockchain systems in construction. Blockchain systems are not cost-free. They involve capital investment, e.g., to develop the system, and operational cost, e.g., to maintain and upgrade it. Servers and storage are hosted by different project stakeholders and then dissolved when a project is completed, and this contributes a significant portion of the overall blockchain cost. Understanding the level of data redundancy in a blockchain, therefore, is a research topic that is of both academic and practical value.

Three types of blockchain are available: public, private, and consortium (Perera et al., 2020). In a public blockchain, control is distributed among members of the public that join in its operation. Many cryptocurrencies (e.g., Bitcoin) use this type of blockchain. Private blockchain has just one owner organization, and only preauthorized peers can perform certain activities (International Organization for Standardization, 2020). Due to this restrictive nature, private blockchain tends to have better privacy and efficiency than public blockchain (Lu et al., 2021b). However, this controlled environment may reduce transparency and resistance to hackers (Perera et al., 2020). Consortium blockchain operates under a selected set of organizations, and only preauthorized peers are allowed to conduct certain activities (Du et al., 2020). It has many of the advantages of the private blockchain while reducing the counterparty risk of private blockchain because it has more than one organization to manage the network.

There are different blockchain platforms based on which different blockchain systems can be developed. Lu et al. (2021c) compare the main blockchain platforms Bitcoin, Ethereum, Hyperledger Fabric, and R3 Corda in terms of their focus domain. Hyperledger Fabric is a generic, open-source platform for any industry (Perera et al., 2020) that can be used to develop both private and consortium blockchain systems, and that allows for transaction data to be accessed only by permissioned persons. Therefore, Hyperledger Fabric is attractive to construction organizations (Nawari and Ravindran, 2019).

We build a blockchain system based on Hyperledger Fabric as the testbed to test the hypotheses in five controlled experiments that involve changing file size, numbers of peers organized in a local area network (LAN), numbers of construction organizations, block size, and operation frequency. We organize the peers in a physical server only. In real-life blockchain systems, such peers are normally dispersed in different servers, and in different construction organizations. Each peer is initiated as a Docker container and then connected to the Fabric network using Docker Swarm. Docker swarm is a container orchestration tool, meaning that it allows the user to manage multiple containers deployed across multiple host machines. The “Proof of Stakeholder” consensus mechanism is adopted, which means the monotone logical expression ‘AND’ is used to specify that every endorsement peer from a construction organization is required to endorse transactions via the decentralized network. All the containers corresponding to each peer are run on the server. The physical server has 16 central processing units (CPUs) (Intel Xeon Silver 4110 @ 2.10 GHz) with 32GB RAM. The experiments are run on Ubuntu 20.10 long-term support (LTS) with the installed Hyperledger Fabric (version 1.4.2).

Step 1:

In the experiments, we assume that a participant is asked to submit a file to the blockchain system as a typical blockchain operation in a construction project. Table 1 summarizes the test construction files used in this study. We select four types (i.e., gif, docx, jpg, pdf), each with 10 different sizes, as it is unclear whether different construction file types have different effects on file redundancy in a blockchain system. File content could include progress payment transactions, construction legal contracts, inspection records, design ideas, or any meaningful construction information. The files are read into the network using the Base64 algorithm (Rahim et al., 2018). The default block interval, i.e., the amount of time that has elapsed since the last block (Hyperledger, 2020), is controlled as constant (1 s) in the experiments. In addition, with the exception of Experiment 4, a default block size of 98 MB is adopted. In each experiment described below, the data volume of the blockchain system is recorded by the research team after the completion of each operation.

Step 2:

Hypothesis H1 is tested by Experiment 1, which aims to understand data redundancy in a blockchain system by examining whether the total data volume of a blockchain system is proportionally correlated with the size of the original uploaded construction file. In this experiment, each test file is uploaded to the blockchain system 10 times for endorsement. During this process, the number of endorsement peers is controlled at 7, and all are under the same project-based construction organization.

Step 3:

Hypothesis H2 is tested by Experiment 2, which aims to understand data redundancy by measuring the impact of the number of peers on the overall data volume of the blockchain system. In this experiment, each test file is uploaded to the blockchain system 10 times for endorsement. The number of endorsement peers, all under the same organization, is adjusted from 1 to 10 correspondingly.

Step 4:

Hypothesis H3 is tested by Experiment 3, which aims to understand data redundancy by investigating the impact of the number of construction organizations on the overall data volume of the blockchain system. In this experiment, each test file is uploaded to the blockchain network 10 times for endorsement. During this process, the number of peers is controlled at 10. The number of construction organizations is adjusted from 1 to 10, therefore each construction organization contains 10 to one peer(s), respectively.

Step 5:

Hypothesis H4 is tested by Experiment 4, which aims to understand data redundancy by investigating the relationship between the overall data volume of a blockchain system and the block size. In this experiment, each test file is uploaded to the blockchain system 10 times for endorsement. During this process, the number of endorsement peers is controlled at 10, and all under the same organization. The block size is adjusted in 2 MB increments from four to 22 MB.

Step 6:

Hypothesis H5 is tested by Experiment 5, which aims to understand data redundancy by investigating the relationship between the overall data volume of a blockchain system and the operation frequency (file uploads). In this experiment, each test file is uploaded to the system 100 times for endorsement. During this process, the number of peers is controlled at 10 and peers are under the same organization.

The results of testing these five hypotheses are presented in Sections 5.1.1 to 5.1.5 accordingly. Section 5.2 then presents the data redundancy model of the Hyperledger Fabric in construction projects. Lastly, the model validation results are given in Section 5.3.

The data volume added to a blockchain system due to a construction transaction (e.g., file upload) is determined by four parts (Parts I to IV), as shown in Figure 10. Based on Experiment 1, it is found that the Part I (Value) contained in the proposal is directly affected by the original construction file size (s). Since we used the Base64 algorithm to read the test construction files during the experiments, Eq. 1 can then be used to calculate Part I (P _I ). P I = ⌈ s 3 ⌉ i n t e g e r × 4 . (1)

In the Fabric blockchain network, Part II (Response) contained in a transaction is similar in size to the original construction file (s). Thus, the response (P _II ) size due to a transaction can be obtained by using Formula Eq. 2 presented below. Based on Experiment 2, we discover that every time a new endorsement peer is added, an extra 1003-byte endorsement is added to the data volume of an endorsement peer, on average, when a transaction is executed. Therefore, Part III (endorsements, [P _III ]) included in a transaction can be calculated based on the number of endorsement peers configured in the network (n) from Formula Eq. 3. P I I = s (2) P I I I = 1003 × n . (3)

Part IV consists of nine sub-parts: the function (Part IV-1, [P _Iv-1 ]), chaincode_ID (Part IV-2, [P _Iv-2 ]), and key (Part IV-3, [P _Iv-3 ]) included in a proposal; the header (Part IV-4, [P _Iv-4 ]) and signature (Part IV-5, [P _Iv-5 ]) contained in a transaction; and the block number (Part IV-6, [P _Iv-6 ]), hash of current block transaction (Part IV-7, [P _Iv-7 ]), copy of hash from previous block (Part IV-8), [P _Iv-8 ]), and metadata (Part IV-9, [P _Iv-9 ]) produced from block ordering. According to Experiments 4 and 5, the data volume of these nine sub-parts is relatively constant. Therefore, the size of Part IV (P_IV) can be calculated by adding the data volume occupied by these nine sub-parts using Formula Eq. 4. P I V = P I V − 1 + P I V − 2 + P I V − 3 + P I V − 4 + P I V − 5 + P I V − 6 + P I V − 7 + P I V − 8 + P I V − 9 ≈ 3434 . (4)

The total data volume (P_Total) added to the blockchain system with n number of peers due to a transaction is P T o t a l = P I + P I I + P I I I + P I V × n (5a)

By substituting formulas Eqs 1–4 into Eq. 5a, we obtain Eq. 5b P T o t a l = ⌈ s 3 ⌉ i n t e g e r × 4 + s + 1003 × n + 3434 × n . (5b)

If the same transaction repeated f times, then the total data volume is P T o t a l = ⌈ s 3 ⌉ i n t e g e r × 4 + s + 1003 × n + 3434 × n × f (6)

If we have multiple transactions with different sizes o _1, o ₂…o _n, repeated f _1, f ₂…f _n times correspondingly, then the total data volume is (see Eq. 7) P T o t a l = ⌈ s 1 3 ⌉ i n t e g e r × 4 + s 1 + 1003 × n + 3434 × n × f 1 + ⌈ s 2 3 ⌉ i n t e g e r × 4 + s 2 + 1003 × n + 3434 × n × f 2 + … + ⌈ s n 3 ⌉ i n t e g e r × 4 + s n + 1003 × n + 3434 × n × f n (7)

One can convert the unit from bytes to KBs by using Formula Eq. 8 P T o t a l   Bytes = P T o t a l × 0.00097656   KBs (8)

The data redundancy (R) brought by multiple transactions can be calculated from R = P T o t a l s 1 × f 1 + s 2 × f 2 + … s n × f n (9)

In this section, we perform experimental measurements to verify the correctness of our data redundancy model. When corresponding variables (g = 1, f = 10, b = 98 MBs, s = 9.7 KBs [test.gif], or 48.9 KBs [test.docx], or 394.6 KBs [test.jpg], or 1,567 KBs [test.pdf]) are under control, Eqs 6, 9 are used to determine the predicted data redundancy (R _pre ) of each test file. This is compared with the corresponding actual data redundancy (R _act ) obtained from Experiment 2 (see Table 3). Figure 11A shows that the predicted data redundancy is within one percent of the actual data redundancy error range, which indicates that the model has high accuracy. For the other three test files, the same conclusion can be drawn (see Figures 11B–D).

In summary, the predicted and actual data redundancy match well in the four types of test files. We take the data in Figure 10 as inputs and exhibit the accuracy θ in Table 7. We calculate and define the accuracy percentage as θ = R A c t   / R P r e × 100 % . As Table 7 shows, our model predicts data redundancy with an accuracy of 99.92% and higher for Test. gif files; 99.99% and above for Test. docx files; 100% for Test. jpg files, and 100% for Test. pdf files.