Zenon’s Future as Hinted by Kaine

Development
1

0. Ground rules: what’s Kaine vs what’s us

Before we plan anything, the community needs to clearly separate:

  • What Kaine explicitly said

  • What logically follows from his design choices

  • What devs are adding now (e.g. zero-sync, zkSync-style stuff)

So we’ll frame it like this in the doc:

Kaine’s part: minimal L1, light-node focus, zk-rollups fit NoM, WASM/unikernels, interop, libp2p, TSS, sentinels, etc.

Our part: browser-native light client design, zero-sync UX, concrete rollup designs, specific protocol choices.

That way nobody can say “you’re putting words in his mouth” — we’re just extending his principles.

1. Kaine’s Design Pillars (What’s Actually Canon)

These are the core ideas Kaine repeated in different language:

1.1 Minimal, robust L1 (No heavy VM)

  • L1 should be minimal, robust, efficient.

  • Heavy VMs at L1 (EVM/WASM) are a deal-breaker for long-term scalability.

  • Smart contract “heaviness” should move off L1, into:

    • WASM runtimes

    • unikernels

    • zk-rollups / Plasma-like layers

Takeaway for community:

Stop thinking “let’s just bolt an EVM onto L1.”

Think: “L1 = ordering + consensus + basic embedded contracts. Everything else = layers on top.”

1.2 Light nodes & many clients

From his mentions of:

  • IBD/ILD

  • tx processing optimizations

  • light node optimizations

  • running znnd on a phone

  • target of ~100K full nodes and millions of light clients

…it’s very clear he expected:

  • Few heavy nodes (pillars/full nodes)

  • Millions of light nodes (mobile, lightweight, potentially browser)

He didn’t say “browser”, but the constraints he optimized for match browser/mobile environments perfectly.

1.3 Modular execution (WASM, unikernels, multi-VM)

Kaine explicitly:

  • supported multiple runtimes

  • recommended WASM

  • mentioned unikernel integrations

  • warned about blindly adding Solana/EVM-like VMs without understanding trade-offs

  • suggested extension / off-chain runtimes for smart contracts

This is the model:

L1: lean

On top: pluggable runtimes (zWASM, unikernels, zk-rollup VMs)

Community chooses de-facto standard (hopefully WASM)

1.4 P2P + libp2p + privacy

He mentioned:

  • upgrading the P2P layer

  • using libp2p

  • zk-telemetry to map the network privately

  • Tor, SSL/WSS, gRPC integration

  • incentivizing P2P decentralization

So the network isn’t meant to be RPC-centric like Ethereum today; it’s meant as a real P2P fabric that light clients and sentinels sit on top of.

1.5 Advanced crypto: TSS, scriptless scripts, zk-rollups

Kaine clearly cared about:

  • TSS (Threshold Signature Schemes)

  • Pillars as TSS signers holding BTC vaults

  • Scriptless scripts + Taproot-style functionality

  • ZK-rollups being a perfect fit for NoM

  • ZK-based scaling to keep L1 minimal

  • MEV mitigation via threshold encryption

All of that screams:

“We want cryptography to enforce trustlessness and fairness, not social trust or RPC providers.”

2. The Extended Thesis (What Devs Are Adding Now)

These are new ideas that are consistent with Kaine’s pillars, but not words he actually used:

  • Zero-sync light nodes (zkSync-style or similar)

  • Browser-native light client in WASM (Rust/TS implementation)

  • Full WebRTC-based browser node behavior

  • Specific zk circuits / proof systems

We should present them like:

“Based on Kaine’s principles (minimal L1, zk-rollups, light-node focus, libp2p), here’s what the next-gen architecture could look like.”

So nobody confuses speculation with canon.

3. Clean mental model for the community

You can frame the whole system in three layers:

3.1 Base layer: NoM (L1)

  • Account-chains + momentums

  • Basic embedded contracts (in Go)

  • No heavy VM

  • Consensus led by pillars

  • TSS possible at consensus level

  • Designed to be phone-friendly, light-client-friendly

