Blockchain-Enabled Provenance Tracking for Sustainable Material Reuse in Construction Supply Chains ^†

Abstract

The growing complexity of construction supply chains and the significant impact of the construction industry on the environment demand an understanding of how to reuse and repurpose materials. In response to this critical challenge, research gaps that are significant in promoting material circularity are described. Despite its potential, the use of blockchain technology in construction faces challenges in verifiability, scalability, privacy, and interoperability. We propose a novel multilayer blockchain framework to enhance provenance tracking and data retrieval to enable a reliable audit trail. The framework utilises a privacy-centric solution that combines decentralised and centralised storage, security, and privacy. Furthermore, the framework implements access control to strengthen security and privacy, fostering transparency and information sharing among the stakeholders. These contributions collectively lead to trusted material circularity in a built environment. The implementation framework aims to create a prototype for blockchain applications in construction supply chains.

1. Introduction

The construction sector significantly impacts climate change by being accountable for 39% of total greenhouse gas (GHG) emissions [1], and it consumes approximately 32% of all extracted natural resources [2]. According to the European Green Deal [3], construction supply chains require immediate attention as a critical area for action. The European Commission has initiated a set of policy measures to achieve carbon neutrality for the European Union by 2050.

Addressing the building sector’s environmental impact necessitates a paradigm shift towards a more circular supply chain model in which material reuse is not an afterthought but a fundamental principle. The primary impediment to achieving this goal is the lack of reliable tracking systems, which are essential for monitoring the movement and condition of construction materials. Reliable tracking is the foundation that allows materials to be confidently reclaimed, classified, and redirected for reuse. Without such systems, it is nearly impossible to verify the quality, safety, and compliance of materials, resulting in potential risks and inefficiencies during reuse. The ability to trace a material’s history, from its inception to its entire life cycle, is critical for a sustainable construction ecosystem that prioritises resource conservation and waste minimisation.

The Ellen MacArthur Foundation [4] is one of the non-profit organisations that promotes the principles of the circular economy (CE). They have introduced the idea of a “material passport” (MP) to promote the traceability of products within a circular supply chain. An MP is a document that tracks a product’s journey from the extraction of raw materials to the end of its life. It helps to share information across the supply chain in a timely manner. The MP contains comprehensive information about the composition of a product, its location, and its impact on the environment. Many industry projects have realised the potential of the MP and implemented it in their projects, such as Madaster [5], ORMS [6], and Buildings As Material Banks (BAMB) [7]. The use of MPs can help in tracking materials/products in the entire construction supply chain and identifying their origins. Having more details about construction materials can lead to more efficient and less wasteful building construction processes. Furthermore, MPs can also be utilised to dispose of materials properly once they are no longer useful.

Although MPs have proven to be beneficial in the construction sector, there still remain limitations to achieving the desired sustainability outcomes. One of the significant challenges in generating MPs is the absence of unified approaches or standards. This lack of standardisation results in the use of different terminologies and processes in MPs, which reduces their usefulness for other partners in the construction industry. Additionally, the construction supply chain involves multiple stakeholders who manage a product at various stages of the process, which makes it challenging to always keep the MP updated throughout the life cycle of the product. There are also challenges associated with confidentiality while sharing business information in MPs. In this context, we will explain how MPs can be used while mitigating the impact of these limitations.

Blockchain technology offers a promising solution for improving provenance tracking in the construction industry. Its decentralised approach eliminates the need for a central authority, resulting in a transparent and collaborative environment in which all stakeholders can access information. The immutability of a blockchain ensures that once a record is entered, it cannot be changed, resulting in a tamper-proof history of materials. This fosters trust and reliability. Smart contracts also automate and enforce transaction terms, making it easier to exchange information securely. By utilising these features, blockchain technology provides a high level of detail and accountability in provenance tracking. This is critical for certifying the quality, safety, and sustainability of repurposed materials. This not only supports environmental goals but also promotes the CE by extending the lifespan of resources. Our contributions are as follows:

• We propose a novel framework that uses a multilayer blockchain to improve data retrieval and provenance tracking, allowing for a reliable audit trail for material reuse.
• We propose a privacy-centric storage solution that combines the InterPlanetary File System (IPFS) with backend servers, balancing decentralisation and robust data management to secure sensitive information while maintaining transparency in material provenance.
• The framework implements efficient access controls, strengthens security and privacy, and promotes transparency and information sharing among stakeholders, all of which are vital for trusted material reuse in construction supply chains.

This paper is an extended version of the work published in [8]. The rest of the paper is structured as follows: Section 2 surveys the related work in this area. Section 3 describes the motivation as well as use case scenarios for the work. Section 4 discusses the blockchain platform we have adopted in this work and its components. Section 5 elaborates on the system’s architecture and deployment of the blockchain-based implementation. Section 6 provides an evaluation of the performance and security features of the proposed architecture. Section 7 concludes this work by describing key findings and providing suggestions for future work.

2. Literature and Related Works

This section consists of three parts. Section 2.1 describes work on material reuse in the construction industry and existing barriers to achieving such reuse. Section 2.2 describes the existing work that makes use of a blockchain to support circularity in the built environment. Research gaps based on an analysis of the existing work are then described in Section 2.3.

2.1. Material Reuse and Circularity

