search

oxen-io / eth-sn-contracts

4 stars 8 forks source link

Add bls<->ed25519 mapping to reject dupe keys #85

Closed Doy-lee closed 2 months ago

Doy-lee commented 2 months ago

The mapping is used to outright reject anyone that tries to register a different BLS key for the same Ed25519 key, but similarly, also, a different Ed25519 key for the same BLS key.

If these make it through the contract, the contract locks up collateral and then the onus of freeing up those funds ends up in the oxen codebase. There are issues in this because the link between L2 and Oxen is more vulnerable than just outright preventing us from getting into the situation in the first place.

--

Note C++ tests are broken because of some renaming that happened in this PR and I believe we are looking to sunset that so I haven't updated them but certainly can if that's non-negotiable.

--

Additionally some small cleanup in the rewards contract

  1. Public variables have an automatically generated getter function so there's no need to re-specify those in the rewards contract itself which just bloats the contract with duplicate code.
  2. Inline addBLSPublicKey because there's no other auxiliary contract in our ecosystem that needs to be able to parameterise the caller of that function.
Doy-lee commented 2 months ago

Oh I thought of a way that works in theory. Introduce a ServiceNodeV2 with the new field- pause the contract, add an admin function to walk the list and migrate all ServiceNode structs -> ServiceNodeV2, unpause the contract.