Blockchain scalability

[void4]

The consensus layer provides risk takers with certainty about time ordering and validity of transactions and state. To achieve this in open, mostly untrusted environments, different consensus algorithms are used:

• economic, objective consensus (Proof of Work: Bitcoin, Ethereum, weakly objective Proof of Stake)
• social, subjective consensus (Ripple, Stellar Consensus Protocol)

These systems create a network with periodic global consensus about a set of states. State updates are collated in block, the time between these blocks varies with systems and security parameters from a few seconds to several minutes. Each block references the previous one, creating a chain of blocks: the blockchain.

However, almost all blockchain projects with global consensus depend, at least implicitly, on the development of a scalability layer. Some reasons for this are that we

• want secure sub-blocktime interactions - not wait one or more blocks for state changes
• want to pay the least amount of transaction fees possible
• want to benefit from other advantages a more direct (non-global) layer entails, privacy for example

The general idea to make blockchain scalable is to use it only as a fallback in case consensus between two or more parties without a trusted intermediary fails.

The following approaches share this property:

• sidechains
• channels

In fact, they are very similar. The main mechanism is as follows:

1. Freeze/lock a state and/or stake equivalent to the financial risk in the main chain (the consensus layer that serves as the ground truth).
2. Take further interaction off chain and let all risk takers sign (ordered) state updates
3. Provide a mechanism in the main chain to update the chain state according to a specific state update (in most cases, the last)

Types of channels:

• Payment channels (transfer of cryptocurrency or subtokens on these systems)
• State channels (full or partial state updates of a contract)
• Contract channels (scalability solutions that allow for many-program/contract interaction - possibly sharding)

Open questions:

• different state channel topologies and design patterns (e.g. timeouts)
• theoretical analysis of risks, efficiency, privacy, cost and other tradeoffs in multiparty interactions
• to what extent can permanent centralization be avoided?
• state channel routing and -incentivization
• is off chain contract creation possible?

Other considerations:

• how should developers interact with these systems, can they be transparent?
• how can these systems ensure availability?
• what kind of guarantees can these systems make and what are their limits?
• in which cases is global consensus required? (payments: double spending, registries: uniqueness)
• self modifying or interpreting contracts could make development easier

Possibly related: lambda-architecture.net