Leveraging Blockchain for Scaffolding Work Management in Construction

As a temporary facility, scaffolding has an essential role in providing a work environment at height in the construction industry. According to the Occupational Safety and Health Administration (OSHA), approximately 65% of laborers work on scaffolding. Scaffolding work information needs to be effectively managed with reliability to provide a safe environment. However, managing information of the scaffolding work process remains challenging in forgery risk and manual verification. Blockchain has been widely introduced as an accountable and efficient information management solution. This study presents a blockchain-based system for scaffolding work to grant reliability and efficiency of information management. The system is developed to secure applicability by considering three aspects: (1) optimal blockchain platform regarding characteristics of scaffolding work; (2) storage method to address the hindrance of blockchain; (3) information needed to be compared for verifying adequacy. The detailed configuration and process model for the system is categorically presented, and validated via a case study. The case study confirmed that the system was able to store the information in the block smoothly, verify the information using the smart contract successfully, and remain the block size constant by using off-chain. The proposed system has the potential of practical applicability and could contribute to mitigate potential safety risks associated with inadequate scaffolding work management. Furthermore, the proposed system development flow can be leveraged as a guideline to extend blockchain applications to diverse areas in the construction domain.


I. INTRODUCTION
Scaffolding refers to an essential and temporary structure, that is used to elevate and support workers during construction. Statistics from the Occupational Safety and Health Administration revealed that 65% of construction laborers work on scaffolding [1], [2], [3]. However, the ineffective management of scaffolding annually causes approximately 60 deaths, 4,500 injuries, and USD 90 million worth of damage [1]. In South Korea, 488 deaths have occurred from scaffolding over the past five years, accounting for approximately 23% of the total number of deaths [4]. According to the results from a recent on-site inspection by the Korea Occupational Safety and Health Administration, cases concerning a lack of guardrails and planks in the scaffolding account for approximately 83% of the total [5]. In particular, small-size projects have a short construction period, which causes work to be carried out or dismantled in dangerous environments where external scaffolding is not properly installed. In common practice, architectural and bid drawings do not incorporate temporary facilities, and temporary facilities are often installed at construction sites when needed but without sufficient planning effort [3]. Such problems can be attributed to failures in scaffolding management (e.g., planning mistakes, poor scheduling, and controls) [6]. For better management, information related to scaffolding work, a work package, must be managed effectively throughout its life cycle: planning, quantity take-off, ordering, installing, and dismantling. For this, improved methods and tools for managing the scaffolding work information are required to enhance scaffolding safety and prevent accidents.
Several previous researchers and companies have noted that the above problems can be addressed via information management and design tools [2], [3], [7], such as project management information system (PMIS) and Design for Safety tools. With the aid of tools in conjunction with ordering and procurement systems, stakeholders can seamlessly share scaffolding work-related information. However, owing to the fragmented cultures in the construction industry, wherein several stakeholders with misaligned interests participate in a project [8], [9], there are coordination challenges such as a lack of trust, poor information exchange, and supply chain fragmentation [9]. Stakeholders are often reluctant to use a centralized system (i.e., PMIS and design tools on the cloud system) attributed to a specific participant. This leads to the information regarding the various stages (order-procurementinstallation) of scaffolding work becoming fragmented and disconnected resulting in document-based management. The inspector must manually check that the correct information is created, stored, and shared within the documents. Such information managed with documents is vulnerable to potential forgery risks [10], [11]. In the case of South Korea, attempts have been made to manipulate scaffolding installation information and document in order to evade accountability and hide the inadequacy of rule compliance [12], and other document information is often found to be falsified [13]. These documents are insufficient evidence to determine whether the scaffolding work is executed to secure the safe work environment unless the inspector visits the site before dismantling. Therefore, the scaffolding work-related information must be managed with reliability to create a safe environment effectively.
Blockchain technology, as represented by a distributed and decentralized ledger technology [6], has been widely investigated and used to enhance the reliability of construction data [15], [16], [17]. It enhances reliability through information immutability, forms trust protocols between participants, and opens the door for automated contract execution and datadriven decisions through smart contracts [18]. Blockchain has shown great potential for resolving information disconnections, enhancing reliability, and ensuring more efficient data verification of purchase orders, procurements, and installation information. Despite its promising potential, previous blockchain research has only suggested a conceptual framework, with limited case projects in the supply chain management area. There is a lack of blockchain application cases customized for specific construction work packages, as these may require specific domain knowledge (e.g., unique work process and information flow in the scaffolding work). Moreover, because scaffolding represents a temporary facility, photographs play a major role in verifying that the scaffolding has been installed as planned (i.e., on time, in place with the correct quantities). However, blockchain is not designed for large-size data sharing [19]; thus, photographs may not be stored and shared among blockchain systems [20]. Therefore, there is a growing need for an advanced blockchain system enabled to store and share scaffolding work-related information without concerns regarding the data file size.
This study proposes a blockchain-based system for managing information of scaffolding work with reliability and efficiency. The objective of the system is to verify the adequacy of information for securing a safe environment through smart contracts, and resolve the data storage problem for the application of the real world. The smart contracts in blockchain can logically determine whether the information is falsely entered by comparing the information entered during the scaffolding process with the metadata of the photographs, thereby providing efficiency and reliability. In addition, the proposed system can induce the use of the system by scaffolding work stakeholders due to its applicability. Consequently, represented as document-oriented and manual inspections, current information management methods can be improved through the proposed system, and further, potential safety risks can be prevented by securing a safe environment.
Extended from the preliminary version of research [21], this study presents essential directions for researching blockchain applications in various fields of the construction industry by seeking solutions to the barriers of applying blockchain and proposing methods for applying these solutions to specific processes.