Community job here:

  • Don’t bloat it.

  • Make it faster & leaner: IBD/ILD optimizations, tx processing improvements, better PoW/PoS handling, etc.

3.2 Network layer: P2P fabric

  • Full nodes & pillars = “backbone”

  • Sentinels = relays, protocol oracles, PoW outsourcing

  • Light nodes = mobile/browser/desktop minimal clients

  • libp2p upgrade

  • Optional Tor/SSL/WSS/gRPC

Community job here:

  • Implement libp2p in Go (znnd) and JS (browser/Node).

  • Design sentinel behavior: gossip, oracles, relay, bandwidth incentives.

  • Start with simple incentives (reward well-behaved public nodes).

3.3 Execution layer: off-L1 compute

Three big tracks:

  1. WASM extension chains:

    • For general smart contracts

    • Turing-complete runtime

    • No impact on L1 minimalism

  3. Unikernels:

    • Highly isolated micro-VMs

    • Per-Zapp or per-contract sandboxes

  5. ZK-rollups (and maybe zk-VMs):

    • High-throughput off-chain execution

    • Single proof committed to L1

    • Foundation for zero-sync light nodes later

Community job here:

  • Pick one serious ZK path to prototype (Plonk/Halo2/Starkware-style, etc).

  • Define one WASM runtime spec (what syscalls, what state model).

  • Start with a simple PoC rollup or mini-execution layer.

4. Concrete “Where to Take Things Next” – Action Map

Here’s how you can present a clear community roadmap:

Track A – P2P + light-client foundations (short term, very aligned with Kaine)

  1. Implement libp2p (Go side) for znnd.

  2. Implement libp2p-js + WebRTC for a browser test client.

  3. Define a minimal light-node protocol:

    • What does it store? (headers? partial state?)

    • How does it ask for proofs/state?

  5. Build a minimal browser wallet + Zapp that:

    • Connects via libp2p/WebRTC

    • Signs a transaction

    • Broadcasts it via sentinels

    • Gets a momentum back and verifies it

This alone already kills a lot of Infura-style centralization.

Track B – WASM / contracts / extension layer

  1. Describe a WASM contract model:

    • What does a contract see?

    • How does it read/write state?

    • How is gas measured and limited (if needed)?

  3. Build a simple WASM execution environment off-chain:

    • Single contract type: e.g., token or swap

    • Use ZNN/QSR testnet to anchor roots or results

  5. Connect Zapps → WASM → NoM via a simple API.

This proves “smart-contracts off L1” can work concretely.

Track C – zk-rollup / zero-sync R&D

  1. Start a research thread (not promises) on:

    • What circuits we need (state transitions, balance updates, maybe a simple DEX)

    • Which proof system (SNARK/PLONK/STARK) fits best

  3. Build a tiny zk PoC:

    • One circuit

    • One prover binary

    • One WASM verifier

    • Verify a proof inside a browser

  5. Discuss how this could eventually:

    • Compress big chunks of tx history

    • Allow light clients with almost no historical sync

    • Remove trust in RPC

Don’t sell it as “next upgrade” yet, sell it as “long-term scaling research aligned with Kaine’s ZK comments.”

5. How to communicate this cleanly to the community

You’ll help a lot if you frame it like this:

:brick: 1. “Here’s what Kaine actually said” (with quotes)

  • Minimal L1

  • No heavy VM

  • zk-rollups fit NoM

  • WASM & unikernels as modular runtimes

  • libp2p P2P upgrade

  • TSS, scriptless scripts, MEV-resistance

  • Sentinels, oracles, light nodes, etc.

:brain: 2. “Here’s what follows from that design”

  • If L1 is minimal & zk-friendly → rollups make sense.

  • If he wants millions of light clients & phones → light-browser clients make sense.

  • If he pushes libp2p → browser/WebRTC peers make sense.

:crystal_ball: 3. “Here’s where devs today can take it”

Break it down into tracks (A/B/C above), so different people with different skillsets have entry points:

  • Go devs → P2P/libp2p/sentinels

  • Rust/Crypto devs → ZK/rollups

  • JS/TS devs → browser light client + Zapps

  • Protocol thinkers → WASM/unikernel model