Another chef will be joining the Stake Off! Please meet… the Baklava Voting Bot!
With increasing engagement in TGCSO, there are more participants interested in running validators than can be elected at any one time. This can hinder newcomers from being elected, with undue advantages for early participants, even those with poor performance.
The Voting Bot will give new validators a chance to replace validators with low scores and votes, allowing them to compete to stay in the elected validator set by achieving a high validator score and voting with their rewards.
The test of the Baklava Voting Bot will be rolled out in iterative stages. The first stage, Minimal Impact, slated to launch Feb 5, 2020 at 14:30 UTC, is intended to have little effect on elections. The rest of the stages are scheduled to be deployed across Phase 3. Details on its role and deployment stages are written below.
How does the bot work?
Voting bot controls a number of accounts, each with locked gold.
Once per hour (roughly once per epoch on Baklava), some of those accounts become active and participate in the epoch’s election.
If a bot account has a current vote for a group, it will decide whether or not to keep that vote. This decision is influenced by the score of that group, with higher scores making it more likely that a vote will be kept.
If a bot account has decided to change its vote, or if it is voting for the first time, it chooses a strategy for picking a new group:
Note: C Labs Validator Groups are excluded from the bot’s voting
Random, among validator groups who are not currently elected
Weighted-random, among currently elected validator groups, being more likely to choose a high-scoring group over a lower one
Number of bot accounts
How many simulated voters are participating in elections? This controls how many individual vote choices can happen.
Amount of gold for each account
How much impact does each bot-voter have in elections? Higher amount = larger impact, Low amount = lower impact.
Each time the process runs, what’s the likelihood that each bot will participate? This parameter simulates voter-engagement, assuming that not every voter will participate in every election. In our case, not participating in an election means keeping the last vote made as-is. This parameter allows us to tune “churn” of votes, allowing votes to have more or less volatility in relation to the current performance.
This parameter controls the bias for highly-scoring groups. It comes into play in the choice to keep or change a vote, and when choosing among currently-elected groups based on score.
- If between 0 and 1: Flattens the relative weight of scores for anything other than the very low, near-0 end. A group scoring 0.8 is less than twice as likely to get/keep a vote than a group scoring 0.4, even though it has double the score.
- If equal to 1: Linear relationship. A group scoring 0.8 is twice as likely to get/keep a vote than a group scoring 0.4
- If greater than 1: Heavy bias for highly-scoring groups, with a steep drop-off just under the highest scores. For example, a group scoring 0.9 would be significantly over one scoring 0.8
How likely is a bot to choose a random unelected group vs choose among the incumbents?
- If it’s set to 0, the bot will always choose among the currently elected groups and aim for a high-scoring one.
- If it’s set to 0.5, the bot will choose among currently elected groups half of the time, and among not-elected groups the other half of the time.
- If it’s set to 1, the bot will always choose randomly among groups that are not currently elected.
- Change baseline
Regardless of any other factors, how likely is a bot to change its vote? In other words, this can help break the incumbency bias by making it possible for a group with a perfect score to lose votes.
- If 0: Choice to keep a vote is entirely based on score and score sensitivity
- If 1: Bots will always change their vote each time it wakes up
How frequently does the process run?
Since the bot has an impact on the outcome of TGCSO, the deployment will roll out carefully and fairly, to gain confidence that the bot is supporting the intent to give newcomers a chance at being elected over low-performing incumbents.
Stage 1: Minimal Impact
The bot will be deployed with 500 accounts, with 1 cGLD each. With this amount of gold, even in the case of a statistical anomaly where they all vote for the same group, it is not enough to have an effect on elections. This will test if the other parameters are set correctly to achieve the objectives of the bot.
The process will be run once with these parameters to seed all bot accounts with a vote for an incumbent:
- Participation probability: 1 (all accounts participate)
- Exploration probability: 0 (choose among currently-elected)
- Score sensitivity: 1 (linear relationship between score and vote-choice)
- Change baseline: 0 (on the first run, this has no impact, since there’s no votes to change)
Then, it will be deployed with these parameters:
- Schedule: Once per hour (roughly equivalent to once per epoch)
- Participation probability: 0.3 (30% of bot accounts participate each epoch)
- Exploration probability: 0.6 (Favor choosing newcomers, while also helping to bolster high-performing incumbents)
- Score sensitivity: 1 (linear relationship between score and vote choice)
- Change baseline: 0 (starting without amplifying churn)
Stage 2: Observation
After the initial deployment, the team will watch the voting behavior to determine if the parameters are having the intended effect.
Stage 3: Deploy with Impact
Based on the outcome of the observation stage, parameters will be tuned, and the bot will be redeployed with a larger amount of gold per account, translating into real impact on who gets elected.
The Baklava Voting Bot will provide further insight into how a validator group can improve their chances of staying or getting elected. The team working on TGCSO will communicate details about the bot as it is rolled out and share learnings.
As always, feedback and suggestions are appreciated - on the Forum or Discord.