A. CURRENT SCAFFOLDING WORK PROCESS
In South Korea, most scaffolding work materials are procured by separate suppliers, and orders and installations are carried out by a general contractor (GC) or subcontractor (SC) with a construction license. This process can be divided into three stages: material order, material procurement, and installation ( Fig. 1). The details are as follows.
1) The GC/SC calculates the quantity of scaffolding required to be installed during the process, based on drawings and quantity calculations generated in the scaffolding work planning stages. 2) A purchase order is prepared based on the calculated quantity. The information in the purchase order includes the contractor's name, site name (location), order time, and drawings, in addition to the quantity information. 3) Based on the purchase order, the material supplier (supplier) procures the scaffolding work materials to the site, and issues a statement after the procurement is completed. The statement contains information, including the site name (location), volume, and procurement date. 4) The GC/SC then proceeds with the installation of the procured scaffolding materials. After the construction proceeds, a photograph is captured and stored in the form of a document. The information includes the installation location, installation date, and photographs. In the case of photographs, because these constitute direct evidence of the scaffolding installation, largecapacity data are generated to identify the installation status of each part or the whole structure. The purchase order, statement, and photograph ledger are the results of the information created in this process. These are reviewed by the owner, inspector, and third-party public agency to ascertain whether an appropriate quantity of scaffolding has been installed at the corresponding site at a proper time during the evaluation of progress payment or safety inspection. However, the orders, statements, and photograph ledgers are disconnected information existing in the form of documents. This results in a problem wherein the owner, inspector, and public agency have to compare the site information, dates, times, and quantities contained in these documents one by one to determine the authenticity and appropriateness of the submitted information. Moreover, the information generated in the form of a document has a modulation (alteration) risk [10], [11]. For example, the quantity information may be modulated to reduce costs by saving certain materials to claim excessive progress payments. There is also a risk of modulation of the location and time information of the statement or photograph ledger to circumvent responsibility for accidents that may occur due to inadequate scaffolding installation. Therefore, to effectively manage scaffolding work, it is necessary to secure the reliability of the information and automatically determine the authenticity and adequacy of the data in the document.

B. BLOCKCHAIN TECHNOLOGY FOR RELIABLE DATA TRANSACTION AND VERIFICATION
Blockchain is a distributed ledger technology. It groups the information created by users into blocks, connects them in the form of a chain, and stores the information in a distributed ledger [18]. It can secure the reliability of the information and induce trust in the system through its characteristics such as immutability, non-repudiation, integrity, transparency, and equal rights [22]. In addition, a smart contract, i.e., a computerized protocol implemented through code running on the blockchain, enables the automation of business processes and workflows [23]. This is likely to improve efficiency [14], [17], [19], [24]. Based on these advantages, research has been actively conducted on applying blockchain across various fields of the construction industry. Giuda et al. contended that the gradual introduction of building information modeling (BIM) based on blockchain technology could provide infrastructure for reliable information management at the design, bidding, and construction stages and improve the existing information verification process by storing information in the blockchain, thereby ensuring reliability, transparency, and traceability [15]. Xue and Lu attempted to improve the work process (e.g., information sharing and variation tracking at the installation stage) by storing the variations in the BIM model in a blockchain system to ensure reliability. In addition, they recommended a method for storing only the variations in the BIM model (rather than the entire file) to reduce the size of the stored data [16]. Li et al. performed a study on the procurement management of selfassembly building materials using blockchain and Internet of Things (IoT) technologies, aiming to comprehend the assembly status using BIM and secure reliability by storing related information in a blockchain system [17].
Luo et al. proposed a blockchain-based smart contract framework with sequential approval process requirements for established payments [25]. Ahmadisheykhsarmast and Sonmez proposed an Ethereum blockchain-based payment security system to reduce fees and secure information reliability through peer-to-peer transactions [23]. Hamledari and Fischer conducted a study on construction-progress monitoring by using robotic reality capture technology to automate established payments and smart contracts, via connection to an Ethereum-based platform [26].
Furthermore, Lanko et al. proposed a supply chain management process using blockchain and radio frequency identification technologies for strengthening supply chain management [27]. They also conducted a case study on the manufacturing and delivery processes of ready-mixed concrete, aiming to study the necessity of applying blockchain technology and its limitations. Wang et al. contended that the real-time information communication between construction participants could be improved through a blockchain-based material information management model, and that efficiency could be improved by utilizing smart contracts [28]. Singh presented a framework for gathering real-time supply chain information via IoT technology, and for ensuring reliability by blockchaining [29].
These studies were conducted with the purpose of applying the characteristics of blockchain for securing information reliability and for streamlining information management using smart contracts in various fields of the construction industry, such as in-progress payment, supply chain management, and process management. However, most studies have focused on applying blockchain as a means of storing the information generated in existing processes with attaching other technologies, such as IoT sensors, BIM, and reality capture. These are effective methods for the main objects (e.g., concrete and steel structure, and the prefabricated elements) of the construction project but not for scaffolding as a temporary facility. For the temporary facilities, photography plays a major role in ensuring whether the materials are actually installed on the date listed on the site. Moreover, previous studies adopt the blockchain as the database without concerning the methodologies for selecting the type of blockchain systemically or technical details. A few studies suggest the blockchain system with analyzing the current process of construction projects and concerning blockchain platforms [30], but there is a lack of a detailed method to overcome the hindrance of blockchain. Certain studies have recommended methods for reducing the size of the data stored in the blockchain [16], [31], and suggest the usage off-chain or sidechain methods for storing large-capacity data [26], [32], but also there is lack of detailed information for using the offchain database. Those previous studies are comprehensive approaches and only applicable as alternatives in a limited number of cases and have not completely solved the limitations of the blockchain mechanism, which fundamentally distributes and stores the data. Therefore, to introduce blockchain into real-world scaffolding work and to use it to secure data reliability (e.g., resolving forgery problems and sharing traceable information) and verify its adequacy, there is a need for a storage mechanism that fundamentally solves the blockchain's limited-data-storage problem. In particular, to implement smart contracts (which play a key role in inadequacy verification), specific blockchain network configurations and system frameworks should be designed according to the characteristics of the scaffolding work. Accordingly, this study develops a new blockchain system to solve the above problem with a data storage mechanism, thereby addressing a fundamental limitation of the blockchain. In addition, the study verifies that the blockchain is a remarkable solution for securing data reliability and verifying the adequacy of scaffolding work through a case study.

A. RESEARCH METHOD
This study proposes a realistic system suitable for scaffolding work with overcoming the hindrance of leveraging blockchain to secure a safe work environment. The specific steps are as follows.
1) The best platform is selected by comprehensively considering the advantages, disadvantages, and characteristics of the various forms and types of blockchain platforms. Existing studies related to blockchain platform selection are examined to select the optimal blockchain platform while considering the method and characteristics of the data exchange and comparative verification required for scaffolding work management in Section III-B.
2) The properties of information are defined based on the information to be exchanged among the participants in the current scaffolding work process described in Section II. A method for storing large-capacity data while overcoming the hindrance of blockchain is proposed in Section III-C.
3) The correlations of information generated during the scaffolding work process are analyzed to define the target information for the smart contracts, which determines the adequacy of the input information by comparative verification in III-D. Also, the authors define the stage of scaffolding work that is needed to be compared with other stages. 4) In Section IV, regarding those aspects, the authors propose the system framework, network configuration, and pseudocodes into a system operable in the real world. Transaction flow, storing information, and verification process in the blockchain system are also described. 5) In Section VI, the author presents the codes, which are for hash verification described in Section III-C, extraction of metadata to meet predefined key information in Section III-D, and verification process described in Section IV. The system is developed based on the proposed configurations in Section V. In addition, implemented system is applied to a case study, and validation is conducted.

B. BLOCKCHAIN PLATFORM SELECTION
Blockchain can be categorized into the following types depending on the type of node participating in the network and consensus process: public blockchain, private blockchain, and federated blockchain (which can be considered as a type of private blockchain) [33]. A public blockchain allows all entities to join the network, create transactions, and participate in the consensus process without requiring permission, thereby enabling complete decentralization without a specific entity managing the network and ensuring anonymity. However, most representative public blockchain platforms, such as Bitcoin and Ethereum, use the Proof of Work (POW) consensus algorithm. Because this consensus algorithm involves a verification process for all nodes (full nodes), the more users there are, the slower the system, and the higher the computing power required [34]. Moreover, significant time is required to verify the block, as all variations must be recorded in the connected blocks [35].
Meanwhile, a private blockchain is a form in which only authorized users can participate. It is also called a federated blockchain when subjects with an identical purpose are gathered to configure it [36]. Hunhevicz and Hall classified private blockchains according to the presence of a specific institution or individual authorized for adjusting the platform, e.g., a private permissioned blockchain platform or a private permissionless blockchain platform [8]. In a private blockchain, only authorized and limited nodes or groups can generate transactions and participate in the consensus process, thereby enabling node identification and the utilization of algorithms other than the POW. As a result, according to the increase in the nodes, the system's throughput can be maintained at a higher rate than that of the public blockchain, resulting in high scalability. Scalability is a representative hindrance to blockchain applications in addition to the storage problem [19], and it is conjectured that the higher the throughput and lower the latency, the higher the scalability [37], [38]. High scalability implies that there is available scope for scaling the system, i.e., according to an increase in the number of users or data exchange capacity of the blockchain, or the number of data exchanges. Furthermore, only authorized users can view the information, providing an advantage in terms of data privacy [24]. However, because only authorized users can participate in the consensus process, a completely decentralized network is infeasible [33], and the risk of forgery may be higher than that of the public blockchain [36].
To select a suitable platform for scaffolding work among these blockchain types, this study refers to studies on the selection of blockchain platforms by Hunhevicz and Hall [8], Peck [9], and Li et al. [14]. Based on this, the main factors influencing the platform selection were classified into necessity, trustability among participants, anonymity, data privacy, and authority items. The details regarding the decision-making, considering the characteristics of scaffolding work, are shown in Table I.
Blockchain utilizes a distributed ledger technology that can solve reliability problems regarding information and provide decentralized management with fewer errors and corruption than those seen in current systems and introduce more flexible and transparent democratic processes [14]. Thus, it can solve the problems regarding disconnected and falsifiable information caused by reliability issues in the information, as mentioned in Section II. Thereby, the trustability problems between participants (GCs/SCs, suppliers, and owners/inspectors) owing to conflicting interests can be solved, and system usage can be induced. This will enable more efficient management. In contrast, when participants of the scaffolding work generate information anonymously, it may be infeasible to identify the participant responsible for generating an item of information.

