oracle

[vshvsh]

oracle (smart contract)

based on https://github.com/depools/depool-dao/blob/master/apps/depooloracle/contracts/DePoolOracle.sol but

1. oracles should report uniform data: it's eth2 blockchain, when finalized there should be no two different views on network and all honest oracles should report the exact same result
   thus https://github.com/depools/depool-dao/blob/master/apps/depooloracle/contracts/DePoolOracle.sol#L225
   should count quorum on exact results instead of mean result
2. Find a different name for Epoch (maybe interval) bc people are confusing it with eth2 Epoch
3. allow reporting epochs from the past (not current epochs) as long as epoch is > than the last reported one and <= current one (nb can be exploited in edge cases for a short time)

oracle (daemon)

oracle should report balance for every 7200*x slot (0, 7200, 14400, ...) when it's finalized but not earlier. In pushData(uint256 _epoch, ...) _epoch (that needs to be renamed to _data_timestamp or something) should be the blocktime of the slot. Edge cases are when there's no block for the slot - in that case, balance and blocktime should be for the last finalized block before 7200*x, usually 7200*x-1.

Balance reported = sum of all balances on active validators under depool control (up to date list of keys is in the smart contract), + sum of all balances on validators under depool control in the activation queue + sum of all balances under depool control in the exit queue + sum of all balances on inactive (exited) validators under depool control

[ongrid]

After research and modeling I'd propose to use ETH2 epochs as a main measurement unit in algorithm instead of initially proposed slots. Reasons:

• epochs are the main subject of ETH2 finality
• both prysm and lighthouse APIs and STDOUT logs they produce give the finality attribute for epoch objects.
• With less parameters to care, state management and troubleshooting are simpler.
• states (balances) are tied to epochs, not slots. Polling states from adjacent slots that belong to the same epoch produce the same results.
• larger units - less syncronization confusions and less aggressive timing

With Eth2 defaults

SLOTS_PER_EPOCH=32

one-day long interval 7200/32 = 225 epochs

@vshvsh your opinion?