A blockchain-based integrated document management framework for construction applications

Abstract

Document management systems in AEC projects manage important project documents such as schedules, RFIs, and change orders. Hence, security concerns in document management systems especially involving data integrity of documents and records may have a severe effect on a project in terms of money and the reputations of project participants. Therefore, in this research blockchain technology is leveraged to facilitate data integrity in document management for construction applications through - (1) irreversible and irrevocable approval workflow logic via smart contract technology, (2) irreversible recording of document changes via blockchain ledger technology, and (3) document version history integrity via a blockchain-based data structure. A prototype of the proposed smart contract framework was developed using Hyperledger fabric and evaluated. The scalability of the proposed framework to support document version integrity was also evaluated and discussed. A formulation based on existing literature is developed to evaluate the cost viability of the proposed framework.

Full text

1
A Blockchain-based Integrated Document Management Framework for Construction
Applications
Authors: Moumita Das, Xingyu Tao, Yuhan Liu, Jack C. P. Cheng*
Highlights
• A smart contract logic to facilitate integration via customizable document approval workflows
is developed.
• A data structure to securely record document version history is developed.
• A blockchain ledger data model to securely record document lifecycle is developed.
• An example scenario and prototype evaluation of the proposed framework are presented.
Abstract
Document management systems in AEC projects manage important project documents such as
schedules, RFIs, and change orders. Hence, security concerns in document management systems
especially involving data integrity of documents and records may have a severe effect on a project in
terms of money and the reputations of project participants. Therefore, in this research blockchain
technology is leveraged to facilitate data integrity in document management for construction
applications through - (1) irreversible and irrevocable approval workflow logic via smart contract
technology, (2) irreversible recording of document changes via blockchain ledger technology, and (3)
document version history integrity via a blockchain-based data structure. A prototype of the proposed
smart contract framework was developed using Hyperledger fabric and evaluated. The scalability of the
proposed framework to support document version integrity was also evaluated and discussed. A
formulation based on existing literature is developed to evaluate the cost viability of the proposed
framework.
Keywords: Blockchain, Distributed Ledger, Document Management System, IPFS, Security, Smart
Contracts
1. Introduction
Project documents are written or visual instructions that define the scope of AEC (Architecture,
Engineering, and Construction) projects and hence are critical to successful project delivery. AEC
Projects contain hundreds of project documents such as specifications, quality control documents,
progress monitoring documents, and correspondence. Therefore, document management
systems/methods are highly important in AEC projects. Document management systems aid in
document management, i.e. management document generation, storage, updating, and distribution for

2
faster and streamlined collaboration among project stakeholders. The primary functions of document
management systems in AEC projects can be summarized as [30,73], - (1) approval workflow
management i.e., facilitating customizable document approval workflows in which project participants
are connected using pre-defined business rules to support processes such as design review and RFI
(Request for Information) management, (2) ‘document lifecycle recording’, i.e. establishing ‘audit logs’
to help project comply with standard guidelines and monitor potential problems, (3) ‘document version
management, i.e. storing, categorizing, and distributing different versions of various project documents.
The existing document management systems in the AEC industry include paper-based document
management methods (in small and medium-sized organizations in certain countries) which are tedious
and highly inefficient [3]. Electronic document management systems are more popular, instances of
which are widely found in literature and commercially. Caldas and Soibelman [8] proposed an SVM-
based framework to classify unstructured construction documents according to standard construction
information classification systems such as CSI MasterFormat [14]. Park et al. [58] proposed an
ontology-based document management system to facilitate a consistent vocabulary amongst multi-
disciplinary project participants of AEC projects. Moon et al. [52] proposed a document management
system using text-mining algorithms for automatically grouping and searching construction documents.
Guo et al. [30] presented a study involving the selection criteria for electronic document management
systems for the transportation construction industry. Hajjar and Abourizk [31] proposed a data model
to integrate construction site data with then-existing electronic document management systems. Opitz
et al. [3] proposed a document-to-object linked data model to develop an integrated BIM-based
document management system using embedded description document metadata. Investigation on real-
time data-supported structured document management systems was conducted by Cha and Lee [12] in
the year 2018. Commercial document management platforms such as SharePoint [50] and IBM
Connections [36] prevalent in industries such as manufacturing and IT, were also investigated for AEC
projects but were found unsuitable mainly because of the temporary and fragmented nature of AEC
projects [29]. Other commercial document management systems developed specifically for AEC
projects include BIM 360 [5] and Aconex [57] with cloud-based and on-premise deployment options
[73]. In addition to document management systems, SMEs also use cloud based repositories such as
Dropbox for document storage and distribution [18].
However, the existing approaches to document management in AEC projects suffer from the lack of
methods supporting integration and security. In construction projects, documents are generated as a
result of several discontinuous processes such as design collaboration, submission management,
tendering, RFI management, and work order management over the life cycle of a project [38]. These
documents are needed to be distributed amongst various project teams on-demand who require them in
their individual tasks [27]. In construction projects, the project stakeholders depend on each other for

3
information but are not contracted amongst themselves, thus leaving project document security to trust
in relationships and unexpressed agreements [24]. As a result, peripheral project participants such as
sub-contractors and external bodies (such as government organizations in submission review), have
difficulties in verifying the integrity of processes and project documents [75]. The existing document
management systems (common data environments such as BIM 360) mainly cater to key project
participants, hence leaving out smaller project participants and local information silos. The current
practice among small and medium-sized enterprises is to use cloud-based repositories such as Dropbox
and emails instead of document management systems [18] due to the high cost of investment of
document management systems [30]. Therefore, a transparent and traceable framework that can easily
integrate all the project participants and local information silos, repositories, and communication and
facilitate the functionalities of the document management framework in a secure manner is necessary.
This framework should have certain security facilitating features supporting the functionalities of
typical document management systems.
Firstly the document management framework should support secure information management
workflows. Security in document approval workflows refers to user authenticity, i.e., the ability to
authenticate the identity of various document approvers correctly, control, i.e. ascertaining the
workflow sequence through an irreversible and transparent workflow logic, and auditability, i.e. the
ability to record workflow events in an irreversible manner to ascertain accountability [54]. In current
practice, contractual clauses and risk mitigation instruments are added to ensure the security of
document workflows [41]. However, it does not completely prevent the problem and often leads to
disputes and litigation. Therefore, robust technical solutions in parallel to contractual obligations are
also necessary to ensure security and functional requirements of information approval workflows in the
existing methods of document management in AEC projects. Secondly, documents are modified by
different processes such as design review and RFIs in AEC projects [38]. Therefore, it is necessary to
record document lifecycles for purposes of audit and quality control [54]. Thirdly, the existing
approaches to document management systems lack version security which means, it is possible to
modify or delete document version records without leaving a trail. In addition, SMEs t hat use cloud-
based repositories cannot employ methods for version management that can ensure security and
integration of documents. Therefore, a system that can integrate documents and document -related
information (metadata) from existing document management systems, cloud-based repositories, and
methods of correspondence and also provide security against data tampering is much desired.

4
Blockchain is a technology of distributed ledgers that removes the role of central administrators
and runs with the consent of multiple peer members [72]. Blockchain deploys cryptographic methods
and decentralized consensus mechanisms to ensure data recording in an irreversible manner [72].
Blockchain is also programmable via smart contract technology that can deploy customized rules on
blockchain to regulate and update blockchain ledgers. Blockchain platforms in existing literature are
primarily of two types – (1) public blockchain platform contracts and (2) permissioned blockchain smart
platforms. The consensus mechanisms of public blockchain such as PoW (Proof-of-Work) are
computationally expensive, however are more decentralized compared to the consensus mechanism of
permissioned blockchain platforms. For example, the PBFT (Practical Byzantine Fault Tolerance)
based consensus Hyperledger fabric (permissioned) is more vulnerable to attacks such as intentional
fork attacks as an Ordering Service node is responsible for verifying and adding blocks [17]. Moreover,
the fault tolerance (% adversarial computational power for a successful attack) of public blockchain
smart contracts with probabilistic consensus algorithms like PoW and PoS (Proof-of-Stake) is 50%
compared to 33% [11] and 20% [16] for permissioned blockchain platforms using PBFT and Ripple
respectively [78].
This paper deploys blockchain technology to develop a secure document management system to
integrate project participants and document/record silos and impart security of data irreversibility and
data integrity. In particular, the proposed document management system includes - (1) blockchain-based
smart contract framework to facilitate customized and secure document approval workflows, (2)
blockchain-based secure ledger data model to facilitate the irreversible recording of document lifecycle
(change records) for audit logging and monitoring, and (3) a modified Merkle-Patricia Trie (MPT)
based data structure to facilitate irreversible document version history. The smart contract framework
is designed to facilitate customized document approval workflows by selecting the number of workflow
steps, roles, and actions as per the requirements of an organization. The customizability of workflow
allows project managers to define document approval workflows at the beginning of a project according
to organizational policies that may vary from project to project. The smart contract workflow may be
deployed on top of existing document management systems or cloud-repositories, hence facilitating
integration. Since the smart contract logic is blockchain-based, it is irreversible by users as well as the
administrators of document management systems. The distributed ledger data model is recorded
document lifecycles using document metadata [23,48,56] to support the smart contract-based
information approval workflow. The ledger data model also provides an integrated platform on top of
document management systems or cloud repositories for document lifecycle recording in an irreversible
manner for monitoring or quality control at a later stage. The modified MPT-based data structure is

