Protecting the intellectual property of built environment designs using blockchain technology

The use of digital design and authoring tools instead of the manual design approach improved productivity and reduced the complexities in the design development process. Indeed, collaborative construction design and BIM-based design approaches improved the construction design process and construction projects overall by solving design clashes before facing them in the construction stage and by reducing the time required for design rework tasks (Adibfar et al. 2020). However, digital design files are prone to cyber threats, resulting in sensitive data leaks or design copyright infringement, especially since design files developed using BIM are data-rich models containing reusable elements (Sardroud et al. 2018). An infringement happens when a construction design is used wilfully or unintentionally without authorisation from the legal owner. However, determining ownership in a collaborative environment, wherein digital assets result from the efforts undertaken by multiple stakeholders, is difficult. A simplified ownership concept within the collaborative work can have three ownership levels: (1) contribution, which refers to a limited level of involvement in the whole development; (2) authorship refers to a substantial contribution to the development of the digital built environment asset; the authors are legally liable for the content they produce; however, they do not own the rights to control the whole asset; (3) ownership refers to the ultimate right for controlling a built environment digital asset, including transferring ownership or delegating authorship to perform modifications on the digital asset (Darabseh and Martins 2021).

Blockchain is a combination of decentralised data storage technology and cryptography. The implementation of this technology means introducing a decentralised and distributed ledger connected using cryptographic hashes. The data stored in a blockchain ledger is stored in block forms and chained together cryptographically, hence the name blockchain (Crosby et al. 2016). Data stored in the blockchain ledger is immutable, which protects it against change, thus providing an indisputable digital source of information that can be utilised in several areas, such as healthcare (Kuo et al. 2017), government (Ølnes et al. 2017) and finance (Tapscott and Tapscott 2017). In construction, there is a growing number of studies investigating the possible uses of blockchain to improve digital processes. The literature includes several examples of blockchain applications in fields such as BIM (Turk and Klinc 2017), digital twins (Celik et al. 2021), supply chain (Li et al. 2022) and payments (Luo et al. 2019).

Investigating blockchain for construction-related purposes is still considered limited from a development standpoint. However, there are several limitations to adopting blockchain in construction-related applications: (1) scalability in public blockchains, whereby public blockchains use consensus to accept transactions on their ledger, limiting its ability to process transactions faster; (2) cost of adoption, whereby the costs for developing blockchain networks and upgrading the current digital infrastructure to support the technology are considered barriers to adopting this technology; (3) legal ambiguity, whereby the use of blockchain is currently not regulated; therefore, regulations are needed to provide legal coverage for the use of blockchain within construction-related activities (Darabseh and Martins 2020).

Blockchain’s capability to create an immutable record digitally can provide proof–of-ownership rights for content creators. Digital content is easily replicated, and it is hard to track whether users have respected the rules for use defined by the content owner. Protection of digital content from unauthorised use is the main concern for digital content producers in industries, such as entertainment, literature and software. Examples of studies in which blockchain was used to combat intellectual property infringement follow.

Jing et al. (2021) studied plagiarism in the software development process and the unauthorised use of code. Their study presented a blockchain-based copyrights management system for combating copyright infringement. Their system used ANother Tool for Language Recognition (ANTLR), a software that identifies code using lexical and syntactic analyses to generate a digital fingerprint and adds it to the blockchain system to find plagiarised content.

Chi et al. (2020) presented a system for book publishing using blockchain to secure content and the purchasers’ right to read the book. The system deploys public and private blockchains to create a decentralised book publishing experience, providing a transparent and effective literature management process. Public blockchains store metadata of the literature and purchasing records, which guarantee access to the buyer and royalties to the author. Book content is stored on a private blockchain to ensure that it is only accessible to authorised people who acquire reading rights.

Protecting 3D designs with blockchain is a growing field of research, with solutions that fall into two main classes. The first approach is securing the design transfer process, such as creating a safe channel to access 3D designs with a controlled environment in which designs are protected from unauthorised copying or accessing. Examples of such studies are those by Alkaabi et al. (2020) and Holland et al. (2017), who studied the additive manufacturing process and how to create a blockchain protected design distribution system. The second approach involves certifying design ownership by generating a blockchain-based ownership certificate. Mouris and Tsoutsos (2022) presented a framework for protecting computer-aided design (CAD) 3D designs produced for digital manufacturing by creating a fingerprint of these designs using design spectrogram patterns generated using multidimensional fast Fourier transform and then storing the generated pattern into an NFT to function as the ownership certificate for the design owner.

