jagerman
commented
2 months ago The smart contract has a stop-gap for this that it also starts, independently from the network a 30 day timer in which you can evict the a node from the smart contract without a signature. (Again another point of potential desync between the SNL and the smart contract).
I think this one is self-correcting: when removeBLSPublicKeyAfterWaitTime gets called we'll still a ServiceNodeRemoval event that should get witnessed and confirmed by Oxen. (But maybe Oxen currently rejects it, because it didn't see the unlock initiation?)
A whole bunch of stuff, and, also a bunch of stuff that still needs to be done. But I've marked them as TODO.
The general gist is nodes that are deregistered by the protocol or those that have initiated a voluntary exit (and the necessary exit time has elapsed,
UNLOCK_DURATION=> 24hrs for stagenet, 15 days on mainnet), then nodes are erased from the SNL and moved into a staging buffer called therecently_removed_nodeslist. This is an extension of what Sean started with but I've fleshed it out more.All nodes in the
recently_removed_nodeslist are eligible to exit the smart contract by aggregating a signature from the network. If they don't exit in a timely manner (ETH_EXIT_BUFFER=> 2hrs on stagenet, 1 week on mainnet), these nodes then become eligible to be liquidated.Once eligible for exit/liquidation SN's will accept a request to sign a request to remove the node. You can then submit this to the smart contract and that will be witnessed by Oxen thereby removing it from the
recently_removed_nodes.I have some concerns about the SNL and smart contract going out of sync from potential bugs I haven't addressed here but we should mitigate. The smart contract has a stop-gap for this that it also starts, independently from the network a 30 day timer in which you can evict the a node from the smart contract without a signature. (Again another point of potential desync between the SNL and the smart contract).
But, the PR here should be good enough for the feature release and the remainder is more guarding against adversarial cases around the system.
Here's a short list of new things that need to be addressed:
Some mechanism to mitigate the SNL becoming desynced from the smart contract (e.g. the node exists in the SNL but not the smart contract, we handle the other case where the node exists in the smart contract but not the SNL which is the expected case using aggregate signatures). This is related to https://github.com/oxen-io/oxen-core/pull/1670
Nodes that have exited the SNL but not the smart contract should participate in the BLS aggregation for stability of the network (until they are removed from the smart contract at which point they no longer contribute to the master BLS key).
We should not be able to insert a cryptonote address into the delayed payments table after the HF. This happened accidentally from a bug, but, the moment it got inserted the entire network stalled because of an uncaught exception blocking block production. Too fragile to leave this be, there should be more checks at the DB layer.
The smart contracts don't currently enforce a sensible maximum bound on the timestamp given to exits and liquidations. Our threat model is that we assume that someone will be able to get the network to sign a malicious request. If a request is signed for 100 years into the future, the signature can be reused for the next 100 years (TBF requires a fairly stable SNL list ...)
Pre-calculate some lookup tables on block receive (e.g. list of active service nodes, bls -> ed25519 mapping, list of removable and liquidatable nodes for each height) to avoid unnecessary linear scans.
Still accept proofs from recently removed nodes (protocol dereg/voluntary exit) whilst they are still in the smart contract (since they still contribute to the master BLS key) so that we have an up to date IP and port to contact them on for signature aggregation