Edit
Join the community
Join Beckn Open Collective
Join Beckn Open Collective
Edit
march 2024
beckn bengaluru meetup
Discord Github
Edit

Enabling Trusted Commerce using Beckn Protocol and Blockchain

keywords: decentralized commerce, trusted commerce, beckn protocol, blockchain, cord, verifiable credential, provenance, availability to promise

 

authors: amar tumballi ([email protected]), ravi prakash v ([email protected])

Introduction

Beckn is an open protocol to enable decentralized digital commerce by way of open and inclusive networks instead of closed platforms. Beckn protocol enables decentralized economic transactions beyond commerce, covering sectors like healthcare, mobility, travel and stay, and skilling and employment. Beckn is a semantic protocol that is agnostic of the underlying technology.

The blockchain technology provides enhanced trust to participants and their interactions on the chain.

This blog captures a demonstration of how beckn protocol can be adopted by a blockchain to provide decentralized digital commerce, and offer augmented trust on certain aspects of commerce interactions. The demonstration only attempts a sample set of use cases of trust with a sample business scenario but it showcases the possibility to extend this solution to multiple use cases for trust. Please see the section of future evolutions at the end.

The blockchain adopted for the demonstration is an open-source chain called CORD developed by Dhiway. CORD offers varied services to enhance trust to the economy interactions on the chain. This demonstration is a joint voluntary effort of Dhiway and Beckn Foundation along with few other volunteers from the beckn open community that supported the effort at different stages of implementation

A Business Scenario

There is a farmer in Shimla that owns an apple orchard. Every month, he farms 1000 kilos of genuine Shimla apples. He sells these apples to various retailers, big and small. The apples he produces are certified by various food certification agencies like FPO, FSSAI, Agmark etc. These retailers in-turn sell these apples to the end-consumers. The transactions between the farmer and retailer, and those between retailer and end-consumer happen through various e-commerce platforms.

A business transaction

Let’s consider the following scenario. Say, a typical end-consumer is searching for authentic Shimla Apples on their usual e-commerce app. Upon searching, they see a listing of retailers that sell “Authentic Shimla Apples” that claim to be sourced from genuine apple farmers based in Shimla. When viewed on the consumer’s application, the products show all the certifications (like the above) that have been issued to them.

He selects a retailer and adds a dozen Shimla Apples to his cart and does a checkout. The order is created and a short while later, he receives the product.

However, the buyer doesn’t really know whether the products he has ordered are really genuine Shimla Apples. The buyer has no choice but to trust the platform he is on, to ensure the quality of products being sold to them. Without a clear traceability to the manufacturer/producer, retailers can always sell fake Shimla apples with the same certifications attached. A typical consumer may not be able to tell the difference between a real Shimla Apple and a fake one.

 

Trust as it exists today is either broken, or concentrated in the hands of a few intermediaries

At the consumer-facing end, the users of these platforms have to trust the platform they are on, to offer only genuine, high-quality products and services. And at the provider-facing end, the platform must take the responsibility of ensuring genuineness and quality assurance of  products and services they are publishing in their catalog.

If a product or service turns out to be of low quality, or worse, fake, the consumer’s trust breaks. Post-facto, the consumer can always hold the platform responsible. And the platform could either replace the product, initiate a refund, or initiate a return. This incurs cost to the platform and thus can only be done by large platforms with sufficient resources to provide the trust. But, there is a risk that consumers may never trust the platform or the seller or both, ever again.

Introducing beckn protocol

Beckn protocol [1], is an open, interoperable and universal transaction protocol to enable a decentralized digital economy. It is a set of open interoperable specifications that helps re-imagine the world of consumer-provider transactions. The image below describes the 5-layered architecture of beckn protocol.

Beckn protocol fundamentally unbundles the idea of 2-sided platform-centric systems into multiple 1-sided platforms/apps forming an open network connected via the interoperable protocol layer. When implemented, this protocol allows consumers and providers to connect and transact with each other using any platform of their choice, thus creating a beckn-enabled network or simply, a beckn network.>

For more information on beckn protocol and its applications, visit https://becknprotocol.io.

In a beckn-enabled ecosystem

In a beckn-enabled ecosystem, the consumer exists on one platform to place orders for products and services published on a different platform via beckn protocol API calls. This forms a network of consumer-facing platforms also known as beckn application platforms or BAPs, and provider-facing platforms also known as beckn provider platforms or BPPs all using beckn protocol to do discovery, ordering, fulfillment and post-fulfillment of products and services.

Assuming this architecture, let us consider the following situation.

Let us assume that there are multiple consumer platforms and provider platforms, all talking to each other via beckn protocol. To facilitate trusted communication between these platforms, there is an open registry acting as a public key infrastructure (PKI) that stores public keys, endpoints, and other details of all the participants of the network. The sender digitally signs their messages using their private keys and the receiver looks up the public keys of the sender on the registry to digitally verify the signature. Hence, the registry acts as a trust infrastructure for inter-platform communication.

