🏗️Nuchain Architecture

This document describes the high-level operation of NuChain System architectures. It describes each of the system components and how they interact with each other. It also describes the data model implemented by both architectures and provides some discussion of its limitations. The intention is to provide a more accurate and lower-level picture than the descriptions publicly announced so that it is clearer what functionality to expect when reading the code.

Proving, verification of batches, and state changes are all controlled by smart contracts. Most important to understand is the primary path taken by transactions from when users submit these transactions to the Nuchain network up until they are finalized and incorporated in the Final State.NuChain achieves this by utilizing several actors. The diagram below depicts the various actors and how they interact.

Here is an outline of the most prominent Nuchain components:

• The users, who connect to the Nuchain network by means of an RPC node (e.g., Infura or Alchemy), submit their transactions to Nuchain Validators for execution.

• The Beacons are the load routers and distributed queuing system for transactions submitted by users. Transactions are kept in the pool waiting to be put in a batch by the beacon to any of the validators.

• The Validator is a node responsible for validating and sequencing the transactions, checking if the transactions are valid, and then putting valid ones into a batch. The beacon submits all batches and then sequences the batches.

• The Outpost is a complex cryptographic tool capable of producing ZK-proofs of hundreds of batches and aggregating these into a single ZK-proof which is published as the validity proof. This also provides RPC Interaction points for the external APIs to connect with NuChain

• The Co-ordinator architecture implements a UHS by ordering transactions into a linear sequence of batches called "blocks". A replicated service called a "Co-ordinator" collects notifications about valid transactions from Validators and emits a new block at a fixed time interval. Validators apply the block to their own subset of the UHS atomically. Like in the two-phase commit architecture, Validators store a fixed subset of the overall UHS based on a prefix of the hash. Unlike in a two-phase commit, the Validators are not replicated in a state machine and redundancy is achieved via multiple Validators with overlapping prefix ranges. An archiving service provides long-term storage of historical blocks for future auditing and allows Validators to catch up to the most recent block in the event of a failure. A service called the "watchtower" indexes recent blocks so that end-users can query the status of recent transactions

For more information, please check below:

⚡Validator👨‍🔧Co-ordinator💼Archiver⏱️Watchtower