Add more getters to staking providers smart contracts for testing purposes

[itaven]

Suggestions:

1) Implement getSigningKeys() function which will return an array of signing keys that were added for current sp.
Current solution: right now we can only getSigningKey(sp_id,SigningKey_index)
Reason: for testing purposes where we will test the whole system with a big number of signing keys. We must check the correctness of added signing keys with the source. We can't expect how the system will react to it and also it's not too flexible to call getSigningKey(sp_index,signingKey_index) 200 times for example.
2) Implement getActiveSigningKeys() function which will return an array of active signing keys that became active after validators started.
Current solution: right now we can only check that added signing keys are started validation by check sp1.getUsedSigningKeys().
Reasons: To match used signing keys with active validators pubKeys in the eth2 side. We can clearly check sp1.usedSigningKeys() count,but can`t correctly compare usedSigningKeys active validators pubKeys in eth2.

In conclusion, I might admit that in bundle sp signing keys -> to eth2 we can`t track correctly this action.

[vshvsh]

Why 1) can't be implemented on js side as a helper function that calls getSigningKey 200 times for the purpose of testing?

[vshvsh]

What do you mean by "active" in 2)? "Actively validating on eth2 side"? If so, smart contracts have no idea what happens on eth2 side except very limited information delivered by the oracles.

[itaven]

Why 1) can't be implemented on js side as a helper function that calls getSigningKey 200 times for the purpose of testing?

Yes, we do.But it is not too flex solution and can be and can take a long time.

[itaven]

What do you mean by "active" in 2)? "Actively validating on eth2 side"? If so, smart contracts have no idea what happens on eth2 side except very limited information delivered by the oracles.

Yes, but if signing keys of sp became actively validating on the eth2 side,we can only compare it with added signing keys from the array which was added to addSigningKeys().

const sp1SigningKeys = getGeneratedSigningKeys(10)
sp1.addSigningKeys(10,sp1.SigningKeys().pubKey,sp1.SigningKeys.signature)
send 320 ETH
wait for validation start
// We can`t operatie with sp1 object to call activeKeys
t.is(eth2.getActivePubKeys(),sp1SigningKeys.pubKey)

[skozin]

Adding code to a smart contract solely for testing purposes is not a good idea since it increases its compiled size => more gas costs for deployment, easier to reach size limit, wider attack surface, etc.

Calling getters multiple times from JS side might take a lot of time, but it can be improved by calling them in parallel, something along the lines of this:

const totalProviders = await registry.getStakingProvidersCount()

const infoPromises = Array.from({ length: +totalProviders }, async (_, iProvider) => {
  const [totalKeys, totalUnusedKeys] = await Promise.all([
    registry.getTotalSigningKeyCount(iProvider),
    registry.getUnusedSigningKeyCount(iProvider)
  ])
  const keyPromises = Array.from({ length: +totalKeys }, (_, iKey) =>
    registry.getSigningKey(iProvider, iKey))
  return {
    totalKeys: +totalKeys,
    totalUnusedKeys: +totalUnusedKeys,
    keys: await Promise.all(keyPromises)
  }
})

const providersInfo = await Promise.all(infoPromises)

(I haven't tested this code so it might contain minor errors)

Another option is to create a derived testing-only smart contract, containing the desired functions, and deploy it instead of the "real" contract (see TestDePool.sol for example).

[vshvsh]

To get all used signing key you can iterate from getSigningKey(sp_id, 0) to getSigningKey(sp_id, getStakingProvider(sp_id). usedSigningKeys - 1))
I'd suggest using parallel js helpers as @skozin proposed and iff that makes for too long of a delay in test, try for a helper contract for testing.