This is the 3rd blog in a comprehensive blog series meticulously exploring the intricate convergence of the Ethereum Virtual Machine (EVM) and the Cosmos ecosystem. Our investigation specifically scrutinizes this convergence through the analytical framework of layered blockchain architecture, a conceptual paradigm that has garnered substantial prominence subsequent to the pivotal Ethereum Merge in 2022.

Previous articles in this series, Part 1 and Part 2, primarily concentrated on elucidating the monolithic architectural paradigm, wherein a singular blockchain functions as a self-contained entity within the broader Cosmos framework. While instrumental for apprehending foundational concepts, this monolithic perspective does not fully encapsulate the evolving landscape of blockchain design.

The present article, conversely, reorients its focus toward a more granular examination of layered architectures. We will meticulously dissect the two fundamental layers that constitute such systems: the consensus layer (CL) and the execution layer (EL), as well as the interoperability between them. By rigorously analyzing the distinct responsibilities and functionalities of each layer, we aim to uncover their profound and respective implications for both the Cosmos framework and the EVM.

This in-depth analysis will illuminate how the judicious separation of concerns between these layers can engender enhanced scalability, flexibility, and interoperability within the blockchain domain, ultimately shaping the future trajectory of decentralized applications and networks.

Overview

Following the momentous Merge, the Ethereum mainnet underwent a fundamental transformation, resulting in a sophisticated architecture comprised of two distinct and specialized functional layers.

• Execution Layer (EL): This layer serves as the computational engine of Ethereum, meticulously maintaining the Ethereum Virtual Machine (EVM) execution environment. It essentially retains its original implementation, responsible for processing transactions, executing smart contracts, and managing the network's state. The EL is where the "work" of the blockchain happens, where dApps reside, and where the decentralized applications truly come to life. Clients within this layer, such as Geth, Erigon, and Nethermind, are crucial for maintaining the EVM's operations and interacting with the network's data.
• Consensus Layer (CL): This layer is the backbone of Ethereum's security and integrity, solely dedicated to handling the network's consensus engine. It leverages the robust and energy-efficient Proof-of-Stake (PoS) algorithm, specifically Gasper FFG (Finality Gadget and Friendly Finality Gadget), inherited from the Beacon Chain. The CL is responsible for validating blocks, reaching agreement on the state of the blockchain, and ensuring the finality of transactions. Validators, staking their ETH, participate in this layer to propose and attest to blocks, thereby securing the network. Clients operating within this layer include Prysm, Lighthouse, Teku, and Nimbus, each playing a vital role in maintaining the PoS consensus.
• Engine API: An indispensable internal API, the Engine API acts as the crucial bridge facilitating seamless and secure communication between the Execution Layer and the Consensus Layer. This API ensures that the two layers can efficiently exchange information, allowing the CL to propose blocks containing transactions from the EL and the EL to receive validated blocks from the CL. This intricate communication is fundamental to the operational harmony of the post-Merge Ethereum network.

Since the Merge, the inherent complexity of Gasper FFG: Casper FFG (Friendly Finality Gadget) with combining of LMD (Latest Message Driven) - GHOST (Greedy Heaviest-Observed Sub-Tree), to elaborate on the aforementioned glossary, is not even easy to understand.

Interoperability via Engine APIs

