1.2. Background

Distributed protocols, like bitcoin, or more complex smart contract systems, need a way to synchronize the state across all parties that participate in the protocol. Thus, operations under such a protocol must be organized in atomic transactions (or, more generally, state transitions) - and the sequence in which these operations are applied to an initial (genesis) state must be clearly defined. The rule of the ordering is named consensus rule, and the protocol that has a well-defined consensus rule is named consensus protocol.

Blockchain originated as a specific form utilized by distributed protocols (initially bitcoin) which combined consensus mechanism with actual operations (transactions, in case of bitcoin), organized into a time-ordered chain (i.e. sequence), named ledger. Thus, bitcoin blockchain is a consensus (PoW Nakamoto consensus) plus transaction ledger, whose finality and ordering is maintained by that consensus. The same applies to most of other existing blockchains.

It is quite clear that the main value for a distributed system is maintaining the consensus - event ordering - and not keeping the data of the actual events. Instead, it is sufficient to have a way for consensus layer to keep only short cryptographic commits to the ledger events, keeping/storing the actual event information (ledger) outside of the blockchain. This approach originates from the works of Peter Todd where he names it “client-side-validation”. It solves two major issues specific to any blockchain: scalability in terms of the size of the data kept onchain, and privacy, where both the transaction graph and actual transactions data are publicly known. With client-side-validation we can again use blockchain for the single task it does well: consensus, moving the idea of keeping a ledger of transactions into the oblivion it deserves.