Brought to you by @0xfan

• Several rollups are presently engaged in constructing their individual L2/L3 application ecosystem through the provision of diverse SDKs. Nevertheless, certain hindrances continue to limit widespread adoption. One possible explanation for this is the development friction associated with building application rollups.

• Building a rollup using an SDK typically involves several stages that can cause development friction. These stages include node services, installation and debugging, customization, smart contract development, and maintenance.

• Customizing a rollup, such as integrating a new VM, is a complex undertaking for the rollup development team. It requires a comprehensive understanding of the workings of each VM, extracting the code base, and adapting the VM into the various interfaces provided by each rollup SDK, such as the ABCI interface for Rollkit. Additionally, the most time-consuming aspect of developing a vanilla rollup typically involves resolving various errors and issues that arise during the process.

• Building a rollup also involves making several trade-offs, such as balancing trustlessness and efficiency. The finality of rollup transactions is classified into three levels, and the level of trust required increases as faster finality times are desired.

• In fact, the presence of an intermediary capable of mitigating development difficulties and facilitating flexible navigation between the associated trade-offs is indispensable for building the application rollups. This is when RaaS comes into the market.

• The implementation of a pay-to-use business model is not a requisite for RaaS to create revenue. A different strategy could include offering free access while generating income through the capture of MEV and potentially a share of transaction fees. Another viable option is to establish a central platform that streamlines bridging, liquidity, and security for all application rollups, consequently capturing their value.

• How can we identify a high-quality RaaS product? The most critical factor is the provider's ability to offer a diverse range of virtual machines (VMs). A greater variety of VMs is more important than other services. RaaS should prioritize its role as a VM-as-a-service provider before offering any additional features.

• In addition, projects with well-established nodes and robust node management structures are viable candidates for RaaS. For example, Eigenlayer could potentially leverage its existing platform to develop another RaaS offering.

With the advancements in modular rollups and their SDKs, numerous rollups have emerged with promising futures in this space. For instance, Optimism has introduced Op Stack, Zksync has open-sourced its Zk Stack, Arbitrum has Abirtrum Nitro, while Polygon has developed its rollup-centric 2.0 architecture. The availability of generic block space is no longer the primary constraint; instead, the focus has shifted to convenience and customization.

In the last article, we conducted a comparison of the existing Rollup-as-a-Service (RaaS) projects and their features. However, a pertinent question remains unanswered: In a multi-rollup ecosystem where each Layer 2 network has its own Layer 3 and SDK, why do developers prefer RaaS over building their own L3/rollup using mature SDKs?

To answer this question, we can initially look into the Web2 world and explore why a developer might opt for KaaS instead of running Kubernetes themselves.

Containers refer to a software technology that enables the virtual packaging and isolation of applications for deployment purposes. On the other hand, Kubernetes, also referred to as K8s, is an open-source system designed to automate the deployment, scaling, and management of containerized applications. By offering a platform to schedule and execute containers, it brings structure and organization to the process while also automating relevant operational duties.

If we compare the KaaS and RaaS, we would find this relationship:

The Rollup SDK and Kubernetes Cluster share a commonality in that both are fully open-source and freely available for use. It is unlikely for them to charge fees at the SDK level. Initially, the Google team proposed Kubernetes as a free service, but later became the first to offer KaaS as a revenue-generating service.

While Kubernetes itself is open source and free, each organization that manages a Kubernetes cluster must handle the following responsibilities:

• Providing technical training to teams due to the steep learning curve associated with Kubernetes

• Managing and upgrading multiple versions of Kubernetes

• Handling the installation and upgrading of the Kubernetes system

• Deploying applications on the cluster

• Managing scalability and cluster configuration

• Ensuring that the cluster is configured securely to prevent unauthorized access or data breaches.

Furthermore, managing different clusters can be challenging, as it requires one person to handle various tasks across different clusters.

