Make Churner work on v2 smart contracts #213
Conversation
|
Unfortunately, I don't think this design works because it doesn't enforce any connection between the operatorAddress and the PublicKeys. In particular, it allows for the operator to register with the churner using one operatorAddress and PubKey (one with a lot of stake) and then call the RegisterOperator contract method with a different address. I think the simplest solution may be to include both the address and the operatorId in the messaage signed by the churner. However, this may require smart contract changes. |
|
Good point! The message it signs right now is exactly the request hash (of the ChurnRequest), so it looks straightforward to extend from here. |
Just make sure to check the smart contract side. The message will need to be updated there as well, so we probably need @0x0aa0, @gpsanant involved for this to make it into the middleware contracts. |
|
Yeah, I'm leaving the smart contract out. It looks this one: https://github.com/Layr-Labs/eigenlayer-middleware/blob/6e95af93430583a886c3faa393d44bd7e29f677e/src/RegistryCoordinator.sol#L897 |
jianoaix
changed the title
| @@ -588,7 +589,7 @@ func (t *Transactor) CalculateOperatorChurnApprovalDigestHash( | |||
| } | |||
| return t.Bindings.RegistryCoordinator.CalculateOperatorChurnApprovalDigestHash(&bind.CallOpts{ | |||
| Context: ctx, | |||
| }, operatorId, opKickParams, salt, expiry) | |||
| }, operatorAddress, operatorId, opKickParams, salt, expiry) | |||
There was a problem hiding this comment.
@0x0aa0 This is where we depend on the onchain change
| @@ -33,6 +33,8 @@ message ChurnRequest { | |||
| // - If any of the quorum fails to register, this entire request will fail. | |||
| // The IDs must be in range [0, 255]. | |||
| repeated uint32 quorum_ids = 5; | |||
| // The Ethereum address (in hex like "0x123abcdef...") of the operator. | |||
| string operator_address = 6; | |||
There was a problem hiding this comment.
This would be better to place at the top. It's just about having to change the field number, which is breaking.
Why are these changes needed?
In the v2 contracts, there is no pubkey compendium registration before registering the operator. As a result, we cannot convert operatorID to address.
The reason we did this was to avoid spams. However, since we set the rate limit to 5mins per request, it should be safe enough to counter the spams.
We may come up with stronger measures if this isn't the case (e.g. requiring a eth address with min balance).
Checks