Incremental BIM-Based Collaborative Design Using IPFS and Blockchain

Abstract

Building information modeling (BIM)-based collaborative design can support sustainable construction, but current workflows often transmit complete models even when minor changes have been made and rely on centrally controlled records. This study proposes an incremental collaborative design framework that integrates a self-contained extension of the Tracing Semantic Differential Transaction (TSDT) method, hierarchical conflict detection, a permissioned blockchain ledger, and private IPFS storage. The framework formalizes a five-stage workflow and specifies the acceptance checks, incremental packet structure, conflict rules, and governance assumptions implemented in the prototype. In seven change scenarios, the improved TSDT packets reduced transmitted data volumes by 64.47% to 99.85% relative to the corresponding modified full models, with the largest savings observed for minor changes. The prototype also achieved low average on-chain latency and successful model reconstruction in a controlled single-server environment. These findings demonstrate the framework’s technical feasibility and its ability to support record-level traceability and integrity verification.

1. Introduction

As construction projects become larger and more complex, design activities are increasingly multidisciplinary and data-intensive. Large projects require close coordination among architectural, structural, and other design teams [1]. In this context, Building Information Modeling (BIM)-based collaborative design has emerged as an important digital approach for enhancing information integration and interdisciplinary coordination. By providing a shared digital representation of project information, BIM allows multiple disciplines to work concurrently, improves design efficiency, and supports early detection of design conflicts [2]. These capabilities can also contribute to more sustainable construction practices [3].

Despite these advantages, current BIM-based collaborative design practices are still limited by inefficient data exchange and weak inter-organizational trust [4]. Most existing workflows depend on centralized platforms and repeatedly transmit complete BIM models [5]. Because many existing systems do not support incremental updates or local synchronization, even a minor component-level revision may require the entire model to be re-exported, uploaded, synchronized, and redistributed. As model size increases, this full-model transmission creates substantial storage overhead and computational burden [6]. Trust is also constrained because centralized platforms store records on servers con-trolled by a single organization, providing limited support for tamper-resistant verification of historical design operations [7].

Incremental collaborative design offers a promising way to reduce the inefficiencies caused by full-model transmission. Derived conceptually from version control systems in software engineering, incremental collaboration records and exchanges only the differences between successive versions, the current model state can then be reconstructed from a base version and a sequence of incremental updates [8]. Applied to BIM-based collaboration, this approach enables localized model changes to be extracted, represented, transmitted, and applied to existing models with explicit semantic meaning, rather than requiring repeated exchange of complete BIM models [9]. By storing and sharing only modified information, incremental collaborative design can reduce data redundancy and improve the efficiency of multi-version design iterations.

However, incremental collaborative design alone is insufficient to solve the record-verification challenges of distributed multidisciplinary collaboration. Although incremental updates improve data-exchange efficiency, a mechanism is still required to preserve evidence of design changes and verify the integrity of shared data [10]. Blockchain technology offers a potential solution through its distributed and traceable ledger structure [11]. By recording design-change metadata, operation logs, and verification information in chronological order, a permissioned blockchain can strengthen auditability and accountability under configured identity and governance policies. Nevertheless, storing BIM models or large numbers of incremental records directly on-chain is economically and technically impractical [12].

To address the storage limitations of blockchain, the InterPlanetary File System (IPFS) can be used as an off-chain distributed storage mechanism. IPFS adopts content addressing to generate a unique Content Identifier (CID) from the cryptographic hash of file content, which enables data-level integrity verification [13]. Through block-based storage and distributed hash tables, IPFS supports decentralized routing, retrieval, and distribution of large-scale models [14]. Therefore, the integration of blockchain and IPFS provides a feasible means of combining efficient distributed storage with traceable evidence preservation.

Motivated by the need for more efficient and resource-conscious collaboration in construction, this study proposes an incremental BIM-based collaborative design framework that integrates blockchain and IPFS. The framework combines incremental version control, blockchain-based evidence preservation, and IPFS-enabled distributed storage. At the data-flow level, it supports extraction, transmission, and sharing of BIM model changes. At the data-assurance level, it provides authorization under permissioned governance, traceability of accepted transactions, and CID-based integrity verification. These capabilities can support sustainable construction by improving information reuse, reducing coordination inefficiencies, and strengthening accountability across organizations.

2. Literature Review

2.1. BIM-Based Collaborative Design

Early studies on BIM-based collaborative design primarily focused on centralized collaboration architectures supported by cloud platforms or BIM servers. In these architectures, BIM models are stored on a central server, and engineers from different disciplines access and update a shared data source through client-side applications. Singh et al. [15] proposed a theoretical framework for a centralized BIM-server-based collaboration platform. Oh et al. [16] developed an integrated system to support multidisciplinary design coordination. With the implementation of the ISO 19650 standard [17], the Common Data Environment (CDE) has become a central concept for standardizing information management and collaborative workflows [18].

Subsequent studies examined CDE-based and BIM-enabled collaboration in specific design contexts, extending centralized collaboration from theoretical frameworks to industry implementation. Zanni et al. [19] developed a sustainable architectural design process model, and Kurwi et al. [20] proposed a collaborative process model for the design phase of railway projects. By configuring workflows within customized CDE platforms, these studies supported centralized project information management and improved design coordination.

