Amaru

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

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

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.

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