Build a tool (or extend agora-cli) to simulate activity on an Agora network

[AndrejMitrovic]

We want to start testing Agora in an environment which simulates a real-world network. You may think of this as TestNet, however this system of nodes does not need to be public - therefore it does not need to be TestNet. It could be any network with a custom-defined genesis block. For example, it could be a network of Agora nodes running only on the developer's computer for just a short period of time. Or it could run on a dedicated cloud service that only we have access to.

Exactly where the network is running is not important for this issue.

Currently, we have support for:

• Starting a new Agora node (docker)
• Creating transactions and sending them to an Agora node (agora-cli Build a command line tool to send transactions #206)

In order to fully simulate a network we also need some additional features:

• An ability to continuously generate new valid transactions and send these to one (or more) Agora nodes
• An ability to purposefully DDoS an Agora node with well-formed API requests. These requests contain parameters which are valid (e.g. valid transactions)
• An ability to purposefully DDoS an Agora node with malformed API requests. This will require the use of randomness. For example, the tool could try to flip random bits or send garbage data to an API end-point. The tool could also try to call into end-points which don't exist. An Agora node should handle all these cases properly.

It may be possible to extend agora-cli for this purpose, or it may be necessary to build a new tool.

The objective of this tool is to:

• Find any hidden bugs that could cause an Agora node to become faulty. It's important to catch as many as these bugs before CoinNet is deployed.
• Find performance bottlenecks, and thereafter optimize Agora.

As a developer your goal is to:

• Find a good set of features that this tool should support, and the use-cases for such a feature. Some of them are listed above.
• Implement those features. If the scope of implementing the features is too large, feel free to break this down into several smaller issues.

@kchulj would you consider this to be an interesting feature to work on?

@Geod24 please share any ideas about the features we may need, or if the scope of the requirements should be re-adjusted.

[Geod24]

There was #1234 merged and worked on this sprint.
Currently the feature set is quite limited, and it is not deployed. Also, the current design (a CLI tool) makes it hard to work with, as such a tool needs knowledge of the UTXO. This is an issue @kchulj is aware of (we discussed it) and I believe he's working on it, however I don't think we can consider this closed.

[Geod24]

The basic work is done. The rest should be split into smaller issues in bpfkorea/faucet.