Is Modular Blockchain at Risk?

1. Modular Blockchain - From Development to Refinement

2023 was the year of the “Development” of Modular Blockchain. According to our tracking, more than 100 projects were developed around the core infrastructure of modular blockchain, diversifying the multiple layers of blockchain. The execution environment and settlement and data availability were diversified.

Many projects were launched in production mode, and many attempts are being made. This can be especially evident in the execution environment—supporting VMs like EVM, WasmVM, MoveVM, CairoVM, general RISC-V VM, and MIPS VM. Also, the settlement process, acknowledged as the proof generation and the verifying process, is diverse, and each project has developed different methods. The advancements observed in 2023 collectively underscore that this year marked the " Development " phase in Modular Blockchain.

Source: The Rollup

Following the "Development Phase," 2024 is the year of "Refinement." The integration of diverse components is gaining increased importance. Questions such as, "Would using an execution environment with OP-Stack, DA like EigenDA, and settlement in Ethereum be seamless?" or "What if we have shared sequencer sets in between? Will there be any risks?" arise.

Moreover, the full range of integration possibilities still needs to be explored. We need to compare different DAs regarding cost and security and see which rollup frameworks offer better integration with other services.

1.1 Security Risks Are Overlooked

Currently, the exploration of the integration of different modular blockchain projects is being actively tested. For instance, Celestia's Data Availability (DA) layer features a component known as blobstream. This relays commitments to Celestia's data root to an on-chain light client on Ethereum, which developers can integrate into L2 contracts. You might wonder, what happens if Celestia stops? Will it affect all the L2s that use Celestia as a DA?

Currently, Celestia has devised a fallback mechanism for each roll-up framework. If Celestia fails, the rollups will automatically post their data to Ethereum. However, this mechanism is still being developed and requires testing. Integrating different components carries potential risks, even with security measures in place. It's crucial to review the architecture for possible security and integration risks.

These risks are more apparent for projects that have started using rollup frameworks to develop their rollup. As these project devs lack expertise in the core codebase compared to the core framework team, updates to the codebase may be overlooked, causing breaking changes in their integration with other services. For instance, the recent halt of Blast due to the Ethereum Decun upgrade can be considered a case in point. This situation could pose a significant risk to the overall ecosystem.

Without careful coordination, divergence in the codebase of each rollup can become evident, as observed in the Cosmos ecosystem. The chains have evolved to resemble different codebases despite using the same Cosmos-SDK codebase. While the risks might be minimal in this ecosystem, since the entire stack is packaged in a single framework, it's different for a Modular Blockchain.

In this article, we'll explore the potential risks associated with Modular blockchain and examine specific projects, such as Dymension, Eclipse, and Gibraltar of Espresso, to understand their unique architectural risks.

2. Dissecting Modular Blockchain

Modular blockchain introduces new risks due to the integration between layers. These layers typically include execution, sequencing, data availability, settlement, and consensus, and dangers can arise due to the separation of these layers. In this context, a monolithic blockchain can be seen as layers combined into a single extensive layer. Before delving into the layers, let's examine how a monolithic Ethereum blockchain incorporated these layers.

2.1 On Ethereum - Combined Layers

Here's a step-by-step breakdown of the Ethereum finality process within the lifecycle of a block in the PoS context:

2.1.1 Execution: Block Proposal

• Ordering and Transaction: The chosen validator, which is randomly selected by their amount of staked ETH, aggregates transactions from the mempool, executes them, and proposes a new block containing these transactions along with a reference to the previous block (parent block), creating a chain of blocks.

2.1.2 DA and pre-Settlement

• Data Availability: Other validators (attesters) check the proposed block, validate its transactions, ensure it follows the Ethereum protocol rules, and vote for it by publishing an attestation that includes its signature, the block's hash, and the epoch.

• Once a block receives attestations from more than 2/3 of a randomly selected committee of validators, it is considered justified, indicating strong support for the block and a preliminary step towards finality.

2.1.4 Consensus by the Committee

• Finality: Finality is achieved when at least two consecutive epochs are justified, and the second justified epoch is directly linked to the first as its parent. This condition leads to finalizing the first epoch and all its blocks, including the blocks in the previous epochs that had not yet been finalized.

