Simulator revamp

[sydhds]

Intro

In order to better test our PR, we need drastic changes in the massa-network-simulator

Modifications (Docker)

• Use Docker-compose and have ready to use 2/4/6 nodes running
• Document each of these configurations:
  • open ports / open bash shell / basic api check with curl

Question: more nodes? 8?, other special configurations (perf monitoring)?

Modifications (Docker api)

• By using docker-compose, we should not need this api anymore.

Question: should we need dynamic configuration or scenario, we could improve it with Docstrings, no hard-coding, typing...

Python API (to deal with Public & Private API)

Add a generic and easy to use Python API to interact with Public & Private API. We have a basic skeleton in test_scripts/test.py
, but it has to be improved a lot

Python API 2 (High level functions to interact with a node)

Add an API to:

• Create tx
• Send an operation
• ...

Some functions could be extracted from charge.py.

Functional tests

By leveraging our python API, we should implement functional tests that the end user (a developer) will run.

This functional tests should be implemented using a python test framework (unittest (in std) or pytest).
Note that these tests, should run whatever the scenario is (2, 4, 6 nodes...)

Minimum required unit tests:

• Buying roll
• Send one transaction
  • Checks: endorsements creators, Ledger balances, Check for bans if any, waiting for the block to become final, check signatures
• Selling roll

Nice to have:

• Run some smart contract
• Basic stress testing nodes
  • Invalid transactions (Refer an unknown block, too much in the future)
  • Invalid endorsement
  • ...

Other ideas:

• Stress testing the node with lots of transaction

[AurelienFT]

The usage of docker compose as you mentioned above hard code the number of nodes ? Currently with the JSON we are more modular on this point.
I agree on the python API SDK.
Yes automated testing with the simulator is a good next steps. We could go even further with the debug that has been added recently to diagnostic protocol and network usage. We could hide this print behind a rust feature and activate it when running simulator so that we have even more data.

[sydhds]

Yes using docker compose would hard code the number of nodes but I think will be way more explicit than a script (everything remains in docker-compose.yml or Dockerfile).
But at the end, we could keep the main.py for advanced / specific testing.

[AurelienFT]

I don't find it more explicit people are more familiar with JSON than docker-compose files and if the simulator is well done and well abstracted the people need to just edit the config file and I think the JSON format for a config file is better. I think we should add the commit etc on this JSON so that we don't specifically code it for docker but we could replace by/add AWS for example in the future and still have the same config file with a field "provider"

[sydhds]

Docker compose file are just yaml files (and yml support comments) and the format is nicely documented (https://docs.docker.com/compose/compose-file/compose-file-v3/).

From what I see, there are a lots of advantages using docker compose like:

• explicit networking config, ulimits && sysctl
• comments

And docker compose is well supported by a lot of cloud providers like:

• https://aws.amazon.com/fr/blogs/containers/deploy-applications-on-amazon-ecs-using-docker-compose/
• https://learn.microsoft.com/fr-fr/azure/container-instances/tutorial-docker-compose

[AurelienFT]

Yes they are well supported but to run docker on this cloud providers. I was thinking on a format that is agnostic of docker or things like that.

[sydhds]

Oh I see! Nice idea :). Any idea of another 'provider' that you'd like?