Section 3: ZkNode Individual Components

RPC endpoints

The role of JSON RPC

zknode JSON RPC is similar to Ethereum's official JSON RPC, but adds some additional information such as L2 network. In RPC mode, it mainly maintains the latest instance of L2 state, initially related to the batch broadcast by the trusted sequencer and later related to the batch sequence obtained from the consensus contract. Nodes constantly interact with L1 to keep their local L2 state up to date and to check synchronization of the L2 state root. Unless otherwise specified in the configuration, the synchronizer's default synchronization rate is once every 2 seconds. See the next section for details.

Run RPC, required components

• JSON RPC: Can run on a separate instance, and can have multiple instances; multiple JSON RPC helps improve the robustness of the service.

• Synchronizer: A single instance that can run on a separate instance; a single instance synchronizer helps ensure data consistency.

• Executor & Merkletree: Services that can run on separate instances.

• State database: Postgres SQL that can run on a separate instance.

Sequencer

The role of Sequencer

The trusted sequencer component is responsible for receiving L2 transactions from users, sorting them, generating batches, and submitting them in the form of a sequence to the storage slot of the consensus contract.

The sequencer executes and broadcasts batched transactions to L2 network nodes to enable fast finalization and reduce costs associated with high network usage. That's before submitting them to L1.

The trusted orderer must run the zkEVM node in orderer mode and control the Ethereum account on which the consensus contract is executed.

The sequencer collects transactions and publishes them in batches; at the same time, it collects fees from published transactions and pays L1 transaction fees + MATIC (depending on the batch to be processed); MATIC flows to the aggregator. If txs fees > L1 call + MATIC fee, the account corresponding to running the Sequencer service can make a profit. details as follows:

• Anyone with the necessary software to run a zkEVM node can become a sequencer.

• Each sequencer must pay a fee in the form of MATIC tokens for the right to create and propose batches.

• Sequencers that propose valid batches (composed of valid transactions) are incentivized by fees paid by transaction requesters or network users.

Run Sequencer service, required components

• JSON RPC: Can run on a separate instance, and can have multiple instances; multiple JSON RPC helps improve the robustness of the service.

• Serializer and synchronizer: a single instance needs to be run together; a single instance guarantees data consistency.

• Executor & Merkletree: Services that can run on separate instances.

• Pooled database: Postgres SQL that can run on a separate instance.

• State database: Postgres SQL that can run on a separate instance.

Synchronize

Synchronize periodically obtains network updates, mainly from the L1 network, but also through the Trusted Sequencer's broadcast mechanism, to stay up to date. The default sync rate for synchronization is once every 2 seconds unless otherwise specified in settings.

Aggregator

The role of Aggregator

In zkEVM, the main role of the aggregator is to submit proofs and smart contracts verify the validity of state transfers. The logic of the consensus contract verifies the zero-knowledge proof, allowing zkEVM to inherit L1 security. A new L2 state root needs to be verified before being submitted to the consensus contract. A verified proof is irrefutable evidence that a given batch sequence leads to a specific L2 state.

The aggregator needs to process transactions published by the sequencer, build zkProof, and receive MATIC from the sequencer. The cost of running the aggregator includes: L1 call cost and server cost (build proof); when MATIC fee > L1 call + server cost, it will bring profit. details as follows:

• The aggregator is tasked with providing validity proofs for L2 transactions proposed by the sequencer.

• In addition to the zkNode software running zkEVM, the aggregator needs to have specialized hardware to create zero-knowledge validity proofs using zkProver.

• For a given batch, the aggregator that submits a proof of validity first earns MATIC fees (paid by the sequencer for that batch).

• Aggregators need to indicate their intent to verify transactions. Afterwards, they compete to provide proof of effectiveness based on their strategies.

Run the Aggregator service, required components

• Synchronizer: A single instance that needs to run them together; a single instance guarantees data consistency.

• Executor & Merkletree: Services that can run on separate instances.

• State database: Postgres SQL that can run on a separate instance.

• Aggregator: A single instance that can run on separate instances.

• Prover: A single instance that can run on a separate instance.

• Executor: A single instance that can run on a separate instance.

Etherman

Etherman is a low-level component that implements methods for all interactions with the L1 network and smart contracts. Other components use Etherman to modify the status of L1 network smart contracts or obtain L1 network smart contract related data.