feat: add DIY Validium blog post by oskarth · Pull Request #27 · ethereum/iptf-web

oskarth · 2026-03-16T03:59:38Z

Summary

New blog post: "DIY Validium: Private Logic on Public Rails"
Covers the DIY validium PoC: guest program pattern (disclosure proof as full exhibit), validium architecture, escape hatch + forced withdrawal (anti-censorship), trust model comparison with other IPTF approaches, and open questions on private shared state
Three Excalidraw diagrams: zkVM pattern flow, three-layer architecture, censorship resistance spectrum
Working outline included for reference

Still needed

Hero image (1200x600, 2:1 ratio) for Twitter card
Final date confirmation
Review of disclosure.rs code block against actual source on feat/escape-hatch branch
Verify internal links render correctly with bundle exec jekyll serve

Test plan

bundle exec jekyll serve renders post correctly
Diagrams display at correct size
Internal links to previous posts work
No double dashes or em-dashes in prose
External links (SPEC, source code, IPTF map) resolve

Blog post: "DIY Validium: Private Logic on Public Rails" Covers the DIY validium PoC: guest program pattern (disclosure proof as full exhibit), validium architecture, escape hatch + forced withdrawal (anti-censorship), trust model comparison with other IPTF approaches, and open questions on private shared state. Three Excalidraw diagrams and hero image.

rymnc · 2026-03-16T06:14:56Z

_posts/2026-03-21-diy-validium.md

+
+The program commits three values to the proof's public journal: the Merkle root, the threshold, and the disclosure key hash. That's all the auditor gets. Balance met a threshold, against a specific state root, bound to their identity.
+
+A compliance officer can read this code. Compare that to Circom, where the same check needs roughly 80 lines of manual signal routing and SHA-256 constraint wiring. The business logic (`balance >= threshold`) is identical either way; everything around it in Circom is circuit plumbing.


might want to say the tradeoff here is maintainability vs perf?

Good call — added this. The line now reads:

The tradeoff is maintainability vs performance: zkVMs are slower than hand-optimized circuits, but the code is readable and auditable.

tldr: ✅ Added maintainability vs perf tradeoff.

rymnc · 2026-03-16T06:18:16Z

_posts/2026-03-21-diy-validium.md

+This is a PoC. Some of the gaps are straightforward to close, others are open problems.
+
+On the engineering side: the operator is centralized (production would use a DA committee or post calldata). Users save their own data for escape (production would add blob checkpoints or encrypted DA). Disclosure keys are hash-based (production would use verifiable encryption; both Aztec and Miden are exploring this). There's no batching, and deposits and withdrawals are public.


curious, each state transition triggered by a transfer/deposit would invalidate all pending transactions in the mempool due to root mismatch, right? can we count that as a limitation?

Yes exactly — each state transition updates the root, so any in-flight proof built against the old root becomes invalid. Added this as an explicit limitation:

Each state transition updates the root, which invalidates any in-flight proofs built against the old root — there's no concurrent transaction processing without batching.

tldr: ✅ Called out root invalidation as a limitation in "What's missing".

Meyanis95 · 2026-03-16T08:48:51Z

_posts/2026-03-21-diy-validium.md

+
+## Write Rust, prove it, verify on-chain
+
+A validium keeps account data off-chain (held by an operator) and posts only Merkle roots and validity proofs on-chain. The chain stores almost nothing, but every state transition is cryptographically proven. If a transfer violates the rules, the proof won't verify and the contract rejects it.


Intro might be a bit too technical.
Validium => define it as a rollup
Merkle roots => commitment
validity proofs on-chain => a proof that the operator is doing correct work on the L1 contract...

Agreed — rewrote the intro. Now reads:

A validium is a type of rollup that keeps account data off-chain with an operator and posts only commitments and proofs to L1. The L1 contract verifies that the operator performed each state transition correctly.

tldr: ✅ Defined validium as a rollup, replaced jargon with plain language.

rymnc · 2026-03-16T08:50:12Z

assets/images/2026-03-18-diy-validium/hero.png

what did you use to generate this? looks sick

From the PR message, it might be a placeholder, but I agree it does look cool.

Generated some Midjourney prompts and then tweaking a bit :) Midjourney

Not placeholder, this is the real hero iamge!

rymnc · 2026-03-16T08:50:33Z

assets/images/2026-03-21-diy-validium/zkvm-pattern.excalidraw

do we need this committed?

Nope — deleted all three excalidraw source files and added *.excalidraw to .gitignore. PNGs are still there.

tldr: ✅ Removed, gitignored.

rymnc · 2026-03-16T08:51:11Z

diy-validium-outline.md

don't need this committed

Deleted.

tldr: ✅ Removed.

rymnc

overall i think it looks good, but seems too playful and has a bit of an ai voice to it, dealing in superlatives, slightly shilling etc

Meyanis95 · 2026-03-16T08:58:04Z

_posts/2026-03-21-diy-validium.md

