Blockchain and Building Information Modeling (BIM): Review and Applications in Post-Disaster Recovery

: Blockchain Technology (BCT) is a growing digital technology that in recent years has gained widespread traction in various industries in the public and private sectors. BCT is a decentralized ledger that records every transaction made in the network, known as a ‘block’, the body of which is comprised of encrypted data of the entire transaction history. BCT was introduced as the working mechanism that forms the operational basis of Bitcoin, the ﬁrst digital cryptocurrency to gain mainstream appeal. The introduction of decentralized data exchange technology in any industry would require strengthened security, enforce accountability, and could potentially accelerate a shift in workﬂow dynamics from current centralized architectures to a decentralized, cooperative chain of command and a ﬀ ect a cultural and societal change by encouraging trust and transparency. BCT aims at creating a system that would o ﬀ er a robust self-regulating, self-monitoring, and cyber-resilient data transaction operation, assuring the facilitation and protection of a truly e ﬃ cient data exchange system. In the state of Florida, climate change and unpredicted weather disasters have put pressure on state and local decision-makers to adapt quick and e ﬃ cient post-disaster recovery systems. Part of the recovery e ﬀ orts is the reconstruction of buildings and infrastructure. The introduction of new technologies in the Architecture, Engineering, and Construction (AEC) industry can contribute to addressing recovery and rebuilding after the event of a natural disaster. With parallel technological advancement in geospatial data and Geographic Information System (GIS), as well as worsening climatic conditions, concerns can be suitably addressed by employing an integrated system of both Building Information Modeling (BIM) and BCT. While several potential applications of BIM must provide solutions to disaster-related issues, few have seen practical applications in recent years that indicate the potential beneﬁts of such implementations. The feasibility of BIM-based applications still rests on the reliability of connectivity and cyber-security, indicating a strong use case for using BCT in conjunction with BIM for post-disaster recovery. This research depicts a survey of BCT and its applications in the Architecture, Engineering, and Construction (AEC) industries and examines the potential incorporation within the BIM process to address post-disaster rebuilding problems. Moreover, the study investigates the potential application of BCT in improving the framework for automating the building permitting process using Smart Contract (SC) technologies and Hyperledger Fabric (HLF), as well as discussing future research areas. The study proposes a new conceptualized framework resulting from the integration of BCT and BIM processes to improve the e ﬃ ciency of building permit processes in post-disaster events.


Introduction
The rebuilding process after a disaster is critical for communities affected by disaster events. The time required to rebuild ideally should be as short as possible. However, building permits for new homes and structures must be issued in compliance with county zoning and state codes. This permit process currently takes considerable time, which has a negative impact on communities affected by these disasters. This study explores the employment of Building Information Modeling (BIM) and Blockchain Technology (BCT) to assist in the rebuilding process after disaster events by reducing the time and resources needed to issue building permits.
In post-disaster recovery, the challenges facing the local governments are the need to spend time to reflect on taking well-planned decisions and enacting quick response, to the willingness of the community to rebuild faster [1][2][3]. The federal-wide efforts provided by FEMA to local governments  In general, three generations of BCT can be distinguished: blockchain 1.0, which covers applications enabling digital cryptocurrency transactions; blockchain 2.0, which expands blockchain 1.0 by introduction Smart contracts and a set of applications beyond cryptocurrency transactions; blockchain 3.0, which enhances the capabilities of blockchain 2.0 in terms of transaction time, scalability, and ease of implementation using DApp; This research contributes to a thorough understanding of the BCT and its current state-of-the-art applications, particularly its relationship to the rebuilding process after disaster. Moreover, this paper provides new approaches for integrating BCT with the BIM workflow, such as improving the framework for automating building code compliance checks and the permitting processes.
The rest of the paper is structured as follows. In Section 2, the purpose of the study and research questions are described. The objectives of this work are given in Section 3. The methodology employed to conduct a systematic literature review is introduced in Section 4. The findings and evaluation of the retrieved literature about BCT are presented in Section 5, while Section 6 addresses the applications of BCT in different industries. Section 7 discusses the relationships between the BCT and BIM processes. In Section 8, the paper introduces a new approach for enhancing the framework for building permitting process using BCT and BIM workflow. Conclusions and future research areas are presented in Section 8.

Problem Statement
Post-disaster recovery and construction market growth are pushing the efforts of streamlining the submission and review of design documents by the building authorities. A growing number of local building departments are switching their paper-based process to an electronic-based process. The Alliance for Building Regulatory Reform in the Digital Age at FIATECH investigated the total savings generated per year from 3000 permit applications after the adaptation of the e-permitting process. The investigation result have shown that the shift to the new process has reduced the driving Buildings 2019, 9,149 5 of 32 mileage by 31,2000 miles and saved 20,800 gallons of gas, decreased the omission of carbon monoxide by 457,600 lbs., cut the cost of the fuels by $57,200, gained 12,480 h of driving, and eliminated storage location for 12,000 lbs. of paper [15,16]. The e-permitting process certainly helps to improve the permitting process; however, it is still based on a manual review of the pdf or CAD files. There is no automation or semi-automation of the review and permitting process. Thus, this research aims to review the fundamentals of Blockchain Technology (BCT) and its application in the AEC industry, focusing on BIM workflow to assist in post-disaster rebuilding efforts.
The hypothesis of this work is that conducting a systematic review of BCT and its current applications would assist in developing an integrative framework BCT+BIM to assist in post-disaster recovery. In particular, the study aims to address the following research questions: (i) How does BCT develop over time? (ii) What are the fundamentals of BCT and its areas of applications? (iii) Is there any potential of integrating BCT with BIM workflow to enhance the post-disaster rebuilding process?

Methodology
The research is designed as a non-experimental, retrospective-prospective study, which examines and curates blockchain technology and BIM integration to improve the post-disaster rebuilding process. The research approach is based on a systematized review of the current development of Blockchain Technology (BCT), and its applications in the AEC to enable the development of an integrative framework for enhancing the rebuilding process after disasters. The procedure comprises two phases. Phase 1 includes identifying the research's key aspects, selecting the relevant studies, assessing the quality of the content, extracting data, and synthesizing the information. The second phase deals with the development of an integrative BCT + BIM framework, using the information from phase 1 to improve the post-disaster rebuilding efforts.
A comprehensive investigation of the current literature is essential to further the knowledge base of significant topics, enable the formulation of a viable narrative, and justify the research goals and future studies. Figure 1 illustrates the overall method employed in this study. The first phase of the research protocol focuses on the scope identification and the survey background on the current state of BCT and its applications. This phase covers the existing knowledge base, to provide background on the historical developments of prominent BCTG, the significant development of key features, market impact, and uptake. The knowledge of ongoing research efforts could provide a fair prediction of future developments. This phase ascertains the upper and lower limits of relevant fields with respect to the current capabilities and limitations of BCT and BIM. This includes classifying the publications according to the main categories: BCT related only, BCT and the AEC, BCT and BIM, and the post-disaster rebuilding and BIM. Since there has been minimal overlap between the fields of BCT and BIM (or between post-disaster reconstruction and BCT), it was necessary to develop a cache of descriptive data and conceptual underpinnings pertaining to both fields. This review helped to strengthen the research question, clarify the scope and objectives, and validate the direction of the paper. Finally, conclusions about the potential applications of the emerging BCT in the post-disaster rebuilding are presented, as well as a proposal for a new integrative framework resulting from incorporating BCT in the BIM workflow, which could simplify the rebuilding process after a disaster.
Phase 1 of the study centers around assembling evidence through an extensive literature review. The literature review provides definitions, background, historic development, current knowledge areas, and ongoing research efforts on each relevant area. The prevalent aspects currently discussed and researched are used to identify the keywords, which have served to widen the search process in search tools, such as Google Scholar, Mendeley, Microsoft Academic, Bielfeld Academic Search Engine (BASE), arXiv, WorldWideScience, RefSeek, Science.gov, ResearchGate, and Virtual Learning Resources Center. The first set of articles collected was examined for relevancy by reading the abstracts. A closer examination of the papers determined the relevancy of the papers to the post-disaster rebuilding investigation. A preliminary study of literature articles suggests that BIM interoperability, BIM collaboration, data integrity and cybersecurity, Smart Contract (SC), and Hyperledger Fabric (HLF) are While many publications exist that tackle the fundamentals, operational mechanisms, and research directions of BCT, limited research papers address areas of BCT that overlap with application in the AEC industry and post-disaster recovery. Even fewer publications are available that focus specifically on the use of BCT in BIM processes in connection with rebuilding after a disaster. However, the current number of papers tackling these subjects are reassuring, as many research results published in recent years propose the employment of BCT, precisely its Smart Contract (SC) concept, to achieve different solutions in a BIM environment.