5
designed to map document lifecycle records (on the blockchain ledger) with document identifiers to
facilitate document version integrity i.e., the assurance that the contents of document version and
version history are untampered. The functions of the proposed document management framework
including integration and security is demonstrated via an example scenario. A prototype was developed
using Hyperledger fabric and evaluated for efficiency and scalability. The scalability of the proposed
framework is also qualitatively analyzed and discussed.
The remaining paper is structured as follows: Section 2 presents a literature review of existing
approaches using blockchain technology for information management. Section 3 presents the key
technologies used to develop the proposed framework. A Section 4 describing the overall methodology
of this paper is presented. In Section 5, the various components of the proposed framework are presented.
This is followed by an example scenario, prototype development, and evaluation of the proposed
framework in in Section 6. Section 7 evaluates the proposed framework and presents results. A
discussion is presented in Section 8 and the paper is concluded in Section 9.
2. Literature Review
Application of blockchain in authenticating digital videos [35], securing decentralized AI applications
[39], securing applications of 5G [13,51], and IoT [40] networks is widely found in the existing
literature. For the construction industry, blockchain has found initial application in tracking changes
[69], measuring construction productivity [37], pre-cast supply chain management [71], and contract
management [70] in research. Feasibility analysis of applying blockchain to regulate project bank
accounts [45], BIM models [79], and Common Data Environments [59] can be found in active research.
For AEC projects, blockchain’s potential to facilitate BIM adoption through consistent and hacking-
resistant design records has been investigated. Nawari et al. [55] emphasized on the advantages of in
BIM workflows. Elghaish et al. [22] supported the potential of blockchain in BIM-based change
recording and increasing traceability. Salah et al. deploy blockchain-based smart contracts to govern
and control interactions and transactions among the participants of an agricultural supply chain to
improve traceability [64]. Hasan and Salah [34] developed a blockchain-based proof of delivery
solution of shipped physical items that trace activities, logs, and events in a decentralized manner. Erri
et al. [24] adopted a design science research based methodology to discuss the potential of blockchain
technologies in information exchange in construction processes. They have evaluated the suitability of
blockchain technologies by implementing a prototype using simulated project and dispute scenarios.
Yang et al. [75] explored the feasibility of public and private blockchain systems in construction
industry using industry cases. Although their study is limited to specific business cases and blockchain
platforms, they have discussed the advantages, limitations, and challenges of adopting blockchain
technology for construction uses. Hargaden et al. [33] explored smart contract applications for
integrating blockchain technology with BIM and information management. Dounas and Lombardi [21]
implemented a prototype demonstrating the connection between CAD applications and blockchain

6
technologies using the Ethereum platform. Their study is limited to implementation scenarios for design
authoring and could be extended to cover project lifecycle records. Liu et al. [46] proposed a two-level
framework to demonstrate the applications of integrating BIM with blockchain technology for
sustainable design coordination and collaboration. Singh and Ashuri [65] proposed a blockchain
framework to track design lifecycle by blockchaining design commands and events. Zheng et al. [79]
proposed a model for facilitating tracing and authentication of BIM historical records using blockchain
to secure BIM data audit. Xue and Lu [74] proposed a scalable framework for BIM change recording
using semantic differential transactions. Hamledari and Fischer [32] developed an autonomous payment
administration solution using blockchain enabled smart contracts. They implemented their prototype in
two real world commercial projects demonstrating elimination of reliance on current intermediated
payment applications. In the existing literature, investigation on securing and facilitating document
lifecycle tracking and management for construction applications is an area that is not thoroughly
investigated. Therefore, in this paper, the functional and security related problems of document
management for construction application is investigated and a framework using key technologies such
as blockchain and cryptographical data structures (introduced in Section 3) is proposed in Section 5.
3. Key Technologies
3.1 The Blockchain Technology
Blockchain is the technology of secure distributed ledgers that underlies cryptocurrencies such as
Bitcoin [53] and Ether[72]. Technologies such as cryptography and peer-to-peer networking are
deployed by blockchain to verify and synchronize records among distributed peers without a
centralized administrator [47]. Figure 1 shows the system architecture of a blockchain platform
consisting of distributed peer nodes connected through a peer-to-peer network. The core idea of the
blockchain network is decentralization which means blockchain is distributed over a network of
nodes. Each node verifies the actions of other entities in the network, as well as can create,
authenticate and validate the new transaction to be recorded in the blockchain. This decentralized
architecture ensures robust and secure operations on the blockchain with the advantages of tamper
resistance and no single-point failure vulnerabilities. As shown in Figure 1, every peer node consists
of (1) a distributed ledger and (2) smart contracts.

7
Figure 1 Architecture of Blockchain Platforms
The distributed ledger consists of a collection of data blocks (as shown in Figure 1). The security of the
ledger comes from its structure where every block is linked to its previous block through hash values.
The hash values are created using “hash” functions which convert contents of any length into a 256-bit
long unique value [9]. Therefore, to corrupt a block, all blocks that precede it must be manipulated,
which is difficult as blocks are added based on collective consensus algorithms that involve multiple
peer members. Smart contracts are customizable executable codes that can be used to deploy business
rules for the addition of blocks for an application. Smart contract languages such as Solidity [26] are
object-oriented languages with pre-defined methods to facilitate functions such as cryptographic
verification, storing data on a blockchain, libraries for using digital signatures and hashing.
In this paper, the potential of blockchain to facilitate integration and security in document management
in AEC projects is investigated. A smart contract logic and a blockchain ledger data model to create
customized information approval workflow and document lifecycle recording are developed.
3.2 Cryptographic Data Structures for Proving Data Integrity
In this paper, cryptographic structures based on Radix trees [44] and Merkle trees [67] are deployed to
facilitate verification of document version history. A radix tree is an efficient data structure for storing,
indexing, and retrieving in-memory data that goes through a lot of updates [44]. As shown in Figure 2,
data in a radix tree is stored in a key-value format, where the “key” consists of a group of non-leaf nodes
arranged in lexicographical order whereas the “value” is the lead node which is led to by the key path.

8
Figure 2 shows a case or model that can be used to store a radix tree in a key-value database such as
LevelDB [28].
Figure 2 Example shows the Data Structure of Radix trees
Unlike other in-memory tree-like data structures such as T-tree and variants of B+ trees [62] which
require complete rearrangement of the index structure with every update, the radix tree grows
horizontally and hence are less expensive computationally. The reason behind its high performance is
the shallow depth of the tree data structure. Therefore, for environments with a large number of datasets
(n), the radix tree is very efficient as the length of keys (k) does not grow as fast as the number of
datasets. Hash tables [66] are another popular in-memory data structure that is very fast and has almost
constant search time. However, they are seldom used for indexing as they are not suitable for range
queries.
The second type of tree data structure used in the proposed framework is Merkle Tree. Merkle trees use
a deterministic encryption mechanism, known as “hash” functions in general, which irreversibly
converts contents of any length into a unique 256-bit value [9]. As shown in Figure 3, a Merkle tree
consists of leaf nodes that are hash values of their data content and non-leaf nodes that are hash values
of their child nodes.

9
Figure 3 Data structure of a Merkle Tree and its Property to Prove Data Integrity
The property of a Merkle tree that can be used to prove the completeness and consistency of a data set
in a distributed environment is demonstrated in Figure 3. As shown in the figure, an update in a Merkle
tree is facilitated by horizontally incrementing the tree and maintaining references to old unmodified
nodes. In a distributed environment, the integrity of updated data can be verified from its corresponding
root hash value as shown in Figure 3. For example, the integrity of dataset “9” can be verified if a user
can produce the “new root” using the elements “H4”, “H12”, and “H5678” (as shown in Figure 3).
Merkle Patricia Tries (MPT)[72] are key-value-based indexing data structures that combine the
properties of Merkle trees [67] and Radix trees [44] to quickly generate cryptographic proofs of data
integrity and to perform efficient data searching respectively. It is particularly suitable for supporting
distributed applications in which records are frequently updated via incremental growth requiring no
complete reconstruction (unlike variants of B+ trees [43,62], which require reconstruction with every
update). Applications of MPTs can be widely found in popular blockchain platforms such as Ethereum
[72], for cloud verification[49], and privacy-preserving authentication in vehicular networks [6].
In the proposed framework, the data structure of MPT is modified to record document version history
by deploying document IDs (created using Omniclass definitions) as a key and content identifier of
document versions as value. Unlike the existing implementations of MPT, the values of documents
from the same versions are linked together in the modified MPT so that the integrity of document
version history can be protected and proven.
4. Methodology
In this paper, a Design Science research (DSR) philosophy for the development and evaluation of the
proposed document management framework. DSR is a philosophy that focuses on the development and
Data Structure of Merkle Tree
H(x) = deterministic hash function
Space Efficient Updates and Data Verification
Old Root
New Root
Old data
New data

10
performance of artifacts (scientific solutions) with the intension of improving the functional
performance of the artifact [24,60]. The objective of DSR is not develop optimal solutions and instead
aims to provide a satisfactory solution to a problem in its context [24]. In this paper, a design science
research process model described by Peffers et al [60] is adopted. Table 1 outlines the steps taken in
this paper as part of the research strategy described by Peffers et al. [60]. As shown in Table 1, the
problem of security and integration is identified in existing document management system, which is
followed of the objectives of the proposed solution (as shown in Figure 4). In this paper, the prototype
method is used for evaluation. As described in Table 1, prototypes implementing the “artifact” were
used to evaluate the solution using a simulated project scenario.

11
Table 1 Steps of Design Science Research Strategy [60] for the proposed solution
Defined
Processes [60]
Description
Steps taken in this paper
Problem
Identification
and motivation
Define
problem and
show
importance
• The need of security in document management for construction
applications was identified from existing literature.
• Existing solutions were explored and investigated from existing
literature
• The limitations (security and integration related) of existing
solutions were identified.
• The ability of current blockchain solutions to address the
limitations were investigated.
Objectives of a
solution
What would a
better artifact
accomplish?
It was identified and that the proposed solution would
• Provide a method to integrate the different components of
document management in a secure manner.
• Secure document approval workflows in terms of irreversibility
and availability
• Secure document lifecycle recording by facilitating irreversibility.
• Secure document versioning by ensuring secure version tr
Design and
Development
Artifact
• Design document metadata (Omniclass Classification System)
was used develop a document management framework for secure
document management
• Methods to facilitate document approval workflow, record
document lifecycle record data model, and version management
in a secure manner were developed
Demonstration
Find suitable
context and
use artifact to
solve
problem
• The methods of document approval workflows and document
lifecycle recording were implemented in a prototype consisting of
smart contract logics and blockchain ledger data models. The
effectiveness of the proposed framework to solve security and
integration related problems (as defined) was demonstrated in a
simulated RFI management scenario.
Evaluation
Observe how
effective and
efficient
• The methods of document approval workflows and document
lifecycle recording, and document version management were
evaluated in a simulated scenario and relevant performance
metrics collected to show efficiency.
Communication
Scholarly
publications
or
Professional
publications
• An initial publication of the proposed framework was made [19]
and positive response was received.

