Abstract
The paper introduces a framework for decentralised architectural design in the context of the fourth industrial revolution. We examine first the constraints of building information modelling in regard to collaboration and trust. We then introduce Blockchain infrastructure as a means for creating new operational and business models for architectural design, through project governance, scaling collaboration nominally to thousands of agents, and shifting trust to the infrastructure rather than the architectural design team. Through a wider consideration of Blockchains in construction projects we focus on the design process and validate our framework with a prototype of BIM design optimisation integrated with a Blockchain mechanism. The paper concludes by outlining the contributions our framework can enhance in the building information modelling processes, within the context of the fourth industrial revolution.
Keywords
Introduction
The history of industrial revolutions showcases the upgrade of human productivity in successive steps. 1 The first industrial revolution in the 1700’s brought mechanised production and the concept of the production line, driven through the power of water and steam. The second industrial revolution, in the 1870s, exploited the development of electricity in creating systems of mass production. Almost a century later, in the 1960–70s the third industrial revolution began with the rise of electronics and computers, famously praised by the late Steve Jobs as a ‘bicycle for our minds’. 2 We are now at the advent of the fourth industrial revolution where biological and computational systems converge, as an acceleration of the third industrial revolution.3,4 At the core of the fourth industrial revolution, lies the automation of industry, with the exploitation of Artificial intelligence, Blockchain and Robotics. The use of blockchain in architectural design and construction, within an industry 4.0 context has seen an abundance of speculative research, but a dearth of actual implementations that showcase the potential of the technology. This is constrained further within the Building Information Modelling (BIM) space, where there is clear knowledge gap, as researchers have not yet investigated thoroughly the interplay of the two technologies. 5
Furthermore, the fourth industrial revolution’s challenges for the stakeholders in the construction sector include risks associated with increased financial transparency, radical shifts in operational and organisational processes, and unclear regulatory landscapes, while the opportunities include increases in productivity and reliability, the establishment of legal frameworks that reduce uncertainties, and the safety enhancements by eliminating or mitigating risk. 6 Blockchain technologies, due to their decentralised nature can provide a response to some aspects of these challenges and contribute significantly in enhancing and delivering novel opportunities. The blockchain’s public ledger of transactions has been hailed as an excellent example of transactional transparency, while its decentralisation features can be an excellent fit to the fragmented nature of the construction industry. Moreover, smart contracts and automatic execution of code provide improved reliability through requiring stakeholders to negotiate and agree all aspects of projects before legal issues arise.
This paper explores the features of a framework of governance, trust and incentivisation in decentralised systems for architectural design by integrating building information modelling (BIM) with blockchain at the computational level. We validate our framework through a proof of concept BIM–Blockchain Integration in architectural design. In our prototype, agents compete to create an optimum design for a given problem, where each intermediate optimum solution found in the design space is used to synchronise all other agents’ solutions. The processes presented in the paper diverge from known and well-established processes of project governance in architectural design as they enable immutability of the design decisions taken, and decentralisation with ‘trust-less’ frameworks. Essentially with our framework, one does not need to establish trust with their stakeholders to deliver the design project. In parallel, the blockchain processes described are an excellent fit for the fragmented nature of the AEC industry in the sense that they avoid several of the seven deadly sins of BIM. 7 These are ‘Elision-Omission’ of believing that design takes place early in the project in projects that heavily use BIM, or the shortcomings of Integrated Project Delivery (IPD) methods, where stakeholders need to put the interests of the project above the interests of their own organisation. Blockchain can also alleviate ‘Diffidence’, that is the need for process change when adopting BIM practices, and ‘Monocultures’, that is design in disciplinary silos, without adopting a process for data exchange and design acumen between disciplines. 7
Background
Building Information Modelling
BIM is an operational paradigm where n-dimensional models are created and used by multiple stakeholders to visualise and manage what is to be built, solving any design, construction or operational issues. BIM is positioned to be used by the full gamut of the Architecture, Engineering and Construction (AEC) industry and is elected at the moment as the prevalent paradigm of integrated collaboration in architectural design, and indeed in Integrated Project Delivery (IPD). Within IPD, professionals rely on and trust BIM tools as agents in the AEC team, while stakeholders from the clients to regulatory authorities can, in theory at least, participate and access BIM models centrally. However, issues of design problem framing, trust, reliability and transparency of operations still remain within the BIM paradigm. 8
Building Information Modelling: fragmentation
Claims of a single authoritative version of a BIM database go only so far as the trust stakeholders have in the maintainer and owner of the database, and the infrastructure that the database operates on.9,10 Any critical failure at single points in the infrastructure or the database translates into loss of data and integrity for the whole BIM system. The issue of trust and governance is also connected with the transparency and ownership over the BIM files a team operates on: file version and control in an AEC team is complex, more so when in practice BIM models are fragmented over multiple files. Within IPD teams, automation of BIM via extensions can be successful for collaborative tasks. 11 Similarly, one of the aforementioned seven sins of BIM, is the implicit packaging of IPD with BIM, an assumption that is not understood often by stakeholders who adopt BIM. We propose a networked hybrid approach as an alternative to extend BIM, where collaborators mix working through a central server with peer-to-peer collaboration and direct exchange of electronic files. 12 Within that system, a number of teams work in tandem in their own BIM silo, with information coordinated amongst the silos at key moments. Those moments are the ones where the team achieves consensus on which is the latest ‘true’ version of information that represents the current state of the project. Time as a critical component of making decisions informs also the design at larger scales such as masterplanning. 13 A map of the fragmented nature of BIM operations, through the usage of social media and data flows in BIM processes, can help establish quality assurance and responsibility within the project. 14 Within such a map, the conditions for the success of collaboration using design tools within the BIM paradigm: ‘BIM’ must be set up as a design process rather than a ‘design’ tool, so that bottlenecks in collaboration can be identified. While BIM is promoted as a centralised paradigm, the nature of collaboration amongst AEC teams using tools within BIM processes is fragmented and works best when the fragmentation and decentralisation are accommodated, rather than resisted.
Building Information Modelling: trust
Still, in this fragmentation and distributed manner of working, ‘truth’ is validated between different versions of the BIM files as information processing is dispersed between agents. By examining trust in distributed agent-based design problems, it is difficult to assign trust in a design agent automatically. 9 Within this difficulty, there exists an issue of trust within AEC virtual teams when a higher than normal effort and reflexivity is needed on their part to trust data that is entered into the database by others. 10 The issue of trust then becomes connected and is correlated with the performance of a team, as agents in a distributed group need to know which action to take in response to stimuli from other agents. We conclude then that BIM collaborations would benefit from a mechanism that records data flows immutably, assigns responsibility to all stakeholders according to their role and actions, and secures transparency in data entry and sources. The importance lies in being able to communicate actions across a distributed team, in absolute, stigmergic coordination.
Blockchain-distributed ledger technologies
Distributed ledger technologies, and specifically Blockchain, are essentially computer state machines distributed between various decentralised computing nodes. 15 Due to their distributed nature, there exists a difficulty in establishing a common and agreed version of the truth between nodes, as it would be possible to write two different strings in two different computing nodes hosting each part of the record. This would lead of course to the record being unable to show a single value corresponding to a single query, but instead serving multiple different answers to the same query. To solve this, most Blockchains use a computational mechanism (called ‘mining’) to establish consensus regarding which operation and transaction on a distributed database network is true and which one is not, 16 by creating a new block of data, validating a series of transactions, and encapsulating a cryptographic hash of these operations and the cryptographic hash of the previous block of data. 15 Thus, the term Blockchain is created. 16 This provides additional benefits compared to other BC platforms such as Bitcoin 15 like the possibility of automatically executing smart contracts. The full Ethereum network with all participating nodes (mining, full nodes and light clients) is a full ‘Turing’ machine, called the Ethereum virtual Machine (EVM), on which values are stored and smart contracts are executed. ‘Turing’ equivalence means that the Ethereum Blockchain presents all features of ‘Turing’ completeness, implying that one can treat the Ethereum Blockchain as a generic computing infrastructure, capable of emulating other computers. This also means that the Ethereum Blockchain is also susceptible to the problem of ‘incomputability’, that is not knowing, for all classes of problems, whether a computation will terminate with a solution or indefinitely loop with no halting mechanism, before one attempts the computation. 17 Subsequently, the Ethereum Blockchain has a built-in halting mechanism, in the form of computation or transaction fees, called Gas. Using the metaphor of fuel, computations in the Ethereum Blockchain halt when they run out of gas.17,15
Framework for decentralised architectural design
BIM is nowadays crucial to the design of buildings, expecting an integrated construction industry, where the models produced through a BIM process are used directly for construction. The building design then, and the manner in which the model is made is also crucial. Normally there is a top-down hierarchical structure with which a project is governed, with few agents-architects in the process having the authority to make decisions. This highly conservative approach reduces the potential for good ideas to emerge and contribute to the project from the agents participating in the periphery of governance.8,14 These decisions are so excluded as there is a heavy burden in hierarchical bureaucracy and not easily channel towards a final output. In BIM environments, prototypical templates, usually called families, can be re-used, with parametric variation, in multiple projects. Families allow the standardisation, documentation and distribution of the accumulated intellectual property (IP), experience and knowledge in an architectural office. Sharing those BIM families openly, in a project with other collaborators that in the future may be competitors can compromise the ability of any architecture firm to defend and further monetise their IP in subsequent projects. In contrast, participating in a project using a BIM paradigm requires the initial establishment of trustworthiness and reliability, usually through economic means by requiring a certain financial or insurance liability investment from a firm, excluding potentially capable agents to participate in a design project. Hence BIM projects become a matter that only larger offices can control. In parallel, BIM requires the maintenance of costly centralised infrastructure in localised servers or the use of ‘cloud servers’ owned by third parties, creating additional potential risks. 10 Hence the advantages blockchain offers, of decentralisation, of immutability of decisions and files, of protecting intellectual property, are a good fit to enhance some of the shortcomings of centralised BIM implementations.
All decision-making frameworks on whether to use a decentralised ledger or blockchain, employ two questions: are the participants known, and are their interests aligned?.5,18 Currently, the only stage where participants are not known in architectural design are in anonymous architectural design competitions. In all other cases, architectural design teams operate after they have established both the identities of the participants and a level of trust in each member of the team, even though as the number of disciplines in a team grow, this level of trust erodes. 9 Within our framework, trust in the team members is not needed as it is assigned to the underlying technical system of the public permission-less blockchain. As such our framework can be deployed at the early stages of a construction project, aligned with an IPD mechanism. 19 This establishes a new business and operational model of architectural design where design agents do not need to establish trust to operate.5,18
Prior elementary work on BIM-Blockchain integration
In our previous work, we have discussed how agents can establish a level of trust through integrating a CAD system with smart contracts on a Blockchain. 20 From this investigation, we framed four possible levels of integration between BIM systems and a Blockchain. We consider this framework as the basis of any infrastructure relationship that can exist between BIM and Blockchain (Figure 1).
Four levels of BIM to Blockchain integration (figure drawn by T Dounas, 2020).
These levels are: (1) A blockchain operating completely inside a BIM environment, (2) BIM and Blockchain connected through the web, (3) BIM and blockchain integrated through a blockchain (Ethereum node) and, (4) BIM running with its database completely implemented as a decentralised blockchain. Within this analysis of BIM to Blockchain integration levels, we have explored team reflexivity, trust and collective decision-making in a design project where a distributed team, through creating a series of shape grammar, operates as a ‘Decentralised Autonomous Organisation’ (DAO) on the Ethereum Blockchain. 20
Decentralised Autonomous Organisations
The idea of the DAO, that one can form and run fully Decentralised Autonomous Organisations on smart contracts, with no other organisational principle or physical connection other than the code of the contracts is a manifestation of shifting trust from the people to the underlying infrastructure. Although DAOs can be currently used for design governance, they are still far from being suitable for iterative exploration of issues of engineering or design performance. Due to their distributed nature, DAOs can establish collaboration within large groups and facilitate decisions for a wider construction programme, but are not yet efficient to the level of execution, where a network of collaborative, but independent agents provide better solutions. As such DAOs might be a better fit for setting a general direction for the ‘wicked’ nature of design but not play an active role as infrastructure in the act of designing itself, where integrated tools are needed. Both of our previous prototypes fill a knowledge gap that other researchers have identified in the application of Blockchain technologies in the construction industry, specifically the application of and integration with BIM. 5
We can deduct thus that a framework for governing and implementing decentralised architectural design projects can be envisaged that aligns within a larger context of using the blockchain and smart contracts in BIM in AEC, that is to design, construct and operate buildings.5,15,18–24 In this DAOs set the general design direction and the optimisation prototype presented here executes the design optimisation (Figure 2).
Framework for governing an AEC project, from design to construction to operation (figure drawn by T Dounas, 2020).
In parallel, the creation of reference models for BIM where complex information can be represented and manipulated by a surrogate topologically connected models is an important tool in reducing information clutter, file sizes and complexity in the early stages of architectural design work using BIM tools. 25 This greatly simplifies geometric representation, transformations and complex operations of energy analysis and structural optimisation. Coupled with this type of information densification and encapsulation, the potential use of Blockchain to record idea generation, design manipulation and optimisation becomes invaluable. This programming and representation paradigm have the capacity to reduce complex, data heavy, BIM mechanisms into simple, but rigorous geometric representations that maintain topological and semantic information. It also brings to the fore a capacity for cross-translation of visual scripting languages between various CAD and BIM packages. This abstraction allows computational designers to sketch the logic of computational design ideas and implement them in a platform-agnostic manner, enabling for the interchange of computational designs between a variety of 3D software platforms with visual scripting capabilities (Figure 3).
Topologic library running on Dynamo/Revit 26 (software by Jabi et al., 2018, figure captured by T Dounas, 2020).
Research goals, methods, constraints
Goals
Our goal is thus to create a BIM to Blockchain integration for the design part of the framework. This can take two forms:
Software that establishes performance-based integration between BIM and the Blockchain. Collaborative and competitive design projects will be simulated through applying performance-based optimisation strategies. In this combination of smart contracts and BIM plugins we envisage a series of optimisation techniques that are applied in a BIM model, each one triggering a new action to be written to the blockchain. Thus, the team will be able to concisely and elegantly organise work to be done in optimisation, assigning each optimisation to various agents who can work either collaboratively, within the same organisation, or competitively. The knowledge gained from such a process will drive changes to the manner in which work is outsourced or distributed amongst participants in an organisation or outside the organisation. This will also enable large and complicated architectural design studies to be succinctly be implemented by a collective rather than centralised entities. In effect, such software will allow the scaling of the size of an architectural design team and the assumption that agents of the team can be completely automated and be assigned to an Artificial Intelligence (AI).
Smart contracts and the infrastructure to track changes to a model on the Ethereum Blockchain. The software will visualise a series of trusted changes to a model, and thus we will be able to identify moments of value creation during the design process. In parallel it will allow the release of digital BIM families, self-contained parametric components of buildings on the internet, traceable through the blockchain, where change or use to the BIM family can trigger payment or approval by the original owner of the file. This will create new business and labour models for architecture. 27
As such we have developed a prototype of this first form of BIM to Blockchain Integration, where the design performance of a computational script would be used to achieve consensus between various design agents. Ultimately, we are establishing a process where design agents would be incentivised to compete or collaborate to the desired effect working in a design environment linked to a BC platform. A divergence from established paradigms is the scale, nature and identity of these agents: there is no restriction on numbers since they could be thousands or millions, on their identity since there is no need for the system or the DAO to trust them before they begin designing, and their nature, as they can be human, artificial, or hybrid, agents. Thus, our framework diverges from established paradigms where trust exists between the design agents. On a computational level, the challenge that we faced is the interaction of BIM clients to the ETH Blockchain, to establish synchronisation and consensus. 15 True blockchain decentralisation of the whole BIM infrastructure presents significant challenges, as one needs to replace every component of their infrastructure. This is of course a constraint that needs to be measured against leaving things as they are. 18 However, the integration of BIM to Blockchain where the database, computation and memory are all decentralised would be a true decentralised BIM.
Methods
We have employed a hybrid research method, combining an evolutionary prototype built-in software, 28 which validates concepts in computational design that we developed through the building of our framework for decentralised architectural design. Evolutionary prototypes are essentially empirical experiments in software design and engineering, where the researchers create a functional system as a base for evolving the full functionality later. 29 Our software allows for cross-platform communication between BIM platforms and their respective visual scripting APIs and environments. The qualitative method we employ on design research focused on the dimensions of collaboration, trust and incentivisation in BIM teams/design agents. Our prototype essentially uses the ETH blockchain as the decentralised neural system that allows a stigmergic coordination between competing/collaborating agents. For brevity, only the collaborating version of the prototype is presented here.
Constraints
Others 21 have discussed incentivisation and have outlined Dynamo/Revit prototypes that are similar in nature with the first level of Blockchain to CAD integration we have described in our previous work. In this setup, actions are encapsulated in a private Blockchain that runs inside the visual scripting environment. Having already achieved a communication of a visual script with a Blockchain that executes inside the BIM environment 20 we set out to establish communication of a BIM client instance and integration with the Ethereum Blockchain, as this would establish trust, due to the blockchain’s immutability. The prototype presented in this paper is constrained to a particular scope of collaboration and incentivisation in decentralised design teams, where the Ethereum Blockchain plays a core role in the governance and regulation of the collaboration. The prototype is not a complete solution for BIM to Blockchain interplay and integration but establishes a base for potential avenues of further development and research.
Software prototype integrating BIM with the Ethereum Blockchain
Design overview of the prototype
We have developed a BIM to Ethereum software prototype, that uses design performance as a vehicle to navigate issues of consensus, trust, transparency, responsibility and incentivisation between design agents in a distributed design environment. We have structured the prototype in a manner that allows interoperability between digital tools that can communicate with the Blockchain Ethereum. We simulate three design agents that are working each within their own software platform. However, the platform can scale to thousands of agents, irrespective of whether an agent is a human designer or machine learning algorithm. Our expectation is that similar tools may be developed in the future to use the blockchain as the main tool to record information in a resilient manner, allowing to record the sequence and decision making of both humans and AI/Machine learning algorithms in a team. The agents in both competition and collaboration mode synchronise between themselves and achieve consensus at particular inflection points through the blockchain (Figure 4).
Three agents solving a design problem, where they achieve consensus in particular inflection points (figure drawn by T Dounas, 2020).
In our scenario, all three agents are attempting to solve a structural design problem that has been deployed by a DAO as a smart contract at an address on the Blockchain. Note that for the purposes of the exercise, no formal legal contract or trust needs to be established between the agent-designers and the DAO. This is different to the established trust paradigm of negotiating agreements before a collaboration can begin. The DAO acts as the stakeholder who sets the design problem. Within the DAO any stakeholder can participate through their own Ethereum address and stake tokens towards desirable outcomes. This means that we can include non-expert participants in the governance of the design project, by having them participate in the DAO, without eroding the knowledge and decision-making capacity of the experts. 20 Our prototype governs the solution to a design problem after the DAO has made a proposal to use this particular method.
The DAO that acts as problem setter is essentially a collective entity that uses the Ethereum blockchain to take strategic decisions on a project through the allocation of funds for incentivisation. The designer-agents, beyond just searching for an optimised solution, have the opportunity to re-formulate the problem that they are being asked to optimise. Within this possibility, each designer can propose their own version of how to formulate the optimisation solution, in a sense the manner by which to ask the question. This capability allows our prototype to accommodate ‘wicked’ problems, which are inherent in design, and to not constrain the agents purely on numerical computations (Figure 5).8,23
Federated organisation of a DAO including experts and non-experts. Non-expert stakeholders are still able to participate in the decisions 20 (figure drawn by D Lombardi, 2019, adapted by T Dounas, 2020).
The DAO-stakeholder who sets the design problem has a few options at hand, structured within a series of contracts on the ETH Blockchain, to frame the way in which the design task can get solved. 20 The crucial decision is whether the process will run in a competitive or collaborative mode or a hybrid mode. Since storing large amounts of data on the ETH Blockchain is computationally expensive, it appeared necessary to rely on another immutable, decentralised manner in which we distribute files between participants. The Interplanetary File System, IPFS, a decentralised filesystem that distributes storage amongst participants, provides the necessary storage space to allocate the files for running the competition among the agents. Using IPFS avoids the use of proprietary ‘cloud’ storage or centralised servers that would compromise the entire decentralisation-approach. When the DAO sets the problem via the smart contract, it also uploads a model file on the IPFS, which associates a cryptographic hash with the problem on the smart contract, uniquely identifying the design task to be solved. Similarly, the agents that attempt to solve the design problem, use IPFS as a distributed file system, where they upload solutions once they meet certain criteria. Each value retrieved at the end of each loop is sent to the Ethereum blockchain and stored as a solution provided by a potential designer participating to the project either in ‘collaborative’ or ‘competitive’ mode (Figure 6).
Design problem stakeholder data flow on the Ethereum Blockchain, in both competitive and collaborative mode (figure drawn by T Dounas, 2020).
The structural design optimisation problem that the agents are trying to execute is a process based on the Finite Element Analysis (FEA) of a simple structure adopting the plugin ‘Karamba3D’ 30 as FEA within the Grasshopper environment. The algorithm starts by creating an orthogonal grid that equally divides a surface by a variable number of steps. Lines are then transformed into beams while the nodes of the grid become the points where supports are positioned. For the purpose of this research we simulate the presence of a high number of designers involved in finding the optimal position of the supports by introducing Galapagos, genetic solver of Grasshopper, to automatically create a number of different solutions. A random component is applied to randomise the position of the supports and connected to the solver to generate and analyse multiple options. The algorithm then follows the standard path to run an FEA by adding a simple gravity load. Default cross-sections and material were used. The fitness value used for the optimisation is inversely proportional to the displacement in the structure obtained at the end of the analysis.
We use a number of smart contracts on the ETH Blockchain, each with a particular purpose. ‘BIMmanager’ connects the BIM software to the Ethereum Blockchain. ‘IPFSHasHolder’ handles storage of the related hashes on IPFS, while three more contracts hold values that represent the design problem itself: ‘Problem’ represents the BIM design problem we attempt to solve on the ETH Blockchain, ‘Solution’ represents the BIM design solution an agent will submit, and ‘Solutionise’ closes the loop and executes the award of incentives to agents. On the side of the BIM platform a native plugin takes care of communicating between BIM and the Ethereum Blockchain, while a web interface allows the DAO to control the information flow (Figure 7).
Smart contract structure and data/ETH payment data flow of the prototype for one agent (diagram drawn by T Dounas, 2020).
The ‘BIMmanager’ contract parameter structure is simple: it includes an address in the Blockchain, for example ‘0xEBE7e47e89129382D0837F067Ed51D318c891307’ that holds the smart contract and the funds. It also includes the following parameters:
The id of the problem;
The cryptographic hash of the ‘problem’ file on IPFS;
The desirable inputs/outputs;
The minimal required performance;
The reward amount and an expiry date, after which the smart contract stops receiving input for resolution.
On the agent side, three values need to be provided: the user ETH address, a username id and a payout ETH address, as one might want to divert monetary rewards in addresses other than the one that identifies the user. When the agent solves the design optimisation problem, or has information that their solution is better than the current state, it first uploads their file to IPFS and receives a hash. The agent activates a transaction with the blockchain where a plugin on the agent’s BIM platform submits to the ‘BIMmanager’ the following data parameters: the user address, the problem id, a timestamp that establishes time of submission, and the cryptographic hash that corresponds to the file the agent wants to submit as a solution.
The smart contracts compare the value of the node with the current optimised value and a predetermined threshold, and if the result is better than both, it automatically executes a function on the smart contract: the contract requests from the agent which has found the higher value to send over their file from IPFS. The winning file definition is given a hash and is synchronised over to the collaborating agents which adopt it as the current best-performing script. With this process, the solution of one agent is communicated to all others, and through this mechanism design consensus is reached. The cycle can potentially continue indefinitely with the smart contract on the Blockchain synchronising all the agents to the best performing script of all agents (Figure 7).
Smart contract architecture
The main function of the BIM manager smart contract is to connect the Grasshopper script with the Ethereum Blockchain, that is this is the smart contract that receives the input from the ‘Blockchain’ gh plugin. The BIMmanager contract itemises the number of design problems and the number of solutions, and holds a register of their identities. It further maps and sets the number of the problem owners DAO and checks and regulates the ID of agents who have registered as problem solvers or problem owners. The contract then deploys a new instance of the design problem to be solved publicly on the Blockchain, and associates that ID with the ID of the DAO problem manager/owner.
The ‘IPFSHashHolde’, contract processes and stores all of the IPFS hashes that are mapped against the design optimisation solutions which are uploaded on IPFS, while the ‘ProblemContract’ loops through an algorithm that checks the process state, then deploys an instance of the ‘problem’ contract, which stores the problem ID for this contract, and initialises the ID on the blockchain. It finally describes five states of the design problem, as Initialised, Opened, Solved, Completed, Cancelled. The ‘SolutionContract’ is connected in turn both with the ‘IPFSHashHolder’ contract and with the ‘ProblemContract’. The ‘SolutionContract’, depending on the data it receives from BIM validates the state of the solution and communicates with the problem contract. If the solution is accepted as optimised, then it returns an affirmative value. Then this value is communicated to the next contract ‘Solutionise’, where payment is to be sent to the ETH address that has provided the best optimised solution.
‘Solutionise’ executes the incentive payment to the distributed agents who collaborate work to find the optimised value. It is important to note that when the node sends the optimisation value to the Blockchain, if the value is lower than the current optimum, then the Blockchain records the attempt thus creating an immutable log of all design activity. At set moments in time, all agents synchronise with IPFS and their solutions are hashed, that is encoded using an SHA256 algorithm, so that even the failed solutions can be recorded. The smart contract terminates the problem when time and/or gas runs out, or when an agent finds the best solution possible. Within this construct, the DAO, as mentioned earlier, has the potential of setting the process in either a collaborative or competitive mode (Figures 8, 9, 10, 11 and 12).
Design consensus where only the agents that find optimised value get compensated 29 (drawn by D Lombardi, adapted by T Dounas, 2020).
Design consensus where compensation is shared between participants 29 (drawn by D Lombardi, adapted by T Dounas, 2020).
Web API showcasing the interface to all contracts (screenshot of the web interface, Ethereum blockchain and a failed transaction on setting a problem, set up and captured by T Dounas, 2019).
Grasshopper connecting with the Blockchain using the ‘Blockchai’, Prototype Plugin and the web interface (screenshot captured by D Lombardi, 2019).
Optimised value submitted unto smart contracts, stakeholder is about to pay the agent with the best solution (screenshot captured by D Lombardi, 2019).
Conclusion
We have developed a framework of decentralised architectural design using BIM agents connected over the Ethereum blockchain. Within this framework we have developed a software prototype written for Rhinoceros/Grasshopper and a suite of Ethereum smart contracts governing the project. Our platform can scale to thousands of participants, that can resolve ‘design’ problems in both collaborative and competitive modes, with appropriate incentives distributed to each participant. Our prototype diverges from established trust paradigms in the sense that a design solution can be developed through a decentralised process, without the problem owner – an entity which operates itself on the blockchain – having to establish trust with the participating agents. Instead, trust is built via the radical transparency of the blockchain and secured via incentives and cryptographic records. In parallel, our prototype allows no distinction between artificial intelligence/machine learning agents and humans. This lends credibility to results that are produced by machine learning as a blockchain platform for design can be used to record their results in an immutable, resilient manner, removing their ‘black box’ nature. Due to its potential for scale and regulating transparency, resiliency of results, our BIM-Blockchain Framework is able to record all design attempts, including ones that have ‘failed’, and all positive steps towards design optimisation. It shows in an immutable manner each agent’s contribution, as Blockchains act as permanent records of the design process.
Even though other researchers 5 have identified BIM and Blockchain as a low maturity field in the built environment, our project evidences that the potential to build such tools is valid within the context of the fourth industrial revolution. 27 We have created a stigmergic coordination of agents providing both a radical transparency of how agents are operating and a decentralised structure of operations that is an excellent fit for the fragmented nature of the AEC industry. The framework we have built, encapsulating the software prototypes, advances the field against the low maturity in BIM-to-blockchain integration. Our processes show how the ETH Blockchain and the associated smart contracts can be a valuable, workable infrastructure for BIM operations, where trust, immutability and legibility of design responsibilities, and much more importantly value creation, are key for the successful adoption of the technology by architectural designers. Through this stigmergic coordination,31,32 the Blockchain becomes both the infrastructure but also the neural system for the architectural design process providing a robust system for governing the design, construction and operation of buildings. 33 It further allows the development and implementation of new business models for architectural and computational designers.
One key development that will enable full integration with the Blockchain ecosystem is the creation of full-fledged ‘blockchain wallet’ software inside computational tools that designers use such as Revit/dynamo and Rhinoceros/Grasshopper. 34 We believe that such ‘blockchain light clients’ in combination with the decentralised common document environment that IPFS promises, allows for the creation of a decentralised BIM, at level 4 in our framework. Within this effort, the wicked nature of the design problems is also a feature that the Blockchain might help alleviate, as all design actions and governance can be transparently recorded.
Footnotes
Acknowledgements
The authors would like to thank Avalone Consultants for implementing the code that showcases the smart contracts and the ‘Blockchai’, Grasshopper plugin.
Declaration of conflicting interests
The author(s) declared no potential conflicts of interest with respect to the research, authorship and/or publication of this article.
Funding
The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: The project has been funded by the Robbert Gordon University Pump Priming Fund 2018.
