Back to portfolio
Technical & SecuritySimulated project

ZK Engineer / Cryptography Researcher portfolio brief

A simulated technical & security exercise for ZK Engineer / Cryptography Researcher. Treat it as realistic practice, not real client or protocol work.

Objective

Choose the engineering or research track explicitly

Expected deliverables

Circuit or proof-system implementationBenchmark suiteResearch note or paperSecurity assumption mapOpen-source contributionIntegration guide

Recommended workflow

  1. Choose the engineering or research track explicitly
  2. Reproduce one result or build one circuit
  3. Publish code, methodology, assumptions, and limitations
  4. Review the result against the rubric, then package it as a case study.

Constraints and safety

  • Use only public sources or clearly simulated data.
  • Never include seed phrases, private keys, or wallet secrets.
  • Redact private user, company, security, legal, or compensation information.
  • State every assumption you make.

Tools in practice

Rust, C++, Python, or relevant languages
Collect and analyse the evidence used in circuit or proof-system implementation and benchmark suite, with definitions and reproducible steps.
proof-system frameworks
Implement circuits, proving and verification flows, recursion, and integration tests in the selected proof system.
formal tools
Check selected algebraic, logical, or security properties and document the limits of the verification.
GitHub
Review source, manage branches and pull requests, run tests, and leave implementation or security decisions in a traceable history.
paper and benchmark tooling
Reproduce published results, record hardware and parameter assumptions, and compare performance with a transparent methodology.
specialized hardware where relevant
Benchmark proving workloads on GPUs, FPGAs, or other accelerators when hardware materially affects cost or latency.

What a strong submission shows

  • A small circuit and benchmark
  • An implementation contribution
  • A paper reproduction
  • A research note explaining assumptions and trade-offs

Weak submission patterns

  • A tutorial copied without understanding
  • Benchmark claims with no hardware or method
  • Using 'cryptographer' for routine integration work

Review rubric

  • Accuracy of claims and sources
  • Relevance to the target role
  • Decision quality and trade-offs
  • Completeness of the deliverable
  • Clarity of communication
  • Honest limitations and next steps

Present it as a case study

  • Explain the problem, sources, decisions, ownership, constraints, output, review, and what you would change.
  • Show the final artifact before the process notes.
  • State what you owned and what belonged to other people.
  • Label the work as simulated, and keep any real contribution clearly separate.

Interview questions this project helps you answer

  1. Where do ZK engineering and cryptography research overlap, and where do they require different evidence?

  2. What does a proof establish, and what does it not establish about the surrounding system?

  3. How would you evaluate a performance claim across proving systems?

Turn this into an application