Source-linked AI summary

Do you need a blockchain in construction? Use case categories and decision framework for DLT design options

Jens J. Hunhevicz, Daniel M. Hall

arXiv:2004.04626v1cs.CR

TL;DR

Construction DLT research has many proposed use cases but few documented implementations, leaving a gap between use-case ideas and technical system choices. The paper reviews and categorizes these use cases, describes DLT design options, and proposes a framework for matching options to use-case characteristics. Its analysis finds that most proposals apply DLT to existing processes without requiring it, so prototypes and case studies are needed to validate benefits.

  • Problem

    Construction’s decentralized and fragmented project structure creates trust, information-exchange, and coordination challenges, while DLT research remains largely theoretical with few implementations.

  • Method

    The paper reviews and categorizes construction DLT use cases, describes four DLT design options alongside traditional databases, and applies a decision framework to the proposed use cases.

  • Results

    Most analyzed use cases apply DLT to existing processes where it is not necessarily required, while only a few enable innovative use cases that cannot be realized without DLT.

  • Takeaways & Limitations

    The use-case categories and framework provide a tool for connecting construction use cases with DLT design options and guiding further exploration.

  • Takeaways & Limitations

    The analysis is limited because participant trust relationships are difficult to assess from high-level use-case descriptions, leaving multiple DLT design options plausible for most cases.

Abstract

from arXiv · show

Blockchain and other forms of distributed ledger technology (DLT) provide an opportunity to integrate digital information, management, and contracts to increase trust and collaboration within the construction industry. DLT enables direct peer-to-peer transactions of value across a distributed network by providing an immutable and transparent record of these transactions. Furthermore, there is potential for business process optimization and automation on the transaction level, through the use of smart contracts, which are code protocols deployed on supported DLT systems. However, DLT research in the construction industry remains at a theoretical level; there have been few implementation case studies to date. One potential reason for this is a knowledge gap between use-case ideas and the DLT technical system implementation. This paper aims to reduce this gap by 1) reviewing and categorizing proposed DLT use cases in construction literature, 2) providing an overview of DLT and its design options, 3) proposing an integrated framework to match DLT design options with desired characteristics of a use case, and 4) analysing the use cases using the new framework. Together, the use case categories and proposed decision framework can guide future implementers toward more connected and structured thinking between the technological properties of DLT and use cases in construction.

1. Introduction

DLT offers construction a distributed, transparent basis for trusted transactions and smart-contract automation, but implementation remains limited and disconnected from technical design choices. This paper addresses that gap by linking construction use cases to suitable DLT options through categorization and a decision framework.

  • DLT foundations: DLT enables peer-to-peer value transactions without central-authority intermediation through distributed records of timestamped transactions.Blockchain is the most prominent DLT type, using sequential records that resist alteration without redoing proof-of-work.
  • DLT foundations: DLT design involves a tradeoff between security and trust properties on one side and transaction speed and system overhead on the other.Consequently, a single DLT implementation is unlikely to satisfy every usage scenario.
  • DLT foundations: Smart contracts execute code protocols on DLT and can automate business logic for assets and data, including tokenized digital assets.This extends DLT beyond recordkeeping toward transaction-level business-process automation.
  • Construction context: Construction’s decentralized, project-based, geographically distributed, and fragmented structure creates coordination challenges involving trust, information exchange, and supply chains.DLT’s potential for trusted, efficient, transparent, and accountable transactions aligns theoretically with these challenges.
  • Research gap and aim: Construction DLT research has proposed use cases and combinations with BIM and IoT, but few implementations exist and little work structures use cases by DLT value propositions.The paper therefore seeks to connect use-case ideas with technical implementation through categorization, design-option analysis, and a decision framework.

2. Categorization of DLT Use Cases in Construction

The review examines construction-focused DLT literature and clusters its proposed applications into seven categories aligned with DLT’s main value propositions. These propositions center on trust and transparency, business-process automation, and tokenized assets.

  • Review scope: The review covers fifteen construction-focused sources, including scholarly papers and consulting reports, while excluding energy, smart-city, smart-home, and general built-environment literature.The restricted scope reflects the limited construction DLT literature available for review.
  • Use-case categories: Twenty-four potential construction DLT use cases were identified and clustered into higher-level categories.The categorization extends earlier work by adding six recent papers and separating immutable transaction records from immutable asset or ownership records.
  • Value propositions: The seven categories align with DLT value propositions: transparency and trust, process optimization and automation, and token creation for financial or incentive purposes.Categories 3 and 4 correspond to transparency and trust; categories 1, 2, 6, and 7 to smart-contract automation; and category 5 to tokenized assets.
  • Review scope: Table 1 organizes the reviewed literature by source type and coverage of paper sections used in the analysis.Its caption distinguishes scholarly papers from consulting reports.
  • Use-case categories: Table 2 presents the clustering of construction DLT use cases into seven categories based on the reviewed literature.The table is adapted from Hunhevicz and Hall and reflects the paper’s refinement of the category structure.

1 - Internal Use for Administrative Purposes

