Blockchain DApp for Wastes Tracking Developer Guide

Design and architecture

EFPF waste tracking application architecture

Figure 2: EFPF waste tracking application architecture

DApps:

An application can be built in any language you prefer. It can override the EFPF Registration/Login Process and connect directly to the three APIs to their Endpoints. The applications must deploy a registration form that will publish the user information to the Identity API, a login screen that will communicate with the Identity API, a service for producing valid JSON objects to communicate with the supply chain and/or logging APIs.

EFPF Platform and Data Spine:

These components act as an entry point and a communication layer respectively. They can be omitted in case someone develops their own solution. They are replaced by your custom applications. Identity API: The Identity API supports user registration and login processes. When a user logs in to the system, they are given the ability to interact with the Supply-Chain and the Logging APIs in order to immutably record their transactions through valid JSON objects.

Supply Chain and Logging API:

These APIs are responsible for interfacing the DApps with the backend blockchain nodes and the smart contracts for adding permanent records on the blockchain. Through JSON objects that are validated at the endpoints the user can digitally sign and add their records on the ledger and receive a unique ID for each record. In cases of dispute or request for proof, these records can act as the single point of truth.

EFPF Blockchain Servers:

The backend system is formed by Sawtooth nodes that use a permissioning system for granting writing rights to the EFPF users. The network is consortium based and all the nodes must validate every transaction and come to a consensus in order to accept it.

Next