evm signature 'v' derivation

[tkernell]

• we need to know proper v values for the data bridge when:
  • deriving evm addresses for layer validators. these are derived from a signature. we are appending 00 to signatures before deriving evm addresses.
  • relaying bridge validator set update signatures to the bridge contract
  • relaying oracle attestations to the bridge contract

we expect the 00 value to correspond to a 27 in solidity's ecrecover function, but we found that we often need to use 28 instead. sometimes neither 27 nor 28 works. this has yet to be resolved.

[tkernell]

The method we're using for handling this issue is:

• when deriving layer validators' evm addresses, we have each validator sign 2 messages "messageA" and "messageB". We then derive 2 evm addresses for each message using both 00 and 01 as v values. Then we check which address from the "messageA" set matches an address from the "messageB" set. That is the validator's evm address.
• before inputting a signature into the bridge contract, we use a similar method to above. We check whether using 27 or 28 as a v value gives the expected evm address, and we use that value for inputting into the bridge contract when verifying valset change and oracle signatures.