BCT Basics
Blockchain concepts, functionality, present implementation, mining, cybersecurity, and transaction protocols are discussed by many studies, such as [13,14,[18][19][20][21][22][23][24][25][26][27][28][29][30][31][32][33]. The advantages of using different types of BCT are studied by [21,[34][35][36][37]. In a blockchain network, the ledger consists of a chain of sequentially arranged blocks of discretized, encrypted data, which is created and stored with cryptographic hashes upon validating a transaction. The two main parts that constitute an individual block are: i. Block header, consisting of the block version, a timestamp, Merkle tree root hash equivalent of the transactions, nBits, Nonce, and a parent block. A Block version indicates the set of the block validation. Timestamp displays the current universal time. Nonce is a 4 byte field that generally starts from zero, and increases by one for every hash calculation, thus acting somewhat as a transaction counter. The parent block hash is the 256 bit hash value that references the parent block, i.e. the sequentially preceding block to the one in the discussion. The first block in the chain that does not have a precursor is called the genesis block. ii.
Block body, which contains the actual transaction data. This is the part of the block that effectively dictates the upper limit of the possible transactions, as well as the transaction time [18]. While many publications exist that tackle the fundamentals, operational mechanisms, and research directions of BCT, limited research papers address areas of BCT that overlap with application in the AEC industry and post-disaster recovery. Even fewer publications are available that focus specifically on the use of BCT in BIM processes in connection with rebuilding after a disaster. However, the current number of papers tackling these subjects are reassuring, as many research results published in recent years propose the employment of BCT, precisely its Smart Contract (SC) concept, to achieve different solutions in a BIM environment.
The digital infrastructure of the blockchain network can be divided into two layers of code [38]: Fabric layer: consists of the actual blockchain code base, communication protocols, public key infrastructure, data structures for database maintenance, and smart contract capabilities. Since the blockchain network is owned and controlled by the developers, the fabric layer cannot be tampered with.
Application layer: contains the application logic of smart contracts. It is collectively controlled by the participants who deploy the code onto the blockchain network when it is operational. Any participant that holds access and control of the deployed code can write the application layer.
The blockchain networks can be generated in several ways. These are typically organized according to the network's management and permissions, such as public (permissionless), private (permissioned), and federated [18,[39][40][41]. It is worth mentioning that in a public blockchain network, any entity can join as a new user and perform operations, such as transactions or authentications.

Decentralized Systems
A centralized network is one that tasks a single central node with monitoring, controlling the flow of information between the other nodes, and dictating operational controls. From a personal standpoint, one decision-maker could reduce the likelihood of conflicts and disagreement, but on the other hand, several other factors could affect coherent interoperability and collaborative decision-making, such as if even one of the two parties is acting with malicious intent, or is negligent or incompetent.
A decentralized database structure, which is known as Decentralized Ledger Technology (DLT), is a peer-to-peer network that typically integrates a decentralized agreement mechanism, distributing the computational workload across multiple nodes present throughout the network, facilitating the nodes to create connections, and ensuring the links stay alive, while also ensuring every node in the network receives and transfers out data [18,20,42]. This mechanism excludes the likelihood of a system failure or a complete network blackout. DLTs usually achieve this by integrating a decentralized consensus structure before the blockchain initiating transaction operation. The network participants agree in advance and decide on a consensus mechanism appropriate to their requirements. Every endorsing node in the network runs the same consensus algorithm. Thus, the system does not need any third-party administrator to oversee the data exchange operations [43].

Trust Systems
Members of the network must prove themselves as legitimate members. Thus, reaching a consensus agreement is one of the key features of a distributed technology [43]. A consensus between all participants in the blockchain network is agreed on prior to the implementation of the BCT, and this agreement ensures that the ledger is shared, unchangeable, and immutable throughout its life.
After agreement on the consensus mechanism, the peers execute the consensus protocol to validate transactions, create blocks and hash chains. The ledger is updated and appended in the event of the occurrence of errors, instead of overwriting them. New transactions recorded on the ledger are validated by miners. A block is mined every few minutes. The Byzantine Generals (BG) problem is central to determining consensus in a BCT, and all consensus mechanisms are developed with the aim to overcome this issue. The Byzantine General Problem was a security flaw in distributed systems developed prior to Bitcoin, in which the nodes aim to reach a consensus despite having a faulty component [44]. This increases the possibility of malicious intent or network irregularities. The different mechanisms through which consensus is reached are:

•
Proof of Work: 'Mining' or the Proof of Work (PoW) mechanism works by determining the node that writes a block on ledgers using a combination of game theory, cryptography, and incentive engineering [18]. The nodes in the network compete to solve a mathematical puzzle (generally a computationally difficult but easily verifiable pattern) to record a transaction. Upon resolving the puzzle, a consensus is reached by broadcasting the resolved solution to other nodes in the network, thereby ensuring transparency, robustness, and incorruptibility of the network. Consequently, the group with larger total computing power dictates the decision-making and reaching consensus. The two most popular BCT systems, Bitcoin and Ethereum, operate on a PoW mechanism. However, this involves expensive transaction fees, extensive computing tower, and cumbersome mining processes to create new blocks.

•
Proof of Stake: The creator of the block is chosen in a deterministic method, depending on the stake held by the participant. An algorithm is employed to determine collective decision-making and the level of privacy between participants. This mechanism requires the credibility of data, which is denoted by proof of ownership of cryptocurrency coins. If a created block can be validated, the cryptocurrency will be returned to the original node as a bonus. This method involves no block rewards but operates solely on transaction fees. It is thus an energy-saving alternative to PoW and presents several economic benefits. Ethereum aims to shift the paradigm by transitioning to a PoS mechanism. • Practical Byzantine Fault Tolerance (PBFT): This is a Byzantine agreement consensus method that can tolerate a maximum of 1/3 malicious byzantine replicas. A primary is selected in each round and is responsible for ordering the transaction. A node enters the next phase if it receives 2/3 of votes from the remaining nodes in the network [18]. Thus, PBFT requires each node to query other nodes. Hyperledger fabric uses the PBFT algorithm; • Delegated Proof of Stake (DPOS): Stakeholders elect representatives to validate blocks. Since this mechanism features a relatively small number of nodes, the processing of transactions is quicker [18]. The delegates are authorized to modify the network parameters.

Mining
Mining is the mandatory process of recording transactions on the blockchain network using the computer's processing power. The subset of nodes in the network that are equipped with special software that validate the transactions to be added on the blockchain is called miners [28].

Privacy
A blockchain can address the accessibility and visibility of the data in a secure and efficient manner, since the ledger is distributed [43,[45][46][47][48]. This ledger facilitates setting different levels of privacy, as every participant is essentially a stakeholder and no single participant has full administrative privileges. Thus, formulating and enforcing consensus is crucial to the blockchain operation, with respect to data updates, error-checking, and collective decision-making. The selection of which BCT to use depends much on the method of the agreement to reach consensus.
Based on the privacy, blockchains can be classified as: • Permissioned blockchains: Permissioned Blockchains restrict the actors that can contribute to the consensus of the system state. Only a restricted set of users have the rights to validate transactions and may also restrict access to approved actors who can create smart contracts. HLF is an example of this permission type.

•
Permission-less or public blockchains: Blockchain networks that are permission-less allow any participant to create consensus, as well as smart contracts, and uses the PoW mechanism to reach a consensus. They typically use a native cryptocurrency or none to validate transactions. Bitcoin and Ethereum blockchains are good examples of this type of permission.

Smart Contracts
Smart contracts are contracts programmed with the blockchain that automatically execute upon the fulfilment of certain conditions. This removes the requirement of a third-party intermediary for Buildings 2019, 9, 149 9 of 32 overseeing the transaction in real-time [45,46,[48][49][50]. They are an extension of the blockchain that can independently enforce rules without requiring manual intervention. Figure 3 illustrates the concept of a smart contract in a blockchain network.
In the context of the BCT taxonomy, two different definitions for the term 'smart contracts' are given, since the term is used interchangeably for the written code and the binding contracts [45,46]. Smart contracts codes: They are software agents fulfilling pre-set obligations and exercising certain rights and may take control of certain assets within a shared leger.
• Smart legal contracts: This term focuses on the expression and implementation of the software and encompasses operational aspects and issues about the composition and interpretation of the contract. A high-level definition that combines both aspects of the smart contract and is based on automation and enforceability is given in [46]: "A smart contract is an automatable and enforceable agreement, automatable by a computer, although some parts may require human input and control, enforceable either by the legal enforcement of rights and obligations or via tamper-proof execution of computer code." Two widely used programming languages for writing Ethereum Smart Contract (SC) are Solidity and Serpent. Further, there are a number of emerging contract-oriented high-level languages under development, such as Viper, Lisk, and chain.
In a Hyperledger Fabric (HLF), SC is known as chaincode, which is executable code, deployed on the network, where it is invoked and validated by peers during the consensus process. The common programming languages used in developing chaincode are Go, Ruby, Java, and NodeJS [51].
In summary, the main characteristics of a smart contract generally include [46]: • Automation: Automation is accomplished by linking the legal prose to the smart contract code via parameters that generate instructions regarding the final operational details. • Enforceability: The smart contract code must execute successfully, accurately, and within a reasonable timeframe. A smart legal contract must include legally enforceable obligations and rights that are expressed in complex, time-dependent, sequential, context-sensitive prose. These may also include overriding obligations based on the fulfilment of certain conditions. The following is a definition for the concept of smart contracts [28]: "Smart contracts are digital contracts allowing terms contingent on the decentralized consensus that is self-enforcing and tamper-proof through automated execution." The introduction of smart contracts in blockchains has opened many new possibilities, such as complete lifecycle management of legal contracts, automated execution of contracts, and personalization of customizable contracts.

Hyperledger Fabric (HLF)
In the context of the BCT taxonomy, two different definitions for the term 'smart contracts' are given, since the term is used interchangeably for the written code and the binding contracts [45,46]. Smart contracts codes: They are software agents fulfilling pre-set obligations and exercising certain rights and may take control of certain assets within a shared leger.

•
Smart legal contracts: This term focuses on the expression and implementation of the software and encompasses operational aspects and issues about the composition and interpretation of the contract.
A high-level definition that combines both aspects of the smart contract and is based on automation and enforceability is given in [46]: "A smart contract is an automatable and enforceable agreement, automatable by a computer, although some parts may require human input and control, enforceable either by the legal enforcement of rights and obligations or via tamper-proof execution of computer code." Two widely used programming languages for writing Ethereum Smart Contract (SC) are Solidity and Serpent. Further, there are a number of emerging contract-oriented high-level languages under development, such as Viper, Lisk, and chain.
In a Hyperledger Fabric (HLF), SC is known as chaincode, which is executable code, deployed on the network, where it is invoked and validated by peers during the consensus process. The common programming languages used in developing chaincode are Go, Ruby, Java, and NodeJS [51].
In summary, the main characteristics of a smart contract generally include [46]: • Automation: Automation is accomplished by linking the legal prose to the smart contract code via parameters that generate instructions regarding the final operational details.
• Enforceability: The smart contract code must execute successfully, accurately, and within a reasonable timeframe. A smart legal contract must include legally enforceable obligations and rights that are expressed in complex, time-dependent, sequential, context-sensitive prose. These may also include overriding obligations based on the fulfilment of certain conditions.

Hyperledger Fabric (HLF)
Hyperledger Fabric is a platform for generating distributed ledger blockchain systems, supported by a modular design, offering an elastic and extensible digital framework that delivers high levels of confidentiality and scalability. The Hyperledger Fabric is designed to support pluggable implementations of different components and accommodate the complexity and details that exist across the economic ecosystem. The Hyperledger blockchain aims to be a general purpose, enterprise-grade, open-source DLT that features permission management, pluggability, enhanced confidentiality, and a consensus mechanism, and is developed through a collaborative effort. HLF is one of the blockchain projects within Hyperledger. Like other BCT, it has a ledger, uses smart contracts, and is a system by which participants manage their transactions.
Hyperledger was founded by the Linux Foundation in 2015 to advance cross-industry BCT. It was the first blockchain developed that enabled the development of distributed applications written in standard general-purpose programming languages [52]. Presently, the Hyperledger consortium involves IBM, the Linux Foundation, and other organizations that contribute to the BCT development and related apps [48]. The open source nature of the BCT is augmented by the lack of necessity in mining cryptocurrency or expensive computations to validate transactions. The HLF was the first blockchain developed that enabled the development of distributed applications written in standard, general-purpose programming languages [52]. HLF was founded by IBM and aims to be a platform for developing applications with a modular architecture. It permits plug-and-play components and leverages containers to host smart contracts called chaincodes, which comprise the business logic of the application.
The fundamental difference between HLF and other blockchain systems is that it is private and requires permissions. In contrast to an open permission-less system that allows unknown identities to participate in the network (necessitating rules like PoW to authenticate transactions and secure the network), the nodes (members) of an HLF network join through a trusted Membership Service Provider (MSP). Furthermore, HLF offers several pluggable options, such as ledger data, which can be stored in multiple formats, and consensus mechanisms, which can be exchanged in and out; diverse MSPs are also supported.
Moreover, Hyperledger Fabric has the ability to create channels, allowing a subgroup of participants in the network to establish a separate ledger of transactions. This is an especially important option for BIM workflow where subcontractors can exchange data within the only subgroup of the network. For example, the structural engineer of record of the project can exchange information with steel connection subcontractors only while still being part of the HLF network and sharing those transactions with the rest of the nodes.
• Assets: Assets can range from physical objects (real estate and hardware) to the intangible (BIM models, contracts, and intellectual property). Hyperledger Fabric provides the ability to modify assets using chaincode transactions. • Ledger: It is comprised of a blockchain to save the immutable, sequenced records in blocks, as well as a state database to preserve the fabric state. There is generally one ledger per channel. Each node sustains a copy of the ledger for each channel of which a node is a member. The shared ledger encodes the entire transaction history for each channel and includes SQL-like query capabilities for efficient processing.
• Privacy: Channels enable multi-lateral data exchanges with the high degrees of privacy and confidentiality required by the AEC specialized and other regulated industries that exchange data on a shared network. A ledger exists in the scope of a channel and it can be shared across the entire network (assuming every participant is operating on one common channel), or it can be constrained to only contain a specific set of participants. • Security and Membership Services: Permissioned membership provides a trusted blockchain network, where participants know that all transactions can be detected and traced by authorized regulators and auditors.

•
Consensus: It is defined as the full cycle of verification of the correctness of a set of transactions comprising a block in a distributed ledger system. HLF consensus covers the entire transaction flow, from proposal and endorsement to ordering, validation, and commitment. Hyperledger Fabric has been designed to allow a new application to select a consensus mechanism that best characterizes the relationships that exist between participants in the network. • Smart Contracts: Hyperledger Fabric smart contracts are written in chaincode and are invoked by an application external to the BCT when that application needs to interact with the ledger. In most cases, chaincode interacts only with the database component of the ledger, the world state (querying it, for example), and not the transaction log. Chaincode can be implemented in several programming languages. The currently supported chaincode language is Go, with support for Java and other languages coming in future releases.

Limitations
On one hand, there are notable advantages of BCT that include: the trust system (consensus, mining and the public ledger), secure communication on open networks using cryptography, and encryption; transparency; removal of Intermediaries; decentralization; reduced costs; and increased transaction speed. On the other hand, there are also downsides and risks associated with the standard BCT that can be ignored at this time. These limitations may involve [13,18,25,30,32,33,43,55]: Lack of Privacy: Decentralized public blockchains lack privacy, which will make full acceptance difficult. Not only is the information not private, but it is also readily accessible at any given moment to anyone using the system This is also concerning considering that the computers running a large amount of the blockchain networks are in countries like Russia and China, where computer crime rates are high and personal information may be used against people living in or traveling to those countries. This is particularly an issue for Bitcoin and Ethereum systems.
Security concerns: Blockchain-based assets are like cash. If the cash in your wallet is stolen or lost, then it is gone. Blockchain-based systems use advanced cryptography and encryption that are more secure than standard internet passwords or number access codes. However, more security can sometimes result in a system being less secure. There are countless examples of cryptocurrencies where someone has forgotten their private key and cannot access their money. With blockchain-based systems, transactions cannot be altered or reversed, and there is no intermediary to assist you if fraud occurs on your account. If you sent funds to the wrong account number (wallet) on the blockchain, then those funds are gone. If someone gains access to your private key, they can access other members' data easily.
Lack of a centralized management entity: The control is placed with most members of the network, creating issues with regards to control of the blockchain network. The decentralized nature of many blockchains means that the system must agree and decide the future direction of the blockchain system. With a traditional network and software, if an organization wants to make a change, they can make that change after approval from relevant departments within the organization. With a decentralized public blockchain system like Bitcoin, changes must be agreed to by a certain majority of the networks' participants. This may be over 50% but could be as high as 70% to 80% of the nodes of the network. No single entity has control over the changes or direction of a decentralized blockchain system, making them risky for businesses to use as they cannot manage any changes to the system. Risk of a 51% attack: If someone were able to control over 50% of the computers on a blockchain network, that person would control the transactions on the blockchain network. A malicious user controlling over 50% of the computers on a blockchain network is known as a 51% attack. Leveraging this control over a cryptocurrency network, they would theoretically be able to block new transactions from confirming, reverse transactions, and allow for moving assets freely in a Bitcoin network.
Cost: The Proof-of-Work (PoW) algorithm that many blockchain networks use requires proof that computing power and resources contributed to the network before a block is added to the network. This proof is in the form of an answer to a puzzle that is attached to the block for the network to confirm it is correct. Solving this puzzle requires an enormous amount of computing power and electricity.
Lack of scalability: At the current rate of energy consumption, the electricity costs of running certain public blockchain system, such as Bitcoin, and using the PoW algorithm make it unfeasible to handle the number of transactions (for example, by credit card companies like Visa and MasterCard). This is one of the factors that is presently affecting the scalability of blockchain networks.

Summary of BCT
Blockchain systems are generally comprised of four building blocks: (1) a shared ledger, (2) privacy, (3) trust, and (4) smart contracts (see Figure 4). These main blocks are briefly explained below: Shared ledger: Shared ledger refers to the distributed transaction records in the network. With the bitcoin blockchain system, the intent was to publicize the visibility and transparency of data exchanges. However, enterprise blockchain systems requires a different approach due to the regulation of consumer data.
Privacy: Privacy is achieved through cryptographic encryption of data and ensures that transactions are authenticated and verified. Privacy is a crucial part of the BCT to strengthen security and make the distributed system on the network more difficult to breach.
Trust (consensus): Trust means using the power of the network to verify data transaction. The trust model (consensus) is truly the heart of blockchain applications. Trust is what delivers the tenets of trust, exchanges, and ownership. Trust is what enables the blockchain to displace the transaction system, but this can only happen when trade and ownership are addressed by distributed/shared ledgers. The trust system is modified whenever new participants join the blockchain network and apply BCT to a new use case or change. There is still much work needed to define an optimized trust system for various use cases.
Smart contracts: Smart contracts are business agreements embedded into the transaction database and executed automatically with transactions. Contracts consist of rules that are required in any commerce activities to define the flow of values and the state of transactions. A contract is smart because it uses a computerized protocol to execute the terms of the contract. Various contractual clauses (such as collateral, bonding, delineation of property rights, and so forth) can be transformed into machine language to enforce compliance with the terms of the contract and ensure a successful transaction. Smart contracts are intended to guarantee one party that the other will satisfy their promise. Part of the objective of such contracts is to reduce the costs of verification and enforcement due to the lack of an intermediary party to oversee transactions.
Smart contracts must be transparent (indicating that participants can see or prove each other's actions pertaining to the contract), confirmable (meaning that members can prove to other nodes in the network that a contract has been completed or breached), and private (implying that knowledge of the contents/performance of the contract should involve only the necessary members required to execute it). These advances made it possible for complex business contracts to be codified in a blockchain system. Smart contracts: Smart contracts are business agreements embedded into the transaction database and executed automatically with transactions. Contracts consist of rules that are required in any commerce activities to define the flow of values and the state of transactions. A contract is smart because it uses a computerized protocol to execute the terms of the contract. Various contractual clauses (such as collateral, bonding, delineation of property rights, and so forth) can be transformed into machine language to enforce compliance with the terms of the contract and ensure a successful transaction. Smart contracts are intended to guarantee one party that the other will satisfy their promise. Part of the objective of such contracts is to reduce the costs of verification and enforcement due to the lack of an intermediary party to oversee transactions.
Smart contracts must be transparent (indicating that participants can see or prove each other's actions pertaining to the contract), confirmable (meaning that members can prove to other nodes in the network that a contract has been completed or breached), and private (implying that knowledge of the contents/performance of the contract should involve only the necessary members required to

General
While noting that BCT development is still in its infancy, the U.S government has recognized its potential and has begun to study BCT to address various technical issues at different levels, as noted in [56]. The removal of an overseeing third-party as an essential actor in a particular transaction may be viewed less favorably by banks. However, the same report [56] implies an annual $8-$12 billion in savings per bank, stemming from just negating processing fees and paperwork. A critical path for success in governmental implementation that sees widespread systemic integration and use is to lower costs to a minimum well below current levels while providing transparency and secure network services without interruption [56], as is the case for every emergent digital technology. BCT appears to fulfill all these requirements and provides several other applicable use cases as well, and the uptake and direction of development seems to be encouraging at the moment.

BCT and the AEC Industry
While the digitization of many designs and engineering processes in the AEC industry has seen advances in recent years, it should be noted that the AEC industry has the slowest rate of digital transformation, just above agriculture and hunting [57]. Changes are largely impeded by the fragmented nature of the construction sector, stemming from the current organization of teams and projects, featuring a collaborative process for a project. This is counterproductive in that each party may aim to merely deliver the minimum work order, prioritize profit margins, and minimize liabilities [57]. Thus, the modern economy favors an adversarial environment where firms would be better incentivized by minimizing information exchange between parties. However, in the future, data exchanges in networks can help to achieve significant savings in cost, time, error, and labor, as well as stimulate collaborative learning.
There is still clearly inadequate education at the firm and workforce levels to present an overall holistic picture of how updating current trends could lead to several advantages. Several organizations have not yet recognized the potential and significance of adopting Building Information Modeling (BIM) techniques and have instead concluded that this would, in fact, complicate existing practices, while disregarding the long-term benefit and overhead savings. Further, the collaborative design process in BIM could create difficulties in assigning responsibilities and liabilities due to the overlap of roles and responsibilities, ensuring intellectual property protection, risk allocation, privacy, third-party reliance, and software agents [22,58]. The focus of firms on return on investment, the complexity of projects, large initial capital, firm reputation, untrained personnel, legal considerations, and government restrictions are other factors that still impede digitization.

Current Advances
The advent of Building Information Modelling (BIM) has facilitated a collaborative work environment with a single centralized model, so that the structure can be analyzed, checked for compliance, and cleared of errors in the design stage prior to actual construction. Adopting BIM presents a novel way of integrating all pertinent data into a shared digital model with geometric, temporal, and financial and asset management dimensions. BIM software, like Revit and ArchiCAD, also includes a plethora of plug-in tools that can simulate and assess several important aspects of a building structure, such as operational energy analysis, lifecycle costs, occupancy behavior, connection design, interior acclimatization, building envelope, quantizing ecological footprint, etc. Thus, one can simulate scenarios and focus on one or more specific variables in real-time for every stage in the building lifecycle. This not only avoids unforeseen circumstances and errors in future stages but greatly saves time, manual labor, and the need for excessive paperwork.

Blockchain in Construction Management
Blockchain technology, while still in its nascent developmental stages, has the potential to accelerate and streamline much of today's design and engineering practices with a multitude of benefits to the firm, individual, industry, clients, and society. The implementation of BCT could lead to the effective management and utilization of several tools that would drive efficiencies, transform industry culture, and advance futuristic advancements, such as [21]: • Building information modelling software for intelligent and collaborative 3D design and modelling; • cloud-based technology, allowing for real-time creation and coordination of a visualized database and serving as a platform for multi-disciplinary collaboration; • smart contracts, a set of coded instructions that can automatically execute upon the fulfillment of certain conditions; • reality capture technology, allowing verification and conversion of digital assets into real value; • managing the Internet of Things (IoT); • functionally permissioned blockchains that facilitate consensus-based collaboration.
BCT can considerably slash administrative costs, effectively protect intellectual property rights, and eliminate cumbersome paperwork, manual verifications, and contract execution. A potentially new stream of revenue for design professionals could be created by evaluating and selling designs and workflows. This, however, would also include addressing future problems that might arise, such as a possible drop in quality standards and continued liability [21].
Building a reputation is an essential asset to any organization, which is difficult to quantify and compare. BCT can facilitate the creation of a registry consisting of past achievements and qualifications, with a goal to enable comparison of team constellations and thus aiding in decision-making processes for clients and project managers to select a well-balanced team with varied skill sets, experience, and versatility [21].

BCT Applications in Disaster Relief
The management of the post disaster recovery process can be slowed down because of the poor management of permitting process. Incorporating fast-tracked approaches and enhancing collaboration with other stakeholders can reduce the repairs, and new construction permits delays [59]. There are insufficient efforts highlighting such problems when preparing a post-disaster management plan. The post-disaster recovery goals are to reconstruct a built environment that is sustainable and can stand against any future disaster events. Decision makers can learn from the consequences of unplanned recovery process as what happened in Venezuela in 1999, where 15,000 people lost their lives due to mudslides and floods. These people were relocated to an unsafe region after the major landslide of 1984 [1]. In the United States, the Federal governments has created 10 different zones directed by FEMA staff to coordinate and support the local government response to the disasters in their jurisdictions.
According to FEMA, pre-disaster and post-disaster planning can be categorized into four stages. Every stage has a range of activities and decisions that should be taken to achieve a full recovery. The different response activities have been addressed by the National Response Framework (NRF) and the National Disaster Recovery Framework (NDRF). Both are federal Frameworks that complement each other. The tasks that need to be performed during short term and intermediate recovery stages are critical for saving lives and properties and providing basic needs. Some of these activities include sheltering, rescuing, debris clearing, power restoring, and building repairing. These tasks can last for months. The long-term recovery stage tasks focus on the reconstruction of buildings and infrastructures that have been impacted significantly. This stage may last for several years if the damage scope is enormous [60].
The inherent characteristics of a distributed ledger make it an appropriate tool to implement in disaster management systems, as evidenced by recent efforts. Connecting services tasked with transporting food, water, and other aid are often impeded by a lack of transparency between different functionalities, cumbersome coordination between different parties, complicated logistical planning, delayed deliveries, shortages, and a waste of resources [8].
Rohr [61] states that disaster situations necessitate absolute transparency, which only distributed networks can provide [62]. BCT can thus act as the central system of all operations by connecting all involved parties and enhancing convenience in communication while upholding a secure protocol over the network. A model proposed by [63] suggests an integrative model over a blockchain network that connects government bodies, medical suppliers, shelter providers, relief aid, telecom service providers, residents, and transportation providers.
The transparency and automated dissemination of recorded information that is characteristic of BCT can negate the requirement of human involvement and arduous paperwork [8] for sanctioning approvals and can further streamline other managerial operations.
'Building Blocks' is a blockchain initiative launched in January 2017 by the World Food Program (WFP). This initiative targets the Azrap refugee camp in Hordan, with the aim of increasing the overall efficiency of the cash-based transfer scheme in a number of processes, such as refugee registration and financial accounting [63]. Initial development and deployment were achieved in under five months.
Building Blocks was meant to augment and increase the efficiency of the existing digital infrastructure of WFP's processes for beneficiary information registration and payment mechanisms by streamlining back-end processing while the cash system used by the beneficiaries was unchanged [63]. It involves an integrative synthesis of blockchains, digital databases, and biometrics, and is estimated to have saved WFP monthly costs of $150,000 by eliminating 98% of bank-related fees [63].

Blockchain and BIM
This section addresses issues related to the potential capabilities of BCT in scaling and enriching the BIM process. It explores various aspects of existing BIM workflow that could benefit from the integration of blockchain technologies.
BIM is at the forefront of digital transformation in the AEC industry, encouraging collaboration and trust and simplifying data exchange. McGraw-Hill reports that BIM adoption increased to 71% in 2012 from 49% in 2009 [17,64]. BIM models present a comprehensive design model of the building that can include all aspects of the structure, like architecture, structural elements, and MEP design areas. Further, several built-in plug-ins in BIM platforms, like Autodesk Revit, enable the simulation of external site conditions, geography, weather, as well as carry out energy analysis, building energy modeling, structural analysis, etc. In the future, BIM development will eventually aim to unify all design and analysis tools in one platform.
In terms of the benefits incurred from the adoption of BIM in the AEC industry, Cannistrato [65] studied data from 408 projects over 6 years, totaling $558,858,574, to quantify how much BIM contributed to saving money. The report indicated that BIM saved more money and the project team became more collaborative in the process. Another example is the study by [66], which indicated similar results. Their investigation covered a set of 35 case studies between 2008-2010, which all indicate cost savings due to BIM usage. The study has also noted reduced times in project schedules, improved communication, greater information exchange, and higher levels of coordination. The data clearly implies that initial costs, such as hardware upgrades, software implementation, and training of personnel, are offset on the long term upon BIM implementation. However, the BIM process still bears a number of shortcomings. These include some limitations in the schema, technical toolset, and managerial aspects of the current BIM process. More specifically, these deficiencies involve: • an insufficient toolset or methods that can efficiently comment or mark upon Requests For Information (RFIs) [

Data Ownership
BIM can address the issue of converting intrinsic value to digital values by creating added value, coupled with BCT's ability to provide reward mechanisms in the form of virtual currencies that hold validity long after the project's completion. BIM authoring tools can expand their potentials by adding budget control objects to assist in tracking costs and savings. #AECoin is a recently developed cryptocurrency specifically created for design and engineering transactions. This currency could help address the difficulties in assigning responsibilities and liabilities due to an overlap of roles and responsibilities, ensuring intellectual property protection, risk allocation, and privacy in the current BIM workflow [22]. Connecting the budget control objects with #AECoin will add many benefits to the BIM process. For instance, #AECoin and the proposed budget control objects can be used to measure the added intrinsic and intangible value of a physical artifact and accurately calculate the rewards earned by the participant by assessing the individual/collaborative project contribution over the product's lifecycle. This concept of monetizing designs throughout the lifecycle would ensure a superior outcome and more effectively motivate engineers and architects to deliver their best efforts by providing proportionate incentives.

BIM workflow and Security
Most industries currently rely on the "security through obscurity" approach to secure engineering, which emphasizes the confidentiality of the implementation and mechanisms of the cybersecurity system. Thus, a small leak of information could potentially endanger the entire network [55]. BIM offers a diverse multifunctional workspace that addresses asset management, performance monitoring, and changes management through the lifecycle, apart from overlooking the planning, design, and construction phases of the structure. To facilitate continuous collaboration among all parties, BIM makes use of Common Data Environment (CDE), which provides a single repository for project information. This repository is used to collect, manage, and distribute data for multi-disciplinary teams [24]. It requires the auditing, monitoring, and tracking of data through the CDE, which will develop throughout the project's lifecycle. Hence, it is vital to provide suitable governance and curation to address information management and uphold data security, quality, and integrity. Since BIM involves complex interactions involving collaborative actions and information exchange between actors, technology and processes, and inter-relationships, it is crucial to consider cyber-security implications, assess current levels of reliability, address current drawbacks, and reinforce security. In current usage, all BIM data are electronically shared across a common data environment. It is essential for all project members to understand and abide by cybersecurity rules [37]. There are fewer trust issues among BIM actors compared to those in traditional information sharing. However, BIM's complicated collaborative framework creates security issues of data leakage, information theft, and information protection while dealing.
Both permissioned and permission-less BCTs have their respective advantages and drawbacks, and the BCT for use must be chosen appropriately based on the desired functionality and level of privacy needed. Concerning BIM workflow, there are generally several different parties working simultaneously on one model. In such cases, implementing a permission-less blockchain could produce positive effects, such as improved communication, transparency of work, and opportunities for collaborative design processes. However, the current socio-economic environment of the AEC industry may necessitate tighter management of permissions due to concerns like data theft, conflicting interests, misuse of information, and others concerns arising from the number of third-parties involved in a typical construction project, which usually entails high levels of copyright, budget, and accountability to government bodies and regulatory entities. Hence, employing a permissioned blockchain is a far more realistic option for most BIM projects. Cybersecurity can be defined as "the collection of tools, policies, security concepts, security safeguards, guidelines, risk management approaches, actions, training, best practices, assurance and technologies that can be used to protect the cyber environment and organization and user's assets" [24]. The cyber environment includes the Internet, telecommunication networks, embedded processors, controllers, sensors, data storage and control devices, as well as the information, services, and collaborative and business functions that only exist in cyberspace.
Cybersecurity threats that can potentially affect BIM workflow. Its connected systems can be classified into three categories: • External threat agents: unconnected malicious outsiders, criminal entities attempting to access data for reconnaissance, hackers, intellectual property theft, the leak of sensitive or confidential information, and malware that can attack the BIM database; • Internal threat agents: involved participants who may bear malicious intent, the abuse of authorized access to steal, leak, or corrupt information to disrupt BIM operations, as well as human errors like omissions, ignorance, or negligence of work; • Systems and business failures: natural causes by extreme weather, interference from animals, storage device failures, poor maintenance of the centralized IT infrastructure, bankruptcies, and business failures.

Advantages of using BCT for Improving Cybersecurity
The elimination of the requirement of a designated intermediary party to oversee data transactions in the network offers several improvements over existent systems in terms of cybersecurity levels. Blockchain networks ensure that no single node in the network has complete access to all the information. Multi-signature (multisig) protection can add another layer of security in authorizing transactions by accepting more than one key. Hackers can gain complete access in the network only if more than 50% of the nodes are compromised [55].
Effective interoperability can be achieved by ensuring the identifiability and authentication of participants and establishing a ubiquitous and secure infrastructure that serves as a repository for data storage, as well as a reliable platform that facilitates data exchange, subject to required permissibility levels. Key features of a blockchain, such as utilizing secure cryptography, asset sharing, auditing trails of data access, and a resilient peer-to-peer network, present a novel and promising emergent method of addressing cybersecurity and collaborative issues. However, it should be noted that the implementation of BCT does not directly ensure infallibility. Further, blockchain can enable a secure and transparent method of Proof of Delivery (PoD) for the transport and delivery of physical assets [33].

Trust
The immutable, instantaneous, and transparent nature of DLT emphasizes compliance and trust between all involved parties on the network. The current economy, which is inherently adversarial, incentivizes the minimal exchange of information between parties involved in the completion of a project with the intention of protecting one's interests. The advent of BCT is increasingly disruptive to the existing paradigm and will shift work culture in a direction that rewards collaboration and proves advantageous in the design process by facilitating better-informed decision making, collaborative learning, and easier debugging of errors. This change can be accelerated by the ability of BCT to reward the intrinsic value of any data through an #AECoin cryptocurrency [21]. Blockchain can facilitate the creation of a registry comprised of past achievements and the qualifications of individuals, with a view toward enabling a comparison of team constellations and thus aiding in the decision-making processes for clients and project managers to select a versatile and well-balanced team with diverse skill sets and experience. The BCT platforms can primarily serve as recordkeeping tools to record changes in the BIM model throughout the design and construction phases of the structure.
Moreover, smart contracts can be programmed to automate awarding or revoking privileges based on the satisfaction of certain terms, as well as store an immutable record of all modifications in the BIM model data, along with other associated information [27]. The tamper-proof append-only nature of the records in a DLT also help to enforce compliance among workers. The transparency of the DLT coupled with the database properties of BIM [27] can introduce an 'evidence of trust' [21], which would create a new value proposition for the AEC industry.

Background
The building authorities' role in post-disaster efforts is to support relief exertions, expedite the inspection of the existing buildings safety, and provide the construction permits for new buildings and retrofitting. In general, these permits are needed if the owner aims to change the size, the structure, or the use of the building. The building authorities use the adopted codes to outline the permissions and the required technical details [75]. Enforcement of the applied building code and design standards in the rebuilding process is obligatory to avoid any imminent destruction, as seen in countries such as Haiti [59]. The permitting process is complicated during post-disaster redevelopment more than pre-disaster development due to the additional responsibilities imposed on the building officials to assess damages and uphold federal and state government requirements.
In response to the challenges and calls to modernize and expedite the local government agencies' operations, the state of Florida has adopted variety of laws to facilitate electronic transactions and establish a legal framework to solve any interstate business disputes; these laws are known by the Electronic Signature Act and the Uniform Electronic Transactions Act (UETA) [76]. The advantages of going digital were explained in Florida statues 668.001. The Building Authorities in Florida have been slow to adopt and benefit from e-business and other innovations in the AEC industry compared to the private sector. The reasons for this reluctancy are the pushback against change and organizational and technical problems. All changes come with costs and impacts [77]. The shift of some Architecture and engineering firms into digital-based operations has reduced the time and costs of delivering their services and products compared to the traditional way.
Several building authorities have learned that changing their traditional paper-based process to an electronic-based process at the time of submitting and reviewing a construction permit is the best way to cope with the statewide growth of the construction industry. This process is known as e-permitting. The county of Osceola in the south central of Florida has launched a new initiative to expedite the permitting process by allowing their customers to use an e-plan submission system. As a result, the participants' stockholders can submit and track their permits online. The county building department is discussing the use of an e-plan system internally with more departments, such as the planning department. This attempt has saved the Osceola building department about 60 hours per month for reviewing the plans. The time to review commercial buildings has been reduced to 10 business days compared to 5 weeks in the past. According to The Alliance for Building Regulatory Reform in the Digital Age, the electronic-based process has not just helped in saving time-it has helped to protect the environment. The impacts of such a process on one of the building departments that issue 3000 permits every year included the reduction of 20,800 gallons of gas, the elimination of 312,000 miles and 12,480 h of driving, the saving of $57,200 for fuel, and the preservation of 239 trees [15,16] In times of disasters, the e-permitting processes can facilitate the ability to review plans from anywhere and anytime. Furthermore, the ability to store the design documents on servers using e-permitting technology can help the first responders have quick access to as-built designs of the collapsed buildings and save people's lives [15] Further advantage for the Jurisdiction's switched to an electronic review process is the ability to conduct a parallel review by multiple departments. Introducing the BLT+BIM framework to e-permitting will yield further benefits, particularly for post-disaster rebuilding efforts.
Nowadays, growing numbers of building code communities are looking for the best way to benefit from the technological evolution of Building Information Modeling (BIM) to streamline the plan review process [15]. The existing plan review systems, such as Solibri and CORENET E-PlanCheck, were the first initiatives that demonstrated the ability to develop a smart review system. However, these systems were limited in their use and can only check the model based on specific codes. This research aims to develop a framework approach for Virtual Permitting Process (VPP) to address post-disaster rebuilding in the state of Florida based on the local construction standards and current building codes.

Automated Code-Checking and Compliance (ACCC) Framework
Regulations are normative texts prescribed by governing entities to enforce constraints to design and engineering processes and manufacturing based on existing conditions and function as the defining text for laws, codes, specifications, standards, etc. Automating or semi-automating code-checking and compliance processes in the AEC industry would benefit the industry by saving time, money, labor, and minimizing the chancefor risk and human errors. While much of the decision-making and consideration of the code is dependent on the experience of the reviewers, automation could at least enforce the upper and lower limits and report results instantaneously. The translation of various clauses and statements into computable language presents a major challenge in achieving automation [78,79]. However, following an ideal framework to develop a tool that successfully accounts for all regulations through an accurate interpretation of formal language and model data exchange could be pivotal in increasing efficiency and upholding safety standards in any AEC projects.
The process tree of an automated rule verification system involves taxonomy development, a logical arrangement of rules, and interpretation in its first phase. This phase is followed by generating building model data and the commencement of information checking. Then, the actual rule compliance verification process is executed, and the results are reported. There are several techniques to translate natural language into a set of rules. There have been developments in Artificial Intelligence, markup document modelling, and hypertext to formulate efficient domain knowledge representation techniques [80][81][82][83][84][85]. Recent research on the ACCC has been focused more on the concept of regulatory text mining and semantic web approaches for creating a computable representation [86][87][88].
Other studies are centered mainly on the automated or semi-automated extraction of information from regulatory texts into rules using Artificial Intelligence (AI) and Natural Language Processing (NLP) [89][90][91][92].
The introduction of the Industry Foundation Classes (IFC) was the most significant data standard for building a model schema [93], since it offered an open-source, flexible, and standardized schema that could interact with many supporting technologies. Taking advantage of the standardized IFC schema to represent BIM model data and the automatable and enforceable properties of smart contracts, ACCC can be carried out in a much more effective, secure, and instantaneous way while instantly transmitting results to various parties [79,94]. Using BCT also negates the need to store all pertinent model checking data in one centralized location.
Clash detection, or clash prevention, is the most frequently employed compliance-checking domain to validate models. This method is popular because of its favorable effort-benefit ratio, which allows the project team members to simultaneously detect discrepancies in the model from design, or detect a clash between two or more facets of the building structure [95]. Most BIM platforms generally provide tools to perform clash detection studies. This technique, however, is limited in that it does not facilitate a comprehensive code review and verification of information-rich content embedded in the BIM objects. A rule-based validation method is, therefore, essential for ACCC to be able to process complex building attributes, design specifications, environmental conditions, and other areas that can be sufficiently validated through visual methods.
The primary objective of developing an efficient framework to automate code-checking and compliance processes is to achieve a computable model with a clear syntax to accurately represent code requirements, reduce model complexity, and develop a unified format to exemplify building regulations and building information modelling [80,81]. The compliance checking process must be secure and collaborative. The following example demonstrates the potential application of the HLF in improving the security and efficiency of the automatic design review process in a BIM workflow.

Proposed Integrative BCT+BIM Framework
To address the issues related to post-disaster rebuilding, this paper introduces new approaches for automating, or semi-automating, the building permit process. These methods are based upon integrating the ACCC with blockchain systems (see Figure 5). The three primary components of the framework are the Generalized Adaptive Framework (GAF) for the ACCC model, as proposed by [82], smart contracts, and blockchain network systems. The BCT proposed for this framework is described below: Buildings 2019, 9, x FOR PEER REVIEW 21 of 32 allows the project team members to simultaneously detect discrepancies in the model from design, or detect a clash between two or more facets of the building structure [96]. Most BIM platforms generally provide tools to perform clash detection studies. This technique, however, is limited in that it does not facilitate a comprehensive code review and verification of information-rich content embedded in the BIM objects. A rule-based validation method is, therefore, essential for ACCC to be able to process complex building attributes, design specifications, environmental conditions, and other areas that can be sufficiently validated through visual methods. The primary objective of developing an efficient framework to automate code-checking and compliance processes is to achieve a computable model with a clear syntax to accurately represent code requirements, reduce model complexity, and develop a unified format to exemplify building regulations and building information modelling [81,82]. The compliance checking process must be secure and collaborative. The following example demonstrates the potential application of the HLF in improving the security and efficiency of the automatic design review process in a BIM workflow.

Proposed Integrative BCT+BIM Framework
To address the issues related to post-disaster rebuilding, this paper introduces new approaches for automating, or semi-automating, the building permit process. These methods are based upon integrating the ACCC with blockchain systems (see Figure 5). The three primary components of the framework are the Generalized Adaptive Framework (GAF) for the ACCC model, as proposed by [82], smart contracts, and blockchain network systems. The BCT proposed for this framework is described below:

(i) Permissioned Blockchain
Given the multidisciplinary nature of a BIM project, with teams who may belong to different organizations, and considering other project participants with varying levels of functions and privileges, a permissioned blockchain is the most suitable BCT for a collaborative BIM environment. Thus, this study proposes the Hyperledger Fabric (HLF), since it relies on a permissioned blockchain. A permissioned blockchain provides a way to protect data exchanges between members of entities who share a mutual goal but have intellectual properties that they need to secure while exchanging information. A permissioned blockchain depends on the identities of its peers, and, thus, they can

(i) Permissioned Blockchain
Given the multidisciplinary nature of a BIM project, with teams who may belong to different organizations, and considering other project participants with varying levels of functions and privileges, a permissioned blockchain is the most suitable BCT for a collaborative BIM environment. Thus, this study proposes the Hyperledger Fabric (HLF), since it relies on a permissioned blockchain. A permissioned blockchain provides a way to protect data exchanges between members of entities who share a mutual goal but have intellectual properties that they need to secure while exchanging information. A permissioned blockchain depends on the identities of its peers, and, thus, they can use traditional Byzantine-fault tolerant (BFT) consensus mechanisms. BFT is a protocol that has been widely used in IT solutions to reach a consensus on the state of faulty nodes in a network.
The HLF is based upon modular and extensible architectures. An example of possible modules that can be plugged in and implemented in the Hyperledger Fabric include (see Figure 6): participating in the blockchain network. It provides a specialized digital certificate authority for issuing certificates to members of the blockchain network. (b) Chaincode services: A chaincode, or a smart contract, is application-level code stored on the ledger as a part of a transaction. The chaincode runs transactions that may modify the data on the ledger. Business logic is written as a chaincode (often in the Go or Java languages). A chaincode is installed on network members' machines, which require access to the asset states to perform read and write operations. The chaincode is then instantiated on particular channels for specific peers. Ledgers are normally shareable across entire networks of peers or include only a specific set of participants. Peers can participate in multiple blockchain channels. (c) Consensus services: These services are at the heart of any blockchain application. They enable a trust system. The consensus service permits digitally signed transactions to be proposed and validated by network members. The consensus is normally pluggable and tightly linked to the endorse-order-validation model that the Hyperledger proposes. The ordering services in HLF represent the consensus system. The ordering service groups multiple transactions into blocks and outputs a hash-chained sequence of blocks containing transactions.
that can be plugged in and implemented in the Hyperledger Fabric include (see Figure 6): (a) Membership services: This module deals with permissioning and serves to create a root of trust during network formation. This module is also vital in managing the identity of members participating in the blockchain network. It provides a specialized digital certificate authority for issuing certificates to members of the blockchain network. (b) Chaincode services: A chaincode, or a smart contract, is application-level code stored on the ledger as a part of a transaction. The chaincode runs transactions that may modify the data on the ledger. Business logic is written as a chaincode (often in the Go or Java languages). A chaincode is installed on network members' machines, which require access to the asset states to perform read and write operations. The chaincode is then instantiated on particular channels for specific peers. Ledgers are normally shareable across entire networks of peers or include only a specific set of participants. Peers can participate in multiple blockchain channels. (c) Consensus services: These services are at the heart of any blockchain application. They enable a trust system. The consensus service permits digitally signed transactions to be proposed and validated by network members. The consensus is normally pluggable and tightly linked to the endorse-order-validation model that the Hyperledger proposes. The ordering services in HLF represent the consensus system. The ordering service groups multiple transactions into blocks and outputs a hash-chained sequence of blocks containing transactions. A transaction in Hyperledger is simply a request to the blockchain to invoke a function on the ledger. The function is implemented by a chaincode (smart contract). Cryptography ensures the integrity and security of transactions by linking the transaction to previous blocks and linking the cryptogram or hash from previously linked blocks. Each channel in HLF is its own blockchain. A smart contract functions as a trusted, distributed application and gains its security from the blockchain and the underlying consensus among its network nodes. The SDK (Software Development Kit) enables the development of applications that deploy and invoke transactions on a shared ledger. Currently, the Hyperledger Fabric supports both Node.js and Java SDK. The SDKs are critical in blockchain application development. With an SDK, one can create the application client, chaincode, users, and events in the HLF. A transaction in Hyperledger is simply a request to the blockchain to invoke a function on the ledger. The function is implemented by a chaincode (smart contract). Cryptography ensures the integrity and security of transactions by linking the transaction to previous blocks and linking the cryptogram or hash from previously linked blocks. Each channel in HLF is its own blockchain. A smart contract functions as a trusted, distributed application and gains its security from the blockchain and the underlying consensus among its network nodes.
The SDK (Software Development Kit) enables the development of applications that deploy and invoke transactions on a shared ledger. Currently, the Hyperledger Fabric supports both Node.js and Java SDK. The SDKs are critical in blockchain application development. With an SDK, one can create the application client, chaincode, users, and events in the HLF.
This study suggested a structure that stores building codes rules and BIM model data off-chain and facilitates the chaincode to function as the model checker and building permit issuer. The details of this mechanism include: (a) The building codes or regulations upon which the BIM model data are to be examined must be processed into a computable language. A smart contract (chaincode) can be programmed to process the rules from a natural language using GAF [81]. This contract must be defined carefully to account for all clauses, terms, and variables used in the building code and regulations. After transformation of the rules, the smart contract generates a second appended smart contract that can now be used by the model checker. If the smart contract's capabilities do not support adequate levels of semantic enrichment, the rules can be directly expressed in the scripting languages. (b) The BIM model data are exported from the platform in IFC format (ifcXML) and accessed using the scripting language, such as Java or Go, employed by the smart contract platform. The BIM model data file is now generated and used as off-chain data. (c) A model checker is programmed in the form of another smart contract that can extract information from the BIM model data upon calling and verify that information against the translated rules created in step (a). (d) The model checker invokes the code-checking functions and creates another smart contract where the results are reported and sent to an authority to confirm the final permit.
(ii) External Oracles Governing authorities, legislative bodies, and licensing entities can use external oracles to force an external state into the programmed chaincode. The concerned party can directly force the rules required to validate the building model using a smart contract containing the building model data expressed in a scripting language and can view output results directly. External oracles can also be used to directly append changes and updates in existing building codes and regulations that are present in the form of smart contracts.

(iii) Sidechains or Cross-Chain bridges
A sidechain is a mechanism that can provide a solution to address the scaling issue that is essentially a hierarchy of lower tier consensus instances [96], which can provide a lower degree of decentralization. A sidechain is a blockchain that runs in parallel to the main blockchain, which extends its functionality through interoperable blockchain networks, permitting a decentralized method of transactions between the two chains. Figure 7 exemplifies the model of the sidechain data processing framework.
This study suggested a structure that stores building codes rules and BIM model data off-chain and facilitates the chaincode to function as the model checker and building permit issuer. The details of this mechanism include: a) The building codes or regulations upon which the BIM model data are to be examined must be processed into a computable language. A smart contract (chaincode) can be programmed to process the rules from a natural language using GAF [82]. This contract must be defined carefully to account for all clauses, terms, and variables used in the building code and regulations. After transformation of the rules, the smart contract generates a second appended smart contract that can now be used by the model checker. If the smart contract's capabilities do not support adequate levels of semantic enrichment, the rules can be directly expressed in the scripting languages. b) The BIM model data are exported from the platform in IFC format (ifcXML) and accessed using the scripting language, such as Java or Go, employed by the smart contract platform. The BIM model data file is now generated and used as off-chain data. c) A model checker is programmed in the form of another smart contract that can extract information from the BIM model data upon calling and verify that information against the translated rules created in step (a). d) The model checker invokes the code-checking functions and creates another smart contract where the results are reported and sent to an authority to confirm the final permit.
(ii) External Oracles Governing authorities, legislative bodies, and licensing entities can use external oracles to force an external state into the programmed chaincode. The concerned party can directly force the rules required to validate the building model using a smart contract containing the building model data expressed in a scripting language and can view output results directly. External oracles can also be used to directly append changes and updates in existing building codes and regulations that are present in the form of smart contracts.

(iii) Sidechains or Cross-Chain bridges
A sidechain is a mechanism that can provide a solution to address the scaling issue that is essentially a hierarchy of lower tier consensus instances [97], which can provide a lower degree of decentralization. A sidechain is a blockchain that runs in parallel to the main blockchain, which extends its functionality through interoperable blockchain networks, permitting a decentralized method of transactions between the two chains. Figure 7 exemplifies the model of the sidechain data processing framework.

A Case Study
This example depicts a higher-level framework for implementing the proposed approach described in the previous section. This case study assumes that a BIM model has been developed for new construction after a disaster. Figure 8 illustrates the instances of invoking the proposed framework in post-disaster recovery efforts. Sharing BIM data will enable building departments to receive 3D and other building designs and component data that can be used to expedite the electronic plan review and field inspections while facilitating the exchange of BIM data with neighboring jurisdictions, should the need arise during a future disaster or post-disaster event. This example depicts a higher-level framework for implementing the proposed approach described in the previous section. This case study assumes that a BIM model has been developed for new construction after a disaster. Figure 8 illustrates the instances of invoking the proposed framework in post-disaster recovery efforts. Sharing BIM data will enable building departments to receive 3D and other building designs and component data that can be used to expedite the electronic plan review and field inspections while facilitating the exchange of BIM data with neighboring jurisdictions, should the need arise during a future disaster or post-disaster event.

REBUILDING
Integrative BCT+BIM Framework Using the proposed integrative BCT+BIM framework, the BIM model data and the building code regulations are encrypted using BCT. The chaincode (containing a set of key-value pairs representing the initial state of the BIM model) is saved on the peer's computers (nodes) participating in the HLF and invoked on the channel. The chaincode contains logic defining a set of data exchange instructions and any agreed upon financial terms. An endorsement policy has also been set for this chaincode, stating that both node X and node Y must endorse any transaction [51]. A smart contract can be created using a Turing-complete programming language (C# or Java). This contract consists of information relating to the compliance checking of model data against regulations, the order in which it is carried, and the corresponding output. This contract is also discretized and encrypted into blocks. Thus, this method is secure, fast, discrete and efficient in that it records every code-checking transaction in the permanent ledger, and the information is available for peer viewing.

(i) Initiate a Data Exchange
Architect or homeowner A is sending a request to the building department to review the design and issue a building permit (R) for the project. The request includes a BIM model for the project. The request targets node A and node R, who are, respectively, representative of architect or owner (A) and building reviewers (R). The endorsement policy states that both members of the network must endorse any transaction. Therefore, the request is sent to node A and node R. The next step is to construct a transaction request. This is achieved by leveraging a supported Software Development Kit (SDK) (using Java, Go, etc.) that uses one of the available Application Programming Interfaces (APIs), creating a data exchange proposal. The proposal is a request to invoke a chaincode function so that data can be read and written to the ledger. With the help of the HLF SDK, the transaction proposal is transformed into a proper format utilizing the user's cryptographic credentials to generate a unique signature for this transaction request (see Figure 9). Using the proposed integrative BCT+BIM framework, the BIM model data and the building code regulations are encrypted using BCT. The chaincode (containing a set of key-value pairs representing the initial state of the BIM model) is saved on the peer's computers (nodes) participating in the HLF and invoked on the channel. The chaincode contains logic defining a set of data exchange instructions and any agreed upon financial terms. An endorsement policy has also been set for this chaincode, stating that both node X and node Y must endorse any transaction [51]. A smart contract can be created using a Turing-complete programming language (C# or Java). This contract consists of information relating to the compliance checking of model data against regulations, the order in which it is carried, and the corresponding output. This contract is also discretized and encrypted into blocks. Thus, this method is secure, fast, discrete and efficient in that it records every code-checking transaction in the permanent ledger, and the information is available for peer viewing.

(i) Initiate a Data Exchange
Architect or homeowner A is sending a request to the building department to review the design and issue a building permit (R) for the project. The request includes a BIM model for the project. The request targets node A and node R, who are, respectively, representative of architect or owner (A) and building reviewers (R). The endorsement policy states that both members of the network must endorse any transaction. Therefore, the request is sent to node A and node R. The next step is to construct a transaction request. This is achieved by leveraging a supported Software Development Kit (SDK) (using Java, Go, etc.) that uses one of the available Application Programming Interfaces (APIs), creating a data exchange proposal. The proposal is a request to invoke a chaincode function so that data can be read and written to the ledger. With the help of the HLF SDK, the transaction proposal is transformed into a proper format utilizing the user's cryptographic credentials to generate a unique signature for this transaction request (see Figure 9).  Figure 9. Data exchange initiation between an architect (owner) and building authority.
(ii) Verify and Execute The endorsing nodes in the channel verify that: (a) the transaction proposal is well formed, (b) it has not been submitted previously (replay-attack protection), (c) the signature is valid (using MSP), and (d) that the submitter (Architect A, in the example) is accurately approved to accomplish the proposed operation on that channel (i.e., the submitter satisfies the channel's writer policy (the writing policy specifies, at the time of channel creation, which user is permitted to submit a transaction to that channel).
The nodes consider the transaction request inputs as arguments to the invoked chaincode's function (see Figure 10). The chaincode is then executed against the current state database to generate transaction results (including a response value), read the dataset, and updating dataset. No updates are made to the ledger at this point. This result, along with the endorsing node's signature, is conveyed back as a proposal response to the SDK, which parses the information for the application to process.

(iii) Request Authentication
The application validates the nodes' signatures and examines the request responses to see if the responses are the correct ones. The chaincode will then process the request and send it to the respective parties for further processing (see Figure 11). This can occur, for instance, when requests for an input from the zoning department are needed to verify the site location of the project. The system is generally built in such a way that even if an application decides not to verify responses, or otherwise forwards an unauthorized transaction, the endorsement policy will still be enforced by the nodes and maintained at the validation phase before writing results to the ledger.

Channels
Transactions Results -Code Checking Reports (ii) Verify and Execute The endorsing nodes in the channel verify that: (a) the transaction proposal is well formed, (b) it has not been submitted previously (replay-attack protection), (c) the signature is valid (using MSP), and (d) that the submitter (Architect A, in the example) is accurately approved to accomplish the proposed operation on that channel (i.e., the submitter satisfies the channel's writer policy (the writing policy specifies, at the time of channel creation, which user is permitted to submit a transaction to that channel).
The nodes consider the transaction request inputs as arguments to the invoked chaincode's function (see Figure 10). The chaincode is then executed against the current state database to generate transaction results (including a response value), read the dataset, and updating dataset. No updates are made to the ledger at this point. This result, along with the endorsing node's signature, is conveyed back as a proposal response to the SDK, which parses the information for the application to process.  Figure 9. Data exchange initiation between an architect (owner) and building authority.
(ii) Verify and Execute The endorsing nodes in the channel verify that: (a) the transaction proposal is well formed, (b) it has not been submitted previously (replay-attack protection), (c) the signature is valid (using MSP), and (d) that the submitter (Architect A, in the example) is accurately approved to accomplish the proposed operation on that channel (i.e., the submitter satisfies the channel's writer policy (the writing policy specifies, at the time of channel creation, which user is permitted to submit a transaction to that channel).
The nodes consider the transaction request inputs as arguments to the invoked chaincode's function (see Figure 10). The chaincode is then executed against the current state database to generate transaction results (including a response value), read the dataset, and updating dataset. No updates are made to the ledger at this point. This result, along with the endorsing node's signature, is conveyed back as a proposal response to the SDK, which parses the information for the application to process.

(iii) Request Authentication
The application validates the nodes' signatures and examines the request responses to see if the responses are the correct ones. The chaincode will then process the request and send it to the respective parties for further processing (see Figure 11). This can occur, for instance, when requests for an input from the zoning department are needed to verify the site location of the project. The system is generally built in such a way that even if an application decides not to verify responses, or otherwise forwards an unauthorized transaction, the endorsement policy will still be enforced by the nodes and maintained at the validation phase before writing results to the ledger.

Channels
Transactions Results -Code Checking Reports

(iii) Request Authentication
The application validates the nodes' signatures and examines the request responses to see if the responses are the correct ones. The chaincode will then process the request and send it to the respective parties for further processing (see Figure 11). This can occur, for instance, when requests for an input from the zoning department are needed to verify the site location of the project. The system is generally built in such a way that even if an application decides not to verify responses, or otherwise forwards an unauthorized transaction, the endorsement policy will still be enforced by the nodes and maintained at the validation phase before writing results to the ledger.
The application validates the nodes' signatures and examines the request responses to see if the responses are the correct ones. The chaincode will then process the request and send it to the respective parties for further processing (see Figure 11). This can occur, for instance, when requests for an input from the zoning department are needed to verify the site location of the project. The system is generally built in such a way that even if an application decides not to verify responses, or otherwise forwards an unauthorized transaction, the endorsement policy will still be enforced by the nodes and maintained at the validation phase before writing results to the ledger.

Channels
Transactions Results -Code Checking Reports (iv) Assemble Replies The blocks of data are then validated and transmitted to all nodes on the channel of the network. The validation process also ensures that there have been no changes to the ledger state, and blocks are marked as being valid or invalid.
Then, the application will transmit the transaction proposal and response within a transaction message to the correct code checking services, which can consist of several chaincodes. The transaction will contain the read/write datasets, the endorsing nodes' signatures, and the Channel identification ID. Then, the application will build up the blocks of the code's compliance, checking transactions per channel (see Figure 12). (iv) Assemble Replies The blocks of data are then validated and transmitted to all nodes on the channel of the network. The validation process also ensures that there have been no changes to the ledger state, and blocks are marked as being valid or invalid.
Then, the application will transmit the transaction proposal and response within a transaction message to the correct code checking services, which can consist of several chaincodes. The transaction will contain the read/write datasets, the endorsing nodes' signatures, and the Channel identification ID. Then, the application will build up the blocks of the code's compliance, checking transactions per channel (see Figure 12).  (v) Validation and Transmission

Code Compliance
The blocks of data are then validated and transmitted to all peers on the channel of the network. The validation process also ensures that there have been no changes to the ledger state, and blocks are marked as being valid or invalid.
(vi) Updating the Database The blocks will be appended from each node in the channel for valid blocks and written to the current state of the ledger (see Figure 13). After the transaction is committed to the database, an event is invoked to notify the Architect or the owner (A) that the reply from the building review authority (R) transaction has been appended to the chain, and the owner or the Architect can take further actions.

Conclusions
The blocks of data are then validated and transmitted to all peers on the channel of the network. The validation process also ensures that there have been no changes to the ledger state, and blocks are marked as being valid or invalid.
(vi) Updating the Database The blocks will be appended from each node in the channel for valid blocks and written to the current state of the ledger (see Figure 13). After the transaction is committed to the database, an event is invoked to notify the Architect or the owner (A) that the reply from the building review authority (R) transaction has been appended to the chain, and the owner or the Architect can take further actions.
(vi) Updating the Database The blocks will be appended from each node in the channel for valid blocks and written to the current state of the ledger (see Figure 13). After the transaction is committed to the database, an event is invoked to notify the Architect or the owner (A) that the reply from the building review authority (R) transaction has been appended to the chain, and the owner or the Architect can take further actions.

Conclusions
This paper presents a comprehensive survey of BCT and its applications in the built environment and examines BCT's potential integration with Building Information Modeling (BIM) workflow. This study examines how commissioning distributed ledger technology (DLT), such as the Hyperledger Fabric (HLF), could be advantageous in the BIM working processes by reinforcing network security,

Conclusions
This paper presents a comprehensive survey of BCT and its applications in the built environment and examines BCT's potential integration with Building Information Modeling (BIM) workflow. This study examines how commissioning distributed ledger technology (DLT), such as the Hyperledger Fabric (HLF), could be advantageous in the BIM working processes by reinforcing network security, providing more reliable data storage and management of permissions, and ensuring change tracing and data ownership.
The building permitting process is more complicated during post-disaster redevelopment than pre-disaster development, due to the additional responsibilities imposed on the building officials to assess damages and uphold federal and state government requirements. The process is often characterized by a longer duration, which adversely affects the rebuilding efforts. The proposed BCT+BIM framework has the potential to enchance the permitting process and positively impact post-disaster recovery efforts.
The present example indicates that the application of BCT in a BIM workflow creates a system that is built on the principles of decentralization, open governance (or self-governance), and transparency, a system that rewards innovation and eradicates disintermediation. Moreover, such systems provide the secure execution of BIM data exchanges and validation through privacy and trust mechanisms, in a secure process that facilities speedy, robust transactions. The cryptographically enforced interconnectivity in the blockchain applications fosters the stability and security of distributed ledgers.
HLF is a BCT that is particularly suited for developing the automation of code-checking compliances (ACCC) in BIM workflows, due to its ease of programming (using SDK), flexibility, user-defined smart contract (chaincode), robust security, identity features, and modular architecture with pluggable consensus protocols. The example presented depicts that the smart contract technologies (also known as chaincodes) available in HLFs are promising technologies for advancing the security and efficiency in the AEC industry, particularly for post-disaster recovery. The removal of an overseeing third-party in the proposed BCT+BIM as an essential actor in any transaction related to post-disaster rebuilding could lead to significant savings by negating processing fees, paperwork, and the time needed to issue building permits. Moreover, the proposed integrative BCT+BIM framework aims to provide transparency and secure network services without interruption during the process of rebuilding after a disaster. In this framework, the HLF can address many of the current concerns, such as data security, privacy, the speed of transactions, and change tracing and permission management that arise from using centralized BIM work processes. Future research will focus on expanding the integrative framework to include other issues related to post-disaster recovery efforts, such as infrastructures and services.