Harala et al. [9] investigated the changes required within industrial ecosystems to enable benefits from reuse within the industry. Their survey focused on reuse instead of recycling, analysed the prerequisites for material reuse, and identified how various actors in the industry must collaborate to achieve it. One key point from this survey is the need for effective stakeholder collaboration to achieve the benefits of reuse within construction supply chains. However, the study did not address any implementation models or technologies to mitigate the challenges. Ginga et al. [10] described how the growing volume of construction and demolition waste (CDW) poses a significant challenge to global waste management practices and sustainability goals. They provided a comprehensive analysis of the current state and potential of circular economy (CE) frameworks for reducing CDW’s environmental impact. They emphasised the importance of transitioning from traditional landfill practices to more sustainable material recovery and reuse methods. The authors argued that adopting circular models can significantly reduce CDW volume while also extending material life cycles and contributing to environmental sustainability. Their findings indicated that recycled construction materials have comparable physical and mechanical properties to virgin materials, supporting the feasibility and environmental benefits of incorporating recycled components into new construction projects. However, the study noted that the scarcity of quantitative studies on reuse compared to recycling research restricts the understanding of its benefits.

Davari et al. [11] pinpointed traceability as the key aspect in the transition towards a CE. However, achieving traceability is difficult due to the complexity of construction projects and the lack of proper awareness about its benefits. In order to successfully implement traceability, it is necessary to have complete information about the material’s path from raw materials to deconstructed entities. The authors proposed an elaborate traceability framework to enable material traceability to implement circularity. Nevertheless, the framework’s reliability and effectiveness, though theoretically sound, have yet to be fully tested in practical scenarios. Bertino et al. [12] described the construction industry’s significant environmental impact, emphasising the critical need to shift from a linear model of resource consumption to a CE framework. The authors argued that deconstruction—the selective dismantling of building components with the goal of future reuse, repurposing, or recycling—is critical to this paradigm shift. In contrast to traditional demolition, which is often quick and wasteful, deconstruction provides an approach to reducing waste and encouraging the circular flow of materials within the urban environment. The authors advocated for a comprehensive deconstruction methodology to be embedded throughout a building’s life cycle, presenting a sustainable alternative that reduces not only the environmental impact but also provides secondary resources to the construction sector.

Vahidi et al. [13] identified the urgent need for advanced digital solutions in the construction industry for effective product tracking and information sharing among the stakeholders in circular supply chains. They discussed the potential of the material passport (MP) for sustainable resource management and as a means to increase the circularity of materials. Their work explored the feasibility of using radio frequency identification (RFID) technology as an MP to enhance sustainability in the concrete industry. However, their work may inherently contain a vulnerability as the loss/damage of RFID tags could lead to significant information loss, challenging the integrity and effectiveness of the approach. The survey paper by Benachio et al. [14] examined the construction sector’s transition from a traditional linear economic model to a CE framework. This shift is critical given the industry’s significant impact on natural resource extraction and solid waste production. This paper covered six key areas: CE development, material stocks, material reuse, the CE in built environment design, MPs, and a life cycle assessment (LCA) analysis. They identified the need to raise awareness on the adoption of CE practices, the difficulties associated with standardising methods for practical implementation, and the importance of incorporating CE principles early in project design to increase material reuse to reduce environmental footprints. However, the lack of universally accepted standards and practices significantly hinders the adoption of CE principles in real-world projects.

Crawford [1] discussed the need to adopt sustainable practices in the construction industry. Crawford’s work provided a detailed analysis of the environmental impact of construction activities worldwide, emphasising the sector’s significant contribution to global greenhouse gas (GHG) emissions. According to the study, the production and processing of construction materials not only consumes a lot of energy but also produces significant ${\mathrm{CO}}_2$ emissions, which contributes to the industry’s environmental impact. Adams et al. [15] provided in-depth insights into the implementation of CE principles in the construction sector. They assessed the current level of awareness and implementation challenges of CE practices, shedding light on the critical barriers to their widespread adoption in the construction industry. Key challenges identified included a lack of material standardisation, difficulties in assessing material life cycle impacts, and economic and regulatory barriers that impede the transition to circularity. Their work identified several enablers that could help with the adoption of CE principles, including technological innovation, policy and regulatory support, and the creation of new business models that prioritise sustainability and resource efficiency. Furthermore, the authors pointed out the need for the development of standards and frameworks to bring more collaboration and information exchange to the construction industry.

2.2. Transparency and Traceability in Construction

Publications [16,17,18,19,20] have identified the use of blockchain technology in supporting circularity in the construction industry. These references identified the need to securely share information and support interoperability between different blockchain systems as key challenges to be addressed. Kouhizadeh et al. [16] looked at the intersection of blockchain technology and the circular economy (CE), emphasising its potential to transform industry practices. This research used industrial case studies to identify the transformative benefits and challenges of blockchain in improving supply chain transparency, efficiency, and security, all of which are critical for CE implementation. Their work identified that, despite the enthusiasm for blockchain’s capabilities, its adoption is still primarily in the pilot stage, hampered by interoperability, technological security, and stability issues. Dutta et al. [17] discussed blockchain technology as a transformative force in the supply chain, emphasising its ability to improve operational efficiency, data management, and transparency across both global and local supply chains. Their work provides a comprehensive overview of blockchain’s promising role in the supply chain by delving into its architecture and applications across various sectors. It emphasises blockchain’s ability to provide a competitive advantage by addressing the need for the standardisation and integration of diverse blockchain systems.