Types Questions Remarks Description
Necessity -Can a conventional database technology satisfy your requirement? [9] -Would a conventional database satisfy your requirements? [14] N • A conventional database cannot provide trustability for the system because of information reliability. This hinders information integration.
-Are there multiple writers? [8] -Should more than one participant be able to update the data? [9] Y •At least two participants (general contractor (GC)/subcontractor (SC) and supplier) should update the information regarding scaffolding works.
-Do you require high-performance, rapid (~millisecond) transactions? [14] - •Controlling information regarding scaffolding need not involve excessively rapid transactions. However, an appropriate level of transaction speed should be ensured to secure system usability and prevent claims owing to the finality of blocks.
Trustability -Can you use an always online TTP(trusted third-party)?
[8] -Do you and all those updaters trust one another? [9] N •Participants in scaffolding works may not trust each other because their interests are not aligned.
Anonymity -Are all the participants known? [8] Y •All the participants should know each other to interact and communicate. • Anonymity is not necessary to clarify responsibility.
Data Privacy -Is public verifiability required/demanded? [8] N •Information regarding scaffolding work, such as drawings, ordered quantity, and time, can be a competence of the contractor. •Competence data should be maintained private.
-Is the data maintained private? [9] Y Authority -Do you need to control who can modify the blockchain software? [9] -Control functionality at the protocol level? [8] Y •Under the present management system, scaffolding workprocurement information is reviewed by a third-party such as a public agency. •Moreover, there is a risk of collusion if the participants have the right to endorse and create blocks. •The third party must have system-control authority. Moreover, GCs/SCs, suppliers, and owners/inspectors can clearly specify the other party by contract. Hence, anonymity (one of the characteristics of a public blockchain) is considered unnecessary. Regarding data privacy, the drawings, ordering time, and supplies related to scaffolding work are regarded as the private information of the project participants. Furthermore, the corresponding information is generally not disclosed to third parties unrelated to the project. Therefore, a blockchain suitable for scaffolding work should be in the form of a private blockchain to permit network participants to specify each other without anonymity, and establish access rights to the information contained in the block. However, the private blockchain has a problem; the risk of collision is higher than that for public blockchain, because the number of nodes participating in the consensus process is relatively small [39]. Furthermore, as described above, because each entity participating in the scaffolding work clearly knows each other's identity, delegating the authority to create blocks solely to the participants in the scaffolding work can pose a risk of information modulation by collusion. Therefore, a third party that is not a participant of the project but uses related information to determine the adequacy of the scaffolding work and is trusted by all the project participants should be given the authority to coordinate the platform by participating in the blockchain network. Public agencies not directly participating in the project in the current scaffolding work process but with authority to view information are evidently suitable as third parties (Fig. 1).
Based on these aspects, a decision-making process for selecting the platform type was conducted as shown in Fig. 2. The necessity for the blockchain is determined as required, and trustability needs to be secured because there is an absence of trust among participants. Furthermore, owing to the characteristics of the scaffolding work, it is concluded that anonymity is not required, whereas data privacy and authority for the third-party verification are required. Therefore, a private permissioned blockchain platform is considered suitable for scaffolding work.
In general, the Hyperledger Fabric (HLF) and R3 Corda are classified as private permissioned blockchains [8]. Of these, the HLF has the lowest latency and highest throughput [38] and, therefore, the highest scalability. It does not require a high processing speed (in milliseconds) for the information generated in the scaffolding work process to be verified. However, when multiple nodes enter information simultaneously, the farther the time to finality for the generated blocks to be shared in the distributed ledger and for their authenticity to be determined, the weaker the immutability of the information in the blockchain, leading to reliability problems. In addition, the finality delay and slow processing are factors that reduce the competitiveness of blockchain-based systems [40]. Therefore, the HLF is selected as the platform for developing the system proposed in this study.

C. HYBRID ON-CHAIN AND OFF-CHAIN MODEL TO ADDRESS STORAGE ISSUE IN BLOCKCHAIN
The types of information generated in the process of scaffolding procurement and installation, as mentioned in Section II, include string, int, datetime, drawings, and photographs (Table II). Most of the information generated by GCs/SCs and material suppliers consists of low-capacity information, such as strings or ints. However, drawings and photographs have a relatively large capacity (> 1 MB).
In the case of Bitcoins, the block size is limited to 1 MB [41]. Meanwhile, the average block size in the case of Ethereum, which has variability in its block size, is approximately 87 KB at present [42]. The HLF can increase the size of the block to 99 MB. However, this can cause problems, such as a need for increased computing resources and time to create the block, lower propagation speed, larger time-to-finality of the block, and also increased maintenance costs for the chain [43], [44]. In addition, the system's latency may increase [40]; this can negatively affect the system's scalability. Blockchain is not suitable for storing largecapacity data, because it holds a full copy of the recorded information in multiple nodes. As a solution, large-capacity data must be stored off-chain in a separate database [45]. Therefore, this study adapts a method wherein the drawings and photographic data are not stored in the blockchain, but in an off-chain database, i.e., by creating a hash and storing it in the blockchain to secure the reliability of the original data stored in the off-chain. A hash refers to a unique key that maps to specific data using an encryption hash algorithm. It can verify the authenticity of data by examining whether the data are mapped to a given hash value in the blockchain. It is feasible to verify the accuracy and validity of the data by assessing whether the hash calculated from the original data matches that stored in the blockchain [46]. This study applies the SHA-256 hash algorithm, which returns drawing and photographic data as a string value of 256 bits (64hex). The verification process using the SHA-256 algorithm is presented in Fig. 3. When a system user uploads drawings and photographic data (Data version 0, Dv0) to the system, a hash (hash version 0, Hv0) is assigned using the SHA-256 algorithm and stored in a blockchain, and the raw photographs and drawing data are stored in an off-chain database. After that, when the user reads the data, the original data (Data version 1, Dv1) in the off-chain database estimated to be Dv0 are loaded, and the hash (Hash version 1, Hv1) is returned using the SHA-256 algorithm, so as to verify whether it matches Hv0. The verification results provided to the user may determine whether Hv0 and Hv1 match, that is, whether the original data stored in the off-chain has been modulated.
Simultaneously, the time, location, and photographer information included in the photographic data in Table II are stored in the blockchain through a separate extraction process. This is because the time and location are included in the information to be verified in the current scaffolding work material order-procurement-installation process will be present in Section III-D. Photographer information is needed to be re-verified and to be clarified separately from the system's access authority. In particular, the photographer's information can be used to ascertain whether the information uploaded by an official of the stakeholders participating in the related construction project is correct. Accordingly, when the order and procurement information is stored in the blockchain, the appropriateness of the information can be determined via comparing the metadata of the photograph.

