1/ Today, I'd like to share some of the highlights in Section 2 of our new report on #DLT systems (available here: papers.ssrn.com/sol3/papers.cf…).
We will provide a formal definition of a DLT system and explain some of the key concepts.
We will provide a formal definition of a DLT system and explain some of the key concepts.
2/ Before diving into the key concepts, it is important to understand that unlike 'traditional' databases, DLT systems are designed to operate in an adversarial environment. 
3/ That doesn't necessarily mean that there are adversaries actively trying to attack or sabotage the system; rather, a DLT system should be designed to tolerate the potential presence of malicious actors - to a certain extent.
4/ We refrain on purpose from using a specific data structure (e.g. #blockchain) in the formal definition. Note that we also don't make 'immutability' or, more accurately, tamper resistance a condition.
5/ The reason for the latter is that many current DLT systems that have been deployed (both permissioned and permissionless) cannot be considered tamper-resistant; they are merely tamper-evident.
6/ We also provide a list of properties that an 'ideal' DLT system should be capable of ensuring. Note that many systems labelling themselves "DLT" do not currently satisfy all properties. They may, however, do so in the future.
7/ Given the business requirements of certain use cases in an enterprise context, it is questionable whether these properties are indeed desirable.
8/ Now moving over to the key concepts. We attempt to provide a common terminology that is used throughout the report.
Please note that the following terms are used outside their "accounting" meaning.
Please note that the following terms are used outside their "accounting" meaning.
9/ We use these terms according to the extent that transaction data has been accepted, processed, and validated by the network as a whole.
10/ An alternative representation with additional explanations:
11/ At the heart is the 'ledger' concept, the primary output of the system. A common misconception is to think that this 'ledger' is something tangible of which every node keeps a copy.
12/ Instead, each node in the network has its own, potentially imperfect 'instance' of the ledger (i.e. a 'journal'). As a result, some of the data held by nodes is provisional and partial and may not always reflect the complete set of structured, authoritative records.
13/ The goal of a DLT system is to keep these individual instances (journals) of the structured record in sync, leading to a convergence towards a single accepted set of authoritative records (the 'ledger').
14/ Conceptually, the ‘ledger’ should be regarded as a latent, abstract construct that is generated by the DLT system as whole through the constant efforts of synchronising the individual copies maintained by each full participant ('full node').
15/ You may have seen some of these terms being used differently and/or have different meaning in other contexts.
We use them throughout this report to refer to specific concepts in order to provide a consistent terminology.
We use them throughout this report to refer to specific concepts in order to provide a consistent terminology.
16/ Tomorrow, I will share the different steps required for an unconfirmed transaction to become part of a finalised record; that is, buried deep enough in the ledger to be (reasonably) safe from reversal.