• A finalized block can never be reverted. This ensures the blockchain's immutability and protects against double-spending and history revision attacks.

2.2 Modular Process and Potential Risks

2.2.1 Sequencing: Ordering

In the context of sequencing, initially, the transactions are added to the sequencer mempool and then ordered. This setup allows some projects to enable users to directly send transactions to the Layer 1 (L1) blockchain. The sequencers order the transactions and produce a block that includes the ordered list of transactions.

Shared Sequencers that are to be in production this year are the ones that have multiple sequencers that handle the output of a block with an ordered list of transactions. Those are then sent to the execution nodes to change the state.

Potential Risks

• Centralization: The current process is centralized, with sequencers operated and storage managed by a single entity. This centralization presents inherent risks, notably censorship and the limitation that only allowed operators can interact with the Settlement Layer, such as Layer 1 blockchains like Ethereum, which is commonly used for rollups. However, shared sequencers (a set of sequencers shared among rollups) or a decentralized sequencer (a set of sequencers used by a single rollup) are trying to address this problem, but they are not in production yet.

2.2.2 Execution: State transition

The execution layer applies a list of transactions to modify the current state. This transition is carried out following predefined logic. For instance, in the Ethereum Virtual Machine (EVM), a simple token transfer alters the account balance for both the sender and the receiver. On the other hand, Fuel Network implements this transfer using the Unspent Transaction Output (UTXO) format. Furthermore, blockchains based on intelligent contracts contain codes that execute transactions.

This layer is currently experiencing a surge of experimentation, which can be categorized into three primary methods:

1. Enhancing Existing Virtual Machines: Projects such as zkSync have incorporated AA into their chain layer to improve user and developer experiences. Similarly, Kakarot, a zkEVM built on top of CairoVM, plans to incorporate parallel EVM execution by leveraging CairoVM's capabilities.

2. Developing New Virtual Machines: While the EVM has been the dominant virtual machine for blockchains, new VMs such as SVM, MoveVM, WasmVM, and general zkVMs (based on MIPS and RiscV) are currently under development.

3. MultiVM: Projects like MultiVM create an execution environment that allows EVM, SVM, and other VMs to coexist within a single execution environment.

Potential Risks

• Different VM Specifications: Currently, not all EVMs are the same; most of the EVMs are equivalents, which means they are not fully compatible with the original EVM. Certain EVMs might not support some opcodes. There will be some breaking components since dapps are trying to expand their reach by deploying to other blockchains with the same contract base. For example, a dapp in ZkSync had 921 ETH funds frozen in their smart contract (which was eventually resolved) since ZkSync had a gas calculation system different from EVM.

2.2.3 Data Availability: Publication of the block data

Currently, availability is mostly guaranteed by having transactions stored in L1. Nodes can check Ethereum to see the list of sequenced transactions.

Most of the projects utilized the underlying layer to publish the transactions. Since the Decun upgrade, Ethereum will have a much lower cost. However, this option is still expensive, and since most of the operating cost of rollups occurs from storing transactions, altDA projects like Celestia and Avail have been created to provide a cheaper alternative.

Potential Risks:

• Failure of altDA: The possibility of Ethereum's failure is low, but since altDAs have only recently been in production, they can fail. However, altDA projects like Celestia provide an option to allow rollups to use Ethereum as a DA when their network fails.

2.2.4 Settlement: proof of execution

Settlement is where the proof for the transition is made. There are currently three types: optimistic proof, zk proof, and hybrid

• Optimistic rollups validate transactions by default, only requiring proof of fraud if challenged.

• zkRollups employ zero-knowledge proofs to verify transactions while preserving privacy and ensuring fast finality.

• A hybrid proof combines the fast soft-finality of optimistic proof with the zk proof to reduce the long challenge window typically associated with optimistic proof. It's currently employed in various methods, including projects such as Fuel Network, Metis, and Kroma.

2.2.5 Consensus: finalization

