Discussion: Juno's Role in Providing DevNet and Rollup-as-a-Service (RaaS) in the StarkNet Ecosystem

[rianhughes]

Description: This issue tracks ongoing discussions regarding Juno's role in delivering both DevNet and Rollup-as-a-Service (RaaS) within the StarkNet ecosystem.

Currently, Juno primarily focuses on syncing, storing, and serving StarkNet data in accordance with the RPC specification. However, there are additional features such as P2P networking, Consensus, and Sequencing that are actively being developed, none of which are production ready yet.

DevNet vs. RaaS

It may be useful to distinguish between the two concepts:

• DevNet: The primary aim of the DevNet is to provide a lightweight and fast environment for contract developers to deploy, test, and iterate on their smart contracts. Since the focus is on testing and development smart contracts, it bypasses many of the complexities of a production network, such as syncing, consensus, and P2P. However, it does require additional features we don't currently support (see below). At its core, this is a centralised Juno sequencer + some nice smart contract testing features.

• RaaS: Building an entire rollup from a Juno node is significantly more complex. Key decisions must be made regarding the settlement layer—for instance, whether to settle on Ethereum or Starknet. This choice impacts the core contracts that the rollup will use: for example, can we fork Starknet’s core contracts on Ethereum, or if we settle on Starknet, will we need to develop new ones? Additionally, it’s important to determine whether the network will be centralized or decentralized. If decentralization is required, this will necessitate implementing consensus and P2P features. Since Starknet is a ZK-rollup, we’ll likely need to generate cryptographic proofs (e.g., using SHARP). Beyond these, other components like block explorers, wallets, and developer tools will also be essential for a fully functional RaaS platform.

Components for a StarkNet-like RaaS Platform

• Settlement Layer:
  We need to decide which blockchain we will settle on (e.g., Ethereum, directly on StarkNet, or another chain).
  This decision will impact security, finality, and reorg resistance of the rollup.

• Core Contracts:
  Depending on the chosen settlement layer, we need to develop, deploy, and test core contracts that can validate ZK proofs and store state updates.
  These contracts form the foundation for securing the rollup.

• Sequencer:
  A sequencer is required to receive transactions, execute them, and build blocks.
  Juno currently supports sequencing but is not yet production-ready.

• Data Availability:
  We need nodes that can serve the rollup’s state and ensure data availability.
  Currently, Juno’s primary functionality is providing data availability for StarkNet, which can be extended to the rollup.

• Prover:
  To ensure the cryptographic security of the rollup, we need to generate proofs (and the necessary prover inputs) for the rollup state diffs. Juno could integrate with SNOS (once it's released) to generate these prover inputs, which could then be passed to a system like SHARP to produce the actual proofs. This process will also impact the design and development of the core contracts, as they will need to be capable of verifying these proofs on the settlement laye

• Consensus & P2P:
  If the rollup is centralized, we can forgo P2P and consensus features.
  If we aim for decentralization, Juno will need robust P2P and consensus features, which are still in active development.

• Other Tools:
  We will likely leverage existing tools from the StarkNet ecosystem where applicable, including block explorers, wallets, and developer tools.

Components for a Juno based Starknet devnet

Running the make sequencer-with-accounts command on this branch boots up the Juno sequencer with a fee token contract and pre-funded accounts, forming the core of a DevNet. However, it is not yet production-ready and lacks key DevNet features that developers typically expect:

• Forking Capabilities: Ability to fork mainnet or testnet to simulate real-world interactions and test with live blockchain data.
• Debugging and Tracing Tools: Transaction tracing, call logs, enhanced error reporting, and gas usage analysis for more efficient debugging.
• In-Memory Blockchain Storage: Fast in-memory blockchain for testing instead of slower disk-based storage.
• State Reset and Snapshotting: Ability to reset or snapshot the blockchain state for quick re-testing scenarios without restarting the entire network.
• Contract Deployment to Testnet/Mainnet: Easy deployment workflows for testnet and mainnet, bridging the gap from local development to production.
• Developer Documentation: Clear, comprehensive guides for setting up the DevNet, deploying contracts, running tests, and debugging.
• Preloaded Test Accounts: Automatically configured accounts with preloaded funds for easier contract interaction during testing.

Other things to consider:

• Execution dependencies: StarkNet, and by extension Juno, relies on Blockifier to execute transactions. Blockifier is regularly updated, and these updates can include breaking changes. This introduces a dependency on keeping the DevNet (and Raas) in sync with the latest Blockifier versions to ensure compatibility with Starknet. It may be necessary to manage versioning carefully and provide documentation or tooling that helps developers deal with changes or upgrade paths when new Blockifier versions are released.

• Consensus and P2P dependencies: Consensus mechanisms and P2P networking are very much under active development. These features will likely have a significant impact on the Rollup-as-a-Service (RaaS) offering, assuming we want a decentralised rollup.