Singh et al. [18] presented an insightful survey on the barriers to blockchain adoption in the construction supply chain, emphasising the need for transparency among the participants in the supply chain. Experts from different fields validated these barriers and emphasised the need to overcome them for blockchain to be effective. Among the various barriers discussed, the need for interoperability and standardisation across different systems and platforms was emphasised. Li et al. [19] made a significant contribution to understanding blockchain’s potential for improving circular supply chains in the built environment. Their work investigated the various ways blockchain technology can be used to promote sustainability and efficiency in construction supply chains. The authors argued that a blockchain improves transparency and accountability in material sourcing and usage, making it easier to implement CE principles for secure and immutable records of material life cycles. Incorvaja et al. [20] offered insightful integration of CE principles into construction supply chains. They emphasised the critical importance of implementing CE frameworks to improve sustainability and efficiency in construction supply chains. They emphasised the potential of CE practices to reduce waste and environmental impacts while also creating economic value through material recovery and reuse. Their paper discussed blockchain technology’s potential as a transformative tool to support product provenance and tracking. Implementing an Ethereum-based use case scenario for the reuse of LED light fittings, the work aimed to answer key questions about the technology’s ability to support traceability in construction supply chains and the specific data required for material reuse.

2.3. Research Gaps

Despite the advancements made by integrating blockchain with the construction supply chain, there are still areas for consideration, such as verifiability, privacy, scalability, and interoperability between blockchains. Additional work is needed to support verifiability in the development of trustworthy product provenance monitoring systems. This involves recording ownership changes across the lifespan of the product, enhancing accountability and ensuring the quality and compliance of materials to be reused. Promoting data privacy within an ecosystem that requires information exchange is a difficult task to accomplish. Additional research that leverages the inherent strengths of blockchain technology to support transparency in supply chain transactions whilst maintaining confidentiality is also needed. The challenge of scalability in supply chains must consider both the handling of increasing data volumes and the integration and collaboration of multiple stakeholders from various projects and organisations. This also points to the need for interoperability between different blockchain platforms. In addition, there is limited research which focuses on information exchange among diverse blockchain networks to guarantee smooth operations and collaboration among projects and stakeholders. Our work seeks to address these research gaps by the provision of a blockchain with access control mechanisms and decentralised data storage to promote circularity in construction supply chains as a step towards addressing these challenges.

3. Motivation and Reuse Scenario

Our proposed framework aims to provide features that are essential for advancing circular economies within supply chains. The material passport (MP) design enables dynamic updates that ensure the complete transparency and traceability of materials from their origin to destruction/decommissioning or reuse, providing a chain of custody that stakeholders can trust. The architecture of our system is built to support seamless interoperability across different data systems, enabling collaboration across diverse stakeholders. The following important questions are considered in this work:

• Q1: Is this approach capable of ensuring the tracing and tracking of products and materials through the entire supply chain while also providing updates on their current status within the supply chain?
• Q2: Does this method facilitate the accuracy and autonomy of data for all supply chain participants?
• Q3: In what ways can the use of MP and its supporting systems help to integrate material information with other critical systems across the network while also supporting scalability as the supply chain’s participants grow?

The implementation and design of our framework aim to achieve the objective of the questions discussed above. (i) Verifiability: Storing supply chain information on a typical database does not ensure data security inherently. However, blockchain can provide a solution to this problem by allowing information to be verified without the requirement for a trusted third party. This promotes confidence among participating entities by guaranteeing that the product’s integrity is upheld and that it originates from the stated source. (ii) Privacy: The information stored on the public blockchain systems is visible to the participating entities in the network. For enhanced privacy, organisations can employ privately managed blockchains, which allow for controlled visibility. When multiple organisations are part of a construction-like project, these individual blockchains need to interact with one another, highlighting the importance of blockchain interoperability. This setup enables each entity to control its private information and blockchain while selectively sharing data with other project participants as necessary. Our framework utilises parachains to facilitate this process effectively. (iii) Minimum on-chain information: Storing every detail of a particular product on a blockchain is not practical due to scalability issues. To address this, we opt to keep the data off-chain while retaining a reference on the blockchain for accountability. Our design incorporates the InterPlanetary File System (IPFS), which helps in maintaining data accessibility, eliminating the risk of a single point of failure and safeguarding against data tampering. (iv) Provenance: During its life cycle, a product can change hands multiple times. To evaluate its condition and know how long it has been in use, accessing its full history is crucial. To facilitate this, we have established a system for provenance tracking, enabling the tracing of a product’s journey back to its source using blockchain technology.

3.1. Wood Reuse Scenario

To effectively demonstrate our proposed framework, we use a wood construction supply chain scenario that exemplifies our system’s capabilities. This scenario, as depicted in Figure 1, involves a series of events spanning seven distinct entities, each representing an interconnected role in the supply chain. It starts with the manufacturer, who sources raw materials and creates the initial product while also generating an MP for it. The MP serves as a comprehensive digital document that describes the product’s characteristics. The manufactured goods are then routed through a network of warehouses that serve as intermediaries, temporarily storing the products before they reach end users in the construction industry.

When the products reach the end of their intended life cycle, they enter a reuse loop and are rigorously evaluated. If appropriate, they are refurbished to meet strict reuse standards before being reintegrated into the supply chain and used for new purposes. This loop not only extends the materials’ life cycle but also emphasises the principle of circularity. When materials are deemed unsuitable for reuse, they are recycled, effectively closing the loop. The MP is an essential component of this process as it is constantly updated to reflect current ownership, transaction timestamps, and the product’s operational history. Such provenance reinforces trust and confidence in the wood construction supply chain, leading to more sustainable practices.

4. Platform Selection: Polkadot