Consensus is the final stage, where the alterations to the state of a modular blockchain or rollup are conclusively established. This stage serves to certify the finality of the modified storage and the root of the state. Most projects incorporate a time buffer for finalization to account for unforeseen scenarios. For instance, Optimistic rollups typically have a 7-day challenge period (which is subject to customization), and zk rollups also implement this buffer.

2.3 Dissecting Use Cases

Modular architecture is currently receiving significant attention in the field, yet its ecosystem remains in its infancy. One might think, "Isn't building a modular blockchain like stacking Legos?" However, modularizing and connecting the intricately linked layers is more complex than it seems. The difficulty in finding projects that have fully integrated various modular components at the time of research proves this. This section introduces several cases of modular projects analyzed through research, with the problems they tried to solve and potential threats their approach may encounter.

3. Case Study A: Espresso Sequencer

A centralized (single) sequencing scheme of L2s embeds several intrinsic problems as follows:

• Single Point of Failure: We have already seen several cases of block production halt due to the sequencer’s failure in the L2 blockchain. Their causes were reported to be software bugs and L1 gas fee outages, but the root cause of all the incidents is fundamentally the centralized operation of the sequencer. Some L2s have implemented “exit hatches” to let the users enforce the L2 node to execute their transactions and withdraw their funds when the sequencer halts its operation for a specific time range. However, when the exit hatch is activated, severe instability follows the chain as the validity of transactions cannot be verified and may lead to L2 forks.

• MEV of Sequencer: Centralized sequencers can be (rationally) motivated to extract economic values from user transactions through front/backrunning.

• Censorship: In extreme cases, a single sequencer can censor user transactions and exclude them from block production. Leading L2s have implemented sequencer feeds and fraud-proof mechanisms so that users or validators can identify or challenge the inclusion of submitted transactions. However, as application-level chain meta flourishes, users of those chains should be aware if their transactions handled by the single sequencer can be validated against censorship.

To address this, Espresso aims to decentralize the sequencing layer by performing an economic security-based consensus and providing strong pre-confirmation of transactions with scalability. Sequencing is based on a simple First-Come-First-Served manner, so the Espresso sequencer mitigates MEV and censorship issues. With its data availability layer, Tiramisu, Espresso attempts to resolve performance concerns on shared sequencing mechanisms. Also, as Espresso operates as a shared sequencing layer of Ethereum L2, it introduces the advantages of interoperability between rollups.

In addition, Espresso engages L1 validators for its consensus to provide stronger security than the other rollups. Espresso points out the bribery issue on current rollups, as L1 validators can be bribed to fork the roll-up smart contract state and profit themselves, as most of the economic incentives are captured by the sequencer in the current state. Collaborating with EigenLayer, Espresso enables Ethereum validators to subscribe to the HotShot consensus rules and get incentives aligned.

Espresso has been testing its performance with four testnet releases, integrating with different execution layers, including Polygon SDK, OP Stack, and Arbitrum Nitro. To introduce the architectural risks when the modular protocols are integrated, we decided to observe one of the testnets. Among them, we analyzed the architecture of Gibraltar testnet, which is the latest version and integration with Arbitrum Nitro. Gibraltar is deployed through Caldera as an Arbitrum Nitro instance named Milan and integrated the Espresso Sequencer.

As a result, it comprises:

• Sequencing: Espresso Sequencer

• Execution: Arbitrum Nitro

• Settlement: Ethereum

• Data Availability: Ethereum / Espresso Savoiardi (TBU)

For simplicity, the structure of Gibraltar is further explained in the Appendix.

3.1 Sequencing

Before addressing the issues, let’s examine how transactions are sequenced and posted via Espresso.

When the user submits a transaction to the rollup server through RPC services, the rollup server sends the transaction to Espresso API with the rollup’s identifier attached. Espresso bundles the user transactions every epoch named “view.” In each view, Espresso’s HotShot consensus randomly (based on the stake) selects one of the HotShot nodes as a block proposer that bundles the transactions into a block. The transactions in each view are ordered, using a First-Come-First-Served or Bid-based sorting approach.