Although existing studies provide an important foundation for BIM-based collaborative design, two limitations remain. First, most workflows synchronize complete BIM models, which makes frequent iterations of large-scale models difficult to manage efficiently. Second, centralized collaboration architectures lack a neutral, tamper-resistant mechanism for recording and verifying design operations, limiting their support for cross-organizational collaboration.

2.2. Incremental Collaborative Design

To reduce storage redundancy and improve operational traceability in full-model transmission workflows, BIM-based incremental collaborative design has become an important research direction. Its core objective is to identify, extract, and transmit only the changes between model versions. Early studies commonly used comparison methods based on globally unique identifiers (GUIDs) [21]. However, GUID retention can be unstable during cross-software data exchange, reducing the reliability of object matching across heterogeneous BIM platforms.

To overcome the limitations of GUID-dependent comparison, graph-based methods have been proposed, which can abstract BIM models into attribute graph structures and identify model changes through graph-difference computation. Compared with GUID-based methods, graph-based methods offer greater robustness in heterogeneous data environments, but they introduce higher computational complexity [22,23]. More recently, content-semantic-based comparison methods have attracted increasing attention. These methods construct hierarchical model structures and perform bottom-up iterative comparison to improve the efficiency of change extraction [24,25,26]. Nevertheless, they are highly sensitive to byte-level variations. As a result, semantically equivalent changes may be incorrectly classified as different, producing redundant incremental records.

Building on model change extraction, some studies have developed incremental collaborative design methods for BIM. Poinet et al. [27] developed an open-source distributed data environment that supports cross-software collaboration through object-level incremental transmission and ID-based mapping. Dietmair et al. [28] introduced a tagged property graph structure to support a more robust incremental update mechanism. Esser et al. [29,30] converted BIM models into property graph structures, used GUIDs as matching anchors to calculate graph differences, and generated graph transformation rules. They also introduced branching mechanisms and conflict detection to support model branch merging and conflict resolution, respectively.

Despite these advances, many existing incremental methods still depend on stable GUIDs and are deployed on centralized servers or third-party platforms. Consequently, independent organizations may find it difficult to verify the provenance and integrity of incremental records. To address these problems, Xue et al. [31] proposed the Semantic Differential Transaction (SDT) method, which constructs content-based semantic feature identifiers through hash calculation. This method eliminates GUID dependence and establishes a more robust object-mapping mechanism. Building on SDT, Kong et al. [32] proposed the Tracing Semantic Differential Transaction (TSDT) method. By introducing a three-level mapping dictionary and a two-stage semantic tracing process, TSDT enables more precise identification and tracking of object-level semantic changes.

However, several limitations restrict the practical application of TSDT. First, the method does not address incremental conflicts caused by concurrent multi-user operations. Second, it lacks a tamper-resistant and verifiable storage mechanism for both BIM models and incremental records. Therefore, overcoming these limitations is essential for promoting TSDT-based incremental collaboration.

2.3. Blockchain and IPFS in Design

Blockchain technology has increasingly been explored in design and construction information management because of its potential to enhance traceability in collaborative processes. Pradeep et al. [33] used blockchain to record metadata from key design processes, thereby enabling verification of document integrity. Dounas et al. [34] investigated the use of smart contracts to automate design review procedures and demonstrated the feasibility of recording design decisions in a decentralized framework. In addition, blockchain has been used for copyright protection and trusted archiving of design deliverables. Tao et al. [35] proposed an access control model to protect sensitive BIM data within a blockchain ledger, while Hsu et al. [36] developed archiving solutions by recording model parameters on-chain or constructing blockchain-based digital archive frameworks.

Existing studies have mainly adopted blockchain for process recording or for storing lightweight model parameters. However, BIM models themselves constitute critical digital assets in collaborative design, and their integrity directly affects the authenticity of design outcomes [37]. If operational records are stored on-chain but model files remain on centralized platforms, the underlying BIM data may still be vulnerable to tampering, replacement, or unauthorized modification [38]. Therefore, BIM models should be incorporated into a verifiable storage and integrity-checking mechanism, together with appropriate access-control and availability policies.

IPFS has been introduced as an off-chain distributed storage solution. A common architecture is to store actual files off-chain in IPFS while recording their CIDs and related metadata on-chain. Several studies have examined the integration of blockchain and IPFS in BIM-based collaboration. Wang et al. [39] used blockchain and IPFS to support copyright protection in BIM-based collaborative design. Tao et al. [40] proposed a distributed CDE-based on blockchain and IPFS. By storing design changes on-chain and design files off-chain, and using smart contracts to regulate collaborative processes, their framework created a reliable environment for managing cross-disciplinary dependencies. Additionally, Antinozzi et al. [41] integrated BIM, IPFS, and smart contracts to verify the traceability of information management and contract execution.

Table 1. Positioning relative to closely related studies.

