BTC transactions per second

ETH & BTC fees, all time

ETH & BTC fees, last year

Transactions per second (TPS)

• Bitcoin: about 3-7 TPS
  • 3 TPS is about 260k TXNs per day
  • Theoretical maximum of 10-12 TPS
• Ethereum, pre PoS: about 10 TPS
  • 10 TPS is about 864k TXNs per day
• Ethereum, post PoS: about 13 TPS
  • 13 TPS is about 1.1M TXNs per day
  • Estimated upper limit of 100,000 TPS
• VISA: about 6,000 TPS in 2020 (source)
  • 6k TPS is about 518M per day
  • Even higher during the holiday shopping season

Fundamental problem

• How do we allow a cryptocurrency system to grow...
  • As more people use it and more transactions occur
• While also:
  • Preserving security
  • Not having the blockchain size become prohibitively large
  • Keeping fees to a reasonable level
  • Keeping transaction times to a reasonable size

Blockchain layers

The "parts" of a modern cryptocurrency can be thought of as different "layers", each built upon the one below:

• Layer 0, the "Network" layer: the base system and network (P2P network, Internet, etc.)
• Layer 1, the "Fundamental" or "Implementation" layer: consensus, cryptography, the computing machine (EVM, e.g.)
• Layer 2, the "Execution" layer: smart contracts, dApps
• Layer 3, the "Application" layer: user-facing tools and web interfaces

A note on layers

• Different sources define a different number of layers
  • From 2 to 6
• Some separate out the computing aspect of layer 1 into a "Layer 1.5"
• Optimizations
  • Layer 0 optimizations are outside the scope of this course
  • Most focus is on layers 1 and 2
  • Layer 3 is less of a cryptocurrency issue, so we won't focus on that

Classic Blockchain Trilemma

• There are three important aspects to consider:
  • Scalability
  • Decentralization
  • Security
• Any change to one of them will affect the others
  • Often negatively
• So how to improve one without affecting the others?
  • That's the Blockchain Trilemma

Layer 1 Scaling

• Options include:
  • Increase block creation speed
  • Increase block size
  • Change the consensus protocol
  • Sharding
• Called "on-chain" scaling solutions
  • Require a change to some aspect of the cryptocurrency itself
• Some solutions create "child" chains
  • They are still part of the overall blockchain

Layer 2 Scaling

• Options include payment channels, nested channels, and side chains
• Examples
  • Lightning Network is a Bitcoin's layer-2 scaling solution
  • Polkadot is a layer-2 scaling solution for Ethereum
• Called "off-chain" scaling solutions
  • It does not require a change to the cryptocurrency itself
• Some solutions create "side chains"
  • They are on a separate blockchain different from the main cryptocurrency blockchain

On-Chain Scaling (Layer 1)

• Modifications to the cryptocurrency protocol itself
• Topics:
  • Increasing block size, increasing block creation speed, changing the consensus algorithm
  • Bitcoin's SegWit (segregated witness)
  • Bitcoin's Lightning Network
  • Sharding: splitting a blockchain into multiple, smaller blockchains

Increase block size?

• Doing so will cause increased delays
  • The additional TXs have to get around the P2P network
  • Nodes have to spend more time accumulating transactions into the (now larger) blocks
  • More computational power to compute the hash / nonce for a block
  • Longer time to verify blocks
• Consensus security takes longer with increased block size
• Current cryptocurrencies strike a balance between these factors

Current blockchain stats

• Bitcoin's blockchain size is $\approx$560 GB (as of 3/31/24)
  • And increasing at about 150 Mb per day
• Ethereum's full blockchain is about 1.7 Tb
  • And increasing at about 400 Mb per day!
• This won't be sustainable with increased adoption

Increase block creation speed?

• A big difference between Ethereum and Bitcoin
• Too fast a block creation speed adds too many coins to circulation
  • This will devalue the currency
• This requires fundamental changes to how the cryptocurrency works
  • Consensus times, mining algorithms, P2P communication, etc.
  • This means it likely creates a new cryptocurrency

Changing the consensus algorithm

• A necessary step to increase block creation speed or block size
• But it is not a solution in and of itself
  • Meaning we have to pair it with increased block size or decreased block time
• And requires changing much of how the cryptocurrency is structured

Bitcoin's Segregated Witness

• This puts some data into a separate section, called a witness
  • This is raw stack data
  • If redeeming multiple UTXOs, then this data can be shared between all the UTXOs
  • Thus decreasing the average TXN size and increasing TXN count per block
• (It also fixed the issue of the TXN hash changing during mining)

Sharding

shard [noun]: a fragment, especially of broken earthenware.

Sharding is splitting a database into pieces, or shards

Database Sharding

• A very large database could keep the columns in different databases
  • And link them by a unique ID
  • Especially if different operations need mutually exclusive columns
