As the Web3 space continues to grow, contextualising the various technologies has become an increasingly demanding task. In this series of articles, we will start with a high level overview of the various concepts and eventually arrive at the use cases which various Web3 protocols are trying to solve.
This article focuses on the different blockchain types within the transaction settlement layer. The articles are divided into 3 levels of increasing detail:
L1 — Overview
An overview of the different layers and how they enable Web3 functionality through building on top of each other:
L2 — Concepts
The key concepts within each layer that informs business and technical decisions. This highlights the different categories of Web3 technologies:
L3 — Implementations
Understanding the difference between various protocol/standard implementations and how they relate to each other. The focus will be on Web3 lego blocks and its affects on value flows:
- Transaction Settlement
- Assets
- Web3 Primitives
- Optimisers (WIP)
Layer 0: Cross-chain communication infrastructure
Inter-Blockchain Communication Protocol (IBC)
Protocol to handle authentication and transport of data between blockchains through exposing a standard interface and verifiable relayers. As any two chains that implement IBC are able to directly communicate, a mesh topology is technically feasible whereby each chain is connected to every other chain in the network. Consequently, chains which implement IBC are provided more guarantees around parallel communications, robustness, as well as privacy and security.
Parachains
An application-specific data structure that is globally coherent and validatable by the validators of the Relay Chain. The Relay Chain acts as a central hub through which all parachains are able to securely communicate. This topology enables transaction processing to be parallelised across parachains while inheriting the security of the entire network.
Layer 1: State finality through consensus
All blockchains follow one of two bookkeeping models: UTXO or Account Based. The bookkeeping model defines how state transitions are handled by the network regardless of the consensus model implemented. I highly recommend the following article which this section draws heavily from:
Unspent Transaction Output (UTXO)
The UTXO model predefines a set of assets, with their relevant owners, which can be transacted and recorded via a directed acyclic graph. Individual transactions are grouped into blocks to be finalised through network consensus. Transaction outputs must be completely spent resulting in the creation of one or more new transaction outputs. UTXO only keeps track of transaction receipts with account balances being calculated on the client side by aggregating all transactions tied to an address. Global state is only extended through the creation of new UTXOs.
This transaction output verification model affords UTXO a few advantages: transaction processing parallelisation of unique resources; transaction processing is independent of global state and bounded by the inputs; simpler privacy model which makes it harder to link transactions.
- Modified UTXO/DAG:
Blockchains which extend the classic UTXO model in order to achieve a myriad of use cases: smart contract programmability; state rental economic model; parallel transaction validation without total ordering.
- Privacy:
UTXO blockchains which implement additional privacy enhancing cryptography tech to ensure the anonymity of users as well as obscure transaction provenance. Privacy is guaranteed at the transaction level.
Account Based
The account model represents assets as balances within accounts. Accounts can be externally-owned (i.e. owned by a user) or code controlled (i.e. smart contract). Global state is updated via adding/subtracting the account balances. Accounts maintain an auto-incremented transaction count (i.e. nonce) to prevent any replay attacks. Account balances from the originating account are checked to prevent overspending. Transaction fees are calculated based on the computational steps required by the transaction. Transactions are ordered and batched into a block to be finalised via the network’s consensus model.
This computational account model offers a few advantages: simpler state handling which reduces processing overhead involving complex logic; more efficient memory usage; less data throughput and storage requirements; natively mixes coins within an account for better privacy.
- Ethereum Virtual Machine (EVM)**: **A virtual machine environment which was purpose built to execute transactional computation on a network of nodes. The EVM defines the computing rules (i.e. data types, opcodes, etc.) for valid state transitions as blocks are added to the chain. Critically, the EVM is not limited to the Ethereum protocol and new blockchains have sprung up with different levels of EVM compatibility (i.e. ability to run the same code as Ethereum). Majority of chains have implemented EVM compatibility as this enables composability of battle-tested smart contracts between chains.
Layer 2: Scalability via off-loading compute
Application Specific
Application specific Layer 2 scaling solutions focus on executing the application use case particularly well. These solutions utilise the security of the base chain while minimising the total compute and memory resources required in order to arrive at the same final state of the network. This is achieved via application specific contracts being deployed on the base chain.
The efficiency and lower resource overhead of application specific solutions comes at the expense of not being able to natively support general purpose computing logic. Due to this reason alone, the Ethereum community has been moving towards a rollup-centric roadmap.
- **State Channels: **Multi-sig contracts are deployed and pre-funded on the main chain. Based on the available funds, an infinite amount of transactions can be executed on the state channel with the final net amount being committed to the main chain. As channel participants needs to be known at point of contract creation, liquidity network effects incentivises a hub-and-spoke topology model.
- **Plasma: **Framework that utilises Merkle Trees to enable creation of unlimited child chains. Transactions are offloaded to the child chains with all block headers being snapshot onto the main chain. To prevent exploitation by bad actors, an exit game is required which results in long withdrawal waiting periods.
General Purpose
General purpose solutions enable arbitrary contract executions and have their own security and consensus model. Transactions are executed external to Layer 1 but the data is posted back to Layer 1. This design enables more efficient use of memory as data can be compressed prior to being stored on the main chain. These solutions are achieved by deploying smart contracts on the main chain which are responsible for processing transfers and verifying proofs.
- **Sidechains: **EVM compatible independent blockchains which implement their own consensus and tokenomics. Each sidechain has a separate set of validators and operators that runs the protocol specific software.
- **Rollups: **A framework for bundling sidechain transactions into a single transaction from which a cryptographic proof is generated to be committed to the base layer. The main chain is able to verify the validity of the sidechain transactions by verifying the cryptographic proof against the main chain state.
- **Optimistic Rollups: **EVM compatible VM (Optimistic VM) which allows execution of EVM smart contracts on a sidechain. Optimistic rollups assumes the correctness of the data posted hence the name. As such, to ensure the reliability of the chain, optimistic rollups have to economically incentivise dispute resolutions when verifying fraud proofs. This is achieved by requiring the party responsible for posting data to the main chain to stake personal funds which is exposed to slashing risks. The locking of funds results in longer withdrawal times as sufficient time must be given for dispute resolution to achieve the desired levels of security.
- **Zero-Knowledge Rollups: **Sidechains where the processed data is batch posted for validation on the main chain via a zk-SNARK proof. As the correctness of the data can be verified through the validity proof alone, funds are available immediately. Zero knowledge modules are known to be more computationally expensive and hence tends to require higher spec machines. While the complexity of zero knowledge technologies makes it harder to support EVM compatibility, there are now testnets which are piloting the reliability of zkEVMs.