EDEN Lightpaper

OCT2019

https://multichain.ventureshttps://eden.software

EPCIS Decentralized Netw

ork (EDEN)

Company Sum

mary

2

https://EDEN.software

Modern supply chains, built on centralized systems, face incredible strain from increased demand in the digital ecosystem (online sales surpass retail), further exposing concern about item originality, security, and integrity, as well as diversion into illicit channels. Decentralization of supply chain management produces incredible efficiencies at scale that provide trustless data provenance to track the physical movement of goods as well as procurement of services. Combining these benefits with the GS1.org global business language establishes the future of supply chain standards. Particularly, EPCIS, or Electronic Product Code Information Services, is the established framework for communication between supply chain management systems. EPCIS Decentralized Network (EDEN) produces a layer blockchain infrastructure that can be appended to any existing supply chain management system for better visibility and provenance of data.

The first client for EDEN is TheraCann International, which provides systems to track “seed-to-sale” supply chain information within the cannabis industry, to help businesses and regulatory compliance. Theracann has produced a spray system known as ETCH, which tags cannabis at a fundamental level with molecular biomarkers. The purpose here is to ensure the origin of cannabis products within a supply chain - preventing grey market goods from introduction into a supply chain. By combining this innovation with the EDEN Blockchain, we have a solution to the “garbage in, garbage out” (GIGO) problem inherent to supply chain tracking. Issues relating to diversion, corporate and product insurance, quality assurance, law enforcement, fraud detection, and consumer protection are ever prevalent in many current licensed countries - EDEN reduces these burdens - and structures the data for future interoperability and interstate sale.

Despite the standardized nature of EPCIS, building within this framework does not inhibit the ability to deploy in a regulatory environment with specific reporting variables. It is important to note that the EDEN is not an ERP software system, but rather a data layer that can immutably log the data from existing ERPs and provide a standardized backbone to reduce business reliance on multiple reporting systems. Further, while current deployments of EDEN with TheraCann are for the cannabis vertical, the EDEN software is fundamentally industry agnostic.

Tokes (TKS) is the native token used to pay for EDEN event entries on the blockchain.

EPCIS Decentralized Netw

ork (EDEN)

Technical Approach

3

Rather than reinvent the wheel by entering the market as a competing front-end software provider, EDEN aims to strengthen the provenance, security, and immutability within the existing EPCIS infrastructure via EDEN. The EDEN Blockchain is fundamentally front-end software agnostic, designed to integrate with existing enterprise and legacy tracking systems. EPCIS data is stored as “objects” representing typically physical items, such as products, logistic units, or documents. These objects are tied to “events” which are tagged with a detailed set of descriptors for the object including: “what” – the description of the object, “when” – the date and time that the event related to the object took place, “where” – the location where the event occurred and where the object is expected to be following this event, and “why” – the business step taking place (e.g., shipping or receiving) along with the state of the object (e.g., active, damaged, etc.). Additionally, there are many different event types and modifiers to these basic descriptors. This data is all entered via a capture interface that inputs object information via IoT devices, RFID tags, QR, or bar codes, which is then logged to the blockchain. Subsequently, a query interface - a front end software system - facilitates retrieval and visualization of the data for both auditors and business stakeholders.

To produce a data structure around this event data with the EDEN Blockchain, the system leverages two well established pieces of blockchain technology for the EDEN deployment - the Ethereum network coupled with the Origin Trail protocol for supply chain management. The current proof of concept of the EDEN Blockchain leverages the open, public protocols of both Ethereum and Origin Trail, however, in a potentially more refined solution, a private deployment of nodes can be established in order to ensure the scalability of the network.

Data Capture Interface and Data Store These events and variables around the events are logged via off-chain hosted EDEN capture interfaces - specifically the EDEN API, via XML files, or manual entry (see Figure 1 for a manual entry interface). These events must be formatted leveraging the EPCIS core business vocabulary (CBV; see Appendix A for details on EPCIS CBV) with the requisite variables around events (e.g., What, When, Where, Why). Additional data points specific to the industry vertical (e.g., cannabis) can be appended to the CBV to meet state standards around reporting (e.g., product information, strain data, testing data, sales data, customer data). The nature of the API allows for seamless integration with existing IoT monitors and data capture devices. See Figure 2 for a process flow of data from entry to retrieval.

EPCIS Decentralized Netw

ork (EDEN)

Technical Approach