The balancing act between decentralisation, security, and scalability is a common challenge faced by developers of blockchain applications and solutions; it is referred to as the “blockchain trilemma.” Since striking a balance between these three is extremely difficult, applications are limited to incorporating no more than two of them. For the development process to optimise the performance of the other two, one must be sacrificed. Decentralisation has typically been prioritised over scalability in the development of blockchain services. As a consequence, applications frequently exhibit reduced scalability in comparison to standalone systems [21]. Belchior et al. [22] suggested that the issues related to scalability can be overcome by implementing interoperability. Interoperability is defined as a blockchain’s ability to perform transactions and process ledgers on other blockchains that are either homogeneous or heterogeneous in nature with the option of verifying transactions on both sides. There are different platforms that provide interoperable blockchain solutions, such as Cosmos [23], Ark [24], Avalanche [25], Cardano [26], and Polkadot [27]. Belchior et al. [28] analysed multiple solutions and suggested that Cosmos and Ark could connect up to two heterogeneous blockchains, which is a limitation in situations with more than two heterogeneous platforms and identifies Polkadot as suitable to deal with more than two heterogeneous blockchains.

Polkadot is a blockchain platform jointly created by the Parity Technologies and Web3 Foundation. It was introduced in 2020 with the intention of facilitating blockchain interoperability. This multi-chain technology enables seamless communication between existing heterogeneous blockchain networks via network bridges while also facilitating the rapid development of new chains [27]. Polkadot is constituted of a number of components and consensus processes to attain interoperability.

4.1. Relay Chain

The relay chain is the Polkadot network’s foundation layer. It allows shared communication between heterogeneous and independent blockchain networks (parachains), thus making the blockchain truly decentralised. The relay chain enables transactions from all chains in the network to be processed at the same time, and only a subset of the transaction results in sovereign blockchains may be advertised to the rest of the Polkadot network. The relay chain also provides a shared security model for all connected networks by its consensus mechanism.

4.2. Parachains

Parachains are blockchains that can function independently and in parallel and are fully customisable by their owners. They may be application-specific and also come with their own suite of programming logic. Parachains are connected to the relay chain, which gives additional benefits such as interoperability between different blockchain networks, shared consensus, and network security adopted from the relay chain. Every parachain can communicate with other parachains using the Cross-Consensus Message Passing (XCMP) protocol [29].

4.3. Validators

Validator nodes are responsible for maintaining the relay chain. They are responsible for the creation and verification of new blocks. Every parachain has a unique group of validators for approving the new relay chain blocks. To control desired behaviours, validators have to stake their own funds in the blockchain network as part of the NPoS (Nominated Proof of Stake) algorithm.

4.4. Collators

Collators are nodes responsible for collecting the states of blocks and then submitting them to the relay chain through the validators. Collators are the full nodes of the relay chain and the specific parachains in which they belong. Being full nodes, they can access all transaction-related information and create new blocks that the respective validators of the parachain may validate. Since the collators are the full nodes of the relay chain, all the collators of the network know the existence of other collators, enabling them to communicate efficiently. The collators know about every parachain transaction [30].

4.5. Nominators

Nominators have the responsibility to secure the network by responsibly selecting the validators. They are Polkadot’s passive entities, and their benefits depend on the good behaviour of the validators they select. Nominators stake DOTs (Polkadot’s coin) and choose reliable validators to protect the relay chain.

5. Implementation

The use case scenario described in Section 3.1 is implemented using material passports (MP), the IPFS for decentralised storage, backend servers, and Polkadot as the blockchain platform as shown in Figure 2. In the designed use case for our blockchain architecture, we define a system in which the manufacturer, logistics, and construction companies operate as separate entities, each with its own dedicated parachain. This specialised blockchain infrastructure enables tailored functionalities and governance models to meet the needs of each ecosystem participant. The manufacturer begins the product’s life cycle by creating an MP that contains all relevant information about the product’s origin, characteristics, and history. This MP is then pushed on the relay chain, which serves as the Polkadot network’s central communication hub, ensuring interoperability across the entire blockchain. Ownership is a critical component of this architecture, and the smart contract deployed on the manufacturer’s parachain records the initial ownership status. It strictly enforces that only the recognised owner can transfer ownership rights, preventing unauthorised transactions.

5.1. Architectural Components

We describe the integral role of backend servers and the IPFS within our framework; the functionality of parachains are discussed in Section 4.

5.1.1. Backend Servers

The inclusion of a backend server in our architecture is critical for supporting the cost-effectiveness of blockchain technology. This decision was based on a number of technological and economic factors as not all information needs to be stored on the blockchain. The blockchain’s immutability and distributed nature make it ideal for storing data that require verification and audit trails. However, the cost of storing massive amounts of data on the blockchain is significant. This cost, also known as ’gas fees’, increases with the amount of data stored. Hence, the efficient use of blockchain storage is critical for cost management. Furthermore, accessing data stored on the blockchain is not free of charge. Reading information, while less resource-intensive than writing data, still incurs a fee in many blockchain implementations. This aspect emphasises the importance of being selective when storing data on the blockchain. The architecture proposes using the blockchain as a repository for data references, with the actual data stored off-chain. This approach leverages the blockchain’s strengths in data integrity and verifiability while lowering the storage costs and technical constraints associated with direct data storage on the blockchain. Another major concern is the management of sensitive information. Blockchain data are inherently transparent, and once recorded, they are unchangeable. While these characteristics improve auditability and trustworthiness, they are not suitable for storing private or sensitive data. As a result, the architecture carefully separates sensitive data and stores them off-chain to ensure confidentiality and compliance with data privacy regulations. The strategic integration of backend servers into our architecture is more than a technical preference; it is a requirement driven by the blockchain’s inherent characteristics and the economic realities of its application. This design choice makes our solution scalable, secure, and cost-effective.

5.1.2. InterPlanetary File System

