HackMDGav's Unofficial JAM Prize Notes
THIS IS UNOFFICIAL!
For the official prize documentation, see https://jam.web3.foundation/
For news on the protocol, see https://graypaper.com/
For an unofficial list of JAM implementation teams, see https://jamcha.in/clients
Judge's decision is Final
Judges: The Polkadot Fellowship, excluding members involved in the implementation being voted on.
Rules
- Prizes for languages delivered in the set only.
- For languages not in the set, an application may be made including the set you propose, why that set is sensible and why the language is sufficiently different from the others to be valuable.
- Code must be idiomatic for languages which define idiom.
- Clean-room implementation using the Graypaper and public implementor chat channels as the only resource. (Additional materials may be added here at a later stage.)
- Any Jam-implementation code which is viewed before or during implementation must be declared.
- Relevant private (not in the public implementors channel) conversations with other implementors must be declared and summarised.
- Generative AI must not be used in any substantive way.
- Prize may be reduced in case collusion may be sufficient to reduce network security.
- If concerned then declarations may be stated up-front and the maximum reduction set; as long as declarations are accurate and no further collusion happens, then reduction proportion will be the maximum.
- Interview may be requested after submission to ensure team members are the legitimate authors of the code. This precludes the use of generative AI.
- Interview will seek to ensure the individual has definitive expertise on both the Graypaper and their own codebase. INABILITY TO PROVE THIS EXPERTISE MAY RESULT IN A REDUCED PRIZE OR FULL DISQUALIFICATION.
- A clear Git history and public, credibly timestamped commits is necessary in order to help evidence organic code development.
- Timestamps may be by virtue of pushing code to Github on a timely basis.
- For code developed in private, commit hashes should be placed, in a timely fashion, on a major public blockchain and readily visible on a block explorer.
- Any individual may only be part of one team's prize-claim per milestone only.
- e.g. An individual may not be a part of two claims to two implementations' milestone 1. Only the first is claimable.
- APPARENT LACK OF ORIGINALITY, UNDECLARED COLLUSION AND SUSPECTED PLAGIARISM MAY RESULT IN DISQUALIFICATION ENTIRELY AT THE DISCRETION OF THE JUDGES.
- Appeals may be made though a governance reference on the Polkadot Wish For Change track and the result will be respected by Polkadot Fellowship.
- Implementations must pass all relevent public and private conformance/performance tests.
- Prizes are paid no earlier than the ratification, by the Polkadot Fellowship, of version 1.0 of the JAM protocol.
- Prizes paid on first-come-first-served basis.
- Prize pots may be redistributed in the case of a pot approaching depletion but:
- only with a 3 month period of notice;
- only at most 25% may be scheduled for redistribution at a time.
- Prizes will be composed of fully-liquid and vested tokens. The specific ratio and vesting schedule is yet to be confirmed. Vesting tokens will be usable for staking and voting.
- One full milestone prize (100,000 DOT + 1,000 KSM) will be reserved for Milestone 5 (M5) in each language set; two full milestone prizes for M4 in each language set, three full milestone prizes for M3, four full milestone prizes for M2.
Prizes
- Total pot: 10,000,000 DOT, 100,000 KSM
- Pot per A-D language set: 2,500,000 DOT, 20,000 KSM
- Pot for Z language set: 20,000 KSM
The Paths
Three paths to prizes exist:
- Validating node. Maximum prize: 500,000 DOT + 5,000 KSM
- Non-PVM validating node. Maximum prize: 350,000 DOT + 3,500 KSM (a conversion option exists though)
- Light node. Maximum prize: 250,000 DOT + 2,500 KSM
In all paths the first milestone (M1, MN1, ML1) is the same.
In all paths third-party libraries for low-level primitives not specific to the JAM protocol are acceptable, such as:
- cryptographic primitives (erasure-coding, Bandersnatch, Ed25519)
- binary codec
- databases
- low-level networking stack (e.g. QUIC).
Following the accepted completion of each milestone, one developer may be promoted to the rank commensurate with their code and protocol contributions regardless of regular time requirements. The promotion should be in line with regular interpretation of the Manifesto except for the time requirements (which are disregarded). The maximum rank to be attained in this way shall be III Dan (Fellow).
Following completion of M1/MN1/ML1, evidence for Polkadot Fellowship rank-retentions (and, where applicable, promotions) may include regular, meaningful contributions to the project.
Validating Node Path
Maximum prize for completing this path: 500,000 DOT + 5,000 KSM
This path involves the creation of a full validating, block-authoring implementation of JAM including a working and performant PVM.
PVM execution, trie/DB, signature-verification and availability (EC/DB) performance tests are requirements and will be run on a standard hardware.
Following completion of M2, teams receive a login to their own instance of the standard hardware on which to make unit benchmarks of their performance.
Following completion of M3, teams receive time/slots on the JAM TOASTER to trial and debug overall emergent activity.
Following completion of M4, implementations may apply for a professional external audit at no cost.
Five milestones (each implies the ones before):
- (M1) IMPORTER: State-transitioning conformance tests pass and can import blocks: 100,000 DOT + 1,000 KSM
- (M2) AUTHORER: Fully conformant and can produce blocks (incl networking, off-chain): 100,000 DOT + 1,000 KSM
- (M3) HALF-SPEED: Conformance and 50% of required performance (including PVM impl): 100,000 DOT + 1,000 KSM
- (M4) FULL-SPEED: Conformance and 100% of required performance (including PVM impl): 100,000 DOT + 1,000 KSM
- (M5) SECURE: Fully audited: 100,000 DOT + 1,000 KSM
Non-PVM Validating Node Path
Maximum prize for completing this path: 350,000 DOT and 3,500 KSM (though a conversion path exists to increase this to 450,000 DOT and 4,500 KSM – see below)
This path involves the creation of a full validating, block-authoring implementation of JAM including an original working PVM. For the purpose of performance testing, a third-party PVM implementation may be used to help achieve the required performance.
Only half of the regular milestone prizes are paid for this path's Milestones 3, 4 and 5.
Trie/DB, signature-verification and availability (EC/DB) performance tests are still requirements and will be run on a standard hardware.
Following completion of MN2, teams receive a login to their own instance of the standard hardware on which to make unit benchmarks of their performance.
Following completion of MN3, teams receive time/slots on the JAM TOASTER to trial and debug overall emergent activity.
Following completion of MN4, implementations may apply for a professional external audit at no cost.
Five milestones (each implies the ones before):
- (MN1) IMPORTER: State-transitioning conformance tests pass and can import blocks: 100,000 DOT + 1,000 KSM
- (MN2) AUTHORER: Fully conformant and can produce blocks (incl networking, off-chain): 100,000 DOT + 1,000 KSM
- (MN3) HALF-SPEED: Conformance and 50% of required performance (not including PVM impl): 50,000 DOT + 500 KSM
- (MN4) FULL-SPEED: Conformance and 100% of required performance (not including PVM impl): 50,000 DOT + 500 KSM
- (MN5) SECURE: Fully audited: 50,000 DOT + 500 KSM
Once completed, a full implementation including full-performance PVM may be submitted at a later date for peformance testing and auditing in a nominal milestone 6 (MN6). In the event it fulfills both performance tests and passes a professional audit then a further 100,000 DOT + 1,000 KSM may be paid.
Light-node
Maximum prize for completing this path: 300,000 DOT and 3,000 KSM
This path involves the creation of a low-resource JAM node not capable of block-authoring, but capable of servicing network requests, suitable for embedding in other program code (such as tooling and web pages) and an extremely low footprint and synchronisation time.
Footprints and resource usage for a variety of standard tasks will be tested on a standard hardware and must complete in sufficiently low time, CPU utilisation, memory utilisation, storage utilisation and network utilisation. Resource usage should be broadly in line with smoldot.
Following completion of ML1, teams receive a login to their own instance of the standard hardware on which to make unit benchmarks of their performance.
Following completion of ML2, implementations may apply for a professional external audit at no cost.
Five milestones (each implies the ones before):
- (ML1) IMPORTER: State-transitioning conformance tests pass and can import blocks: 100,000 DOT + 1,000 KSM
- (ML2) FULL-SPEED: Conformance and 100% of required performance: 50,000 DOT + 500 KSM
- (ML3) SECURE: Fully audited: 100,000 DOT + 1,000 KSM
There are several additional rules for prizes given on this path:
- 4 ML2 payments are reserved in each language group.
- Exactly 2 ML3 payments are available in each language group.
- ML3 payments must belong to separate languages.
- On reaching ML2, teams may reserve their ML3 place for a period of 6 months to complete the audit and bring their node up to date with the protocol if needed. If no successful ML3 candidate is submitted during that period then another ML2-passing team may reserve and submit. Reservations are processed on a first-come-first-serve basis.
Prize payment
Prizes are paid to the earliest account IDs stated in the repository's README. In the case of a tie, payment is split equally. Local (Swiss) law requires that Web 3 Foundation take KYC/AML information on the recipient together with proof of account control.
Language Sets
Unless otherwise stated, major language dialects are acceptable.
The language set of an implementation is determined as the language in which its business logic is written. Peripheral, performance-bottleneck components of an implementation may be written in a higher-performance language without any impact on the consideration of language set. A non-exhaustive list of such components include:
- PVM
- Database
- Erasure (de-)coding
A: "Company code"
(Maximum) Prize per milestone: 100,000 DOT + 1,000 KSM
- Java, AspectJ, Kotlin
- C#
- Go
B: "Native code"
(Maximum) Prize per milestone: 100,000 DOT + 1,000 KSM
- C, C++, D
- Rust
- Swift
- Zig
- Carbon
- Fortran
C: "Concise code"
(Maximum) Prize per milestone: 100,000 DOT + 1,000 KSM
- Scheme, Common Lisp, Prolog, Haskell, ML
- Perl, Python, Ruby
- Javascript
- Groovy
- Dart
D: "Correct code"
(Maximum) Prize per milestone: 100,000 DOT + 1,000 KSM
- Ada
- Julia
- Erlang/Elixir
- Ocaml
- Smalltalk
- F#
- Scala
- APL
Z: Mad
(Maximum) Prize per milestone: 5,000 KSM
- Brainfuck
- Whitespace
- Minecraft Red-stone
Advice
Begin in order:
- Block/header data structures and serialization
- State data structures and serialization
- In-memory DB and Merklization
- Non-PVM block execution/state-transition
- PVM instancing, execution and host-functions
- Block-import tests
FAQs
Q: Clean room?
A: Cooperation between teams is essential but anything which goes beyond trivial misunderstandings of the graypaper should be documented, either as issues in the GP repo or as side notes of the implementation to be submitted at the time of milestone review. To stay safe, teams should stay away from the implementation specifics of other implementations and definitely not be sharing code.
It's ok to ruminate on high level approaches to solve problems or optimize, it's not so ok to be looking at some other implementation's specific solution.
What the Fellowship will be looking out for is for undeclared collusion between teams. Code which appears to be a little too similar for it to have been independently written. A big red flag would be the same bug popping up in two implementations.
But this is not to detract from the fun of getting two cleanroom impls talking to each other. Of course this is a big part of it and you mustn't feel like it's not allowed.
Just be sure to document anything which you discover when working alongside another team so everyone can benefit.
Q: This all sounds too risky for me. Can we not have something closer to a regular service agreement?
A: No.
Q: Roughly how long will it take my developer/team to implement Milestone X?
A: How long is a piece of string? Seriously, read the Graypaper and decide yourself. Every developer is different.
Q: Does my implementation need to exploit JAM's asynchrony?
A: We don't explicitly state what code paths need be asynchronous. It is up to implementations to decide this for themselves.
To clarify, for M2, nodes are expected to provide (and use) information in a timely fashion; this goes for all aspects of block authoring and production. Needless not providing an assurance or guarantee, or not using one which was provided is incorrect behaviour.