12
Figure 4 Problem identification and objectives of the proposed solution

13
5. The Proposed Approach for Document Management for Construction
Applications
Figure 5 Conceptual Model of the Proposed Approach
Figure 5 shows the conceptual model of the proposed blockchain-based construction document
management system consisting of peer-to-peer blockchain and data storage networks connecting project
participants (peers) to document management functionalities (via workflows logic, documents, and
change records) as shown in Figure 5. The proposed approach deploys technologies including smart
contracts, distributed blockchain ledger, and content-addressed distributed file systems to facilitate
document approval workflows, the recording of document-lifecycle, and document versioning
respectively (discussed in Section 5). As shown in Figure 5, the proposed approach deploys the concept
of full or light nodes/peers [73]. Full nodes (as shown by ‘Peer B’ in Figure 5) contain the complete
blockchain ledger (change records), documents, and smart contract logics, while the light nodes (as
shown by, ‘Peer A’ in Figure 5) contain a portion of the blockchain ledger and certain smart contracts
as per requirement.
Integral project participants such as members of the architectural firm are configured as full nodes to
host the complete history of change records and documents (as per document ownership). External
bodies such as government departments may be added to the proposed document management system

14
network as “light nodes” (as described in Section 5) temporarily (hosting a part of change records and
document integrity proofs) to support processes such as e-submissions and e-tendering. Unlike full
nodes, the light nodes may only have the access to update specific records (such as recording approval
or rejection) and to verify the integrity of documents (requested/received from the document owners)
using the document integrity proofs from the blockchain ledger made available to them.
In this paper, document metadata (data that describes documents) is deployed to record document
lifecycle and to prove version integrity of documents. Table 2 shows the list of metadata used in the
proposed framework including ‘Document ID’, ‘Version’, ‘Content Identifier’.
Table 2 Description of Document Metadata Used in the Proposed Framework
Name
Description
Example
Primary Purpose
Document
ID
Unique identifier of a
document.
1-17-11-1-1
Change Recording and Version
Management
Version
The version number of a
document
Version 1, Version 2, …
(a part of the document ID)
Change Recording and Version
Management
Version
Description
Description of change made to
a document
‘payment period added’, ‘east wall
modified’ etc.
Change Recording
Status
Status of a document under
review
Initiated, Under Review,
Approved/Endorsed, Rejected, etc.
Change Recording and Version
Management
Content
Identifier
Unique Identifier of a
document based on its content
ea12a19ae3953079b641762356383d48fe
9018e6662394e753dcc9e36132f52b
(Document Hash such as from IPFS)
Change Recording
Current
Actor
(Reviewer/
Creator
Unique verifiable identifier of
the participant who has
responded to the current step of
a workflow (creator/ reviewer
of a document)
3e3r9160755cf7c414c006c3a3a55fc81e0
b9fa23468a8e57b80ee85120735re
(Blockchain public Key of the transaction
sender)
Change Recording
Date
(Timestamp)
The date on which document is
created/modified.
15-August-2020
(Blockchain timestamp)
Change Recording
NextActor
Identity of the participant
whose response is expected in
the next step of a workflow
Uret23hs755cf7c414c006c3a3a55fc81e0
b9fa23468a8e57b80ee85120fnch32
(Public Key of the next actor)
Workflow Facilitation
Next Due
Date
The date by which the next
step of a workflow is due
20-August-2020
(Blockchain timestamp + ‘x’ days)
Workflow Facilitation
As shown in Figure 6, the ‘Document ID’ is a unique identifier of a document structured in the format,
‘Domain-Document Type- Document Number-Version Number’ using Omniclass Classification System
[15,73], to facilitate the systematic grouping of documents for efficient searchability. ‘Domain’ refers

15
to the category of work supported by a document such as a Substructure, Superstructure, Exterior
Enclosure, Fittings and Equipment, Mechanical, Electrical. An example of ‘Document Type’ that
indicates the content of documents is shown in Figure 6. ‘Document Number’ is a sequential number
for a document under a document type. ‘Version Number’ as shown in Figure 6 represents a version of
a document under a document type.
Figure 6 Example Document IDs used the Proposed Framework
As shown in Table 2, ‘Content Identifier’ is an irreversible 256-bit long cryptographic representation
of the contents of a document, in the proposed framework. Apart from document metadata, other
information such as ‘Version Description’, ‘Current Actor’, ‘Status’, and ‘Tim estamp’ as defined in
Table 2 are deployed in the proposed framework to facilitate approval workflows, record document
lifecycle, and document versioning as described in Sections 0, 0, 5.4 respectively.
Figure 7 shows the architecture of a standard (full node) peer node consisting of five layers – (1) a data
access layer, (2) a smart contract layer, (3) a distributed ledger layer, (4) a data integrity layer, and (5)
a data storage layer, discussed in the following subsections.
5.1 The Data Access Layer
The data access layer is the frontend of the proposed document management system connecting the
underlying layers. Functions for initiating such requests including (1) adding a new document via a
smart contract request, (2) querying audit logs of a document’s lifecycle (from blockchain ledger), (3)
requesting the proof of the integrity of document versions, and (4) requests for document searching and
retrieval. The purpose of this layer is to direct requests to underlying layers that have the functionalities
to execute the request and return appropriate responses.
Example of Document ID
Omniclass – Table 36

16
Figure 7 Architecture of a Full Peer Node in the Proposed Framework
5.2 The Smart Contract Layer
The smart contract layer shown in Figure 7 contains smart contract logic to facilitate the creation and
execution of customizable document approval workflows securely. In general, the proposed smart
contract logic is designed to verify data and users, enable workflow progression (orchestration of multi-
step customized workflows), and record document lifecycles (for example, document creation,
endorsement, and feedback). Figure 8(a) shows the typical sub-components of document approval
workflows in AEC projects (for example, design review, RFI management, and change order
management). As shown in Figure 8(b), document approval workflows in AEC projects enable
document lifecycles by processing data (such as documents and records) via sub-processes such as those
for ‘document creation’, ‘endorsement’, and ‘feedback’. The sub-processes are facilitated by various
roles such as architects and review engineers through workflow progression logics (sequence of sub-
processes in the progression of a workflow).

17
Figure 8 Document Approval Workflows in Construction Projects – (a) Sub-processes, Data, and Roles in
Document Approval Workflows and (b) Workflow Progression Logic of Typical Document Approval Workflows
Based on the sub-components and workflow progression logics of typical document approval
workflows, the architecture of the proposed smart contract layer is modeled as shown in Figure 9. It
consists of two groups of smart contracts – (1) Workflow-orchestrator smart contracts and (2) Approver
smart contracts, as described in Sections 0 and 0. The advantage of the proposed smart contract
framework logic is its flexibility to create custom document approval workflows as per the requirements
of an organization supported by the security of blockchain technology.

18
Figure 9 Architecture of the Smart Contract Layer for Document Approval Workflows
5.2.1 Workflow-Orchestrator Smart Contracts
The ‘Workflow-orchestrator’ smart contracts primarily represent the workflow progression logic of
document approval workflows. The logic consists of workflow sub-processes that may be differently
arranged as per the requirement of an approval workflow (hence customizable). For example, for a
Design Review workflow, as shown in Figure 9, a project manager can define the sequence in which
the different sub-processes (as shown by numbers, (1),(2), etc. in Figure 9), owned by different project
stakeholders (roles) may be invoked. The smart contract layer is customizable in terms of the sequence
of roles and actions in document approval workflows to address the requirements of different
organizations as needed. Figure 10 shows the diagrammatic representation of a Workflow Orchestrator
smart contract logic (representing workflow progression logic, introduced in Figure 9).

19
Figure 10 Example Diagrammatic Representation of Logic in a Workflow-Orchestrator Smart Contract
As shown in Figure 10, the proposed smart contract logic facilitates workflow progression through a
step-by-step assessment of the state of completion of the different stages of a document approval
workflow. For example, the first step in a design review workflow (shown in Figure 10), checks whether
the design document is available/created for review. If not, an intimation is sent to the designer to create
a design document for review, which is recorded on the blockchain ledger (data model explained in
Section 5.2). When the designer creates the design document for review, the workflow logic marks the
end of the first sub-process by creating a record in the blockchain ledger and sending a notification to
the next actor (which is a Review Engineer in the case of Figure 10). The Review Engineer, in this case,
endorses/rejects the document under review, which is also written to the blockchain ledger, and so on
(It is to be noted that the sub-processes such as ‘create’ and ‘endorse’ shown in Figure 10 are functions
of the Approver smart contracts explained in Section 5.2).
A self-explanatory pseudocode of the proposed workflow logic is shown in Figure 11. As shown in
Figure 11, the proposed smart contract logic deploys two features specific to smart contract languages,
namely, - (i) state variables (may be identified by the prefix, ‘WO_’ in Figure 11 ) and (ii) smart
contract-to-smart contract calling. State variables are permanent records of data (of the unit size of 256-
bits) stored on the blockchain network, that may be accessed or updated only via corresponding smart
contracts. Hence, state variables are secure against manipulation via cyber-attacks that may affect
existing cloud-based document management systems. The smart contract-to-smart contract calling
method is used to maneuver the workflow progression logic to corresponding Approver smart contracts
(with roles and functions as per the requirement of a customized document approval workflow), as
described in Section 5.

20
FUNCTION InitialiseVariables()
Pass In: Integer representing the number of Processes in a document approval workflow
(N), DocumentID
WO_LatestDocumentID = DocumentID
WO_WorkflowCounter = 0
//Create an array state variable of size N
WO_Array[N]
Loop While (0< i <N-1)
WO_Array [i] == FALSE
i ++
End Loop
Pass Out: nothing
END FUNCTION
FUNCTION RunWorkflow()
Pass In: function parameters //according to external function called
IF (WO_Array [WO_WorkflowCounter]== FALSE)
SWITCH(WO_WorkflowCounter)
CASE 0:
V_Response = Invoke FUNCTION ‘X’ in Approver Smart Contract’
IF (V_Response == TRUE)
V_Workflow[WO_WorkflowCounter]= TRUE;
//Special Condition as applicable to external function
//For example, if X is document updating function, the state variable
LatestDocumentID will be updated as follows
WO_LatestDocumentID = V_Response.A_DocumentID
//counter not updated if response is not successful
WO_WorkflowCounter++;
END IF
break
CASE 1:
V_Response = Invoke FUNCTION ‘Y’ in Approver Smart Contract’
……//call to an Approver Smart Contract Function
break
CASE 2:
V_Response = Invoke FUNCTION ‘Z’ in Approver Smart Contract’
……//call to an Approver Smart Contract Function
break
ELSE
EXIT;
FUNCTION SendFailureNotification()
END IF
Pass Out: Success/Failure message
END FUNCTION
Figure 11 Pseudocode for a Workflow-Orchestrator Smart Contract
5.2.2 Approver Smart Contracts
The ‘Approver smart contracts’ are modeled to contain the logic to facilitate the “action” related to a
sub-process (document creation, updating, endorsement, etc.) and record the event on blockchain.
The two main functions of approver smart contracts are: (1) registering and authenticating project
participants (using a cryptographic identification – a public key) for user security, and (2) recording
sub-process execution (creation, updating, endorsement, and feedback) to support workflow
progression (guided by Workflow-orchestrator smart contract) by incorporating data security.

21
For project participant registration and authentication, public-key cryptography (for example, the RSA
(Rivest, Shamir, Adleman) algorithm [63]) is used. Public key cryptography deploys cryptographic key
pairs consisting of – a public key (used for identification and encryption) and a private key (used for
identity verification and decryption). To ensure adequate security, 2048-bit or longer cryptographic
keys may be used as per the recommendations of the National Institute of Standards and Technology
(NIST) [54]. In the proposed Approver smart contract logic, public cryptographic keys are deployed to
identify users (project-participants) and their corresponding Approver smart contracts. It is done so to
ensure that approver smart contracts are always run by their corresponding smart contract owners
(facilitating user authentication). For example, in the design review workflow in Figure 9, the
endorsement received from the review engineer in step (2) can be traced back (and verified) to his public
key identity. To ensure user security against blockchain specific cyberattacks such as ‘replay attacks’[2],
a nonce element (using an integer array state variable) is used in every user signature to prevent old
digital signatures from being reused (for example, as shown in the EndorseDocument() function Figure
12 ).
For securely recording sub-process execution, the Approver smart contracts contain data authenticity
and version continuity checks in their logic. Figure 12 shows the corresponding self-explanatory
pseudocode for deploying an Approver smart contract. For example, as shown Figure 12, in the
CreateDocuemnt() function, the smart contract logic uses a state variable array (depicted by
A_DocumentID[]) to store all the document IDs created by a particular Approver smart contract. This
information is later checked during the updating of a document (as shown in UpdateDocument()
function in Figure 12) to ensure that only a document creator can update a document (hence ensure
document ownership security). A simple approver smart contract is available at
https://github.com/mouasda/doc.

22
// Creating a new Document
FUNCTION CreateDocument()
Pass In: DocumentID, ContentIdentifier, WorkflowInvokerSignature
//Verify if the message sender is the owner of the approver contract
IF (WorkflowInvokerSignature ≡ ContractDeployerPublicKey)
DocumentVersionNumber = ExtractFrom (DocumentID)
IF (DocumentVersionNumber ==1)
//Add document ID to state variable A_DocumentID
INSERT DocumentID to A_DocumentID[]
//Add document creation record to blockchain
Update Blockchain Ledger //according to proposed ledger data model
END IF
END IF
Pass out: ResponseParameters
END FUNCTION
// Updating an Existing Document
FUNCTION UpdateDocument()
Pass In: DocumentID, WO_LatestDocumentID, ContentIdentifier, WO_LatestDocumentID,
WorkflowInvokerSignature
IF (WorkflowInvokerSignature ≡ ContractDeployerPublicKey)
IF(WO_LatestDocumentID == (getVersionNumberFrom(WO_LatestDocumentID)-1)) and
IF (WO_LatestDocumentID IN A_DocumentID[])
//Add document updating record to blockchain
Update Blockchain Ledger //according to proposed ledger data model
END IF
END IF
Pass out: ResponseParameters
END FUNCTION
// Endorsing a Document
FUNCTION EndorseDocument()
Pass In: DocumentID, Endorsement, ContentIdentifier, WO_LatestDocumentID,
WorkflowInvokerSignature
IF (WorkflowInvokerSignature ≡ ContractDeployerPublicKey)
//The endorsement should be signed by the contract deployer
IF (SignatureOnEndorsement ≡ ContractDeployerPublicKey)
//Old endorsements cannot be used
AND (EndorsementNonce NOT in A_UsedNonces)
//Only latest documents may be sent for endorsements
AND (DocumentIDinEndorsement == WO_LatestDocumentID)
Update Blockchain Ledger //according to proposed ledger data model
END IF
END IF
Pass out: ResponseParameters
END FUNCTION
// Commenting/Feedback on a Document
FUNCTION CommentOnDocument()
Pass In: DocumentID, Comment/Feedback, ContentIdentifier, WO_LatestDocumentID,
WorkflowInvokerSignature
IF (WorkflowInvokerSignature ≡ ContractDeployerPublicKey)
//Only latest documents may be commented on
IF (DocumentIDinEndorsement == WO_LatestDocumentID)
Update Blockchain Ledger //according to proposed ledger data model
END IF
END IF
Pass out: ResponseParameters
END FUNCTION
Figure 12 Pseudocode for an Approver Smart Contract of the Proposed Smart Contract Layer

23
5.3 The Distributed Ledger Layer
This section presents the blockchain ledger data model (Figure 13) for recording document lifecycles
to support monitoring and versioning of AEC project documents. Figure 13 shows a typical blockchain
ledger [72] consisting of a cryptographically irreversible linked chain of blocks (linked via irreversible
hash values [10]). As shown in Figure 13, the body of a typical blockchain block contains transactions
i.e., the records of the states of digital assets (which are documents in the proposed framework) resulting
from the execution of corresponding smart contracts.
Figure 13 Data Model of the Blockchain Ledger for Document Management
Figure 13 shows the blockchain ledger data model (only additions are shown in detail) for the proposed
document management framework. The data model is designed primarily considering the requirements
of document lifecycle recording and document workflow facilitation using document metadata (as
described in Table 2). As shown in Figure 13, document ID, document status, version description with
blockchain records such as transaction sender, and timestamp to record document lifecycle.
For workflow facilitation, the workflow user who is supposed to be responding next according to the
workflow progression logic and various due dates are included in the proposed blockchain ledger. A

24
cryptographic identifier, named, ‘document root’ (described in Section 5.4) is added to the proposed
ledger data model to prove the version integrity of documents.
5.4 Document Version Integrity Layer
In this section, a Merkle-Patricia-Trie-based [72] data structure is proposed for document management,
henceforth referred to as the ‘document management tree’ (DMT).
Merkle Patricia tries (MPT) are distributed indexing data structures that consist of data (known as nodes)
arranged in a recursive tree-like fashion. The data structure of an MPT contains branches (consisting
of two or more non-leaf nodes) representing a unique data identifier each with the actual data (non-leaf
node) at the end of every branch. The branches are arranged in a fashion to facilitate incremental updates
(unlike T-tree and variants of B+ trees [42] that require complete reconstruction with every update) to
ensure performance in distributed systems, i.e. updates requiring minimum computation and fast
querying of data.
In the proposed Document Management Tree (DMT), the data structure of leaf-nodes and non-leaf
nodes are designed for document management (document versioning and searching) as shown in Figure
14.

25
Figure 14 Document Management Tree (DMT) for Document Version Management and Proof of Integrity
The structure of a node consists of part of document ID as the key and a node identifier as value (format
is “part document ID” : “node identifier”). As shown in Figure 14, the leaf nodes are designed as
numbered data where the keys are designed as sequential version numbers such as 1, 2, and 3. The
corresponding values in leaf nodes are node identifies which in this case are cryptographic document
identifiers or hash values (of 256-bit length) of the contents of documents, as described in Table 2. As
shown in Figure 14, the value of a non-leaf node is depicted by H(DocA) representing the Hash value
of Document A.
The keys of the non-leaf nodes (as shown in Figure 14) are parts of Document IDs. For example, a
document ID, ‘1-17-11-1-1’ is split into node keys such as ‘1’, ‘17’, and ‘11’ as shown in Figure 14.
The value (i.e. node identifier) in a non-leaf node of the proposed DMT is designed as the cryptographic
hash value of the concatenation of hash values of its corresponding child nodes.
Therefore, the resulting DMT has three main properties. First, a node in the DMT is a unique and
irreversible identifier consisting of the contents of its child nodes. The head of the DMT termed

26
document root (DR) is a unique identifier created via recursive hashing of all its child nodes. Therefore,
the document roots are unique cryptographic references depicting the data integrity of different versions
of a document. This means all the versions of a document are secure and has the security of not being
deleted without a trace. Second, a branch in a DMT represents the mapping between a document
identifier and a document. For example, a branch as shown in Figure 14, maps the document ID, ‘1-17-
11-1-1’ to the first version of Document A. Due to this type of data structure, the proof of integrity of a
document version can be easily searched and retrieved for verification. Third, information regarding
document versioning is maintained in the DMT. The existing MPT implementations in blockchain
platforms such as Ethereum [72] are designed to store the latest version of asset data (such as the latest
account balance). In contrast, the proposed DMT maintains references to versioned data (with the help
of document ID construction and numbered leaf nodes) by maintaining references at non-leaf and leaf
node level (explained in Section 5.3). These aforesaid properties of the DMT are deployed to facilitate
document versioning (updating), document searching, and verification of version integrity, as explained
in the following sections through Figure 15.

27
Figure 15 Diagrammatic Representation of Updates in the Proposed DMT
5.4.1 Updating of the proposed DMT for Version Management
Figure 15 shows how the proposed DMT handles updates initiated by the smart contract layer (explained
in Section 5.2) for document versioning. As shown in Figure 15, the state, ‘original’ represents an
initial DMT (introduced in Figure 14) containing a document with document ID, ‘1-17-11-1-1’. At this
stage, the root of the DMT is represented by ‘DR0’ as shown in Figure 15. The subsequent updates, i.e.
addition of new documents or new document versions are depicted by ‘Update 1’, ‘Update 2’, ‘Update
3’, and ‘Update 4’ in Figure 15.
Unlike a traditional MPT, the proposed DMT grows incrementally by maintaining pointers to older
nodes on two levels – (1) unmodified nodes on the non-leaf node level (shown by black arrows in Figure
15), and (2) older versions on the leaf node level (shown by red arrows in Figure 15). For example, the

28
addition of a new document (‘DocB’) shown by ‘Update 1’ in Figure 15, consists of the creation of a
new branch (‘1-17-11-2-1’) leading to the leaf node depicted by ‘Hash24’. In this update, a reference
to the unmodified old node (‘Hash13’) is maintained to facilitate the incremental growth of the DMT
while preserving its primary properties (as explained in Figure 14). Similarly, versioning of a document,
‘DocA’ is shown in ‘Update 2’ of Figure 15, where references to older versions are also maintained to
help document searching as explained in Section 5.5.
5.4.2 Verification of Document Integrity using the proposed DMT
The data storage layer for hosting documents (explained in Section 5.5) is designed to store documents
according to data ownership. Therefore, in the proposed document management framework, some
project participants may have access to specific documents whereas others may not. However, in the
proposed framework, all the project participants will have access to the blockchain ledger and the DMT.
Therefore, a non-data owner on the network may verify the completeness and consistency of a particular
version of a document sent to him by a document owner using the document root available to him (on
the public blockchain). For example, as shown in Figure 15, a non-owner may verify the integrity of
the document, ‘DocB’ by calculating the document root, ‘DR1’ (from public DMT) by using ‘Hash12’
(from public DMT) and document content (sent by document owner) and matching it with the document
root which he can obtain from the blockchain ledger. The proposed DMT is an in-memory data structure,
but maybe saved on disk and recreated as explained in Section 5.5. The DMT also facilitates different
types of range searches related to document revisions and is explained in Section 5.5.
5.5 The Data Storage Layer
This section describes the data storage layer of the proposed framework (as shown in Figure 7) for
storing the DMT and document. In this section, a key-value based database (for example, levelDB [28])
data model for storing the proposed DMT to support document management via blockchain technology
is proposed. The purpose of this data model is to permanently record the DMT to support document
searching and verification of document integrity. Table 3 shows the data model consisting of a ‘database
key’ and a ‘database value’. For representing the DMT in a database, the node identifier (described in
Section 5.4) is used as a database key. The corresponding values of a database key is the list of the node
identifiers and partial document identifiers of the child nodes. In general, the database data model can
be expressed in a (K, V) format as ([node identifier of parent node], [node identifiers of child nodes:
node keys of child nodes]) as shown in Table 3.

29
Table 3 Data Model for Disk Storage of the Document Management Trie through Several Updates
Original Trie
Update 1
Update 2
Update 3
Update 4
I
D
Key
Value
ID
Key
Value
ID
Key
Value
ID
Key
Value
ID
Key
Value
(1
)
Hash
14
{H(DocA
)}
(7)
Hash
24
{H(DocB
) }
(1
3)
Hash
34
{H(DocA
’)}
(19
)
Hash
44
{H(DocA
’’)}
(25
)
Hash
54
H(DocA’’
’)
(2
)
Hash
13
{Hash14:
1}
(8)
Hash
23
{Hash24:
1}
(1
4)
Hash
33
{Hash34:
2,
Hash14:
1}
(20
)
Hash
43
{Hash44:
3, Hash
34: 2,
Hash
14:1}
(26
)
Hash
53
{Hash54:4
,
Hash44:3,
Hash34:2,
Hash
14:1}
(3
)
Hash
12
{Hash13:
1}
(9)
Hash
22
{Hash23:
2,
Hash 13:
1}
(1
5)
Hash
32
{Hash33:
1,
Hash23:
2}
(21
)
Hash
42
{Hash 43:
1,
Hash23:
2,}
(27
)
Hash
52
{Hash53:1
,
Hash23:1}
(4
)
Hash
11
{Hash12:
11}
(1
0)
Hash
21
{Hash22:
11}
(1
6)
Hash
31
{Hash32:
11}
(22
)
Hash
41
{Hash42:
11}
(28
)
Hash
51
{Hash52 :
11}
(5
)
Hash
10
{Hash11:
17}
(1
1)
Hash
20
{Hash21:
1}
(1
7)
Hash
30
{Hash31:
17}
(23
)
Hash
40
{Hash41:
17}
(29
)
Hash
50
{Hash51:
17}
(6
)
DR0
{Hash10:
1}
(1
2)
DR1
{Hash20:
1}
(1
8)
DR2
{Hash30:
1}
(24
)
DR3
{Hash40:
1}
(30
)
DR4
{Hash50 :
1}
For example, the column ‘Original Trie’ of Table 3 shows the database data model of the DMT shown
in Figure 15). This proposed data model is designed to support queries to find (1) the proof associated
with a document version using ‘document ID’ and ‘Document Root’ from the blockchain ledger, (2)
the latest version of a document, and (3) the latest documents under a particular version. To prove the
version identity of a document, say the version DocA (sent by its owner to a requester), a document
requester may try to construct the corresponding document root, ‘DR3’ using the document at hand and
public information the DMT (part of blockchain). For example, assuming that the document in hand is
the correct version, i.e., DocA’’’ in this case, the requester should be able to generate DR3 using
DocA’’’ and DMT nodes, Hash14, Hash34, and Hash 23 available publicly (as shown by ‘Update 3’
in red in Table 3). If the content of DocA’’’ is not as same as recorded initially on the blockchain ledger
via DMT, this verification process will fail, indicating the lack of authenticity of the received document.
To find the latest version of a document for example with a document ID, ‘1-17-11-1-x’, where x is the
version number (unknown), the corresponding document root ‘DR3’ can be used to traverse the path
(24)-(23)-(22)-(21)-(20)-(19) (IDs in Table 3) to fetch H(DocA’’), which may be used to extract the
document from the document store (as explained in 5.5). A similar approach may be taken to find all
the latest documents.