The InterPlanetary File System (IPFS) operates as a network-driven protocol, offering an efficient and decentralised solution for the storage and distribution of files online. This approach stands in contrast to the traditional, centralised models of server-based storage and web hosting. Four foundational components of the IPFS guarantee its security, high performance, and data throughput. These components are self-certifying file systems (SFS), a distributed hash table (DHT), a Merkle DAG structure, and a BitSwap protocol [31]. Unlike a distributed database, the IPFS serves as a distributed file system. The MP can encapsulate diverse types of data, including textual product information and CAD drawings of building plans, among others. If blockchain is used to store all this information, then decentralised storage would be unnecessary. However, the immutability of information on the IPFS, coupled with the practice of recording the content identifier (CID) from the IPFS as a reference on the blockchain, introduces an additional layer of security. Any alteration on the stored information results in the creation of a new CID.

In our framework, the MP is stored within the IPFS, with its CID maintained on the blockchain. This methodology presents two key advantages: first, it ensures data immutability through the generation of new CIDs upon data changes; second, it addresses the risk of single-point failure associated with centralised storage solutions thanks to its distributed nature. Incorporating the IPFS into the architecture is a strategic decision that seeks to capitalise on the advantages of decentralised storage while addressing the limitations and challenges associated with traditional data storage methods and the blockchain. Although blockchain technology offers unparalleled security and immutability, it is not intended for efficient large-scale data storage. To ensure cost-effectiveness and performance, not all information, particularly large data files, should be stored directly on the blockchain. Using centralised databases to store sensitive information increases the risk of data tampering and manipulation. Centralised storage facilities can become targets for malicious attacks, exposing the confidentiality and integrity of information. Such vulnerabilities are a major source of concern in applications that rely on data accuracy and authenticity. Storing data on the IPFS can provide a high level of security and reliability, similar to the blockchain, but without the high costs associated with on-chain data storage. The IPFS’s decentralised system distributes data across multiple locations, reducing the likelihood of data loss or tampering. Integrating the IPFS and blockchain technology can greatly improve data security and integrity. Instead of storing actual data on the blockchain, only IPFS hashes are stored, which helps to leverage the blockchain’s immutability. This approach ensures that the data references cannot be changed, ensuring the verifiability of data integrity on the blockchain. As a result, even though the data are stored off-chain, the blockchain ensures its integrity.

5.2. Practical Deployment

Our framework was built on the Polkadot platform, version 0.9.40, and ink! version 4 was used for smart contract development. The user interface created with Polkadot.js [32] interacts with these smart Contracts to execute operations on the blockchain. All involved parties need to operate a parachain node as well as a MongoDB database. These parties communicate with the system backend via the smart contract on the blockchain and MongoDB. A central MongoDB database at the backend acts as a directory, listing all participants in the supply chain. During the transactions, the backend is responsible for managing the communication with smart contracts, and it ensures that the database of the initiating party is updated accordingly. Having a dedicated database for each participant enhances the efficiency of data access locally and reduces the costs incurred from frequent blockchain queries. In the case of a database outage, the critical information remains accessible on the blockchain, safeguarding against data loss. A critical authentication operation is required when a user requests information from the supply chain through the backend. This is facilitated via the smart contract that holds a register of user permissions associated with the corresponding user account. After a successful authentication process, an access token is issued by the smart contract, thereby granting the backend permission to retrieve the requested data.

Figure 3 shows the developed web portal. The system is comprised of a front-end interface wherein the stakeholders possess the capability to upload MPs and effectuate the creation and transfer of products among various proprietors. Participants are required to authenticate themselves through their Polkadot wallet account as an identity credential. Manufacturers, in turn, have the capability to produce an MP for their respective products and subsequently commit it to the IPFS, whereby the CID is generated as a reference for the product. The front-end also displays an inventory of products currently owned by the authenticated account holder. Each product also contains a comprehensive record of the product’s history derived from the blockchain, including the preceding owner and its status within the supply chain.

The framework employs a backend server to store a database for more effective data retrieval since not every piece of information resides on the blockchain and the IPFS does not offer traditional database-querying capabilities. The use of backend servers in our framework does not lead to a single point of failure provided that the product identifier (product_id), which acts as a key on the blockchain for mapping, is available. With this product_id, the IPFS reference can be fetched from the blockchain, and product specifics can be obtained from the IPFS. This process of information retrieval from the blockchain and the IPFS allows for the validation of a product’s authenticity and tracks its origin.

The system’s process is depicted in Figure 4, highlighting four primary operations. They are: adding a product to the blockchain, altering the ownership of a product permanently or temporarily, fetching details about the product (MP), and confirming the product’s details on the blockchain.

In the process of adding the product, we assume that every product has a unique ID. As the manufacturer enters product details (step 1.1), the system generates its MP, and the system sends it to the IPFS (step 1.2) and retrieves the respective file reference from the IPFS (step 1.3). When the backend receives the IPFS reference, it sends this through the smart contract to the blockchain (steps 1.4 and 1.5). In this process, the blockchain performs the following validations: (i) it checks whether the entity is registered as a manufacturer since only the manufacturer can add the product to whom the initial ownership is assigned; (ii) it checks whether the product is a new product and not previously added (i.e., if product_id already exists). Among the various mappings used in the smart contract, one maps the product_id to the respective IPFS reference, and the other maps to the critical information about the product. The smart contract also adds transaction details to trace the previous state of a product; for a new product, the previous state is added as NULL, indicating it is the starting point of the product on the blockchain. Once the transaction is completed in the blockchain, the system retrieves the transaction details (step 1.6) and stores them on the backend server for future reference. Algorithm 1 shows the process of adding a product.

Algorithm 1 Adding a product