However, it does not solve the issue of ensuring authenticity of products, service providers and agents. Some of these credentials may be platform-specific like number of rides performed by a driver; number of 5-star ratings given to an agent. Others could be cross platform credentials like food quality certifications, safety certifications etc. Every time a service provider or an agent moves from one platform to another, their entire platform-specific reputation and credentials remain with the platform they were on and need to be built up again on the new platform. And the new platform again has the responsibility of ensuring that the products, services and agents on their platform are genuine.

Beckn with Blockchain

To ensure portable cross-platform credentialing of products, services and agents, an additional infrastructure layer must be added to store these credentials so that they can be verified by any platform on the network. However, if we use a platform to store these credentials, it is just shifting the trust up one level, from one platform to another. BAPs and BPPs will have to trust the platform as a single source for all the credentials. Due to the centralized nature of this credentialing infrastructure, beckn network participants may be wary of putting their trust on a single platform to store the credentials of every entity on the network. Furthermore, this also introduces a single point of failure that puts the burden of availability on the credentialing platform itself to always be available for storing and verifying credentials. Therefore a more robust system is needed that not only is highly available, but also where the trust comes via a logical consensus of multiple distributed entities as opposed to a single source of truth that the network participants have to implicitly trust. In short, there is a need for consensus rather than trust otherwise known as trustlessness.

One way to create a distributed, consensus-based infrastructure is to use a Distributed Ledger Technology like blockchain to store the credentials. A blockchain network uses consensus algorithms to ensure the truth comes from multiple platforms agreeing to a common output, thus creating a decentralized database of information. This ensures that the credentials being stored on a decentralized database are immutable and non-repudiable.

Such an infrastructure can be used for several advantages. Firstly, a retailer registered on a beckn-enabled network can only add products to his catalog that match the exact description of the product that the farmer intended to be sold to the end-customer.

Also, a retailer registered on a beckn-enabled network would not be able to add products to his catalog that are more than the quantity as purchased from the farmer.

Consumers will purchase these products via their network-verified apps. Just before placing the order, the consumer app will verify the authenticity of the product credentials by referring to the previous blockchain transactions.Once verified, the order is confirmed.

How it Works

Overview

In our implementation we have assumed a beckn-enabled network where there are consumer platforms, retail platforms and Manufacturer platforms.

Alongside the beckn-enabled network, there is a blockchain-based network that stores the identities and credentials of authorized participants. The semantic nature of beckn protocol allows beckn-enabled networks to be layered on any blockchain or DLT network.  In this article, we will use a reference blockchain network called CORD [2] to demonstrate a verifiable credential being created, stored and verified across a multi-network transaction. The CORD blockchain network enables the anchoring of tokenized transaction records and links to information objects that present a durable model for entities participating in the ecosystem. CORD enables discovery, access and acclaim records for various activities that relate to humans interacting with organizations, other individuals or machines. CORD provides the foundational layer of digital trust required to create a resilient, sustainable and economically viable ecosystem around authenticated data flows.

The Retail BAP [3], Retail BPP [4], Supply-chain BAP, and Supply Chain BPP are all registered on a blockchain as authorized entities that can transact on a network. This eliminates the need for a central network registry and therefore creates a trustless infrastructure for authentication and digital signatures.

In this example, a beckn-enabled network layered on top of CORD acts as a decentralized token store for verifiable credentials and registries. The decentralized nature of CORD and native implementation of beckn protocol specifications enables the end user application to verify the Availability-to-Promise (ATP) of products before ordering and trace its ownership all the way back to the manufacturer/producer irrespective of the number of intermediaries it has gone through.

In this example scenario, each beckn network participant i.e, Consumer Platforms, Retail Platforms and Supply-chain Platforms communicates with CORD via an API implemented at the CORD nodes

High level Flow (TL;DR)

Farmers will upload their products i.e “Shimla Apple” to their inventory on their Beckn-CORD-enabled Supply-chain application.

This application refers to the product schema reference stored on the CORD blockchain while uploading the object as per the prescribed product schema. The BPP will generate a unique hash of the product, its schema reference, and quantity, and send it to the CORD network. The CORD network chain nodes verify the product against the product schema and generate a unique block hash ID that represents the verifiable credential of the product. This ID is transmitted along with the product ID across the beckn-enabled network.

Retailers will place orders to these farmers via network-verified Supply-chain BAP apps to buy a specific number of units of genuine Shimla apples.

Farmers will sell their produce to retailers on Supply Chain BAPs via Supply-chain BPP applications. This happens via standard beckn APIs adopted by network participants.

Retailers add products that they have purchased from the manufacturers into their catalog. Due to their purchase reference being recorded on a blockchain, they are unable to upload more than the amount of units they have purchased from the retailer.

Consumers purchase these products from the retailer. The consumer app verifies the ownership of these products before placing an order.

Let us look at each of these interactions in more detail.

Retailer-Manufacturer Transaction