30
6 Illustrative Use Case Scenario of the Proposed Smart Contract Framework
In this section, an illustrative case scenario of an RFI (Request for Information) is used to demonstrate
the functions and properties of the proposed blockchain framework for document management. An RFI
is a request for information used in AEC projects to clarify uncertainties and find missing information
in project documents such as specifications, plans, and contracts.
In this illustrative example, the functionality of the proposed approach to – (1) integrate resources and
(2) facilitate security to support processes such as RFI workflows is demonstrated. Figure 16 shows an
RFI workflow that consists of several steps such as creating an RFI, submitting an official response,
and providing endorsements. As shown in Figure 16, it is required that the actions are facilitated by
different roles according to a pre-defined workflow progression logic. For example, it is the
responsibility of an RFI manager to initiate an RFI by ascertaining the pre-defined logic, ensure that the
RFI lifecycle is recorded, and closing the RFI. Similarly, a sub-contractor is responsible for creating a
new RFI, i.e. documenting the reason for creating the RFI such as missing information, and passing the
control to the next stakeholder (the contractor as shown in Figure 16). The other roles such as contractor,
architect, and client are responsible for editing the RFI, composing an official response, and endorsing
the RFI respectively as shown in Figure 16.
Figure 16 Example of a Request for Information Workflow

