by Federico Bo
Throughout the blockchain sector, there are still ambiguities in the definitions used. This post will attempt to clarify, at the very least, the key terms that define blockchain technology.
Let’s start with a distributed database is: a digital archive stored on multiple devices (computers/servers), called nodes. These nodes, part of a single “organization” (for example, a big company), naturally “trust” each other.
A Distributed Ledger (or DL), on the other hand, is a digital data structure stored on different nodes which cannottrust each other.
We may imagine this data structure like an accounting book represented by a simple Excel file or a database. The information in the ledger represents transactions: a node transfers or exchanges a digital asset or the digital representation of a physical asset (money, asset services, etc) with another node. Transactions may be added but never deleted, making this data structure of an append-only nature.
Distributed Ledger Technology (DLT) is a technology that can store, update, and synchronize files between multiple computers (nodes) in a distributed manner, ie. without first going through a central node in order to redistribute the updated file to other nodes.
A DLT therefore essentially consists of three parts:
1. a data model (reproducing, for example, a ledger like the one mentioned above) representing the current state of the register, updated to the last transaction carried out;
2. a communication language for modifying the register following a new transaction;
3. a protocol that allows the nodes to reach a consensus so as to guarantee that all nodes share the same data in the same order, and prevents manipulation by malicious nodes.
Amongst the types of DLTs out there is a subset named blockchain. As can be inferred from its name, blockchains are characterized by an uninterrupted chain of blocks, each linked to the previous one. Each block consists of transactions, encrypted and validated by all nodes.
Encryption provides secure communication and immutability of the registry, necessary in a vulnerable environment such as that of the decentralized one.
Having cleared (hopefully!) the distinction between DLTs and blockchain, here are some definitions one might find useful.
In their book “Blockchain Revolution” (Portfolio, 2016), Don & Alex Tapscott declare that
(t)he blockchain is an incorruptible digital ledger of economic transactions that can be programmed to record not just financial transactions but virtually everything of value.
Mike Orcutt, curator of ChainLetter, MIT’s newsletter on the subject, defines blockchain as
…essentially a shared ledger that uses cryptography and a computer network to track resources and protect the registry from tampering.
Vitalik Buterin, Ethereum’s founder, says,
“A blockchain is a decentralized system that contains some sort of shared memory.”
A World Bank document describes blockchain as
… a particular type of DLT that uses cryptographic and algorithmic methods to create and verify an ever-growing, “append-only” data structure, which takes the form of a chain of so-called “blocks of transactions “- the blockchain — which serves the function of a ledger.
Some time ago, I too developed a definition of my own:
A blockchain is a set of techniques, protocols and tools that allows an unchangeable digital archive of transactions, distributed between the nodes of a network and periodically validated by them.
As you can see, there is no particular set definition of blockchain: from time to time, technical or functional characteristics are highlighted, even while ‘distributed’ and ‘unchangeable’ remain its chief descriptors.
The first real blockchain was Bitcoin: a public network, open to all. Anyone can access it, make transactions, read the history of all transactions, “mine” bitcoins (a lowercase initial indicates the currency, an uppercase initial is used to refer to the whole infrastructure). Bitcoin users enjoy pseudo-anonymity: their real identity may be traced only under certain, rather difficult conditions. This means that, if necessary, it is possible (albeit complicated) to trace a user’s real identity.
Ethereum is another public blockchain. Similar to Bitcoin, it is called permissionless to indicate its free accessibility.
Public and permissionless are not interchangeable terms: for example, a voting system can be based on a public blockchain but would still require authorized access in order to prevent a user from voting several times.
Blockchains that require authorized access tend to be called private, with username and password credentials or more sophisticated certificates. They are often also called permissioned, or enterprise blockchain, and are used mostly in the industrial sector, in business networks where information is confidential, reserved for a set of trusted users with controlled access. Controlled access allows you to determine who can do what: for example, a participant could have reading but not writing permission, or only be allowed limited types of transactions.
Again, it is possible here to distinguish between private and permissioned: a blockchain installed exclusively on a private network could be — precisely that— private, but permissionless.
For many, the difference between public and private blockchain is strictly tied to the reading of its data, whereas the difference between permissionless and permissioned is in its writing and validation.
To conclude, here is a cheat sheet of the main advantages and disadvantages of public and private blockchains.
Purists (AKA ‘fundamentalists’) often insist that the only real blockchains are the public ones, often engaging in heated and often unpleasant discussions with ‘pragmatists’. Both blockchain types are but distinct systems serving different purposes. The Internet of Value needs both.
Belotti M., Božić N. et al. “A Vademecum on Blockchain Technologies: When, Which and How”
Falazi G., Khinchi V. et al. “Transactional Properties of Permissioned Blockchains”
|bcookie||2 years||LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.|
|bscookie||2 years||LinkedIn sets this cookie to store performed actions on the website.|
|lang||session||LinkedIn sets this cookie to remember a user's language setting.|
|lidc||1 day||LinkedIn sets the lidc cookie to facilitate data center selection.|
|UserMatchHistory||1 month||LinkedIn sets this cookie for LinkedIn Ads ID syncing.|
|AnalyticsSyncHistory||30 days||Used to store information about the time a sync took place with the lms_analytics cookie.|
|wp-wpml_current_language||session||Stores the current language of the website.|