When enterprises consider a strategic implementation, their initial inclination is to manage it themselves. However, they may soon realize that managing multiple clusters while ensuring stability for each one can be difficult. Not only does it fail to provide them with a competitive advantage, but vendors are also likely to be more adept at managing it than they are.

Moreover, Kubernetes operates via pods, which contain all the necessary storage resources to support a container application or multiple containers, along with a unique network IP and operational settings. However, pods have a limited lifespan, which presents a unique challenge for DevOps teams utilizing Kubernetes. The critical question becomes how to maintain the stability of the essential "backend" pods to ensure that their corresponding "front end" pods continue to function correctly.

This is where KaaS enters the market.

Similarly, in the world of rollups, why do we require RaaS when there are valuable, freely available Rollup SDKs?

Take Celestia’s Rollkit as an example. To utilize a Rollup SDK and launch a new rollup, one must, at a minimum, complete the following steps:

• Node services

  Rollup is run by the nodes. Nowadays, it is quite typical to employ cloud services for node operation, except for running the rollup locally. Using cloud services for node operation can lead to fixed costs. In the KaaS domain, the provider that delivers the most effective node services (such as AWS, Google Cloud, etc.) becomes the KaaS service provider.

  Presently, RaaS teams such as Vistara Labs utilize cloud services to initiate Kubernetes clusters for their RaaS offerings. Ultimately, it will be the responsibility of network participants to ensure the dependable operation of nodes for modular rollups.

• Installation& Debugging

  Developers could encounter several problems or errors while starting rollups.

  For instance, when using Rollkit to launch a local rollup, resolving numerous errors and issues could consume roughly 80% of the time required for a vanilla rollup. This is because, even though the SDK offers an abstract way to operate a rollup, tasks like setting up the environment and dependencies, executing bash scripts, and interacting with the RPC API must be handled independently. This adds to the complexity of the process.

• Customization

  When developers intend to customize the network, they cannot merely use the templates provided in the repository. They must comprehend the underlying logic of the SDK, which may have a steep learning curve. Furthermore, each SDK has distinct logic and programming languages; for instance, Arbitrum Nitro utilizes Go and Rust, while Op Stack employs Go and Solidity.

  Regarding the VM aspect, forking existing projects is insufficient. Those who wish to incorporate a VM into an SDK must understand how each VM operates, extract the VM initialization and server codebase, and then wrap the VM into different interfaces provided by each SDK, such as the ABCI interface for Rollkit and the Engine API for Op Stack. Therefore, integrating various VMs with each SDK would entail a complicated combination problem (SDK ↔ VMs) that requires resources, time, and personnel. It is reasonable to expect an intermediary to handle this instead of requiring developers to do it themselves.

Even when comparing current L3 solutions provided by Optimism, StarkNet, and Arbitrum, certain features have to be chosen or designed by developers, which may not be immediately apparent.

• Sequencing scheme. The sequencing scheme would be tailored or adjusted to suit the needs of app-rollup developers. This may include FCFS, PGA, or more intricate schemes such as Narwhall & Bullshark or Hotstuff, which have been utilized by Sui and Aptos. One may opt for a third-party provider, such as a shared sequencer provider, to handle this, as it would still be challenging to manage independently.

• Trade-offs between finality and trustlessness. Both zk-rollups and optimistic rollups come with varying levels of finality. Generally, there are three types of finality: pre-confirmation, soft and hard finality. Soft finality depends on trusting both the L1 validators and L2 executors (e.g., challenger for optimistic rollups and prover/verifier for zk rollups), and the finality time is determined by the sequencer batching time and L1 finality time. In contrast, hard finality is achieved after the time window in which the rollup transaction was ultimately settled on the base layer for optimistic rollups, and it is only necessary to trust the L2 executors. For zk rollups, hard finality is attained when the proof is verified.