31
In this example (Figure 17), it is demonstrated how resources such as documents, comments, and
records and roles are integrated using the proposed blockchain platform. The example also demonstrates
how – (1) version security, i.e., the data integrity of the latest version and irreversibility of version
history, (2) user security, i.e., certainty that only authorized users are allowed to perform actions pre-
defined according to the workflow logic, (3) workflow security, i.e. integrity of the pre-defined
workflow logic, and (4) document lifecycle transparency is facilitated by the proposed framework.
Figure 17 Example Scenario Demonstrating Integration and Security Using Proposed Blockchain Framework
As shown in Figure 17, an RFI manager deploys the workflow logic in which the sequence of the actions
and the roles who should perform them are predefined. The workflow logic is deployed by deploying a
workflow orchestrator smart contract (as described in Section 5.2) that contains links to the smart
contracts of different project stakeholders (called approver smart contracts as described in Sections 0),
as shown by (ii), (iii), (iv), (v) in Figure 17. As explained in Section 5.2 and as shown in Figure 17, the

32
workflow smart contract can on-the-fly assign the number of workflow steps, roles, and actions.
Therefore, the workflow logic is integrative and customizable. It at the same time is irreversible because
it is deployed on the blockchain
As shown in Figure 17, the workflow participants such as sub-contractors, contractors, architects, and
clients are authenticated using their credentials stored on the blockchain via their respective smart
contracts. For example, the architect’s smart contract and the client’s smart contract (depicted by (iv)
and (v) Figure 17) contain the architect’s and the client’s cryptographic credentials, respectively. Since
the smart contracts containing the credentials are deployed on the blockchain, the credentials are
irreversible or untamperable. As explained in Section 5.2, the proposed smart contract framework is
designed in such as way that the workflow participants are always validated using their respective smart
contracts/credentials which adds a level of security.
Figure 17 also shows the blockchain ledger data model which is used to record document lifecycle
through all the steps of an information approval workflow. For example, a sub-contractor may initiate
the workflow by recording information such as document number (of the main document driving the
workflow), proof of document integrity, attachments, the next actor, and due date. When the next actor
that is the contractor is notified via email, he/she may verify use the transparent blockchain ledger data
to perform actions such as verify the integrity of attachments and checking version history. Therefore,
using the proposed framework as demonstrated in Figure 17, using a smart contract, blockchain ledger,
and methods of correspondence such as email, an integrated and secure approach may be taken to
facilitate information approval workflow and document management.
7 Implementation and Evaluation
7.1 Proof-of-Concept
In this section, a prototype of the proposed approach is developed as shown in Figure 18. The prototype
is developed to demonstrate an RFI workflow (explained in Section 5.1) with one workflow orchestrator
smart contract to deploy the RFI workflow logic and four approver smart contracts of the participants
of the RFI workflows, i.e., a sub-contractor, a contractor, an architect, and a client (as shown by smart
contracts (i) – (v) in Figure 17). The prototype in Figure 18 shows a user interface, that allows end-
users to choose workflow details such as the number of steps in the workflow and due date (as shown
by steps 1-3 in Figure 18). Based on the input provided, the front end lets the end-user/creator of an
approval workflow (an RFI manager in this case) choose the appropriate smart contracts and methods
(as shown by steps 4 and 5 Figure 18).

