ETSI GR PDL 003 V1.1.1 (2020-12)

Permissioned Distributed Ledger (PDL); Application Scenarios

DGR/PDL-003_App_scenarios

General Information

• Status: Not Published
• Technical Committee: PDL - Permissioned Distributed Ledger
• Current Stage: 12 - Completion
• Due Date: 15-Jan-2021
• Completion Date: 18-Dec-2020

Standards Content (Sample)

GROUP REPORT
Permissioned Distributed Ledger (PDL);
Application Scenarios
Disclaimer
The present document has been produced and approved by the Permissioned Distributed Ledger ETSI Industry Specification
Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GR PDL 003 V1.1.1 (2020-12)
Reference
DGR/PDL-003_App_scenarios
Keywords
ledger, use case
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: [phone]  Fax: [phone]
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© ETSI 2020.
All rights reserved.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI GR PDL 003 V1.1.1 (2020-12)
Contents
Intellectual Property Rights . 7
Foreword . 7
Modal verbs terminology . 7
1 Scope . 8
2 References . 8
2.1 Normative references . 8
2.2 Informative references . 8
3 Definition of terms, symbols and abbreviations . 9
3.1 Terms . 9
3.2 Symbols . 9
3.3 Abbreviations . 9
4 PDL Reference Framework . 10
4.1 Introduction . 10
4.2 Definition of PDL . 10
4.3 Abstract PDL Architecture . 11
4.4 PDL Platform Governance and Management . 12
4.5 Stakeholders . 13
4.6 PDL Platform Abstraction Layers . 14
5 The infrastructure Layer . 15
5.1 ICT Verticals . 15
5.2 The Connectivity Vertical . 16
5.2.1 Introduction to the Connectivity Vertical . 16
5.2.2 Accessibility . 16
5.2.3 Availability . 16
5.2.4 Integrity . 16
5.2.5 Confidentiality . 16
5.2.6 Quality . 16
5.3 The Compute Vertical . 17
5.3.1 Introduction to the Compute Vertical . 17
5.3.2 Jurisdiction . 17
5.3.3 Privacy and Confidentiality . 17
5.3.4 Availability . 17
5.3.5 Integrity and Security. 17
5.3.6 Compute Device Characteristics . 17
5.4 The Storage Vertical . 17
5.4.1 Introduction to the Storage Vertical . 17
5.4.2 Per node storage . 17
5.4.3 Off-Chain storage . 18
5.4.4 Jurisdiction . 18
5.4.5 Privacy and Confidentiality . 18
5.4.6 Availability . 18
5.4.7 Integrity and Security. 18
5.4.8 Storage Characteristics . 18
6 Horizontal Integration . 18
6.1 Definitions . 18
6.2 Similarities and differences between PDL and Legacy Databases/Ledgers . 19
6.2.1 Introduction to comparative discussion of PDLs and Legacy Databases/Ledgers . 19
6.2.2 Consensus Mechanisms . 19
6.2.3 Basic Blockchain Operation . 19
6.2.3.1 Discussion of basic Blockchain operations . 19
6.2.3.2 Capture data transactions . 19
6.2.3.3 Hashing the block . 19
6.2.3.4 Chaining blocks . 20
ETSI
4 ETSI GR PDL 003 V1.1.1 (2020-12)
6.2.3.5 Reading data from blocks . 20
6.2.4 Other Blockchain Operations . 20
6.2.4.1 Discussion of other Blockchain operations . 20
6.2.4.2 Smart Contracts . 20
6.2.4.3 Zero Knowledge Proof (ZKP) . 20
6.2.4.4 Forks . 20
6.2.4.4.1 Discussion of Forks . 20
6.2.4.4.2 Incidental Forks . 21
6.2.4.4.3 Intentional Forks . 21
6.2.4.4.4 Hard Forks . 21
6.2.4.4.5 Soft Forks . 21
6.2.5 Data storage and Privacy concerns . 21
6.2.5.1 Discussion of Privacy concerns . 21
6.2.5.2 Competition . 21
6.2.5.3 Geography . 21
6.2.5.4 GDPR . 21
6.2.5.5 Storage in the Cloud and On-Premise . 22
6.2.6 Data Interfaces . 22
6.2.6.1 Introduction to Data Interfaces . 22
6.2.6.2 Application to PDL . 22
6.2.6.3 PDL node to Storage . 22
6.2.6.4 Node to Node . 22
6.2.7 Data Operation and Management . 23
6.2.7.1 Introduction to Data Operation and Management . 23
6.2.7.2 Membership Management . 23
6.2.7.3 Governance . 23
6.2.8 Non-Permissioned/Permissionless Ledgers . 25
6.3 Platform Management . 25
6.3.1 Inter-Node Communications . 25
6.3.2 Node Management . 25
6.3.2.1 Node management consideratons . 25
6.3.2.2 Hardware resource management . 25
6.3.2.3 Software resource management . 26
6.3.2.4 Storage resource management . 26
6.3.2.5 Node-Level Governance management . 26
6.3.3 Network resource management . 27
6.3.3.1 Bandwidth Management . 27
6.3.3.2 Performance Management . 27
6.3.3.3 Governance . 27
6.3.3.4 Inter-Node Network Management . 27
6.3.3.5 Inter-Node Network Management . 27
6.3.4 Identity Management . 27
6.3.5 Inter-Ledger Management . 28
6.3.6 Inter-Layer Management . 29
6.4 General Considerations . 29
6.4.1 Security . 29
6.4.2 Economic Incentives . 30
6.4.3 Operational Incentives . 30
6.4.4 Disintermediation . 30
6.4.5 Identity Sovereignty . 30
7 Integration Layers and Applications . 31
7.1 Introduction to Integration . 31
7.2 Templates . 31
7.2.1 Template considerations . 31
7.2.2 Applications . 31
7.2.3 APIs . 31
7.2.4 Common Functions . 31
7.2.5 PDL Implementations . 31
7.2.6 Platform management and Governance . 32
7.2.7 Infrastructure . 32
7.2 PDL Middleware . 32
ETSI
5 ETSI GR PDL 003 V1.1.1 (2020-12)
7.2.1 PDL-Application abstraction . 32
7.2.2 Application-Application abstraction . 32
7.2.3 PDL-PDL abstraction . 33
7.3 Platform APIs . 33
7.4 Service and Ecosystem APIs . 34
7.5 PDL-based Retail Applications . 34
7.6 PDL-based Wholesale Applications . 34
7.7 Interactions between PDL-based Wholesale and Retail applications . 35
8 Permissioned Distributed Ledger Governance . 35
8.1 The need for Governance . 35
8.2 Governance Methods and Structure . 36
8.3 Governing the Governance . 36
History . 38