• Trade-offs between shared and self-run executors. The executor is responsible for executing transactions and updating the off-chain database, while the sequencer is responsible for ordering transactions and placing them into the underlying layer.

  There is room for flexibility in this role. A dedicated executor can offer better and more personalized performance, but this would require significant effort from the app-rollup developers as well as high hardware requirements. For instance, a gamefi that seeks better performance may prefer to have dedicated executors. Alternatively, one can choose to use the underlying layer's executor for convenience.

  Furthermore, having a shared executor set allows for atomic transactions that either execute entirely or do not execute at all, which can be a significant advantage.

• Trade-offs between decentralization and costs. Web2 game companies may not prioritize the decentralization of the rollup. The game studio itself is centralized, and they sign off on the data they wish to post into the chain, functioning as an oracle. Thus, they may not care about the decentralization of the da/sequencer. For their needs, a DAC or a centralized DA node would be more appropriate and much less expensive than the standard case.

Thus, an intermediary that can handle all these features and processes on behalf of the user is crucial, such as VMs wrapped into various SDKs, version control, multiple rollup types, and value-added features like MEV protection. Furthermore, developing a rollup involves various trade-offs. A solution provider like RaaS can assist in making better decisions regarding these trade-offs.

However, even in the KaaS world, 35% of developers opt to build their own Kubernetes in-house rather than using KaaS. This is primarily due to sensitive data security concerns or challenging on-premises dependencies, particularly for large and complex organizations like Amadeus and Bloomberg. The same may apply in the RaaS world, where developers may not choose to use RaaS due to privacy concerns.

Therefore, RaaS functions as an intermediary to handle tasks that developers may find difficult to accomplish on their own. However, the question is, who will emerge as the winner of RaaS? What features should be considered when compared to all the competitors?

Instead of a traditional subscription model, there are three potential ways to generate value:

• Subscribe to use. Users can create a new rollup by paying RaaS with its own token. This is considered the worst business model as it is likely to result in a price war and is not crypto-native.

• Validator Stakes tokens to earn transaction fees, MEV, and rewards. Validators, such as sequencers and executors of rollups, have to stake tokens to function. RaaS can receive a portion of L1-type fees (e.g., MEV, transaction fees, rewards) as revenue. This approach has been employed by Eigenlayer and Vistara Labs.

• Building a hub for all app-rollups. Developing a hub chain for its native token can help accrue value as it acts as a bridging, liquidity, and security center. This is a popular approach used by the RaaS ecosystem, which includes Optimism, Arbitrum, Polygon 2.0, Eclipse, and others.

In my view, staking tokens and building a hub are not mutually exclusive. Implementing both simultaneously can generate more value.

However, when an app-rollup experiences significant adoption, it may not be willing to share a portion of its value with the hub or validators. In such cases, launching their own chain to capture all the value, similar to what Dydx has done, is still a possibility.

Let's examine KaaS to identify the features that have the most significant impact on developers' willingness to use it.

The success of EKS is still reliant on Amazon Cloud services, as Amazon currently dominates the global cloud provider market. Thus, users of Amazon's cloud services may find it practical to opt for EKS as their KaaS service to receive optimal support for the Amazon architecture.

• EKS allows for a bring-your-own-OS option, enabling the use of virtually any operating system, while GKE has more restrictions in this regard.

  While EKS offers a high degree of flexibility when configuring your cluster, this also implies that developers must handle the burden of management. For instance, while EKS supports Calico CNI for network policies, users need to install and upgrade it manually.

• Google Kubernetes Engine was a better offering to begin with. It always had more features than any competitor in the market, including EKS.

  GKE undoubtedly remains the king of managed Kubernetes in terms of features, support, and ease of use. GKE is also the only service to provide a completely automated master and node upgrade process

In summary,

• EKS's extensive customer base is attributable to Amazon's cloud services, and it provides a greater degree of customization for the operating system and security. However, this results in a trade-off with convenience and automation.

• GKS provides the most features and supports lowering the barrier for developers to use. However, it compromises to some extent on the security and customization of the operating system.

