client-spec

Use Cases - EEA Tech Specs

Status of this Document

This is a draft document for consideration by the Core Specification Working Group of the Enterprise Ethereum Alliance (EEA). It is work designed to inform technical discussion. This document is unfinished, and it is inappropriate to cite this other than as “work in progress” or a “working document”.

A future version of this document might be published as an EEA publication.

This document is copyright &copy 2018-2022 Enterprise Ethereum Alliance Incorporated (EEA). It is made available under the terms of the Apache License version 2.0.

Contents

Introduction

This document describes use cases that inform the work of the EEA’s Core specifications Working Group. They are based on real cases customers are interested in solving. They have been anonymized, so may be slightly more generic. They are intended to provide a reference to ensure the Working Group is addressing the identified needs of customers.

How to Read a Use Case

Each use case describes the expected participants, how they are distributed geographically, whether they are known to and trusted by each other, and some features of the network they expect to use.

This is followed by a brief description of the Use Case, and then requirements that will need to be met for the Use Case to be viable.

Requirement Categories

Each Use Case lists a set of “Basic Requirements”, annotated with a category, such as

[CATEGORY: Privacy] The system MUST warn against adding personally identifiable information
	to a transaction.

These categories loosely correspond to categories of requirements in the EEA Enterprise Ethereum Client Specification. When proposing a new Use Case, new categories can be added as relevant.

[CATEGORY: Crosschain Interoperability]

This is a requirement that is based on operations that require coordinated interaction between two or more blockchains, such as transferring a token from one to another, or enabling a smart contract on one blockchain to call a function in a smart contract deployed on a different blockchain. The EEA Crosschain Interoperability WG is developing standards to enable this functionality.

[CATEGORY: Performance]

These describe approximate performance requirements to meet the Use Case. Some Use Cases can be easily fulfilled if a blockchain processes as few as 10 transactions per hour, others require scalability to thousands of transactions processed per second.

[CATEGORY: Permissioning]

These refer to the use of permissioning to manage access to and control of Enterprise Ethereum Permissioned Blockchains. This is defined in the EEA Enterprise Ethereum Client Specification.

[CATEGORY: Privacy]

The EEA Enterprise Ethereum Client Specification defines mechanisms such as Private Transactions, to enable interaction with Blockchains to preserve privacy, for example because it is a customer requirement for a Use Case, or a legal requirement such as GDPR or for a specific industry.

[CATEGORY: Resilience]

These refer to requirements for the blockchain to continue to function adequately, in the face of either equipment failures or malicious attacks.

[CATEGORY: Scalability]

Requirements for the blockchain to scale to a certain size, for example number of Nodes or number of active accounts.

Contributing Use Cases

The Working Group welcomes contributions of new Use Cases from EEA members, either through its Github repository as issues or Pull Requests, or from direct participation.

Use Cases should not identify a specific customer, but should be based on real proposals or requests.

International payments

(p2p, b2b, cash management)

Participants
Multiple subsidiaries of the same bank
Trust
Participants trust each other but still need to operate at arm’s length
Geographies
Global
Network
Private, operated entirely inside bank firewalls

Description

Multiple subsidiaries of the same bank facilitate clients making international payments between those subsidiaries. This requires existing core bank systems (CBSs) to be connected to the blockchain through an API, and an interface that detects movements of funds in the CBSs and creates tokenized versions of those real world assets. The tokens can then be transferred from one bank to another through a smart contract that can determine real-time foreign exchange rates and orderbook.

Basic Requirements

National-level Smart Contracts Platform

Participants
Multiple companies and government entities in a single country
Trust
Participants are known but do not trust each other
Geographies
Single country
Network
Publicly accessible with permissioned validators

Description

A government-sponsored smart contracts platform for a single country. The initial use case would be to support a national-level identity scheme that already exists in partnership with public notaries. Certain information will be shared privately between parties to a transaction.

Basic Requirements

X-Value Adjustment

Participants
Counterparties within derivatives deals
Trust
Business partners have some element of this each other but still need to operate at arm’s length, sometime via centralised institutions
Geographies
Euro-clearing area
Network
Private, operated within the derivative liquidity pool shared by trading houses

Description

Using a distributed ledger with smart contracts capability to connect multiple business units trading derivatives, across European region to facilitate clients hedging or actively trading X-Value Adjustment positions. Such a system would require existing core systems to be connected to the blockchain through an API and an interface that calculates, analyses, and limits exposures across entities, minimizing capital charges for Basel III compliance. An added benefit is fast accurate detections of movement in PFE, COLVA, and so on. In this process we would create tokenized versions of those real world assets, which can in turn be then valued in a cryptocurrency. Transfer would occur from one participant to another through a set of smart contracts that contains real-time foreign exchange rates and an OTC orderbook or trade ledger. A clearing fund will be provided for unmargined derivatives.