ETSI
6 ETSI GR PDL 003 V1.1.1 (2020-12)
List of Figures
Figure 1: Abstract PDL Reference Framework .11
Figure 2: Simplified Functional PDL Reference Framework .12
Figure 3: PDL Reference Framework .15
Figure 4: The Infrastructure Layer .16
Figure 5: Architecture of Standards Governance .24
Figure 6: Inter-Ledger Management .28

ETSI
7 ETSI GR PDL 003 V1.1.1 (2020-12)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Permissioned Distributed
Ledger (PDL).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
8 ETSI GR PDL 003 V1.1.1 (2020-12)
1 Scope
The present document describes Permissioned Distributed Ledger Application Scenarios. The aim is to consider and
describe the potential application scenarios for the operation of PDLs, including provision models with special
emphasis on as-a-service paradigms, and PDL infrastructure governance aspects. The present document provides
definition of terms to be used in the scenarios and recommendations for future normative specifications.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ISO TC307: "Blockchain and distributed ledger technologies".
[i.2] ISO 22739: "Blockchain and distributed ledger technologies -- Vocabulary".
[i.3] Recommendation ITU-T SG13: "Future networks including cloud computing, mobile and next-
generation networks".
[i.4] ETSI GR PDL 001: "Permissioned Distributed Ledger (PDL); Landscape of Standards and
Technologies".
[i.5] ITU-T Technical Specification FG DLT D1.1: "Distributed ledger technology terms and
definitions", Definition number 6.22 "Fork".
[i.6] ITU-T Technical Specification FG DLT D1.1: "Distributed ledger technology terms and
definitions", Definition number 6.25 "Hard Fork".
[i.7] World Economic Forum (04/2020): "Inclusive Deployment of Blockchain for Supply Chains:
Part 6 - A Framework for Blockchain Interoperability".
NOTE: Available at https://www.weforum.org/whitepapers/inclusive-deployment-of-blockchain-for-supply-
chains-part-6-a-framework-for-blockchain-interoperability.
[i.8] Jennifer J.Xu.:"Are blockchains immune to all malicious attacks?".
NOTE: Available at https://jfin-swufe.springeropen.com/track/pdf/10.1186/s40854-016-0046-5.
[i.9] Aljosha Judmayer, Nicholas Stifter, Alexei Zamyatin, Itay Tsabary, Ittay Eyal, Peter Gaži, Sarah
Meiklejohn, Edgar Weippl: "Pay-To-Win: Cheap, Crowdfundable, Cross-chain Incentive
Manipulation Attacks on Cryptocurrencies".
NOTE: Available at https://eprint.iacr.org/2019/775.pdf.
[i.10] ETSI GR PDL 004: "PDL: Smart Contracts Permissioned Distributed Ledgers System
Architecture and Functional Specification".
ETSI
9 ETSI GR PDL 003 V1.1.1 (2020-12)
[i.11] ETSI GR PDL 006: "Permissioned Distributed Ledger (PDL); Inter-Ledger Interoperability".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
API Gateway: API management tool that sits between a client and a collection of backend services and acts as a
reverse proxy to accept all Application Programming Interface (API) calls, aggregate the various services required to
fulfil them, and return the appropriate result ®
NOTE: See Red Hat at https://www.redhat.com/.
chain: collection of PDL records concatenated to each other through a unique format and a specific order that may vary
depending on PDL type
common functionalities: such functionalities that offer similar or same behaviour across multiple applications
core functionalities: such functionalities that exist in all applications
fork: occurence where a single blockchain is split into two or more separate blockchains by having different blocks
appended to it. Once Forked, each blockchain becomes an individual Chain
node: device (real or virtual) that transacts on a Chain
omni-Lateral: PDL that all (Omni) nodes in a platform participate in
PDL Platform: collection of Nodes transacting in a coordinated manner on one or more Chains
PDL Type: PDL variations by Functional components such as Chain structure, Consensus mechanism, Publicity,
Implementation, Security, Discoverability
Permissioned Distributed Ledger (PDL): distributed Ledger that maintains access control to allow certain actions to
be performed only by certain identifiable participants
NOTE: See clause 4.1 of the present document.
transacting node: node that transacts on a PDL but does not participate in a Consensus Vote
validating node: node that participates in a Consensus vote
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AML Anti-Money Laundering
API Application Programmable Interface
AS Autonomous System
BGP Border Gateway Protocol
CPU Central Processing Unit
DLT Distributed Ledger Technology
DNS Domain Name Service
ETSI European Telecommunications Standards Institute
EU European Union
GDPR General Data Protection Regulation
ETSI
10 ETSI GR PDL 003 V1.1.1 (2020-12)
GPS Global Positioning Service
GR Group Report
GUI Graphical User Interface
HR Human Resources
ICT Information and Communications Technology
IP Internet Protocol
ISG Interim Study Group
ISO International Organization for Standardization
IT Information Technology
ITU International Telecommunication Unit
ITU-T ITU Telecommunication standardization sector
KYC Know Your Customer
MVP Minimum Viable Product
NAS Network Attached Storage
OS Operating System
OSI Open Systems Interconnection
P2P Peer-to-Peer
PDL Permissioned Distributed Ledger
RAID Redundant Array of Independent Disks
RAM Random Access Memory
SATA Serial Advanced Technology Attachment
SHA Secure Hash Algorithm
SLA Service Level Agreement
SMS Short Message Service
SWIFT Society for Worldwide Interbank Financial Telecommunication
TCP Transmission Control Protocol
TLS Transport Layer Security
TPS Transactions Per Second
VM Virtual Machine
WEF World Economic Forum
ZKP Zero Knowledge Proof
4 PDL Reference Framework
4.1 Introduction
Chains differ from one another by multiple dimensions, such as consensus mechanism, transaction rate,
programmability (through smart contracts), tamper-immunity and many others. The present document does not intend
to compare different chain types nor is it the intention here to make a recommendation of a specific, or group, of chains.
The commonalities are that PDL platforms can be Manageable and Governable, have to be Accessible by Applications
and Services through APIs, and could, depending on DLT type, be programmable through Templates (that may be
dependent on chain type).
4.2 Definition of PDL
PDL is a Distributed Ledger architecture offering modular possibilities with permission based processes.
Permissioned Distributed Ledger are commonly divided into two different approaches:
a) Public Permissioned Distributed Ledger.
b) Private Permissioned Distributed Ledger.
The operational scenarios of such ledgers are discussed in greater detail in clause 6.2.3 of the present document and can
be generally defined as follows:
• Public PDL scenarios operate with no restrictions once an acceptance process is completed. Such process is
part of the governance and operation of a DLT, which also include other policies with the aim to provide
trustworthiness and a public or general-purpose service.
ETSI
11 ETSI GR PDL 003 V1.1.1 (2020-12)
• Private PDL scenarios allow access to select members that have passed a certain selection criteria defined
through the governance structure, and are aimed for a private or a specific purpose service.
4.3 Abstract PDL Architecture
In order to provide a basis for discussing various PDL Application Scenarios, an abstract, simplified, reference
framework and functional diagram is used. Figure 1 herewith defines the three abstract layers that appear in most PDL
implementations. They are discussed here one by one, as well as the relations and dependencies therein.

