HF21 OXEN -> SESH transition #1790
Conversation
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.
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. |
|
LGTM |
tewinget
force-pushed
the
hf21-transition-pr
branch
2 times, most recently
from
35ac715 to
89913f0
Compare
Boost 1.87 removed many things which were previously only deprecated, some of which we were still using.
changing from including boost asio io_service to io_context is roughly equivalent, but the former has a typedef for compatibility. I replicated the typedef, but gated it on the boost version that removed the io_service include.
the bulk of the code for transitioning to HF21 is present, and much testing code is present. This code does not yet work, and the tests are not yet complete. add hf21 transition mechanism to sqlite db
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
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
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
one line of this commit was kept and moved, making actually reverting it and demolishing this commit tedious, so it stays, but the important aspect of it which was to be reverted was later reverted.
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
nodes which fail hf21 transition but were seeded into the contract need to be removeable from the contract. the ones which were *not* seeded into the contract would not be removable from `recently_removed_nodes` so should not be added there to begin with
tewinget
force-pushed
the
hf21-transition-pr
branch
2 times, most recently
from
8ee1800 to
6286082
Compare
tewinget
force-pushed
the
hf21-transition-pr
branch
from
6286082 to
0f959f7
Compare
No description provided.