Basic Requirements

Illiquid Securities Management

Participants
Investment Banks, Asset Management, Hedge Funds, Prime Brokerage, Family Offices & Pension Funds
Trust
Investment Banks will set up a private permissioned network for the Buy Side Community to invest & manage illiquid securities lifecycle management
Geographies
Regional
Network
Private, operated entirely inside bank firewalls

Description

Using a distributed ledger with smart contracts capability to create a marketplace or ecosystem to manage the illiquid securities between the investment communities. The solution would require existing trading and securities back office system to be connected to the blockchain through an API and an interface that detects movements of illiquid securities in the distributed ledger ecosystem, which is in the form of tokenized assets that can be transferred from one bank to another through a smart contract that contains real-time valuations, orderbook, trade book, and positions.

Basic Requirements

Inter-library Loan

Participants
Municipal, university, corporate and private libraries
Trust
Libraries need to have security over their own resources. As these are increasingly digital, they are under a variety of obligations to demonstrate that they are not replicating resources beyond the terms of their license for content.
Geographies
Global
Network
Publicly Accessible, needs a trusted but minimal-cost validation

Description

Inter-library loans are a long-standing part of library management. Essentially, libraries enter into multi-lateral arrangements allowing their members borrowing rights from participating libraries. As library holdings are increasingly digital, or digitized to reduce the cost of delivery, libraries are under increasing obligations to demonstrate that they are only making available material under the terms of their licenses. In particular, they often need to keep track of how many digital copies are on loan, and not exceed a given number at any time.

Basic Requirements

Anonymous Voting System

Participants
Ballot callers, Voters, and Result reporters
Trust
When a ballot is called, voters require trust that their individual vote choice will not be be revealed. Result reporters need to trust the voter authentication and the overall result.
Geographies
Global
Network
Publicly Accessible, ability to authenticate voters

Description

An anonymous voting system requires that the identity of a voter cannot be correlated to their vote, and that when the Result reporters get the results they can be trusted.

Ballot callers can create a ballot and have voters notified the voting period is open. Once the voting period closes, the tally information is available, without revealing (or making it possible to identify) individual votes.

Basic Requirements

Supply Chain Consortium

Participants
Suppliers, Bidders
Trust
Bidders must enjoy complete privacy when placing bids with each supplier. All transactions must occur in private with no knowledge of transactions between suppliers.
Geographies
Global
Network
Permissioned, with strict views of private data for each bidder and supplier.

Description

A supply chain consortium consists in a group of suppliers vying for the business of bidders. Bidders place bids and product orders against manufacturers, and use structured processes to manage the lifecycle of an order. The consortium aims to regulate the processes by which bidders can automate their supply chain audit requirements.

Basic Requirements

PvP Payments

(p2p, b2b, cash management)

Participants
Multiple financial institutions
Trust
Participants trust each other but still need to operate at arm’s length
Geographies
Global
Network
Private, multiple networks for different currencies

Description

Participants are members of multiple tokenized cash networks and want to be able to perform PvP trades where one cash instrument is exchanged for another. This entails a cross-chain transaction using an interoperability protocol to atomically settle the transaction. Participants use a private P2P messaging layer to exchange information around a trade ensuring that sensitive data is not stored on the blockchain.

Basic Requirements

Validator Set Management

Participants
Potential validator node operators
Trust
Some trust is required by the network participants since validators have limited power over the network such as censoring transactions as well as changing the order of transactions (before they are included in a block, and for different signing accounts)
Geographies
Any
Network
Private, Proof of Authority

Description

In Proof of Authority (POA) based blockchain networks a set of validators are responsible for collecting transactions and including them in blocks in an orderly and regular fashion. The communication between the set of validators consumes a portion of available network bandwidth such that beyond a certain number (let this be X) of validators the performance of the blockchain network will start degrading.

In addition, certain blockchain networks will have a set of potential validator nodes that is larger than X. In order to distribute the responsibility for (orderly and regular) production of blocks, the potential validator nodes that are non-validating need to be included in the active set of validators. In addition, a select number of the validator nodes need to be excluded from the set of active validators so that the number of actively validating nodes remain below or equal to X.

Therefore, there is a need to be able to change the currently active validator set in an orderly fashion from the set that is currently active, to a set that includes currently non-validating nodes and excludes some/all currently active validator nodes.

Basic Requirements