1: $I{D}_P\leftarrow \mathrm{UniqueID}\left(P\right)$  2: $M{P}_P\leftarrow \mathrm{GenerateMaterialPassport}\left(P\right)$  3: $Re{f}_{IPFS}\leftarrow \mathrm{SendToIPFS}\left(M{P}_P\right)$  4: if $\mathrm{IsManufacturer}\left(\right)\wedge \neg \mathrm{ProductExists}\left(I{D}_P\right)$ then  5:  $IPFS\_Map\left[I{D}_P\right]\leftarrow Re{f}_{ipfs}$  6:  $Info\_Map\left[I{D}_P\right]\leftarrow \mathrm{CriticalInformation}\left(P\right)$  7:  $TX\_Details\leftarrow \mathrm{BlockchainTransactionDetails}$  8:  $\mathrm{StoreTransactionDetails}(TX\_Details)$  9:  return TRUE 10: else 11:  if $\neg \mathrm{IsManufacturer}\left(\right)$ then 12:   return $\mathrm{ERROR}\left(“\mathrm{Invalid}\mathrm{access}.\mathrm{Permission}\mathrm{denied}”\right)$ 13:  else 14:   return $\mathrm{ERROR}\left(“\mathrm{Duplicate}\mathrm{Product}”\right)$ 15:  end if 16: end if

The second operation deals with a change in ownership. In a supply chain, as a product moves from one owner to another, such changes must be reflected on the blockchain to enable provenance tracking. This process expects two inputs from the user: the product_id and the identifier of the new owner (step 2.1). As the system receives this information, it is sent through the smart contract to the blockchain (steps 2.2 and 2.3). The smart contract performs two validations in this process: it checks whether the products exist on the chain and whether the user who executes the function is the current owner of the product. If there is no matching product on the chain, the process fails. Similarly, only the current owner can transfer the product to another user, and if any other user attempts to perform this action, it results in transaction failure. Along with the user input of product_id and the new owner, the system fetches the previous transaction details of the product and sends them to the smart contract. Adding the previous transaction details with the current state helps to trace the previous state of the product. If the validations fail, the process is aborted, whereas successful transactions return the transaction details (step 2.4), which are stored for future reference. Algorithm 2 describes this process.

Algorithm 2 Ownership transfer process

1: $I{D}_P\leftarrow \mathrm{UniqueID}\left(P\right)$  2: $I{D}_{new\_owner}\leftarrow \mathrm{NewOwner}\left(P\right)$  3: $T{X}_{previous\_state}\leftarrow \mathrm{PreviousStateDetails}\left(P\right)$  4: if $\mathrm{ProductExists}\left(I{D}_P\right)\wedge \mathrm{IsOwner}(I{D}_P,I{D}_{caller})$ then  5:  $TX\_Details\leftarrow \mathrm{TransferOwnership}(I{D}_P,I{D}_{new\_owner},T{X}_{previous\_state})$  6:  $\mathrm{StoreTransactionDetails}(TX\_Details)$  7:  return TRUE  8: else  9:  if $\neg \mathrm{ProductExists}\left(I{D}_P\right)$ then 10:   return $\mathrm{ERROR}\left(“\mathrm{Product}\mathrm{does}\mathrm{not}\mathrm{exist}”\right)$ 11:  else 12:   return $\mathrm{ERROR}\left(“\mathrm{Invalid}\mathrm{access}.\mathrm{Caller}\mathrm{is}\mathrm{not}\mathrm{current}\mathrm{owner}”\right)$ 13:  end if 14: end if

The third process focuses on retrieving information from the IPFS. Even reading information from the blockchain requires gas expenses in most blockchain platforms. This process permits users to retrieve an MP from the IPFS without the involvement of the blockchain. By providing the product_id (step 3.1), the framework gathers and sends the reference to the IPFS (step 3.2), which returns the MP (steps 3.3 and 3.4). The fourth process deals with the verifiability of the product with the proof from the blockchain. If a user wants to check the authenticity of a product, i.e., whether it comes from a particular entity, the user can check it by providing the product_id to the framework (step 4.1); the smart contract then checks the product on the blockchain (step 4.2). If the product exists on the chain, it returns the respective MP mapped to a particular product_id on the blockchain, along with other critical information. Using the details received from the blockchain, it compares and fetches the MP from the IPFS (steps 4.3 and 4.4) and returns it to the requesting user (step 4.5). Algorithm 3 elaborates on this process. Tracking the complete history of the product on the blockchain with its ownership details is an extension of the fourth process since the details of the previous state are stored in the current state of the product. Using the information from the current state, the previous state can be retrieved from the blockchain until there are no previous states available for that particular product.

Algorithm 3 Verification process

1: $P_{status}\leftarrow \mathrm{ProductExists}\left(I{D}_P\right)$ 2: if $P_{status}$ then 3:  $MP\leftarrow \mathrm{GetMP}\left(I{D}_P\right)$ 4:  $CritInfo\leftarrow \mathrm{GetCriticalInformation}\left(I{D}_P\right)$ 5:  $M{P}_{ipfs}\leftarrow \mathrm{FetchFromIPFS}\left(MP\right)$ 6:  return $\{M{P}_{ipfs},CritInfo\}$ 7: else 8:  return $\mathrm{ERROR}\left(“\mathrm{Product}\mathrm{does}\mathrm{not}\mathrm{exist}”\right)$ 9: end if

5.3. Smart Contract Development

In this section, we delve into the creation and implementation of a robust smart contract using ink! 0.4. The smart contract is the backbone of the system, incorporating different data structures to handle admin roles, participant engagement, product information, and access control. Role-based access control (RBAC) is utilised to define the roles of different entities. The data structures are carefully chosen to ensure data integrity and the traceability of a product’s life cycle.