DLT can support internal administrative uses by notarizing and synchronizing documents across organizational boundaries. This can simplify and automate administrative processes.

  • Document administration: DLT can notarize and synchronize document creation, deletion, and updating across an inter-organizational system.The same approach can record quality data or resource-consumption data.

2 - Transaction Automation Between Stakeholders with Smart Contract

Smart contracts can automate transactions and contractual actions between construction stakeholders. Proposed applications include payment triggers, deliverables, and immutable records supporting project and supply-chain processes.

  • Transaction automation: Smart contracts can automatically trigger payments between stakeholders and trigger predefined contractual deliverables when ledger states are updated.Automatic payment triggering is the most frequently mentioned transaction-automation use case, while payment delays are repeatedly associated with disputes.
  • Immutable records: DLT can immutably and transparently record transaction-related events including digital-model changes, supply-chain logistics, project progress, worked hours, maintenance, safety incidents, and compliance.Proposed applications also include verifying installation tasks such as correct insulation-panel installation.

4 - Immutable Record of Assets/Identities

DLT can provide immutable and transparent records for assets, identities, ownership, provenance, and certifications across construction workflows.

  • DLT can record ownership of BIM intellectual property and physical assets such as property.
  • DLT can maintain identities for people and organizations to support clear and trustworthy identification.
  • Material and product passports can preserve product and provenance information throughout the supply chain.
  • Trusted asset data can support quality assurance, material reuse toward a circular economy, and product or building certification.

5 - Coins/Tokens as Payment or Incentive Scheme

DLT enables token-based financial and incentive use cases, including cross-border cryptocurrency payments and shared risk-and-reward structures.

  • DLT can create coins or tokens for financial and incentive-related construction use cases.
  • Cryptocurrency payments allow participants to send money across borders instantly with small transaction fees.
  • Shared accounts and insurance can use distributed structures for risk and reward among multiple independent stakeholders.

6 - Decentralized Applications (DApps)

DApps provide intermediary-free interfaces to DLT for long-term, cross-project users, including decentralized marketplaces and common data environments.

  • DApps are DLT-based applications designed for direct user interaction without an intermediary.
  • Unlike project-specific web applications, DApps target global users who may be unknown and participate in multiple projects.
  • Decentralized marketplaces can combine digital identities with objective tendering data without disclosing sensitive information to third parties.
  • Decentralized common data environments can combine cloud storage and DLT to store digital models without relying on third-party servers or private servers vulnerable to attacks.

7 - Decentralized Autonomous Organizations (DAOs)

DAOs are fully autonomous organizations governed by smart contracts and crypto-economic incentives, with proposed construction applications including automated building maintenance.

  • DAOs are autonomous organizations whose governance rules are coded in smart contracts running on DLT without human involvement.
  • DAOs use crypto-economic design to embed incentive mechanisms in their governance.
  • DAOs often use IoT and digital models to connect automated governance with real-world interaction and location context.
  • Automated building maintenance systems are among the construction applications proposed in the literature.

3. Overview of DLT Technology and Design Options

DLT design combines layered technical components with governance choices that determine how transactions are stored, validated, accessed, and automated. These choices affect fundamental properties such as immutability, non-repudiation, integrity, transparency, and equal rights, alongside system performance.

  • Technology stack: DLT technology is organized as a stack whose layers support information sharing, ledger storage, network participation, governance, and application-level computation.The paper uses an adapted technology-stack structure to relate technical DLT features to use-case capability expectations.
  • Ledger: The ledger stores transaction data and can use blockchains with sequential total order or directed acyclic graphs with parallel transaction confirmation.Blockchain integrity relies on linked hashes, while sidechains, sharding, and other ledger structures address scalability concerns.
  • Application layer: Smart contracts are code protocols that execute logic based on ledger state when the DLT supports a Turing-complete protocol layer.They are unchangeable unless explicitly designed to be updateable and can support coded relations at the application layer.
  • Network design: Permissioned or permissionless participation and public or private visibility determine who can join, write transactions, and read ledger data.Permissionless systems allow broader participation, whereas permissioned systems restrict node setup or write access; public systems permit general visibility.
  • Governance: Consensus governance defines how ledger entries are written, validated, and agreed upon, while crypto-economic incentives support honest participation in public DLT networks.Proof-of-work protects against attacks but is resource intensive, motivating alternatives such as proof-of-stake.
  • Fundamental properties and design options: DLT design options vary in trust properties: integrity is common across DLT options, while public permissionless systems can provide all five fundamental properties.Higher fundamental properties generally involve a tradeoff with transaction speed and system overhead, so no single design suits every scenario.

4. A Decision Framework for DLT Design Options in Construction

