ToDo

• [x] Update Lucid

  • [x] Update the lucid to reflect v2 (and retain the old)
  • [x] Add diagrams to v1/v2 specs like we had in old spartan docs using lucid

• [ ] Extend consensus spec

  • [x] Seperate the notion of reward address from signing address

  • [x] Update the randomness generation from BABE to C-Correlation (fully implemented)

  • [ ] Include a new section on voter extrinsics and voter chains (partially implemented)

    1. We have votes, that do nothing but increse the reward frequency

    2. Later, votes will be sorted to voter chains and reduce confirmation latency following the Prism protocol (paper, lecture, Rust impl, Lei Yang)

    3. Incentive compatible reward sharing between proposer and voter blocks

       Prism Incentives.pdf

  • [x] iii. Proof-of-Time: adapt Srivatsan’s documents to be a proper part of the spec

• [ ] New specs to write

  • [x] sync protocol (Jeremiah working on this w/Ved + Nazar)
  • old DSN description (updated + formalized)
  • [x] DecEx / Domains → in design phase (Jeremiah + Ved + Liu-Cheng)

• [ ] Long Term — Subspace Master Architecture Document (independent of Subnomicon)

  • [ ] Overview + Naming Scheme
  • [ ] Consensus Specification
  • [ ] Distributed Storage Spec
  • [ ] Execution + Domains Spec
  • [ ] Scalability (Sketch)
  • [ ] All snapshotted and on GitHub

• [ ] Setup SIP in Notion to start, then Github

  • [ ] Need to define what constitutes a meaningful change
  • [ ] New upgrade/idea/feature stats as a design document / summary
  • [ ] Internal review process
  • [ ] PR to change the formal spec
  • [ ] Result in the actual code change
  • [ ] Start as notion, eventually have Github Repo for SIP/SRC (by mainet launch)
    • Protocol Engineering
    • Community
    • R&D → Subspace PARC

• [ ] Open Research Agenda — PARC

  • Publish papers
  • Prove formal security
  • New protocol upgrades (zk-proofs)

• [x] Finalize the Formal Subspace Specification (Consensus)

  • [x] Read and review, such that it makes sense. Resolve open questions with Nazar and extend the spec to answer questions which were obvious to team but not to readers.
  • [x] Compare the specification to the actual implementation to ensure they match, documenting where they do not. Code does not match spec → github issue to resolve Spec does not match code → validate and update the spec
  • [x] Confirm that epoch, eon, era have all been implemented (spec says they are TBD)
  • [x] Update the Design