Study	Incremental Mechanism	Conflict/Version Support	Storage Model and Distinguishing Scope
Xue et al. [31]	SDT with content-based semantic identifiers	Semantic difference representation	BIM–blockchain integration centered on differential transactions
Kong et al. [32]	TSDT with mapping dictionary and semantic tracing	Traceable incremental sequence	Blockchain virtual disk; external mapping dependence and concurrent conflicts remain
Tao et al. [40]	Design-file and change management in a CDE	Smart-contract workflow and access control	Blockchain-IPFS distributed CDE without self-contained TSDT packets
This study	Self-contained improved TSDT packet	Explicit hierarchical detection with manual arbitration	Integrated packet, conflict rules, permissioned acceptance, and linked metadata workflow

positions the proposed framework relative to the most closely related SDT/TSDT and blockchain-IPFS studies. Prior SDT/TSDT research provides semantic incremental representation and tracing, whereas blockchain-IPFS common data environments provide distributed record and file management. The contribution of this study is the integration of a self-contained TSDT packet, explicitly defined hierarchical conflict rules, and a linked on-chain/off-chain metadata workflow in a single prototype. This integration is a feasibility demonstration and does not imply that all security or governance problems are solved.

3. Materials and Methods

3.1. Overview of the Framework

The incremental BIM-based collaborative design framework proposed in this study integrates blockchain and IPFS to support efficient and traceable multidisciplinary collaboration. As shown in Figure 1, the framework organizes the collaborative design process into five sequential stages, including base model initialization, local parallel editing and incremental extraction, concurrent submission and conflict detection, conflict arbitration, and version release with global synchronization.

Stage 1: Base model initialization. At the beginning of a project, an initial BIM model is created to serve as the global base model for subsequent collaborative design. The model file is uploaded to the IPFS off-chain storage network, which returns a corresponding CID. The CID, together with relevant project metadata, is then submitted to the blockchain in order to establish the initial on-chain record of the base model. Each discipline retrieves the CID of the current base model from the blockchain, downloads the model through the off-chain storage network, and imports it into local modeling software. This process ensures that all participating engineers begin from a consistent, traceable, and verifiable model state.

Stage 2: Local parallel editing and incremental extraction. Based on the initialized base model, engineers from different disciplines perform their design tasks independently in local modeling environments, thereby producing locally modified model versions. After completing a design task or phase, each engineer submits the modified model for incremental analysis. The framework compares the local model with the corresponding base model, extracts the semantic differences between the two versions, and generates a structured incremental record. This record captures the changes made by the engineer, including affected objects, attributes, and operations, rather than storing or transmitting the complete modified model. In this way, model exchange is shifted from full-file transmission to change-oriented representation.

Stage 3: Concurrent submission and conflict detection. After an incremental record has been generated, the engineer uploads the incremental packet to IPFS and submits the returned CID to the blockchain together with the operator identity, project identifier, increment identifier, base version, parent increment identifier, and timestamp. The smart contract performs authorization and version-continuity checks before accepting the submission. Version continuity is satisfied when the submitted base version matches the current released base version of the project, or when the base version is empty for the first pending increment. A submission is accepted only if the caller provides a valid consortium certificate, holds an authorized project role, references an existing project and base version, specifies a valid pending parent increment under the same base version when a parent is provided, and satisfies the configured endorsement policy. If any check fails, the transaction is rejected without changing the ledger. After these preliminary checks, the framework retrieves all accepted but unmerged incremental records derived from the same base version and performs conflict detection. A non-conflicting record is recorded as pending metadata on the ledger. When a defined conflict is detected, the framework generates structured conflict information specifying the violated rule, the affected object and attribute paths, and the two inconsistent operations. This information is returned to the submitter, and the conflicting record is excluded from merging. The threat model considers stale, malformed, unauthorized, and content-tampered submissions, together with individual IPFS node or client failures. It assumes that the permissioned consensus mechanism, certificate authorities, and endorsement threshold are not simultaneously compromised. Under these assumptions, the framework can reject unauthorized or discontinuous transactions, preserve an auditable history of accepted operations, and detect retrieved content that does not match its recorded CID.

Stage 4: Conflict arbitration. When a conflict is detected, the relevant engineers review the structured conflict information and determine a resolution based on design intent, professional judgment, and project coordination requirements. They may retain one change, accept the alternative change, or create a revised change that reconciles the inconsistency. Any revised incremental packet must pass the same authorization, version continuity, and conflict detection checks before it can be accepted. If no agreement is reached, the conflicting submission remains rejected and unmerged. The designated project coordinator may defer the issue, request redesign, or archive the rejected submission for future reference. Automatic conflict detection confirms only the absence of predefined conflict types; it does not automatically resolve substantive design disagreements.

Stage 5: Version release and global synchronization. When the accepted pending records satisfy the configured release conditions, an authorized project manager triggers version release. The framework retrieves the current base model and all valid pending records, verifies their base-version and parent-increment links, and performs a dry-run application of the records in submission order. If the application fails or an orphaned dependency is detected, the release process is stopped and the affected record is returned for review. The current prototype adopts a linear history and assumes that accepted increments are commutative; it does not yet implement multi-branch histories, automatic rollback, or general handling of non-commutative changes. After a successful merge, the updated base model is stored in IPFS, and its CID and version metadata are recorded on-chain. A version-update event is then broadcast so that all participants can download the new base model or retrieve missing incremental records, thereby synchronizing their local modeling environments with the latest released version.