D. INFORMATION FOR COMPARATIVE VERIFICATION
To determine the adequacy of the information managed in the blockchain system proposed herein, the information in Table  II is input to the system by order, procurement, and installation stages and was subject to the data comparison process, as shown in Fig. 4. Among the corresponding data, the information on the total quantity, order and procurement quantity, and order and procurement date is used to determine the adequacy by examining whether the required quantity of scaffolding is ordered and procured for each period. The relationship between the quantity and time is verified at the stages of the ordering and procurement of the scaffolding work materials. Furthermore, at the procurement and installation stages, the relationship with time at each stage is verified.   Moreover, the GPS and photographer information from the metadata of the photograph uploaded during the installation stage is used to verify that the uploaded photograph is captured at the corresponding site. This verification is done by examining whether it matches the location data in the project information.
However, in the HLF, only authorized users have the right to participate in the network. Furthermore, only users of the participants involved in the project should have the right to read/write data to solve the data privacy problem. Because information related to ordering and procurement could only be viewed by users related to the project, it is conjectured that the on-site location information would be similar at the stages of order and procurement. Hence, it is not considered as a comparison target for determining information adequacy. Similarly, because users of the system can specify each other without anonymity, the names of the other parties to the contract are not considered as comparison targets.

IV. SYSTEM CONFIGURATION AND CONCEPT MODEL
As described above, in this study, the HLF is used to implement a blockchain system, and drawings and photographic data were stored by configuring an off-chain. In addition, the information compared in the ordering, procurement, and installation stages is limited to the quantity, time, and location information. This section presents the system framework, architectures, and pseudocodes, including role definitions for each system user and project participant.

A. SYSTEM FRAMEWORK
The system nodes consist of users and peers. Users are individuals such as workers and managers. They have the right to access the blockchain network by accessing a peer to which the user belongs through a decentralized application (Dapp). The peer is the unit in which the distributed ledger is stored. It comprises a GC/SC, supplier, and owner/inspector, i.e., the actual user's employment participants (project participants).
Meanwhile, the HLF can set up a channel to respectively set the peers and users participating in each channel, and to create a separate distributed ledger [10]. Therefore, in this study, a channel was created on a site basis, such that only peers participating in the channel could access the corresponding site information, and only the corresponding peer had a distributed ledger of the channel in which it is participating. For example, in Fig. 5, User 2 of Supplier A, which only participated in Channel 1, could only access Channel 1. In contrast, because the GC/SC participated in Channels 1, 2, and 3 (sites 1, 2, and 3), User 1 (belonging to the GC/SC) could access all of the information on Channels 1, 2, and 3. However, User 1 could not propagate information from Channel 2 to 1.
When users enter information according to the ordering, procurement, and installation stages are shown in Fig. 4, the result value is derived internally in the system through the chaincode (referred to as the smart contract in the HLF) used to read/write and compare the information in the HLF. Subsequently, a block including the user input information is generated and propagated through a consensus process consisting of endorsement, ordering, and validation. As described in Section III-C, the drawings and photographic data are stored off-chain during this process, and only the hash and metadata undergo the consensus process. In addition, the propagation of the block is feasible only between peers in the same channel.

