Good

Bad

Ugly

Haskell Node

Exists

Reasonably stable

Designed end-to-end

Well-documented

Archive-capable

Controlled by one entity

Unmaintainable parts

Mixing responsibilities

Hard to radically extend

Maximized resource usage

Limited monitoring

Limited/pedantic interfaces

Developed end-to-end

ledger

consensus

networking

peer-management

block & tx diffusion

chain-sync

leader election

chain-selection

chain storage

bookkeeping (stake distribution)

transaction validation

chain state

Challenge #1: Peer Management

  • Random connections to arbitrary peers.
    • May or may not send valid information
    • May or may not abuse our own resources
    • May or may not be a sibyl actor
       
  • PoS & block legitimacy
    • Requires extrinsic knowledge (stake distribution)
    • Private leader-schedule
    • Blocks are computationally cheap to forge
       
  • Distributed system
    • Blocks typically arrive out-of-order
    • Information takes time to propagate

Challenge #2: Multiple realities

  • Potentially as many chains as there are peers
    • In practice, the probability of long-fork exponentially decreases with length, but increases with adversarial stake
    • Attack still feasible with <50% of the stake
       
  • Can switch to any fork of length < k=2160
    • Must track all plausible forks
    • Must remember who sent what (peer management)
       
  • Slot battles
    • Induced by the private-leader schedule
    • Cause regular small forks/rollbacks

How people typically view

"the blockchain"

How it actually is

up to 2160 levels

Challenge #3: Δ < 1s

  • Block propagation must* reach 95% of network within 5s
    • For optimal network operation; can still reach consensus otherwise but with degraded performances.
    • Latency worldwide ~400-500ms
       
  • I/O is slow, but required for persistence
    • Trade-offs between RAM vs commodity storage
       
  • In practice, any block validation must be done within 1s
    • Binomial distribution of blocks due to random leader schedule
    • One block every 20s on average, 50% of blocks between 1 and 14s, with significant portion (5%) at 1s.
       

Challenge #4: Deferred computations

  • Leader-schedule uses stake distribution from previous epoch
    • Snapshot required at every epoch boundary
    • ~1.4M accounts, ~1.6M UTxO, ~3000 pools,
       
  • Rewards are calculated using stake from 2 epochs in the past
    • Requires pool performances from past epochs.
    • Expensive computation which virtually happens at the epoch boundary, spread over the epoch in practice.
    • Paid directly into accounts, no on-chain materialization of that, but influences leader-schedule

Amaru

OpenTelemetry

RocksDB

Tokio

Leveraging Open Source Titans

Arnaud

Andrew

Chris

Matthias

Santiago

Pi

Damien

- Long-time Cardano contributors

- Dual skillset Haskell / Rust

- Recognized experts & community educators

- Core maintainers of most used Cardano tools

- Mathematicians & computer scientists

- SPOs & infrastructure experts

- Large-scale project management expertise

ledger

consensus

networking

peer-management

block & tx diffusion

chain-sync

leader schedule

chain-selection

chain storage

bookkeeping

transaction validation

chain state

Amaru

By Matthias Benkort