Through this five-stage process, the proposed framework shifts the routine unit of BIM information exchange from complete model files to incremental records. This shift reduces redundant data transmission and storage overhead during iterative design. By integrating a permissioned ledger with content-addressed IPFS storage, the framework also provides traceable records and supports integrity verification. Section 3.2 defines the self-contained incremental packet and the conflict detection procedure, and Section 3.3 describes the dual-layer metadata and storage model.

3.2. Improved TSDT for Distributed Collaboration

In the original TSDT method, incremental extraction generates a mapping dictionary that records the correspondence between IFC-GUIDs and internal identifiers. During model reconstruction, this dictionary is required to restore referenced objects and supplement redundant information. As a result, participating disciplines must synchronize both the incremental record and the associated intermediate mapping files. This dependence on external intermediate files reduces the fault tolerance of model reconstruction. In projects with frequent design changes, the cumulative size of the intermediate files may even exceed the size of the incremental record, undermining the efficiency gains expected from incremental exchange.

To address these limitations, this study extends TSDT by embedding only the mapping entries required by the objects that are affected in the current change. These entries are integrated with the corresponding sequence of operation instructions and encapsulated in a unified incremental data packet, as illustrated in Figure 2. During model reconstruction, the recipient parses the required mapping information directly from the incremental packet and can complete reconstruction without external intermediate files. This improvement ensures that each incremental packet contains the contextual information required for independent reconstruction. Consequently, the incremental record becomes independently transferable and verifiable.

In stage 3 of the framework, multiple disciplines may submit incremental records derived from the same base model. Conflict detection must be performed before incremental records are written to the shared repository. The incremental record extracted by TSDT represents model changes into a structured sequence of operation instructions. The objects to be added, modified, or deleted, together with their corresponding attribute operations (e.g., changes to attribute values such as dimensions, materials, or positions), are explicitly labeled. On this basis, this study classifies conflicts as object-level or attribute-level conflicts. Object-level conflicts arise when operations affect the existence or identity of entire objects (e.g., when one engineer modifies an object while another deletes it). Attribute-level conflicts occur when different operations target the same attribute of an object but produce inconsistent changes (e.g., modifying the same attribute to different values).

Table 2. Conflict classification.

Primary Category	Secondary Category	Description
Object-level conflict	Existence exclusion conflict	One engineer modifies the attributes of an object, while another engineer logically deletes the same object, causing the modification operation to lose its target.
	Topological consistency conflict	One engineer adds or modifies a relationship object, while another engineer deletes the endpoint object on which the relationship depends, thereby violating referential integrity.
	Unique identifier conflict	Two engineers independently add new objects but assign them the same GUID.
Attribute-level conflict	Attribute value conflict	Two engineers modify the same attribute of the same object, but the resulting values are inconsistent.
	Attribute existence conflict	One engineer modifies the value of an attribute, while another engineer deletes the corresponding attribute key.
	Duplicate attribute addition conflict	Two engineers add the same attribute but assign different values to it.
	Attribute hierarchy conflict	One engineer modifies a child node, while another engineer deletes its parent node, thereby disrupting the attribute tree structure.

summarizes the detailed classification according to operation scope and type of mutual exclusion.

Conflict detection is implemented through a hierarchical detection process based on a three-way merge strategy. In this process, the base model serves as the common reference for comparing both local incremental records and previously committed incremental records. From the sequence of operation instructions generated by TSDT, the system extracts the sets of newly added, modified, and deleted objects, as well as the corresponding sets of attribute-level operations.

The detection process begins at the object level. The intersection between the modification and deletion sets is calculated to identify existence-exclusion conflicts. Then, the system traverses the addition and modification sets for relationship objects to determine whether their endpoint objects appear in the deletion set, thereby identifying topological consistency conflicts. In addition, the intersection of addition sets submitted by different engineers is calculated to detect GUID collisions.

After object-level validation, the detection process proceeds to the attribute level. The attribute modification, addition, and deletion sets are cross-referenced. Combined with attribute-path prefix matching, this process sequentially identifies attribute value conflicts, attribute existence conflicts, duplicate attribute addition conflicts, and attribute hierarchy conflicts.

Upon completion of conflict detection, conflicting incremental records are grouped according to conflict type and affected object and returned to the relevant disciplines for arbitration. Non-conflicting incremental records are written into the incremental sequence and trigger the on-chain evidence preservation process.

3.3. Dual-Layer Collaborative Storage Model

To provide record-level integrity verification, operational traceability, and version-history management in a distributed environment, this study adopts a dual-layer storage model integrating a permissioned blockchain and IPFS. The blockchain stores accepted transaction metadata and CIDs, whereas IPFS stores model files and incremental packets. The model creates a verifiable link between an accepted on-chain record and the retrieved off-chain content.

When a file is uploaded to IPFS, the system calculates a cryptographic hash from the file content and generates a unique CID. The submitter then records this CID on the blockchain with relevant metadata, including operator identity, timestamp, and version dependencies. After the smart contract validates the submission, the metadata are written to the on-chain ledger, establishing a binding relationship between the on-chain record and the corresponding off-chain data entity. This forward-anchoring mechanism ensures that each recorded operation can be traced to a unique off-chain file through its CID. Because the CID is derived from file content, any modification to the off-chain file produces a different CID, making unauthorized tampering detectable. Figure 3 illustrates the upload process for incremental records.

