DEV Community

Nicola Lorenzini
Nicola Lorenzini

Posted on

From Local AI to Ethereum: Building a Verifiable Knowledge Proof with MyZubster

From Local AI to Ethereum: Building a Verifiable Knowledge Proof with MyZubster

Over the last few weeks, I've been experimenting with a simple question:

Can the things I learn and build become verifiable evidence instead of just claims on a profile?

Together with the MyZubster project and with AI-assisted development, I built and tested a proof-of-concept that connects local software experiments, GitHub evidence, a Knowledge Card, cryptographic hashing and Ethereum Sepolia.

The current flow looks like this:


text
N4K48
  ↓
real work and local tests
  ↓
GitHub evidence
  ↓
MyZubster Knowledge Card
  ↓
canonical payload
  ↓
SHA-256
  ↓
Ethereum Sepolia
  ↓
Knowledge Proof Verifier
  ↓
Knowledge Graph

This is still an experiment, but we now have a complete reproducible path.
1. Starting locally: Docker + AI + RAG
The work started inside myzubster-mvp.
I built and tested a local environment involving:
- Docker / Docker Compose
- Ollama
- Qdrant
- Open WebUI
- Python / Flask APIs
- local knowledge ingestion
- RAG retrieval
One of the concrete improvements was changing the knowledge chunking and testing a new ingestion.
The resulting ingestion loaded 46 knowledge chunks into Qdrant while skipping one empty document.
I also tested retrieval through the API and adjusted the AI context limit so the expected GitHub context could be retrieved.
Repository:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp
2. Turning the work into a Knowledge Card
Instead of describing this work only in a README or profile, I created a public MyZubster Knowledge Card:
https://www.myzubster.com/knowledge-card?id=6abaaefb3a7460c4574a45fd
The card connects the activity to supporting evidence such as:
- the repository;
- commits;
- local test descriptions;
- Proof documentation;
- Ethereum contracts;
- deployment transactions;
- the Knowledge Proof Verifier.
The important idea is that the profile claim and the evidence remain separate.
The evidence supports inspection.
It doesn't automatically certify the claim.
3. Proof v1: proving the URL
The first Ethereum experiment was intentionally simple.
I calculated a SHA-256 digest from the Knowledge Card URL and stored it in a small Solidity contract on Ethereum Sepolia.
That proved that I could create a public on-chain anchor.
But it also exposed an important limitation:
hashing the URL is not the same as hashing the content.
So we moved to a second version.
4. Proof v2: hashing the canonical payload
For Proof v2, I created a stable JSON representation of the Knowledge Card.
Instead of hashing the URL, the system hashes the exact payload bytes.
The SHA-256 was:
6097e05866bafceec24663d2638cb1dae5742ac78284abbfd45cc9c3b0bfb845

That value was stored as bytes32 in a new Sepolia contract.
The public knowledgeHash() value could then be read and compared with the locally calculated digest.
This was much closer to the model I wanted:
content
  → exact bytes
  → SHA-256
  → bytes32
  → public blockchain

5. Building a repeatable verifier
Manually comparing hashes is useful during an experiment, but it isn't a good verification interface.
So the next step was MYZ-213: a repeatable Knowledge Proof Verifier.
The verifier:
1. reads the exact saved payload bytes;
2. calculates SHA-256;
3. reads knowledgeHash() from the Sepolia contract;
4. compares the values;
5. reports one of the meaningful outcomes:
MATCH
NO_MATCH
ERROR

It also includes tests for an altered payload and an unavailable RPC endpoint.
The verifier was merged through PR #16:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/pull/16
No private key is required for verification.
No signature is required.
No transaction is required.
Verification uses public, read-only Ethereum RPC calls.
6. Proof v3: verifying the updated knowledge payload
After adding the new development evidence, I created a third payload.
The exact committed v3 payload is:
proofs/knowledge-card-6abaaefb3a7460c4574a45fd-v3.json

Size:
5083 bytes

SHA-256:
d1c89d2a4157a159b56e92825ca59fdb1f0e84e003b05e022af67da69ed25ac4