In the broadcasting stage, Espresso leverages its data availability module. Espresso utilizes a small group of nodes with a sizeable staking set named DA committees for the fast process. After the block production, the block proposer sends DA committees the DA proposals, which consist of the block’s transaction data and epoch number. Suppose the proposal successfully passes with sufficient votes. In that case, the block proposer creates a Data Availability Certificate (DAC) and sends a cryptographic proof named “block commitment” that guarantees the block's validity to the other nodes. Normal nodes validate the evidence, and the block gets finalized if the proof gets votes with over 2/3 of HotShot stakes.

If DA committees fail, Espresso leverages the erasure coding proof-based mechanism. During the DA proposal vote, the block proposer shares a small chunk of data with all the other nodes in parallel. These chunks can, in theory, be used to reconstruct the block data when a sufficient number of chunks are aggregated, which means retrieving the block's data availability. The nodes with data chunks can vote for the DA proof validation, acting as a fallback for DA committees.

Generated block commitments are posted in the L1 Sequencer Contract, which validators can leverage to validate the sequencer’s actions. Blocks produced by the Espresso sequencer are subscribed by the rollup nodes, which selectively fetch the transactions in the block that match the rollup identifier.

The risks in the sequencing layer that the Gibraltar testnet may encounter are as follows:

• Spam Transactions: Espresso Sequencer sequences transactions without executing them, opting for a First-Come-First-Served or Timeboost method based on bidding for transaction ordering. If invalid transactions are included, they are part of the L2 block but do not trigger state changes. This method could stress the chain through malicious activities like spam transactions. Espresso encourages execution layers to prevent this by adopting the collaborative chain PBS (Proposer-Builder Separation) structure and enhancing data availability protocol. However, these are external issues from Espresso that require significant time and effort to resolve for the integrating protocols.

• Malicious Rollups: Rollup servers submit user transactions with a numeric identifier attached to let the rollup nodes filter the transactions in the batch that the Espresso sequencer produces. However, as Espresso does not block duplicated rollup identifiers, each rollup should implement protection that prevents cross-rollup replay attacks.

• Stake Table Management: Espresso's HotShot consensus mechanism manages & retrieves the validator state through a sequencer contract on Ethereum. Despite being an extreme case, radical changes in validator status should be handled as unintended results can be produced before the finalization of validator status changes in L1. According to Espresso, the stake table is currently in the development phase.

• Sequencer Stall: As described in the official documentation, Gibraltar still submits batch transactions through the Nitro sequencer, inheriting the potential for at least block production halts experienced by Arbitrum Nitro's single sequencer structure. Ideally, the Espresso sequencer should directly submit batch transactions to L1 to enhance its decentralized features.

• Centralization Risk: Despite claims of decentralization, the degree of decentrlization varies based on the structure of the shared sequencer. In Gibraltar, the Espresso Sequencer is operated by an external node operator, Blockdaemon, running nine nodes in different regions. The low number of nodes can be understood at the level of a proof-of-concept testnet, with potential resolution in the upcoming Espresso mainnet deployment. Regarding the censorship issue, Espresso effectively mitigates by committing proofs to the L1 sequencer contract that enables rollup executors to validate the execution of all transactions the sequencer delivers.

3.2 Execution

Gibraltar inherits the risks of Arbitrum Nitro by combining it with the Espresso sequencer.

• Centralization Risk: Arbitrum has a Security Council that can upgrade critical contracts without delay in emergencies. The Arbitrum DAO designates these entities. As a proof-of-concept testnet, the documentation does not mention the security challenges. However, projects using the Arbitrum tech stack as an execution layer might need to establish their own Security Council through governance, placing trust burdens on users.

3.3 Settlement

Proofs of bundled transactions executed at the execution layer are stored in Ethereum's Inbox contract, and proofs of consensus results from Espresso sequencer nodes are stored in Ethereum's HotShot contract. Transaction validity is verified through off-chain computations in the WASM VM.

• Fraud Proof Implementation Challenges: Implementing fraud proof conditions is challenging due to the high computational cost of verifying state changes down to the opcode level within a short timeframe. Since the batch poster and commitment submitter differ in Gibraltar, it faces the additional challenge of developing another fraud proof mechanism to verify commitments from HotShot. This task is shared by most rollups and modular chains, including those based on Optimism.