Upon deploying the smart contract, two users are designated as admins, who are responsible for assigning roles to other users. Admin-specific functions form a crucial aspect of our contract, offering privileged controls to maintain the system’s integrity and operational flow. They allow dynamic and secure role management, which is pivotal for enforcing data privacy and system governance. Four specific functions are reserved for admins: check_roles, grant_roles, get_participants, and revoke_roles. The function of add_product is exclusively available to the entities that have a role as a manufacturer, while the other functionalities are open to all entities. The smart contract also includes an array of public functions that highlight the versatility and user-centric design of our architecture.

Table 1. Smart contract functions.

Functions	Executable	Operation	Purpose
grant_roles	Admin-specific	Write	Used by the admins to create and assign roles to the stakeholders
revoke_roles	Admin-specific	Write	Used to revoke the current role of a member
check_roles	Admin-specific	Read	Used to find the current role of any member
get_participants	Admin-specific	Read	Used to obtain a list of all participating members
add_product	Manufacturer-specific	Write	Used by the manufacturer to add the product details to the chain
transfer_product	Any member	Write	Only the current owner is authorised to transfer ownership
get_MP	Any member	Read	Used to retrieve the MP reference stored on-chain
get_owner	Any member	Read	Used to find the current owner of a product
get_pro_details	Any member	Read	Used by the members to access the details of the product
get_pro_history	Any member	Read	Used to obtain previous ownership details

highlights a few important functionalities used in the smart contract, which enforces various background checks before execution by the entities.

6. Evaluation

In this section, we evaluate the efficiency and resilience of the developed system through two metrics: performance and security.

6.1. Performance Evaluation

Our performance evaluation was conducted through two scenarios: (i) cost-effectiveness and (ii) the system’s scalability and throughput under different operational loads. For this evaluation, we used a machine with an Intel i5-8250U processor with 6 GB RAM.

6.1.1. Cost Evaluation

Our c cost evaluation considers the amount of gas required for transactions. The functions are the same as discussed in Table 1. The functions that involve a write operation require a gas fee, while a read operation does not (as a private blockchain is used in our implementation). The two most commonly used inputs required for these functions are either userID or product_id.

Table 2. Cost evaluation of functions [8].

Functions	Input	Output	Gas Fee *
grant_roles	userID, role	Success/fail	0.11363819
revoke_roles	userID	Success/fail	0.11363819
check_roles	userID	Role of the user	No
get_participants	—–	List of participants	No
add_product	product_id, userID, MP_hash	Transaction details	0.11363829
transfer_product	product_id, userID, previous transaction details	Transaction details	0.11363829
get_MP	product_id	MP	No
get_owner	product_id	userID	No
get_pro_details	product_id	Product info	No
get_pro_history	product_id	List of previous owners	No

* Gas estimates only include partial fees. Full transaction fees can only be calculated in the production environment.

provides a summary of the functions and their respective gas fees. As outlined in Table 2, the operations incur a cost of 0.11363819 DOT for the transactions performed on the Polkadot platform used in the framework.

When incorporating a product onto the blockchain, what’s actually recorded is the MP reference, a 46-character IPFS string, preserved as a hash datatype in ink!. During the process of changing ownership of a product, the transaction details (including block and transaction hashes) are documented. Unlike in a single-layer blockchain, where the details can be accessed using just the transaction hash, Polkadot necessitates both [33]. Embedding transaction details within the smart contract allows network participants to backtrack ownership information independently.

6.1.2. Scalability and Throughput

Scalability remains one of the key reasons we selected Polkadot as our blockchain platform. An evaluation was carried out for the two main blockchain operations, adding a product and product verification, which are discussed in the sequence diagram in Figure 4. The scalability test evaluated how the developed model performs under incremental workloads. The system performance for the add_product function can be observed from Figure 5. As the number of transactions increases from 1 to 50, the transaction completion times require an average of 168.5ms, with a minimum and maximum spread from 151.8 ms to 262.7 ms, respectively. This suggests stable performance under lighter loads. Between 50 and 250 transactions, transaction times are reduced as compared to the prior transaction counts. This demonstrates the ability of the implementation to handle higher request loads. At 500 transactions, there is an unexpected dip in the average response time to 174.8 ms, which arises due to system optimisation or variability in load handling between 250 and 500 transactions. For transaction counts above 500, the service starts to degrade, with significantly higher transaction times. The saturation point for this model is thus estimated to be at approximately 500 transactions. An additional 60 s was given for transaction counts above the saturation point, after which tests were terminated to avoid system crashes.

The verification process has two parts: the first involves retrieving the MP reference from Polkadot, and the second involves retrieving the MP itself as a file from the IPFS.

Table 3. Verification process performance metrics.

No. of Users	Transactions per User	Fetch Chain Average (ms)	IPFS Average (ms)	Requests/s (Incl. Authentication)
1	1	78.00	11.00	1.00
	50	69.46	8.95	24.80
	100	66.66	8.42	26.48
	250	81.54	10.08	21.61
	500	83.61	8.91	21.34
5	1	316.37	25.48	18.22
	10	317.58	101.25	22.13
	20	270.51	114.30	24.80
	50	288.43	111.09	24.41
	100	260.29	102.59	27.22
10	1	548.63	207.22	17.45
	5	612.39	203.57	20.90
	10	610.50	177.65	23.64
	25	607.51	179.39	24.48
	50	554.33	182.23	26.64