33
Figure 18 Prototype of the Proposed Blockchain Framework
The workflow orchestrator smart contract (for RFI) in this case is deployed on a Hyperledger Fabric
(version 1.4) network. As shown in Figure 18, the Hyperledger network is configured with two
organizations with two peer nodes each for testing.
7.2 Evaluation
7.2.1 Smart Contract Logic
The smart contracts are tested for two performance indicators namely latency and throughput. Latency
is defined as the total time taken to send a request to blockchain and receive confirmation. Therefore,
latency is a measure of the efficiency of the smart contract framework developed for document
management. Throughput is the number of transactions the blockchain network can process in a second.
Therefore, throughput indicates how well does the proposed system performs under heavy load and
hence is a measure of the scalability of the proposed smart contract framework. For performance

34
benchmarking, Hyperledger Tape [76], a benchmarking tool for Hyperledger Fabric networks is used.
For measurement of latency and throughput, 10 rounds of transaction sets containing a hundred
transactions each are fired at the prototype blockchain network of the proposed framework. Figure 19
and Figure 20 show the results of performance benchmarking. Figure 19 shows that the average latency
among all the methods of the smart contracts of the proposed framework is within the range of 160-170
milliseconds. The average throughput of the proposed framework is within the range of 50-60
transactions per second. Therefore, it is reasonable to claim that the proposed framework is performance
efficient and scalable.
Figure 19 Latency of Different Smart Contract Functions of the Proposed Framework

35
Figure 20 Throughput of the Smart Contracts of the Proposed Framework
7.2.2 Data structure for Document Versioning Security
In this section, transaction performance, i.e., the time taken to conduct blockchain transactions for
document management using the proposed DMT is evaluated. The transaction performance depends on
two factors – (1) time taken for a transaction to update the trie-based data structure (which is the
proposed DMT in this case) and (2) transaction transmission time on the blockchain network [77]. For
the proposed blockchain framework, the block size is assumed to be less than 1 MB and hence the
transaction transmission time is ignored in the calculation of transaction performance as blocks less
than 1 MB in size have no measurable effect on transmission time [20]. The time (T) taken to update
the proposed DMT is calculated using the following equation (2) [68,77] for trie-based data structures.
   
  
… (2)
where,
t = read/write time on a key-value database (LevelDB considered)
a = number of times a transaction updates the trie data structure = 1 (in the proposed framework, a
blockchain transaction updates the DMT only once).
n = number of leaf nodes in the trie data structure i.e the total number of documents
As shown in Equation (2), the time taken to update the proposed DMT depends on the time taken to
perform a write operation on a database (LevelDB in this case), the number of times the DMT is updated
by a transaction for document management, and the number of documents (i.e. number of leaf nodes)

36
in the DMT. The time (t) taken to perform a write operation on LevelDB is considered as 0.03 ms [28].
The number of times (‘a’) that a document management transaction updates the DMT is 1. Using
equation 2, the predicted time taken to update the DMT for a varying number of documents is calculated
and plotted, as illustrated in Figure 21.
The DMT was also verified by modifying the ‘go-ethereum/trie/trie.go’ data structure and running on
a single Geth [25] node on an 8 GB memory computer. As shown in Figure 21, the experimental results
show a similar logarithmic pattern that is comparable to the predicted results. The difference between
the experimental and predicted results may have been caused by the assumption of constant read/write
time on LevelDB. The actual time of read/write on LevelDB may be much lower [77] for smaller data,
as considered in this case.
As shown in Figure 21, the time cost increases logarithmically with the number of documents. The
increase in time due to DMT is low for a large number of documents (in milliseconds) which shows
that the DMT is scalable for a large number of documents.
Figure 21 Predicted and Experimental Time required to update DMT
8. Discussion
Common Data Environments (CDE) or electronic document management systems (EDMS) hold
information relating to all aspects of a project including documents such as contracts, reports, bids, and
models. However, there are several challenges in implementing CDE/EDMS for construction
applications. One of the main challenges identified with CDE/EDMS is data security and legal
implications. Electronically stored documents are susceptible to alteration and loss which results in
legal issues during the project [1,61]. Secondly, the existing implementations of CDE are usually under

37
a subscription model (for example, cloud-based solutions such as Autodesk BIM 360), which may not
be suitable to some project stakeholders due to their momentary/temporary involvement in the project
[24]. For example, in the case of e-submissions, external building regulatory bodies may not be a part
of CDE subscriptions but may still be interested in verification of document integrity and access to
trustable document lifecycle records [7]. Thirdly, small and medium-sized organizations still use data
repositories such as Dropbox instead of CDE/EDMS implementations and therefore may find it
challenging to implement various CDE functionalities such as document approval workflows and
document audit trails [18]. To address these challenges, the current study presents an overarching
blockchain-based approach that may be implemented on top of CDE/EDMS and data repositories to
facilitate the required functionalities of document management for construction applications. The
proposed blockchain-based approach facilitates the integration of data sources and enables data security.
The proposed approach has two main contributions. Firstly, a cryptographic data structure, DMT, and
a blockchain ledger data model are developed to verify document version integrity. The DMT data
structure is designed to create mappings between respective documents, document proofs, document
identifiers which can be used to search and verify the integrity of a document. In addition, the data
model of the DMT is designed to store document versioning information which means that version
records of documents cannot be deleted without a trace. Therefore, a non-data owner, or a light node
(for example, external building regulatory bodies or small sub-contractors) who may not have a
subscription to CDE/EDMS may verify the completeness and consistency of a particular document
version, document history, or latest document using the distributed DMT. The blockchain ledger data
model is designed using document metadata as per Omniclass classification system to record document
lifecycle which can be later used prove the accountability of project stakeholders (who may or may not
be subscribed to the CDE) in case of disputes. Secondly this study has designed document approval
workflow logic using smart contracts (which has the security of blockchain) to deploy integrated
approval workflows on disconnected CDEs/EDMS and data repositories. The events of document
approval is recorded on the blockchain ledger which facilitates transparency with the security or
irreversibility.
9. Conclusion
The security of document management systems is crucial to the success of AEC projects. However, the
existing approaches to document management lack certain types of security such as irreversibility, non-
repudiation, and data integrity. The existing document management systems are uni-polar in terms of
data ownership, i.e. crucial information such as information approval logic, documents, and records are
required to be entrusted with a centralized party such as a cloud service provider. However, due to the
fragmented project organizational structure of AEC projects with multiple document owners, such an

38
arrangement may not be suitable as it may lead to undesirable consequences such as stealing intellectual
property and manipulation of records.
Therefore, in this paper, a decentralized document management system is developed using security-
enabling technologies such as blockchain to facilitate security to document management for AEC
projects. To meet the functionalities of document management, blockchain ledger data model and smart
contract logic are designed to support the primary functions of document management in AEC projects
such as customizable information approval workflows, version management, and document lifecycle
recording.
Blockchain-based smart contract logic is developed to facilitate customized document approval
workflows for AEC projects. The lifecycle of documents (versioning and endorsements) are irreversibly
recorded through the deployment of distributed ledger technology of blockchain. The proposed
distributed ledger is supported by methods to search and prove the version integrity of documents and
document version history. Document storage may be facilitated through centralized cloud-based
repositories or IPFS technology which avoids single points of failure through data replication
mechanisms.
A prototype was created using Hyperledger fabric and demonstrated with a use case scenario. The
prototype was also evaluated for scalability by collecting metrices such as latency and transactions per
second. The results show that the proposed framework is scalable.
The proposed framework leverages the security of blockchain but may suffer from certain
vulnerabilities. Data integrity and non-repudiation are two important security requirements of document
management systems. However, blockchain networks may be susceptible to Man-in-the-middle (MIM)
attacks or replay attacks [4,34]. The proposed framework stores user credentials on the blockchain via
approver smart contracts and signed nonces to prevent MIM and replay attacks respectively. The
proposed framework in its current form assumes that the cost of deployment will be borne by all project
participants collectively. However, for smaller contractors, such an arrangement may not be feasible.
Therefore, in the future, an incentive-based approach will be explored where project participants will
be rewarded for providing unused storage space to the project. For smaller projects, public
implementation of the proposed framework is recommended. However, to ensure document privacy,
encryption of documents in a manner that does not hinder their functionality is required and will be
explored in the future. The integration of the proposed framework with other relevant data sources such
as OpenBIM, IoT, and GIS (towards a common data environment) will also be explored in the future
References
[1] A. Pandey, F. Shahbodaghlou, J. Burger, Legal and contractual challenges of Building
Information Modeling—Designers’ perspectives, Proceedings of the Construction

