Using "vote()" on the Election.sol Celo Smart Contract

[douglasqian]

Context

Building a Celo staking dApp that interacts with Celo smart contracts directly. The rough steps for that are:

• lock() on LockedGold.sol
• vote() on Election.sol
• activate() on Election.sol (after pending epoch)

vote() has a very interesting function signature:

function vote(address group, uint256 value, address lesser, address greater) external returns (bool);

From digging around the code a little, it seems like lesser and greater are needed because the list of eligible validator groups is tracked on SortedLinkedList data structure. So essentially you need to find the 2 validator groups that the group you want to vote on is sandwiched between to correctly call this API (sorted by votes).

Problem

My strategy for getting proper values for lesser & greater is to query getTotalVotesForEligibleValidatorGroups which returns an array of eligible validator group addresses and the votes they have (both sorted by votes, descending).

What's interesting is that when I query this method, it doesn't seem to be returning the full set of validator groups. Specifically I'm looking for 0xEba452a3fACad973d03DAab5ca158C286c59A540 but am only getting 51 validator groups. When I run celocli validatorgroup:list I see 89 validator groups on Baklava.

To double-check, I also queried getGroupEligibility with this validator group address and it returns true. This conflict doesn't make sense to me. Then I thought it might be because of a pagination issue, but querying getTotalVotesForEligibleValidatorGroups on mainnet returned 79 validator groups so I ruled that out. The same problems exist on the getEligibleValidatorGroups method (only 51 returned).

Asks

Could use some help understanding how to get around this. If there is a better way to query the vote() without using getTotalVotesForEligibleValidatorGroups or getEligibleValidatorGroups I would also appreciate that.

Also made a post on the Celo Discord about this here:
https://discord.com/channels/600834479145353243/783326878806048819/984319483869020161

[gastonponti]

As you find out, the idea between the lesser and greater is to avoid that computation in the contract and basically make that call cheaper (gas/computation)

The validatorgroup:list shows every validatorgroup in existence, but the eligible, shows only the ones that have at least 1 validator.

For what I'm checking right now, this address 0xEba452a3fACad973d03DAab5ca158C286c59A540 is part of the response of the getTotalVotesForEligibleValidatorGroups call for baklava. Just a guess, but maybe when you queried that method, the group didn't have any validator.

Let me know if your issue persist.

For the way to calculate the lesser and greater, you can check what we are doing in the contractKit (also, if you are developing something in javascript/typescript I encourage you to use it):
https://github.com/celo-org/celo-monorepo/blob/b5be0334c8856ead47755f445dc582d8106baeef/packages/sdk/contractkit/src/wrappers/Election.ts#L426

[douglasqian]

Thanks for the reply @gastonponti

Just confirmed that 0xEba452a3fACad973d03DAab5ca158C286c59A540 is indeed in the response of getTotalVotesForEligibleValidatorGroups on Baklava. Not sure why this wasn't working before, but at least the 2 methods' return values make sense now.

Thanks for the help and the pointer to contractKit's implementation.

One last question out of curiosity -- would pagination ever become an issue on these API calls?