Blockchain

David Chaum introduced digital cash as a research topic in 1983, in a setting with a central server that is trusted to prevent double-spending. To mitigate the privacy risk to individuals from this central trusted party, and to enforce fungibility, Chaum introduced the blind signature, which he used to provide a cryptographic means to prevent linking of the central server’s signatures (which represent coins), while still allowing the central server to perform double-spend prevention. The requirement for a central server became the Achilles’ heel of digital cash. While it is possible to distribute this single point of failure by replacing the central server’s signature with a threshold signature of several signers, it is important for auditability that the signers be distinct and identifiable. This still leaves the system vulnerable to failure, since each signer can fail, or be made to fail, one by one.

In January of 2009, Satoshi Nakamoto released the first widely used implementation of peer to-peer trustless electronic cash [Nak09], replacing the central server’s signature with a consensus mechanism based on proof of work, with economic incentives to act cooperatively. Bitcoin tracks payments by aggregating them into blocks, each with an associated blockheader, which cryptographically commits1 to: the contents of the block, a timestamp, and the previous blockheader. The commitments to previous headers form a blockchain, or chain, which provides a well-defined ordering for transactions.

We observe that Bitcoin’s blockheaders can be regarded as an example of a dynamic membership multi-party signature (or DMMS), which we consider to be of independent interest as a new type of group signature. Bitcoin provides the first embodiment of such a signature, although this has not appeared in the literature until now. A DMMS is a digital signature formed by a set of signers which has no fixed size. Bitcoin’s blockheaders are DMMSes because their proof-of-work has the property that anyone can contribute with no enrolment process. Further, contribution is weighted by computational power rather than one threshold signature contribution per party, which allows anonymous membership without risk of a Sybil attack (when one party joins many times and has disproportionate input into the signature). For this reason, the DMMS has also been described as a solution to the Byzantine Generals Problem.

Because the blocks are chained together, Bitcoin’s DMMS is cumulative: any chain (or chain fragment) of blockheaders is also a DMMS on its first block, with computational strength equal to the sum of the strengths of the DMMSes it is composed of. Nakamoto’s key innovation is the use of a DMMS as a signature of computational power rather than a signature of knowledge. Because signers prove computational work, rather than proving secret knowledge as is typical for digital signatures, we refer to them as miners. To achieve stable consensus on the blockchain history, economic incentives are provided where miners are rewarded with fees and subsidies in the form of coins that are valuable only if the miners form a shared valid history, incentivizing them to behave honestly. Because the strength of Bitcoin’s cumulative DMMS is directly proportional to the total computational power contributed by all miners, it becomes infeasible for a computational minority to change the chain. If they try to revise the DMMS-secured ledger, they will fall behind and be continually unable to catch up to the moving target of the progressing consensus blockchain.

Because the miners do not form an identifiable set, they cannot have discretion over the rules determining transaction validity. Therefore, Bitcoin’s rules must be determined at the start of its history, and new valid transaction forms cannot be added except with the agreement of every network participant. Even with such an agreement, changes are difficult to deploy because they require all participants to implement and execute the new rules in exactly the same way, including edge cases and unexpected interactions with other features.

For this reason, Bitcoin’s objective is relatively simple: it is a blockchain supporting the transfer of a single native digital asset, which is not redeemable for anything else. This allowed many simplifications in the implementation, but real-world demands are now challenging those simplifications. In particular, current innovation is focused around the following areas:

• There are trade-offs between scalability and decentralization. For example, a larger block size would allow the network to support a higher transaction rate, at the cost of placing more work on validators — a centralisation risk.

Similarly, there are trade-offs between security and cost. Bitcoin stores every transaction in its history with the same level of irreversibility. This is expensive to maintain and may not be appropriate for low value or low-risk transactions (e.g. where all parties already have shared legal infrastructure in place to handle fraud).

These trade-offs should be made for each transaction, as transactions vary widely in value and risk profile. However, Bitcoin by construction supports only a “one size fits all” solution.

• There are many more trade-offs for blockchain features. For example, Bitcoin’s script could be more powerful to enable succinct and useful contracts, or could be made less powerful to assist in auditability.
• There are assets besides currencies that may be traded on blockchains, such as IOUs and other contracts, as well as smart property
• There is a risk of monoculture: Bitcoin is composed of many cryptographic components, any one of whose failures could cause a total loss of value. If possible, it would be prudent not to secure every bitcoin with the same set of algorithms.
• New technology might enable new features not imagined when Bitcoin was first developed. For example, privacy and censorship-resistance could be improved by use of cryptographic accumulators, ring signatures, or Chaumian blinding.
• Evenif there is a pressing need to do so, there is no safe upgrade path for Bitcoin, in the sense that all participants must act in concert for any change to be effected. There is consensus amongst Bitcoin developers that changes to Bitcoin must be done slowly, cautiously, and only with clear assent from the community.

The fact that functionality must be broadly acceptable to gain adoption limits participants’ personal freedom and autonomy over their own coins. Small groups are unable to implement features, such as special-purpose script extensions, because they lack broad consensus.

An early solution to these problems with Bitcoin has been the development of alternate blockchains, or altchains, which share the Bitcoin codebase except for modifications to address the above concerns. However, implementing technical changes through the creation of independent but essentially similar systems is problematic.

Current Status of Blockchain Technology

Current major iterations of blockchain possess several problems: