# EVM<>Cosmos Convergence Research From Security Base Part3
**TL;DR:** 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.
Preceding articles in this series, [Part-1](https://www.certik.com/resources/blog/5qV6J92hIMutH80pzRGHD3-evm-cosmos-convergence-research-from-security-base-part-1) and [Part 2](https://www.certik.com/resources/blog/evm-cosmos-convergence-research-from-security-base-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), and 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 the aforementioned grossary 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 image below:

According to [Blocks](https://ethereum.org/en/developers/docs/blocks/), the *execution_payload*, representing a duplicate of the execution layer 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 response.
3. **Payload Retrieval**: Validator 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 (CL) and Execution Layers (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 recent 2 years, innovative projects like [Berachain](https://docs.berachain.com/) and [Story Protocol](https://docs.story.foundation/introduction) 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 Ethereum-based 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](https://docs.cometbft.com/v1.0/spec/abci/abci++_basic_concepts), 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 covers **Payload Initiation** to **Block Finalization and Propagation** using Engine APIs like `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**. As well the processes are repeated for subsequent slots.

## Security Issues By Discrepency
Substituting CometBFT as an alternative consensus layer seems 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](https://github.com/berachain/security-audits/blob/main/20250221-BeaconKit-CantinaCompetition.pdf), the **ProcessProposal** step, essential for validating proposer creations, treats all errors as "non-fatal", just as below code snippet shown:
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, just as code snippet shown:
This design choice results in `createProcessProposalResponse` accepting invalid proposals and impact the following 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 for 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, just as below code snippet shown:

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 from 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.

## Reference:
1. [Ethereum Execution Transition](https://eth2book.info/latest/part3/transition/execution/)
2. [Engine API](https://hackmd.io/@danielrachi/engine_api)
3. [Ethereum Shanghai Spec](https://github.com/ethereum/execution-apis/blob/main/src/engine/shanghai.md)
4. [Casper the Friendly Finality Gadget](https://arxiv.org/pdf/1710.09437)
5. [Combining GHOST and Casper](https://arxiv.org/pdf/2003.03052)
6. [Ethereum Blocks](https://ethereum.org/en/developers/docs/blocks/)
7. [Berachain](https://docs.berachain.com/)
8. [Story Protocol](https://docs.story.foundation/introduction)
9. [CometBFT ABCI Spec](https://docs.cometbft.com/v1.0/spec/abci/)
10. [BeaconKit Cantina Competition Report](https://github.com/berachain/security-audits/blob/main/20250221-BeaconKit-CantinaCompetition.pdf)