The study utilises blockchain to tokenise BIM designs as NFTs. The NFT content includes the design ownership information and a multi-dimensional identity. The first dimension of the identity is the global unique identifier (GUID) list, and the second is the IFC entities hash list. The third dimension is the content identifier (CID) list. The NFT metadata is generated based on the ownership information and the generated identity. A standard Ethereum Request for Comment (ERC)-721 smart contract was deployed and invoked to bind the design to an NFT.

NFT is utilised here to provide proof of ownership for the built environment design based on IFC files. To achieve this, a fingerprint for designs needs to be developed because storing the design itself directly on the blockchain is not feasible, as transaction costs increase according to the content size attached to the transaction. Furthermore, design files have legal liability and defined privacy and sharing rules; therefore, the NFT content should be established considering these factors, using an NFT that merges two groups of information: (1) ownership information; and (2) IFC design file fingerprint. The fingerprint can be defined as a characteristic or an attribute that helps identify its origin. The designed fingerprint has three aspects, as explained in the following sections.

3.2.1

Identifying a design based on the IFC schema specifications

IFC files follow the IFC schema. At the time of writing, IFC 4.0.2.1 is the official version (BuildingSMART 2020a). The schema specifies that IfcRoot is a super-type of all IFC entities. Each entity that is a subtype of IfcRoot can be defined through a set of identity attributes, which are as follows: (1) GUID (BuildingSMART 2020b), which is a global identifier for the object as defined in International Organisation for Standardisation/International Electrotechnical Commission (ISO/IEC) 11578:1996 (ISO, 1996); (2) owner history, which includes information about the current owner of the object; (3) name, which is a label that reflects the purpose of the object; and (4) description, a set of information that contains comments about the object. Therefore, designs can be referenced according to the GUID for the objects found in the IFC file. The first dimension of the design fingerprint is a list of GUIDs extracted from the IFC file and stored in a separate JavaScript Object Notation (JSON) file using Ifcopenshell, a Python library designed to process IFC files. Figure 1 shows an example of GUIDs highlighted within an IFC entity.

Fig. 1:

3.2.2

Identifying a design file based on entities hash list

The IFC file format is a human-readable data exchange serialisation similar to eXtensible Markup Language (XML) and JSON formats (Wright et al. 2020). This means that the content of the IFC file can be explored as text; therefore, it is possible to perform a cryptographic identification operation on IFC files as text. The IFC file contains three sections: header, body and footer, as shown in Figure 2. The body stores the list of design elements. Each model element is represented as an entity that starts with “# “regardless of the element’s geometric or semantic nature.

Fig. 2:

Sharing the list directly means sharing the full design details; therefore, the second dimension of this fingerprint is a hashed list of the entity list inside an IFC file. In order to generate the hash for each entity, the hashlib library (Python Foundation 2022) in Python was used with the parameters defined in Table 1.

Tab. 1:

Hash formula used to generate the entities hash list.

Parameter	Value	Parameter description
Hashing algorithm	SHA256	Determine the desired hashing algorithm
Salt	IFC	Salt is a set of characters used to increase the complexity of the original hashed content
Iteration	1	Number of times that the hash should be rehashed
Length	64	The number of characters in the generated hashes

IFC, Industry Foundation Classes; SHA, Secure Hash Algorithm; SHA, Secure Hash Algorithm.

SHA256 (Gilbert and Handschuh 2004) was used as a hashing algorithm because, in addition to its collision resistance capabilities, it provides a high level of encryption, resulting in unique hashes when the content is different. Table 2 shows examples of the inputs and outputs of this process.

Tab. 2:

Examples of the input and output of the hashing function.

