Gav'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.

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 Path

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).

Gas, trie/DB, signature-verification and availability (EC/DB) performance tests are requirements and will be run on a standard hardware.

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 (1), evidence for Polkadot Fellowship rank-retentions (and, where applicable, promotions) may include regular, meaningful contributions to the project.

Following completion of (2), teams receive a login to their own instance of the standard hardware on which to make unit benchmarks of their performance.

Following completion of (3), teams receive time/slots on the JAM TOASTER to trial and debug overall emergent activity.

Following completion of (4), implementations may apply for a professional external audit at no cost.

Five milestones (each implies the ones before):

1. IMPORTER: State-transitioning conformance tests pass and can import blocks.
2. AUTHORER: Fully conformant and can produce blocks (incl networking, off-chain).
3. HALF-SPEED: Conformance and Kusama-level performance (including PVM impl).
4. FULL-SPEED: Conformance and Polkadot-level performance (including PVM impl).
5. SECURE: Fully audited.

Prizes are paid to the earliest Polkadot/Kusama 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:

1. Block/header data structures and serialization
2. State data structures and serialization
3. In-memory DB and Merklization
4. Non-PVM block execution/state-transition
5. PVM instancing, execution and host-functions
6. 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.