• This is called vertical scaling
  • As the columns, which are vertical, are split among different databases

Database Sharding

• A very large database could also keep the rows in different databases
  • Especially if any operation needed mutually exclusive rows
  • Each row has a "home" database
• This is called horizontal scaling or sharding
  • As the rows, which are horizontal, are split among different databases

Cryptocurrency sharding

• Typically only on a proof-of-stake blockchain
  • Proof-of-work blockchains: how to verify TXN on a different shard?
• Sharding is splitting a blockchain into multiple, smaller blockchains (shards) to reduce congestion and increase TPS
  • Often called "child" chains
• Miners / validators work on one (or more) shards
  • Transactions on a shard have a root Merkle hash, which appears on the main chain
  • Some allow child chains to have different consensus algorithms, block details, etc.

Off-Chain Scaling (Layer 2)

• Off-chain scaling uses work done outside of the blockchain to improve efficiency of the system
• This includes grouping transactions together (rollups) and using side channels
  • Side channels == side chains == parallel chains

Optimistic Rollups

• Assumes the data is valid, but checks it
  • If it is, then no further action needed
• If not...
  • Identify the problem transactions and undo them
    • Perform a fraud proof to do so
  • Penalize the guilty party
    • This means a bond is provided by those submitting TXNs
    • Also by those performing the fraud proofs to prevent malicious proofs
  • Revert those transactions back to before the invalidity
  • This whole process can take a few weeks!

zk-Rollups

• Transactions provide zero-knowledge proof showing validity
• These zero knowledge proofs are "bundled" into a single transaction
  • Anybody can then verify it

Proof types

• Fraud proofs
  • Optimistic rollups assume that the transactions are valid
  • But if challenged, the system runs a fraud proof to see if fraud takes place
• Validity proofs
  • When the rollup results are supplied to the main chain, a proof of validity is provided as well
  • Which is then checked
  • zk-rollups use these, as do other scaling solutions

Rollups

• Optimistic rollups are relatively easy to implement
  • But disputes can take weeks to resolve
• zkRollups are very hard to implement and computationally intensive
  • But much easier to resolve disputes
• Both can scale up transactions significantly

Bitcoin's Lightning Network

• The money is committed on the blockchain to open a payment channel
  • It cannot be spent outside the LN until that channel is closed
• Any transactions in the channel are much faster
  • And don't store data on the blockchain
• The channel can be closed at any time
  • The final settlement is posted to the blockchain

LN Routing

• Imagine if:
  • Alice and Bob have a payment channel
  • Bob and Charlie have a payment channel
• If Alice wants to pay Charlie...
  • Then she could route it through Bob
    • Assuming the channel is sufficiently large enough
  • And still keep it off the chain
• Bob may collect some (small) fees for this

Lightning Network Benefits

• Once off the Bitcoin blockchain, LN is not constrained by those parameters
  • Can use different consensus, block size, fee structure, etc.
• Much faster transactions
  • Don't have to wait to be included in a 10 minute block
• Lower fees than the Bitcoin blockchain
  • Ideal for micro-transactions
• Lowers the data load on the Bitcoin blockchain
  • Increasing throughput for all

Lightning Network Drawbacks

• LN-enabled wallets are not all that friendly
• You have to encourage people to run LN nodes
  • Fees paid to those people help
• Vulnerable to many attacks
  • See next slide
• You have to un-lock your funds to spend them elsewhere

LN Attacks 1 (source)

• Griefing attacks: Funds aren't lost, but it causes the victim's Lightning funds to be frozen so that the payment channel cannot process any transactions
• Flood and loot: An attacker forces many victims to claim their funds from the blockchain at the same time (flood)
  • The attacker uses this congestion to steal funds that were unable to be claimed before the deadline (loot)

LN Attacks 2 (source)

• Time-dilation attacks: An attacker lengthens the time a victim becomes aware of new blocks by delaying block delivery
• Pinning attacks: An attacker tricks a victim into closing their LN channel improperly and steals individual transactions

ETH Simple Payment Channel

• From here and here

pragma solidity ^0.4.24;

import "zeppelin-solidity/contracts/math/SafeMath.sol";
import "zeppelin-solidity/contracts/ECRecovery.sol";

/**
 * @title SimplePaymentChannel
 * @author Eric Olszewski (eolszewski@gmail.com)
 *
 * @dev Ethereum payment channels allow for off-chain transactions with an on-chain
 * settlement. In this implementation, a party (sender) can open a channel with a 
 * deposit, expiration, and recipient. The sender can then sign transactions off-chain
 * and send them to the recipient, who can submit one of these signed transactions to 
 * chain to close and settle the channel.
 */