Figure 1: Abstract PDL Reference Framework
The Applications and Services layer represents the actual customer/consumer facing application, be that consumer an
individual accessing the PDL platform through a portal or an application, or another platform/device accessing the PDL
platform through an API or other means of electronic transactions. Depending on PDL type, an application can be
implemented as a smart contract, as an external code/application (which may be platform or operating system specific
e.g. mobile phone, desktop computer, IoT device) or as a mix of both.
It is beyond the scope of the present document to discuss the applications themselves and the methods by which they
interface (northbound) with the customer/consumer.
Applications would require exchange of information with the PDL Platform itself, possibly more than one PDL,
through a southbound interface. Such PDLs may be developed and operated by different entities.
APIs and Tooling layer allows interaction between the applications/services and the PDLs. This layer is referenced by
ISO as the API Layer. For consistency, the present document follows the term used by the EU Blockchain Observatory
and Forum. This layer allows abstraction of the PDL Platform and Application layers in a manner that may allow
applications to operate on more than one PDL Type and vice-versa. This layer consists of consoles, dashboards, and
development environments made available to developers, institutional users, auditors and regulators.
The PDL Platform layer contains the PDL nodes as well as smart contracts, management and governance tools, and
other software elements that are embedded into code running on the PDL nodes. The PDL platform may use any of the
multitude of PDL types available at the time and may use governance and management tools that are
compatible/interoperable with said PDL Type.
In certain scenarios, specifically when the application is embedded into the PDL platform (e.g. as a smart-contract) and
the users interface the PDL Platform layer directly, the Application and/or API layers may not be required.
Examples would be:
1) Scheduled actions taken without external intervention occur on the PDL Platform layer and do not require the
API and Application layers.
2) A smart contract in a PDL platform that can be accessed through an API through a third party application (e.g.
wallet) that is not part of the PDL platform itself.
ETSI
12 ETSI GR PDL 003 V1.1.1 (2020-12)
4.4 PDL Platform Governance and Management
The Abstract PDL platform architecture discussed in clause 4.3 is enhanced by additional Governance and Management
functionalities as depicted in Figure 2 herewith.