Put this conclusion into the RaaS ecosystem.

• The most critical factor is the provider's ability to offer a diverse range of virtual machines (VMs). A greater variety of VMs is more important than other services. RaaS should prioritize its role as a VM-as-a-service provider before offering any additional features.

• Projects with well-established nodes and robust node management structures are viable candidates for RaaS. For example, Eigenlayer could potentially leverage its existing platform to develop another RaaS offering.

• Ensuring the security of the node/sequencer is paramount and cannot be compromised.

• Optimism

The OP stack is available for others to use without the restriction of being an L3 on Optimism. The revenue model for OP Stack is similar to that of Cosmos Hub, where the more L3 connections to Optimism, the more value can be captured by $OP. If op-stack-based rollups choose not to connect to Optimism, there will be no value captured by $OP.

For instance, OpBNB uses OP Stack to build but doesn't use Optimism's sequencer nor share a tx fee with the OP DAO/foundation. All the value will be captured by their own project. In contrast, the Base chain will give a portion of the transaction fee to OP to reward the common goods in the OP ecosystem, but it's not mandatory.

• Arbitrum

To fully leverage the value of $arb, it's essential to note that the Arbitrum Orbit license doesn't automatically include chains that settle to a non-Arbitrum-DAO-governed chain. Developers can only use Nitro to build L3 on top of Arbitrum's chains. If they want to build an L2 that settles directly to Ethereum, they must propose it and obtain the agreement of Artbitrum's DAO.

It's worth noting that Nitro is only used for EVM-compatible rollups. Those who want to try ZKVM, which is non-EVM-compatible, will need to use RaaS.

• Starknet

Starknet has proposed its roadmap for the multi-rollup universe. Although StarkEx is currently serving customers as an L2 solution, it will be ported to L3 to reduce the cost further.

In addition to the StarkEx future, there would be a place for the app-specific L3 built on top of the StarkNet. It can achieve a higher level of customization and sovereignty than the StarkEx services. The Stakrware team handles this function by building the Madara sequencer, which allows anyone to launch their own Starknet appchain. Users can utilize Cairo's capabilities while maintaining complete control over the custom app chain.

Madara is based on substrate and uses the Cairo VM to execute Cairo programs and Starknet smart contracts. With the help of Kakarot, users can build a zk-evm rollup. Ultimately, a prover or a prover market can listen to the blocks produced by the chain and generate proofs. Thus, a madara-chain can technically settle on any L1/L2.

• ZkSync

Zksync has recently launched a framework for constructing independent zero-knowledge chains. However, the ZK Stack isn't suitable for everyone. If creating a generic DeFi dapp or an NFT project, deploying it on an existing Hyperchain, such as zkSync Era, will be a more straightforward process.

ZK Stack focuses on the cross-chain communication process, implementing a shared prover to aggregate the proof of different Hyperchains. This allows for quick finality of cross-chain messaging. The more Hyperchain in the ecosystem, the less value would be captured by the ZkSync Era.

• Polygon 2.0

Polygon 2.0 aims to transition from the divergence phase to the convergence phase, where all Polygon chains will operate under the same architecture. This will include a staking layer for validators to stake Polygon's native token and provide services for the rollups. Additionally, there will be a unified interop layer to aggregate zk proof and facilitate cross-chain communications. As activity on Polygon's chains increases, the value of Polygon's native token will also increase.

Developing an application rollup entails encountering development friction and trade-offs. Therefore, an intermediary that can manage all these features and processes on behalf of the user is essential. This includes VMs wrapped into various SDKs, version control, multiple rollup types, and value-added features like MEV protection. Moreover, it's beneficial for this intermediary to assist in making better decisions concerning trade-offs while building application rollups. So far, RaaS is the one that can fulfill this role. When evaluating a good RaaS, the diversity of virtual machines (VMs) offered is more crucial than other services. RaaS should prioritize its role as a VM-as-a-service provider before offering any additional features.