3.4 Data Availability

Gibraltar's current implementation uses Ethereum for data availability, with long-term plans to apply Espresso's DA layer, Tiramisu, directly or indirectly through AnyTrust.

• Malicious DA Participants: A randomly selected DA leader, who is identical to the block producer elected by HotShot consensus, can harm the chain's usability by intentionally delaying the delivery of the Data Availability Certificate to the L1 sequencer contract. Espresso addresses this by facilitating economic control through slashing, but this indicates potential instability/inability to be combined with the other data availability protocols.

• Espresso DA layer optimistically handles the data availability problem, as a randomly sampled DA committee is selected to hand over the entire data blob retrieved by the DA layer. However, as previously explained, it could effectively be managed through the fallback mechanism if an issue occurs. Like the other data availability protocols, such as Celestia and Avail, Espresso DA utilizes erasure coding proof in VID to verify data availability with small data chunks retrieved from storage nodes. Therefore, Espresso DA generally provides very fast data retrievability from a randomly selected DA committee that retrieves the entire data blob and utilizes an erasure coding proof-based mechanism in case of failure.

3.5 Conclusion

Espresso has operated testnets with various execution layers, such as Arbitrum Nitro and OP Stack, and plans to release a complete modular chain with support from other data availability protocols. However, challenges remain, including implementing fault proof for HotShot commitments, fully decentralizing the sequencer, and ensuring compatibility with data availability protocols.

4. Case Study B: Dymension

Dymension aims to resolve the need for interoperability among the rollups by providing a common settlement layer for them and enables easier development & deployment of Appchains through their rollup SDK.

The settlement layer, Dymension Hub, is based on the Cosmos SDK and operates through Tendermint for state consensus via proof of stake. Dymension Hub features an IBC-like bridge between rollapps and includes an AMM within Dymension Hub for liquidity sharing among appchains, similar to Injective. Dymension emphasizes modular blockchain through various DA layer compatibilities and easy rollapp deployment via the SDK.

Dymension's layers are managed by:

• Sequencing: RollApp Sequencer

• Execution: Dymint Rollapps

• Settlement: Dymension Hub

• Data Availability: Celestia / Avail

The overall structure of Dymension is further explained in the Appendix.

4.1 Sequencing

• Centralization Risk: Each rollapp in Dymension whitelists sequencers through governance. The sequencer used for transaction processing is probabilistically determined based on the staking amount of DYM tokens, with the transaction result being relayed to the DA and Settlement layers. However, if the rollapp operator's staking amount overwhelmingly exceeds that of users, it could effectively centralize operations to the rollapp's own (or correlated) sequencer. Dymension mitigates this issue partially through the forced inclusion of transactions via the settlement layer.

• Malicious Sequencer: While there's a risk of sequencers intentionally delaying transactions, Dymension implements a mechanism to slash staked tokens if transactions are not processed within a specific timeframe. However, as the sequencer's staked DYM provides the economic security guarantees, there's still a risk of user funds being stolen or frozen by off-chain sequencers, especially when DYM price plummets due to security incidents.

4.2 Execution

Each rollapp is implemented based on Dymint, a Tendermint-based program, with functional elements handled by servers and block generation and interoperability features by clients. The execution stage does not involve consensus, which Dymension Hub manages upon receiving the state root from Dymint.

• Faulty Data Publication: Dymint submits its state values, state root, and references to the data availability layer to both the data availability and settlement layers. Validators and sequencers guarantee the integrity of computations through staking, but no such collateral is found at the execution stage. Unless validators perform semi-pessimistic validation, significant usability issues or rollapp forks could result if challenges are not made within the challenge period.

• Malicious Rollapps: For easier onboarding of developers, Dymension provides Rollapp SDK with the basic functionalities of Rollapps that are implemented. However, if integrity tests are not performed on the Rollapp implementation, which detects the revision of core functionalities that may incur unintended or malicious behaviors of Rollapps. As Rollapps are closer to an independent chain than a contract, users would have more difficulty finding backdoors or risks that may make their funds frozen or lost.

4.3 Settlement