Figure 2: Simplified Functional PDL Reference Framework
The major difference between the abstract diagrams depicted in Figure 1 and Figure 2 is the separation of the
Infrastructure from the PDL Platform, and the addition of a Management and Governance Support functionality.
The Platform is managed and governed through various methods, that may vary by PDL type, consensus mechanism
and application.
The Platform Management and Governance Support functionality allows the continued operation of the entire
platform by ensuring resources are available, governance requirements are met, and the PDL is operating in good order
(e.g. no forks, a sufficient number of validating nodes are in operation, etc.). Governance can be implemented in
multiple forms. In certain scenarios it can be implement through a hierarchical structure where a top-level entity
governs the behaviour of the lower levels. In other scenarios there may be no hierarchy and governance is applied
through consensus between equal-level entities. There are also hybrid models in existence where a human board of
elected or appointed directors defines the rules of operation and the governance structure implements the same. This is
discussed in greater details in clause 6.3 herewith.
ETSI
13 ETSI GR PDL 003 V1.1.1 (2020-12)
The Infrastructure: PDL platforms require computing, storage and communication infrastructure. The computing
resources would typically be off-the-shelf blades, and in most cases can be implemented as VMs or containers in private
or public clouds. It would be worth mentioning here that certain permissionless distributed ledgers require that the node
is owned, operated and in-house by its user. This is not necessarily the case for permissioned distributed ledgers that the
present document is about. Such nodes can, subject to regulations and respective policies, be operated in public cloud.
Storage requirements depend on the choice of PDL, as well as the requirements of the applications. PDL platforms
today typically use best-effort networks such as the public Internet as the means of communication between nodes and
between users to the PDL platform. Future scenarios may introduce the need for managed communications between
nodes in order to ensure predictable and secured performance.
Templates: Certain core and common functionalities, such as Identity, smart contracts, assurance, are defined as
Templates that may be re-used and integrated with repetition in multiple instances and aspects. Templates are ready-to-
use PDL implementations or functionalities that can be applied as needed. The may be implemented in multiple layers.
This is a useful functionality that may serve, in certain scenarios, as a presumption of conformity with certain
guidelines, requirements or specifications. Templates are not specific to a PDL layer. Examples of templates would be:
Cyber-Security Type approval for a vehicle, Security and Privacy specifications for data storage, Commercial
Reconciliation rules for bilateral settlement. The Identity of a person or an entity may be used in multiple applications
and will preferably be presented in a common way regardless of the application and ledger. Templates are discussed in
further details in clause 7.2 herewith.
4.5 Stakeholders
A PDL application may involve one or more of the below Stakeholders:
• End Users:
- Humans. Individuals or groups of people that use a PDL application.
- Machines (e.g. an application accessing a PDL without human intervention).
• Platform Operators:
- PDL. A PDL can operate autonomously during certain phases of its lifecycle.
- Management (e.g. governance, board). A PDL may be managed trough an internal/external governance
structure.
- Auditor/Monitor. A PDL may be monitored and audited for puposes.
• Software Vendors:
- PDL developers. Software vendors who develop PDLs.
- Application developers. Software vendors who develop applications that use PDLs.
• Infrastructure vendors:
- Cloud. Vendors providing cloud infrastructure used to host PDL nodes or store PDL data.
- Connectivity:
 Fixed. Operators providing fixed/physical infrastructure used to convey information between PDL
