The Rollup - Modular Appchain Design Choices with Cartesi - Revelo Intel

The Rollup – Modular Appchain Design Choices with Cartesi

In this episode of The Rollup, which took place on March 14, 2024, Robbie, Andy, and Felipe discuss the differences between app-specific rollups and general-purpose chains and choosing a modular stack composition. Read our notes below to learn more.

Background

  • Robbie (Host) – Merkle Tree Maxi, Co-Founder of The Rollup
  • Andy (Host) – zkProof Maxi, Co-Founder of The Rollup
  • Felipe (Guest) – Co-Founder of 
  • Cartesi – an application-specific rollup protocol with a Linux runtime

Modular Execution Layers

  • Felipe says that execution layers are context-dependent, varying based on goals and requirements, with numerous factors influencing their design. Felipe shares his background as the first Dev lead of rollups implementation at Cartesi and his current role as an advisor at Cartesi Foundation.
  • He talks about the fundamental components of a modular stack: execution, settlement, consensus, and data availability layers solved by various solutions New layers like aggregation, governance, meme culture, and convenience services are emerging within the modular stack landscape.
  • Felipe emphasizes understanding the simplicity of an execution layer as a state transition function involving inputs leading to outputs in blockchain systems like Ethereum. The complexity arises from interdependencies between execution and data layers illustrated through a “cone of innovation,” showcasing computational capacity versus data availability for optimal resource utilization.

Metaverses and Computational Capacity

  • Felipe says that the scale of computational capacity and data availability ranges from Ethereum layer-1 to appchain rollups with modular DA. With varying computational and data capacities, different use cases require specific design choices.
  • He adds that there are factors to consider when designing or selecting an execution layer including:
    • Type of dApp being developed (e.g., gaming-specific or smart contracts).
    • Computational intensity is required for hosting on the execution layer.
    • Preferred programming language for coding (e.g., Solidity, Cairo, Rust).

Key Considerations for Execution Layers

  • Felipe says that determining the type of dApp being developed is essential as it influences design choices. Optimization goals impact trade-offs; high composability may lead to limitations in other areas. 
  • He adds that programming language preference (Solidity, Cairo, Rust) affects development flexibility and compatibility with existing codebases. Developer resources such as introspection capabilities and tooling availability play a significant role in deployment efficiency.

Latency Tolerance and Execution Environments

  • Felipe says that application-specific latency requirements determine the necessity for instant composability within the execution environment. He differentiates between DeFi applications requiring low latency versus games with potentially higher tolerance levels.
  • He adds that shared vs. isolated environments impact communication efficiency; shared environments cater to multiple dApps simultaneously but necessitate careful consideration due to complexity.

Proving Systems

  • Felipe says that choosing between validity proofs or fraud proofs involves intricate considerations aligning with the overall execution environment’s compatibility The ability to prove system functionality post-execution poses challenges related to prior design choices’ alignment with proving mechanisms.

Understanding Execution Layers in Blockchain

  • Felipe says that validators play a crucial role in ensuring the integrity of blockchain networks. Cheating is discouraged as it leads to financial losses for validators. A delicate balance exists where too much validation can discourage cheating, but excessive acceptance can lead to vulnerabilities.
  • He adds that privacy is a significant consideration in execution layers, particularly regarding inputs and states. Aztec is an EVM rollup with built-in privacy features from inception. Differentiating between privacy for inputs and states is essential for network security.

Factors Influencing Choice of Execution Layer

  • Felipe says that developers face various choices when selecting an execution layer:
    • Determining what constitutes an input influences connectivity to different data layers like Ethereum or Solana.
    • Defining output structures impacts communication with external protocols such as Uniswap on layer-1.
  • He adds that builders must consider multiple aspects when choosing an execution layer. Starting with defining the type of dApp being developed and progressing through compute power requirements, language preferences, speed considerations, and monetization strategies.

Navigating Execution Layer Possibilities

  • Felipe says that builders need to navigate numerous choices within execution layers. Understanding key considerations such as speed, composability, environment preferences (ZK, optimistic), and incentivization models for privacy inputs/outputs.
  • He adds that effective decision-making involves understanding trade-offs and aligning choices with project objectives:

