Voting bot for stake off

[timmoreton]

Expected Behavior

We would like a number of instances of a voting bot to run in a testnet. For simplicity, we could extend the load testing client to do this for us (see celo-monorepo/packages/celotool/src/cmds/geth/simulate_client.ts )

• lock up gold initially (maybe in the migrations?)
• wake up at a random interval
• with a given probability, do nothing, otherwise evaluate whether to change vote
• implement a strategy that picks the group that can receive votes AND has highest recent rewards
• add some degree of randomness to it: with certain probability pick a random group

@rcroessmann and @asaj will have ideas based on their recent simulation.

Current Behavior

Rely on external users to vote.

[yerdua]

The load test client appears to be a thing that we run on-demand, and this sounds like something we want running continuously for the duration of the stake off. That difference makes me think they shouldn't be combined, and the voting bot should be a standalone thing.

Especially if we want gold to be locked up in migrations, the account(s) used by the voting bot will need to be funded in the genesis block. How much gold is an appropriate amount?

Roughly how many bots do we want running?

cc: @asaj @rcroessmann

[timmoreton]

The load test clients are already funded in genesis -- see https://github.com/celo-org/celo-monorepo/blob/baklava-dec-2-2019/packages/celotool/src/lib/generate_utils.ts#L161

[timmoreton]

They get a configurable amount of CG each, currently 1000 CG.

[timmoreton]

I think we run the load test continuously to generate constant background tx load @tkporter ? feels like the simplest place to add support for voting as it already has funds and the infra is already in place.

[tkporter]

The way load test clients work is each pod is constantly running with 1 container running an ultralight client with an unlocked account and 1 container running celotooljs geth simulate-client ..... that creates transactions every few seconds. We could maybe add another container to the pod that runs a separate celotool command that votes every once in a while (we could even make this conditional using a helm template).

Just to verify, the nonce should be set by the ultralight client & not contractkit, so we shouldn't run into conflicting nonce issues by having 2 separate containers send a transaction simultaneously, right?

[yerdua]

Oh cool! Thanks for the info. If the plan is to have these load test clients running for the duration of the stake off, it seems fine to have them do the voting.