When historical data are retrieved, the requester obtains the CID and associated metadata from the blockchain and uses the CID to locate the corresponding IPFS object. Recomputing the CID verifies whether the retrieved content matches the content referenced by the accepted on-chain record. A mismatch indicates altered or incorrect content. This reverse-resolution process verifies file integrity relative to the recorded CID, but it does not prove that the file remains available or that its creator was authorized outside the permissioned transaction context. The process is shown in Figure 4.

In the proposed dual-layer collaborative storage model, operational metadata stored on-chain are organized into three core object types, including project metadata, base model metadata, and incremental metadata. The principal fields of these metadata types are summarized in

Table 3. Principal metadata types and their fields.

Metadata Type	Key Field	Description
Project metadata	Project ID	A unique on-chain identifier used to distinguish one project from another.
	Project name	A descriptive project name.
	Base version	The version tag pointing to the latest released base model of the project.
	Base CID	The content identifier of the latest base model stored in IPFS, used for off-chain file location and integrity verification.
Base model metadata	Model ID	A unique on-chain identifier of a specific reference model version.
	Version ID	The version tag of the base model, representing a milestone in the model evolution process.
	Parent version	The preceding reference model version on which the current version is based, used to trace the evolution chain of the base model.
	Included increment	A set of identifiers for the incremental records merged from the parent version into the current version.
	CID	The content identifier of this model version stored in IPFS.
	Status	The state of the current model version, categorized as either “shared” or “archived”.
Incremental metadata	Increment ID	A unique on-chain identifier of an incremental submission.
	Base version	The base model version on which the incremental record is generated, used to verify version continuity.
	Parent increment ID	The identifier of the preceding incremental commit under the same base version, used to construct the incremental commit sequence.
	CID	The content identifier of the incremental record stored in IPFS.
	Status	The state of the current incremental record, categorized as either “pending merge” or “merged”.

.

In addition to these principal fields, all three metadata categories contain supplementary fields such as the evidence hash, timestamp, and channel affiliation of the corresponding blockchain transaction. These fields provide an audit trail under the configured consortium identity and endorsement policies. Through identifier-based associations, the three metadata categories form a hierarchical version-evolution network that includes both the base-model evolution path and the incremental-record evolution path, as illustrated in Figure 5.

Project metadata locate the latest model state through a pointer to the current base version. Base model metadata are linked sequentially through parent-version identifiers, enabling stepwise traceback from the current version to the initial version and providing a complete record of macro-level model evolution. At the same time, each base version records the set of changes incorporated into it through a list of increment identifiers. Incremental metadata form an ordered commit sequence through parent-increment identifiers. They also establish dependency relationships between incremental records and base models by pointing to the base version used as the contextual reference when the incremental record was generated. This structure enables the collaborative storage system to support traceable version evolution, verifiable data checking, and distributed model reconstruction across on-chain and off-chain environments.

IPFS content addressing does not eliminate the need to manage parent files or guarantee their availability. Under the proposed operational policy, the current base model and all unmerged packets must remain pinned by more than one authorized organization. Files incorporated into a released base version may be moved to a governed archival tier after a retention period, while their CIDs and version metadata remain on-chain. Garbage collection must exclude required pinned and archived objects, and a missing object must block reconstruction or release until a replica is restored.

BIM models may contain sensitive information. A private swarm key isolates the prototype IPFS network, but it does not provide per-file confidentiality or prevent an authorized node from reading stored content. Therefore, production deployment requires encryption before upload, secure key distribution, role-based retrieval authorization, and key-revocation procedures. These confidentiality controls are outside the scope of the current prototype and are identified as future work.

4. Prototype Demonstration and Evaluation

4.1. Experimental Setup and Workflow Demonstration

The collaborative design scenarios involved four organizations, including a general design contractor (Org1), an architectural design team (Org2), a structural design team (Org3), and a supervision team (Org4). Each organization independently deployed a certificate authority node, a client SDK, a peer node, and an IPFS node for identity management, on-chain interaction, ledger maintenance, and off-chain file storage, respectively. The ordering service globally ordered evidence proposals and generated blocks.

The experimental configuration was as follows. A server running Ubuntu 22.04 with a 16-core Intel processor, 32 GB of RAM, and a 2 TB hard drive hosted the consortium blockchain network and private IPFS cluster. Docker containers isolated the logical blockchain and IPFS nodes of each organization. The blockchain used Hyperledger Fabric 2.4 with Raft ordering, and the IPFS environment used Kubo 0.39.0. Smart contracts were developed in Node.js, backend business logic in Python 3.9, and BIM models in Autodesk Revit 2025 exported to IFC4.

To demonstrate that the prototype can execute the proposed workflow, four representative scenarios were designed, covering project creation and base-model initialization, parallel editing and incremental submission, version release and global synchronization, and concurrency conflict arbitration. These scenarios are workflow demonstrations and should not be interpreted as comprehensive tests of correctness, robustness, scalability, or conflict-classification accuracy.