presents data on the performance of the system handling concurrent requests from 1, 5, and 10 users. The fetch chain average column shows the average time taken to fetch data from the blockchain, and the ipfs average column shows the average time to retrieve MP from the IPFS. The Requests (incl. authentication) column measures the throughput of the system in terms of the number of requests, including authentications processed per second. For one user, as the number of transactions per user increases from 1 to 500, the average fetch time from the blockchain increases, showing a slight degradation in performance as the number of transactions grows. The IPFS retrieval time remains relatively stable, even slightly decreasing as the number of transactions increases, suggesting that IPFS retrieval may benefit from some form of caching or is less affected by increased transaction volume. The request rate per second is highest at 100 transactions per user, indicating an optimal load under which the system performs best for a single user. When the number of users increases to 5 and then to 10, the average times for both fetching from the blockchain and IPFS retrieval increase significantly. This indicates that the system is experiencing additional strain under the weight of managing multiple parallel sessions. Notably, for 5 and 10 users, the request rate per second does not fall off as sharply as might be expected given the increased load, suggesting that the system is still managing to process a reasonable number of requests per second even under higher concurrency. However, the increase in processing times with more users indicates that the system’s resources are becoming a bottleneck, potentially due to increased contention for network or computational resources.

Figure 6 displays the total test time for a verification process across different numbers of users and transactions per user. For a single user, the total time increases from 4073 ms for 50 transactions to 46,898 ms for 500 transactions, which is a significant increase for this number of transactions. With five users, the time taken is initially relatively low, at 816 ms for a single transaction, but this value escalates to 36,842 ms for 100 transactions, showing that the total processing time increases with both the number of users and transactions. For ten users, the total test time begins at 1681 ms for one transaction and reaches 37,905 ms for 50 transactions. These performance results indicate that the system can handle multiple transactions and users, but the total test time rises significantly with increased load.

The total test time thus increases due to various factors. An increase in time for both single and multiple users suggests significant overheads for the system when handling the verification process and concurrent user sessions. The increase in total test time for 5 and 10 users indicates an additional workload from managing multiple concurrent processes, possibly due to context switching, increased synchronisation overhead, or data contention issues. The findings emphasise the need to optimise concurrency and scaling resources to handle increased loads efficiently.

6.2. Security and Privacy

This section evaluates access control mechanisms and resilience in recovery, ensuring robust protection against unauthorised access and effective data retrieval post-compromise/attack.

6.2.1. Access Control

Role-based access control (RBAC) is built into our blockchain architecture to provide a strong foundation for secure access to the system. This approach improves transaction security and integrity and ensures that privacy considerations are strictly followed. RBAC improves the overall security posture of our blockchain solution by protecting sensitive information and critical functionalities from unauthorised access and potential vulnerabilities. During the deployment stage, the smart contract designates two users as administrators, who oversee the processes of assigning and managing roles for all other users. This controlled environment is critical for establishing a secure system with strict access rights from the start. Each role is assigned specific responsibilities and restrictions under the smart contract. For example, only the manufacturer can add a product to the blockchain, and only the current owner can pass it on to the new owner. The roles ensure that information is only accessible to those with delegated roles, preserving privacy. This reduces the likelihood of unauthorised access to sensitive data and critical functionalities. This selective restriction of access rights based on roles ensures that users can only access information that is relevant to their role, upholding the principles of data minimisation and privacy. Administrators can dynamically manage roles, allowing the system to adapt to changing security landscapes and respond quickly to potential threats or breaches. Figure 7 shows snippets of the smart contract deployment and the grant_roles functions.

6.2.2. Resilience and Recovery

The system employs a robust mechanism to ensure data integrity and speedy recovery. This mechanism is built around the strategic use of a unique product identifier, which serves as a mapping key on the blockchain. The integration of IPFS and blockchain technology strengthens our system’s ability to protect data. We store data on the IPFS and reference them on the blockchain, creating a tamper-proof decentralised storage system. If the backend systems fail, the unique product identifier is a valuable tool for data recovery. Stakeholders can use it to connect to the blockchain, obtain the relevant IPFS hash, and retrieve detailed MP and other critical data stored on the IPFS. This process ensures that even in the event of an unreachable backend server, each product’s integrity and history are preserved and accessible.

7. Conclusions

A multilayer blockchain system is developed using Polkadot and the IPFS to improve circularity and product reuse/repurposing in the construction sector. It allows each entity within a product’s supply chain to operate its own blockchain to log its local transactions. Additionally, it permits the selective sharing of transaction data based on mutually agreed-upon terms among project collaborators. The framework supports the scalability and privacy of information, facilitating the adaption of new entities with the expansion of supply chains. Through a practical use case, we illustrate an application of this framework involving key supply chain participants, such as manufacturers, logistics providers, storage facilities, and end-users. The material passport (MP) plays a significant role in achieving a sustainable supply chain by recording all the features of a specific product and the processes it undergoes throughout its life cycle. We use parachains to store the MP, assuring all supply chain members of the veracity of the recorded information. The implications of our research offer practical insights into a deployable framework for industry practitioners and policymakers to foster sustainable practices. The use of parachains also supports scalability by design within our framework, enabling multiple stakeholders to operate their own blockchain, which can be integrated through a relay chain. However, there are still barriers to blockchain adoption that require further research, such as the standardisation of the MP and studies on the economic aspects (return on investments). We plan to engage with industries and business partners to study this further.

In the next stage of our work, we aim to develop a specialised marketplace specifically tailored for the circular supply chain by updating our current framework. This marketplace will incorporate building information modelling (BIM) for material extraction and recycling data, MPs for detailed material documentation, and defined marketplace roles to facilitate interactions. Blockchain integration will support transaction efficiency through smart contracts, while a user-friendly consumer interface will enhance publisher–subscriber communication. The marketplace aims to incentivise active engagement with recycled materials through smart contracts, AI-enhanced analytics for material–demand matchmaking, and dynamic pricing mechanisms. This initiative represents a significant step towards optimiing the circular economy supply chain, making it more accessible and appealing to all stakeholders involved.