The proposed framework connects use-case trust requirements and technical constraints to a suitable DLT design option. It first tests whether DLT is needed, then selects the design, and finally considers additional constraints and compromises.

  • Framework development: Existing DLT decision frameworks were reviewed and combined into an integrated framework centered on trust and the fundamental properties required by a use case.The framework seeks to optimize performance while ensuring that the selected DLT provides the properties the use case needs.
  • Stage 1: Do you need a DLT?: Stage 1 asks whether state must be stored, whether multiple writers exist, and whether an always-online trusted third party can be used.It also asks whether a trusted third party is desired, then assesses whether participants are known and whether their interests are aligned.
  • Stage 2: Which DLT design?: If participants are unknown, Stage 2 favors permissionless DLT; if known participants have misaligned interests, a permissioned system may offer better performance.The stage then considers public verifiability and whether participants need protocol-level control.
  • Stage 2: Which DLT design?: Private permissionless DLT can be considered instead of private permissioned DLT when protocol-level functionality control is unnecessary.Both can keep data private, but private permissioned systems require operating an own network with the necessary infrastructure.
  • Decision assumption: The framework assumes that fundamental properties and performance are generally inversely related, so it chooses better performance when higher properties are not required.This assumption makes the decision directly related to the security level needed by the system.
  • Stage 3: Constraints?: Stage 3 evaluates use-case-specific constraints, including smart-contract support, cost structure, and other dimensions that may shift the preferred DLT option.The proposed constraint dimensions are not complete, and compromises may be necessary because one system cannot always provide every desired benefit.

5. Analysis of Use Cases

The framework analyzes construction DLT use cases in stages: whether DLT is needed, which design option fits participant relationships and verifiability needs, and which additional constraints must be assessed.

  • Framework application: The authors analyze categorized use cases by simulating possible constellations through the framework, with multiple DLT design options sometimes remaining appropriate.High-level use-case descriptions may not specify participant relationships sufficiently to determine one option.
  • Stage 1 – Do you need DLT?: All analyzed use cases store state and involve multiple writers, while the first stage evaluates whether an always-online trusted third party is possible.If a trusted third party is possible, DLT is not needed, although cost reduction or avoidance of intermediary control may still justify DLT.
  • Stage 1 – Do you need DLT?: When a trusted third party is unavailable, the framework directly evaluates whether participants are known and whether their interests are aligned.This applies to cryptocurrency payments and use cases relying on decentralized characteristics, including proposed solutions not already existing in construction.
  • Stage 2 – Which DLT design option?: For suitable DLT cases, stage 2 selects among design options according to whether participants are unknown or their interests are not aligned.Known participants with misaligned interests yield options ii), iii), and iv), while insufficient relationship detail can require considering options v) to ix).
  • Stage 2 – Which DLT design option?: Stage 2 also filters cases by public-verifiability requirements and assesses protocol-level functionality control for private DLT options.Sensitive internal documents may not require public verifiability, whereas asset or ownership records may; control preferences can leave both private combinations possible.
  • Stage 3 – Constraints?: Stage 3 discusses constraints for the specific use case and may lead to another DLT option or no DLT if the proposed design cannot be realized.Smart-contract cases require support at the application layer, and external-state interactions may require public verifiability and sufficient throughput.

6. Summary and Discussion

The paper categorizes construction DLT use cases and introduces a framework that links their required fundamental properties and constraints to DLT design options. The analysis finds that DLT is often not necessary for existing processes, while practical validation and more detailed participant analysis remain needed.

  • 6.1. Contribution: The review extends prior categorization work, identifies an additional use-case category, and organizes construction DLT applications by their value propositions.The categorization supports clearer comparison of commonalities and differences among use cases.
  • 6.1.2. Limitations: The literature review was not systematic, so the identified use cases are not claimed to be complete and may change as the field evolves.Future research should revise or extend the categories and validate benefits through prototypes and case studies.
  • 6.2. Contribution: The framework selects DLT design options by first assessing required fundamental properties, then optimizing performance and finally considering implementation constraints.It was developed by reviewing and cross-comparing eight existing frameworks.
  • 6.3. Contribution: The framework can indicate whether DLT suits a use case and, when appropriate, which DLT design option may fit it.Its assessment is based on the use case’s need for a trusted solution.
  • 6.3. Contribution: For many existing construction processes, a trusted third party could achieve the same result, so DLT is not necessarily required.The savings from removing a trusted third party must be weighed against the cost of operating DLT.
  • 6.3.2. Limitations: Most use cases permit multiple DLT design options because their descriptions do not specify participant constellations and trust relationships in sufficient detail.The best-suited option depends on the final constellation of participants, although some category-level consistency is visible.

7. Conclusion

The paper structures construction DLT use cases and assesses their need for DLT through a framework linking use cases to four design options. Many cases could benefit from DLT, but most apply it to existing processes where its added value still requires validation.

  • 7. Conclusion: The paper introduces a decision framework linking construction use cases to four DLT design options according to their required fundamental properties.The framework also assesses whether a DLT solution is actually needed.
  • 7. Conclusion: Many analyzed use cases could potentially profit from DLT, but most apply it to existing processes where DLT is not necessarily required.Only a few proposals use DLT to enable innovative use cases that cannot be realized without it.
  • 7. Conclusion: Prototypes and case studies are needed to evaluate DLT’s added value, socio-economic impacts, and effects on construction processes.Further analysis must also examine participant trust relationships because these vary across proposed use cases.
  • 7. Conclusion: The use-case clustering and framework provide a tool for connecting construction use cases with DLT design options and advancing research.This follows from the partial alignment between construction use cases and DLT’s fundamental properties.
Loading 2004.04626v1…