1 Introduction

Blockchain (BC) is a recent technology that was first introduced with the Bitcoin cryptocurrency (Houben and Snyers 2018). However, BC technological capabilities are not only applicable to cryptocurrency and so it has been proposed to be used in other applications. According to Guo and Yu (2022) BC proposes to add several features to any application, namely: decentralization, autonomy, integrity, immutability, verification, fault-tolerance, anonymity, auditability, and transparency. Blockchain is proposed to be a viable method of tracking assets while guaranteeing security and data integrity (Meidute-Kavaliauskiene et al. 2021). The benefits of blockchain-based tracing include the security of information sharing, real-time collection of product data, transparency, and visibility in the supply chain, as well as quality control throughout the entire lifecycle (Agrawal et al. 2021). According to several authors most of these features seem to make a perfect fit to supply chains since they support the key basic objectives: quality, speed, dependability, cost and flexibility (Casey and Wong 2017; Dinh et al. 2017; Kaur and Parashar 2022).

1.1 Problem relevance

For supply chain a recent duo of aspects: traceability and provenance have gained more importance. The focus on these aspects aims to allow the industries and customers dependent on supply chain to become assured of the products and processes sustainability (Kshetri 2018; Pal and Kant 2019). While it is common nowadays for logistics operators to accurately track packages at the transportation stages, that type of granularity is either lost or many times not possible at all stages of the supply chains since they have become much more international, complex and interorganizational spanning (Kim and Laskowski 2018).

From literature it is clear that the loss of traceability and provenance information the main factor that affects existing sustainability and compliance certification efforts making it crucial and the focus of research in the context of supply chains (Garcia-Torres et al. 2019). The traceability aspect additionally will also permit the optimization of supply chains which has always been one of the most preeminent topics for businesses as it highly influences a firm’s success (Kros et al. 2019). This traceability optimization aspect of the supply chain is then the main driving reason that has led some companies to make trials for Supply Chains using BC for traceability (Berg and Myllymaa 2021; Wang et al. 2019). Examples are; Maersk – tracking global shipping, Alibaba – reduce food fraud, Lockheed Martin – improve cybersecurity, Everledger – implement diamonds and wine certificates, Walmart – monitor pork produce in China, Modum – safe drug delivery, Intel – track seafood supply chain, Bext360 – bring transparency into the coffee bean supply chain (Kshetri 2018).

1.2 Summary of the solution

This article proposes that to effect true and complete traceability the solution is to connect both the Supply Chain Actors (SCAs) and products identifications and provenance certificates. With the proposed approach the chosen BC and the designed Smart Contracts will be used to manage the traceability and validation of the identities while the storage, importing, exporting and verification of production and provenance certificates uses another existing architecture solution off-chain: WalliDFootnote 1 (Tavares et al. 2018). To create, validate the certificates and setup the chain of trust, an appropriate PKI (Public Key Infrastructure) with the corresponding CAs (Certificate Authorities) was designed as part of the proposal. To instantiate the problem and apply the solution a real food supply chain example was chosen. The chosen example uses the widely adopted and EU commission sponsored label and quality certificate system: Protected Designation of Origin (PDO). The main advantage of this proposed solution with an aggregated BC and Certificate architecture is that all SCAs (including producers, logistics operators, sellers and the end consumers/buyers) can use the system to view and self-verify the validity of both the traceability and the provenance claims.

In summary this work aims to provide a concrete answer to the supply chain traceability problem for the use case of supply chain certifiable actors, producers, products and consumers. The answer is a complete traceability system that provides both SCAs and the customers the highest level of traceability by assuring provenance, chain of custody and traceability verifiability and visibility to the SCAs and customers. The solution proposal consists of a set of artifacts (architecture diagrams and workflows, Ethereum SC and a PKI infrastructure) that followed the Design Science Research (DSR) methodology. Along the following points, we present a literature review covering various topics related to the scope of our study, like the chosen Blockchain and its impact on supply chains and their actors, the limitations and challenges of supply chains by using BC, the concepts of traceability, provenance, chain of custody, the supply chain agents and the requirements involved on their involvement. Then the research methodology based in the Design Science approach is introduced, and the proof-of-concept results are then analysed and discussed. The proof of concepts includes an architecture and a Use Case functionality for the Protected Designation of Origin for alimentary products (beef). Finally, the conclusions and future work are presented.

2 Literature review

2.1 Blockchain contributes to supply chain management

