JAM Introduction by Gavin Wood at ETH PRAGUE

JAM protocol introduction ath ETH Prague by Gavin Wood

1. EthPrague

2. Driving Factors and the Web3 maxims

e Resilience
Generality
Performance
Coherency
Accessibility

3. Size-Synchrony Antagonism

4. Overview The Core Model

JAM is generally coherent with transient decoherence
In-core (access to DDL, stateless) + on-chain (stateful)
The basis of coherency: Refine /Accumulate

Inter-core DDT using DDL

In-core state data lookup and lookup-anchor

5. JAM Rollup Host & Reactor

JAM hosts 341 (-2'°/3) secure rollups and a reactor
Rollups can be seen as reactor pre-processor
Rollups have common access to data lake

Data lake synchronized every 1 or 2 blocks

Secured by ELVES (optimistic with bounded security)
Consensus by Safrole and GRANDPA

6. The Join-Accumulate Machine

7. The JAM Data Topology

8. The JAM Anatomy

PAST

MONTH

"250m Ev ges [e
= 750K Woes /6 cure

9. Graypaper
Implementors
Prize

10. The JAM Approach

Protocol-oriented and decentralized

GRAY PAPER
JAM PRIZE
JAM TOASTER

11. The JAM Approach: The GRAY PAPER

4. OVERVIEW

As in the Yellow Paper, we begin our formalisms by
recalling that a blockchain may be defined as a pairing
of some initial state together with a block-level state-
transition function. ‘The latter defines the posterior state
given a pairing of some prior state and a block of data
applied to it. Formally, we say:

(1) o'=Y(0,B)

Where a is the prior state, 0’ is the posterior state, B is
some valid block and Y is our block-level state-transition
function.

Broadly speaking, JAM (and indeed blockchains in gen-
eral) may be defined simply by specifying Y and some gen-
esis state 0°.” We also make several additional assump-
tions of agreed knowledge: a universally known clock, and
the practical means of sharing data with other systems
operating under the same consensus rules. The latter two
were both assumptions silently made in the YP.

12. The
JAM PRIZE

Prize per milestone is
100,000 DOT + 1,000 KSM

Milestone 1: Importer
Milestone 2: Authorer
Milestone 3: Half-speed
Milestone 4: Full-speed

Milestone 5: Secure

13. The
JAM PRIZE

Additional Support

Fellowship Sponsoring
On-chain “Salaries”
Professional Audits
International Seminars
Hardware

JAM TOASTER Access

14. A: Corporate code
Java, Aspect
Kotlin

CH

Go

500,000 DOT+5,000 KSM

C: Cute code
Scheme, Common LISP
Prolog, Haskell, ML

Perl, Python, Ruby, JS
Groovy, Dart

500,000 DOT+5,000 KSM

2 Code
5,000 KsM for Milestone 1 only

B: Quick code

C, C++, D
Swift, Rust
Zig, Carbon
Fortran

500,000 DOT+5,000 KSM

D: Correct code
Ada, Julia, Smalltalk
Erlang, Elixir

Ocaml, APL

Scala, F#

500,000 DOT+5,000 KSM

Brainfuck, Whitespace, Redstone

15. The
JAM TOASTER

Facilitating a data-driven
approach for an optimally
parameterized protocol

16,384 AMD TR 5 GHz cores

16 GB total L2 cache
32 TB RAM, 8 channel
20 PB secondary storage

10 Tbps ethernet switching

16. Overview The Core Model

JAM is generally coherent with transient decoherence
In-core (DDL access, stateless) + on-chain (sync, stateful)
The basis of coherency: Services: Refine /Accumulate
Inter-core DDT using DDL

In-core state data lookup and lookup-anchor

17. Overview The JAM Concept

e Shared state is arranged into Services

e Creation of a service is permissionless

e Services have a single piece of code with 3 entry points:
© refine: Do the rollup (stateless except for DDL & SL)
© accumulate: Integrate the output into shared state
© on_transfer: Accept some memo/tokens from some other service

18. JAM is Permissionless

e JAM-chain hosts services’ code, data and state

e Introducing a new service is permissionless
Services are limited in their code, data and state only by
deposit requirements

e Example service: “Parachains” (i.e. “Polkadot 1.0”)

19. JAM is Transactionless

e Notransactions.

e Still extrinsic information; five types:
o Guarantees (reports of the output from refine computation)
o Assurances (attestations of the availability of Work Packages)
o Judgements (dispute outcome)
o Preimages (lookup data which a service has requested)
o Tickets (anonymous entries into future block production lottery)
e Minimal opinionation

20. Overview Service model

e Refine
Accepts up to 12MB of data (extrinsic and DDL)
Yields up to 48KB of data
May execute for 5-6 seconds of PVM gas
Gets contextual information on other contents of Work Package
May make preimage lookups, invoke PVMs
e Accumulate
o Accepts multiple outputs from Refine
o May execute for up to 10ms of PVM gas per output
© Stateful: may transfer funds, alter state, read other services’ state
o May create services and upgrade its code and request preimage availability
e OnTransfer
o Stateful: may alter state and read other services’ state

60000

21. Overview The PVM and Gas

Based on RV32ECM RISC-V ISA

13 register machine (1 zero, 2 reserved for O/S)
Little-endian, 32-bit registers, 32-bit addressable RAM
RAM is segmented (4KB pages, TBC) and faultable
Recompiles well to x86/x64

64-bit gas; ~50% native performance

Metering costs ~5-10%, optimistic to have good WC corr.

22. JAM Authorization Model

@ Work Packages are atom of work (12MB/5-6s Refine +
48KB/10ms/10k IOPs Accumulate), associated with a JAM core
Authorizer mapping t—Auth associated with each of 341 JAM cores
Authorizers are arbitrary code mapping Work Package to Boolean
Work Package WP only valid if core's Auth[ core] (WP)=true
Coretime sold in monthly chunks

Chunks can be subdivided & straddled before Authorizer assignment
Secondary market encouraged

23. Overview JAM Limits

Node:

e 500Mbps+ up/down

e 16-core AMD TR or equiv

e RAM: 64 GB, 8 channel ; SSD: 2x4 TB M.2 NVMe, 750k IOPS read
JAM:

e -150x native CPU (~600Gop/s)
e DDL: 682MB/s I/O; 1.7 PB total
e Sync DB: 16MB/s, 1M DBop/s

24. Agnostic to
Staking,
Economics,
Governance

25. FORTE

ofyork