+commitment = SHA256(pubkey || balance_le || salt)
+```
+
+`balance_le` is the balance encoded as little-endian bytes (matching Rust's `u64::to_le_bytes()`). Sequential root checks (`require(oldRoot == stateRoot)`) prevent replay: each operation changes the root, making stale proofs invalid. We don't need nullifiers (unlike UTXO models like Zcash or our [shielded pool PoC](/building-private-transfers-on-ethereum/)), but the tradeoff is that a centralized state holder is required.


Should we go that deep in a blog post? Or can it be abstracted?

Agreed — removed the code block with the commitment formula. Now just says:

Each account is a leaf in a Merkle tree. The leaf is a hash of the account's public key, balance, and a random salt.

tldr: ✅ Abstracted away, no more code block.

oskarth · 2026-03-17T05:01:18Z

Thanks for the review comments!

Addressed Feedback

@rymnc

✅ Added maintainability vs performance tradeoff note (line 82)
✅ Added root invalidation as an explicit limitation in "What's missing" section (line 185)
✅ Removed excalidraw source files and gitignored *.excalidraw
✅ Removed diy-validium-outline.md

@Meyanis95

✅ Rewrote intro paragraph: defined validium as "a type of rollup", replaced "Merkle roots and validity proofs" with "commitments and proofs to L1"
✅ Abstracted the commitment formula — removed code block, replaced with plain English description

Ready for re-review.

Remove excalidraw source files (PNGs kept), gitignore *.excalidraw, delete outline doc, and refine blog post wording for clarity.

rymnc · 2026-03-17T05:26:00Z

_posts/2026-03-21-diy-validium.md

+---
+layout: post
+title: "DIY Validium: Private Logic on Public Rails"
+description: "We built a validium in a few hundred lines of Rust and Solidity to understand what programmable privacy looks like end to end. The business logic is just Rust, proved in zero knowledge and verified on Ethereum."


dont think that the description should be so long

Good catch — shortened to: "A validium PoC where the business logic is ordinary Rust, proved in zero knowledge and verified on Ethereum." Should fit in preview now.

…lint Address reviewer feedback on forced withdrawal two-step semantics and deposit stranding risk. Apply voice lint: hook pivot, orientation line, trust model forward-reference, UTXO callout, and ending recap.

oskarth · 2026-03-17T09:08:54Z

overall i think it looks good, but seems too playful and has a bit of an ai voice to it, dealing in superlatives, slightly shilling etc

Tweaked in a bunch of places; if there are still specific places that seems off to you please comment in-line

Meyanis95

LGTM

Lead with problem statement instead of cold-opening with a code block. Remove duplicated "what are the moving parts" motivation. Keep assert! snippet as an earned reveal. Re-add Prividium mention in validium definition paragraph. Co-Authored-By: oskarth <o@oskx.io>

oskarth · 2026-03-18T02:39:36Z

Reworked the opening section:

Lead with problem statement instead of cold-opening with a code block
assert! snippet is now an earned reveal ("Here's a line of vanilla Rust code:")
Removed duplicated "what are the moving parts" motivation (was in both opener and "Write Rust" section)
Re-added Prividium mention in the validium definition paragraph
Fixed closing recap back-reference ("in the guest program" instead of "we started with")

Net: -2 lines, matches the voice of earlier posts in the series.

Co-Authored-By: oskarth <o@oskx.io>

oskarth force-pushed the feat/diy-validium-post branch from 1685611 to 56b764a Compare March 16, 2026 04:01

oskarth requested review from Meyanis95, mojalil and rymnc March 16, 2026 04:01

oskarth force-pushed the feat/diy-validium-post branch from 56b764a to f9c9c3d Compare March 16, 2026 04:20

rymnc reviewed Mar 16, 2026

View reviewed changes

Meyanis95 reviewed Mar 16, 2026

View reviewed changes

rymnc reviewed Mar 16, 2026

View reviewed changes

Meyanis95 reviewed Mar 16, 2026

View reviewed changes

chore: clean up excalidraw sources and tighten blog prose

129148a

Remove excalidraw source files (PNGs kept), gitignore *.excalidraw, delete outline doc, and refine blog post wording for clarity.

oskarth force-pushed the feat/diy-validium-post branch from 11f7a9e to 129148a Compare March 17, 2026 05:17

rymnc reviewed Mar 17, 2026

View reviewed changes

oskarth added 2 commits March 17, 2026 13:45

fix: clarify forced withdrawal flow, strengthen deposit trust, voice …

b2c99b0

…lint Address reviewer feedback on forced withdrawal two-step semantics and deposit stranding risk. Apply voice lint: hook pivot, orientation line, trust model forward-reference, UTXO callout, and ending recap.

fix: shorten post description for social card preview

dee7949

oskarth requested review from Meyanis95 and rymnc March 17, 2026 09:05

Meyanis95 approved these changes Mar 17, 2026

View reviewed changes

chore: update post date to 2026-03-18

3364800

Co-Authored-By: oskarth <o@oskx.io>

oskarth merged commit 7451910 into main Mar 18, 2026
1 check passed


		The program commits three values to the proof's public journal: the Merkle root, the threshold, and the disclosure key hash. That's all the auditor gets. Balance met a threshold, against a specific state root, bound to their identity.

		A compliance officer can read this code. Compare that to Circom, where the same check needs roughly 80 lines of manual signal routing and SHA-256 constraint wiring. The business logic (`balance >= threshold`) is identical either way; everything around it in Circom is circuit plumbing.

		This is a PoC. Some of the gaps are straightforward to close, others are open problems.

		On the engineering side: the operator is centralized (production would use a DA committee or post calldata). Users save their own data for escape (production would add blob checkpoints or encrypted DA). Disclosure keys are hash-based (production would use verifiable encryption; both Aztec and Miden are exploring this). There's no batching, and deposits and withdrawals are public.


		## Write Rust, prove it, verify on-chain

		A validium keeps account data off-chain (held by an operator) and posts only Merkle roots and validity proofs on-chain. The chain stores almost nothing, but every state transition is cryptographically proven. If a transfer violates the rules, the proof won't verify and the contract rejects it.

Conversation

oskarth commented Mar 16, 2026

Summary

Still needed

Test plan

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rymnc left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

oskarth commented Mar 17, 2026

Addressed Feedback

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

oskarth commented Mar 17, 2026

Uh oh!

Meyanis95 left a comment

Choose a reason for hiding this comment

Uh oh!

oskarth commented Mar 18, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants