HF21 OXEN -> SESH transition #1790
Conversation
TODO: split commits and better commit message(s)
After HF21, any nodes which did not transition to SENT stakes need to be removed. Doing them all at once would be chaotic with swarms, so they will be removed by the existing decommission/deregister system. That system now has a config-determined limit of deactivations per block so that this transition (but also huge network outages) won't cause swarms to disappear (or other possible chaos resulting from mass removal).
Staked oxen addresses which are not registered for the SENT transition will have their pending service node rewards paid out in full on the final block before HF21. Modified local devnet testing to leave a staked static-startup address out of the registration for testing this (and adjusted expected numbers accordingly).
nodes which did not transition to hf21 will be removed by the decommission->deregister mechanism rather than by the bls-key-not-in-the-contract mechanism
TODO: set hf21 fork height
script needs parameters set as appropriate: - oxen -> eth address mapping - transition bonus mapping - staking requirement and scaling ratio TODO: some mainnet nodes have a larger stake, scaling needs to be normalized for those
The mechanism previous commits used is no longer present after a rebase This could (should) be merged into an earlier commit
They cannot ever come back, so there's really no point of leaving them for a week. (We *don't* want to immediately dereg them because going into decomm still allows SN comms between storage servers, allowing the leaving nodes to still transfer their files out to the remaining nodes upon swarm dissolution).
nodes which do not transition at hardfork 21 should not be in the reward payment rotation
calling this method returns a before and after as if hf21 would happen the very next block. Because outstanding oxen rewards will differ from the exact fork height (and from block to block), this can only be approximate, but it should be fairly close to what the actual result will be.
higher staking requirement to test hf21 transition correctly scaling stake proportions in multi-contrib
The block before HF21 all addresses with accrued rewards which are not registered for the HF21 transition with an ETH address will have their OXEN balance paid out at that height rather than converted. This was not working correctly for multiple reasons, but is now.
also update devnet hf21 parameters
There was a problem hiding this comment.
Generally LGTM, minor nitpicks.
Are we missing some code to block someone from requesting to leave the network after HF20? I think there might be an edge case we don't handle if we let people exit and their requested_unlock_height is set on Oxen but the equivalent mechanism is not set on the smart contract.
I couldn't come up with any other edge cases so far, seems like a bunch of the edge cases are already covered.
| @@ -3665,7 +3741,7 @@ void service_node_list::process_block( | |||
| } | |||
|
|
|||
| m_state.update_from_block( | |||
| blockchain.db(), | |||
| blockchain, | |||
There was a problem hiding this comment.
We should just use the new function prototype here and pass in blockchain.db() and blockchain.maybe_sqlite_db() since the call-site had to be updated anyway in this case to take blockchain instead of blockchain.db.
Which means then we can get rid of the helper function that takes the Blockchain and thunks into a function that pulls out the SQL DB. The SNL header is quite unwieldy so it'd be good to try and get rid of stuff from there where we can.
I don't think we need such a block. Whenever an oxen unlock is processed, we set the exit height at +15d. (That may well be from an unlock issued during HF19 if the HF20 window is less than 15d). If that unlock height extends into HF21, I think it's fine: we will end up with a node that the contract does not know initiated an unlock, but that oxend does, and so when that unlock happens on the oxend-side, service nodes will start issuing voluntary exit signatures, and start issuing liquidation signatures 7d after that. Before this reversion that would have been a problem, but with that check gone the contract will happily exit anything the oxen network has signed off on. |
No description provided.