B. NETWORK AND CONSENSUS CONFIGURATION
Meanwhile, to minimize the time-to-finality problem mentioned in Section III-B, the HLF can separately designate a Kafka-based ordering service node (orderer) that sequentially generates a block [47]. Kafka uses a conceptual 'leader and follower' configuration, in which transactions are replicated from the leader node to the follower nodes. In the event of the leader node goes down, one of the followers becomes the leader and ordering can continue, ensuring crash fault tolerance [47]. However, Kafka has the limitation that does not prevent the Byzantine faults in which malicious nodes transmit false information and tamper with information [48]. To overcome the absence of Byzantine fault tolerance and information modulation through collusion by a small number of peers participating in the channel, as mentioned in Section III-B, government inspection agencies are assumed to be the endorsing peers and orderers. Furthermore, several peers are grouped into a "Construction Company Org" for GCs and SCs; "Rental Company Org" for suppliers; "Owner Inspector Org" for owner and inspector; and "Public Agency Org" for the government and public agencies that were endorsing peers. This user-peer-Org configuration can be implemented through a membership service provider (MSP); the MSP sets the nodes' roles, affiliations, and authorities constituting the network on the HLF [49]. In general, the participants directly related to the scaffolding work at a construction site are the GCs or SCs, suppliers, and owners/inspectors. The third FIGURE 6. MSP configuration and generation parties that examine information related to the scaffolding work are the government and public agencies. Overall, [8][9][10][11][12][13][14][15][16][17][18][19][20] participants are likely involved directly or indirectly at a site. Accordingly, the number of peers participating in the system developed in this study is set to eight (one GC, two suppliers, two owners/inspectors, three endorsing peers (government and public agencies), and three orderers (same as endorsing peers). The number of user accounts assigned to each of the three peers was set to 10, 4, and 4( Fig. 6-a).
Consequently, MSPs for the Org and peer are generated, as shown in Fig. 6-b. In addition, public keys for decryption to access information, private keys for encryption to enter and store information, and certificates for guaranteeing public keys are generated. Accordingly, the user could obtain permission for the authority and role (in terms of which channel belongs to which peer of which Org) by using the public key certificate registered in the MSP while accessing the Dapp. Fig. 7 illustrates the transaction flow under this channel configuration. The details are as follows.
1) The peer in each Org participating in the channel is marked in red, and its configuration is shown in Figs. 5 and 6. 2) A user belonging to a GC/SC or supplier enters the ordering and procurement information through the Dapp, and a transaction proposal occurs. 3) Peers of the "Public Agency Org" simulate the chaincode that each holds for the corresponding proposal, calculate the result to ensure the result value, and request block creation from the orderer based on endorsement policies (such as majority vote or unanimous agreement). This study set an endorsement policy using Shell Script through the pseudocode shown in Fig. 8 by applying the "AND" option, which represents unanimous agreement. 4) The orderer creates a new block including the corresponding transactions. In this study, it is assumed that there are a total of three (2f + 1 [50]) peers, and that the number of disabilities permitted is one (f). These are based on applying the crash fault tolerancebased Kafka algorithm supported by the pluggabletype consensus algorithm in the HLF [51]. This setting is for the case in which the orderer's peer experienced communication and system failures. 5) The generated blocks are delivered to the leader peer defined by the local MSP for each Org. Furthermore, distributed storage is completed by updating peers in the same channel and same Org using the HLF's gossip protocol.

C. BLOCK STRUCTURE AND VERIFICATION PROCESS
The block headers include block numbers, a hash of the current blocks, and a hash of the previous blocks. The block data include the transaction ID, key information and metadata of the photographs, and information of the peers related to the transactions. The block metadata include the certificate and signature information of the block creator (orderer) and block validation results between peers as generated during the block propagation process [52]. Fig. 9 shows the information contained in the blocks as generated during each stage of scaffolding work, and the process of comparing and verifying this information based on the system utilization scenario,  . Information storage and validation process in the blockchain system system conceptual diagram, and network configuration, as described above. The details are as follows.
1) The channel configuration information in Fig. 7 and block generation setting information (generation cycle and maximum size) are stored in a 'Genesis' block.
The distribution and test result values of the chaincode, which enables the information input, are stored in blocks 1-N. 2) Subsequently, the project information, such as the total quantity and location information input by the GC/SC, are stored in block N + 1. The order information, such as the drawings, quantity, and order-time input by the GC/SC, are stored in block N + 2. The original drawing file is stored in a separate database off-chain rather than in a block during this process. Only the hash, which refers to the drawing, is stored in the block.
3) The item of procurement information as input by the supplier is identical to the item input by the GC/SC. The suitability of the input value is determined by information comparison with block N + 2, and the result is stored in block N + 3. * Basis for calculating the quantity of orders and procurement: The hash of the contractor's uploaded drawing = The hash of the supplier's uploaded drawing * Order and procurement quantity: Quantity of orders placed by the GC/SC = Quantity procured by the supplier * Order and procurement time: material order time ≤ material procurement time 4) After installing the scaffolding, a photograph is uploaded by the GC/SC responsible for conducting the scaffolding work. The GPS, time, and photographer information are collected from the photographs and stored in the block by assigning a hash value to the original photographic file. The adequacy is evaluated using the following logic, and is stored in the block N +4.
* GPS: Basic project information (site location) = metadata (GPS) of photographs * Time: material procurement time ≤ metadata(time) of photographs * Photographer information: Identity and affiliation of the Dapp user ⊂ or = Peer 5) However, the blocks from N+2 to N+4 contain verification results of the information storage and verification process corresponding to the first order, procurement, and installation. Therefore, when an additional scaffolding order is performed, the information is sequentially stored in blocks after N+4 through the same data storage and verification process.  A comparative verification of the procurement, order, and installation of the scaffolding work materials in the system is conducted twice. The Go Programming Language pseudocode for implementing the comparative verification with the chaincode is shown in Fig. 10. As the first comparative verification takes place at the procurement stage, the comparison between 'MATERIAL RENTAL DATA' entered by the supplier and args[0], args [1], and args [5] in 'ORDERED DATA' entered at the ordering stage is performed in this manner. The second comparative verification is performed between the metadata of the photographs at the installation stage and the args[0] from 'ORDERED DATA' and args [3] from 'PROJECT DATA'. However, arg [2], arg [4], and arg [5] are not used for the comparative verification, but the information stored in the blockchain is provided when the user reads the comparative verification result.

