The description and formal specification of the Jam protocol, a potential successor to the Polkadot Relay chain.
Build with xelatex.
- Rewards. WAITING ON AL
- Make all subscript names capitalized.
- Ensure all definitions are referenced.
- Link and integrate to Bandersnatch RingVRF references (Davide/Syed) IN-PROGRESS
- All "where" and "let" lines are unnumbered/integrated
- Remove any "TODOs" in text
- Define Erasure Coding proof means
- Define binary Merkle proof-generation function which compiles neighbours down to leaf.
- Define binary Merkle proof-verification function exists sequence of values which contains our value and Merklised to some root.
- Improve audit spec
- Announcement signatures
- How to build perspective on other validators with announcements
- Discussion and Conclusions/Further Work
- Security assumptions: redirect to ELVES paper
- Creating a parachains service: further work (RFC for upgrade perhaps)
- Key differences
- limited size of Work Output vs unlimited candidate receipt
- Laissez-faire on Work Items vs requirement for valid transition
- Hermit relay (staking &c is on system chains)
- Supporting liveness
- Supporting *MP
- No need for UMP/DMP
- Key differences
- Compare with danksharding v1
- Deeper talk Cost & latency comparison with RISC0-VM and latest ZK stuff.
- Beefy root and accumulate-result hash.
- Judgements
- Using posterior assignments.
- optional
on_reportentry point - Remove assignments from state - no need for it to be there as it's derivable from
$\eta_2$ alone. - Work Package should be Merklized on pre-stated boundary points.
- Add BoundedVec<(ServiceId, u32, u32), MAX_POINTS> to WorkPackage
- Construct Merkle trie for Work Package and put root in IsAuthorized
- Think harder about if the recent blocks, availability timeouts & anchor stuff is affected by using timeslot rather than height.
- Make memo bounded, rather than fixed.
- Lookup anchor: maybe it should be 48 hours since lookup anchor can already be up to 24 hours after reporting and we want something available up to 24 hours after that?
DA lasts 28 days instead of 24h.
WP has additional field manifest: Vec<ManifestEntry>:
struct Commitment {
hash: Hash,
len: u32,
erasure_root: Hash,
}
type CommitmentTreeRoot = Hash; //binary Merkle tree of `Commitment` leaves
struct HashCommitment {
len: u32,
hash: Hash,
}
enum PackageManifestEntry {
Export(Vec<u8>),
Import(Commitment),
Renew(Commitment),
ExportCache(Vec<u8>),
ImportCache(Hash),
RenewCache { len: u32, hash: Hash },
}WR specification has extra field of type manifest_root: CommitmentTreeRoot.
Affinity for validator indexes minimizes renewal xfer costs.
Guarantor ECs WP, each proc-export/export/renewal; checks each import chunk is available for > 8h and fetches. Guarantor distributes chunks of proc-exports/exports/renewals. Auditor:
- downloads/reconstitutes WP and all nodes of
manifest_rootand downloads/reconstitutes all exports/renewals. - ECs WP/exports/renewals
Guaranteeing involves:
- Fetching/Reconstucting all Imports & Renews
- Fetching all ImportCaches & RenewCaches
- Executing
- ErasureCoding all Exports & GenExports & Renews
- Distributing chunks of all Exports & GenExports & Renews
- Hashing all ExportCaches & GenExportCaches
- Distributing data of all ExportCaches & GenExportCaches & RenewCaches
- Merklizing ErasureRoots/Hashes to create WR's
manifest_root
Auditing involves (10 of):
- Fetching/Reconstucting all Exports, Imports & Renews
- Fetching all ExportCaches & RenewCaches
- ErasureCoding all Exports (Renews & Imports should already be audited)
- Executing
- ErasureCoding all GenExports
- Hashing all GenExportCaches
- Merklizing ErasureRoots/Hashes to verify WR's
manifest_root
refine has new host-call:
export(payload: &[u8], cache: bool)- Calling this introduces an additional node in the manifest tree (
manifest_root), iff the overall manifest size is constraints would break then the call fails. The WP does not become invalid.
refine has new argument:
, manifest_payloads: Vec<(Hash, Vec<u8>)>
const BASE: u32 = 2048; // Example - might be less.
let dist = |WP| + SUM_{Export(payload) in M}(payload.len() + BASE) + SUM_{Renew(c) in M}(c.len + BASE) + SUM_{ExportCache(c) in M}(c.len() * 341 + BASE) + SUM_{RenewCache{len, ..} in M}(len * 341 + BASE)
let ecode = |WP| + SUM_{Export(payload) in M}(payload.len() + BASE) + SUM_{Renew(c) in M}(c.len + BASE) + SUM_{ExportCache(c) in M}(c.len() * 341 + BASE) + SUM_{RenewCache{len, ..} in M}(len * 341 + BASE) let reco = |WP| + SUM_{Import(c) in M, Renew(c) in M}(c.len + BASE)
WP is valid iff: max(dist, reco) <= 8MB WP is available iff: all imports are in DA now and will still be in DA 8 hours from now
- Proper gas schedule.
- Networking protocol.
- Off-chain sub-protocols:
- Better integration to Grandpa
- Better description of Beefy
- Full definition of Bandersnatch RingVRF.
- Independent definition of PVM.
- PVM:
- Aux registers?
- Move to 64-bit?
- No pages mappable in first 64 KB
% No persistent distance between parts as in eth, cos, dot etc
% A set of independent, sequential, asynchronously interacting 32-octet state machines each of whose transitions lasts around 2 seconds of webassembly computation if a predetermined and fixed program and whose transition arguments are 5 MB. While well-suited to the verification of substrate blockchains, it is otherwise quite limiting.
- Edit Previous Work.
- Edit Discussion.
- Document guide at beginning.
- Move constants to appendix and define at first use.
- Context strings for all signatures.
- List of all context strings in definitions.
- Remove header items from ST dependency graph where possible.
- Update serialization
- For
$\beta$ component$b$ - implement MMR encode. - Additional field:
$\rho_g$
- For
- Link and integrate to RISCV references (Jan) HAVE SPEC
- Link and integrate to Beefy signing spec (Syed)
- Link and integrate to Erasure-Coding references (work with Al)
- Grandpa/best-block: Disregard blocks which we believe are equivocated unless finalized.
- Other PVM work
- Define
sbrkproperly: - Update host functions to agreed API.
- Figure out what to do with the jump table.
- Define
- Define inner PVM host-calls
- Spec below
- Figure out what the
$c_i$ /$c_b$ are - Avoid entry point
- Ensure code and jump-table is amalgamated down to VM-spec
- Move host calls to use register index
- Update serialization for Judgement extrinsic and judgements state.
- Define Beefy process
- Accumulate: should return Beefy service hash
- Define Keccak hash
$\mathbb{H}_K$ - Remove Beefy root from header
- Put the Beefy root into recent blocks after computation
- Recent blocks should store MMR of roots of tree of accumulated service hashes
- Define an MMR
- Add \textsc{bls} public key to keyset (48 octet).
- Specify requirement of validators to sign.
- Define audit process.
- Erasure coding root must be correct
- This means we cannot assume that the WP hash can be inverted.
- Instead, we assume that we can collect 1/3 chunks and combine to produce some data
- Then we check:
- if that hashes to the WP hash.
- if the erasure-coded chunks merklise into a tree of the given root.
- If so we continue.
- NOTE: The above should be done in guarantor stage also.
- Auditing: Always finish once announced.
- Judgements: Should cancel work-report from Rho prior to accumulation.
- Signed judgements should not include guarantor keys;
- Judgement extrinsic should use from rho.
- Check "Which History" section and ensure it mentions possibility for reversion via judgement.
- No reversion beyond finalized
- Of unfinalized extension, not block containing work-reports which appear in the banned-set of any other (valid) block.
- Prior work and refine/remove the zk argumentation (work with Al)
- Disputes state transitioning and extrinsic (work with Al)
- Finish Merklization description
- Bibliography