Interoperability through the Engine API is a key area of focus. Since the Merge, the Engine API has seen several iterations, with version 5 anticipated by Q4 2025 alongside the upcoming Fusaka upgrade. However, this article will use the [Shanghai Spec] (https://github.com/ethereum/execution-apis/blob/main/src/engine/shanghai.md) as an example to demonstrate the interoperability between the Execution Layer (EL) and Consensus Layer (CL) via Engine API v2:

• engine_exchangeCapabilities: Facilitates the exchange of supported Engine API methods between clients;
• engine_forkchoiceUpdatedV2: Updates the fork choice of the EL client and initiates the payload build process;
• engine_getPayloadV2: Retrieves an execution_payload from a build process previously started by engine_forkchoiceUpdatedV2 by CL client;
• engine_newPayloadV2: Used by the CL client to send an execution_payload to the execution layer client for validation

The complete workflow is illustrated in the following image:

According to Blocks, the execution_payload, representing a duplicate of the Execution Layer(EL) block, is an integral sub-field within the beacon block object. It is crucial for the beacon block's creation and propagation in the Consensus Layer (CL). The process unfolds as follows:

1. Block Proposal: A validator (V) is designated to propose a new beacon block when it is created for a specific slot.
2. Payload Initiation: The proposer (V) must incorporate the execution_payload into the beacon block. This is achieved by sending engine_forkchoiceUpdatedV2 to the Execution Layer (EL), which updates the EL client's fork choice and initiates the execution_payload build process. The CL receives a buildProcessId as a response.
3. Payload Retrieval: The proposer V subsequently retrieves the execution_payload using engine_getPayloadV2, referencing the buildProcessId from the previously initiated build process.
4. Block Creation and Propagation: The retrieved execution_payload is integrated into the beacon block, updating the state_root. The block is then propagated within the CL.
5. Block Validation: Other validators receive the proposed beacon block and commence validation. The execution_payload is extracted from the beacon block and transmitted to the EL for validation via engine_newPayloadV2.
6. Chain Generation: If all checks are successful, the validator adds the block to its canonical chain, and this process is repeated for subsequent slots.

New Chain Layers with Consensus Replacement

Ethereum's architecture, featuring decoupled Consensus Layer(CL) and Execution Layer(EL), facilitates the integration of new consensus engines into the CL while maintaining compatibility with the existing EL. This is achieved through the Engine API, which carefully designs communication protocols and data structures to ensure seamless information flow and network stability, thereby optimizing Ethereum for efficiency, scalability, and resilience.

In the past two years, innovative projects like Berachain and Story Protocol have actively explored alternative consensus mechanisms. A significant area of this research and development focuses on the feasibility of replacing Gasper FFG with CometBFT(former Tendermint) in the Consensus Layer. The CometBFT, a well-established and widely utilized Byzantine Fault Tolerant (BFT) consensus engine, offers distinct characteristics and potential advantages that some teams believe could enhance certain aspects of the Consensus Layer compared to Ethereum.

BeaconKit, the Berachain Consensus Layer, is a groundbreaking, modular consensus layer that integrates the CometBFT consensus algorithm with any EVM execution environment, making it compatible with EVM blockchains. This is achieved by bundling CometBFT with a modular middleware layer engineered to accept blocks from any execution environment adhering to the Engine API specification. The overall architecture can be seen below:

CometBFT's consensus mechanism, as detailed in the ABCI++ specification, significantly differs from Ethereum's. Block creation involves four primary ABCI interfaces/methods, which can be understood by comparing them to the Ethereum mainnet process:

1. PrepareProposal: This method enables the block proposer to execute application-specific tasks before proposing a block. This phase encompasses Payload Initiation to Block Creation and Propagation using Engine APIs, such as engine_forkchoiceUpdated and engine_getPayload.
2. ProcessProposal: Validators utilize this method to perform application-dependent work on a proposed block. During this phase, Block Validation occurs, with engine_newPayload sent to the EL for block validation.
3. FinalizeBlock: This method delivers a decided block. Due to CometBFT's instant finality, there is no fork choice rule imposed in CL. However, finally, an ForkChoiceUpdate (FCU) request, without payload attributes, is sent to EL clients to update the state.
4. Commit: This instructs to persist its state with Chain Generation. Additionally, the processes are repeated for subsequent slots.

Security Issues By Discrepancy

Substituting CometBFT as an alternative consensus layer appears to be largely compatible with the current Engine API specification and the existing EVM execution layer. Nevertheless, slight discrepancies between the two consensus algorithms and their respective implementations might introduce high-severity vulnerabilities.

Inappropriate Error Handling in ProcessProposal Leading to Consensus Level issues

As highlighted earlier, the four core methods(PrepareProposal, ProcessProposal, FinalizeBlock, and Commit) within ABCI form a robust consensus engine. These methods are designed with atomic revert operations to ensure the consistency of the entire block production process.

In the BeaconKit Cantina Competition Report, the ProcessProposal step, essential for validating proposer creations, treats all errors as "non-fatal", as shown in the code snippet below:

When an invalid proposal is encountered, two approaches are possible:

• Reject the proposal entirely.
• Accept the proposal but defer processing.

BeaconKit adopts the second approach, accepting all proposals regardless of their correctness, as shown in the code snippet below:

This design choice results in createProcessProposalResponse accepting invalid proposals, which impacts the subsequent process during the block finalization stage within FinalizationBlock. This will lead to several severe consequences:

• The CL will process blocks that contain an invalid execution_payload (EVM transactions).
• The CL will accept Blob transactions, even if they lack sidecars in storage.

To ensure alignment with the Execution Layer, the ProcessProposal logic must reject proposals that lead to an execution error, thereby reverting the proposal process.

Malicious User Can Halt Chain by Issuing 2 Similar Blobs in Single EVM Block

The verifier.verifySidecars function, used in ProcessProposal to verify sidecars, fails when duplicate KZG commitments are detected due to an error in its duplicate detection logic, as shown in the code snippet below:

If two blobs within a single EVM block contain identical data, they will generate the same KZG commitment. When the Consensus Layer (CL) prepares a proposal for this EVM block from the EL, it will include two sidecars with identical KZG commitments. This will cause ProcessProposal to fail due to a flaw in the aforementioned duplicate detection logic. Consequently, a malicious user could exploit this to halt the chain by submitting two blob transactions with identical blob data, leading to repeated proposal reversions.

Duplicate KZG commitments should be accepted by the duplicateCommitment check when the sidecar index differs. This allows for two blobs to contain identical data while preventing duplicate sidecars.

Summary

Inspired by Ethereum's post-Merge architecture (since 2022), this article explores a layered blockchain design consisting of an Execution Layer, a Consensus Layer, and Engine APIs for inter-layer communication.

Significant innovation has emerged through adapting this model, particularly by replacing Ethereum's consensus layer with the widely adopted CometBFT engine. This approach aims to deliver an enhanced scalability EVM (Ethereum Virtual Machine) experience while preserving security and robustness. Projects like Berachain and Story Protocol demonstrate the success of this approach in achieving desired outcomes.

However, differences in consensus engines can introduce potential flaws in both mechanism and implementation, necessitating thorough investigation. CertiK is dedicated to providing fundamental security assessments to safeguard the overall security of complex blockchain protocols employing layered architectures.

References:

1. Engine API
2. Ethereum Shanghai Spec
3. Casper the Friendly Finality Gadget
4. Combining GHOST and Casper
5. Ethereum Blocks
6. Berachain
7. Story Protocol
8. CometBFT ABCI Spec
9. BeaconKit Cantina Competition Report