Proofs Optimism and Execution Environments

  • Felipe says that the EVM aims to offer capabilities for shed rollups, emphasizing the need to understand different execution environments without being overly critical of their tradeoffs. The AVM plays a crucial role in settlement layers, particularly in shared rollups with privacy features like ZK tech.
  • He adds that shed rollups focus on instant composability but face limitations such as a competitive fee market and shared block space. Appchain rollups prioritize computational power for individual applications, sacrificing some composability.

Execution Layers Design Considerations

  • Felipe says that distinguishing between shed rollups and appchain rollups helps mitigate security risks associated with shared layers.
  • He adds that execution layers must be robust enough to handle malicious applications,and gas metering attacks, and ensure application integrity.

zkSync Design Choices

  • Felipe says that zkSync‘s design aligns with Ethereum’s computational limitations by optimizing hashing operations and leveraging zero-knowledge proofs efficiently. He emphasizes the importance of settlement layers for verifying ZK proofs efficiently and enabling fault-proof games within decentralized applications.

Execution Environment and Computational Power Optimization

  • Felipe says that Cartesi rollups utilize the Cartesian machine due to its alignment with the project’s goals and requirements. The focus is on leveraging RISC-V based architecture to enhance computation capabilities within isolated environments like nChain.
  • He says that emphasis is placed on providing expressiveness to developers through optimized tooling within the execution layer, catering to complex applications that require substantial computational resources. Features such as a file system and comprehensive tooling are integrated to support complex applications with varying data needs, allowing for decentralized customization based on specific application requirements.

Fraud Proof System Design

  • Felipe says that the fraud-proof system focuses on application-specific requirements, optimizing verification processes for enhanced security against delay attacks. Contrasting approaches like Arbitrum’s fraud-proofing system VAT challenge scalability when combating attackers, underscoring the importance of aligning fraud-proof systems with specific environment characteristics.
  • He adds that selecting appropriate fraud-proof systems is crucial to mitigate delay attacks effectively while ensuring computational efficiency during state transitions within applications. Balancing design choices between shared/general-purpose execution environments and app-specific/isolated environments is essential for optimizing performance based on distinct use cases and operational requirements.
  • Felipe says that metering is crucial in shared execution environments to prevent validators from losing money when validating multiple dApps. Validators need to be compensated fairly for executing transactions.
  • He adds that self-containment within EVMs ensures that deployed code cannot access the storage of other contracts, preventing unauthorized actions like stealing funds. This self-containment is vital for security and integrity within shared environments.

Balancing Computational Intensity and Functionality in AppChains

  • Felipe says that they avoid catering to computationally intensive applications in shared layers as it can lead to centralization or high costs for block space. Overloading validators with resource-intensive tasks can strain the network’s scalability.
  • He adds that appchains should aim to cover a wide range of functions within a domain to enhance usability and interoperability. Integrating functionalities like exchanges, governance mechanisms, and staking can create a holistic ecosystem on appchains.

Exploration of Tooling and Resources in AppChains

  • Felipe says that appchains provide an ideal environment for experimenting with new architectures like RISC-V or WebAssembly due to their flexibility and tooling support. Leveraging appchains for research on shared rollups presents challenges but offers opportunities for innovation. 
  • He adds that appchains offer customizability and sovereignty over execution environments, allowing builders to tailor solutions based on specific use cases without being constrained by external decisions.

Presentation Insights and Cone of Innovation

  • Felipe says that general-purpose environments require compromises across all considerations due to accommodating various dApps. Application-specific environments can prioritize specific use cases without compromising, allowing for tailored optimizations like lower latency or enhanced privacy.
  • He adds that shared environments are positioned at the bottom left of the cone, optimized for general purposes but with limited capacity and data availability. Application-specific environments reside at the outer edge of the cone, catering to cutting-edge dApps with increased computational and data availability capacities.

Expanding Considerations in Design Space

  • Felipe says that computational intensity, data availability, and privacy are ed as crucial factors influencing design decisions. Each consideration could potentially form an axis on a graph depicting optimization levels in design space.

Check out these important links

Show Information

  • Medium: Youtube
  • Show: The Rollup 
  • Show Title: Modular March EP 4: Modular Appchain Design Choices with Cartesi
  • Show Date: March 14, 2024