Make voting for contracts update more "async"

[greenhat]

In their votes, an oracle needs to specify the reward token amount in the pool box at the time of update-pool command is initiated. See the check at the update contract https://github.com/ergoplatform/eips/blob/e485df29ed54778af0b4a67136a1516409341031/eip-0023/contracts/update_contract.es

So if the update-pool command is not planned to run in the current epoch, the oracles have to estimate the reward token amount in the pool box in the upcoming epochs. Since the reward tokens are given only to the posting oracles whose data points are within the deviation range, it is quite hard to exactly estimate the reward tokens amount in the pool box in a few epochs, let alone the next day. This effectively makes the whole prepare-update, vote-update-pool, update-pool process to be run in the shortest time possible, ideally within one epoch. I foresee this would be hard in a decentralized environment.

[sethdusek]

Do you think this would potentially require changes to the contract? Maybe the best way would be for the person initiating the update to have some amount of reward tokens to "plug the gap" (one epoch worth of reward tokens for example), when updating.

For a decentralized way there could be a reserve box like so that contains extra reward tokens and can only be spent during an update:

INPUTS(1).tokens(0)._1 == updateTokenId

[greenhat]

Do you think this would potentially require changes to the contract?

Probably, yes. The only idea I have so far is to loosen the requirement from = to >=, but it effectively unlocks the delta reward tokens to be taken by the operator that issues the update tx.

Maybe the best way would be for the person initiating the update to have some amount of reward tokens to "plug the gap" (one epoch worth of reward tokens for example), when updating.

For a decentralized way there could be a reserve box like so that contains extra reward tokens and can only be spent during an update:

INPUTS(1).tokens(0)._1 == updateTokenId

Sounds interesting! I'm worrying that adding this step will add more complexity to an already very complex process. Plus, with update NFT id hard coded in the reserve box contract, there will be one more contract to update. :) Wait, I don't think it will even be possible to update it, thus potentially making the update for update contract impossible.

[greenhat]

What if we request the reward token id and amount from voters and check that the new pool box has it only when a new reward token is minted? Otherwise, check that the reward token is preserved in the update contract.
The whole check could be expressed as "reward tokens in the new pool box should be preserved (poolIn==poolOut) OR exactly as voted for (reward token id and amount in ballot box registers)"

EDIT: Here is my proposed change to the update contract - https://github.com/ergoplatform/eips/pull/41/files#r1104628742

EDIT2: Here is my proposed change to the update contract PR - ergoplatform/eips#89

[greenhat]

@scalahub @sethdusek What do you think? ⬆️

[sethdusek]

@scalahub @sethdusek What do you think? arrow_up

Hmm, this does seem like a reasonable solution to me. I don't see any issues with it.

[scalahub]

LGTM