Mousse: An Ethereum 2.0 Emulator for Local Testing of Eth2 Applications
TL;DR
- Mousse is a local testing tool that supports the development of Ethereum 2.0 applications, especially Rollups, similar to Ganache to the current Ethereum.
- Mousse provides the HTTP server to interact with the Eth2 world and the dashboard to visualize Eth2’s blocks and states and manipulate the emulator.
- Internally, Mousse simulates the beacon block production, consensus progress, and data market in shards, including the system’s various failure scenarios.
Mousse Overview
Ethereum 2.0 (Eth2) is a major upgrade to improve the scalability and security of Ethereum. The beacon chain was successfully launched last December. The beacon chain is the core system of Eth2, and various Eth2 applications will not actually be deployed until the launch of data sharding. Data sharding introduces 64 shards that can store arbitrary data. Its primary use is to store transaction data of Rollups, layer 2 scaling solutions. It is expected that the combination of data sharding and Rollups will greatly improve the scalability of Ethereum.
(For some educational resources on Eth2 data sharding, please refer to the contents of the Eth2 online workshop in Feb 2021)
The specification of data sharding is currently being discussed. Soon, it will be urgent to develop Rollups to support data sharding. However, at this time, there is no tool for local testing of Eth2 applications such as Rollups. In the current Ethereum community, Ganache and other local testing tools are commonly used.
Therefore, we started developing Mousse, a “Ganache for Eth2 data sharding.” The name is taken from a chocolate sweet, following Ganache. Mousse is an Eth2 emulator to support the development of Eth2 applications.
Mousse consists of the following three components:
- Simulator of Eth2 data sharding
- HTTP Server that mimics APIs of P2P clients for Eth2 data sharding
- Dashboard for visualizing blocks and states and manipulating the emulator
The current design of Mousse assumes data sharding before Eth1 and Eth2 are merged. The simulator is based on the data sharding spec in the two pull requests (#2146 and #2172) in the Eth2 spec repository. In Mousse, validators, P2P networks, the consensus algorithm (Casper FFG, LMD GHOST, attestations, etc.), and data availability mechanisms are abstracted away.
Eth2 application developers can run various testing cases in Eth2 by replacing the communication with Eth2’s P2P clients with Mousse’s HTTP server. Mousse can emulate various failure scenarios in Eth2; for example, no beacon block is proposed for a certain period, or no data is included in shards, etc.
Mousse is not only useful for Eth2 application development but also for educational purposes. The visualization and the interaction with Mousse’s dashboard will help developers to understand how data sharding works.
Key Features
Let us introduce the key features of Mousse.
Bidding
In data sharding, users are assumed to publish “bids” to request validators to put their data on shards. Each bid specifies “fee.” A shard validator is supposed to pick up the bid with the highest fee at each slot in the shard and proposes the data requested by the bid as “shard blob,” which is stored in the shard. Before the merge with Eth1, users pay the fee to validators via Eth1 contracts. (See this post about the details of the “fee market manager contract” in Eth1.)
In Mousse, you can publish a bid by filling the following fields:
- Shard: The shard in which you want to put data
- Slot: The slot at which you want to put the data on the shard
- Fee: The fee paid for the data
- Data file (e.g., a picture of your pet!)
Note that there are no “ether” or validators’ balances in Mousse, and the fee payment mechanism is omitted.
Failure Scenarios
As shown in the figure below, you can make the emulator proceed to a specified slot by choosing from the normal case or various failure cases.
The scenarios in a slot that Mousse currently supports are:
- Nothing fails. (Happy case.)
- No data is included in the shard blob.
- No shard blob is proposed.
- No shard header is included.
- Shard header confirmation is delayed.
- Beacon chain finality is delayed.
- No beacon block is proposed.
Also, if you select “random,” the emulator randomly picks one from the above.
Automatic Processing
Mousse can also proceed with slots automatically. You can set the interval at which the slot proceeds and the probability that a failure occurs. In case of failures, one type of failure is randomly selected from the above.
Getting Beacon Blocks
You can get a list of beacon blocks and check if a bid has been included in the block or not.
In each shard, a “shard header” with the cryptographic commitment to the data proposed as a shard blob is published and included in the slot’s beacon block. (The commitment scheme used here is called KZG commitment. However, in the current implementation of Mousse, the commitment is replaced with a dummy value, i.e., the hash).
Getting Beacon States
You can also get a list of beacon states.
The shard header included in a beacon block is stored as “pending” in the beacon state.
In the actual protocol, the shard committee (i.e., the validators allocated to that shard) verifies that the data referenced by a shard header is available and publishes attestations. If a sufficient number of attestations to the shard header is collected, the header becomes “confirmed” in the beacon state. In Mousse, these mechanism is abstracted away, i.e., a header is immediately marked as confirmed, or the confirmation is delayed in failure scenarios.
Getting Started
Please visit Mousse GitHub!
What’s Next?
Mousse is still under development.
First of all, cryptographic primitives are not implemented correctly for now. KZG commitment of shard data and BLS signature of shard header are replaced by dummy values (hash of the target value).
Also, the REST API needs to be more sophisticated. The current API is much simplified compared to the current Eth2 Beacon Node API. The blocks and states returned by the API are only in JSON format, and SSZ (the canonical serialization format in Eth2) is not supported. Thus, it is impossible to test the validation of Eth2 data (such as Rollup transaction data) in Eth1 contracts.
Furthermore, the current Mousse is designed for data sharding before Eth1 and Eth2 are merged, but in the future, it would be better to emulate the post-merge data sharding (i.e., implementing the “executable beacon chain”).
If you would like to get updates on Mousse, join our Discord! Feedback, questions, and participation in development are welcome. Mousse is currently being developed by Naoya Okanami and Ryuya Nakamura.
