EBDF: The enterprise blockchain design framework and its application to an e-Procurement ecosystem

Blockchain technologies have seen a steady growth in interest from industries as the technology is gaining maturity. It is offering a novel way to establish trust amongst multiple stakeholders without relying or trusting centralised authorities. While its use as a decentralised store of value has been validated through the emergence of cryptocurrencies, its use case in industrial applications with multiple stakeholder ecosystems such as industrial supply chain management, is still at an early stage of design and experimentation where private blockchains are used as opposed to public blockchains. Many enterprise blockchain projects failed to gain traction after initial launches, due to inefficient design, lack of incentives to all stakeholders or simply because the use of blockchain was not really necessary in the first place. There has been a need for a framework that allows blockchain designers and researchers to evaluate scenarios when a blockchain solution is useful and design the key configurations for an enterprise blockchain solution. Literature on blockchain architectures are sparse and only applicable to specific use cases or functionalities. This paper proposes a comprehensive Enterprise Blockchain Design Framework (EBDF), that not only identifies the relevant use cases when a blockchain must be utilised, but also details all the characteristics and configurations for designing an enterprise blockchain ecosystem, applicable to multiple industries. To validate the EBDF, we apply the same to the Vortal e-Procurement ecosystem allowing for multiple platforms to interoperate with greater transparency and accountability over the proposed blockchain framework. In this use case, many vendors bid for procurement procedures, often for publicly managed funds where it is extremely vital that full transparency and accountability is ensured in the entire process. Ensuring that certain digital certification functions, such as timestamps are independent from e-Pro-curement platform owners has been a challenge. Blockchain technology has emerged as a promising solution for not only ensuring transparency and immutability of records, but also providing for interoperability across different platforms by acting as a trusted third-party. The applied framework is used to design a Hyperledger based blockchain solution with some of the key architectural elements that could fulfil these needs while presenting the advantages of such a solution.


Introduction
Industrial clusters involve several entities that collaborate and interoperate with each other and often need to share transaction records, sensitive data and record micro transactions amongst each other (A. Grilo et al., 2007). Such business scenarios are common across multiple industries such as automotive sectors, supply chains and other business ecosystems. One of the critical challenges in establishing such collaborations is to have a high degree of trust that the sensitive transaction records, audits, and accounting across multiple parties is handled in a manner that can be trusted by all participating entities. Establishing this trust is often a technical as well as business challenge.
Conventionally, there are three forms of trust that have existed in business relationships (Werbach, 2018). The first one is peer-to-peer trust where parties trust each other based on existing relationships, like the trust in a long-time associate or business partner. The second form of trust is trusting the parties based on rules and the legal support which usually is slow, inefficient, and often expensive since conflicts need to be taken to a judicial body to be resolved. The third form of trust is where parties trust a central actor which could be a bank, an exchange, a cloud based data service provider, a digital platform (e.g., Amazon), or any other trusted third party (Zutshi & Grilo, 2019). While trust in third parties have been the basis of globalisation and scalability of various business such as through platforms like Alibaba, trusting a single intermediary can be a single point of failure. The flow of users' information, identity, reputation, or money are controlled by a single third party, which requires complex audit arrangements and multiple legal agreements across partners in the case of a data breach.
Blockchain has emerged as a fourth form of trust, where all data and critical records are stored in a decentralised way across multiple nodes. The parties can trust the history of transactions recorded cryptographically in the Distributed Ledger Technology (DLT) through a variety of different technical mechanisms known as consensus -an agreement among the network peers (Chang et al., 2021). So, eventually, each machine has an exact copy of the blockchain throughout the network (Bamakan et al., 2020). This technology solves the issue of data authenticity and transparency . Additionally, it can provide smart contract programmability, such that rules for transactions, settlements and accounts that can be automated and programmed to be executed based on predefined rules. Such solutions can support payment systems to transact value between the actors as well as identity system to identify the actors. Moreover, it can create reputation systems to form a free peer to peer exchange instead of having a monopolistic provider monitoring the interactions.
Many enterprise ecosystems failed to gain traction after initial announcements because their current systems did not have a real problem of trust deficit and hence the real motivation to build a blockchain solution was really not there. In addition, enterprise blockchain ecosystems are being designed around technologies which are still not mature and continue to evolve and compete. The design of such a system requires a selection of multiple parameters that define its architecture, such as business logics, consensus mechanism, smart contract structures, token models, etc. There is a lack of an established framework that enables blockchain designers to systematically identify the key parameters for designing an enterprise blockchain.

Key contributions of this Paper:
This paper analysis the key issues involved in the design of an Enterprise Blockchain Ecosystem, and presents an Enterprise Blockchain Design framework (EBDF) that is platform and technology agnostic. While different competing technologies such as Corda, Hyperledger, Cardano, etc. are still under different stages of evolution and it is still not clear which technologies will finally succeed. We envisage that such a framework will always be helpful for identifying the correct use case of blockchain technology and characterising the various architectural components that will help design the ideal blockchain for the required scenario.
The framework is then used to design a blockchain ecosystem for a consortium of e-Procurement platform providers in Europe led by the company Vortal. The proposed blockchain ecosystem is at a design stage, and would complement the existing platform participants, by providing interoperability across buyers and sellers in different platforms. This application of the proposed framework provides a guidance to how the framework can be applied to other enterprise blockchain based applications.
There are two key contributions in this paper: theoretical and practical. From a theoretical standpoint, it provides a comprehensive review of all the factors to consider while building and deploying a new blockchain application. It describes a framework that comprises of two complementing perspectives: business and engineering, and it includes the essential aspects and dimensions for developing a new blockchain ecosystem. It could be a handy resource for anyone who needs a quick overview of all the puzzle components for a new enterprise blockchain design.
From the practical point of view, it describes what seems to be plan for transition of the Vortal platform to use the blockchain technology to become interoperable with other platform providers in Europe. The paper describes the case application layer by layer, previously described in the theoretical framework. The description within each blockchain layer follow closely the platform chosen solution and describes the configuration options to meet the Vortal market requirements.

Structure of the Paper:
In section 2, we present a methodology to identify when blockchain is a relevant and optimal solution instead of a centralised database and which type of blockchain is the most appropriate for a given scenario. Making the correct selection is a crucial factor in the application of any blockchain project. In section 3 we present the existing literature on blockchain design frameworks and solutions which have been used for the development of the proposed framework in this article. In section 4 we present the Enterprise Blockchain Design Framework (EBDF) that identifies all the major parameters necessary to develop a blockchain architecture for any specific enterprise scenario. This framework is one of the key contributions of the paper. In section 4 we present an application scenario for the proposed framework to demonstrate its applicability. This scenario involves developing a blockchain ecosystem for multiple cross border e-Procurement platforms to collaborate and interoperate. We elaborate on how EBDF was applied and covers the design of all blockchain parameters starting from the business logics, stakeholder identification, use case definitions, blockchain identification, token mechanisms, and consensus mechanisms. Section 5 presents a conclusion, limitations and managerial implications of this paper.