Scenario 1: Project creation and base model initialization. In this scenario, the general design contractor creates the initial BIM model locally. The model is uploaded to IPFS, where a content identifier, denoted as CID_M0, is generated. Then, the contractor submits the project identifier, project name, CID_M0, and other relevant information to the blockchain. After the smart contract verifies the identity of the submitter, it creates a project metadata object and a base model metadata object on-chain. The operator identity and timestamp are also recorded on the blockchain as evidence, as illustrated in Figure 6. After initial registration, the architectural and structural engineers retrieve CID_M0 from the blockchain, download the corresponding model file from IPFS, and import it into their local modeling software. This process ensures that all engineers use the same base model as the unified starting point for subsequent collaborative design.

Scenario 2: Parallel editing and incremental submission. In this scenario, the architectural designer adds a door to the south-facing wall of the reference model and relocates a window. At the same time, the structural engineer removes a structural column from the lower part of the same wall. They use TSDT to extract their respective incremental changes, denoted as Δ1 (architectural design change) and Δ2 (structural design change). The architectural designer first uploads Δ1 to IPFS, obtains the corresponding content identifier CID_M1, and submits it to the blockchain together with the operator identity, timestamp, and the reference base version on which the incremental record is generated. After the smart contract verifies the submission, the incremental metadata are written to the ledger, as shown in Figure 7. The structural engineer subsequently submits Δ2 using the same procedure. The conflict detection mechanism determines that there is no conflict between Δ1 and Δ2, and the incremental metadata for Δ2 are also recorded on-chain. The two incremental records are linked through their parent-increment identifiers, forming an ordered sequence of incremental submissions under the same base version.

Scenario 3: Version release and global synchronization. In this scenario, version release is triggered after the incremental submissions are completed. The incremental records Δ1 and Δ2 are applied to the base model in submission order, generating a new base model. The updated model is uploaded to IPFS, producing a new content identifier, denoted as CID_M2. The metadata of the newly generated base model are added to the blockchain. At the same time, the pointer to the current base version in the project metadata is updated, and the status of the merged incremental metadata is synchronized accordingly. The process is illustrated in Figure 8. After receiving the version update event, all organizations can obtain CID_M2 from the blockchain, download the corresponding model from IPFS, and synchronize their model views. This process maintains a consistent view of the latest released model.

Scenario 4: Concurrency conflicts and arbitration. The architectural designer modifies the position of a window while the structural engineer deletes the same window. The deletion is submitted first. When the modification is submitted, the detector reports an existence-exclusion conflict and returns the affected component and operations, as shown in Figure 9. The architectural designer then revises and resubmits the change. This scenario demonstrates only one rule from Table 2; the current evaluation does not measure false positives or false negatives across all conflict categories.

4.2. Example of Incremental Extraction and Reconstruction

To illustrate incremental extraction and reconstruction, we use a simple scenario. The baseline is a BIM model containing a window on an external wall. The modified model introduces three changes, with one window moved to the left, another window on an adjacent wall deleted, and a door added, as shown in Figure 10.

Both model versions are processed using the improved self-contained TSDT method. The method represents the window relocation as one attribute modification, the window removal as one object deletion, and the door insertion as one object addition. These operations are packaged with the mapping fragment required to link the affected IFC-GUIDs to internal IFCJSON-GUIDs and with dependencies for the associated geometric and property-set changes.

The improved TSDT reconstruction procedure is then applied to the baseline BIM model using the extracted packet. Figure 11 compares the baseline and reconstructed models. The three primary changes in this worked example were reproduced.

Table 4. Operations and reconstruction outcomes in the worked example.

Operation Type	Affected Element	Count	Packet Representation	Reconstruction Outcome
Attribute modification	Window relocation	1	attributeOps + mappingFragment	Reproduced
Object deletion	Adjacent window	1	objectOps.delete + mappingFragment	Reproduced
Object addition	Door	1	objectOps.add + mappingFragment	Reproduced

reports the operation counts and reconstruction outcomes.

4.3. Performance Evaluation

The performance of on-chain evidence preservation and off-chain file storage directly influences the response time of incremental commits and the transmission efficiency of version synchronization. It is therefore critical to determining whether the proposed framework can support high-frequency collaborative design. Accordingly, this section evaluates the blockchain-based evidence preservation mechanism and the IPFS-based off-chain storage mechanism separately.

To evaluate the performance and stability of the consortium blockchain network built on Hyperledger Fabric, as well as the execution efficiency of the deployed smart contracts, load testing was conducted using Hyperledger Caliper. The tests measured transaction throughput, transaction latency, and system resource consumption under different business scenarios. The Caliper client was configured with 15 concurrent workers to simulate a high-concurrency environment in which multiple clients submit requests to the blockchain network simultaneously. The specific test scenarios are summarized in

Table 5. Test scenarios for performance evaluation.

Scenario	Business Logic	Load Type	Test Volume
Project creation	Invoke the project creation contract to create a new BIM project and initialize its basic information.	Fixed-load test simulating baseline data writing during system initialization.	200
Incremental record submission	Invoke the incremental record submission contract to upload BIM model incremental data.	Fixed-rate test with a sending rate of 100 TPS, simulating high-concurrency submissions during parallel model modification.	500
Model version release	Invoke the model version release contract to verify the status of multiple incremental records and generate a new model version asset.	Fixed-rate test with a sending rate of 50 TPS, simulating peak load during version iteration.	100
Asset query	Invoke the asset query contract to retrieve project or version details.	Linear-rate test in which the request rate increases from 100 TPS to 300 TPS to evaluate the read-performance limit of the system.	1000

