Research Topic: Clarifying Zenon’s Core Architecture Components

[TminusZ]

This issue is an open discussion thread for developers who want to analyze, clarify, or expand on the architectural components of Zenon — The Network of Momentum.

Key areas for exploration:

1. Momentum-Based Consensus

• How momentums anchor account chains
• Consensus flow and verification assumptions
• Signature validation and quorum details

2. Account-Chain Structure

• Parallel account-block DAG
• Send/receive mechanics
• State anchoring into momentums

3. Node Roles

• Pillars (consensus)
• Delegators (bonding)
• Sentries (proof-serving concept)
• Full nodes vs light nodes

4. ACIs (Application Contract Interfaces)

• Deterministic schema-based execution
• How ACIs differ from a traditional VM
• How proofs/commitments are handled

5. Proof and State Model

• SPV verification pathways
• Account-block inclusion proofs
• Momentum header verification

Reference document:

• /docs/architecture/architecture-overview.md

Anyone may contribute diagrams, clarifications, critiques, or further breakdowns.

[coinselor]

The original Zenon lightpaper, which predates the whitepaper by a couple of years, describes Zenon as "a decentralized cyberspace sharing a global distributed cryptographic ledger that is replicated across participating computer nodes." It mentions an architecture that is sharded in several places:

..an efficient atomic inter-shard communication protocol for transactions traversing the multidimensional sharding space.

Sentinels are a special type of sentries that will enable inter-sharding communication channels within the Network of Momentum, participating in the global consensus by validating the integrity of the shards.

This is done "in order to achieve a good positioning in the distributed ledger trilemma" while maintaining an asynchronous transaction model emphasized in the "thinking outside the 'block'" section.

In contrast, the whitepaper introduces a dual ledger architecture instead, composed of the momentum-based consensus and the account-chain DAG, with no mention of sharding at all. Given that sharding is primarily concerned with addressing scalability without compromising decentralization and security, and that maintaining security in a sharded architecture is challenging, I can infer that the dual ledger design aims to solve this issue by "simplifying" the architecture while preserving scalability properties.

The README describes Optimistic Rollups as useful for understanding off-chain execution with on-chain verification. Like Zenon, it seems that the original vision of Ethereum was a monolithic sharded architecture, but the focus has gradually shifted to scaling with Layer 2 rollups via cheap data availability (blobs). The sacrifices for scaling with rollups are significant: liquidity fragmentation, reduced composability, UX complexity, sequencer centralization, etc.

In essence, what rollups do is order the transactions and post the compressed data to L1. Carrying this analogy forward to the Zenon architecture, while keeping it extremely high-level:

• The momentum-chain acts as the L1 where data is posted.
• The account-chain acts as a scalable tool for user-generated "rollups" on demand.
• The supervisor layer would take care of ordering and submitting the data, similar to how sequencers operate.

I hope there is still value in this oversimplification and that the analogy holds some weight. In case it does, here's a follow-up question:

• Would Zenon state transitions also be optimistic in nature and require fraud proofs to be submitted?

[TminusZ]

The analogy is useful at a very high level (execution isolation), but it breaks at the point where rollups rely on optimistic acceptance and fraud proofs, whereas Zenon’s model rejects invalid transitions deterministically before commitment.

[stark-of-zenon]

Is Narwhal and Tusk designed to do the supervisor things?

[TminusZ]

Narwhal and Tusk are focused on improving how data is shared and ordered inside the consensus process. Narwhal handles efficient data distribution, and Tusk orders that data to reach BFT finality. The “supervisor” discussed here is a conceptual, non-consensus role that would act before consensus, potentially coordinating work, enforcing resource limits, and submitting results that are already verifiable.

In short, Narwhal/Tusk describe how consensus scales, while the supervisor idea explores how optional or heavier work could be handled outside consensus without increasing its complexity.

[stark-of-zenon]

Narwhal is described as operating before consensus and then submits verifiable outputs that consensus orders.

That sounds similar to the decomposition you’re describing for Supervisors.

What’s the optional or heavier work that Supervisors would handle that Narwhal doesn’t already cover?

[TminusZ]

Narwhal decomposes consensus by separating data dissemination from ordering, but it remains strictly within the consensus pipeline. It handles availability and reference ordering, not semantic validation or application-level work.

The supervisor abstraction is intentionally broader and non-consensus: it may perform optional or heavy tasks such as proof aggregation, cross-chain/SPV verification, policy checks, or resource accounting, and then submit already verifiable commitments to Momentum. Consensus only attests to ordering and finality, not to how those commitments were produced.

In that sense, Narwhal optimizes how consensus scales, while supervisors explore how work can be externalized or localized without expanding what consensus is responsible for.

[edgepillar]

@sileneundula

[silenecapensis]

@edgepillar what block is zenon on the btc blockchain timestamped at. It said taproot online. Can you point me towards the block that has the BTC message

[silenecapensis]

@edgepillar Also, have you worked on getting it on centralized exchanges? I dont know if it goes against your values but most people do use centralized exchanges to get it. Decentralized should be preferred. You can take a look at some of my research and ill look into zenon some more.

Edit: Also, look into recursive zk-snarks like halo2 and mina.

[coinselor]

what block is zenon on the btc blockchain timestamped at

First block of Taproot upgrade -> 709,632. Look up this address.

Over the years, Zenon has traded in a few CEXes, only one remains active and basically has 0 liquidity. The protocol incentivizes liquidity providers of Uniswap on ETH, where most of the liquidity is at.