🦅A Bird's Eye View

This is a high level overview of the entire gcEVM blockchain and it's components

What is the gcEVM?

The gcEVM is a new and groundbreaking “flavor” of the EVM that opens the door to privacy-preserving smart contracts. The “gc” stands for “Garbled Circuits,” a technique that allows multiple machines to run a computation without any single machine having access to the inputs, or in some cases, even the output. Although this technology has existed since the 1980s, it is now mature enough to be deployed on real-world blockchains with high throughput and availability.

In other words, the gcEVM unlocks use cases that require privacy in smart contracts, a shift as profound as the introduction of privacy on the internet. Today, we could not imagine the internet without privacy (especially in the financial sector), and soon we won’t be able to imagine Web3 without it. As a side effect, the gcEVM also enables true randomness, a key missing element in Web3 applications that aim for fairness, particularly in gaming.

The current gcEVM implementation can handle 80 confidential transactions per second (cTPS). These are far more computationally intensive than standard EVM transactions. Work to further increase cTPS is already underway and will be reflected in future versions.

When it comes to finality, the gcEVM has instant finality: every block is final with no possibility of forks. The trade-off is liveness, some blocks may take longer than others to seal, and there is no guaranteed maximum block time. Still, deviations are small, and in the vast majority of cases block times range between 5 and 7 seconds. This distribution has a “fat tail,” meaning times can occasionally exceed that range, though the probability drops sharply and never reaches zero.

To support the “gc” aspect, we had to adapt our blockchain architecture. Unlike most EVM-based blockchains, which rely on a single node type, our chain is split into three node types, each with a distinct role necessary for the system to function. These roles will be explored in the following sections.

Currently, the gcEVM is still in its “permissioned” stage. Two of the three roles remain closed to outside participants, while only one is open. Decentralization of the remaining roles is in progress and will be available in future versions.

Changes to the EVM

When we say the gcEVM is a “flavor” of the EVM, we mean that we’ve extended the Ethereum Virtual Machine to support computation on encrypted data. Without getting into the details, our changes fall into two categories:

• Additional secret primitive variables

• Additional operations on secret variables

We implemented this extension by adding a new precompiled contract where the new types and opcodes reside. These new types can be selectively used to maintain private execution states and can also serve as inputs for private operation codes (“opcodes”), allowing developers to keep them secure while still using or mutating their values. The rest of the contract can remain “in the clear” using existing syntax.

This means an existing smart contract can be migrated from Ethereum to the gcEVM with no modifications if privacy features aren’t required. At the same time, developers have the flexibility to use private operations where needed. Since private operations are more complex, they come with a higher gas cost.

The problem with data replication on ‘un-computable’ data

To understand the gcEVM architecture, one must first grasp the challenge facing any blockchain that aims to support streamlined private operations alongside non-private ones.

Distributed systems in general, and blockchains in particular, rely on data replication between nodes. This replication happens through an operation called state transition, which in blockchain terms means that nodes view the current leader’s (miner’s) state as expressed in the chain’s head block and then replicate it locally by running all operations (transactions) in sequence from first to last. A key part of this process is validating that the resulting state matches the state represented in the block’s header.

The problem begins when the miner generates state in a way that other nodes in the network cannot reproduce. If this reminds you of the oracle problem, you’re not mistaken: the “gc” part of the gcEVM can be thought of as an oracle that can “magically” perform a secret calculation no other participant can replicate.

A second challenge, stemming from the same root, is input validation. In other words, how do we know the secret calculation was performed on the correct data? If the oracle is not part of the chain, it could be “fed” operations that do not reflect actual user transactions, and no one would notice. For example, the oracle could be asked to perform a decryption on a secret value even if that operation wasn’t required by any transaction in the block.

The solution to these two problems defines the gcEVM architecture, which we will explore in the following sections.

The Sequencer

To overcome the challenge of input validation, we decided to treat transactions on the gcEVM in the same way they are handled by the Ethereum Beacon Chain. On post-merge Ethereum, validator nodes sequence transactions and arrange them by priority. They then generate a new block by sending these transactions to a legacy Ethereum node (now called the execution layer), which in turn produces the execution block. The difference in the gcEVM is that we still use a single blockchain and do not rely on a separate chain for sequencing.

We achieve this by generating a pseudo state block and then replacing it with a canonical block. The pseudo state block contains a sequence of transactions taken from the transaction pool and is valid in all respects. However, its transactions are only executed to the extent of their non-private state, since the sequencer cannot compute on secrets it does not know.

The pseudo state block can still be validated and replicated by any node that implements the EVM state transition protocol. When this block is transmitted to an execution node, it is first verified. Its transactions are then validated with their private state, generating a new canonical block with the same number. This canonical block replaces the pseudo block and becomes the new chain head.

Once a new canonical chain head is added, the sequencer node repeats the process by generating a new pseudo state block from the transactions in its transaction pool.

The “pseudo state” block

To build some intuition about the pseudo state block, consider the following rule: No more than one pseudo block can be valid, and this block must be the chain’s head. This means the chain is either entirely composed of canonical blocks or has a single pseudo block as its head. There is no case where a pseudo block can serve as the parent of another block anywhere in the chain.

Earlier we noted that evaluating private operations costs orders of magnitude more gas. You might wonder what this means for the block gas limit. The answer is that since there is no way to predict the total gas cost of private operations, the actual gas usage of a transaction may end up much higher in the canonical state than in the pseudo state.