Brought to you by @0xfan

• Several rollups are presently engaged in constructing their individual L2/L3 application ecosystem through the provision of diverse SDKs. Nevertheless, certain hindrances continue to limit widespread adoption. One possible explanation for this is the development friction associated with building application rollups.

• Building a rollup using an SDK typically involves several stages that can cause development friction. These stages include node services, installation and debugging, customization, smart contract development, and maintenance.

• Customizing a rollup, such as integrating a new VM, is a complex undertaking for the rollup development team. It requires a comprehensive understanding of the workings of each VM, extracting the code base, and adapting the VM into the various interfaces provided by each rollup SDK, such as the ABCI interface for Rollkit. Additionally, the most time-consuming aspect of developing a vanilla rollup typically involves resolving various errors and issues that arise during the process.

• Building a rollup also involves making several trade-offs, such as balancing trustlessness and efficiency. The finality of rollup transactions is classified into three levels, and the level of trust required increases as faster finality times are desired.

• In fact, the presence of an intermediary capable of mitigating development difficulties and facilitating flexible navigation between the associated trade-offs is indispensable for building the application rollups. This is when RaaS comes into the market.

• The implementation of a pay-to-use business model is not a requisite for RaaS to create revenue. A different strategy could include offering free access while generating income through the capture of MEV and potentially a share of transaction fees. Another viable option is to establish a central platform that streamlines bridging, liquidity, and security for all application rollups, consequently capturing their value.

• How can we identify a high-quality RaaS product? The most critical factor is the provider's ability to offer a diverse range of virtual machines (VMs). A greater variety of VMs is more important than other services. RaaS should prioritize its role as a VM-as-a-service provider before offering any additional features.

• In addition, projects with well-established nodes and robust node management structures are viable candidates for RaaS. For example, Eigenlayer could potentially leverage its existing platform to develop another RaaS offering.

With the advancements in modular rollups and their SDKs, numerous rollups have emerged with promising futures in this space. For instance, Optimism has introduced Op Stack, Zksync has open-sourced its Zk Stack, Arbitrum has Abirtrum Nitro, while Polygon has developed its rollup-centric 2.0 architecture. The availability of generic block space is no longer the primary constraint; instead, the focus has shifted to convenience and customization.

In the last article, we conducted a comparison of the existing Rollup-as-a-Service (RaaS) projects and their features. However, a pertinent question remains unanswered: In a multi-rollup ecosystem where each Layer 2 network has its own Layer 3 and SDK, why do developers prefer RaaS over building their own L3/rollup using mature SDKs?

To answer this question, we can initially look into the Web2 world and explore why a developer might opt for KaaS instead of running Kubernetes themselves.

Containers refer to a software technology that enables the virtual packaging and isolation of applications for deployment purposes. On the other hand, Kubernetes, also referred to as K8s, is an open-source system designed to automate the deployment, scaling, and management of containerized applications. By offering a platform to schedule and execute containers, it brings structure and organization to the process while also automating relevant operational duties.

If we compare the KaaS and RaaS, we would find this relationship:

The Rollup SDK and Kubernetes Cluster share a commonality in that both are fully open-source and freely available for use. It is unlikely for them to charge fees at the SDK level. Initially, the Google team proposed Kubernetes as a free service, but later became the first to offer KaaS as a revenue-generating service.

While Kubernetes itself is open source and free, each organization that manages a Kubernetes cluster must handle the following responsibilities:

• Providing technical training to teams due to the steep learning curve associated with Kubernetes

• Managing and upgrading multiple versions of Kubernetes

• Handling the installation and upgrading of the Kubernetes system

• Deploying applications on the cluster

• Managing scalability and cluster configuration

• Ensuring that the cluster is configured securely to prevent unauthorized access or data breaches.

Furthermore, managing different clusters can be challenging, as it requires one person to handle various tasks across different clusters.