I reproduced this digest locally using both sha256sum and Python hashlib.
Then I deployed another MyZubsterProof contract to Ethereum Sepolia.
Contract:
0x3233fA7f8c50Aa25d9B1263c25F28535B6eA59bF

Deployment transaction:
0x5c7717be6dc70e6416f8053c72bb1e2bec2b7c5462b23fcb9c4b1077f907fed4

Reading the contract directly returned:
0xd1c89d2a4157a159b56e92825ca59fdb1f0e84e003b05e022af67da69ed25ac4

Exactly the same value as the locally calculated payload digest.
Then I ran the Knowledge Proof Verifier.
The result was:
{
  "status": "MATCH",
  "payload_sha256": "d1c89d2a4157a159b56e92825ca59fdb1f0e84e003b05e022af67da69ed25ac4",
  "calculated_bytes32": "0xd1c89d2a4157a159b56e92825ca59fdb1f0e84e003b05e022af67da69ed25ac4",
  "onchain_bytes32": "0xd1c89d2a4157a159b56e92825ca59fdb1f0e84e003b05e022af67da69ed25ac4",
  "payload_matches_onchain": true,
  "payload_matches_expected": true,
  "network": "Ethereum Sepolia",
  "chain_id": 11155111
}

That was the key milestone.
The same value existed in:
committed payload
      ↓
local SHA-256
      ↓
expected bytes32
      ↓
Sepolia knowledgeHash()

And the verifier returned:
MATCH

Proof v3 documentation:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/blob/main/proofs/SEPOLIA_PROOF_V3.md
7. Connecting it to a Knowledge Graph
The next layer is the MyZubster Knowledge Graph.
The goal is to make this path navigable:
N4K48
 ↓
Knowledge Card
 ↓
contribution
 ↓
GitHub evidence
 ↓
payload
 ↓
SHA-256
 ↓
Ethereum proof

During testing we confirmed that the graph contains a single N4K48 node and a single node for the Knowledge Card.
We also found something useful:
after updating the Knowledge Card with the latest GitHub evidence, the new sources were not yet automatically reflected in the graph.
That's not something to hide.
It's exactly the kind of integration issue this pilot is designed to discover.
The automatic synchronization between updated Knowledge Cards and graph evidence still needs work.
8. What does MATCH actually prove?
This distinction is important.
A MATCH does not mean:
"Everything this person says is true."

It does not automatically certify a professional skill.
It does not automatically prove identity or ownership of every linked artifact.
What it does demonstrate is much narrower and more technically useful:
The exact payload bytes being verified produce the same cryptographic digest as the value stored in the referenced public blockchain contract.

That gives us integrity and provenance evidence.
Other forms of verification can be layered on top later.
9. What I learned
This project connected several areas that I had previously been testing separately:
- local AI and RAG;
- Docker environments;
- Ollama and Qdrant;
- Python APIs;
- GitHub commits and pull requests;
- CI;
- canonical data representation;
- SHA-256;
- Ethereum read-only verification;
- smart contracts;
- Knowledge Cards;
- Knowledge Graphs;
- AI-assisted development.
More importantly, it changed the way I think about a digital profile.
Instead of:
I say I know X

the model can move toward:
I say I know X
      ↓
here is what I did
      ↓
here is the source
      ↓
here is the artifact
      ↓
here is its fingerprint
      ↓
here is a public attestation
      ↓
verify it yourself

What's next?
There is still plenty to build.
The next steps include improving Knowledge Graph synchronization, finishing more end-to-end testing, simplifying the verification UX, and exploring interoperable attestation and credential standards.
The long-term goal isn't to put every piece of personal information on a blockchain.
It's to make useful evidence easier to inspect, reproduce and verify.
For me, this experiment has already reached an important milestone:
local work became documented evidence, the evidence became an exact payload, the payload became a cryptographic fingerprint, and that fingerprint became independently verifiable on a public network.
I'm building this publicly as N4K48.
GitHub:
https://github.com/nicolaususnicola-lgtm
MyZubster:
https://www.myzubster.com
Knowledge Card:
https://www.myzubster.com/knowledge-card?id=6abaaefb3a7460c4574a45fd
The project is experimental and under active development.
Enter fullscreen mode Exit fullscreen mode

Top comments (0)