Skip to main content

Six-Week Study Plan

1. Why This Chapter Exists​

The previous chapters cover the surface of zcash/orchard non-linearly. This chapter weaves them into a six-week plan that ends with the reader opening a small PR. The plan assumes eight to ten hours per week.

2. Definitions​

Definition 2.1 (Course Output)​

The deliverable at the end of week six is a pull request against zcash/orchard that compiles, passes CI, and addresses a real issue (one of the candidates in Chapter 2).

3. The Code​

3.1 Week 1: Orientation​

  • Read Chapter 1 and Chapter 2.
  • Build the crate at the pin (f8915bc) and run cargo test.
  • Note which tests are slow. Run them in --release.
  • Open src/lib.rs and draw the module-dependency graph by hand.

3.2 Week 2: Curves and Halo 2​

  • Read Chapter 3 and Chapter 4.
  • Write a scratch binary that creates a Pallas point and a Vesta point, multiplies each by a sampled scalar, and prints the result. Type-check the binary.

3.3 Week 3: Algebraic Hashes​

  • Read Chapter 6 and Chapter 7.
  • Run cargo bench --bench small and identify which computation dominates the bench.
  • Add a unit test in src/note/nullifier.rs that exercises an edge case (zero nk, zero rho); commit nothing.

3.4 Week 4: Keys, Notes, Tree​

  • Read Chapter 8, Chapter 9, Chapter 10, and Chapter 11.
  • Derive five diversified addresses from a seed and confirm uniqueness in a scratch test.
  • Insert ten leaves into an incrementalmerkletree frontier and recompute the root.

3.5 Week 5: Bundle, Value, and Signature​

3.6 Week 6: Composition, Audits, and the First PR​

  • Read Chapter 18: how Actions compose into a single bundle-level state transition; what an on-chain observer sees; replay protection.
  • Read Chapter 15, Chapter 16, and Chapter 17.
  • Pick one open issue from Chapter 2.
  • Write a one-paragraph plan, post it as a comment on the issue, wait for a maintainer signal, then open the PR.

3.7 Optional Week 7: Research Frontier​

For readers who want to contribute at the protocol level, not just at the API level. Skip if the goal is purely engineering contributions.

  • Read Chapter 19 for the open questions and improvement vectors.
  • Pick one of: a proof-system swap (KZG, Nova, HyperPlonk), a circuit shape change (a smaller K, a unified Sinsemilla/Poseidon chip), or a privacy primitive (post-quantum hybrid KEM, padding distribution).
  • Sketch a one-page proposal citing the relevant paper(s) from Chapter 19 Section 3.7. Post it as an issue on zcash/zips for protocol-level change or zcash/orchard for crate-level change.

3.8 An Alternative: The Researcher Track​

A cryptography researcher can read in a different order. The suggested track is:

  1. Start with References Index and Chapter 19, Section 3.7 for the reading list.
  2. Read the Halo 2 Book in full; come back to Chapter 4 only as a navigation aid.
  3. Read Chapter 5 Sections 3.6 to 3.8 for the design trade-offs and the recursion status.
  4. Read Chapter 18 for the security model the proof must support.
  5. Use Chapter 17 and Chapter 19 as gateways into the open audit reports and the open research questions.

4. Failure Modes​

  • Bypass weeks. Each week assumes the previous weeks' exercises landed. The build test in week 1 catches a stale toolchain; skipping it produces hard-to-debug failures later.
  • Pick a too-large issue. The candidate first PRs were chosen because they are scoped to one or two files. A "fix all clippy warnings" PR is a different kind of work and should be the second PR, not the first.
  • Skip the maintainer signal. Open issues with old threads (S-waiting-on-review) may be stalled for reasons not visible in the thread. A comment on the issue before opening the PR avoids duplicate work.

5. Spec Pointers​

  • CHANGELOG.md: read it whole before week 6.
  • Issue tracker: re-read the top of the list each week; new issues land regularly.

6. Exercises​

The end-of-course test. The reader should be able to answer each in a paragraph.

  1. What are the public inputs and the private witness of an Orchard Action, and why is each one needed?
  2. Why is the Action circuit a single proof per bundle, not per Action?
  3. Which generators are used by Sinsemilla, Poseidon, RedPallas (per flavour), and the Pedersen value commitment? Where in the source are they defined?
  4. How does ZIP 32 for Orchard differ from BIP 32, and why?
  5. Which dependencies of orchard would invalidate consensus if they changed semantics, and which would only change performance?

If a question is unclear, return to the corresponding chapter and re-read the file it points at.

7. Further Reading​

  • The Orchard Book for an alternative high-level walkthrough.
  • The Halo 2 Book for the proof system at depth.
  • The Zcash blog for the ongoing protocol decisions that affect Orchard.