.

Table 6. Comprehensive performance test results of Caliper.

Scenario	Suc.	Fail	Send Rate (TPS)	Max Latency (s)	Min Latency (s)	Avg Latency (s)	Throughput (TPS)
Project creation	195	0	33.8	2.12	0.03	0.14	33.6
Incremental record submission	495	0	102.1	2.03	0.03	0.08	72.2
Model version release	109	0	61.2	0.34	0.03	0.10	59.5
Asset query	990	0	150.3	0.02	0.00	0.00	150.2

reports the transaction counts, offered rates, achieved throughput, and latency values from the Caliper report. In the incremental-submission scenario, the offered rate was 102.1 TPS and achieved throughput was 72.2 TPS, indicating that prototype did not sustain the offered load. Average latency was 0.08 s. The model-release and asset-query scenarios achieved 59.5 TPS and 150.2 TPS, respectively.

To assess the off-chain storage layer, a private IPFS cluster with four logical organizational nodes was deployed as Docker containers on one physical server and connected through a dedicated Docker network. The nodes shared a swarm key for network isolation. This configuration supports controlled functional and upper-bound performance testing under low-latency local conditions. The test dataset contained 50 IFC model files ranging from 25 KB to 225 MB, with a total size of 2.6 GB. The files are classified into five size tiers. Upload time was measured from API request initiation until CID return. Each file was downloaded from all four nodes, and the process was repeated three times per node. The benchmark did not clear IPFS or operating system caches between repeated downloads, nor did it examine node failure or geographically distributed links. Therefore, the reported download throughput may reflect cache and local-network effects.

Table 7. Upload performance by file size tier.

Tier	File Count	Avg. Throughput (MB/s)	Avg. Upload Time (s)
Tiny (<100 KB)	13	12.4	0.008
Small (100 KB–1 MB)	14	37.1	0.019
Medium (1–50 MB)	9	91.5	0.159
Large (50–150 MB)	3	161.9	0.660
Extra-large (>150 MB)	11	314.8	0.676

reports observed upload throughput and time by file-size tier. Throughput increases with file size because the fixed costs of chunking, hashing, and Merkle-DAG construction are amortized over larger payloads. In the single-server test, small files between 100 KB and 1 MB averaged 37.1 MB/s and 0.019 s per upload.

Table 8. Average download throughput (MB/s) by file size tier and node.

Tier	Org1	Org2	Org3	Org4
Tiny (<100 KB)	24.12	7.89	9.7	10.13
Small (100 KB–1 MB)	43.52	34.46	46.3	50.54
Medium (1–50 MB)	127.21	118.58	130.4	129.82
Large (50–150 MB)	261.16	180.67	214.33	218.03
Extra-large (>150 MB)	48.44	94.54	90.96	83.41

reports the average observed download throughput by file-size tier and node. For most tiers, throughput increases with file size, reflecting the amortization of fixed request and processing overheads. However, the extra-large tier shows a pronounced decline, which is mainly attributable to the inherent overhead of the IPFS Bitswap protocol. Specifically, the large number of blocks associated with extra-large files increases control-message exchanges and constrains transfer parallelism, thereby reducing effective throughput.

Table 9. Average download time (s) by file size tier and node.

Tier	Org1	Org2	Org3	Org4
Tiny (<100 KB)	0.002	0.011	0.009	0.006
Small (100 KB–1 MB)	0.016	0.015	0.011	0.009
Medium (1–50 MB)	0.297	0.174	0.125	0.127
Large (50–150 MB)	1.790	2.064	1.467	1.361
Extra-large (>150 MB)	6.005	3.130	5.628	6.001

reports the average download time by file-size tier and node. In the local deployment, files smaller than 1 MB generally completed within 0.002–0.016 s. The extra-large tier exhibits longer download times, ranging from 3.130 s to 6.001 s, consistent with the throughput decline observed for this tier. Because caching was not controlled and all nodes were co-located, these values should be interpreted as upper-bound local measurements and should not be directly extrapolated to multi-site user experience.

4.4. Comparative Test of Incremental Transmission Efficiency

To directly evaluate the reduction in transmitted data, this section compares incremental-packet sizes with modified full-model sizes across seven change scenarios with difference rates ranging from 0.046% to 294.91%. The difference rate is defined as the basic TSDT packet size divided by the baseline-model size. The reduction ratio is calculated as (modified-model size − incremental-packet size)/modified-model size, multiplied by 100%.

Table 10. Comparison of full-model and incremental packet sizes.

Scenario	Full Model (MB)	Modified Model (MB)	Difference Rate	TSDT (KB)	Reduction Ratio	Improved TSDT (KB)	Reduction Ratio (Improved)
1	0.30	0.50	17.41%	52.22	89.56%	53.25	89.35%
2	5.87	5.86	0.14%	8.19	99.86%	17.41	99.70%
3	6.70	6.72	0.046%	3.07	99.95%	10.24	99.85%
4	0.02	0.03	20.48%	4.10	86.33%	5.12	82.93%
5	0.30	0.30	0.68%	2.05	99.32%	3.07	98.98%
6	0.30	5.86	294.91%	884.74	84.90%	2081.79	64.47%
7	0.04	0.08	40.96%	16.38	79.53%	23.55	70.56%