Input (entity)	Output (SHA256 hash)
#12=IFCDIRECTION((1.,0.,0.));	“3d896c6580d86c5895a178d5bdb45ec3901cf3118881495c86caf38b70730a5b”
#14=IFCDIRECTION((-1.,0.,0.));	“fd7a34687b10e217a47657bd93c49340ed00fa59a2f8667a072453160aef9767”
#16=IFCDIRECTION((0.,1.,0.));	“8eeea131de37b45cc0057d63a7e115942257f3315791061adca5ff0704e7f9ea”
#18=IFCDIRECTION((0.,-1.,0.));	“69f375f1c87d560e5981d8168070afdcf6f85953cad3e9d9b6a7e8b218a0c327”

IFC, Industry Foundation Classes; SHA, Secure Hash Algorithm.

3.2.3

Identifying a design file based on its InterPlanetary File System (IPFS) CID

InterPlanetary File System (IPFS) is a peer-to-peer file storage system and an essential element for blockchain-based applications as it removes the centralised storage of the application and replaces it with decentralised storage, which contributes to the application’s decentralisation robustness (Chen et al. 2017). However, since IPFS is content-addressed, files are accessed according to a unique hash generated based on their content. This identifier, or CID, uses the multihash formula to create self-describing hashes to identify files uniquely (Protocol Labs 2022). The CID is an absolute pointer for the content it represents; therefore, a change in the file will result in a new CID. When a file is added to the IPFS system, it is first processed into data chunks of a defined size (currently 265 KB), and then a CID is generated for each chunk; finally, all the individual chunks’ CIDs are hashed to generate the file CID. The CID is a pointer to data, not the data itself. This process generates a Merkle directed acyclic graph (DAG) (Protocol Labs 2020), a common tool to identify cryptographic files, whereby a file can be broken into a defined set of pieces and defined leaf’s structure. Each leaf has a hash in the Merkle trees representing the partially hashed file. This approach is commonly used in software development to identify changes and code versioning. The process is illustrated in Figure 3, which shows a DAG for two examples using 32-byte chunks instead of 256 KB, the default chunk size in the IPFS system (Discuss IPFS 2019). In the example, the word “example” was removed from the original text referred to in Figure 3 as Input 1, which resulted in a change in the content of the final 32-byte chunk, which then affected the chunk CID, and as a result, the CID representing the whole file changed when the input text changed.

Fig. 3:

This concept can be applied to IFC files to generate another dimension for the IFC file fingerprint. Storing the IFC on the IPFS public network will make it accessible to anyone with the IFC CID. Instead, the IFC file can be stored on a private IPFS network to avoid this issue. Users can generate the file CID and sub-CIDs and thereby limit file access to only the members of the private IPFS network. The ipfshttpclient Python library (IPFS Shipyard 2021) can be used to add files to the IPFS network and retrieve the file CID sub-CIDs. The library stores the fingerprint dimension files in the IPFS network, which is used later in the NFT generation process.

The NFT creation process follows the Ethereum standard ERC-721 (Entriken et al. 2018), which specifies the requirements for NFT smart contracts. An ERC-721 NFT is ownable and transferable. An NFT issued according to the ERC-721 should also have a set of characteristics that make it unique, rendering it identifiable. These characteristics vary depending on the NFT’s purpose. Common characteristics of NFTs are as follows: (1) they originate from a smart contract; (2) the smart contract sets the name and symbol, which comprises three or four letters used to identify a smart contract; (3) ID number to internally identify within the smart contract; (4) each NFT has a metadata file accessed through a uniform resource identifier (URI) (Mozilla Developer Network [MDN] 2022). These metadata files are structured in a JSON schema according to the template provided by the ERC-721 standards.

In order to facilitate the smart contract development process and overcome the security concerns of writing smart contracts, the OpenZeppelin (2022) team created a set of smart contracts written in Solidity, which is one of the accepted programming languages for writing smart contracts for the Ethereum public blockchain and other Ethereum virtual machine (EVM)-compatible blockchains. These contracts can be used in two ways: (1) the contract can serve as a template where the developer fills the needed variables and then deploys to blockchain; or (2) a new contract can inherit classes from these contracts. The Open-Zeppelin team provides multiple versions of ERC-721-compatible smart contracts to meet the needs of NFTs.

