Keblobs

How would you describe kebabs? They’re composable. You can pick your meat and veggies, cook them the way you want, season them the way you want - just like how your devnet should be. Why do you need composable devnets? Because blobs are coming, among other things.

Innovations like Arbitrum stylus change the game for web3 developers. Yet even newer incoming innovations like proto-dank-sharding have ripple effects across our current favorite tools and projects. Being able to quickly against these changes, test them thoroughly, and stay ahead of these advancements is key.

Blobs are coming. Are you ready?

Current nitro devnets on Ethereum can already be spun up with one line through a complex docker compose and bash script implementation. However they are challenging to keep updated in a first class way, let alone account for incoming changes like blobs and customizations like changing contract size limits. Furthermore, current devnets only spin up one node using outdated images and flags, meaning developers aren’t able to build against true L1 behavior, leaving blindspots as Ethereum advances underneath.

The Arbitrum Stylus Package sets up a full Arbitrum Stylus development environment in a single command, over Docker or Kubernetes, and comes with a full Ethereum node with EIP4844 support out-of-the-box.

We are using an environment packaging and runtime tool called Kurtosis to define and run this composable Arbitrum devnet. In addition to helpful properties including parameterization and high readability due to a Pythonic syntax, our devnet inherits benefits from the ethereum-package and its sub-components, an environment definition currently used by the Ethereum Foundation, Flashbots, and many other client teams to test Dencun

Beyond blobs, reasons why Arbitrum Stylus Package slaps like a fresh old town kebab:

• Developers can test Arbitrum Stylus node compatibility with non-Prysm consensus implementations on L1 Ethereum
• Developers can test Arbitrum Stylus node at high scales and under adverse network conditions (important for BOLD)
• Core Arbitrum developers can build Arbitrum Stylus node behavior with various types of sequencer logic
• Application developers can validate and test precompiles and other NitroVM-modifying logic at their leisure
• With quick spin up and spin down, and parameterizable config with a simple YAML file, developers can enjoy quick iteration cycles

Blobs are only part of the story. The key is that our environment is easy to build on with low switching cost due to the high readability and walk up usability of Starlark, opposed to the relative monolith complex Docker Compose files and bash scripts are without a high degree of specific expertise. We want our environment to provide developers the freedom to customize and parameterize their environments to build what they want, how they want, to scale the future of Arbitrum and beyond.

The real blobs are the friends we made along the way.

The Arbitrum Stylus package uses a developer tool called Kurtosis to instantiate a full, bleeding edge Arbitrum Stylus development environment over Docker or Kubernetes with a single command. The environment that gets spun up will work over Docker or Kubernetes, is easier to maintain/read, and comes with a full Dencun-ready Ethereum node for EIP4844 blob testing.

The package is written using a Python dialect called Starlark which is an imperative scripting language that is well suited for handling sequential set up logic, dynamic dependency passing, and file generation & mounting required for spinning up complex systems like blockchains.

Specifically, the package gracefully handles:

• Configuring and starting up both the Ethereum Execution Layer (EL) and Ethereum Consensus Layer (CL) client configurations - we support all major EL and CL client pairs, including Reth!
• Generating Ethereum validator keys and Ethereum genesis data for the L1
• Funding the Arbitrum sequencer and validator
• Spamming the Ethereum network with transactions
• Writing the L2 configuration files
• Deploying both the Arbitrum sequencer and batch poster as containers/pods over Docker/Kubernetes
• Deploying a Redis instance
• Deploying the token bridge
• Deploying the Arbitrum Stylus Node

Under the hood, the Kurtosis package uses:

• Docker or Kubernetes
• Kurtosis
• Starlark

To demonstrate the capabilities of this package, we used the Cargo Stylus CLI to deploy a Rust smart contract onto the Arbitrum node. Our sample smart contract uses the Ink! smart contract library for the Substrate blockchain framework. The contract represents a staking system with rewards. Key functionalities include:

• Constructor: Initializes the contract with rewards and staking token addresses, setting default values.
• View Functions: Calculate reward per token, earned rewards, and retrieve staked balances.
• State-Modifying Functions: Allow staking, withdrawal, and claiming rewards, updating balances and emitting events.
• OpenZeppelin Contracts: Utilizes ERC20 token traits for token interactions.

In summary, the contract facilitates staking, rewards accumulation, and withdrawal, all while integrating with ERC20 tokens.