The first task will be agreeing on a high level architecture that can be subdivided between implementors. The use cases for the software should be determined, and sub-tasks created to address them.
This work should include defining interfaces between high-level components, and possibly a stub implementation of each.
The first step of this task is to design an architecture, and create sub-tasks to track the implementation.
The simulation needs to be driven by some outside input provided by the user or client program. The specifics of the API are fairly open. Some possible avenues could include HTTP, grpc, or whatever else suits the data and use case.
The API provided by the simulation itself doesn't necessarily have to conform to the input to the client tooling.
Important features of the API include the synthesis and inspection of chain state.
The first step of this task is to design an architecture, and create sub-tasks to track the implementation.
The simulation needs to create some subset of the complete ETH2 block chain. From my understanding, blocks for the beacon chain and at least one shard are required for the simulation to be useful.
The creation of blocks should be controlled by the API. The design should consider future feature requirements like specifying forks, adding invalid blocks or transactions, delayed attestations, persisting to disk, etc.
The first step of this task is to design an architecture, and create sub-tasks to track the implementation.
Block producers need to execute Wasm modules to produce blocks. Grabbing and using an existing Wasm runtime would make this task easier. Matt's ewasm-rt might be a good starting point.