summarizes the results.

For minor changes with a difference rate below 1%, the improved TSDT packet size remains below 20 KB and achieves a reduction ratio greater than 98%. This result confirms that, for typical design iterations involving small adjustments, the framework can avoid almost all full-model data transmission. For moderate changes with difference rates of approximately 17% to 40%, as in Scenarios 1, 4, and 7, the reduction ratio ranges from 70% to 90%, still representing substantial savings. Even in the extreme case of Scenario 6, where the difference rate reaches 294.91%, the improved TSDT method achieves a reduction ratio of 64.47% relative to the modified model size. Because the improved TSDT method embeds mapping dictionaries for self-contained reconstruction, its packets are slightly larger than those of the basic TSDT method; nevertheless, both methods substantially reduce data volume compared with full-model transmission.

5. Discussion

The proposed framework integrates mechanisms that previous studies have examined separately. Xue et al. [31] and Kong et al. [32] provide important foundations for semantic differential transactions and traceable representations of semantic change, while Tao et al. [40] demonstrates the feasibility of a blockchain-IPFS-based common data environment. Building on these foundations, this study connects self-contained TSDT packets, explicitly defined conflict checks, permissioned transaction acceptance, and bidirectionally associated on-chain and off-chain metadata within a unified incremental BIM collaboration workflow.

A key value of the framework is that it provides bounded record assurance for incremental BIM collaboration. Through the blockchain-IPFS layer, each accepted transaction links an authenticated consortium identity, verified metadata, and a content identifier. Because the CID is generated from file content, recomputing the CID after retrieval can reveal whether the off-chain packet differs from the content originally recorded. This mechanism supports authorization, auditability, version traceability, and record-level integrity verification under the stated governance assumptions. However, this assurance is limited to the integrity and traceability of accepted records. It does not guarantee the correctness of submitted design content, the confidentiality of off-chain files, the continued availability of IPFS-hosted content, or the absence of collusion among authorized participants.

The self-contained packet design addresses a practical limitation of the original TSDT reconstruction process. Instead of requiring access to the complete source model, the improved packet embeds the semantic objects, mapping fragments, and dependencies needed to reconstruct the affected changes. The receiving party can reconstruct changed model content independently from the submitted packet. The prototype example demonstrates reconstruction of one addition, one deletion, and one attribute modification, while the seven experimental scenarios show that substantial transmission savings can still be achieved after adding the information required for independent reconstruction. These results indicate that the packet design can reduce redundant BIM transmission when changes affect only a limited portion of the model.

The hierarchical conflict detector further improves the reproducibility of incremental collaboration by translating qualitative conflict categories into explicit set-based and attribute-path-based rules. When a conflict is detected, the framework returns structured information, including the violated rule, affected object and attribute paths, and inconsistent operations. This output supports manual arbitration by helping project participants identify where and why a conflict occurred. Nevertheless, automatic conflict detection should not be interpreted as automatic design resolution. The current module checks only predefined conflict types and cannot determine design priority, professional acceptability, or the best solution to a substantive design disagreement.

The evaluation demonstrates technical feasibility under controlled conditions. On-chain incremental submission achieved 72.2 TPS with an average latency of 0.08 s. The private IPFS experiment produced an overall average download throughput of 96.2 MB/s across the reported node-tier values. These results suggest that the proposed workflow can be executed with measurable transaction and retrieval performance in the experimental setting. Among the reported experiments, the incremental-size comparison provides the strongest direct evidence. Across the seven tested scenarios, improved TSDT packets reduced transmitted data volume by 64.47% to 99.85% relative to modified full models.

6. Conclusions

This study proposed and demonstrated an incremental BIM collaboration framework that integrates self-contained semantic change packets, explicit conflict-detection rules, permissioned blockchain records, and IPFS-based off-chain storage. The framework is designed to reduce redundant BIM data exchange while preserving traceable and verifiable records of accepted incremental operations. The findings show that the improved TSDT packet can support independent reconstruction of selected semantic changes while substantially reducing transmission volume in the tested scenarios. The blockchain-IPFS layer provides record-level integrity verification and traceability by associating authenticated transaction metadata with content-addressed off-chain packets. The hierarchical conflict detector further formalizes conflict identification by converting collaboration conflicts into explicit rule-based checks. Together, these results indicate that the proposed framework offers a technically feasible approach for managing frequent BIM updates in distributed collaboration settings.

Several limitations remain and should guide future research. The study was conducted in a controlled single-server environment using a Revit-to-IFC4 workflow and a limited number of change scenarios. Future research should validate the framework in heterogeneous network environments, test its compatibility with multiple IFC-compliant authoring tools, evaluate all conflict categories using labeled datasets, and improve off-chain storage and non-linear version control. Further studies should also assess whether incremental BIM collaboration delivers measurable project-level benefits, such as reduced rework and lower coordination costs.