The notion of a blockchain, originating with Wei Dai, 1996 (web, wikipedia B-money) and (Nakamoto2008), allows for the creation of a linear log which can be added to, but is extremely difficult to otherwise modify, in a network with multiple nodes, without any central authority.

Blockchain can be considered as certain data structure – chain of blocks – which are cryptographically “sealed” by hashes which are for each block added to the next block and which is incremented by one of many parties called nodes which follow a commonly accepted algorithm and each contains a copy of the blockchain (full node) or its essential part. Who adds a block, or whose added block is respected by other nodes is a part of the algorithm (blockchain protocol) and is desirable to be byzantine fault tolerant. The securest algorithm in nontrusted environment (public blockchain) is the proof of work algorithm. Regarding that blockchain is a tool to establish noncentralized record verification it is common to use blockchains to carry records of assets, including cryptocurrencies and other token, off chain assets, credential records, verification proofs and so on. These data and transaction steps belong and are authorized by accounts. Modern blockchain protocols assume also that code handling assets in deterministic manner may be part of the account, when the nodes add new blocks they should also execute the code of the contract, within a blockchain virtual machine; such accounts are called smart contracts and realize in a specific way the idea of smart contracts outlined in theoretical computer science before the blockchain era.

The phrase distributed ledger is sometimes viewed as a synonym. Technically, distributed ledger is the same idea realized in a more general setup where the record may be organized in non-linear structure, for example when the blocks form a DAG (directed acyclic graph) rather than a single chain, with appropriate protocol.

Proof of work

The key idea is that of proof of work. Think of a blockchain simply as a list [B 1,B 2,][ B_{1}, B_{2}, \ldots ] of ‘blocks’. A block BB is an unencrypted block of content, which could be anything, together with a cryptographic hash of it (‘signature’) with certain properties.

The key points are the following.

  1. The cryptographic hash with the required properties is hard to create, where ‘hard’ means requiring significant computational resources and taking time (e.g. something like prime factorisation). Use of these computational resources to create the hash is referred to as ‘proof of work’.

  2. The hash of B i+1B_{i+1} depends on the hash of B iB_{i}.

  3. The hash of a block depends exactly on its contents: any change in contents will lead to a significantly different hash.

  4. It is easy (requires little resources and time) to check that a particular hash has the required properties.

Suppose that we have nn nodes in a network. Each node accepts as the current blockchain the longest valid blockchain which it knows of. If a node XX adds a block BB to a blockchain L=[B 1,,B m]L = [ B_1, \ldots, B_m ], i.e. succeeds in a creating a hash of some unencrypted block of content, it sends L=[B 1,,B m,B]L' = [B_1, \ldots, B_m, B] out to all nodes listening to/connected to it. If longest blockchain LL'' which a node YY knows of has length mm, then upon receiving LL' it drops any attempts it is currently making to add a block to LL'', checks the validity of LL', and if it is valid accepts it as the current blockchain.

In such a system, it is extremely difficult for any node to tamper with the blockchain. This is because if it wishes to change the content of a particular block, then because of 2. and 3. it must not only re-create the hash of the tampered block, but also the hash of all blocks after it, as well as the hash of a new block. If any honest node creates the hash of just one new block in the meantime and sends it out to the network, the tampering attempt now has still another block to hash. Because of the computational resources required to create even one valid hash, it is thus highly unlikely that tampering will succeed, and thus a tamperer may soon use up great amounts of resources for no gain. If successful adding of blocks is incentivised appropriately, it is thus more sensible to act honestly.

There are various further details, but this is the rough idea.


While in its way ingenious, the use of proof of work underlying the notion of a blockchain is rather crude. Enormous amounts of electricity, for example, are being consumed by large blockchain networks such as bitcoin during proof of work, whilst the outcome of that proof of work is typically useless. This is not sustainable.

A different criticism regards the algorithm itself. If nodes were to co-operate in such a way that they controlled over 50% of the computational power on the network, a tampering attempt would eventually be able to ‘catch up’ with the honest additions to the blockchain.


A foundational/mathematical introductory book from the point of view of (building) a distributed computing system is

  • Roger Wattenhofer, The science of the blockchain, 115 pp. Inverted Forest Publishing 2016

A comprehensive guide for architects of blockchain applications with an attempt at certain level of abstraction of central concepts is

  • Xiwei Xu, Ingo Weber, Mark Staples, Architecture for blockchain applications, Springer 2019

The following systematic book written by a several authors offers pretty rigorous handbook on blockchain security issues

  • Sachin S. Shetty, Charles A. Kamhoua, Laurent L. Njilla (eds.) Blockchain for distributed systems security, 324 pp. IEEE Press, SMTE Books 2019

See also:

Some key papers in distributed consensus include

  • M. J. Fischer, N. Lynch, M. S. Paterson, Impossibility of distributed con- sensus with one faulty process, JACM 32:2, 374-382 (1985)
  • M. Castro, B. Liskov, et al., Practical byzantine fault tolerance, Proc. 3rd Symposium on Operating Systems Design and Implementation (1999) 173–186.
  • L. Lamport, R. Shostak, M. Pease, The byzantine generals problem, ACM Transactions on Programming Languages and Systems, 4/3 (1982), p. 382–401.

Other references on distributed ledgers

  • Vitalik Buterin, Ethereum: A next-generation smart contract and decentralized application platform, pdf
  • Gavin Wood, Ethereum: a secure decentralised generalised transaction ledger, Ethereum, Tech. Rep. 2017
  • Gavin Wood, PolkaDot: vision for a heterogeneous multi-chain framework pdf
  • Joseph Poon, Vitalik Buterin, Plasma: scalable autonomous smart contracts, pdf
  • Joseph Poon, Tadge Dryja, Lightning network, pdf Mar 2015.
  • Vitalik Buterin, Chain interoperability, R3 reports, Sep 2016 pdf
  • Tier Nolan, Re: Alt chains and atomic transfers, 2013, bitcointalk discussion post
  • Nikolai Durov, Telegram Open Network, 132 pp. Dec 2017 pdf, mirror pdf; Telegram Open Network Blockchain, Sep 2018, 121 pp. pdf; Telegram Open Network Virtual Machine, Sep. 2018, 148 pp. pdf; Fift: a brief introduction (about a new programming language on TON), May 23, 2019, 87 pp. pdf is at channel
  • L. Baird, The Swirlds hashgraph consensus algorithm: fair, fast, byzantine fault tolerance, pdf (May 2016); Hashgraph consensus: detailed examples pdf; Overview of Swirlds Hashgraph: An Introduction To The Hashgraph (SDK Available Now) online; Hedera Hashgraph whitepaper pdf; intro to whitepaper web
  • Aggelos Kiayias, Andrew Miller, Dionysis Zindros, Non-interactive proofs of proof-of-work, IACR preprint 2017 pdf (see also here and Cardano, IOHK)
  • Mike Hearn, Corda – a distributed ledger (technical whitepaper, 2016) pdf; Brown et al. Corda - an introduction, whitepaper 2016, pdf; Brown, Corda - an introduction platform whitepaper 2018 pdf
  • Ittay Eyal, Emin Gün Sirer, Majority is not enough: Bitcoin mining is vulnerable, in: Financial Cryptography and Data Security 436–454, Springer 2014 pdf

For an extended list of references see blockchain (at zoranskoda).

Last revised on May 20, 2021 at 06:37:16. See the history of this page for a list of all contributions to it.