When enterprises consider a strategic implementation, their initial inclination is to manage it themselves. However, they may soon realize that managing multiple clusters while ensuring stability for each one can be difficult. Not only does it fail to provide them with a competitive advantage, but vendors are also likely to be more adept at managing it than they are.

Moreover, Kubernetes operates via pods, which contain all the necessary storage resources to support a container application or multiple containers, along with a unique network IP and operational settings. However, pods have a limited lifespan, which presents a unique challenge for DevOps teams utilizing Kubernetes. The critical question becomes how to maintain the stability of the essential "backend" pods to ensure that their corresponding "front end" pods continue to function correctly.

This is where KaaS enters the market.

Similarly, in the world of rollups, why do we require RaaS when there are valuable, freely available Rollup SDKs?

Take Celestia’s Rollkit as an example. To utilize a Rollup SDK and launch a new rollup, one must, at a minimum, complete the following steps:

• Node services

  Rollup is run by the nodes. Nowadays, it is quite typical to employ cloud services for node operation, except for running the rollup locally. Using cloud services for node operation can lead to fixed costs. In the KaaS domain, the provider that delivers the most effective node services (such as AWS, Google Cloud, etc.) becomes the KaaS service provider.

  Presently, RaaS teams such as Vistara Labs utilize cloud services to initiate Kubernetes clusters for their RaaS offerings. Ultimately, it will be the responsibility of network participants to ensure the dependable operation of nodes for modular rollups.

• Installation& Debugging

  Developers could encounter several problems or errors while starting rollups.

  For instance, when using Rollkit to launch a local rollup, resolving numerous errors and issues could consume roughly 80% of the time required for a vanilla rollup. This is because, even though the SDK offers an abstract way to operate a rollup, tasks like setting up the environment and dependencies, executing bash scripts, and interacting with the RPC API must be handled independently. This adds to the complexity of the process.

• Customization

  When developers intend to customize the network, they cannot merely use the templates provided in the repository. They must comprehend the underlying logic of the SDK, which may have a steep learning curve. Furthermore, each SDK has distinct logic and programming languages; for instance, Arbitrum Nitro utilizes Go and Rust, while Op Stack employs Go and Solidity.

  Regarding the VM aspect, forking existing projects is insufficient. Those who wish to incorporate a VM into an SDK must understand how each VM operates, extract the VM initialization and server codebase, and then wrap the VM into different interfaces provided by each SDK, such as the ABCI interface for Rollkit and the Engine API for Op Stack. Therefore, integrating various VMs with each SDK would entail a complicated combination problem (SDK ↔ VMs) that requires resources, time, and personnel. It is reasonable to expect an intermediary to handle this instead of requiring developers to do it themselves.

Even when comparing current L3 solutions provided by Optimism, StarkNet, and Arbitrum, certain features have to be chosen or designed by developers, which may not be immediately apparent.

• Sequencing scheme. The sequencing scheme would be tailored or adjusted to suit the needs of app-rollup developers. This may include FCFS, PGA, or more intricate schemes such as Narwhall & Bullshark or Hotstuff, which have been utilized by Sui and Aptos. One may opt for a third-party provider, such as a shared sequencer provider, to handle this, as it would still be challenging to manage independently.

• Trade-offs between finality and trustlessness. Both zk-rollups and optimistic rollups come with varying levels of finality. Generally, there are three types of finality: pre-confirmation, soft and hard finality. Soft finality depends on trusting both the L1 validators and L2 executors (e.g., challenger for optimistic rollups and prover/verifier for zk rollups), and the finality time is determined by the sequencer batching time and L1 finality time. In contrast, hard finality is achieved after the time window in which the rollup transaction was ultimately settled on the base layer for optimistic rollups, and it is only necessary to trust the L2 executors. For zk rollups, hard finality is attained when the proof is verified.

