Thread by @mrauchs

1/ Let's get to the core of the report today; namely the conceptual framework that breaks down a #DLT system into distinct pieces in order to better understand the relationships between its elements.

Full report: jbs.cam.ac.uk/faculty-resear…

Alternative link: papers.ssrn.com/sol3/papers.cf…

2/ Speaking of elements: the framework consists of three types: layers, components, and processes.

Each layer is composed of a set of components, and each component comprises a set of processes.

In total, we identify 3 layers, 7 components, and 18 processes.

3/ Let's start with the base layer - the protocol layer.

The protocol layer is the foundation of the entire DLT system: it defines the set of formal rules that governs the system and codifies its architectural design.

4/ Next, we have the network layer.

The network layer is composed of a set of interconnected actors that collectively store, share, and process data. It is the practical implementation of the protocol rules.

5/ The top layer is referred to as data layer.

The data layer refers to the information processed and stored by the DLT system in the form of records. The data layer is at the core of the functionality the system delivers, i.e. provide an authoritative version of shared records.

6/ So, to sum up:

(1) The protocol layer defines, manages, and updates the global ruleset that governs the system.

(2) The network layer implements the ruleset and performs the steps required to reach system-wide consensus.

7/ And...

(3) The data layer specifies the nature and meaning of the data over which agreement is reached.

8/ I won't go into the components and processes in detail today; I will simply mention that Section 5 provides a broad (although certainly non-exhaustive) overview of potential configurations for a specific process.

9/ This means that we provide a list of possible arrangements ('configurations') for each process that are commonly found in existing and/or planned DLT systems.

To give you an example, please see the configuration table for the 'Protocol Governance' process below.

10/ Some processes are so broad in nature that we have added additional 'lenses' that can be used to examine the process in greater detail (e.g. 'Protocol Change' process below).

11/ We attempted to keep the framework as generic as possible so it can theoretically be applied to any type of shared (or even fully closed, internal!) recordkeeping system.

12/ Similarly, we tried to keep the framework flexible so others could add new elements and configurations without affecting its core skeleton.

As a result, new elements (layers, components processes) and configurations might be added in the future as new developments emerge.

13/ The full framework (including a short explanation of each process) is summarised in the table below.

14/ Remember that we're using a systems perspective throughout the report? Tomorrow, we'll have a look at systems interactions:

(a) Within the system boundaries (i.e. between layers & other elements)

(b) Beyond the system boundaries (i.e. with other systems)