39
Research Congress 2016, San Juan, Puerto Rico, 2016, pp. 519–
527.https://doi.org/10.1061/9780784479827.053
[2] C. Adams, Replay Attack, in: H.C.A. van Tilborg, S. Jajodia (Eds.), Encyclopedia of
Cryptography and Security, Springer US, Boston, 2011, pp. 1042-
1042.https://doi.org/10.1007/978-1-4419-5906-5
[3] H.S. Ahmad, I.M. Bazlamit, M.D. Ayoush, Investigation of Document Management
Systems in Small Size Construction Companies in Jordan, Procedia Engineering 182
(2017) pp. 3-9.https://doi.org/10.1016/j.proeng.2017.03.101
[4] R. Almadhoun, M. Kadadha, M. Alhemeiri, M. Alshehhi, K. Salah, A User
Authentication Scheme of IoT Devices using Blockchain-Enabled Fog Nodes,
Proceedings of the 15th International Conference on Computer Systems and
Applications (AICCSA), 2018, pp. 1-8.http://doi.org/10.1109/AICCSA.2018.8612856
[5] Autodesk Inc., BIM 360 Docs, 2020, Available at:https://www.autodesk.com/bim-
360/construction-document-management-software/, Last Accessed:20 September
2021
[6] J. Benet, Ipfs-content addressed versioned p2p file system, 2014, Available
at:https://docs.ipfs.io/, Last Accessed:20 September 2021
[7] BuildingSmart, e-submission common guidelines for introduce BIM to building
process, 2020, Available at: https://www.buildingsmart.org/wp-
content/uploads/2020/08/e-submission-guidelines-Published-Technical-Report-RR-
2020-1015-TR-1.pdf, Last Accessed: 20 September 2021
[8] C.H. Caldas, L. Soibelman, Automating hierarchical document classification for
construction management information systems, Automation in Construction 12 (4)
(2003) pp. 395-406.https://doi.org/10.1016/S0926-5805(03)00004-9
[9] J.L. Carter, M.N. Wegman, Universal classes of hash functions, Computer and
System Sciences 18 (2) (1979) pp. 143-154.https://doi.org/10.1016/0022-
0000(79)90044-8
[10] J.L. Carter, M.N. Wegman, Universal classes of hash functions, Journal of Computer
and System Sciences 18 (2) (1979) pp. 143-154.https://doi.org/10.1016/0022-
0000(79)90044-8
[11] M. Castro, B. Liskov, Practical Byzantine Fault Tolerance, Proceedings of the Third
Symposium on Operating Systems Design and Implementation, Vol. 99, New
Orleans, USA, 1999, pp. 173-186.https://dl.acm.org/doi/10.5555/296806.296824
[12] H. Cha, D. Lee, Framework Based on Building Information Modelling for
Information Management by Linking Construction Documents to Design Objects,
Asian Architecture and Building Engineering 17 (2) (2018) pp. 329-
336.https://doi.org/10.3130/jaabe.17.329
[13] A. Chaer, K. Salah, L. Claudio, P.P. Ray, T.R. Sheltami, Blockchain for 5G:
Opportunities and Challenges, Proceedings of the IEEE Globecom Workshops (GC
Wkshps), Waikoloa, USA, 2019, pp. 1-
6.https://doi.org/10.1109/GCWkshps45667.2019.9024627
[14] Construction Specifications Institute, MasterFormat, 2016, Available
at:https://www.edmca.com/media/35207/masterformat-2016.pdf, Last Accessed:20
September 2021
[15] Construction Specifications Institute, Omniclass, 2012, Available
at:https://www.csiresources.org/standards/omniclass/standards-omniclass-about, Last
Accessed:20 September 2021
[16] N.Y. D. Schwartz, A. Britto, The ripple protocol consensus algorithm (White Paper),
Available at:https://ripple.com/files/ripple_consensus_whitepaper.pdf, Last
Accessed:20 September 2021

40
[17] A. Dabholkar, V. Saraswat, Ripping the Fabric: Attacks and Mitigations on
Hyperledger Fabric, Proceedings of the Applications and Techniques in Information
Security 2019, Vol. 1116, 2019, pp. 300-311.https://doi.org/10.1007/978-981-15-
0871-4_24
[18] M. Das, X. Tao, J.C.P. Cheng, BIM security: A critical review and recommendations
using encryption strategy and blockchain, Automation in Construction 126 (2021) pp.
103682.https://doi.org/10.1016/j.autcon.2021.103682
[19] M. Das, X. Tao, J.C.P. Cheng, A Secure and Distributed Construction Document
Management System Using Blockchain, Proceedings of the 18th International
Conference on Computing in Civil and Building Engineering, Brazil,
2021.https://doi.org/10.1007/978-3-030-51295-8_59
[20] J.A. Donet-Donet, C. Pérez-Solà, J. Herrera-Joancomartí, The Bitcoin P2P Network,
Proceedings of the International Conference on Financial Cryptography and Data
Security 2014, Berlin, Germany, 2014, pp. 87-102.https://doi.org/10.1007/978-3-662-
44774-1_7
[21] T. Dounas, D. Lombardi, A CAD-blockchain integration strategy for distributed
validated digital design, Proceedings of the 36th International Conference on
Education and Research in Computer Aided Architectural Design in Europe, Lodz,
Poland, 2018, pp. 223–230. Available at:
http://papers.cumincad.org/data/works/att/ecaade2018_226.pdf, Last Accessed:20
September
[22] F. Elghaish, S. Abrishami, M.R. Hosseini, Integrated project delivery with
blockchain: An automated financial system, Automation in Construction 114 (2020)
pp. 103182.https://doi.org/10.1016/j.autcon.2020.103182
[23] T. Elghamrawy, F. Boukamp, Managing construction information using RFID-based
semantic contexts, Automation in Construction 19 (8) (2010) pp. 1056-
1066.https://doi.org/10.1016/j.autcon.2010.07.015
[24] A.S. Erri Pradeep, T.W. Yiu, Y. Zou, R. Amor, Blockchain-aided information
exchange records for design liability control and improved security, Automation in
Construction 126 (2021) pp. 103667.https://doi.org/10.1016/j.autcon.2021.103667
[25] Ethereum Foundation, Go Ethereum, 2014, Available at:https://geth.ethereum.org/,
Last Accessed:20 September 2021
[26] Ethereum Foundation, Solidity, 2020, Available
at:https://solidity.readthedocs.io/en/v0.4.24/installing-solidity.html, Last
Accessed:September 20 2021
[27] M.S. Fathi, M. Abedi, S. Rambat, S. Rawai, M.Z. Zakiyudin, Context-Aware Cloud
Computing for Construction Collaboration, Cloud Computing 2012 (2012)
(2012).http://doi.org/10.5171/2012.644927
[28] Google, LevelDB, 2020, Available at:https://github.com/google/leveldb, Last
Accessed:September 20 2021
[29] R. Grover, T.M. Froese, Knowledge Management in Construction Using a SocioBIM
Platform: A Case Study of AYO Smart Home Project, Procedia Engineering 145
(2016) pp. 1283-1290.https://doi.org/10.1016/j.proeng.2016.04.165
[30] F. Guo, C.T. Jahren, Y. Turkan, Electronic Document Management Systems for the
Transportation Construction Industry, Construction Education and Research (2019)
pp. 1-16.https://doi.org/10.1080/15578771.2019.1685612
[31] D. Hajjar, S.M. AbouRizk, Integrating Document Management with Project and
Company Data, Computing in Civil Engineering 14 (1)
(2000).https://doi.org/10.1061/(ASCE)0887-3801(2000)14:1(70)

41
[32] H. Hamledari, M. Fischer, Construction payment automation using blockchain-
enabled smart contracts and robotic reality capture technologies, Automation in
Construction 132 (2021) pp. 103926.https://doi.org/10.1016/j.autcon.2021.103926
[33] V. Hargaden, N. Papakostas, A. Newell, A. Khavia, A. Scanlon, The Role of
Blockchain Technologies in Construction Engineering Project Management,
Proceedings of the 2019 IEEE International Conference on Engineering, Technology
and Innovation (ICE/ITMC), Valbonne Sophia-Antipolis, France, 2019 pp. 1-
6.https://doi.org/10.1109/ICE.2019.8792582
[34] H.R. Hasan, K. Salah, Proof of Delivery of Digital Assets Using Blockchain and
Smart Contracts, IEEE Access 6 (2018) pp. 65439-
65448.http://doi.org/10.1109/ACCESS.2018.2876971
[35] H.R. Hashan, K. Salah, Combating Deepfake Videos Using Blockchain and Smart
Contracts, Journal of IEEE Access 7 (2019) (2019) pp. 41596-
41606.http://doi.org/10.1109/ACCESS.2019.2905689
[36] HCL Technologies, HCL Connections, 2020, Available
at:https://www.hcltechsw.com/products/connections, Last Accessed:20th September
2021
[37] A. Heiskanen, The technology of trust: How the Internet of Things and blockchain
could usher in a new era of construction productivity, Construction Research and
Innovation 8 (2) (2017) pp. 66-70.http://doi.org/10.1080/20450249.2017.1337349
[38] A.K. Jallow, P. Demian, C.J. Anumba, A.N. Baldwin, An enterprise architecture
framework for electronic requirements information management, Information
Management 37 (5) (2017) pp. 455-
472.https://doi.org/10.1016/j.ijinfomgt.2017.04.005
[39] S. Khaled , Habib, M., Nishara, N., Ala, F., Blockchain for AI: Review and Open
Research Challenges, IEEE Access 7
(2019).http://doi.org/10.1109/ACCESS.2018.2890507
[40] M.A. Khan, K. Salah, IoT security: Review, blockchain solutions, and open
challenges, Future Generation Computer Systems 82 (2018) pp. 395-
411.https://doi.org/10.1016/j.future.2017.11.022
[41] P. Lahdenperä, Making sense of the multi-party contractual arrangements of project
partnering, project alliancing and integrated project delivery, Construction
Management and Economics 30 (1) (2012) pp. 57-
79.https://doi.org/10.1080/01446193.2011.648947
[42] T.J. Lehman, M.J. Carey, A Study of Index Structures for Main Memory Database
Management Systems, Proceedings of the 12th International Conference on Very
Large Data Bases, San Francisco, CA, United States, 1986, pp. 294-
303.https://dl.acm.org/doi/10.5555/645913.671312
[43] T.J. Lehman, J.C. Michael, A Study of Index Structures for Main Memory Database
Management Systems, Proceedings of the 12th International Conference on Very
Large Data Bases, San Francisco, CA, United States, 1986, pp. 294–
303.https://dl.acm.org/doi/10.5555/645913.671312
[44] V. Leis, A. Kemper, T. Neumann, The adaptive radix tree: ARTful indexing for main-
memory databases, Proceedings of the 29th International Conference on Data
Engineering (ICDE), Brisbane, QLD, Australia, 2013, pp. 38-
49.http://doi.org/10.1109/ICDE.2013.6544812
[45] J. Li, D. Greenwood, M. and Kassem, Blockchain in the built environment and
construction industry: A systematic review, conceptual models and practical use
cases, Automation in Construction 102 (2019) pp. 288-
307.https://doi.org/10.1016/j.autcon.2019.02.005

