How My Thesis on ZK-SNARKs Became My Entry Point Into Deeper Systems Work

Why this stopped feeling like just a thesis
The problem that kept bothering me
What I actually built
How the prototype worked
The trade-offs I had to accept
Why this project changed how I think

What started as a graduation requirement ended up becoming my first real step into deeper systems work.

At the beginning, I was just trying to finish my final thesis properly, graduate, and move on.

But somewhere in the process, this project stopped feeling like an academic requirement and started feeling like something I genuinely cared about.

I built this thesis at Gunadarma University, and I want to sincerely thank Dr. Avinanta Tarigan for the guidance and support throughout the process. The topic was not easy to approach, and that support mattered a lot.

The title of my thesis was:

PENERAPAN ZK-SNARK DALAM PRIVASI NILAI KOMPETENSI PADA PUBLIC BLOCKCHAIN DI LINGKUNGAN PENDIDIKAN TINGGI

Behind the formal title was a simple question that kept bothering me:

Why should someone have to reveal their exact academic score just to prove they meet a requirement?

1 · Why this stopped feeling like just a thesis

Many student projects focus on features. Some become CRUD apps, some become mobile apps, and some explore AI. I wanted to build something that touched a more fundamental problem.

Education felt like the right place to explore that.

It deals with sensitive information, but many academic verification flows still rely on centralized trust and full data exposure. If the real question is only whether a student meets a minimum requirement, then revealing the exact score feels excessive.

That idea became the center of my thesis.

Not how to hide everything, but how to reveal only what is necessary.

2 · The problem that kept bothering me

Traditional academic verification is usually simple:

an institution holds the score data
a student requests or shares their result
a third party verifies it
the exact score often gets exposed in the process

That works, but it does not respect privacy very well.

If a verifier only needs to know whether I passed a threshold, then why should they also know the exact number?

That question led me to ZK-SNARKs.

The moment I understood the idea, everything started to click. A system could prove that a student’s score met a required minimum while keeping the exact score private.

For example, the system could prove:

“This student’s competency score is above 75.”

without revealing whether the real score was 76, 84, or 93.

3 · What I actually built

This was not just a conceptual paper for me. I built a solo, full working prototype.

The system involved three main actors:

University or institution as the issuer of the academic result
Student as the prover
Third-party verifier as the party checking whether the requirement was met

The prototype focused on one concrete claim: proving that a student’s score was above a threshold without revealing the exact score itself.

That distinction matters. I was not trying to hide everything or build a full production-ready academic platform. I wanted to show that selective disclosure in an academic context was possible.

4 · How the prototype worked

At a high level, the flow looked like this:

institution issues the score → student requests proof → proof is generated off-chain → proof is verified on-chain → verifier receives the result

The split between off-chain and on-chain was intentional.

Off-chain

Sensitive academic data stayed off-chain. This included the private score used to generate the witness and proof. The heavier proving process also happened off-chain, which is where that work belongs.

On-chain

The verification step happened on Ethereum Sepolia, which I used as a public Ethereum testnet for prototype validation.

That part helped me demonstrate a real verification flow on a public blockchain without pretending it was production. In this design, the blockchain was not there to store grades. It was there to act as a verification and integrity layer.

5 · The stack behind it

The stack I used was:

React for the frontend
NestJS for the backend
BullMQ for background processing
Redis for queue support
PostgreSQL for structured data storage
ZoKrates for the circuit and proof workflow
SnarkJS for proof and verifier interoperability
Ethereum Sepolia as the public testnet for verification

I ended up using a hybrid stack because the problem itself was hybrid. Part of the system looked like a normal web application, part behaved like a cryptographic workflow, and another part had to interact with a public blockchain carefully.

That taught me something quickly:

blockchain cannot be the center of everything.

The application still needed a normal backend, storage, queues, and orchestration. The blockchain part only made sense where verification and integrity actually mattered.

6 · The trade-offs I had to accept

This project forced me to think beyond “can I make it work?”

1. Privacy vs simplicity

ZK-SNARKs make selective disclosure possible, but they also add a lot of complexity. The system becomes harder to explain, harder to reason about, and harder to build than a normal academic application.

2. Public verification vs private data

Public blockchain can verify things transparently, but it is not where private academic data belongs. The score stays off-chain. The proof is what moves into the verification layer.

3. Trust minimization vs full trustlessness

I also had to be honest about limitations. This prototype demonstrates a privacy-preserving verification flow, but it does not remove every trust assumption. The institution still matters as the source of the original academic data, and the zk-SNARK approach I used also comes with a trusted setup assumption.

So I do not describe this as fully trustless. I describe it as a prototype that shows the feasibility of private academic claim verification on a public blockchain.

4. Research depth vs benchmarking

One thing I intentionally did not focus on was measurement. Benchmarking proof generation time, gas usage, or deeper performance characteristics was outside the scope of my thesis. My goal was to prove that the flow could work end to end, not to make production-scale claims I could not defend.

7 · Why this project changed how I think

The hardest part for me was not the implementation itself. It was the research.

At the time, I felt there were not many implementation references that matched exactly what I was trying to build. There were explanations about zero-knowledge proofs in theory, and there were technical resources for specific tools, but turning those ideas into a complete academic-system prototype took a lot of digging.

That learning curve changed how I think as an engineer.

Before this, I mostly thought about systems in terms of APIs, databases, UI, and business logic. This project pushed me toward deeper questions:

how do we prove things without oversharing?
what belongs on-chain and what should stay off-chain?
how should trust be distributed in a system?

That is why I do not see this as just my thesis anymore.

I see it as my entry point into deeper systems work.

If there is one thing I took away from this project, it is this:

Privacy should not always mean hiding everything, and verification should not always require revealing everything.

Sometimes the better system is the one that proves less, exposes less, and still gives enough confidence to the people involved.

Table of Contents