V. PROOF OF CONCEPT AND VALIDATION
For system development, eight peers were implemented on two computers using VirtualBox (a virtual machine program). Furthermore, the peers were installed based on the HLF 1.4 on Ubuntu 16.04.7 for blockchain network configuration and chaincode operation. The front-end was implemented as a single-page application using HTML and CSS, and the backend was used HLF, Node.js, and next.js. This section presents the implementation code for hash verification described in Section III-C, JavaScript, and chaincode for implementing the block structure and comparative verification process described in Section IV. In addition, the system is validated by a case study, verifying the information stored in the block and examining the block size.

A. HASH ALGORITHM AND METADATA EXTRACTION OF PHOTOGRAPH
As mentioned in Section III-C, an off-chain database is used to store and manage data (drawings and photographs) which may adversely affect the scalability of the blockchain system beyond 1 MB. Moreover, only the necessary metadata (time, location, and photographer) and hash are stored in the block. Fig. 11 shows the hash verification process using JavaScript. The hash is created using the SHA-256 library, and the hash values were compared.

FIGURE 11. Application of the hash algorithm
The process of collecting the metadata to verify the adequacy of scaffolding work from photographic data is also created in JavaScript, as shown in Fig. 12. In the figure, (a) depicts the front-end coding for extracting the latitude ('tempLatitude') and longitude ('tempLongitude') values and sending these to the server in conjunction with the URL of the photograph ('imageSrc'), photographer('creator'), and time('time'). (b) depicts the back-end coding for defining every item of information (imageSrc, tempLatitude, tempLongitude, creator, time) created from the front-end, and for defining the hash created in Fig. 11. (C) presents a step in which the blockchain network ('ssp') is accessed and the chaincode ('addPhoto') is invoked based on the user's certificate, generated as described in Section IV-B. In this case, the system stores the URL, latitude, longitude, photographer, and hash of the photograph in the block. The affiliated peer and hash indicate the values extracted and stored when uploading the photograph. Through this process, a total of eight pieces of information are stored in block N+4: the upload time of the photograph (args [1]), procurement quantity (args [5]), name of the contractor to which the user (photographer) of the photograph belongs (args [2]), the longitude of photograph (args [3]), the latitude of photograph (args [4]), the comparison result of block N+3 (args [6]), hash of the photograph (args [7]), and final comparison result (args [8]).

