Cambridge University Digital Ledger Technology System Report
Cambridge University Centre for Alternative Finance released a report on DLT. You can find it here. The report has “A Conceptual Framework” as a subtitle.
Here’s why it is interesting in many many ways.
- As they say from the subtitle it is a conceptual report. They aim to offer a framework that set up a common ground in the DLT universe. The report uses Systems Theory and try to approach the whole DLT ecosystem focusing on explaining and understanding rather than using hyped terms to create more hype (see sect 2, esp. 2.1–2.3).
- Definitions matter. That’s why: “The DLT ecosystem is plagued with the use of incomplete and inconsistent definitions and a lack of standardized terminology, creating a needlessly complicated landscape for everyone from experienced policymakers and developers to individuals venturing into the field for the first time” (p. 11 — executive summary).
- How do you ensure your analysis fosters further discussion? You review the state of the art, i.e. other people’s and scholarship definition concerning blockchain and DLT (sect. 2.1.). In that way you show there’s something messy to be cleared.
- How do you define DLT and remove part of the messy definitions? By listing properties. The report chooses (p. 24): (i) shared recordkeeping; (ii) multy-party consensus; (iii) independent validation; (iv) tamper evidence; (v) tamper resistance.
- The properties have to be measurable and — big step up — all the dimensioned addressed by the report come in degrees. They are not 1/0. Decentralization, for example, is a matter of degrees. further, all these properties interact with each other. Designing a DLT is a matter of trade-offs.
- The report digs back into the roots of the problem. History of ideas is a way to detach from the hype of [enter you last ICO]. Thus DLT are traced back before Bitcoin and Blockchain discussing The Byzantine Generals Problem of Lamport et al. (1982). The report also offers a theoretical background of its own perspective, going back to general systems theory and systems philosophy.
- Graphic is great. The report is rigorous as a paper and catchy as a flyer advertising a design conference. Just check the p. 15 of sect. 1. Nice columns layout plus italicized emerging definition of DLT and a box asking the “What Is DLT?” question.
- Mythbusting. The report does a lot to combat that. So this deserves another section.
- The theory is applied. The last part of the report (actually sect. 6 before the conclusion and the appendices) runs an application of the conceptual framework on a 6 different projects (Bitcoin, Ethereum, Ripple — something you would expect; plus Alastria, Verified.me-which you may not expect and a mysterious project called ‘Project X’).
- Appendices rule. There’s a glossary with the main terms. A great way to sum up a lot of clarificatory work. There’s the full scheme to analyze a DLT system and there’s also a table that sums up the comparison of the different project investigated in the application phase (though the appendices are not listed in the order I’ve choosen).
Properties of a DLT are not a binary feature (p. 21). See the note on ‘Decentralisation’ (sect. 4.1.4).
DLT and trust. “DLT systems do not remove trust requirements; they merely shift them from operators to users” (fn. 29). Or, as we read on p. 22: “DLT systems can be characterized as disintermediating technology that ‘delegates trust to the endpoints’ (i.e. the end users) of the system”.
Pseudonomity. “There is a popular belief that records stored on a DLT system are ‘immutable’ and can never be reversed. However, that is not necessarily the case: DLT systems provide different degrees of transaction finality depending on the system design. This means that a confirmed (and executed) transaction may be subject to reversal.”. (p. 35)
Censorship resistance. Blockchain-related things are often called to be censorship resistant. Still, the protocol allows for a change in the rules and for new block to be added while not considering other. Just think about hard-fork (Ethereum and Ethereum Classic anyone?). In short (p. 42): “Changes to protocol rules can overrule data semantics”.
The report (p. 36) nicely explains what we mean talking about censorship and DLT: “Censorship resistance is a term commonly used in the context of DLT which generally refers to the inability of a single party or cartel to unilaterally perform any of the following: 1. Change rules of the system 2. Block or censor transactions 3. Seize accounts and/or freeze balances”.
Finally this, just to use Medium’s quotation tool.
“Contrary to popular belief, a confirmed transaction or record is not necessarily irreversible. Transaction finality determines when a confirmed record can be considered final (i.e. not reversible). Finality can be probabilistic (e.g. PoW-based systems that are computationally impractical to revert) or explicit (e.g. systems that incorporate ‘checkpoints’ that must appear in every transaction history). Finalised records are also called permanently settled. Records that have been produced, but which are feasible to revert, are provisionally settled. Provisionally settled records become permanently settled after the transition period between record creation and finality” (pp. 63–64).
The application-phase includes a mysterious project, ‘Project X’. Feel free to take a guess on what’s that crossing data about the people working on the report and their activities and projects.
The framework developed in the report is too good not to be mentioned briefly.
Protocol layer (what are the rules enforced on a certain DLT?) is clearly distinguished from the Network layer (what happens when we implement the protocol layer?) and the Data layer (combining the previous layers data are added and the ledger keeps growing). See pp. 38–39 for a quick overview with some high quality graphics. See also sect. 5 for a deeper dive into the framework.
The same holds for the clarification of report, transaction, log, record, journal and ledger. Here we go by just quoting p. 25.
Transaction: any proposed change to the ledger; despite the connotation, a transaction need not be economic (value-transferring) in nature.
Log: an unordered set of valid transactions held by a node, which have not yet been incorporated into a formal record subject to network consensus rules (i.e. ‘unconfirmed’ transactions).
Record: transaction data which has been subject to network consensus rules. Note: A ‘candidate record’ is a record that has not yet been propagated to the network.
Journal: the set of records held by a node, although not necessarily consistent with the consensus of other nodes. Journals are partial, provisional, and heterogeneous: they may or may not contain all the same records.
Ledger: the authoritative set of records collectively held by a significant proportion of network participants at any point in time, such that records are unlikely to be erased or amended (i.e. ‘final’).
Isn’t this way clearer than it used to be?
Minor Issues with the Report
There are minor issues in the report. They are nothing dangerous, still they are worth mentioning:
- Page numbering is not consecutive. The PDF has 97 slides, but the report has 109 pages. The reason is that chapters always open on a odd number. Nothing hinges on that except when you have to quote the pages and you track them on the PDF.
- Quotes and references are great but they refer to the article rather than actual pages. Again, this is pretty standard in reports and whitepapers. I guess the reason is that most of the references are available online so, if you want to spot the right place, you just copy-paste the quote and then search.
- There’s a mistaken footnote. Footnote 24 should point to Tasca & Tessone (2018) on DLT [this one], but here we find a reference for Barnaanffy (1949).
- Bertaanffy’s (1949) paper on Biologia generalis is in German and titled “Zu einer allgemeinen Systemlehre,” Biologia Generalis, 19 (1949) 114–129. The work “General Systems Theory” is a book collecting various pieces on the topic, dated 1968. [I was only able to find the book and then extract the data for the Biologia Generalis paper].
- P. 62 talks about the 51% and, there, mentions selfish mining (which actually requires only one third of the votes). Despite the percentage issue (51 and 33,333…) there’s a bunch of extra articles on Medium arguing at length against selfish mining (start from this one).
- Footnote 104 reads: “We assume that there is no collusion between the different Bitcoin or Ethereum mining pools. If there is collusion, as some warn, then this statement is no longer true”. A reference to the ‘some’ would have been appreciated.
Read it. You won’t regret it.