nodes, applications and users.
 Mobile. Operators providing wireless/mobile infrastructure used to convey information between
PDL nodes, applications and users.
• Regulatory and Governance Authorities:
- Regulator. An entity or individual that regulates the behavior of a PDL during its lifecycle.
- Legislator. An entity or individual that defines the rules and legal terms that a PDL applies to.
- Auditor/Monitor. An entity or individual that Audits/Monitors the behaviour and activity of a PDL and
indicates if a PDL is operating normally or not.
ETSI
14 ETSI GR PDL 003 V1.1.1 (2020-12)
- Authenticator. An individual or entity that authenticates validity of actions or other entities/individuals.
• Business Ownership and management:
- Standard bodies. Industry associations or collaborative groups that are recognized as standard defining
organizations.
Figure 3 herewith illustrates an evolved approach to a PDL platform that is agnostic to PDL types, application types,
and thus can be the basis for an open eco-system. Certain application scenarios require PDL-type agnosticism. Such
agnosticism applies to any unique chain that is subject to different operational scenario than other chains (e.g. different
PDLs based on Ethereum chains will be considered different PDL Types). That would typically be the case in eco-
systems where multiple, sometimes competing, entities use PDL in a federated wholesale supply chain. It may be
impossible, or operationally/commercially non-plausible, to enforce the use of a specific PDL Type for an application.
As depicted in Figure 3, the Distributed Ledger Platform may consist of multiple PDLs which are managed via the
functionality of the Platform Management and Governance Support layer and synchronized in a manner that allows
PDL-Type-agnostic applications to operate. Depending on the PDL types involved the Platform Management and
Governance functionality may be broken down to sub-elements each managing a specific PDL type. Certain scenarios
may also include PDL hierarchy (e.g. one PDL encompassing multiple PDLs). The Platform Management and
Governance would then typically be structured in a manner that supports such scenarios.
User access to the PDL platform may be performed, depending on PDL type and design, either directly to the PDL via
an API or through an external application.
Certain eco-systems, such as supply chain management platforms, may require a Distributed Ledger Platform that
supports simultaneous use of both bilateral PDLs and Multi-Lateral/Omni-Lateral PDLs (also referred to as Shared
Ledgers [i.1] and [i.2]) in tandem. While it is operationally and contractually simple to require that both parties in a
bilateral arrangement use the same type of PDL, it may be complex (and in certain cases impossible) to enforce the use
of a specific PDL in a multilateral environment where multiple entities, often competitors, operate. In such cases it is
the task of the Platform Management Support function to enable inter-PDL-Type and inter-chain (in cases of multiple
chains of the same PDL type) interoperability. This includes periodical synchronization between PDLs and chains at a
frequency that meets the requirements of the respective applications. The operational overheads and required
performance of such platform requires ca
...