Zenon’s Guide to the Galaxy

Development
1

Nice, this is a fun one. Let’s treat this like wiring up a circuit:

Goal: map exactly how a user action in a Zapp turns into a finalized state change at pillars (consensus), with sentinels in the middle.

I’ll break it into:

  1. The cast (who does what)

  2. The full request path: Zapp → light node → sentinels → pillars → consensus

  3. The response path: pillars → sentinels → light node → Zapp

  4. How this extends to WASM / rollups later

1. The cast: who are the actors?

:technologist: Zapp

  • Runs in the browser (or mobile / desktop).

  • Written in JS/TS (plus maybe Rust/WASM pieces).

  • Talks to the Zenon network through the SDK (JS/Python/Rust).

  • Does app logic: UI, business logic, encryption, local state.

:globe_with_meridians: Light client (inside/alongside the Zapp)

  • Also in the browser (or lightweight native).

  • Uses:

    • libp2p-js for P2P

    • WebRTC for browser-to-node/browser connections

  • Responsibilities:

    • Build & sign transactions

    • Maintain a minimal view of chain state (headers, a few proofs)

    • Verify new momentums (block-like structures)

    • Never stores full history; it’s not a full node.

:satellite: Sentinels

  • Lightweight network nodes.

  • Roles:

    • Relay transactions & momentums (gossip layer).

    • Act as protocol-level oracles (feed data into the network).

    • Can outsource PoW (if any is required) to external miners.

    • Don’t drive consensus, don’t hold the full “authority” like pillars.

Think of them as: very smart routers + oracles.

:tokyo_tower: Pillars (full nodes / validators)

  • Full nodes with consensus power.

  • Hold the full DAG/account-chain ledger.

  • Maintain mempools, validate transactions, produce & sign momentums.

  • Can act as TSS signers (e.g. BTC vaults).

  • They are the ones that really “lock in” state transitions.

2. Forward path: Zapp → light node → sentinels → pillars → consensus

Let’s walk a single transaction all the way through.

Step 0: User does something in the Zapp

Example: in a browser-based DEX/messenger/payment Zapp, user clicks:

  • “Send 10 ZNN to Alice”

  • or “Place limit order”

  • or “Send encrypted message”

The Zapp:

  1. Collects input (amount, recipient, etc).

  2. Runs local validation (is amount positive? fields filled?).

  3. Calls the Zenon SDK to create a transaction intent.

Step 1: Light client builds & signs the transaction

The light client layer (SDK + crypto):

  1. Fetches current account nonce / balance (from cached state or by asking the network).

  2. Builds a raw transaction object:

    • from, to, amount, type (ZNN, QSR, contract call, etc.)

    • references to current momentum height / hash if needed.

  4. Serializes it into the wire format expected by pillars.

  5. Signs it with the user’s private key (stored locally, e.g. in browser keystore or hardware wallet).

Now we have a complete, signed transaction in the browser.

Step 2: Broadcast via libp2p → sentinels & full nodes

The light client:

  1. Uses libp2p + WebRTC to connect to:

    • Nearby sentinels

    • Possibly some public full nodes/pillars directly

  3. It publishes the signed transaction on a gossip topic (e.g. tx_gossip).

At this point, the transaction leaves the user’s machine and enters the NoM (Network of Momentums).

Step 3: Sentinels receive, check & relay

When a sentinel sees this transaction:

  1. Basic validation:

    • Check tx format, signature validity.

    • Optionally check simple constraints (e.g. not absurd size, correct fields).

  3. If it passes:

    • Add it to a relay buffer / mini-mempool.

    • Gossip it outward:

      • To other sentinels.

      • To known pillars/full nodes.

  5. If the tx type requires oracle data (e.g. price feed, event data), sentinels may:

    • Attach the needed data (signed oracle messages).

    • Or broadcast oracle messages on separate channels.

Sentinels do not finalize anything. They just make sure the tx reaches enough pillars and is enriched with any needed external data.

Step 4: Pillars receive the tx and put it into consensus flow

Each pillar:

  1. Receives the transaction from:

    • Sentinels

    • Other pillars

    • Possibly directly from some light clients

  3. Runs full validation:

    • Signature validity (again).

    • Check account balance / nonce / contract rules.

    • Check that no conflicting or invalid state modifications would happen.

  5. If valid:

    • Insert into their mempool.

    • Take it into account when they build the next momentum / block.

