The code in this repository aims at filling two objectives:
- real-world traffic simulation on a blockchain - obviously, in a simplified way
- comprehensive testing of all available features and functionalities - kinda E2E-tests on steroids
Apart from Rust version specified in rust-toolchain
you do not need anything more installed.
To run the default scenario suite, you need a running chain with some node accessible via ws port.
By default, bots will try communicating with 127.0.0.1:9944
.
In order to change that, see the Adjusting configuration section.
For most actions, bots will need some tokens to pay fees. To set up test accounts with funds run:
$ make setup
Afterwards, to start the test worker run:
$ make run
If you prefer running bots in a docker container, you can call:
$ make setup
$ make docker
This will launch docker-compose
accoring to docker/docker-compose.yml
.
If your chain is running on localhost
, you will have to exchange line node = "127.0.0.1:9944"
with node = "host.docker.internal:9944"
in Timetable.toml
.
Note: To enable backend to communicate with local chain from docker you will need to run node with --unsafe-rpc-external
and --unsafe-ws-external
flags.
In addition, monitoring service will be served at localhost:8080
.
The main file is Timetable.toml
. There you can specify:
node
(by default127.0.0.1:9944
): it is the web socket address to which bots will connectexpose_host
(by default0.0.0.0:8080
): address where statistics are published- which bots to launch and their parameters
Statistics are exposed at two endpoints under the expose_host
address.
Main data is served at /details
(brief information about every launched scenario) and logs from particular scenarios are displayed at /logs/<scenario identifier>
.
Each scenario configuration contains three obligatory fields:
kind
- this specifies which scenario to runident
- a unique identifier of this particular bot (you can launch multiple bots of the samekind
, but they have to be distinguishable byident
)interval
- (human-readable) amount of time that should pass between finishing a run and the subsequent launch
Apart from that, most scenarios have some parameters (like strategy or scale) which you can tweak.
You can configure the initial endowments in set_up/Config.toml
.
For details check set_up/README.md
.
Accounts are given by their seeds.
Note: In a production environment you usually do not want your bots to be exposed to access from anyone.
Therefore, before launching make setup
and make run
(make run-docker
), you can set an environment variable SECRET_PHRASE_SEED
.
Be aware that this is a compile-time variable, which means that changing it requires recompilation.
You can use the provided GUI to browse the statistics by running:
$ make monitoring
This will start a trunk
server with the GUI and open a new browser tab to take you there.
By default, it will be launched at 127.0.0.1:8040
.
To change its configuration, check monitoring/Trunk.toml
.
For more details consult monitoring/README.md
.
common
(lib crate): contains the heart of this repo, i.e. theScenario
trait together with some useful utilities around itchain-support
(lib crate): is a library providing functionality for chain interaction, useful in scenario development; serves as a wrapper aroundaleph-client
andsubstrate-api-client
traffic
(lib crate): is responsible for scheduling and launching scenariosscenarios
(collection of lib crates): gathers independent crates, each focusing on testing a different aspect; something likeframe
directory for pallets crates in the Substrate repositorybin
(binary crate): serves for launching the application from command line and providing environment configuration; additionally starts a web server exposing statisticsmonitoring
(bin crate): (web) frontend part of applicationset_up
(bin crate): is responsible for endowing bot accounts
Just run:
# for backend image (it will be tagged `traffic-maker`)
$ make build-backend-docker
# or for frontend image (it will be tagged `traffic-maker-monitoring`)
$ make build-frontend-docker
In order to implement a new scenario, follow these steps:
- If its scope fits into any existing subdirectories (crates) in
scenarios
, add a new module there (and register it in a correspondinglib.rs
) Otherwise, you will need to create a new crate. It will need to be registered in the default workspace (Cargo.toml
). Also, you will have to add it as a dependency tobin/Cargo.toml
- Write your scenario by implementing
Scenario
from thecommon
crate. Instantiating an object of your class should be done in an analogous way to other scenarios (through a mirror data structure, see e.g.scenarios/transfer/src/simple_transfer.rs
). - Enable creating your scenario from a configuration file.
For this, extend
enum ScenarioConfig
inbin/src/config.rs
and a corresponding method there (construct_scenario
). You should just follow the existing code and prepare very similar handling. - If you need some accounts to have an initial balance, see the Account endowments section.
After your PR is merged into main, a new docker image (containing only backend part) will be built and pushed to a private registry (AWS ECR). To launch it on a server (we have a dedicated EC2 instance for that), you will need to ssh there and run the new image manually. For details contact @pmikolajczyk41 or @skrolikowski-10c.