4

When new data is sent to the network, an initial format check is performed for both syntactic and semantic errors. If an error is found, it is reported back to the sender via a web service response. After this initial check, the data set is converted to graph form in the database, which is uniquely identified via product and batch identifiers. The receiving node then attempts to propagate the new graph data to the network via the distribution protocol. As network nodes receive the data, it is merged into the master graph of the product supply chain, while being validated through network consensus on the blockchain layer.

This blockchain layer serves as a secondary store of the data, as conventional centralized data structures are still required for the ERPs that EDEN will interface with.

Figure 1.EDEN manual capture interface demonstrating the basic EPCIS dimensions - in real world deployments these entries will largely be automatically generated from within the businesses ERP or captured via IoT devices.

EPCIS Decentralized Netw

ork (EDEN)

Technical Approach

5

Advantages of this architecture

1. All changes to the state (storage) of the EDEN repositories are stored in an immutable ledger. Every transaction (i.e., state change) is recorded. This is resilience on the platform-layer.

2. In addition, the event data in the EDEN repository, essentially the event log, is designed so that it cannot be updated or deleted. This is dapp-layer resilience. The data added remains on the blockchain forever.

3. The data is stored in an ISO compliant global standard by GS1.4. With the "stage 2" addition of extensions (miscellaneous information) to the

events, the industry will be able to take advantage of key performance indicators (KPIs) and associated information to look for optimization opportunities and to further improve upon best practices.

5. Monitoring of the EDEN repositories is possible. Integrations with other systems to enhance business efficiency such as automating payments upon event occurrence, is foreseeable.

Figure 2. Diagram of EDEN infrastructure and data flow between platforms.

EPCIS Decentralized Netw

ork (EDEN)

Technical Approach

6

6. Permissions for EDEN instances can be controlled at instantiation, and depending on the initial setting, also later, on the dapp-layer, both on-chain and off-chain, and also using authorization servers.

7. Private instances are also possible on private Ethereum network deployments.

8. On the public Ethereum network, confidential data can be stored off-chain with only a reference hash to assess integrity with the source. On private implementations, data can be privately stored on the blockchain, accessible only by appointed parties.

9. By leveraging open source software, the project will benefit from:a. Community contributors, likely including groups from corporationsb. Global support to develop, upgrade and expand the softwarec. Security auditsd. Custom implementationse. Custom extensions

To provide added features, data capture and query applications can be extended with modules which deliver additional functionality for the users of a specific EDEN instance:● User/Customer authentication (including KYC and AML services)● Industry-wide event lists, supply chain maps, guides● Consortium-specific implementations● Market specific Core Business Vocabularies● Support for sensors and edge devices, capturing data from Trusted

Execution Environments (TEE)● Visualisation tools● Tracking applications

EPCIS Decentralized Netw

ork (EDEN)

Technical Approach

7

Data Capture Interface and Data Store

The query interface for EDEN Blockchain is a work in progress that will serve primarily as a tool for auditors and business stakeholders to visualize the timeline of events and changes around products and materials within the supply chain. As events within the EPCIS standard are multidimensional (e.g., What, Where, When, and Why) - it is necessary to build query tools that capture the flow of goods from multiple points of view. For example; an auditor might want to assess the events around products at a single cultivator, or on a more macro level, assess the regional production within the entire state of Rhode Island - both instances here fall under the “Where” dimension. Additionally, the system allows for particularly granular visualization of data, like a single vegetation room in a multi-warehouse cultivation facility. See Figures 3, 4, 5, 6, and 7 for examples of the Query Interface for the “Where” dimension.

Figure 3. UI design for “Where” dimension of EPCIS data - examining particular business events within a region.

EPCIS Decentralized Netw

ork (EDEN)

Technical Approach

8

Figures 4 and 5. UI design for “Where” dimension of EPCIS data - examining a flow of events within a single facility of an entity, and a summary description of the event types in that facility.

EPCIS Decentralized Netw

ork (EDEN)

Technical Approach

9

Figure 6. UI design of a wireframe visual flow of events at a particular “Read Point” within an entity.

EPCIS Decentralized Netw

ork (EDEN)

Technical Approach

10

