Update 0064-VALP-validator_performance_based_rewards.md #1795
Conversation
…extra cases for PUP.
…eth_changes_during_outages
…eth_changes_during_outages
…specs into eth_changes_during_outages
feat: Add new cases, mostly around eth changes during outages. A few …
chore: remove invalid and unimplemented use cases
refactor: floor slippage
* draft for SORD * add AC for showing rejected reason * typo * execution flags on orders table * add codes to SORD * Update user-interface/7002-SORD-submit_orders.md Co-authored-by: candida-d <[email protected]> * add link to docs --------- Co-authored-by: candida-d <[email protected]>
* Clarify rewards if multisig contains a key it should not * fix: MD lint error --------- Co-authored-by: gordsport <[email protected]>
feat: update FOK MO reduce-only
Co-authored-by: Tom <[email protected]>
fix: Add some more cancel order ACs.
#1637) * feat: Add a test for checking performance scores when checkpoint restart happens in a new epoch. * fix: Typo. * chore: Fix indentation (tabs/spaces).
#1637) * feat: Add a test for checking performance scores when checkpoint restart happens in a new epoch. * fix: Typo. * chore: Fix indentation (tabs/spaces).
Deleted half an AC as discussed on slack (as the number for the performance score didn't make sense here)
* refactor: update ACs * chore: tell approbation to leave me alone * chore: try again * refactor: rephrase AC * refactor: clarify * refactor: fix spelling
* re-arrange ac to save mainetenance * add file extension * onboarding spec tweak * final tweaks and removals * add specs to categories and apps --------- Co-authored-by: Dexter Edwards <[email protected]>
Added Ethereum event forwarding reward/punishment.
Tweak to the formula
Added Heartbeat
Messing with the formulars
Minor clarifications
Formulas generalised
| Detection: Events forwarded by some validators are not forwarded by others. | ||
|
|
||
| #### Ethereum Heartbeat | ||
| For the Ethereum Heartbeat, we use the system parameter <ethereum_heartbeat_period>. This parameter should be either 0 or a value bigger than the number of validators; the recommended initial value is 128, which would create a hearbeat per validator about every 20 minutes (i.e., about 120 heartbeats per validator per epoch). Legal values are all integers larger or equal to 0. |
There was a problem hiding this comment.
should this be a network parameter?
| As we have several performance measurements, they need to be combined to a total score. To this end, we have a system variable performance weights, | ||
| which has n+1 parameters (weight_0,.. weight_n) for n measurements (currently 2, the tendermint-performance and the ethereum-performance.Weights are normalised, so the sum of all weights needs to be 1. Also, all individual performance measurements are normalised to be between 0 and 1. | ||
|
|
||
| The total performance then is |
There was a problem hiding this comment.
Unless we go to the multiplicative version... that would remove the need for weights.
There was a problem hiding this comment.
Indeed; the weights are now also used to choose between multiplicative and additive (or both). If we make a decision that we only need one, they can go.
|
|
||
|
|
||
| #### Performance Measurements | ||
| At the end of each epoch, it is counted how many Ethereum events have been forwarded by each validator; this is (number_of_ethereum_blocks_per_epoch)/`ethereum_heartbeat_period`)+number_of_ethereum_events_per_validator |
There was a problem hiding this comment.
Just thinking about how we're going to know what number_of_ethereum_blocks_per_epoch actually is:
If we want it exactly its something that each node will have to work out by pinging ETH blocks until it finds the first one over the Vega epoch time (which given ethereum block times of ~12 would be a a few Vega blocks later that Vega's epoch end block) and then send their answer through consensus etc etc. Which is a bit faffy.
Is there an acceptable estimate we could use instead i.e using the difference in block-heights and the eth-times between heartbeat's to get a guess at the average eth-block time over the period. And then work out how many of those would fit in Vega's epoch length?
There was a problem hiding this comment.
The performance formulas don't need to be exact - there's some random element in there anyhow, and the reward/punishment formula takes this into account by giving some tolerance; the only precision requirement is agreement on what that value actually is.
What I had in mind when writing is to take the 12/second block time for Ethereum as reliable; otherwise I would measure block height at the beginning and end of a Vega epoch and then run that through agreement. The heartbeats could be used as well, but then I'd do it directly - everyone posting their own number of heartbeats that had that epoch, and then agreeing on the median.
There was a problem hiding this comment.
In any case, the plan was also (if we implement the full reward formula) to initially set the weight parameter for the ETH-event forwarding to 0, so we can get some real life values to verify that it all works before it has serious consequences.
|
closing as replaced by: |
Added Ethereum event forwarding reward/punishment.
close #1993