• Trade-offs between shared and self-run executors. The executor is responsible for executing transactions and updating the off-chain database, while the sequencer is responsible for ordering transactions and placing them into the underlying layer.

  There is room for flexibility in this role. A dedicated executor can offer better and more personalized performance, but this would require significant effort from the app-rollup developers as well as high hardware requirements. For instance, a gamefi that seeks better performance may prefer to have dedicated executors. Alternatively, one can choose to use the underlying layer's executor for convenience.

  Furthermore, having a shared executor set allows for atomic transactions that either execute entirely or do not execute at all, which can be a significant advantage.

• Trade-offs between decentralization and costs. Web2 game companies may not prioritize the decentralization of the rollup. The game studio itself is centralized, and they sign off on the data they wish to post into the chain, functioning as an oracle. Thus, they may not care about the decentralization of the da/sequencer. For their needs, a DAC or a centralized DA node would be more appropriate and much less expensive than the standard case.

Thus, an intermediary that can handle all these features and processes on behalf of the user is crucial, such as VMs wrapped into various SDKs, version control, multiple rollup types, and value-added features like MEV protection. Furthermore, developing a rollup involves various trade-offs. A solution provider like RaaS can assist in making better decisions regarding these trade-offs.

However, even in the KaaS world, 35% of developers opt to build their own Kubernetes in-house rather than using KaaS. This is primarily due to sensitive data security concerns or challenging on-premises dependencies, particularly for large and complex organizations like Amadeus and Bloomberg. The same may apply in the RaaS world, where developers may not choose to use RaaS due to privacy concerns.

Therefore, RaaS functions as an intermediary to handle tasks that developers may find difficult to accomplish on their own. However, the question is, who will emerge as the winner of RaaS? What features should be considered when compared to all the competitors?

Instead of a traditional subscription model, there are three potential ways to generate value:

• Subscribe to use. Users can create a new rollup by paying RaaS with its own token. This is considered the worst business model as it is likely to result in a price war and is not crypto-native.

• Validator Stakes tokens to earn transaction fees, MEV, and rewards. Validators, such as sequencers and executors of rollups, have to stake tokens to function. RaaS can receive a portion of L1-type fees (e.g., MEV, transaction fees, rewards) as revenue. This approach has been employed by Eigenlayer and Vistara Labs.

• Building a hub for all app-rollups. Developing a hub chain for its native token can help accrue value as it acts as a bridging, liquidity, and security center. This is a popular approach used by the RaaS ecosystem, which includes Optimism, Arbitrum, Polygon 2.0, Eclipse, and others.

In my view, staking tokens and building a hub are not mutually exclusive. Implementing both simultaneously can generate more value.

However, when an app-rollup experiences significant adoption, it may not be willing to share a portion of its value with the hub or validators. In such cases, launching their own chain to capture all the value, similar to what Dydx has done, is still a possibility.

Let's examine KaaS to identify the features that have the most significant impact on developers' willingness to use it.

The success of EKS is still reliant on Amazon Cloud services, as Amazon currently dominates the global cloud provider market. Thus, users of Amazon's cloud services may find it practical to opt for EKS as their KaaS service to receive optimal support for the Amazon architecture.

• EKS allows for a bring-your-own-OS option, enabling the use of virtually any operating system, while GKE has more restrictions in this regard.

  While EKS offers a high degree of flexibility when configuring your cluster, this also implies that developers must handle the burden of management. For instance, while EKS supports Calico CNI for network policies, users need to install and upgrade it manually.

• Google Kubernetes Engine was a better offering to begin with. It always had more features than any competitor in the market, including EKS.

  GKE undoubtedly remains the king of managed Kubernetes in terms of features, support, and ease of use. GKE is also the only service to provide a completely automated master and node upgrade process

In summary,

• EKS's extensive customer base is attributable to Amazon's cloud services, and it provides a greater degree of customization for the operating system and security. However, this results in a trade-off with convenience and automation.

• GKS provides the most features and supports lowering the barrier for developers to use. However, it compromises to some extent on the security and customization of the operating system.