As a result, some transactions may be included in the pseudo state block but later excluded from the canonical state block. When this happens, those transactions return to the transaction pool and must wait to be picked up again. Don’t worry though—this non-canonical state is never visible to outside nodes, so the reorganization does not affect the state of your applications or accounts.

Finality over liveness

By now, you probably have a clearer understanding of our “finality over liveness” property. This is a direct result of the consensus rules described in the previous section.

While the chain head is in pseudo state, no additional pseudo blocks can be generated until the pseudo head is replaced by a canonical block. This means we must wait for canonical evaluation, which in most cases takes around 5 seconds. In rare cases it may take longer, with diminishing probability, and in extremely rare cases it can exceed 7 seconds.

We cannot know evaluation times in advance. Block times can only be approximated based on gas limits. After each canonical block, a new pseudo head is generated. The pseudo block number always increments by 1, which prevents forks and guarantees immediate finality.

How transactions are executed

When the pseudo block is received by the execution nodes, or “Executors” for short, it is first validated according to the CO2 consensus engine rules [discussed here]. After validation, the block’s transactions are parsed again, this time with private operations taken into account.

Whenever a private operation needs to be performed, it is sent to the gcEVM evaluators. These evaluators use a garbled-circuits-based MPC technique to return the correct encrypted output. In other words, encrypted data goes in, encrypted data comes out, and no decryption occurs in between.

The results allow the transaction’s true execution, which is then included in the new canonical block. This process is delicate and is discussed in more detail [here]. Once the canonical block is sealed, it is transmitted to the rest of the chain to be evaluated and validated, allowing it to be incorporated as the new canonical block.

Solving the replication problem - The Transcript

As we mentioned earlier, there is an inherent problem with performing state transitions to validate non-executable private transactions. To address this, we made changes to the block body and header structures.

Each gcEVM block contains in its body a Transcript, which stores the encrypted results of the private operations performed in that block. Whenever a transaction with a private operation is evaluated, the process must rely on the transcript for the execution result. The transcript is also included in the signed hash to enable verification, ensuring that it has not been tampered with before the block is transmitted.

To take a step back, we can now see three distinct “modes of execution”:

• Sequencing or pseudo execution: performed initially by the Sequencer and later used by the Executors to validate the pseudo state block.

• MPC execution: performed by the Executors, who rely on gcEVM evaluation nodes to run the actual MPC.

• Transcript evaluation: performed by any entity, including Gateway nodes and Executors, when receiving a new canonical block over the wire.

These three modes will be expanded upon in the following sections.

The gcEVM canonical block

As mentioned previously, the gcEVM chain is composed of two types of blocks: the pseudo block and the canonical block. The canonical block differs from a normal EVM block in several ways:

• Transcript: as described earlier, the Transcript is a new addition to the block body. It contains the outputs of secret operations, and its hash is signed during the block signing process.

• Pseudo header: this is the header of the pseudo block that was used to serve transactions to the Executors. It is also signed during the block signing process.

• Multiple signatures: while normal EVM blocks are signed by a single block miner, gcEVM blocks are signed by all participants in their generation. Each Executor signs the block once, and the block also contains the Sequencer’s signature as part of the pseudo header, which can be verified.

Access to the gcEVM chain

To access the gcEVM network, participants can connect to a dedicated internal Gateway node via API. For developers who want direct chain access, it is also possible to self-host external Gateway nodes. These nodes do not play an active role in block generation and cannot earn by mining or validating blocks, but they contribute to the strength and stability of the network. More on the role of Gateway nodes will follow in the next section.

The CO2 consensus in a high level view

Let’s examine the three roles of the gcEVM node types as part of the CO2 consensus engine.

Executor nodes are responsible for managing gcEVM MPC execution (but not the MPC evaluation itself). They generate the canonical block, both producing the same block with the same Transcript, and both signing every canonical block. Executors evaluate blocks in three ways: through MPC execution when generating a new canonical block, through pseudo execution when validating the pseudo block, or through Transcript evaluation when re-syncing after a failure. They do not have direct access to the TxPool and instead rely on batches of transactions bundled in the pseudo block, as is common in L2 and rollup architectures. The Executors’ view of the chain will be partly in the pseudo head state and partly in the canonical head state.

In the current gcEVM version, a single Sequencer selects transactions from the TxPool to serve the Executors, similar to L2 and rollup architectures. Work is underway to decentralize this role. The Sequencer evaluates transactions in two ways: through Sequencing (the same as pseudo execution) when generating a new pseudo block, or through Transcript evaluation when receiving a canonical block. The Sequencer’s view of the chain is almost always that of the pseudo head.

Gateway nodes, sometimes referred to as full nodes, do not participate in block generation. They do not accept pseudo blocks at all and only see the canonical state of the gcEVM chain. Gateway nodes evaluate and validate canonical blocks through Transcript evaluation. They also have access to the TxPool and are responsible for broadcasting transactions to the Sequencer. There is no limit on the number of Gateway nodes, and they are fully decentralized. Their role is to extend the network and provide participants with P2P access to the chain and its TxPool. Anyone can spin up a Gateway node and connect to the gcEVM network.

Summing up (TL;DR)

The gcEVM is a novel type of Ethereum Virtual Machine that enables privacy-preserving smart contracts by combining Garbled Circuits technology with regular EVM operations. It features instant finality with variable block times and introduces a new custom consensus mechanism called CO2. Users interact with the gcEVM network through Gateway nodes.

The gcEVM design provides privacy while maintaining the integrity of the blockchain. Future versions aim to further decentralize the Sequencer and Executor roles, along with other network entities, as part of the broader goal of making the gcEVM fully permissionless.