# Zenon’s Future as Hinted by Kaine

**URL:** http://forum.zenon.org/t/zenon-s-future-as-hinted-by-kaine/2131
**Category:** Development
**Created:** [November 25, 2025, 3:39pm UTC](http://forum.zenon.org/t/zenon-s-future-as-hinted-by-kaine/2131 "2025-11-25T15:39:44Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![KayRSwon](http://forum.zenon.org/letter_avatar_proxy/v4/letter/k/6f9a4e/32.png) [@KayRSwon](http://forum.zenon.org/u/KayRSwon)
#### Post date: [November 25, 2025, 3:39pm UTC](http://forum.zenon.org/t/zenon-s-future-as-hinted-by-kaine/2131/1 "2025-11-25T15:39:44Z")

</div>

**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:

- 

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:

2. 
3. Unikernels:

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

6. 

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:

4. 
5. Build a minimal browser wallet + Zapp that:

6. 

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

**Track B – WASM / contracts / extension layer**

1. Describe a WASM contract model:

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

4. 
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:

2. 
3. Build a tiny zk PoC:

4. 
5. Discuss how this could eventually:

6. 

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:

**🧱 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.

**🧠 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.

**🔮 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