⬛The gcEVM canonical block

Hee you will find a detailed examination of the modifications made to the Ethereum block structure within the gcEVM environment

Changes made to Ethereum's block structure

With the background from the two previous sections, we can now examine what changes were made to the gcEVM block structure.

Header

• Extra Data: This field is traditionally used for header signatures. Its first 32 bytes are reserved for vanity information, which has no meaning for chain operation. We kept the vanity section unchanged but modified the rest. The next 32 bytes are reserved for the hash of the Transcript. The following 65 bytes are reserved for the Sequencer’s signature (taken from the pseudo block and verifiable using the pseudo header included in the canonical block’s body). The next two 65-byte slots are used for the Executor signatures, ordered lexicographically by their public keys. This last field may increase to enable multisig with many Executors.

Body

• Transcript: This is where the results of private opcode evaluation are recorded for block validation. The opcodes are ordered exactly as they appear when a node evaluates the transactions in the block’s transaction list. Conceptually, it is a two-dimensional array of bytes with no gaps and no fixed number of cells per transaction. Each private opcode consumes the next available cell in the array. After state transition is complete, no unused cells remain. The first cell of the array contains information about the state of garbled circuits, which helps MPC Evaluators synchronize. Even a canonical block with no private transactions still contains this first cell.

• Pseudo block’s Header: This is a critical idea for future decentralization of sequencing and execution in the gcEVM. To prove that MPC nodes did not alter the transactions sent by Sequencing nodes, the signed Sequencer block header is included in the seal hash (which is part of the block signing process). The Sequencer header contains all state roots at the time of sealing, allowing the block to be reconstructed by re-evaluating the transactions in the MPC block using the pseudo state for that block height and then verifying that the roots match. At present, this is not enforced because unpredictable gas costs in private execution can exceed the MPC block’s gas limit, requiring some transactions to be cut. These transactions are then returned to the transaction pool.

The structure of a pseudo block is the same as that of the canonical block, but the Transcript and pseudo header are empty. In addition, the Transcript hash and Sequencer’s signature fields in Extra Data are left empty. The two signature slots are both populated with the Sequencer’s signature.

To sum up

We have added new fields to the preexisting block structure:

The Transcript - to allow state transition for blocks containing secrets

The pseudo block's header - to allow validation that the canonical block is based on the data contained in the pseudo block at the same block height.

We have also made changed to the "ExtraData" field of the block's header to support additional signatures and hashes.