Key Split Update (technical)

With the key split we have updated how assertions and claims work to enable significant gas optimizations.

Changes to Referee, Operator, Assertion, Claims for the 1:100 key split

Summary of changes: the referee contract has been upgraded to allow “Bulk Submit Assertions”. “Bulk Submit Assertions” will now be used in lieu of “submitMultipleAssertions”. The Bulk Submission function is substantially more gas efficient than submitMultipleAssertions, this is achieved by reducing the contract state that is created when submitting an assertion by the Node Operator. The base probability of being able to participate in a challenge has changed proportionally to the change in supply. Previously when there was a supply of 50,000 keys the win probability was 1%, now with 5,000,000 keys the win probability is 0.01%. To achieve this the Referee smart contract is upgraded:

• New algorithm to determine winning keys based on a number of keys submitted for

• Submit/Claim once for all staked keys in a pool or all unstaked keys held in a wallet

• Individual key ids are no longer required to be submitted for assertion or claim transactions.

This means any operator will now be able to submit for any unstaked keys in an assigned owner wallet or for all keys staked in a staking pool owned or delegated.

The amount of winning keys will no longer be determined based on the random chance for a specific Node License Key ID and the staking tier boost factor but from a random chance based on the owner/pool address, the staking tier boost factor and the total amount keys either staked in a pool for a pool bulk submission or unstaked keys in an owner wallet for an owner bulk submission.

New Functions:

1. submitBulkAssertion: params

   1. address _bulkAddress

   2. uint256 _challengeId

   3. bytes memory _confirmData

This function replaces submitMultipleAssertions.

The _bulkAddress should be either the poolAddress being submitted for, or the key owner’s wallet address. Individual key Ids are no longer required to be passed into the function call.

1. claimBulkRewards: params

   1. address _bulkAddress

   2. uint256 _challengeId

This function replaces claimMultipleRewards.

The _bulkAddress should be either the poolAddress being claimed for, or the key owner’s wallet address. Individual key Ids are no longer required to be passed into the function call.

Changes to calculation algorithm:

1. Individual key Ids are no longer used to calculate “Winning Keys”.

2. Instead, a statistical probability method is used.

3. The same method is used for pools and owner wallets.

4. There are two variations to the new algorithm.

   1. High probability of having a winning key (1% or more).

   2. Low probability of having a winning key (Less than 1%)

Algorithm Flow

1. The algorithm will first determine the number of keys being submitted for.

   1. For pools, this will be the total number of keys staked.

   2. For owner wallets, this will be the total number of un-staked keys.

2. Next the algorithm will determine the expected number of winning keys based on the boost factor.

   1. Example: 1,000 keys in a pool with a 700 boost factor would expect 70 winning keys.

High Probability Algorithm: for high probabilities where we expect at least 1 winning key

1. We now use a random number to add/subtract up to 30% variance to the expected winning keys.

   1. This means the example above for an expected winning key count of 70 winning keys could return anywhere from 49 to 91 winning keys with the average being about 70 keys over the long term.

Low Probability Algorithm: for low probabilities (less than 1%), where we do not always expect at least 1 winning key we calculate this differently.

1. We determine the total probability of winning (1= 0.01 %, 100=1% etc…)

2. We scale that up(multiply) by 10,000. (Scaled Probability of Winning)

3. We now generate a random number between 0 - 999,999.

4. If the random number is below the Scaled Probability of Winning, the submission wins for a single key.

What happens when keys get staked or unstaked into a pool during a challenge: Any already submitted bulk assertion for the current challenge will be updated to reflect the changes in the number of keys and resulting number of winning keys.

If a pool has already submitted a bulkAssertion and a new key is staked into the pool before the end of the challenge, the following will happen:

1. If the owner of the staked key as already submitted a bulk submission for the current challenge, that submission will be updated to reflect the owner’s new un-staked key count and will then be re-calculated based on the owner’s new un-staked key count.

2. If the pool has already submitted a pool bulk submission for the current challenge, that submission will be updated to reflect the new staked key count and will then be re-calculated based on the new staked key count.

What happens if keys are un-staked from a pool during a challenge:

If a pool has already submitted a pool bulk submission and a key is un-staked from the pool before the end of the challenge, the following will happen:

1. The previously submitted pool bulk submission will be re-calculated based on the new staked key count after the un-staked key has been removed from the pool’s staked key count.

The goal of the changes are to allow the number of keys/node licenses to be scaled up without increasing the operational gas costs for an operator and reducing the amount of data/computations that need to be handled on-chain.