According to Weber et al (2016) Blockchain can be used as a technology that supports the collaborative process required by a Supply Chain and is proposed as an alternative to having a centralized trusted party. Since then the industry has been alerted to the potential benefits of the use of BC to SC and according to Chang et al. (2020) BC adoption in Supply Chain Management (SCM) is expected to boom over the next 5 years and is one of the BC applications with more growth potential where the market is estimated to grow at a compound annual growth rate of 87%.

2.1.1 Blockchain aspects benefiting supply chains

The mostly stated contributions of blockchain to Supply Chain Management are the traceability and transparency aspects (Moosavi et al. 2021). Already several use cases have been studied and designed by Francisco and Swanson (2018) to illustrate how blockchain could improve traceability, efficiency, and decrease waste in a food supply chain. Blockchain could also help achieve robust cybersecurity and increase trust as demonstrated by Kshetri 2018 and Ying et al. 2018. There are several BC features that can offer advantages or trade-offs in SCM (Litke et al. 2019): Firstly, scalability may be improved since all actors participate in a common ledger without a single point of interaction. There also may also be a performance increase measurable in a reduced time for assurance of transaction verification compared to centralized and escrow services (e.g., bank payment liquidity or manual verification of a bill of lading) made possible due to automatic execution of contracts. Additionally, the consensus mechanism provides trust to all actors in the chain and offers privacy since although the transactions are verified, the actor’s identity might be kept private via the BC specific addressing scheme. Furthermore, the SCM location dependency becomes more flexible by effectively allowing to make transactions autonomous from country regulations and laws. There is also the expectation of reduced cost by allowing faster payments while SCs (Smart Contracts) allow for faster dispute resolution. There are three generic benefits of BC to SC in 3 main topics (Somapa et al. 2018; Wang et al (2019): improvement of SC visibility, ensuring secure information sharing and trust and increased operational effectiveness.

2.1.2 Blockchain benefits to supply chain actors

Perboli et al (2018) used a lean approach to design and evaluate real world use cases that combine BC and SC. In their analysis there are specific benefits to each actor in the supply chain: producer, transporter, distributer, warehouse, final user/customer. For the producer, the value propositions of BC are the improvement of production planning and certification via Enterprise Resource Planning (ERP) integration, introduction of Stock Keeping Unit (SKU) certificates into BC and the reduction of the bullwhip effect since improving supply chain visibility allows for increased production requirements accuracy. For the distributor, the visibility of the whole supply chain allows for better inventory update and the reduction of counterfeit, theft, wrong delivery, product recalls, paperwork and the increase in ease of compliance. For the transporter/carrier, the benefits are the forecast improvement and the time slot reservation by using more real time information on the actual state of the product location and of the processing phase. For the final user, the benefits depend on the segment: Business-to-Business or Business-to-Consumer. Regarding the first, it will benefit more of easier stock management and expiration/recall management while the later will benefit more in better brand value management by providing the consumer better health protection and guarantees with more transparent sustainability or compliance claims.

2.1.3 Blockchain adoption path in supply chains

Dobrovnik et al. (2018) propose an adoption path for BC in supply chains and logistics. They propose that companies should focus first on single use cases to minimize risks of adoption and to start with proof on concepts that require little coordination with third parties and that allow for IT skills to be developed and learn the technology nuances. Specifically, they mention the use case of reconciling multiple companies’ internal databases since it is a contained problem that brings major benefits. The second proposed adoption approach it to tackle the transactions across boundaries as, in example, reducing the paperwork by migrating the bills of lading (responsibility ownership documents used in shipping industry) into BC. Thirdly they recommend focusing on replacing functionalities that do not require that end users significantly change their behaviour. As an example, replacing paper certificates in the diamond industry. Finally, the introduction of new business models or new logics of value creation over BC, as for example using new SCs to act to prioritize specific air corridors.

2.1.4 Problems and challenges of SC over BC

A particularly challenging aspect for supply chains over BC has been reported by Weber et al. (2016) and is the latency and latency variance of transaction completion. In a public Ethereum platform the average latency for a modelled supply chain scenario was measured to about 23s. This problem has been reported to be mitigated in a private customized BC with average latency around 2.8 seconds. Another answer to the low performance problem of BC is claimed by Xu et al (2019). Their study focused on providing traceability assurance via improving certificate traceability systems. These systems receive the certificates issued by inspection authorities, that verify the quality and originality of the products, and store and expose them to other interested parties for accountability purposes. The authors proposed and implemented a proof of concept that moved the centralized certificate traceability system to a decentralized system over BC to avoid the risk of tampering by unreliable employees or firms. Their answer to the lower performance problem however is that it is acceptable in that use case since the number of certified suppliers and products is low. Another problem that affects the effectiveness of supply chains over BC is that the number of stakeholders in global supply chains tend to undermine any traditional type or mechanism for enforcing security. Xu et al. (2018) in their work proposed to enhance the security of said supply chains via the binding of the physical and cyber worlds using digital certificates for both employees, devices and products that are responsible to enter and check the product data in the supply chain.

2.2 SCM traceability conceptual framework

The main problem in SCM when adopting BC is to ensure complete traceability. Many different aspects that provide complete traceability have already been mentioned and it is then important to provide clear definitions and context to their use and relationship to supply chains to have a conceptual framework on how to build a SC with more complete traceability. As mentioned by Keogh (2018), GS1 supply chain industry expert with 35 years of experience in the SC field the concepts of Provenance, Traceability and Chain of Custody (CoC) are often misused but their understanding and differentiation provides a stepwise conceptual framework on how to understand and approach the traceability network.

2.2.1 Provenance

Even before BC was developed it had already been identified that provenance management was a cross-cutting “hard” problem in science, industry and society. In Cheney et al (2009) provenance was defined as the metadata about the origin, context and history of change of origin in associated objects and processes. To assure provenance, there must be some metadata that identifies the item and its geographic characteristic and some functionality that transmits that information along the supply chain. At the time of the rise of the web and search engines it seemed that it was possible to make the claim that all metadata could be indexed, and provenance could be assured. However, several problems with the reality of provenance in SCM were pointed out: provenance was incomplete, unreliable, insecure, heterogeneous, difficult to integrate and non-portable across systems. At the time no real complete solution for provenance assurance was possible although the combination of sematic web and detailed causal graphs was suggested as a path forward. To make evident the difference of applying BC to the provenance problem, Montecchi et al (2019) applied a slogan “It’s real, trust me” when proposing a framework that provides traceability, certifiability, trackability, verifiability and most importantly the increase of provenance knowledge. This increase in provenance knowledge comes from providing provenance assurances, namely: origin tracing, authenticity certification, custody tracking and integrity verification. These will in turn benefit firms by reducing business risks (real or perceived) which can be further categorized in physical, performance, social, psychological and financial risks.

2.2.2 Chain of custody

According to GS1 (2017), chain of custody or cumulative tracking in the context of a supply chain is a time-ordered registry of the sequence of parties who take physical custody of an object or collection of objects as it moves through a supply chain network. Chain of custody historically comes from the legal requirement perspective to provide proof of the tracking process. In highly regulated sectors (such as food, arms and drugs) chain of custody is critical and serves as the basis of both provenance and traceability assurance. According to ISEAL AllianceFootnote 2 (2016) the key propositions of a chain of custody system are to: identify the origin of a product (final or intermediate), ensure a custodial sequence along the supply chain, ensure that a certified product matches the certification characteristics, link, monitor and protect a claim at a certain stage of the chain with a claim at another point of the chain and finally to improve transparency. ISEAL Alliance (2016) proposes several custody models where the choice of the model depends on the claims the system or the actors wish to make. The models (in decreasing order of connectivity with a certain provenance claim) are identity preservation, segregation, mass balance overview and certificate trading.

2.2.3 Traceability

Has been defined in many different standards (EU Regulation (EC) No 178/2002Footnote 3, ISO 9000:2015Footnote 4, FAO CODEX Alimentarius CXG 60-2006Footnote 5) and it can be summarized by: “the origin of materials and parts, the processing history, and the distribution and location of the product after delivery”. Traceability comes from a business requirement perspective of tracking the movement of products and when origin information is preserved it is said to include provenance information. According to the most recent GS1 Global Traceability Standard, V2.0Footnote 6 these traceability concepts (Provenance, Traceability and CoC) when implemented correctly can be used to provide different levels of traceability functionality in supply chains. According to Sermpinis and Sermpinis (2018) there are two types of traceability: forward traceability the ability to find the locality at any point of the supply chain and backward traceability which is the ability to find the origin of any product given certain search criteria. Providing traceability is important for the food industry as is recommendedFootnote 7 by the European Parliament in GMOs and GM free products. To provide traceability using BC in supply chains a possible approach is to tokenize the goods and use Smart Contracts (SCs) to model their transformation (Westerkamp et al. 2019). The BC in SCM traceability model has also been considered for risk management when supporting a Hazard Analysis and Critical Control Points System (HACCP) (Rahmadika et al 2018). BC enabled traceability using SCs is also well adapted to the post supply chain and has been proposed in a Product Ownership Management System (POMS) that detects counterfeits via combining the Radio Frequency Identification (RFID) product tags with a Ethereum BC system (Toyoda et al 2017).

2.3 Standards for traceability data

The already mentioned GS1 V2.0 standard proposes to make the bridge between physical products and their digital counterparts. According to GS1, traceability data that can be collected can be defined to answer the following five questions at each point of any business process role. “Who” – is typically identified by a Global Location Number (GLN) code (constituted by Company Prefix, Location Reference and Check Digit). “What” – can be a combination of identifiers based on Global Trade Identification Number (GTIN) with increased traceability granularity: class-level (GTIN), lot-level (GTIN + batch/lot ID - Identification) or instance level (GTIN + serial ID). When in transport process the GTIN may be coupled with the Serial Shipping Container Code (SSCC) – this is a pallet IDs that is created in during packing (by the shipping party) and loses the context and value after receipt by (the receiving party). “Where” – is typically identified by a GLN but can be extended by a GLN extension component to identify internal locations within a site, the Serial GLN (SGLN). “When” can be answered via a time stamp which should include date and time (including time zone and Coordinated Universal Time (UTC) time offset). Finally, “Why” should state the role of the party in the chain with typical roles being: harvesting, manufacturing, shipping, transporting, receiving and selling. Some additional information might be added if shipping is required: Global Shipment Identification Number (GSIN) or Global Identification Number for Consignment (GINC) when a bill of lading requires that the logistic unit has common delivery or shipping.

3 Research methodology

The DSR methodology was defined by Hevner et al. (2004) as proactive problem-solving paradigm with the objective to create, apply and evaluate useful artifacts that have as objective to forward the human business and social capabilities in the context of information and management systems. The DSR requires that the result of applying the methodology are artifacts and these can be defined either as constructs, models, methods or instantiations. To carried out the DSR, Hevner et al. (2004) established a set of 7 rules or guidelines: (1) problem relevance, (2) research rigor, (3) design as a research problem, (4) design as an artifact, (5) design evaluation, (6) research contributions and (7) communication of the research (Hevner and Chatterjee 2010). In this study the process of investigation was literature review, definition of problems and requirements, definition of architecture and functionality, interview with use case SCAs, production of artifacts, application of use case and finally an interactive review of artifacts. The produced artifacts were a solution architecture, the Smart Contracts, plus the PKI and digital certification scheme required to support the solution.

3.1 Research objective

This research proposal intends to address the traceability problem by formulating a solution that leverages existing BC functionalities and certificate validation and storage architectures and allows SCAs to gain confidence and verifiable knowledge on a product’s traceability in a decentralized manner. To provide context and guide the analysis and design of the solution an alimentary traceability case study has been selected and studied. The research problem then can be formulated as follows: “How to implement a supply chain traceability system using a certificate validation architecture using blockchain?”

3.2 Research problem and questions

The research problem can be summarized as: “How to implement complete traceability and provenance in Supply Chains using Blockchain?”

The research problem was partitioned into more specific research questions in order to facilitate research and design of a solution:

  • Question 1 - What are the relevant attributes and functionalities (requirements) that must be considered to implement complete traceability in Supply Chain?

  • Question 2 - What would be a feasible and applicable solution architecture using available technologies to implement a certified traceability supply chain system?

  • Question 3 - What are the required components and their functionality to implement the solution architecture?

  • Question 4 – What is the required business logic to effectively manage the products ID and data transversally in the SC system?

  • Q5 - How to validate the product’s ID, relevant data and certificates of provenance?

  • Q6 - How can the end user validate the provenance and traceability at the post supply chain?

  • Q7 - How can this system apply to an exemplary supply chain that requires traceability and provenance assurance?

3.3 Stakeholder definition

To understand the stakeholders needs in the supply chain traceability problem it is important to understand their identity and context in the supply chain. In Fig. 1 the relevant stakeholders / agents are mapped according to their use and impact on the supply chain: Supply Chain Actors, SC Certifiers, post SC Actors.

Fig. 1
figure 1

Supply chain organization

Full size image

The actual supply chain users can be grouped as direct actors where they are involved in the same business use case and are directly responsible in the normal managing of the supply chain (Suppliers, Transformation, Logistics, Distribution/Retail). For the purposes of traceability each SCA has different problems requirements and thus will have different role in managing the SC Products (see Table 1 for a description of the SCA attributes pertaining to traceability). The users/buyers of the products after the retail/seller are considered to belong to the Post Supply Chain. These are either end-user consumers or organizations related to consumer interests (Consumers, Consumer groups/Environmental groups - review and influences public opinion on product attributes and impacts, Governmental agencies - verifies product safety and regulations). There are also groups or organizations that influence the working of the supply chain (require that processes or documentation follow guidelines) but that do not participate directly in the supply chain operation. In what influences the traceability problem and the certificates it is possible to group the supply chain certifiers according to the type of certificate:

  • Government: certifies products that are in accordance with governmental regulations.

  • PDO: certifies products in accordance with PDO regulations.

  • NGO: certifies products in accordance with Non-Governmental Organization regulations.

Table 1 Supply chain actors’ problems and requirements
Full size table

3.4 Stakeholder requirements

To understand which functionalities are required for SCAs it is important to define their reported weaknesses and limitations. This was performed in the previously presented review of literature. From that review we derived the following list of SCA requirements for the products and the certificate handling. .

3.5 Analysis of requirements

Based on the review of literature the main SCM problems related to traceability that were found are: access control, impersonation, counterfeiting, theft and wrongful delivery, certifying uniqueness of products, visibility, managing product recalls and brand value. According to the review of literature to solve these problems it is crucial to improve the 3 aspects of the defined traceability conceptual framework: provenance (metadata about the origin and associated objects, processes and users), traceability (ability to trace the history, application or location of an object) and the chain of custody (time-ordered sequence of parties with physical custody of an object). The state-of-the-art literature review of SCM over BC provided indications on the required functionalities that are needed to implement more complete traceability namely: (1) Manage the SCA access authorization via a certification mechanism. (2) Bind the physical and digital worlds by restricting access to supply chain product data only to certified actors and devices. (3) Use of a lightweight tokenization of products for representation of the products. (4) Allow the import of certificates and verify the true identity of both SCAs and products using said certificates. (5) Allow for certification data to be univocally linked with the SCAs and product tokens. (6) Allow processing and transfer of ownership procedures while maintaining the identity chain of custody and respective certificate linkages. (7) Reduce supply chain perceived risks in the post supply chain by allowing the customers to view certification information.

So, the central capability to verify a digital identity and ensure that only that participant, device or product can use that identity is an essential functionality that is required in supply chains that implement traceability. This functionality has 3 parts: (1) being able to verify the digital signature, (2) being able to verify the certificate of a CA has the correct attributes and finally (3) that the participant is the correct owner of the certificate. This traceability functionality was translated into a requirement to setup a PKI involving the SCAs, the product Certificate Authorities (CAs) and that extends to the certified products. According to the literature review it was also possible to summarize the required attributes for a SCM with more complete traceability with verifiable: “user identity” (SCA ID and certificate), “product identity” (Product ID and certificate), “transfer of custody” (two-sided verification of SCA and product IDs), “uniqueness” (ledger of unique product IDs, “location of products” (geographic reference), and “timestamp of operations”. From the required functionality and attributes, it was possible to select a supporting applicable technology and derive the corresponding improvement of the traceability aspect (Table 2).

Table 2 Applicable technology and the corresponding improvement of the traceability aspect
Full size table

4 Results

4.1 Solution design

Following the literature survey research results, in order to design a solution to provide a supply chain system with complete traceability we must focus on providing solutions to the problems raised by the main three concepts:

  • Provenance – provide metadata about the origin, context and history of change of products and producers

  • Traceability – provide record of the trace history, application and location of a produce in the SC

  • Chain of custody – provide time-ordered sequence of events the parties create when they take physical custody of an object or collection of objects as it moves through a supply chain network.

In table 3 we described the identification of the problems of each concept as it related to SCAs and Products. Following the DSR, the use cases and the architecture are the design artifacts that provide the solutions for the research problems.

Table 3 Mapping between Problems, solutions and artifacts
Full size table

4.2 Proposed functionality

According to Weber et al. (2016) BC can be used as the collaborative process execution machine. This is performed in 3 steps. Firstly, translating the process specifications/requirements into Smart Contracts. Secondly using the BC computational infrastructure to organize the collaborative processes. Thirdly using the BC triggers to connect physical and digital world. This proposal adds to that proposal the use digital cryptographic certificates to establish both: SCA and product identity and authenticity inside/post a distributed and untrusted supply chain. The digital representation of supply chain products is supported by a lightweight tokenization of the products and their associated processes in a SC. In this proposal the certificates are only linked to the tokens and to have a minimum increase of BC storage and avoid the cost for the importing and validation of the certificates in the SCM. To implement the previously defined requirements a set of SCM traceability functions/use cases were defined to be implemented in the Ethereum SC (with the Smart Contract business logic). The SCAs can operate the SCM by calling the SC functionsFootnote 8 (Fig. 2). Architecture workflows for referenced use cases A to G are described in ANNEX 1, use cases H and I are described in ANNEX 2.

Fig. 2
figure 2

Proposed functionality

Full size image

4.3 Design aspects

Due to BC’s unique capabilities and features several design aspects and trade-offs must be considered when designing a SCM over BC. The decision to use private/consortium vs. public BC systems will depend on the selected industry use case, its requirement for global public access and will have impacts on the decentralization, the scalability and latency/latency variance of transactions. A public BC like Ethereum is globally accessible, fully decentralized and has higher availability due to the number of nodes. One trade-off of a public BC is that its transactions are expected to have higher latency and latency variance so the scalability aspect is not under control of the participating organizations and the BC code will generally follow a standard that is defined by a distributed improvement proposal scheme. As an example, an operation over Ethereum public BC is expected to take tens of seconds or more, varying much on the load on the system and so the latency is not under control of the SCM participants. This latency and latency variance problem can be mitigated to a few seconds per transaction if a private or consortium BC is used. However, a trade-off of that approach would be to lose some of the global access and availability features. In what regards scalability a private or consortium BC can scale its throughput without having to increase the number of nodes since it is possible for example to specifically configure consensus mechanisms that allow for faster transaction validation. For the use case in analysis in this article and for the proposal both public or private BC networks are possible to be used and there is no dependency to any BC public/private flavor. Another design aspect to consider is how to store some or all the SCM data: on-chain or off-chain. When user data is stored on-chain (as a variable in a SC) it is more costly (at least 2x more but can vary depending on the BC) but is potentially more performant since the data is retrieved from BC immediately. If data is stored off-chain the SC can interact with it but is less performant since it requires querying the off-chain system so we should expect a more complex implementation and possibly the addition of latency to the solution. The proposal in this article is to aim to keep as little supply chain data on-chain as possible while retaining the traceability functionalities thus following a light tokenization approach. Reducing BC storage costs is important since it could make the solution too costly and hinder the business adoption. Following this approach, the certificates are stored/retrieved off chain via a store provider and only the information on the validity of SCA and product certificates are stored in BC. The SCA addresses and roles and a token representing the product is stored in BC. This token has a universal identifier (Electronic Product Code – EPC) which provides an immediate link to the physical world via Bar codes/QR codes/RFID tags. This EPC will also provide the link to the product certificate which is stored off-chain. The only additional token attributes in BC are the ownership link between EPC and SCA, the custody state (e.g., “owned”, “in transfer” or” sold”) and the current geographic location of the product. The SCA access is implemented via SC logic by verification of the SCA certificates. The same pattern is used both for SCA and product certificates. An SCA can import both actors or product certificates into certificate storage and afterwards retrieve the certificate to validate the identity (SCA or Product) with the SC Manager. If the deployment is to a private/consortium BC it would be possible to remove the strict enforcing of authentication in the SC via certificates and have other methods of access control such as LDAPFootnote 9 (Lightweight Directory Access Protocol) and KerberosFootnote 10 to improve performance and prevent attacks on the BC consensus. It could be argued that private BCs provide better security from the start since only allowed users can use the BC. However, one of the main security risks to any BC is the protection of the private keys and the integrity of the SC code, which is non-dependent on network infrastructure control but on good security practices and hardened and well-maintained SC code. As a preliminary step and to interact with the SCM, a SCA must first create a BC account. A BC account is considered to be the public and private keypair that are connected to the user address and the funds (both stored in the network). To manage the account more easily an interface/wrapper is used, and this is what is generically called a BC Wallet. Interworking with BC with the user wallet can be performed in several ways. For this solution proposal we selected MetamaskFootnote 11 since it allows to streamline the end-user experience by having an interaction with a responsive website while also allowing the use of both hardware wallets (e.g., LedgerFootnote 12 with Metamask) and online wallets (e.g., MyEtherWallet (MEW)Footnote 13 with Metamask).

4.4 Proposed architecture

The proposed architecture uses a Ethereum BC SC to implement the already presented use cases. As mentioned, the SCAs interact with the BC using their wallets via Metamask with calls to the SC code using a JavaScript based interface (Web3 APIFootnote 14) (Fig. 3).

Fig. 3
figure 3

Proposed architecture

Full size image

The state of the supply chain, all its actors and products are tokenized in Ethereum via the Smart Contract. This proposal uses digital certificates for user and product authentication and so it requires that recognized organizations implement a PKI (to generate digital certificates and provide the chain of trust). In the case of public market products governments and certification organizations are among the best candidates for establishing a PKI for businesses operating on global supply chains. It is possible to have the PKI implemented directly by consortium organizations when the use cases are restricted to specific businesses or industry sectors. This proposal requires that only validated SCAs (the ones which can provide an ID and certificate that match and verifies) can register products into the SC system. The SCA and products certificates are digital certificates that attest of the business identity (e.g., when registering with national government agency) or attest that the product has unique distinguishing and certified characteristics (such as in the case of PDO (Protected Designation of Origin (1992)) where the products and processes are verified and certified by a selected PDO regulator organization. The importing and retrieval aspects of the SCA and product certificates is performed with the reuse of the Know Your Customer (KYC) solution from WalliD adapted for identities such as organizations and products. Details on the Certificate Import and Validation functionality using WalliD KYC (off-chain solution) are described in ANNEX 2.

In this proposal the products in the supply chain are referenced by an industry referencing standard, the EPC – Electronic Product Code which is a unique identifier commonly used in supply chains as described in the case of livestock supply chain by Hartley et al. (2014). The supply chain can operate with products without certification (since it is optional to provide them) but the main business value of this proposal should be for products that require authenticity validation. The validation of certificate hashes for both SCA identity and products is performed off-chain by the Supply Chain Manager entity (that includes the role of “Certificate Validator”). Another deciding factor to have certificate validation off chain has to do because it is not performant to execute crypto hashing (validation function) on chain in the current Ethereum Virtual Machine (EVM). The SC Manager (“Certificate Validator”) is also responsible to perform certificate revocation in the cases the SCA or the product must leave the SCM BC. Additionally, SC Manager can also provide a website for SCA actors and consumers to request and view the product certificate given a product EPC. The EPC can then be read from the physical product RFID or QR/Serial code tag using a smartphone with an App our via a specific EPC reader device. After SCA certificate validation the Supply chain management and traceability functionality is provided using the SCA BC addresses via transactions in a trusted and decentralized way with no further validation required. The SCM-SC is deployed in the EVM by the SC Manager which is the owner and ultimate responsible for the security and maintenance of the SC codeFootnote 15 Details on the proposed Ethereum Smart Contract code is in ANNEX 3.

4.5 Case study - alimentary PDO use case

As already mentioned, an example about alimentary supply chain use case was selected to better understand the requirements and correct application of the proposed solution. The selected use case was the production and transformation of certified livestock produce (bovine meat) of the “Carne Mirandesa” – a type of bovine meat that is PDO certified and only produced in the northeast region of Portugal. This PDO is already currently certified using a combination of paper certificates and products tags or stickers that are shipped with the product. From an interview with a producer and retailer 3 document samples were collected: the certificate that links the Government ID of the animal (SNIRAFootnote 16 ID) with the PDO ID and certificate of the brand “Mirandesa” (Geneology ID), the transformation identifier that is shipped with the bovine meat that shows the reference to the animal (SNIRA ID) and the sale point invoice that attests to the purchase of the carcass and served meals with the reference to the batch attested by the a governmental agency (SNIRA ID). The unique identifier that is used across the supply chain is the Electronic Product Code (EPC) that is linked with both the SNIRA ID and the Genealogy ID (EPC-SNIRA ID-Genealogy ID). The product certificate to be generated has then to hold these 3 fields in the X509Footnote 17 certificate request as mandatory fields to be certified together with the public key hash of the producer (supplier actor in the SCM). In summary each product will be issued a X509 certificate by the producer. This particular CA chain of trust requires three SCA certificates: one for the root CA (the Government CA), another for the intermediate CA (the PDO association CA) and finally one for the SCA producer. The summaries of the use case data and PKI certificate setup are presented in ANNEX 4 and ANNEX 5. To streamline the production of X509 certificates the request for product certificates can be automated by an application at the producer side that requires that the producer inputs the triad of X509 attributes that need to be certified (EPC, SNIRA-ID, PDO-ID) and then issues the certificate request and at the CA’s side a backend IT system that issues the X509 certificate after the verification processes have been validated. It should also be noted that as a product is processed in the supply chain its EPC code may change from animal EPC (type SGTIN) to carcass EPC (type SSCC) and carton tag EPC (type SGTIN). However even in this case the proposed solution SmartContract code is capable of maintaining reference to the original certified EPC and its owner SCA and support complete certificate traceability. This EPC code change is also described by GS1 in Hartley and Sundermann (2014) where a livestock traceability proof of concept (PoC) was implemented. In that PoC the EPC codes are read from RFID tags but in that case, they were inserted into a centralized SCM application to provide the required traceability metadata while in this proposal the EPC is stored in BC. As in the PoC in this proposal the EPCs can suffer change due to processing the meat thus the requirement for the previously presented “transform product” function in the SCM SmartContract to keep the EPC and certificate linkFootnote 18.

5 Conclusions and future work

As presented before, we posited and fully described a complex research problem. This complexity stems from two factors, the relative novelty of the technology and the combination of several existing solutions (Ethereum Smart Contracts, Digital Certificates, PKI and WallId certificate storage). This combination allows to propose a solution application for a supply chain when it is imperative to assure the traceability and the authenticity of the products sold over that value chain.

5.1 Research contribution and solution benefits

The research contribution of this work is a solution that aims to answer the research problem of providing complete traceability for a supply chain using blockchain. The main benefit of the solution is that it allows for a group of independent participants to implement a decentralized supply chain system with a complete traceability model for certified products. Another benefit is that via the PKI allow for SCAs themselves to import certificates and customers to view them thus providing trust among participants and the end customers. The proposed architecture simplifies the storage of the certificates by reusing a KYC system (used in banking and credential verification) to both store and validate these certificates. If any certificate fails validation or is revoked (e.g., expiration) it can be added to a CRL (Certificate Revocation List) by the CA (as is usual in PKIs) and the SC Manager simply sets an invalid certificate flag in the SC. If a SCA own certificate is revoked it no longer has access to the chain of trust until it provides a valid certificate. If the product certificate is revoked the product token can still be managed in the SCM but the certificates will be shown as expired or invalid to SCAs and customers (allowing the supply chain to operate while the certificate issue is being resolved). During operation, the SCAs have access via the Blockchain to the ownership status, the operations timestamps, the full chain of certificates and the transfer locations (if added) which can be further processed by SCAs own internal Supply Chain Management systems to interoperate with other IT systems (analytics) and optimize the supply chain.

5.2 Limitations

The main drawbacks of the solution are its dependency on a PKI (for SCAs and products), a centralized and hierarchical trust model and the dependency on a central entity (Supply Chain Manager) for certificate validation. Regarding the dependency on PKI the minimum requirements are its setup by a national or regional or any trusted authority in a privately owned supply chain and that the SCAs must subscribe to an authentication scheme for their identities and products. Regarding the SC Manager this actor is required to deploy the proposed SmartContract into the Ethereum BC and to be the entity responsible to be the “certificate validator”. A possible alternative to the use of a centralized PKI (and possibly to replace also the SC Manager) would to use a decentralized approach as has been recently proposed with Self-Sovereign Identities (SSI) and the usage of Decentralized Identifiers (DIDs) as defined by W3C (2022). Instead of digital certificates some previous solutions propose the import of scanned paper certificates. This is the case of “origin Chain” implementation, but this seems a stegap approach since such verification is more complex to implement and may require manual intervention to fix misreading or damage to the paper certificates. A more technology oriented approach would be the use of IoT devices and RFID tags with digital certificates where all authentication and verification is automated with higher granularity and the added security of a physical security token. An alternative for the SCAs certification-based authorization is to replace it with a simpler although less decentralized and autonomous authentication system (e.g., LDAP) but this has the drawback of increased complexity and complexifying the security and management aspects in cases of global SCMs. If only a sectorial industry approach is required and the global decentralization and autonomy is not necessary and it would be more advantageous to operate over a consortium BC, with the benefits of lower latencies/latency variances and centralized SCM control.

5.3 Future work

There remain open points that are left for possible future work and development of a Proof of Concept (PoC). The first open point is that the SC lacks the functionality for all SCAs to add product certificates (currently only suppliers) in the case of transformation of products. Additionally, it is still undefined when to delete product references after the products go to the post supply chain. Some attention should be given also to the issue of certificate validation outside of the BC. One of the possible criticisms of the proposed solution is that of not achieving complete decentralization since due to the centralized PKI and proposing a certificate validation mechanism to be implemented off chain. As previously mentioned it would be very interesting to explore the adoption of SSI and DIDs as a non-centralized approach to the identity and certificate validation problems. For future work, besides the open issues it is left the development and implementation of a PoC that would allow the deployment of a fully-working/testable SCM with this architecture. Also, for future work would be the design of an incentive scheme that would allow for the implementation of the “Certificate Validator” function. This functionality should be possible to implement by third parties in the public Ethereum BC. A future PoC would also require the implementation of a test framework (in JavaScript) to interact with the SC via the Web3 API and the companion browser or possibly IoT software add-ons to facilitate user interaction with the SCM. In addition to real use case validation of the proposal a PoC would allow to measure operating and information storage costs plus the operational feasibility and business competitivity (in terms of required IT infrastructure).