Dymension rollapp operates as an optimistic rollup, verifying transactions through fraud proof like Arbitrum. If a challenge is initiated, the settlement layer's rollapp virtual machine re-executes the transaction to verify state consistency. Uniquely, it allows anyone to challenge through a permissionless fraud proof system.

According to the documentation, the fault proof system of Dymension is currently in the testing phase, with only EVM rollapps included in the scope.

• DoS Attack on Fraud Proof System: The permissionless fraud proof system, which allows anyone to demand system challenge resolutions, must be robustly designed to withstand DoS attacks. It would be helpful if Dymension published the result of a stress test on its permissionless fraud proof system.

• Short Dispute Period: The current mainnet's dispute period is set to approximately 120,000 blocks, which seems short considering Dymension's previous testnet performance of [~20,000 TPS](https://docs.dymension.xyz/learn/rollapps/architecture/dymint/#transaction-lifecycle:~:text=As blocks are produced optimisitcally and don't require active network validation Sequencers are able to produce blocks at configurably low block times. RollApps deployed to the 35-C network were able to maintain an average latency period of 0.2 second with max TPS of ~20%2C000 transactions.). Although Dymension rollapps are designed to produce blocks on-demand, the malicious party can enforce block production by DoS behaviors. Thus, sufficient time is necessary for users to detect anomalies in transaction processing and initiate challenges.

• Economic Risks: The trust basis for Dymension's settlement and sequencing relies on participants staking DYM tokens. However, a token price crash due to exploits or network instability may lead to a token price crash, as the economic value-based security of the chain would be weakened.

4.4 Data Availability

Dymension allows each rollapp to submit chain state values to either Celestia or Avail, based on the rollapp's choice. Both Celestia and Avail employ erasure coding proof, similar to Espresso, to prove data availability with a subset of consensus.

• DA Finality: Celestia and Avail operate as individual chains, with data finalization taking approximately 15 and 20 seconds, respectively. However, as mentioned earlier, Dymension's challenge period is relatively short. Unanticipated behaviors could occur if challenges arise before the data availability protocol’s finalization.

4.5 Conclusion

Dymension aims to allow small-scale applications to deploy at the chain level, providing a low-cost settlement layer for fast transaction processing. However, the usability and security of each rollapp are decentralized at the rollapp level, with rollapps whitelisting sequencers and submitting state roots to the settlement layer. Users of Dymension rollapps should actively monitor the staking amounts of the rollapp nodes and participating sequencers, contributing to protocol safety through regular fraud proofs.

5. Case Study C: Eclipse

Eclipse aims to support Ethereum-level security while providing fast transaction processing speeds through the Solana VM execution environment, marking it as an Ethereum layer 2 protocol.

Eclipse includes the following components:

• Sequencing: Eclipse Sequencer

• Execution: Solana VM / Neon EVM

• Settlement: Ethereum

• Data Availability: Celestia

This architecture is considered one of the most modular among current modular blockchains.

5.1 Sequencing

• Centralization & Censorship Risk: Eclipse currently operates through a single, self-managed sequencer, bringing typical issues associated with centralized sequencers. If the sequencer stops, Eclipse's block production also halts. Like some rollups, including Arbitrum, Eclipse proposes a forced inclusion mechanism through L1 (Ethereum) to address this issue. However, even with a forced inclusion mechanism, the sequencer might engage in malicious activities, such as front-running L1 transactions with its transactions. Eclipse plans to decentralize the sequencer in the long term.

5.2 Execution

Eclipse's notable feature is its execution environment, consisting of Solana VM and parallel EVM. It claims to offer better usability through Solana's parallel processing speed, state size management, and fee management mechanisms. Additionally, Neon EVM allows deploying contracts written in Solidity to Solana through the Solang compiler, converting them into SVM bytecode.

• SVM & EVM Compatibility: Converting Solidity code into SVM bytecode for deployment on Solana is innovative but comes with compatibility issues.

  1) Solidity Updates: Solang must fundamentally operate like Solidity, fully supporting features that may be added or removed over time to avoid unintended bugs.

  2) EVM Compatibility: Eclipse supports contract deployment to SVM through Neon EVM, a parallel EVM. Given Ethereum and Solana's vastly different memory management and computation methods, technical challenges are inevitable. Fortunately, Neon EVM continuously undergoes security audits to identify vulnerabilities, with recent audits highlighting issues related to EVM standard spec mismatches or memory management problems. Eclipse's reliance on Neon EVM for EVM transaction processing means compatibility-related bugs during EVM transaction processing should be carefully considered.

5.3 Settlement

Eclipse nodes periodically submit state changes to an Ethereum contract called the validating bridge for performance improvement, choosing to submit only the state changes caused by transactions instead of the global state root.

• Malicious Nodes: Eclipse's node operators must actively participate in challenges to audit the malicious actions of relayers submitting batch transaction proofs. Details on incentives or staking requirements for node operators have not yet been disclosed.

5.4 Conclusion

If Eclipse completes its planned structure before mainnet deployment, it could become an ideal modular blockchain with excellent structure and performance. However, challenges remain, including decentralizing the sequencer, implementing an incentive model for Eclipse nodes, and implementing zero-knowledge fraud proofs through RISC Zero.

6. Key Insights: Overview of Risks

6.1 Premature Ecosystem

We could observe each project building the modular ecosystem deeply considering security risks, but research on risks that may arise in integrating the layers is still lacking. Thus, to avoid unidentified risks of the modular architecture, most chains that claim “modular architecture” are conservatively approaching, applying DA layers on the existing architecture.

6.2 Centralization Issue Remains

To integrate layers with different operating entities and execution environments, some architectures rely on centralized entities that relay execution results or proofs to other layers. This may lead to more complexity in managing the entire chain’s operation, as those chains introduce multiple points of failure. Relying on multiple centralized entities is different from decentralization; the latter guarantees its operation while some entities malfunction, while the former fails its operation when one of the entities malfunctions.

6.3 Concerns on Data Availability Protocols

The data availability layer is the most critical part of the modular structure, as it guarantees the integrity and scalability of the chain. However, data availability protocols are based on cryptographic proofs such as erasure coding proof, which introduces development difficulties. Reflecting this, there are very few data availability protocols compared to other layers that compose modular architecture.

Although the concept of Erasure Coding has been around in academia for some time, it has not been long since its introduction to blockchain, and we cannot neglect the possibility of unintended behaviors. Also, as erasure coding proof is known to be inappropriate for validating large-size data, it might not be appropriate for future executing layers that have large blocks or using it for fraud proofs.

When the data availability layers malfunction, many protocols may experience data availability issues simultaneously. As mentioned earlier, a fallback mechanism to directly submit data to Ethereum has been devised in case of issues in data availability protocols. However, it is still in the development stage.

Furthermore, the security of data availability protocols is based on tokens staked at each node, meaning the security level of the protocol can vary depending on the activity of projects linked to the data availability protocol. Therefore, the data availability layer will need to have an appropriate number of protocols to coordinate the degree of centralization.

7. Looking Ahead

7.1 Various Proof Systems Are Coming Soon

In the past, the proof systems of modular blockchain projects were straightforward, typically employing either optimistic proof or zk-proof for their execution. However, recent trends have seen a diversification of approaches in the proof system aimed at both enhancing performance and enhancing overall system security.

Optimism, for instance, has introduced its fault-proof system, making it modular and potentially allowing for the integration of zk for added security. Additionally, entities such as risczero and ZKM are offering their zkVM infrastructures to facilitate the implementation of a hybrid-proof system.

7.2 Emerging Shared Security Infra

The primary concern regarding the overall security of a modular blockchain stems from its dependency on the security of other infrastructures. Any failure in one part of the system (for example, the Data Availability layer) could halt the operation of a rollup. This could further incur issues, as those components are also utilized in other modular blockchains.

To mitigate these risks, projects are adopting two main strategies. The first is the utilization of infrastructure with high economic stakes, such as EigenDA, leveraging restaked ETH and Babylon’s Bitcoin checkpointing. The second approach involves designing modular blockchains, particularly some rollups, to automatically leverage other Data Availability layers if the one they are using fails.

Given blockchain's composable nature, which allows for the lending of economic security, we can expect further interesting developments in this area over the coming year.