Methodology to identify applicability of blockchain to a use case
The blockchain technology has first been successfully applied to the domain of cryptocurrencies such as Bitcoin, and subsequently to smart contract platforms like Ethereum which allow for public ownership of assets and smart contract applications. These public blockchains are designed to be fully decentralised (Christidis et al., 2021).
Enterprise blockchains were conceptualised subsequently to borrow some of the characteristics of decentralisation from public blockchains but still have significantly different requirements. Many research work explored the features of blockchain technology that can solve some major enterprise problems (Casino et al., 2019;Luo et al., 2019;Adeyemi et al., 2020) The enterprise blockchains are built by agreement between collaborating entities already engaged in a business collaboration. Hence the level of decentralisation necessary for enterprise blockchains is much limited. Enterprise blockchains can be utilised for a wide variety of use cases in addition to settlement of value or tokens, such as validation of events, management of assets, contracts, identities, and other specific information. However, overcentralisation of enterprise blockchain defeats the purpose of having a blockchain since that means that a few trusted entities already exist within the ecosystem on which all the industrial partners rely on. Thus, a centralised database would be a far simpler and easier system which could be managed by the same trusted entities. This section identifies the set of conditions where a blockchain is considered relevant and useful for a business ecosystem.
Blockchain technology has the potential to change various sectors by offering decentralised transparent solution. While replacing conventional approaches with blockchain can be expensive and it might not be necessarily the best approach. This means each industry should evaluate and choose between a conventional centralised/ decentralised solution or a blockchain based solution. We have studied multiple industrial scenarios and scientific literatures as a base to create a systematic way to decide if blockchain is an applicable solution or not. Amongst the literature, (Liu et al., 2021) proposed and applied a methodology to evaluate the applicability of blockchain in collaborative product customization. (Latifi et al., 2019) explored the application of blockchain technologies and smart contracts in real estate market and presented a method to select between permissioned or permissionless blockchains. (Bhushan, Khamparia, et al., 2020) while presenting the blockchain technology as a solution for security challenges in smart cities, it presented a diagram to decide if blockchain can be employed or not. (Hebert & Di Cerbo, 2019) proposed a methodology that can be used by software developers to assess the security of a software architecture and risk evaluation of applying blockchain technologies. (Fan et al., 2020) presented a systematic study including existing blockchain performance evaluation procedures covering empirical and analytical evaluation approaches.
As shown in Fig. 1, we propose a decision flowchart that can help industries to select a right approach for transforming their industry or solving an existing problem: -The first step is if multiple stakeholders are involved in writing their input in a shared ledger. Traditional database can be more efficient if there is only one party involved. -If there are several parties involved in writing down in a shared database, but there is full trust between them, and there is no place for malicious activities, then blockchain is not a more useful approach.
-If traditionally a trusted third party is required while immutability is essential and there is a uniform set of rules for similar cases, then blockchain can be a beneficial approach. -For the case of permissioned blockchain network, the miners/ validators in the network are known and trusted nodes. Otherwise, the network will be a permissionless blockchain where any node can set up as a validator based on the required conditions. -If transactions of public users are allowed in the network, the network should be a public blockchain, otherwise it should be a private blockchain.
Using our proposed methodology not only identifies applicability of blockchain in a specific scenario, but also indicate the suitable type of blockchain network. In the rest of this section we describe these types with more detail.

Types of blockchain platforms
In a blockchain network, there are distributed nodes that run the consensus mechanism and validate next transactions. Based on which nodes can have the right of validating the next transactions, there are two types of blockchain network, permissionless blockchain and permissioned blockchain (Putz et al., 2019;Ding et al., 2020). Also there are two types of governance models for blockchain networks: public Fig. 1. Applicability of blockchain decision diagram: when to use the blockchain? network or private (consortiums) networks (Bhushan, Sinha, et al., 2020). Fig. 2 depicts these four types of blockchain networks, their characteristics, use cases, and current platforms.
In a Public-Permissionless blockchain like Bitcoin or Ethereum, anyone can access to the ledger or issue a transaction, publish a smart contract or run a node. In this type of network, there is full transparency and a relatively high level of anonymity. However, currently the performance is slow, and scaling is a massive challenge in this type of blockchain. In these networks, there are monetary incentives for those running nodes. In Bitcoin or Ethereum network, there is proof of work consensus algorithm which consumes an immense amount of energy. International fundraising, digital certificate, or digital identity can be few applications of this networks. In a Public-Permissioned blockchain, only those nodes that meet specified predefined criteria can download the consensus protocol and validate the next transactions. Corda and EoS are examples of these types of blockchain platforms. These blockchains are better scalable and having lower energy consumption. Network of energy producers can be one of the applications of this type where the network is open for public, however only those nodes that fulfil certain specifications can run the consensus protocol. In a Private-Permissionless blockchain, anyone can operate a node and join the network where other nodes will acknowledge its presence without sharing any data at first. Each node can decide with whom to share their private information. Each instantiation of a smart contract on these networks specifies who is allowed to read the contract and all related data which means each smart contract has its own ad-hoc chain. Holochain, LTO Network, and Monet are examples of privatepermissioned blockchain platforms. A Private-Permissioned blockchain is a closed ecosystem where all participants are well defined through membership identity services like Hyperledger Fabric and Quorum. Only pre-approved entities can run consensus mechanism. The degrees of decentralization and transparency are dependent on the configuration set by the consortium members. Validation of the transactions does not require mining. Moreover, in validation of a transaction does not require a crypto economic incentive or tokens for the running nodes. Consensus mechanisms are computationally inexpensive allowing permission blockchains to perform and scale much better than permissionless.
Since enterprise network usually requires a high scalability and efficiency as well as the possibility for membership management, permissioned blockchain is the more appropriate network for it. Currently, there exists various blockchain platforms.

Existing literature on blockchain designs
During our Research, we first investigated and analysed the state of the art for available blockchain frameworks for helping design industrial blockchain ecosystems. Most academic literature and industrial applications focus on specific use cases, without developing a broad framework that can be applied across industry, and the frameworks presented provided a conceptual overview rather than a detailed architectural blueprint. We also found that most papers did not detail the blockchain architecture or why certain design choices were made, as opposed to others. We found that most of the published papers (Table 1) provided some insights to some of the aspects of the jigsaw puzzle about considerations for efficient blockchain design, we have combined all of the published knowledge into developing the framework detailed in this paper.
While the above-mentioned articles provide useful insights to blockchain design, they only address the technical challenge for specific scenarios. Many industrial applications require a comprehensive framework that will help identify when blockchain technologies need to be applied and make systematic design considerations to select an optimal configuration of the various blockchain design elements. This need has been the major motivator behind this paper. Based on the analysis of multiple industrial use cases and academic literature, we propose the Enterprise Blockchain Design Framework (EBDF), based on a systematic methodology to help design the various architectural components of an industrial blockchain ecosystem. The Framework is technology neutral, which means it can be applied to various use cases with different blockchain systems. This was a fundamental consideration, since blockchain systems are evolving rapidly and there are many different competing blockchains, and it is yet to be seen which ones assume market dominance.

The enterprise blockchain design framework (EBDF)
Various industries from finance to healthcare or logistic operators are facing issues like Interoperability, security, immutability, privacy, or trust. There are already some centralised solutions for these problems which have their own limitations. Blockchain technology has the potential to unlock various problems for industries and global economies. However, the lack of blockchain technological frameworks makes it very challenging for industrial adoption. In this section, we will discuss our proposed blockchain based reference architecture (shown in Fig. 3) and will discuss multiple layers of it.

Proposed enterprise blockchain design framework
As shown in Fig. 3, EBDF contains Business Layer, Customer Layer, Physical Asset Layer, Interoperation Layer, and Blockchain Layers. Rest of this section will elaborate the functionality and role of each layer.

Business layer
Blockchain based distributed shared ledger and smart contract in enterprises are employed to bring better interoperability, trust, or security between multiple parties. Business layer is one of the most crucial steps to create the blockchain based solution with the propose of identifying business perspective and core functionality of the system. The business layer can utilise and analyse the input from the customer layer and work with the application layer. As a result, this layer can assist all layers in the blockchain network by producing and offering valuable information and services.
The enterprise requires to follow some procedure before developing the solution. The first step is identifying all stakeholders involved in the system and specifying their role. For example, the customers, the legal or governmental body, various providers, designers and so on. Second step is identifying industrial initiatives amongst parties in the form of requirements and guidelines for social, technological, and economical functions which can help to understand the challenges in the enterprise to improve using blockchain technology. There are numerous financial and non-financial use cases for blockchain technology which can play a vital role for industries (Zutshi et al., 2021;Wüst & Gervais, 2017;Aste et al., 2017). Identifying the business challenges and possible blockchain use cases is next important step to have a holistic view for creating a blockchain solution. As discussed earlier, developing a blockchain solution might be expensive and not the best approach. Hence, next step is evaluating the applicability of use case using proposed method in Fig. 1 for each identified application of blockchain.
Another important step is selecting appropriate blockchain technologies. Using the flowchart as suggested in step 4, industry can identify which type of blockchain network is suitable (public-permissionless, public-permissioned, private-permissionless, or privatepermissioned network). Additionally, the team developer team should discuss various available platforms and select the acceptable consensus mechanism and possible programming languages for smart contract. The team needs to compare all possible approaches and select the most suitable ones based on the policy of company and stakeholders involved. Strategic planning is another important step that should be discussed to plan an efficient and logical creation of strategic roadmaps. One more important procedure is cooperation agreements and Legal alignment in order to identify the level of contributions and cooperation of each stakeholder. The parties need to be clear about roadmap and their role in the development stages to avoid complications and increase Digital Assets and Physical Assets (Liu et al., 2021) Blockchain based collaborative customization framework to manage a decentralized consensus on product requirement, quality, and price which automates transactions through smart contracts, and provide more traceability.
Applicability of blockchain (Kharitonov, 2017) Proposed a framework canvas for deploying blockchain technology solution more appropriate in small scale projects.
Strategic study on adoption of the blockchain (Mohanta et al., 2019) A comprehensive study on challenges of implementing of blockchain technology and discussed a blockchain solution with seven layers architecture to support intelligent service.
Blockchain conceptual overview (F. Chen et al., 2020) Presents how to deploy blockchain technology in four different IoT systems and discussed primary issues of deploying blockchain in such environment.
IoT use case (Casino et al., 2020) Blockchain based architecture for food supply chains traceability.
Supply Chain use case (Hofman, 2019) Data sharing reference model for supply and logistics based on blockchain technology. (Esmat et al., 2021) Challenges presented a new decentralized P2P energy trading platform including market and blockchain layers.
Blockchain potentials for energy sector (Adeyemi et al., 2020) Blockchain automation, security, and actual time adjustment using smart contract in Energy Sector (J. Zhang et al., 2020) Challenges of personal credit reporting market in China and designed a blockchain based solution for personal credit information sharing.
Auditing of Transactions (Yu et al., 2019) A blockchain based big data auditing model for smart city environments in order to enhance reliability and stability of system (W.  Challenges in compliance enforcement for intercompany transactions amongst various jurisdictions. (Bhushan, Khamparia, et al., 2020) Solve the security issues of smart city applications such as financial system, healthcare, transportation, smart grid, and education.
Blockchain use cases for smart cities (Kumar et al., 2020) Designing a smart healthcare system using blockchain aiming more interoperability.
Healthcare applications (Cai, 2020) Intellectual property right for digital music.
Digital art application T. Nodehi et al. performance. Next is network effects as one of the significant drivers for the adoption of any new technology and can help in growth. The challenge for multi-stakeholder systems like blockchain network is to create direct or indirect value to the various sides to join the platform. The industry should explore and deploy the possible network effect of solution throughout the development process. Finally, all previous steps should be evaluated and discussed between team before starting development phase to make sure the solution will create value for the customers and enterprise. Other economic, social, and technological impact of solution should be evaluated throughout the various phases of development.

Customer layer
Each scenario can involve different customer such as logistics companies in supply chain network, digital platforms, product/ service Consumers, financing institutions, manufactures, or artists in a digital art marketplace, etc. It is important to identify various customers and their requirements and specifications before designing the blockchain solution. Customer layer collects customer data and provides to business layer and application layers.

Physical asset layer
The physical assets or products are any tangible or intangible item contributing to the performance or the functionality of each enterprise. It may include orders, costumers, processes, workforce (such as drivers, warehouse operators, etc.), logistics, material (such as goods placed in containers), and machines (such as trucks, forklifts, automobiles), etc. The digital asset layer oof blockchain layers is connected and synchronized with the physical asset layer through digital twinning (Nielsen et al., 2020). A digital twin is a digital or virtual representative of a physical asset (Nielsen et al., 2020).

Interoperation layer
Interoperation Layer provides external data, real time information, operational support, or interoperability with external system to the blockchain network. It can be technological support through big data, IoT devices (Pincheira et al., 2021), cognitive computing, artificial intelligence, and machine learning (Solanki & Solanki, 2020), etc. Identity providers can plug to the blockchain and provide their data and services. Cloud providers can collaborate with the blockchain network through cloud software service, distributed storage, data analysis, or control, etc.

Blockchain layers
In EBDF, Blockchain Layers consist of Application Layer, Digital Asset Layer, Token Layer, Contract Layer, Consensus Layer, Data Layer, Network Layer, and Infrastructure Layer.

Application layer.
Application layer is the top layer of blockchain architecture which exchanges data and information with Customer layer and Business layer and provides services to the ecosystem. This layer can incorporate any of following components: - can support users to exploit cloud based solutions to create, host, or operate their blockchain applications on the blockchain while the cloud based service provider caters a reliable and functional infrastructure.
-Layer: Application layer can consist User Interface (UI), scripts for execution of operations, and Application Programming Interfaces (APIs) used by the customers to communicate with the blockchain network. Based on the technology of chosen blockchain platform, an application can use a language specific Software Development Kit (SDK) or a Command-line interface (CLI) tool to share or exchange data with the blockchain network.

Digital asset layer.
One important aspect of migrating the economic systems to a blockchain network is mapping between real world assets identified in the Physical Asset Layer and digital assets in the blockchain. The Digital Asset Layer represents and manages blockchain cyber-physical system where blockchain records and tokens are securely and accurately connected to the underlying asset through automated technology. The functionality of this layer are adopted from proposed solution in (Rachana Harish et al., 2020). The digital asset (DA) service layer performs definition, connection, configuration, and execution of various interactions in the physical space. First, it maps and defines the digital assets based on underlaying tangible or intangible item contributing to the performance or the functionality of each ecosystem. Next, it configures digital asset by creating the sets of appropriate fields and variables. Then, it connects the physical assets to corresponding digital asset automatically and accurately. At last, it executes the interactions between physical and digital space.

Token layer.
Token Layer is an important core layer of blockchain framework that shows how the token connects to the underlying business model and defines these metrics (Benítez-Martínez et al., 2021). After Ethereum blockchain network was launched, it empowered developers from all over the world to develop blockchain based projects and issue their tokens. Since then, many other blockchain platforms such as tron, eos, waves, tezos, polkadot, and corda and various token model have been emerging. Tokens often have unique use cases that are specific to the projects that made them such as money (Choi & Ouyang, 2021), an incentivizing mechanism (Laskowski et al., 2019; Narayan & Tidström, 2020), a vote (Y. Chen, 2018), or an identity in an ecosystem. Tokenomics is short form of token and economics which include series of metrics relating to coin or token such as supply, allocation, distribution, and utility Aistov et al., 2020). In Fig. 4, we created a Blockchain based Token classification based on literature reviews (Y. C. Lo & Medda, 2020;Shen & Pena-Mora, 2018;Latifi et al., 2019;X. Li et al., 2019;Pang, 2020;Lee, 2019;Drasch et al., 2020), specifically paper (Oliveira et al., 2018) with four main high level metrics: Second is specifying the governance model of tokens. It is essential to identify that a token is representation of a digital asset, or physical asset, or a Legal right (Esmaeilian et al., 2020). Moreover, the supply model and incentive model should be discussed and defined in advance.
Third metric is identifying the characteristics of tokens which can include specifying the type of transactions, ownership, burnability, expirability, and fungibility in advance. For example ERC20 is a standard on Ethereum platform that allows creating fungible tokens. It defines 6 mandatory functions such as total supply and 3 optional ones such as decimal that should be implemented in the smart contract. Non-Fungible Tokens (NFTs) are special cryptographic tokens representing unique items or digital collectibles. One of the most famous examples of NFTs is a cryptokitty. These digital cats looked different, had different colour and rarity. There are two major types of NFTs (on Ethereum platform: First is ERC721 tokens which are non-fungible and the tokens are simply not the same. Next is ERC1155 tokens which combines the benefits of fungible and non-fungible tokens together. For example, in the online game of World of Warcraft, there is a fungible in-game currency called gold and there are special in-game items like super rare magic swords. The last metric is specifying technical dimension which includes  identifying the layer and the chain that token will exist. Any independent blockchain network can have its own native token (e.g. Bitcoin or Ethereum). A non-native token can be created on top of a blockchain defined in a smart contract which is also responsible for managing transactions of the token and keeping track of balance. Developers have to send some native token to the smart contract to get non-native tokens. The third type of token can be defined inside a dApp as code. Bitcoin and Ethereum are example of new chain which have their own code. A coin like Doge copied and modified the code of bitcoin and started a new chain which is called forked code. When there is a problem in current chain, the chain and code both can be copied which called forked chain. Finally, for the case of dApp, a chain issues on top of another network using some protocol (e.g. an ERC20 token defined on top of Ethereum network). Each token has a main utility and provides a specific service in the blockchain. (Oliveira et al., 2018) presented eight patterns for service types of tokens in various blockchain scenarios. Fig. 5, represents these eight token types and a short description for each of them.

Contract layer.
This layer aims at defining and integrating smart contract into the architecture. The purpose behind smart contracts is building digital contract controlled by code and enforced by blockchain technology instead of a trusted third-party (Zheng et al., 2020). Smart contract store and verify business logic of a dApp, control digital assets, and state the rights and roles of the participants. If a number of stakeholders meet all the conditions within a smart contract, the contract is cryptographically signed between them and disseminated to the entire blockchain network while the smart contracts execute automatically. Smart contracts are immutable and distributed on the blockchain. Hence, the output of contract is validated by miners or validators on the network. Ethereum was the first blockchain platform supporting building dApps through programming smart contracts with Solidity language. Smart contracts can be applied to many different applications from crowdfunding to IoT and financial sector. Banks could use them to issue loans or to offer automatic payments. Insurance companies could exploit them to process certain claims. Postal companies could use it for payment on delivery. (Hewa et al., 2021) investigated various applications that employed smart contracts and presented different possible benefits of smart contract for each application. (Luo et al., 2019) proposed a framework to automate payments in construction projects through smart contracts. (Ante, 2021) by deep study of 468 articles presented a summary and analysis of the current state of the art on blockchain smart contract and discussed the intellectual structures and emerging trends.

Consensus layer.
This Layer is an important layer of any blockchain based solution which identifies the consensus protocol and based on use case scenario should be discussed in advance. The consensus mechanism in the blockchain network is the key factor to establish a decentralized peer-to-peer system with no authoritative entity. There are various consensus protocols with the same goal to ensure the new records on the ledger are original and accurate (Cao et al., 2020). The difference is the way the consensus is reached (Ismail & Materwala, 2019). Table 2 shows few types of consensus mechanisms, an example of blockchain network, and short description for each of them.
Bitcoin and Ethereum (Buterin, 2015), the two famous and trustable blockchain networks, use Proof-of-Work (PoW) consensus mechanism. In PoW, data transactions are stored in blocks validated by nodes solving a complicated mathematical equation. A reward in the form of a cryptocurrency is issued to the first miner who cracks the problem (S. Zhang & Lee, 2019). This is usually done by powerful computers and is known as mining. However, PoW is wasting huge amount of resources and energy to solve the equation and also the difficulty of problem increases by time. Hence, in Proof-of-Stake (PoS) mechanism, the creator of a new block -validator -is randomly chosen based on how much stake they commit to the network (S. K. Lo et al., 2019). Therefore, the higher the stake placed, the higher the chance to be selected as a validator which give more power to a single node. Blockchain protocols like Cardano adopted the PoS consensus mechanism. Delegated Proof-of-Stake (DPoS) was developed as an advancement of the PoS algorithm by Daniel Larimer, founder of Steemit, EOS and BitShares in 2014 which is more democratic. In this consensus mechanism, people who stake the token can contribute to the "mintage" process. These individuals can get a chance to vote layer two nodes or "witnesses". The selected node can validate block and receive reward for adding blocks to the blockchain. PoET implemented a lottery system to increase the possibility of winning uniformly across network participants, providing every node the same chance of winning. In PoET, each node generates a random number in order to estimate its waiting time which each node must stay idle for that duration. The node with the shortest wait time wakes up first and verify the block, thus being allowed to add a new block to the blockchain.
In the enterprise, the companies need to have some control over that network. They require to know what members and nodes are on the network who has the authority to influence the change on the network. Various industries are often interested in having a pluggable consensus models in which the network can be configured based on appropriate consensus protocol. 5.2.5.6. Data layer. Data layer decides how data is transported and received on the blockchain network. In the blockchain network, a Distributed Ledger can be used for the recording, tracking, monitoring, and transacting of all forms of digital assets. The ledger consists of a string of blocks. Each block is a record of data that has been encrypted and given a unique identifier called the hash mining. Computers on the network validate transactions and add them to the block. After building and verifying a block, the miner/ validator nodes broadcast the completed block to other nodes. Since there is no centralized component to verify the transactions, the network relies on a distributed consensus protocol (Qin et al., 2021). Each block includes a hash value that is related to the hash of the previous block. Hence, if one block is altered then all the other blocks linked to it will be changed. Smart contracts provide the capacity to execute any piece of code on the blockchain. This makes blockchain qualified for the storage of a record with a value or trusted information. Each block contains a timestamp to show the time of creation of block. All the information on the ledger can be accessed using keys and cryptographic signatures. To build a blockchain solution, it is important to define the structure of distributed ledger in order to future process by network and smart contract.

Network layer.
Network layer is a peer-to-peer network which is a group of interconnected devices that exchange information (Guerrero et al., 2018). The responsibilities of this layer are verifying, dispatching, and storing network transactions without a central authority management. Each blockchain platform discussed in section 2.1 provides its own propagation mechanism, verification/ authentication algorithm and communication gateway. Before creating a blockchain solution, it is essential to consider all legal and physical conditions of involved parties for network layer. Such as identifying the conditions for organisations or individuals to set up a validator node. 5.2.5.8. Infrastructure layer. This layer specifies and configures underlaying infrastructure. Various application might require different sets of infrastructure. This layer can include Execution Layer, nodes, storage system, or IoT device nodes. Execution Layer should provide a virtual computing infrastructure for running applications on the blockchain which can be specific for each platform. This can include Virtual Machine, Compiler, Docker Container, Hypervisor, etc. A node in the blockchain network can generate a new transaction block, usually called validator or miner, or simply a node holding a copy of distributed ledger. Block generator nodes execute the smart contract and run the consensus algorithm to verify next transaction. If there is an additional storage system, it is also part of Infrastructure layer. If there are IoT devices in the network, they are considered part of Infrastructure layer. The IoT nodes are depend on various applications like smart city, energy sector, supply chain, and so on including camera, sensor, smart bulb, alarm, automobile, smart gateway.

Applying EBDF: The e-Procurement blockchain ecosystem use case
To apply the proposed blockchain design framework, EBDF, we worked very closely with the Vortal e-Procurement platform which is the initiator of a proposed blockchain based ecosystem that will connect multiple e-Procurement platforms allowing buyers and sellers in different countries using different e-Procurement platforms to conduct business transactions, and have a blockchain for tracking bids, awards and maintaining financial settlements across platforms. Vortal (https://vortal.biz) is the largest e-Procurement platform in Portugal and one of the major players in Europe and was a part of the Interplat EU Project for inter-platform Interoperability . With more than 20 years of experience, Vortal has been a market leader especially in the transparency-sensitive public contracting sector, providing an open platform for several European and Latin-American public agencies. They have been a major driver for the European Single Procurement Document (ESPD) and other initiatives to bring across interoperability across EU-based organizations, so that entities across different EU countries can bid for public and private tenders in any EU country. Owing to their need for bringing transparency, interoperability, and accountability in the sector, they are keen to adopt blockchain technologies to provide improved solutions for their clients.

Business scenario
Online procurement has been established as one of the most important aspect of e-business operational excellence for companies (Mehrbod et al., 2015). E-Procurement platforms have made the bidding process easier, quicker, and more cost efficient by streamlining the procurement process. Most large companies and public entities use these commercial e-Procurement platforms to manage their procurement procedures since these platforms are designed to fulfil bidding requirements of the procuring organizations (Baldus & Hatton, 2020). This translates to more business opportunities for suppliers, vendors and the organizations that are requesting these bids (Bag et al., 2020). Due to the fact that e-Procurement platforms manage the interests of multiple stakeholders, and critical data that could determine the fairness of many of the bidding procedures, it is vital that the platforms not only maintain transparency but are seen to be completely impartial too (Aguiar Costa & Grilo, 2015). That is why procurement digital platforms are governed by many regulations, and interface with independent third-party agencies for issuing digital certifications and timestamps for recording and validation of the bids. Also, many of the procurement digital platforms are exploring cross platform interoperability where sellers on one platform are able to bid for procurement procedures in another platform. This fulfils a key objective of cross border trade within the European Union and was the basis of some of the EU Projects like Interplat. Such cross border cross platform interactions require an even greater level of trust and transparency (Antonio Grilo et al., 2017;Nodehi et al., 2015;Jardim-Goncalves et al., 2013).

Advantages that the blockchain ecosystem will bring compared to current status
Currently e-Procurement platform providers cater to buyers and sellers in their home country. For vendors in one country to offer their bids to procurement calls from buyers in another country, they must register into a different platform provider in the Buyer's home country. The Blockchain based implementation would enable increased interoperability across multiple platform users without needing to set up accounts in different platforms. The specific benefits of Blockchain are:

• Increased Transparency
Since every bid is being tracked on a common blockchain, all platforms and participants can transparently track every bid made. If blockchain was not used, one or the other platform's data had to be trusted by other platforms that participate in the network, while a trustless system offered by blockchain provides increased transparency.

• Reduction of Compliance Costs
Since bids are not currently tracked in an independent platform, to make sure that there is no collusion between the platform and a platform participant in a bid, timestamps need to be purchased from third party auditors for every bid made, to ensure that the timings of the bids are recorded by an independent entity. These costs will completely be eliminated since the blockchain is itself a trusted third party whose data records are immutable.

• Easier Audit
In a blockchain based system, a verifiable copy of the ledger is stored across multiple nodes held by more than one entity (eg. Different procurement platform owners, larger clients, public bodies, independent certification agencies) thus ensuring easier and automated audit.

• Easier Transaction Settlement
Since a common Euro pegged token will be used across the blockchain ecosystem, the platform usage fees across different platforms can be instantly settled in realtime.

Applying EBDF to an e-Procurement ecosystem
The e-Procurement ecosystem business scenario discussed in previous section requires a transparent, high scalable and efficient solution while including the possibility for membership management. It is important to investigate if blockchain based solution is appropriate for e-Procurement ecosystem scenario discussed in previous section. To identify applicability of blockchain for e-Procurement business scenario, we applied the proposed methodology in section 2. During our discussion with the team, we considered the steps in the proposed flowchart in Fig. 1: -Multiple Stakeholders Involved in writing the ledger: Yes -Are the writers trusted? No -Traditionally the trusted intermediaries are required: Yes -Immutably is required: Yes -Governing rules for each case are uniform: Yes -Transaction rules change frequently: No -Are the validators trusted? Yes -Can the writers of ledger be public? No Hence, a blockchain can provide solution for our case study. As a result, it was analysed that a "Private/ Consortium Permissioned blockchain" approach is suitable blockchain network for e-Procurement ecosystem scenario.
In the rest of this section, the key architectural elements according to our proposed blockchain design framework, EBDF, will be explored for a blockchain based solution for e-Procurement ecosystem which includes Business Layer, Customer Layer, Physical Asset Layer, Interoperation Layer, and Blockchain Layer. Finally, the solution workflow will be discussed.

Business layer
In this section we followed the guideline provided in Business Layer of EBDF in previous section and during all steps of creating the solution, the focus of discussions was to plan an efficient and logical strategic roadmap.
To characterise the functions of a blockchain based architecture, it is important to identify the key processes within an e-Procurement platform. We had several internal discussions within different teams in Vortal e-Procurement company. Some of the principal functions are shown in Fig. 6. The buyers create the tender procedure and send invitation to sellers to bid for the tender. Subsequently the sellers prepare proposals and receive receipts for their bids. Following this, the buyers compare the bids and evaluate the proposals. Following the award, the contracts are signed by both the parties. Calls for tenders, requests for proposals and blind auctions are prevalent and essential procedures (Zutshi, Mota, et al., 2018).
The objective of the proposed blockchain ecosystem is to connect different e-Procurement platforms across different countries so that these functions could be performed by buyers and suppliers in two different platforms. This adds additional requirements of trust and transparency since not only the buyers and sellers need to trust each other but trust needs to be created between different platform providers.
In the e-Procurement process, the requests for quotations or sealed bid auctions are often used to collect competing proposals from several bidders. However, e-Procurement platforms are still vulnerable to fraud and corruption (Dávid-Barrett & Fazekas, 2020). With blockchain technology, many of risks can be eliminated and the maximum transparency level of bidding processes can be achieved. The platform requires mechanisms to ensure there won't be information leak to any bidders allowing them to outbid competitors using this inside information (Mehrbod et al., 2017). Currently, third parties sell timestamps or trusted software solutions are utilized to secure the process. Third party timestamps are a guarantee of the bid that is recorded by the platform as well as the exact moment in which it took place. Blockchain technology is a new paradigm that can change the way of interaction with different stakeholders and institutions (Mirabelli & Solina, 2020) (Westerkamp et al., 2020). Blockchain enables trust to be achieved through cryptography and remove the dependence on participant integrity from one side and third-party organisations from another side (Cui et al., 2019). It can automate and govern transactions and bring transparency as well as privacy for various members (Mazzei et al., 2020). The "block" is the key element of a blockchain that can immutably store any value representative of any set of data including the time of creation of a message (Khan et al., 2020). Moreover, this technology can provide a solution to guarantee auditability and cost-effectiveness without the need for third parties.
According to the guideline of Business Layer, we identified the stakeholders and consumers involved in the e-Procurement ecosystem after numerous discussions with the team in Vortal company which includes e-Procurement platforms, Financing Institutions, Timestamp providers, Buyers, Suppliers, Contractors, and Consultants (shown in Fig. 7).
In Business Layer we also required to identify possible blockchain applications for our use case scenario. Based on our collaboration with the Vortal e-Procurement platform and analysing the business needs while proposing the blockchain solution, we identified nine features to be implemented in the Blockchain based e-Procurement ecosystem which are illustrated in Fig. 7.

E-Procurement features identified for the blockchain ecosystem
The first feature is Membership Management, and ID Management-Digital Signature. To avoid frauds and risks in e-Procurement processes, each stakeholder needs to have a certified identity in order to participate in each process. As an example, a fraudulent bidder could prepare multiple bids, all of them digitally signed and timestamped. Then, after the deadline and in collusion with auctioneer's database administrator, see competitors' proposals and set the bid that better fits his requirements. Hence, trusted digital signatures and a permissioned blockchain network can help achieving stakeholder authentication, documents integrity and non-repudiation of tender proposals.
Second feature is Audit Tracker. An audit reviews the procurement process to reduce fraud and offer suggestions for improvement. One of the possible application scenarios in our case study is using blockchain technology for automatically track events and internal audit record and communication of decisions to provide more security and traceability. The blockchain technology can provide solution related to audit tracker in various ways. Automatic and trustable creation of procedures and submission of bids can be one of the approaches. The blockchain technology can maintain a record of every event such as creation of new procedures by buyers or submissions of bids by sellers. Thus, an audit trail can be maintained on the distributed ledger and can be independently verified by different peers from various entity. Automation of internal audit procedure can be another offering of blockchain technology. Audit procedures include an evaluation of employee functions during the purchasing process. Traditionally, auditors might, for example, check if a list and samples of authorized signatures exists and if employees are using the list when verifying purchase orders. Review steps in the formal bidding process to make sure they are being followed. Ask if accounts payable and receiving checklists are being implemented. Determine if conflict-of-interest policies and opportunities for training and purchasing certification are available for employees. Blockchain technology provides a transparent and automatic solution for reviewing  T. Nodehi et al. these internal processes and track each process from the point of origin to the final step. Moreover, blockchain can increase the efficiency of procurement process. Audits provide an opportunity for organisations to assess the effectiveness and efficiency of their procurement process. Traditionally, if an organisation has contracted with a firm specializing in audits, a common end-of-audit procedure is to offer suggestions for improvement to correct the purchasing performance, reduce fraud and enable cost savings. Blockchain can automate the procurement process while it can give a transparent and immutable solution during procurement steps. For example, the identity and validity of the source and destination of each transaction in the platform is recorded in the distributed ledger, hence, nothing can be lost or misfiled which can provide new suggestions and insight as well as opportunity for automation of the process.
The third feature is providing Timestamps. In e-Procurement, timestamping technique enables stakeholders to be sure about the creation and modification time of any document such as a bid proposal. Since security is an important factor and no entity should be able to change a submitted document, currently, third party trusted companies provide timestamps. Blockchain technology can provide timestamps at the exact time of submission of any document with tamper proof records.
Forth feature is creating immutable Tender Document by storing the hash of a tender document on the distributed ledger of blockchain network which by nature is immutable.
Fifth feature is Contract Management, as another important contribution of blockchain. In e-Procurement system, there is a process for creating contract between a supplier and a buyer which governs the tender process. Blockchain can provide an automated and efficient contract process through smart contract mechanism.
Sixth feature is be Payment and micro-payment within the e-Procurement ecosystem. Usually in a e-Procurement platform, a tender is shown only to suppliers using the same platform. We consider a scenario Vortal can collaborate with other European e-Procurement platforms. Based on requirements of each tender, the suppliers in one platform can see and response to the tender in other platform automatically. This means there is a need for a solution that can create a trusted and transparent environment for automating finance processes and settlement of micropayment.
Seventh feature is that blockchain technology can support Internal Data Management of e-Procurement platform. Data on the centralized servers are vulnerable to hacking, data loss, and human error. Using blockchain enables data storage to be more secure and robust against attacks (Meng et al., 2018). One of the obvious use cases is deploying blockchain technology for sensitive data security and management in organisations. Furthermore, through permissioned blockchain technology, it is possible to manage data access and sharing data with the authorized employees (Guo et al., 2018). This will improve data security and privacy.
Eight feature is supporting Interoperability as the use of blockchain based solution for e-Procurement ecosystem can address the challenge for internationalisation and collaboration between various e-Procurement platforms.
The ninth feature is providing more Security. All transactions in the network are secure since they are authenticated and verifiable.
After identifying all nine blockchain use case applications for e-Procurement ecosystem, we had several internal discussions with our partner, Vortal, they have been considering this solution initially as a pilot project. Identifying the contribution and cooperation level of each stakeholder is crucial. Hence, in case of collaboration between several e-Procurement platforms in Europe, some tenders will be available for suppliers from different platforms and countries. This will have many challenges, but it will bring more business opportunities with a more efficient and cheaper solutions. The team will explore and deploy the possible network effect of solution throughout the development process. We also had several in depth discussions amongst the research team, technical development team, and business development team members of project had in order to evaluate the idea, methodology and impact of proposed solution beforehand. The team will be in contact and follow same approach for future development.

Customer layer
As discussed in Business layer and considering Fig. 7, we identified several customers in e-Procurement ecosystem including e-Procurement platforms, financing institutions, buyers, suppliers, contractors, consultants, and timestamp providers. The core stakeholders in this ecosystem are the e-Procurement digital platforms that will interact with blockchain network. Traditionally all payment transactions are happening trough banks and financial institutions. However, in proposed solution, the micropayments will happen through blockchain network and at the end of each agreed situation, the final settlement will happen through banks. Each buyer will have its own ID and can place required tender in the network. The smart contract can be made based on buyer's condition. Each supplier has a unique ID. Each supplier can submit its proposal for a tender. Smart contract evaluates all proposal and when a supplier meets the requirements of a tender and offers the best condition in certain period of, smart contract automatically select that supplier and create a legal contract between buyer and supplier. Traditionally, there are individuals or companies as contractors based on the needs of e-Procurement ecosystem. These contractors still can play their own role in the blockchain network and have their own unique ID. There are situations in the ecosystem that required consultant services. They can also be part of blockchain network and request various transactions in the network. Traditionally there are timestamp providers enable stakeholders to be sure about the creation and modification time of any document such as a bid proposal. Blockchain itself provide timestamps on transactions, hence, the need for central timestamp provider can be eliminated. However, since these companies are trusted parties, they can still have a role in e-Procurement permissioned blockchain ecosystem by running their own node(s) as part of blockchain solution and providing the service to the e-Procurement ecosystem.

Physical asset layer
As shown in Fig. 6, Vortal has sets of processes for e-Procurement that should identified to including creating the tender procedure and invitation to tender, publicising a tender (including contract notice and documents), preparing proposals and receiving online submissions with receipts, comparing bids automatically and evaluating the proposals, holding an e-auction, awarding a bid, creating contract, sending notifications, digitally sign the contract, and finally payment and final settlement. Blockchain ecosystem should be able to operate all mentioned processes seemingly.

Interoperation layer
We require a Blockchain with modular and pluggable architecture that can play a significant role by enabling interoperability between organizations within the network as well as external organization with distinct blockchain solutions. Also, the e-Procurement platform should communicate external data, real time information to the blockchain network. The platform should perform its internal technological operation and provide support the blockchain network through big data, cognitive computing, artificial intelligence, e-cataloguing, and machine learning. It should also provide internal identity and membership management as well as plugging to the external identity providers.

Blockchain layers
To define this layer for e-Procurement use case, we followed same structure as suggested in EBDF which includes selecting the appropriate technologies, Application Layer, Digital Asset Layer, Token Layer, Contract Layer, Consensus Layer, Data Layer, Network Layer, and Infrastructure Layer.

Selecting the appropriate technologies
As a result of previous step, we looked into Fig. 2 (presenting the visual mapping of different types of blockchain network), Table 2 (Comparison of most consensus protocols). Evaluating all conditions, we considered Hyperledger Fabric (HF) as one possible platform for development Phase. HF is hosted by Linux, the world's leading open source community. HF allows components, such as consensus and membership services, to be plug-and-play which means that businesses can plug in different functionalities to suit their particular needs. Hyperledger is not focused on a specific industry and already has been deployed in various industries, such as supply chain traceability, e-Government, insurance, copyright protection and real estate (hy perledger.org/learn/blockchain-showcase). In HF based enterprise blockchain network, there is a possibility to create channels, permitting a group of participants to create a private ledger for the transactions based on their business logic. This feature in the HF based networks is valuable specially where some members are competitors and not want every transaction they make known to all participant (Lu et al., 2020) HF provides all the capabilities of the blockchain architecture -data privacy, information sharing, immutability, with a full stack of security protocols -all for the enterprise. Currently, it has one of the largest blockchain developer communities and allows them to utilize the technology for designing data-sharing networks, micro-currencies, operating systems for marketplaces, and decentralized digital communities. HF incubates and promotes a range of business blockchain technologies, including distributed ledger frameworks, smart contract engines, client libraries, graphical interfaces, utility libraries and sample applications.
Regarding the application scenarios, HF can offer some specific solutions. In case of Membership Management, ID Management and Digital Signature, Fabric network is a private blockchain and each member only through Membership Service Provider (MSP) can be part of the blockchain network. The HF architecture uses x.509 certificates through a public key infrastructure for the MSP or the Certificate Authority (CA). each member or each organisation within a business network will run their own certificate authority. Additionally, as mentioned before, using multi-channel HF network, each consortium can define permissions on who can join the network and what type of access each membership can grant. Vortal-Interdata is considering providing digital identity and validate permissions for stakeholders using HF blockchain technology. This can provide trusted identity of bidders and the bidding entity. In case of Audit Tracker, exploiting the concept of channel can support confidential transactions between authorized members of a (business) group. A Fabric blockchain network can run discrete channels which are completely independent. Each channel can define a different set of rules, business policies, and chaincode smart contract. There can exists only one distributed ledger per channel which every member has access to it. However, each channel can run multiple smart contracts based on the consortium requirement. In a channel, the members of a business can specify asset types for ordering transactions. This can ensure that all participants for a specific call can receive same information and can automate some processes like closing and bid analysis. The HF solution can also provide efficient processing through segregating of consensus and chaincode execution. In case of Contract Management: HF network can create parallel channels that authorize a group of stakeholders to create a private ledger for the transactions based on their business logic which can be programmed by chaincode as a legal contract. Each contract can be signed through digital signature.

Application layer
The blockchain network can integrate the application layer of e-Procurement platform and the rest of operations can happen in underlying layers. In HF based solution, a client node can initiate a transaction using application SDK.

Digital asset layer
The digital asset layer performs definition, connection, configuration, and execution of various interactions in the physical space. In our e-Procurement ecosystem scenario, eToken is a utility token for internal payment within the blockchain network which will be explored more in Token Layer. Additional, the e-Procurement blockchain should provide solutions for all processes and operations identified in Physical asset layer. This will happen through execution of various smart contracts that are specified in Contract Layer including "legal contract management between e-Procurement platforms as well as external service provider", "Micropayment/ Payment mechanism", "Management and automation of a tender process", as well as "Legal contract management between supplier and buyer".

Token layer
This section is suggesting the scenario for using a blockchain based token called eToken in blockchain solution for e-Procurement ecosystem. Each eToken is equal to 1 euro. The e-Procurement platforms in the blockchain network are promising to exchange eToken with fiat currency if it is needed. This token can be used in two scenarios. First, for interoperation payment and micropayment. For example when a tender in platform X is shown in platform Y, and a supplier registered in platform Y wins the tender. Hence, buyer pays platform X with fiat money, platform X pays platform Y with eToken, and platform Y pays fiat money to the awarded supplier. Later each platform can convert its eToken with euros. Second, for contractor or government payment. Sometimes external entities give a service or get a service from e-Procurement Blockchain Ecosystem. They also can pay or receive eToken instead of fiat currency. When they need they can exchange their eToken with euros. Fig. 8 describes 7 steps for tokenomics model.
Considering the Fig. 5 from Token Layer of our proposed framework, EBDF, an eToken is called Utility Token for payment (For internal payment method within the network). Applying the proposed model in Fig. 4, the purpose of eToken will be classified as [Class: Utility Token, Function: Asset-Based Token, Role: Payment]. The governance of eToken will be classified as [Representation: Physical, Supply: Pre-mined, scheduled distribution, Incentive System: Enter (Earn)]. The characteristics of eToken will be as [Transactions: Spendable in the network, Ownership: Non-Tradable, Burnability: Non-Burnable, Expirability: Non-Expirable, Fungibility: Fungible]. And at last, the technical dimension of eToken will be [Layer: Application, Chain: Issued on top of a protocol].

Contract layer
HF leverages container technology to host smart contracts called "chaincode" that comprise the application logic of the system (Androulaki et al., 2018). The chaincode executes when the term and conditions in the smart contract are met. Assets are added, updated, and transferred using chaincode. Fabric has five main functionalities as shown in Fig. 9. A ledger immutably records all the transactions generated by smart contracts. Smart contracts and ledgers are used to encapsulate the shared processes and shared information in a network, respectively.
There will be different channels in the network as subnet of communication between two or more specific network members. Each channel can define the smart contract and consensus algorithms independently for the purpose of conducting private and confidential transactions. This characteristic is going to be useful for audit tracker application scenario as well as membership management for each specific call, since it provides privacy and confidentiality through defined channels.
We identified few smart contract chaincodes that they should be programmed for the e-Procurement blockchain ecosystem: A template for creating legal contract between e-Procurement platforms which can adjust based on agreement between e-Procurement platforms. A template for creating contract between an e-Procurement platform and external service provider which can adjust based of legal rules and ecosystem compliance. Managing the micropayment for interoperation between platforms or getting external services through Exchange smart contract discussed in 4.2.5.4. A template for management and automation of a tender process which can be modified based on the requirement of each tender (including creating the tender procedure and invitation to tender, contract notice and documents, comparing bids automatically and evaluating the proposals, holding an e-auction, awarding a bid). And eventually, a template for creating legal contract between supplier and buyer where Each tender will have its own conditions.

Consensus layer
Instead of proof-of-work consensus mechanism in Bitcoin network where all nodes independently trying to come to consensus on the state of the blockchain, the ordering service node in HF based solution will interact with the peers who are validating the transactions and then will order the blocks and send it out back out to the peers. HF offers a pluggable architecture where a consortium can define their own algorithm. Consensus mechanism in HF comprise of three separate steps of "Transaction endorsement", "Ordering", and "Validation and commitment". Different pluggable configuration options for the ordering   service includes PoA, Kafka, RBFT, and PoET (Sousa et al., 2018).

Data layer
Distributed ledger is the primary component of any blockchain network. In proposed solution, as shown in Fig. 10 a ledger consists of two data structures. First, the "log of transactions or Blockchain" which is an immutable linked list of blocks (a hashchain) with new block always added to the end. Each block contains zero or more transactions and some additional metadata. The first block is known as "genesis" block and has zero transactions. It includes details about configuration of network which contains certificates of all the organizations and peers in the network and information on how to bootstrap the blockchain network for the case study. The Genesis block is downloaded primarily on the ordering service node. Second, the "World State" which stores the last state of smart contracts and output of transactions. World State is stored in a traditional database where data elements can be added, modified, deleted. Each of the peers in the network can run an external state database. CouchDB is the most important externally supported World State database.
The Blockchain component of ledger stores immutable log of all activities and transactions occurred in each channel and can enable audit tracking and as general traceability for our use case. Each transaction can be defined as shown in Fig. 10. Each transaction can be any message or document produced by any stakeholder in the procurement network. Either it is valid or not, it gets a transaction ID at the time of creation and has a creator ID. The time of creation gets recorded in the Timestamp field. The timestamp provides an additional level of verification for any document or event (transaction) created by stakeholders in the procurement process. Transaction proposal or its hashtag depending on the type and size of transaction gets recorded in another filed. The other fields will be described later in this section.
There would not be any security issue for storing the ledgers in hosting nodes outside of Vortal platform, since only the cryptographic hash of various information will be stores on the blockchain. Moreover, based on privacy requirement always it is possible to add or remove a (external/ internal) peer to the business channel configuration.

Network layer
As discussed, we will deploy a consortium permissioned blockchain framework called Hyperledger Fabric (HF) for developing our blockchain ecosystem. A HF network contains a set of nodes which are the primary foundation of the blockchain network for communication. Each node requires permission and valid certificate to communicated with the network. In HF network there are three types of nodes: 1. Client node: It initiates a transaction using application SDK and has an identity. 2. Peer node: Peer nodes can host ledgers and run smart contracts.
There are 4 types of peer nodes. First one is "Committing Peer". Every peer of a channel is a committing peer. The committing peer holds a ledger for each channel that engaged in. It is not necessary to install a chaincode on this kind of peer. The peers validate ordered blocks of transactions and then commits (writes/appends) the blocks to its copy of the channel Ledger. The peers and mark all transactions of each block as valid or invalid. Second one is "Endorsing Peer". Any peer that has a chaincode installed is an endorsing peer. An endorsing peer executes the requested smart contract code and return a proposal response to the client application. Once a transaction is endorsed, it can be accepted onto a committing peerś copy of ledger. Third one is "Leading Peer". In an organisation while there are multiple peers subscribed for various channels, at least one peer should serve as the leading or admin peer for the channel with the responsibility of communicating with the network ordering service on behalf of the organisation. And the last one is called "Anchor Peer" which is defined in channel configuration of an organisation for cross-organisation communication scenarios depends on gossip. Anchor peers increase the availability and redundancy in the network. 3. Ordering node: An Orderer receives endorsed transactions from application SDK, package them into blocks as based on channel configuration file and send them to all other peers to validate those transaction and update their ledgers. Ordering service keeps track of all transactions in their ledger including valid transactions and invalid transactions. It is not necessarily run by every organisation in the network but at least one of the organisations must run it.
There will be different channels in the network as subnet of communication between two or more specific network members. Each channel can define the smart contract and consensus algorithms independently for the purpose of conducting private and confidential transactions.
Each of the involved organizations are running their nodes in their own Docker container virtual networks. These virtual networks are going to interface between each other and that is how the different organizations will interact.

Infrastructure layer
This layer specifies and configures underlaying infrastructure considering the solution will deploy HF. Each organization involved in the blockchain ecosystem requires to run at least one node. As described in Network Layer, the network includes peer nodes to host ledgers and chaincode smart contracts. A computer that runs a node needs to have RaspberryPi or Ubuntu with minimum 4 GB Ram. Each chaincode invoke runs in its own container that will take up additional resources. To monitor the performance, it is possible to integrate Hyperledger Caliper. Hyperledger.github.io recommended using at least 4 Gb of memory to run HF. The following are prerequisites for installing the required development tools: -Operating Systems: Ubuntu Linux 14.04 / 16.04 LTS (both 64-bit), or Mac OS 10.12 -Docker Engine: Version 17.03 or higher -Docker-Compose: Version 1.8 or higher -Node: 8.9 or higher (note version 9 is not supported) -npm: v5.x -git: 2.9.x or higher -Python: 2.7.x -A code editor, VSCode is recommended.

Solution workflow
Previously, we identified and explained the layer of the main components of each layers of proposed architecture for Procurement ecosystem. This solution is a a permissioned blockchain network which is using Hyperledger Fabric (HF) framework which is one of the available open source blockchain solutions as described earlier. Each organization in the ecosystem is running in their own Docker container virtual networks. These virtual networks are going to interface between each other.
In Fig. 11, an example of blockchain solution with following components is presented: -Membership Service: In the proposed solution, every node had an identity and holds set of permissions and valid certificate to communicated with the network. Based on the business requirement the permission can dynamically modified by organisation's administrator(s). One of the important characteristics of provided solution is all capabilities of this solution are modular and pluggable. Hence, Vortal and other platforms can plug in parts of their existing systems to the blockchain solution. One of them is identity management system and certificate authority. Furthermore, in proposed solution, any authorized external entities can host a blockchain node and each member or each entity within a business network can run their own certificate authority. -Client: Each consultant, supplier, contractor, buyer, or even logistics system in the procurement network can be a client. As mentioned before, each client has an ID and it can initiate a transaction using application SDK. -Ordering Service: The ordering service node is not necessarily runed by every organization within the network but at least one of the organizations including Vortal company has to run this node. Because this node is entirely responsible for ordering transactions and blocks in propagating those out to the peers in the network. The ordering service node will interact with the peers who are validating the transactions and then will order the blocks and send it out back out to the peers. -Channels: As described before, in this solution it is possible, within procurement network, to take two or more of the participants and put them in channels and have them sending blockchain transactions to each other without the rest of the network knowing about them. This can happen based on business requirements. All participants in each channel should be authorized and all have access to same ledger. Hence, each channel contains a distributed ledger. However, there can exist more than one smart contract defined for each channel. The segregating of consensus mechanism and the chaincode smart contract execution for each various channels can happen simultaneously. Other that privacy, that enables a very efficient model and it allows a high transaction throughput. One important channel is called "Global Channel" which is created by Vortal to include everyone in the network. All other organizations (which join to the blockchain network and provide different types nodes) can join the global channel. All the peers within each organization will find the global channel and join it using their Certificate Authority (CA). Since every peer is part of Global Channel, to simplify the example shown in Fig. 11, we did not show the Global Channel. -Committing Peers: Every peer of a channel is a committing peer.
The committing peer holds a ledger for each channel that engaged in. They do not run any smart contract chaincode.
-Endorser Peers: The endorsing peers are the ones that run the chaincode on their machines to validate it. Once an endorsing peer receives a transaction proposal, it pursues a four step process to confirm the transaction is correct. First, it checks if the transaction proposal is well-formed with a correct syntax. Second, it inspects if the transaction has been submitted in the past to avoid the double spending. Third, it checks the identity that is submitted the transaction and confirms it has the correct digital signature. Each organization uses its own CA service to validate the transaction signature. Finally, it is important to confirm the authority and permission given to the identity who submitted the transaction.
Once these four steps at endorsing peers have been examined, the transaction proposal can be considered valid. Then, the endorsing peers send back the transaction proposal signatures to the original identity that submitted it. The application SDK verifies the endorsing peer signature and compares the proposal response to determine if the proposal responses are the same. Then the Client combines all collected endorsements into a transaction. The SDK sends the transaction proposals and response within transaction message to the Ordering Service. Then, transaction block gets validated and committed. Finally, relevant ledger (based on the related chaincode) gets updated and the Client gets the notification.

Conclusion and limitations
Despite being a technology at an early stage of its adoption curve, with many open questions about its applicability and evolution, blockchain technology is definitely going to shape data systems and business relationships in multi-party collaborative business ecosystems. Although many competing enterprise blockchain technologies are emerging with many having technological, scalability and implementation issues, it is yet to be seen which platforms compete and finally emerge as a winner. In this scenario we have developed and proposed a technology-agnostic Enterprise Blockchain Design Framework, EBDF, that will help blockchain ecosystem designers to develop models and architectures for enterprise blockchains irrespective of which platforms they select. This has been the attempt and the contribution of this paper.
To validate the applicability of EBDF, we have applied it to a proposed project where the framework was useful in designing the architecture of a collaborative e-Procurement platform ecosystem. Building of a completely functioning blockchain ecosystem is a lengthy process, however EBDF has proven extremely useful in specifying and designing the overall blockchain architecture for the proposed ecosystem.
Open procurement procedures and cross border procurement is requiring new levels of trust and transparency from e-Procurement platforms. Some of these requirements were being fulfilled by third parties who issue certifications, timestamps, and conduct audits. However, these procedures are often cumbersome, expensive, and still require trust in a particular entity or authority which could be prone to corruption or collusion. Blockchain Technology on the other hand provides a promising alternative, that is decentralised, immutable and secure thus can act as a multi-purpose trusted third party for several applications. In this paper we explored some of the key functionalities and use cases where blockchain technology that can be used to benefit e-Procurement platforms. Although we are not at a commercial implementation stage, such modelling has demonstrated the significant advantages that blockchain technologies can bring to the next generation of e-Procurement infrastructure and prepared a blueprint for better analysis and smoother implementation.
Limitations of this work: While public blockchains have seen mainstream adoption particularly in decentralised finance, asset management and NFTs, it is private blockchains that are most suitable for industrial use cases. However industrial application is not just a technological challenge, but a coordination challenge amongst the various stakeholders in a dynamic ecosystem. This coordination amongst industrial players needs to be done after slow and careful consideration of business requirements of all the players involved, and often needs to be implemented in well thought out stages that includes architectural design, proof of concept, intensive testing before adoption. This work provides a sound framework for the architectural design and proof of concept. However its biggest limitation is that the proposed design has not been implemented as a working blockchain solution yet, and hence the effectiveness of the proposed objectives have not been validated in a working blockchain. This is a common constraint with many academic works on enterprise blockchains since the complex nature of the technology implementation means many projects are at a very early stage or at a proof of concept stage.
However the main purpose of this paper is to present the key considerations for blockchain design which are well documented and identified based on public blockchains, and fills the gap of a comprehensive framework for design guidance that will remain relevant despite changes in the technologies applied.

Implications for Managers, Decision Makers and Policy Makers:
Private corporate entities are very experienced in responding rapidly to business and technological challenges. However developing efficiencies and growth does not only require the ability to compete but also to collaborate with ecosystem partners and other players in the industry. Unlike other technologies, Blockchain does not merely provide competitive advantage to one entity, but helps the entire ecosystem by reducing friction, increasing transparency and promoting interoperability. Thus a blockchain based ecosystem will only make sense where a large number of industrial actors require a trustless system to collaborate and interoperate.
The biggest contribution of this paper is to clearly identify where a blockchain really makes sense and where it doesn't. This knowledge is vital for managers to identify if they really need a private blockchain, or should integrate with a public blockchain (like Vechain for supply chain) or go for a centralised database based ecosystem.
The framework presented also enables decision makers to think systematically to identify all the use cases and features of any proposed blockchain, such as data sharing requirements, audit requirements, role of tokens and financial exchange amongst others. The framework provides an overview for such a systematic analysis. Finally Policy Makers and regulatory bodies can use this framework to identify the potential security, audit and interoperability features that a blockchain based system can provide, and hence identify disruptions to existing practices and regulations. For instance, under the Portuguese legislative framework, third party timestamps are a mandatory requirement for e-Procurement platforms, while post the implementation of a blockchain based framework, such requirements can be dispensed with since blockchain itself acts as a trustless third party.

Declaration of Competing Interest
The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.