zkNode
zkNode is the software needed to run a Prom node. It is a client that network users require to synchronize and know the state of the Prom network. The main actors influencing the State and its finality are the trusted Sequencer and trusted Aggregator.
Prom accomplishes this through the use of several key components. Below is a list of the most significant elements of the network:
The Users connect to the network via an RPC node (such as MetaMask) and submit their transactions to a database called Pool DB.
The Pool DB serves as the repository for transactions submitted by Users. Transactions are held in the pool until the Sequencer organizes them into a batch.
The Sequencer is a node tasked with retrieving transactions from the Pool DB, validating them, and then organizing valid transactions into a batch. The sequencer submits all batches to the L1 and sequences them, ensuring that the sequenced batches are included in the L1 State.
The Synchronizer updates the State DB by retrieving data from Ethereum through Etherman.
The Etherman is a low-level component responsible for handling all interactions with the L1 network and smart contracts.
The State DB is a database used for the permanent storage of state data (excluding the Merkle trees).
The Aggregator is another node that produces proofs verifying the integrity of the Sequencer’s proposed state changes. These are zero-knowledge proofs (ZK-proofs), and the Aggregator uses a cryptographic component called the Prover for this task.
The Prover is a sophisticated cryptographic tool that generates ZK-proofs for numerous batches and aggregates them into a single ZK-proof, which is then published as the validity proof.
zkNode roles
The zkNode software is engineered to facilitate the execution of various roles, each necessitating distinct services. While most services can operate in separate instances, the JSON RPC is unique in that it can run across multiple instances, whereas all other services are limited to a single instance.
RPC Endpoints
Anyone can participate in this role as an RPC node.
Required Services and Components:
JSON RPC: This can operate on a separate instance and support multiple instances.
Synchronizer: Requires a single instance that can run independently.
Executor & Merkletree: This service can also run on a separate instance.
State DB: Utilizes Postgres SQL and can function on a separate instance.
There should be only one synchronizer, and it is advisable for it to have exclusive access to an executor instance, although this is not mandatory.While the synchronizer role can function effectively in a single instance, the JSON RPC and executor services may benefit from multiple instances if performance declines due to a high volume of requests.
Trusted Sequencer
This role is restricted to a single entity, as enforced by the smart contract. The methods related to the trusted sequencer can only be executed by the owner of a specific private key.
Required Services and Components:
JSON RPC: Can operate on a separate instance and support multiple instances.
Sequencer & Synchronizer: Must be run together in a single instance.
Executor & Merkletree: This service can function on a separate instance.
Pool DB: Utilizes PostgreSQL and can run independently.
State DB: Also uses PostgreSQL and can operate on a separate instance.
The JSON RPC is essential for receiving transactions. It is recommended that the JSON RPC runs on separate instances and potentially multiple instances, depending on network load. Additionally, it's advisable that the JSON RPC and the sequencer do not share the same executor instance to ensure the sequencer has exclusive access to an executor.
Aggregator
This role can be performed by anyone.
Required Services and Components:
Synchronizer: A single instance that can operate independently.
Executor & Merkletree: This service can run on a separate instance.
State DB: Utilizes PostgreSQL and can function on a separate instance.
Aggregator: A single instance that can run on its own.
Prover: A single instance that can operate separately.
Executor: A single instance that can run independently.
It is recommended to run the prover on a separate instance due to its significant hardware requirements. However, all other components can be consolidated into a single instance if needed.
Last updated