APPENDIX A. Architecture of Gibraltar by Espresso

Gibraltar is the Espresso Sequencer 4th testnet release in Jan 2024. One of the key updates is that it supports Arbitrum Nitro.

Source: Arbitrum Nitro integration - Espresso Sequencer

Let’s walk through the process:

1. Transaction Submission:

• Users/dapps submit transactions to the Arbitrum Nitro RPC node.

1. Sequencing:

• The Nitro node forwards transactions to the Espresso Sequencer for ordering.

• The Espresso Sequencer sequences the transactions and builds them into blocks using its Namespaced Merkle Tree (NMT) structure.

• Each Espresso Sequencer block is committed to Ethereum using HotShot.

1. Block Mapping

• A 1-to-1 mapping is used where each Espresso Sequencer block maps to a single Arbitrum Nitro block.

1. Block Production

• When a new Espresso Sequencer block is produced, the Nitro node builds a corresponding Nitro block containing the sequenced transactions.

• It generates an "EspressoBlockJustification" containing the Sequencer block header and NMT proof to link the Nitro block.

1. Validation

• The WASM validator is modified to accept sequenced transactions and the HotShot commitment as inputs.

• It validates that the Nitro block matches the sequenced transactions. Invalid transactions are included but cannot cause state changes.

1. Data Availability:

• Initially, Ethereum L1 provides on-chain data availability for Nitro blocks.

• Future integrations could leverage the Espresso Sequencer's Tiramisu DA.

1. Preconfirmations

• Clients can query updated Nitro state from nodes before blocks finalize on Ethereum, enabling faster confirmations.

APPENDIX B. Architecture of Dymension

Dymension, a decentralized Delegated Proof-of-Stake L1 blockchain, which provides RollApps with security, interoperability, and liquidity.

B.1 Transaction Flow

1. Users submit transactions to the Sequencer

2. Sequencer processes, orders and batches transactions

3. Blocks are gossiped to full nodes and published on-chain

4. Full nodes verify state roots against network data

5. Sequencer submits new roots to the Dymension Hub

6. Hub tracks roots and can revert invalid transitions

Source: Dymint | Dymension Docs

B.2. Components

The RollApps architecture is divided into several key components, each with its own specific function.

B.2.1 Sequencer

The Sequencer is responsible for validating, ordering, and processing transactions that are submitted through its RPC endpoint. It provides users with immediate state updates following transaction processing and batches processed transactions into blocks at intervals that can be configured. Furthermore, it publishes these blocks to peer full nodes and a data availability network. Finally, it submits new state roots to the Dymension Hub after data acceptance.

The execution logic is built with Dymension RDK (RollApp Development Kit), which is a fork from Cosmos-SDK, allowing customization for Rollapps.

The Dymension RDK allows most Cosmos SDK modules to be integrated into the RollApp for development purposes. Core modules inherited from the Cosmos SDK and IBC include Bank (for facilitating token transfers), Gov (for on-chain proposals and voting), Upgrade (for handling software upgrades), and IBC (a bridging protocol).

B.2.2 Full Nodes

The Full Nodes receive blocks from Sequencers via gossip, which allows for low latency state updates. They can also request block data from the data availability network and verify the RollApp's state root against data on this network.

B.2.3 Data Availability

The Data Availability Network is a decentralized network where Sequencers publish block data. Full nodes can retrieve data from this network to verify state roots. This network ensures long-term data availability and integrity. It currently uses a built-in DA, but could support other altDA in the future.

B.2.4 Consensus by Dymension Hub

Lastly, consensus is achieved by the Dymension Hub. RollApps outsource consensus to Dymension and produce blocks optimistically. The Dymension Hub coordinates optimistic state root updates from Sequencers. It has the power to revert RollApp state transitions if they are proven invalid by fraud proofs. The network validates these fraud proofs by retrieving data from the network. Additionally, it provides trustless bridging between RollApps and light clients.

B.3 Reference

• Dymension RDK | Dymension Docs

• dymensionxyz/dymension: Dymension Hub

• dymensionxyz/dymint: Sequencing Engine for Dymension RollApps