feat!: handle registering evm addresses in QGB module #2169
Conversation
cmwaters
changed the title
evan-forbes
added
the
consensus breaking
x/qgb/keeper/keeper_valset.go
Outdated
| // should always have an associated EVM address. Fortunately we can | ||
| // safely recover from this by deriving the default again. | ||
| ctx.Logger().Error("validator does not have an evm address set") | ||
| evmAddress = types.DefaultEVMAddress(val).String() |
There was a problem hiding this comment.
If we create a new EVM address here, this is not persisting it in store. Does it make sense to loop for correct default addresses in the hook?
Also, does it make sense to have a safer mechanism to derive the default EVM address? Something like hashing the operator address + something deterministic and specific to the current block?
There was a problem hiding this comment.
Also, does it make sense to have a safer mechanism to derive the default EVM address? Something like hashing the operator address + something deterministic and specific to the current block?
I assume the validator address is unique thus it's safe to derive the EVM address from? Is there a reason why you would like to add more variables?
If we create a new EVM address here, this is not persisting it in store. Does it make sense to loop for correct default addresses in the hook?
Hmm so in theory this should never happen but perhaps you're right that it's better that if there is a developer error that we still persist the new default EVM address
There was a problem hiding this comment.
I assume the validator address is unique thus it's safe to derive the EVM address from? Is there a reason why you would like to add more variables?
the validator address is unique but as was discussed yesterday, some other validator can derive your validator EVM address and use it for themselves. Especially if the validator reuses keys
There was a problem hiding this comment.
I guess it makes sense to open an issue to keep note that we can have a squatting issue and we need to investigate it when we have time
Co-authored-by: CHAMI Rachid <[email protected]>
Bumps to the latest version of the SDK. Note that this deactivates the use of the EVM address. To fulfill that functionality we will need to reintroduce a mapping in #2169
Addresses: #1698 --------- Co-authored-by: CHAMI Rachid <[email protected]> Co-authored-by: Evan Forbes <[email protected]>
Bumps to the latest version of the SDK. Note that this deactivates the use of the EVM address. To fulfill that functionality we will need to reintroduce a mapping in celestiaorg/celestia-app#2169
Addresses: #1698