42
[46] Z. Liu, L. Jiang, M. Osmani, P. Demian, Building Information Management (BIM)
and Blockchain (BC) for Sustainable Building Design Information Management
Framework, Electronics 8 (7) (2019) pp.
724.http://doi.org/10.3390/electronics8070724
[47] Y. Lu, The blockchain: State-of-the-art and research challenges, Industrial
Information Integration 15 (2019) pp. 80-90.https://doi.org/10.1016/j.jii.2019.04.002
[48] W. Mao, Y. Zhu, I. Ahmad, Applying metadata models to unstructured content of
construction documents: A view-based approach, Automation in Construction 16 (2)
(2007) pp. 242-252.https://doi.org/10.1016/j.autcon.2006.05.005
[49] S. Mathiyalahan, S. Manivannan, M. Nagasundaram, R. Ezhilarasie, Data Integrity
Verification Using MPT (Merkle Patricia Tree) in Cloud Computing, Engineering and
Technology 7 (2) (2018) pp. 500-506.http://doi.org/10.14419/ijet.v7i2.24.12146
[50] Microsoft, Sharepoint, 2021, Available at:https://products.office.com/en-
in/sharepoint/collaboration, Last Accessed:20th March 2021
[51] I. Mistry, S. Tanwar, S. Tyagi, N. Kumar, Blockchain for 5G-enabled IoT for
industrial automation: A systematic review, solutions, and challenges, Mechanical
Systems and Signal Processing 135 (2020) pp.
106382.https://doi.org/10.1016/j.ymssp.2019.106382
[52] S. Moon, Y. Shin, B. Hwang, Document Management System Using Text Mining for
Information Acquisition of International Construction, KSCE Journal of Civil
Engineering 22 (2018) (2018) pp. 4791–4798.https://doi.org/10.1007/s12205-018-
1528-y
[53] S. Nakamoto, Bitcoin: A peer-to-peer electronic cash system, 2009, Available
at:http://www.bitcoin.org/bitcoin.pdf Last Accessed:20 September 2021
[54] National Institute of Standards and Technology (NIST), Digital Signature Standard
(DSS), 2013, Available at:https://csrc.nist.gov/publications/detail/fips/186/5/draft,
Last Accessed:20 September 2021
[55] N.O. Nawari, S. Ravindran, Blockchain technology and BIM process: review and
potential applications, ITcon 24 (2019) pp. 209-238.https://www.itcon.org/2019/12
[56] F. Opitz, R. Windisch, R.J. Scherer, Integration of Document- and Model-based
Building Information for Project Management Support, Procedia Engineering 85
(2014) pp. 403-411.https://doi.org/10.1016/j.proeng.2014.10.566
[57] Oracle, Aconex, 2020, Available at:https://www.oracle.com/industries/construction-
engineering/aconex-products.html, Last Accessed:20th March 2020
[58] M. Park, K.-w. Lee, H.-s. Lee, P. Jiayi, J. Yu, Ontology-based construction
knowledge retrieval system, KSCE Journal of Civil Engineering 17 (7) (2013) pp.
1654-1663.http://doi.org/10.1007/s12205-013-1155-6
[59] E.A. Parn, D. Edwards, Cyber threats confronting the digital built environment:
Common data environment vulnerabilities and block chain deterrence, Engineering,
Construction Architectural Management 26 (2) (2019) pp. 245-
266.https://doi.org/10.1108/ECAM-03-2018-0101
[60] K. Peffers, T. Tuunanen, M.A. Rothenberger, S. Chatterjee, A Design Science
Research Methodology for Information Systems Research, Management Information
Systems 24 (3) (2007).https://doi.org/10.2753/MIS0742-1222240302
[61] M.A. Qady, A. Kandil, Document Management in Construction: Practices and
Opinions, Construction Engineering and Management 139 (10)
(2013).https://doi.org/10.1061/(ASCE)CO.1943-7862.0000741
[62] J. Rao, K. Ross, Cache Conscious Indexing for Decision-Support in Main Memory,
Proceedings of the 25th International Conference on Very Large Data Bases, San

43
Francisco, CA, United States, 1999, pp. 78–
89.https://dl.acm.org/doi/10.5555/645925.671362
[63] R.L. Rivest, A. Shamir, L. Adleman, A method for obtaining digital signatures and
public-key cryptosystems, Communications of ACM 21 (2) (1978) pp. 120-
126.https://dl.acm.org/doi/10.1145/359340.359342
[64] K. Salah, N. Nizamuddin, R. Jayaraman, M. Omar, Blockchain-Based Soybean
Traceability in Agricultural Supply Chain, IEEE Access 7 (2019) pp. 73295-
73305.http://doi.org/10.1109/ACCESS.2019.2918000
[65] S. Singh, B. Ashuri, Leveraging Blockchain Technology in AEC Industry during
Design Development Phase, Proceedings of the ASCE International Conference on
Computing in Civil Engineering 2019, Atlanta, Georgia, 2019, pp. 393-
401.https://doi.org/10.1061/9780784482421.050
[66] E. Sit, R. Morris, Security Considerations for Peer-to-Peer Distributed Hash Tables. ,
Proceedings of the International Workshop on Peer-to-Peer Systems, Berlin,
Heidelberg, 2002.https://doi.org/10.1007/3-540-45748-8_25
[67] M. Szydlo, Merkle Tree Traversal in Log Space and Time, Proceedings of the
Advances in Cryptology (EUROCRYPT 2004), Vol. 3027, Berlin, Heidelberg, 2004,
pp. 541-554.https://doi.org/10.1007/978-3-540-24676-3_32
[68] W. Tong, R. Goebel, G. Lin, On the Smoothed Heights of Trie and Patricia Index
Trees, Proceedings of the International Computing and Combinatorics Conference
Atlanta, GA, USA, 2014, pp. 94-103.https://doi.org/10.1007/978-3-319-08783-2_9
[69] Ž. Turk, R. and Klinc, Potentials of Blockchain Technology for Construction
Management, Procedia Engineering 196 (2017) pp. 638-
645.https://doi.org/10.1016/j.proeng.2017.08.052
[70] J. Wang, P. Wu, X. Wang, W. Shou, The outlook of blockchain technology for
construction engineering management, Frontiers of Engineering Management 4 (1)
(2017) pp. 67-75.https://doi.org/10.15302/J-FEM-2017006
[71] Z. Wang, T. Wang, H. Hu, J. Gong, X. Ren, Q. Xiao, Blockchain-based framework
for improving supply chain traceability and information sharing in precast
construction, Automation in Construction 111 (2020) pp.
103063.https://doi.org/10.1016/j.autcon.2019.103063
[72] G. Wood, Ethereum: A Secure Decentralised Generalised Transaction Ledger, 2014,
Available at:https://github.com/ethereum/yellowpaper, Last Accessed:20 August 2021
[73] G.V. Wormer, M. Larkin, Document management for design engineering,
construction, and owner operators for the new enterprise, Proceedings of the Annual
Pulp, Paper and Forest Industries Technical Conference (PPFIC), Tacoma, WA, USA,
2017, pp. 1-8.https://doi.org/10.1109/PPIC.2017.8003856
[74] F. Xue, W. Lu, A semantic differential transaction approach to minimizing
information redundancy for BIM and blockchain integration, Automation in
Construction 118 (2020) pp. 103270.https://doi.org/10.1016/j.autcon.2020.103270
[75] R. Yang, R. Wakefield, S. Lyu, S. Jayasuriya, F. Han, X. Yi, X. Yang, G.
Amarasinghe, S. Chen, Public and private blockchain in construction business process
and information integration, Automation in Construction 118 (2020) pp.
103276.https://doi.org/10.1016/j.autcon.2020.103276
[76] S. Yuan, Hyperledger Tape, 2020, Available at:https://github.com/Hyperledger-
TWGC/tape, Last Accessed:20 August 2021
[77] H. Zhang, C. Jin, H. Cui, A Method to Predict the Performance and Storage of
Executing Contract for Ethereum Consortium-Blockchain, Proceedings of the
International Conference on Blockchain, Seattle, USA, 2018, pp. 63-
74.https://doi.org/10.1007/978-3-319-94478-4_5

44
[78] S. Zhang, J.-H. Lee, Analysis of the main consensus protocols of blockchain, ICT
Express 6 (2) (2019) pp. 93-97.https://doi.org/10.1016/j.icte.2019.08.001
[79] R. Zheng, J. Jiang, X. Hao, W. Ren, F. Xiong, Y. Ren, bcBIM: A Blockchain-Based
Big Data Model for BIM Modification Audit and Provenance in Mobile Cloud,
Mathematical Problems in Engineering 2019 (2019) pp.
5349538.https://doi.org/10.1155/2019/5349538