If multiple pillars have different mempool contents, the consensus algorithm and chain selection rules determine which set of txs get into momentums.

Step 5: Consensus: from mempool → momentum → finality

At consensus time (simplified):

  1. Pillars propose or assemble candidate momentums (ordered sets of transactions + state transitions).

  2. Gossip these candidates to each other (via P2P).

  3. Validate each other’s proposals:

    • Do the transactions apply cleanly to current state?

    • Are there any invalid or conflicting changes?

  5. Once consensus is reached:

    • A new momentum is finalized.

    • It includes:

      • A list of transactions.

      • A new state root / ledger root.

      • A pillar signature set (or aggregate signature).

This is the point where your transaction has been accepted by consensus.

3. Backward path: Pillars → sentinels → light node → Zapp

Now we go in reverse, so the user’s app knows what happened.

Step 6: Pillars broadcast the new momentum

Once a pillar finalizes a momentum:

  1. It broadcasts the new momentum header + relevant body info to:

    • Other pillars

    • Sentinels

    • Any connected light clients

  3. This is done over the same libp2p P2P mesh:

    • Pillars → Sentinels → Light nodes

Step 7: Sentinels relay (and optionally index) the new state

Sentinels:

  1. Receive the new momentum and:

    • Verify its signature set.

    • Check that it connects cleanly to the previous momentum chain.

  3. They then:

    • Relay it further out to light clients.

    • Optionally store:

      • A short history of recent momentums.

      • Fast indexes for lookups (e.g. “give me all txs touching address X”).

Sentinels = high-availability access layer for light clients.

Step 8: Light client verifies and updates local state

In the browser, the light node:

  1. Receives:

    • The new momentum header (and maybe some body data).

  3. Verifies:

    • Momentum hash chain (parent link).

    • Pillar signatures (are these real pillars? threshold reached?).

  5. If the user’s transaction was included:

    • It either:

      • Saw the tx in the included list, or

      • Requested a proof / inclusion verification from a sentinel or full node.

  7. Updates local minimal state:

    • Latest momentum height/hash.

    • Account balance/nonce if affected.

    • Any relevant app-level state.

Step 9: Zapp updates UI and logic

Finally, inside the Zapp:

  1. SDK tells the app:

    • “Your tx got included in momentum #N!”

    • “Here is the new balance / status / order state.”

  3. The Zapp:

    • Updates its UI (confirmed, completed, filled, message delivered, etc.).

    • Clears pending indicators or shows an error if tx failed.

From the user’s perspective:

Click in browser → short wait → finalized on-chain, cryptographically verified in the browser.

No Infura. No trusted RPC. No central backend.

4. Where WASM / rollups / extension chains fit in

Everything above works even before we talk smart contracts & rollups.

Now layer in Kaine’s “modular execution” ideas:

A. WASM extension chain

  • Zapp tx might target a WASM execution zone instead of pure L1.

  • Off-chain or sidechain node(s) execute contract logic in WASM.

  • Pillars only see:

    • The resulting state diff or

    • A commitment + proof that the off-chain execution was valid.

But the flow is broadly the same:

Zapp → light client → sentinels → WASM-exec node(s) → pillars finalize state commitment → back via sentinels → light client → Zapp.

B. ZK-rollups (future / R&D)

For zero-sync or compressed-history modes:

  • A Prover (or a prover network) runs many txs off-chain.

  • Generates a zk-proof that “this whole batch was computed correctly.”

  • Pillars include the proof + new state root in a momentum.

  • Light clients just verify one proof instead of thousands of txs.

Sentinels still relay proofs + roots.

Zapps still interact through txs.

Pillars still finalize.

The main difference:

Light clients don’t even need the full transaction list; they just need:

  • proof

  • new root

  • Merkle/accumulator proof for their accounts.

5. Short mental summary you can give others

Zapp runs in the browser and uses a light client to talk to the network.

The light client sends signed txs into the P2P mesh via libp2p/WebRTC.

Sentinels act as relays/oracles, pushing those txs to pillars.

Pillars run full validation and reach consensus, producing a new momentum.

That momentum flows back out via sentinels to light clients, which verify it and update local state.

The Zapp then updates its UI, all without any centralized services.

That’s the clean “zApps → sentinels → pillars → consensus → back” story.