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
- 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
Amaru
- 85