Blockchain development frameworks are another tool used in developing smart contracts and decentralised blockchain applications known as DApps. Frameworks provide a set of tools to facilitate the development process, such as a local testing blockchain and an interface to deploy and interact with the blockchain. Truffle is the most popular framework, which uses JavaScript programming language (ConsenSys 2022); however, in this article, the Brownie framework is used as it is a Python-based framework (Brownie 2020), which is aligned with the remaining parts of the developed code. Brownie provides scripts to interact with smart contracts according to their purpose. Each set of scripts is called a mix (Brownie Mixes 2022). An example of such mixes is the NFT mix. The NFT mix provides advanced and simple NFT deployment options. The simple collectable deployment is a template for deploying a smart contract based on ERC721.sol, which is the standard version of the OpenZeppelin ERC-721-compatible smart contract, however, without using an external data feed. The simple collectable deployment approach is used for this article as the purpose of the smart contract does not require a connection to off-chain information.

It should be stressed that creating the smart contract and creating an NFT are two separate processes, even though one is created to enable the other. The smart contract serves as an NFT factory, as NFTs are created by invoking the smart contract. When using Brownie for creating an NFT smart contract or minting an NFT, two elements are needed: (1) Infura Project ID, where Infura (Infura 2022) is an Ethereum application programming interface (API); (2) Ethereum wallet private key, generated using MetaMask (MetaMask 2022) Web wallet. After creating the required information, it is added to the running operating system as environment variables. The next step is defining the NFT name. This name is used to identify the NFT collection and the symbol, which is an abbreviation of the name. In the deployed contract, the NFT name was Building Designs, and the symbol was BDS as the aim of the NFT collection was to prove building design ownership; however, the name could be assigned according to the developer’s wishes without restrictions according to the ERC-721 standards. Figure 4 shows the smart contract.

Fig. 4:

The first lines of the smart contract define the desired compiler version (in this case, 0.6.6 for Solidity), followed by an import statement for the OpenZeppelin ERC-721 smart contract template. The next part of the smart contract is the constructor that initialises the contract, which inherits the ERC721 contract functions imported earlier. The constructor also defines the name and symbol of the NFTs originating from this contract. Furthermore, the constructor maps the number of NFTs generated by the contract. A minting function is defined after the constructor. The first statement defines who is minting the NFT, followed by the URI of the NFT. Then, the number of NFTs is incremented by one before generating the next token.

After developing the smart contract, the next step is to compile it and deploy it on a test network. The smart contract was compiled and developed on the Rinkeby test net network, one of the Ethereum test networks, using the deploying script provided by the Brownie framework. Figure 5 shows the smart contract deployment transaction on Etherscan.io Ethereum transaction explorer (Etherscan 2022). The transaction page shows the address assigned to the smart contract on the blockchain.

Fig. 5:

The smart contract defines the name of the NFT collection and its symbol. The content of the NFT and what it proves is defined by the metadata of the NFT itself. The metadata URI for each NFT is stored in the blockchain when an NFT is generated. Therefore, the JSON metadata file was designed to accommodate the IFC fingerprint to prove design ownership according to the template in the ERC-721 standard. Figure 6 shows the metadata data example that complies with the JSON schema developed to store the fingerprint filled with information about a sample design.

Fig. 6:

The schema contains two types of information: (1) basic identifying information, such as the name and description of the design, the author information, the original owner information and attributes for the IFC design file (such as the schema), the original authoring application and the organisation where the design was developed. (2) CIDs as links for files stored on the IPFS storage system, which can be used to identify the design file. The original IFC file is stored on a private IPFS network; however, the IFC identification fingerprint files are hosted on the public IPFS network.

After developing the NFT metadata JSON file and storing it on the public IPFS node, an NFT can be minted by invoking the deployed smart contract. The script of the Brownie framework to mint an NFT was used after adding the NFT URI to it, as shown in Figure 7. The figure shows that the URI is defined as the NFT URI, and then the minting of the deployed smart contract is called.

Fig. 7:

After invoking the smart contract, an NFT is generated and assigned an ID by the smart contract. The first NFT gets the ID 0. The transaction details show the IPFS CID for the minted NFT, as shown in Figure 8.

Fig. 8:

The NFT can be viewed in the OpenSea marketplace (OpenSea 2022) for NFTs to ensure that it is ERC-721 compliant. Figure 9 shows that OpenSea recognises the NFT minted as ERC-721 and the NFT attributes defined in the metadata JSON file.

Fig. 9: