> For the complete documentation index, see [llms.txt](https://dataipo.gitbook.io/dataipo-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dataipo.gitbook.io/dataipo-docs/whitepaper-center/simplechain-whitepaper/chapter-4-network-architecture.md). # Chapter 4 — Network Architecture Why a chain of its own. Evidence registration and state versioning need a neutral shared ledger that cannot be silently rewritten. PCT validation needs to complete natively in the execution path. Attestors, oracles, and nodes need the economic discipline of staking and slashing. Institutional nodes and controlled execution domains need a chain-level permission model. Receipts across settlement rails need one finality semantics. On a general-purpose chain these five things can only be conventions inside application contracts; on SimpleChain they are consensus rules. One principle governs the trade-offs: a chain serving capital markets puts determinism and auditability ahead of theoretical peak throughput. The consensus layer keeps the simplest rotating block production, and the engineering effort goes into the five places that decide the actual experience: finality latency, decoupling consensus from execution, parallel execution, network propagation, and state storage. ## 4.1 Consensus: PoSA rotating block production SimpleChain uses PoSA (Proof of Staked Authority). Validators qualify by staking SRW, enter the active set ranked by stake, and produce blocks in fixed rotation. Rotation removes the per-round communication cost of election, verification, and view change, giving the shortest block-production path among EVM chains; production networks led by BNB Chain have proven its stability under institutional load. The active set refreshes periodically by stake weight. Double-signing, prolonged downtime, or data tampering is slashed by grade. Delegators may delegate SRW to validators and share block rewards. The consensus layer does not execute transactions; it agrees only on transaction order (see 4.3). | Element | Design | | --------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Block production | Staked validators rotate in fixed order; no per-round election or view change | | Validator set | Dynamic set ranked by stake; size and thresholds set by governance parameters | | Finality | BFT vote finality: two rounds at ≥ 2/3 as the baseline, a fast path at ≥ 80% for single-round confirmation (see 4.2) | | Execution environment | EVM-compatible; supports permissioned-token standards such as ERC-3643 and EIP-712 signature isolation | | Slashing | Double-signing, downtime, and malicious behavior slashed by grade; delegators share reward deductions pro rata | | Performance figures | Block interval, finality latency, and throughput follow the public monitoring of testnet and mainnet; this paper presets none | ## 4.2 Fast finality: optimistic single-round confirmation The current finality rule: when two consecutive blocks each receive aggregated BLS votes from more than 2/3 of validators, the earlier block is final. Structurally this is a two-round BFT commit. SimpleChain adds an optimistic fast path on top. When a block receives votes from at least 80% of validators in the first round, it is final immediately; below 80%, the process falls back to the two-round ≥ 2/3 baseline. Both paths share the same vote messages and aggregated signatures, and validators need no awareness of which path is active. The safety bound of the fast path follows the classical fast Byzantine consensus result: under the n = 3f + 1 fault assumption, a single-round commit requires a larger quorum than a two-round commit. Setting the fast-path threshold at 80% means that when Byzantine nodes number at most n/5, single-round confirmation is as safe as two-round confirmation; beyond that ratio the fast path simply cannot assemble its quorum, the system lands on the two-round path, and safety rests on the baseline. Under SimpleChain's current network composition, validator uptime and link quality let most blocks take the fast path, cutting confirmation latency by up to 50% in the optimistic case. | Path | Trigger | Rounds | Safety assumption | | --------- | ------------------------------------- | --------------------- | -------------------------------- | | Fast path | First-round votes ≥ 80% of validators | 1 | Byzantine nodes ≤ n/5 | | Baseline | Two consecutive blocks each ≥ 2/3 | 2 | Byzantine nodes < n/3 | | Fallback | Fast path misses its threshold | Automatic to baseline | No extra messages or view change | ## 4.3 Decoupling execution from consensus A traditional EVM chain executes transactions before proposing a block and reaches consensus on the post-execution state root, so execution time sits inside the consensus cycle. SimpleChain separates the two: consensus agrees only on transaction order, execution proceeds asynchronously once order is fixed, and the block header carries a state root delayed by several blocks, with the current block's execution result confirmed in later blocks. Monad and the latest Ethereum roadmap take the same direction. The decoupling changes three things. First, the consensus cycle no longer waits for execution, so block production and voting pipeline cleanly. Second, the execution layer scales independently and adopts parallel execution (4.4) without touching the simplicity of consensus. Third, PCT validation splits into two stages: the consensus layer checks conditions that need no state, such as signatures, nonces, and authorization references, and the execution layer checks conditions that depend on state, such as state versions, evidence validity, and policy decisions. If either stage fails, the transaction never changes asset state. The delay window of the state root is a governance parameter; light clients and cross-chain verification work against the delayed root. ## 4.4 Parallel execution The execution layer runs optimistic parallelism: transactions execute in parallel in the order consensus fixed, the runtime tracks each transaction's read and write sets, conflicting transactions re-execute in order, and the final result equals serial execution exactly. This is the family of Aptos Block-STM and the Monad execution engine; the explicit access lists used by Solana and Sui serve as an additional optimization for specific contracts. Real-asset traffic suits parallel execution well. Evidence registrations, state transitions, and receipt commits for different Asset IDs share no state and parallelize naturally. Updates to the same asset are serialized by TASM's version precondition, so conflicts occur only on concurrent writes to one asset, which is exactly the case the conflict detector handles. ## 4.5 Network propagation Ethereum-family gossip propagates whole blocks, and as validator count and block size grow, propagation delay becomes a hidden ceiling on block production. SimpleChain follows the approach of Solana Turbine and Monad RaptorCast: the proposer splits a block into chunks, adds erasure coding, and propagates through layered relays; each validator receives shards from different upstream nodes and reassembles locally, and any sufficient fraction of shards recovers the full block. Layered propagation turns the proposer's upstream bandwidth from proportional-to-validator-count into a constant, and erasure coding keeps reassembly alive when some nodes drop packets or misbehave. ## 4.6 State storage Read and write on the state database is the largest current bottleneck and the precondition for parallel execution to pay off. The storage layer moves in three directions: a database layout native to the Merkle state tree, removing the layered indexes of a generic KV store; asynchronous IO with prefetching, so parallel execution's state reads do not block one another; and tiered storage separating current from historical state, with history archived to NVMe clusters and cold storage. MonadDB is the reference implementation in this direction. ## 4.7 Node types and permissions | Node | Duties | Admission and constraints | | --------------------------- | ---------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | Validator | Block production, voting, finality | SRW self-stake ≥ threshold plus delegation; slashing | | Institutional node | Institution-grade data domains, controlled execution domains, API/SDK access | KYB and protocol admission; may run a TDS partition | | Attestation and oracle node | Source / Attestor / Oracle data intake and signing | Work-staking; slashing for attestation beyond mandate | | Regulatory node | Three tiers: read-only audit / risk alert / emergency intervention | Multi-signature activation bound to official credentials; every action recorded on-chain | | Storage and compute shard | History archiving, ZK proof generation, encrypted audit | NVMe clusters, FPGA acceleration, SM4 hardware modules | The three regulatory tiers map to routine audit, risk-event tracking, and major-violation response. Every intervention leaves an on-chain record traceable by higher-level regulators. ## 4.8 Native transaction types Beyond plain transfers and contract calls, SimpleChain defines four native transaction types, checked in stages by the consensus and execution layers: | Type | Purpose | Checks | | -------------- | ---------------------------------------------------------------------- | --------------------------------------- | | EvidenceAnchor | Registers an EvidenceEnvelope's commitment, signatures, and references | Attestor credential, GranularHash, time | | Type | Purpose | Checks | | --------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------------ | | StateTransition | Submits a new AssetStateRecord version with its LifecycleEvent | prior\_state match, authorization, valid evidence references | | PCT | Proof-carrying execution: intent + state + evidence + policy + authorization | Nine-step validation order (Chapter 7, 7.5) | | ReceiptCommit | Registers a SettlementReceipt and triggers the state update | External receipt signatures, two-leg match, idempotency | Making PCT a native transaction type means: a transaction failing stateless conditions never enters a block, one failing stateful conditions never changes asset state, and neither case needs an application contract to revert after the fact. ## 4.9 Data availability, scaling, and interoperability The shared ledger stores identifiers, commitments, proofs, and audit references first; sensitive originals stay in TDS or institutional data domains. Material events anchor record by record; high-frequency events anchor in Merkle batches. Any authorized party can verify that what it sees matches the registered commitment. For scaling and interoperability, heterogeneous rollups (ZK and Optimistic) serve as execution domains for specific scenarios, interconnected through a unified settlement layer. Cross-chain adapters cover EVM, Solana, and MOVE-family chains, using HTLC atomic transactions, multi-signature and ZKP verification, real-time risk monitoring, and contract audits. The funding side can ride established chains in coordination and migrate to native settlement as the mainnet evolves. ## 4.10 Order of rollout The five optimizations proceed in order of benefit against cost. Fast finality (4.2) changes the least and pays off directly, so it goes first. Network propagation (4.5) prepares the ground for the next two, so it goes second. Decoupling execution from consensus (4.3) is the architectural core, third. Parallel execution (4.4) plugs in after the decoupling. State storage (4.6) costs the most and goes last. Each stage starts on the strength of testnet data and security audit results, announced by the Foundation's Technical Steering Committee. > **Network claim** > > The target is institutional determinism, and the consensus stays minimal: the simplest rotating block production plus optimistic single-round finality, consensus that only orders while execution runs asynchronously and in parallel, compliance checks staged between consensus and execution, tiered regulatory nodes that leave records, and sensitive data that never leaves its domain. This is a chain built for capital markets. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://dataipo.gitbook.io/dataipo-docs/whitepaper-center/simplechain-whitepaper/chapter-4-network-architecture.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.