The farmer will have an application where he can see the orders he has received and allocate a specific number of authentic apples to each retailer. In the current implementation, authorized farmers and product schema used by each farmer has been pre-configured on the CORD blockchain.

The retailer has a beckn-CORD-enabled application that he uses to place orders from the farmers. Before placing the order, the retailer’s application verifies the ownership of the apples by calling the CORD network with the block hash ID and verifying if the farmer is truly the owner of those apples.

The flow can be summarized in the below diagram.

Consumer-Retailer Transaction

Now the retailer uses a typical retail store management application where he uploads the products (apples) he has purchased from the farmer to his own catalog for consumers to purchase. In this example, the particular retailer chooses to use a Magento-based seller application to manage his inventory and orders. When he uploads his product, he will not be able to upload more than the quantity (1000 units) he has purchased from the Manufacturer. Before uploading, his application calls the CORD blockchain with the product SKU ID and the quantity. The CORD blockchain nodes verify if the retailer is truly the owner of a 1000 units of Shimla Apples by calculating the hash of the product and comparing it with the hash stored on the chain. If he is not, the CORD network returns an error.

The consumer searches for these apples on his app.

And he sees genuine products with a green verified icon on the listing. All the products that have a block hash ID are treated as verifiable products as shown below.

Before placing the order, the consumer application first verifies if the genuine items are actually available in the retailer’s inventory. The chain nodes verify the availability using the previous blockchain transactions if the retailer truly has ownership of the genuine product. The state where a product is available for fulfillment before placing an order is called Availability to Promise (ATP). This prevents double selling or overblocking of inventory where a retailer claims to have more inventory available to sell so that they can get more orders. Once the ATP is verified, the BAP then fires a beckn protocol confirm API call to the Retailer BPP. The retailer BPP then transfers the ownership of the product to the consumer by calling an order.confirm remote procedure call on the CORD blockchain. This adds a ownership transfer record of a fixed amount of units from the retailer to the consumer on the blockchain. This record gets replicated across all chain nodes to ensure immutability. Now there is a non-repudiable claim to ownership of the genuine product by the buyer that the seller cannot refute. This improves the overall trust of the consumer towards the system and the seller.

Once done, the CORD blockchain will have transaction records like

Note

The CORD blockchain doesn’t store actual data but merely the hashes of the transactions to ensure privacy of the participants are protected. The creation of the hashes of the transactions still takes place on the network participant platform i.e BAP and BPP nodes. Such value exchanges augmented through the combination of off-chain verifiable credentials capturing the transaction details and on-chain verifiable proofs create a higher level of assurance for ecosystem participants.

As you can see, we have successfully managed to transmit a verifiable credential i.e the ownership of genuine Shimla Apples across two cascaded networks using beckn protocol and ensured its immutability using blockchain technology.

The entire integration of beckn-enabled networks on a blockchain can be summarized using the below transaction history on a blockchain.

Summary

Beckn protocol allows the unbundling of tightly coupled 2-sided platforms into a network of multiple 1-sided platforms. The inter-platform trust is established using a public key infrastructure that serves as a network registry. Blockchain or Distributed ledger technologies can increase this trust by allowing beckn-enabled networks to layer on top of blockchain networks. Furthermore, the layering of beckn and blockchain networks tremendously increases the consumer’s trust on the platform (BAP) where they’re buying products from especially when the inventory of products being bought are not managed on that platform. Similarly, due to the portability of these credentials, seller platforms do not have to re-verify credentials of an entity when they move from one platform to another.

The below table summarizes the difference between a beckn-network that is using blockchain versus a beckn-network that is not using blockchain in the example discussed in this article

These are just some of many possibilities that can emerge when layering beckn protocol networks on blockchain networks. Let us take a look at some ideas that we intend to implement going forward.

 

Future Evolution

This is just the beginning of beckn protocol’s ability to leverage advancements in the web 3.0 world, and we are already thrilled at the possibilities

Some of the use cases which we are working on imminently are as follows (in no particular order):

  • Executing a fully decentralized beckn protocol interaction on a blockchain
  • Building of identity registries (of entities like retailer, buyer, manufacturer, dealer, delivery partner etc etc), on the ledger/chain/network, so those who have access can co-relate entities in the transactions.
  • Build a Verifiable Credential based ecosystem making any product authentication made easy from the buyer.
  • Better anonymized reputation building system for retailers, buyers and other entities in the ecosystem by handling the rating system with more validations.
  • Possibility of having a token based economy tied to real-world use commerce transactions.
  • Creating of a blockchain-based dispute resolution system for beckn-enabled networks

References

[1] Beckn Protocol Specification

[2] CORD Network – Below links provide more information on the network

[3] Open-source BAP Reference app

  • Source-code for Retail BAP – Click here
  • Source-code for Supply BAP – Click here
  • Retail BAP:live demo: Click here
  • Supply Chain BAP live demo: Click here

[4] Open-source BPP Magento Extension

  • Source-code for Retail BPP – Click here
  • Source-code for Supply-chain BPP – Click here
Linkedin Twitter