The “What” dimension of the Query Interface will summarize particular products or materials within regional supply chains, restricted by date range if desired. Summaries in the case of agriculture might include: total mass produced, total plants grown, total raw material processed, or sales data over a period (see Figure 8 for an example of the “What” dimension). Similarly, the “When” dimension will facilitate a visual flow of event data restricted by date range, and the “Why” will disambiguate event causes (e.g., maturation of a crop from vegetation to flower, harvests, wholesale distribution, raw material processing into extract, etc.).

Additionally, discrete summaries of events can be viewed in the dashboard independent of the four dimension views (see Figure 9). Larger macro-view summaries for data visualization can also be visualized for both larger geographic areas (Figure 10) and for the flow of an object through different events (Figure 11).

Figure 7. UI design for “Where” dimension of EPCIS data - viewing a flow of events within a geographic region - in this instance, Rhode Island

EPCIS Decentralized Netw

ork (EDEN)

Technical Approach

11

Figure 8. UI design for “What” dimension of EPCIS data - viewing goods and materials with summaries of event data.

Figure 9. UI design for summary of discreet EPCIS events

EPCIS Decentralized Netw

ork (EDEN)

Technical Approach

12

Figure 10. UI design for monitoring visualization of events within the network. This can also be designed for a more restricted area (i.e., for a single country, state, county, or city).

EPCIS Decentralized Netw

ork (EDEN)

Technical Approach

13

Scalability and Security

Events that occur on the supply chain will be transacted onto the blockchain via our high-availability application infrastructure. EDEN runs multiple redundant servers (via Reli) on a reliable multi-node Kubernetes cluster. Supply chain events can be recorded directly to the blockchain via separate nodes, meaning if nodes run by our network are down, the global Origin Trail network can still receive inputs from entities using EDEN - with our nodes receiving the data from other global nodes once back online. The time it takes for the supply chain event data to be confirmed on the blockchain will be dependent on the levels of Ethereum network congestion. On average, transactions will be confirmed within 15 seconds. However, on a private network deployment, these transaction times can be reduced. Although the intention is to be online indefinitely, our availability is designed to meet a service level objective (SLO) of a minimum 99.8% uptime. The architecture diagram in Appendix B visualizes the ecosystem of applications and microservices within our Kubernetes cluster.

The nodes responsible for transcribing supply chain events to the blockchain require multiple secured keys to perform a valid request. The signatures used to validate transactions are stored within the configuration of the node, but the multi-faceted access control keeps the functions it performs secure to our system.

Supply chain event data is contained within private networks and accessible only through interface tools provided by EDEN. If a malicious party managed to gain access to an interface, then the activity of a user might be attainable in real time, compromising the supply chain data. Additionally, access to supply chain event data is reliant on our services being online and reachable or the user would have to resort to building their own blockchain interfacing infrastructure to transcribe or read events.

To curb potential threats across all our services, EDEN engages in regular security audits both internally and with an independent firm.

EPCIS Decentralized Netw

ork (EDEN)

Appendix

14

Appendix

EPCIS Core Business Vocabulary (CBV) - from EPCIS and CBV Implementation Guideline (Feb. 2017) - available via https://www.gs1.org/docs/epc/EPCIS_Guideline.pdf

The Core Business Vocabulary (CBV) specifies various vocabulary elements and their values for use in conjunction with the EPCIS standard [EPCIS1.2], which defines mechanisms to exchange information both within and across organisation boundaries. The vocabulary identifiers and definitions are prescribed to ensure that all parties who exchange EPCIS data using the Core Business Vocabulary will have a common understanding of the semantic meaning of that data.

This CBV is intended to provide a basic capability that meets the above goal. In particular, this standard is designed to define vocabularies that are core to the EPCIS abstract data model and are applicable to a broad set of business scenarios common to many industries that have a desire or requirement to share data. It intends to provide a useful set of values and definitions that can be consistently understood by each party in the supply chain.

Additional end user requirements may be addressed by augmenting the vocabulary elements within with additional vocabulary elements defined for a particular industry or a set of users or a single user.

The CBV includes identifier syntax (URI structure) and specific vocabulary element values with their definitions for these Standard Vocabularies:● Business step identifiers● Disposition identifiers● Business transaction types● Source/Destination types● Error reason identifiers

The CBV provides identifier syntax options for these User Vocabularies:● Objects● Locations● Business transactions● Source/Destination identifiers● Transformation identifiers● Event identifiers

The CBV provides Master Data Attributes and Values for describing Physical Locations, Parties, and Trade Items, including Trade Item master data attributes at the GTIN level, lot level, and instance level.