contract SimplePaymentChannel {
    using SafeMath for uint256;
    using ECRecovery for bytes32;

    event ChannelOpened(address sender, address recipient, uint expiration, uint256 deposit);
    event ChannelClosed(uint256 senderBalance, uint256 recipientBalance);

    address public sender;
    address public recipient;
    uint256 public expiration;

    constructor(address _recipient, uint256 _duration) public payable {
        require(msg.value > 0);
        require(msg.sender != _recipient);
        sender = msg.sender;
        recipient = _recipient;
        expiration = now + _duration;
        emit ChannelOpened(sender, recipient, expiration, msg.value);
    }

    function closeChannel(uint256 _balance, bytes _signedMessage) public {
        require(msg.sender == recipient);
        require(isValidSignature(_balance, _signedMessage));
        uint256 balance = _balance;
        uint256 remainder = 0;
        if (_balance > address(this).balance) {
            balance = address(this).balance;
        } else {
            remainder = address(this).balance.sub(balance);
        }
        recipient.transfer(balance);
        emit ChannelClosed(remainder, balance);
        selfdestruct(sender);
    }

    function extendExpiration(uint256 _expiration) public {
        require(msg.sender == sender);
        require(_expiration > expiration);
        expiration = _expiration;
    }

    function claimTimeout() public {
        require(now >= expiration);
        selfdestruct(sender);
    }

    function isValidSignature(uint256 _balance, bytes _signedMessage) internal view returns (bool) {
        bytes32 message = prefixed(keccak256(abi.encodePacked(address(this), _balance)));
        return message.recover(_signedMessage) == sender;
    }

    function prefixed(bytes32 _hash) internal pure returns (bytes32) {
        return keccak256(abi.encodePacked("\x19Ethereum Signed Message:\n32", _hash));
    }
}

Plasma Chains

• A separate blockchain "anchored" to the Ethereum blockchain
  • Technically a "side chain"
  • Uses fraud proofs
  • Sometimes called "child" blockchains
• There are many implementations:
  • OMG network
  • Polygon, which we'll see shortly
  • Gluon
  • LeapDAO (now apparently defunct)

TXN order matters

• What if the transaction order was different?
• The two shown blocks are not the same
• Who gets paid depends on whose transaction is earlier in the block's lists of TXNs
• Is this a race condition?
  • Yes, for the miner / validator
  • No, for the node

Blockchain determinism

• An axiom of a blockchain:

The current state of the blockchain must depend solely on the data (including transaction order) in the blockchain itself

• This means:
  • No random numbers
  • No difference in opinion about the state by different nodes
  • No floating point numbers!

Evaluating transactions

• Transactions are evaluated strictly in the order they are found in the blockchain
  • That's deterministic
• Miners / validators replay each transaction
  • But they get a (potential) reward for doing so
• Nodes also have to replay each transaction
  • But they get no reward!

The problem

• Sync'ing the full Ethereum blockchain can take two weeks
  • And that's optimized
• We need to improve upon sequential execution
  • While staying fully deterministic
• And we'd like to take advantage of multi-core CPUs

Solution: Speculation

• Solution: execute the transactions in parallel
  • Detect when there is a conflict and then fix it
• To make life easier...
  • ... without much loss in speed...
  • ... we can parallel execute the transactions in one block at a time
  • And once that block is all done, move on to the next one
• Every data value on the blockchain will have a read lock and also a write lock
• This is all in the Ethereum Virtual Machine (EVM), which is what is replaying all the transactions

Evaluating Transactions

• There are three different entities who evaluate transactions:
  • Miners / validators as they are mining transactions into blocks
  • Nodes as they are trying to achieve consensus on a just-mined block
  • Nodes that are playing catch-up of the blockchain

Evaluating Transactions

• Miners / validators now include concurrency information in the blocks
  • The first $p$ transactions can be run concurrently, the last $n-p$ must be run sequentially
  • Motivation: if they don't, their block, in the case of a fork, is less attractive to others
• Nodes much check that the TXNs marked as being able to be run concurrently really can be
  • This is part of the block validation tests
• Nodes playing catch-up don't have to check it

How much speed-up?

• Saraph & Herlihy (from Brown) studied this in 2019
  • An Empirical Study of Speculative Concurrency in Ethereum Smart Contracts
  • Their results:
    • 8-fold increase in 2016
    • Declining to a 2-fold increase in late 2017
• The speed-up decreased as the number of transactions and number of conflicts increased
  • A "small" number of "popular" contracts were responsible for most of the conflicts

Increasing speed-up

• Saraph & Herlihy had a number of potential ways to allow for further speed-ups:
  • Split a contract's memory into read memory and write memory
  • Educate contract programmers how to program to avoid conflicts
  • Allow the EVM to have atomic data types that avoid all this
  • Recognize commutative operations and allow them to execute in parallel (assuming they are atomic)
    • Example:

balance['alice'] += 4;
balance['alice'] += 3;
balance['alice'] += 7;

• The order these are executed does not affect the result