Put this conclusion into the RaaS ecosystem.

• The most critical factor is the provider's ability to offer a diverse range of virtual machines (VMs). A greater variety of VMs is more important than other services. RaaS should prioritize its role as a VM-as-a-service provider before offering any additional features.

• Projects with well-established nodes and robust node management structures are viable candidates for RaaS. For example, Eigenlayer could potentially leverage its existing platform to develop another RaaS offering.

• Ensuring the security of the node/sequencer is paramount and cannot be compromised.

• Optimism

The OP stack is available for others to use without the restriction of being an L3 on Optimism. The revenue model for OP Stack is similar to that of Cosmos Hub, where the more L3 connections to Optimism, the more value can be captured by $OP. If op-stack-based rollups choose not to connect to Optimism, there will be no value captured by $OP.

For instance, OpBNB uses OP Stack to build but doesn't use Optimism's sequencer nor share a tx fee with the OP DAO/foundation. All the value will be captured by their own project. In contrast, the Base chain will give a portion of the transaction fee to OP to reward the common goods in the OP ecosystem, but it's not mandatory.

• Arbitrum

To fully leverage the value of $arb, it's essential to note that the Arbitrum Orbit license doesn't automatically include chains that settle to a non-Arbitrum-DAO-governed chain. Developers can only use Nitro to build L3 on top of Arbitrum's chains. If they want to build an L2 that settles directly to Ethereum, they must propose it and obtain the agreement of Artbitrum's DAO.

It's worth noting that Nitro is only used for EVM-compatible rollups. Those who want to try ZKVM, which is non-EVM-compatible, will need to use RaaS.

• Starknet

Starknet has proposed its roadmap for the multi-rollup universe. Although StarkEx is currently serving customers as an L2 solution, it will be ported to L3 to reduce the cost further.

In addition to the StarkEx future, there would be a place for the app-specific L3 built on top of the StarkNet. It can achieve a higher level of customization and sovereignty than the StarkEx services. The Stakrware team handles this function by building the Madara sequencer, which allows anyone to launch their own Starknet appchain. Users can utilize Cairo's capabilities while maintaining complete control over the custom app chain.

Madara is based on substrate and uses the Cairo VM to execute Cairo programs and Starknet smart contracts. With the help of Kakarot, users can build a zk-evm rollup. Ultimately, a prover or a prover market can listen to the blocks produced by the chain and generate proofs. Thus, a madara-chain can technically settle on any L1/L2.

• ZkSync

Zksync has recently launched a framework for constructing independent zero-knowledge chains. However, the ZK Stack isn't suitable for everyone. If creating a generic DeFi dapp or an NFT project, deploying it on an existing Hyperchain, such as zkSync Era, will be a more straightforward process.

ZK Stack focuses on the cross-chain communication process, implementing a shared prover to aggregate the proof of different Hyperchains. This allows for quick finality of cross-chain messaging. The more Hyperchain in the ecosystem, the less value would be captured by the ZkSync Era.

• Polygon 2.0

Polygon 2.0 aims to transition from the divergence phase to the convergence phase, where all Polygon chains will operate under the same architecture. This will include a staking layer for validators to stake Polygon's native token and provide services for the rollups. Additionally, there will be a unified interop layer to aggregate zk proof and facilitate cross-chain communications. As activity on Polygon's chains increases, the value of Polygon's native token will also increase.

Developing an application rollup entails encountering development friction and trade-offs. Therefore, an intermediary that can manage all these features and processes on behalf of the user is essential. This includes VMs wrapped into various SDKs, version control, multiple rollup types, and value-added features like MEV protection. Moreover, it's beneficial for this intermediary to assist in making better decisions concerning trade-offs while building application rollups. So far, RaaS is the one that can fulfill this role. When evaluating a good RaaS, the diversity of virtual machines (VMs) offered is more crucial than other services. RaaS should prioritize its role as a VM-as-a-service provider before offering any additional features.