⚙️The gcEVM node types

Here you will find an in-depth overview of the gcEVM, focusing on the differentiation between pseudo blocks and canonical blocks, and their roles in the blockchain process.

A quick recap

In the gcEVM, there are two types of blocks:

1. A block that bundles transactions in sequence for the MPC nodes. This is called a pseudo block.

2. A block that contains the real state of the chain after execution. This is called the canonical block.

Although the pseudo block is a valid block, it can only exist as the head of the chain and is promptly replaced by the canonical block. Its purpose is solely to convey transactions to the MPC nodes in a verifiable way.

The canonical block contains a Transcript that enables state transition without requiring the ability to run MPC computations.

We call the MPC nodes Operation nodes. They are composed of two components:

• Executor – responsible for pseudo block validation and generation of the canonical block

Evaluator – a component responsible for MPC computation

There are currently two Operation nodes.

We call the nodes responsible for bundling transactions Sequencing nodes. They are responsible for generating pseudo state blocks. There is currently one Sequencing node, which will be from now on referred to as the “Sequencer”.

In addition to Sequencer nodes and Operation nodes, there is another type of node called Gateway nodes which will be described shortly.

Let’s review each of these nodes’ roles

The Executor nodes are responsible for producing the canonical block, also known as the real state block. Because secret transactions involve MPC (Multi-Party Computation), no single Executor node can evaluate the outcome of private operations on its own. This is why we always refer to them in the plural.

Executors do not maintain a transaction pool. The only way they can receive transactions is by parsing the transactions list from the non-canonical or pseudo block sent by the Sequencer. Non-canonical blocks are validated in the same way as normal EVM blocks, with one exception: they always have a difficulty of 1. After a pseudo block is validated and accepted as the chain head (meaning it did not contain transactions that are un-executable in the non-private state), the Executors parse its transactions and begin constructing the new canonical block. They evaluate the transactions in the same order determined by the Sequencer.

Since the final state of private transactions is unknown in the pseudo block, it is possible that some transactions will not be included in the canonical block due to the block gas limit. The transactions in the canonical block form a subset of those in the pseudo block. At most, they are exactly the same, and at minimum, the block can contain a single transaction. The order of transactions must be preserved, and there can be no gaps. For example, if the pseudo block contains five transactions ordered 1 to 5, the canonical block could include 1,2,3,4,5 or just 1,2,3, but it could never contain gaps such as 1,3 or 2,3,4.

The reason for this restriction is that predicting gas costs without knowing the outcome of a transaction is difficult. For example, a transaction might contain a condition that iterates a number of times based on a private value. Because the value is unknown, the number of iterations could be anything the variable allows.

The Sequencer’s role is to pull transactions from the TxPool and sequence them into a new block. This block is temporary and its state is ephemeral. In other words, it is only used to sequence transactions in a way that can be validated and then served to the Executor nodes. After the block has been parsed by the Executors, it is effectively removed from the chain, although it is still stored in the node’s database. Please refer to High Level View and Block Deep Dive for a more detailed explanation of how gcEVM blocks behave.

When it comes to block generation, the Sequencer’s process is the closest to normal EVM block generation. Transactions are taken from the TxPool, bundled into a block, signed, and propagated to the Executor nodes. The main difference is that after this step, the Sequencer waits for a canonical block to be broadcast back to it before beginning work on the next pseudo block. The reason is simple: the canonical block will contain a new state that the Sequencer is not aware of, and it will replace the chain head. Because of this, normal EVM transactions (those without private operations) cannot rely on the state created by earlier transactions in the same pseudo block being mined.

For example, suppose the current pseudo block contains a transfer transaction that creates new funds for an account. If the next transaction attempts to transfer those funds, the outcome depends on whether the first transaction is included in the canonical block. The second transfer will succeed if the first one is mined, and it will fail if it is not. Since the canonical block may only include a prefix of the transactions from the pseudo block, there is no guarantee that all transactions will be preserved before the pseudo block is replaced as the chain head. Gateway nodes do not participate in the block creation process. In fact, they cannot even see the pseudo block. For these nodes, only the canonical state exists. They are called Gateway nodes because they provide access both to the TxPool (since Executors do not have a TxPool and the Sequencer’s TxPool is not directly accessible) and to the chain itself. This is why Gateway nodes only expose the canonical state. Imagine trying to develop a dApp while its state was constantly changing—it would be unmanageable.

To sum up

Gateway nodes act as access points to the gcEVM blockchain. They reflect only the canonical state and cannot generate blocks. They share their transaction pool with the Sequencer and are the only nodes through which transactions can be submitted to the gcEVM chain. Gateway nodes validate blocks using the Transcript.

Sequencer nodes are responsible for bundling and sequencing transactions. They generate the pseudo block as the chain head for every block and then wait for the canonical block to arrive from the Executors, which overrides the pseudo block. The Sequencer is the only source of transactions for the Executors. It can validate blocks using the Transcript and pseudo evaluation (in the rare case of a sync when the chain head is still a pseudo block).

Executors first validate the pseudo block according to the pseudo execution rules. If the validation succeeds, they parse the transactions it contains and begin evaluating them in order. For this, they rely on MPC evaluation nodes to perform the calculations in sync. The canonical block will contain either the full list of transactions from the pseudo block or a prefix of them. Executors will never create a canonical block without first receiving a pseudo block. They can evaluate blocks using three methods: MPC execution, Transcript evaluation, and pseudo evaluation.