C. SYSTEM VALIDATION
The process of entering information as a user of a GC/SC, supplier, and owner/inspector in a system, the inquiring of the verification results, and entered information were validated. The site where scaffolding was installed at Chung-Ang University in South Korea was selected as a project to conduct a case study. It was performed by presenting the ordering, procurement, and installation scenario. The details of the applications are as follows.
1) In the ordering stage ( Fig. 14-a), the author logged in Dapp as 'constructor', and inputted the quantity (35m 2 ), date (2022-01-24), and name of the supplier('supplier'). Also, the drawing (Drawings-50KB.pdf) was uploaded as evidence of estimating the quantity, and the total quantity was automatically retrieved from preset project information. 2) In the procurement stage ( Fig. 14-b), the author logged in Dapp as 'suppler', and inputted the delivered  Fig. 14-e. In addition, it was validated through the Hyperledger Explorer (HLF's block information search module) by determining whether the information entered at each orderprocurement-installation stage was recorded in the blockchain of the distributed ledger. Block 0 was a Genesis Block, which contained configurations, and blocks 1 and 2 were created while distributing the chaincode. Block 3 contained preset project information, including drawing. Block 4-7 contained information during the scaffolding work. Fig. 15 shows that the quantity and order/procurement time composed of the text and numerical information, metadata, and hash of the photograph were entered normally. In the transaction details, the transaction ID is a transaction hash, and the Creator MSP represents the Org to which the information-input subject belongs. The Endorser describes the Org to which the institution that endorsed the transaction belongs.

5) The final verification result is shown in
To verify whether the storage problem of the system was resolved, it was examined whether the off-chain system was working smoothly. For this purpose, photographs and drawing files (JPG, PDF) with different sizes were uploaded to the system five times to verify the variability of the block size from block 3 (Table III). During this process, the block creation cycle was set at 2 s, and the maximum size of the block was set to 99 MB. The block sizes from 3 to 7 remained the same, indicating the scalability of the proposed system. Therefore, the reliability of the information generated during the scaffolding work order-procurement-installation process could be secured using the HLF while minimizing the storage problem, which is indicated as a hindrance to the application of blockchain, by using the off-chain database. The characteristics of the construction industry, in which stakeholders' interests are not aligned, can cause reluctance to use centralized systems, resulting in inefficient management and falsifiable document-based information in scaffolding work. To resolve these problems, this study proposed a blockchain-based system for use by the various stakeholders in scaffolding work. The information generated in the process and characteristics of a third-party inspection of scaffolding work were analyzed to select an adoptable blockchain platform. Furthermore, a system was implemented to solve the storage problem, which is a hindrance to the blockchain application, by proposing a separate storage plan for uploading large-capacity drawings and photographic data while maintaining reliability by comparing hash values. The number of peers participating in the system was set to eight, as the total number of participants directly (GCs/SCs, suppliers, and owners/inspectors) or indirectly (government and public agencies) involved in a site is likely to be 8-20. In addition, because the distributed ledger of the HLF exists based on channels [53], even when the number of construction sites managed by the system in this study increases, only the number of channels increases, as mentioned in Section IV-A. Therefore, it is conjectured that the throughput would not decrease, and the latency would not increase by expanding the network. However, in the case of peers participating in multiple channels, an increased computational capability of the CPU is required; this would be expected to affect the processing.
Meanwhile, as most studies [37], [53], [54] have been conducted on the high performance of the HLF when used for system development, the throughput and latency of these systems have not been measured separately. Furthermore, it was intended to verify the function of utilizing the off-chain database and assigning a hash for storing large-capacity data, that is, to manage external factors affecting the system performance. Accordingly, the information stored in the block was examined to verify the developed system. The variation in the block size according to the photographic and drawing data uploaded was verified. The results revealed that the block size did not vary with the uploaded data size. The hash of the drawing and photograph, and metadata of the photograph were input normally and verified in the block.
This study proposed a blockchain-based system in which various participants in the scaffolding work of a construction project were considered as trustworthy. In particular, this study is expected to be highly realistic in terms of the implementation of storing the photographic data generated in scaffolding work. Moreover, it is significant because it resolves the information disconnection and inefficient management caused by the absence of trust relationships among construction project stakeholders, notwithstanding the availability of several tools or systems from the planning stage. This study indicates multiple achieves in the following aspects.
1) This study is the pioneer attempt to leverage blockchain to scaffolding work, which has received little attention despite its importance. In common practice, the inspection agency pays attention to check information related to scaffolding because scaffolding has a high frequency of fatal hazards. However, fragmented culture and distrust among participants caused problems in sharing reliable information. In order to solve this problem by leveraging blockchain, a systematic study was conducted to select the optimal blockchain platform by analyzing the management characteristics of scaffolding. This study provides the efficiency of verification and reliability for information generated during the ordering-procurementinstallation process of scaffolding. Moreover, from this aspect, this study provides the possibility of automated data comparison and subsequent decision-making through smart contracts, in further an innovative method for remote inspection and management without site visiting.
2) A hybrid on/off-chain model to utilize photographic data is proposed and implemented to increase practical applicability. As mentioned in Section I, since scaffolding is a temporary facility, it is challenging to utilize other technologies such as IoT sensors and BIM information. For this reason, this study attempts to determine the verification of scaffolding installation through comparison with procurement information by using metadata of commonly used photographs. In order to assist in the process of utilizing photographs, this study proposes and implements a detailed solution to overcome the storage problem, a hindrance to blockchain application. 3) The system implemented in this study is highly scalable and is suitable for continuing future research.
In the process of developing the system, this study concerned scalability, time to finality, and storage issues. Therefore, other work packages, which require the reliability of information and smart contracts, can be configured into another channel in the implemented system. In addition, the hybrid on/off-chain system can be used in connection with computer vision and BIM that require storage of large amounts, and IoT sensor technology that requires continuous information update. 4) Detailed information and description on developing system processes can be utilized as an intuitive guideline for researching blockchain applications. The system development process, pseudocodes, and network configuration proposed in this study can be applied to other fields in the construction domain. In addition, these can be used as a major reference for subsequent research.
However, similar to other blockchain systems, the system developed in this study has limitations; Oracle problems. To solve the Oracle problem regarding the quantity and timing of the order information input by the GC/SC, it is necessary to calculate the quantity and estimate the ordering time based on various design tools, such as 4D-BIM tools. If these are linked to the system developed in this study, the Oracle problem can be resolved by verifying the initial data. Furthermore, more advanced forms of remote safety inspections could likely be enabled if computer vision techniques were used to detect the missing guardrails and planks while capturing photographs at the scaffolding installation stage. Computer vision technology can also detect repetitive posting of the same photographs with malicious intentions, thereby further securing reliability in photo information.

VII. CONCLUSION
To improve the management of the scaffolding work, which is a staple on construction projects, this study aimed to secure reliability by blockchaining the information and to develop a real-world system for the usage of various participants. For this purpose, the current scaffolding work process was analyzed, and HLF was selected as the blockchain platform suitable for third-party verification to implement the system. In addition, an off-chain storage method was proposed and implemented to manage photographs in the blockchain system. Photographs are important information owing to the characteristics of scaffolding work, a temporary facility. The implemented system was validated by examining whether the drawing, time, quantity, location, and photograph information input to the front end were normally stored in the block and compared. In addition, the proposed method for solving the storage problem, a hindrance to utilizing blockchain, was validated by measuring block size variations while uploading various data sizes. Consequently, the information was correctly stored in the block, and the block size was fixed.
Therefore, the proposed blockchain system can manage scaffolding work more efficiently at various construction sites; enable owners, inspectors, or third-party public agencies to access reliable information; and enable usage by GCs, SCs, and suppliers. It can be applied to real-world scaffolding work in the construction industry, and the fatal hazards caused by inappropriate scaffolding work management can be reduced. Furthermore, it provides an opportunity to transform the present inspection methods for verifying the appropriateness of scaffolding work installation, as represented by direct visits and document inspections, into remote and automatic inspections. It is expected to further enhance the competitiveness of the construction industry by promoting 'Construction 4.0', enhancing the reliability and transparency of information, minimizing the usage of paper, reducing the burdens on stakeholders, and enabling remote management and inspection while avoiding external environmental risks such as COVID-19, if the methodology of system development proposed in this study is introduced and expanded to other construction parts.
To overcome the limitations of this study, the authors plan to calculate the appropriate quantity and order time for the scaffolding through BIM and big data in a future study. Furthermore, the computer vision techniques can be applied to photographs at the scaffolding installation stage to determine whether guardrails and planks are installed automatically. To apply these functions to an actual construction site, the authors will introduce a safety management platform for converting the current top-down management system to a bottom-up method by implementing a blockchain-based incentivegranting function to induce voluntary information uploads.