Add secp validator key to enable pessimistic bridge

Staking validators
24

Here is my feedback:

  1. Regarding the way validators register their keys:
    In the long term, we should have Stake action and the corresponding host function accept a secp256k1 key in addition to an Ed25519 key. The proposed SetValidatorExtraKeys action may be suitable as a short-term kludge, but I would prefer a solution that avoids it.

  2. Regarding the introduction of BLS keys:
    I am firmly against introducing BLS keys at this time. Currently, there is no signature scheme based on BLS keys that is nearly as popular as Ed25519 or the secp256k1-based ECDSA scheme. Without knowing which exact scheme we are going to use, we also don’t know how exactly the keys will look like. While ETH2 has come up with some specific BLS-based signature scheme, we may want to use a different one in the future. Only after we make this choice, we can introduce BLS keys.

  3. Regarding what exactly is going to be signed using the secp256k1 keys:
    While this will probably be decided a bit later, I think that the specific data that is going to be signed with secp256k1 key (as written in the top post) is not optimal for the bridge use case. I think that a better choice will be to sign H(last_final_block_height, last_final_block_merkle_root, H(H(k[0], stake[0]), ..., H(k[n-1], stake[n-1]), total_stake)), where H is the Keccak variant used in Ethereum, and k[i], stake[i] and total_stake refer to the next epoch. Also, the current code for secp256k1 signatures, as implemented in nearcore, will hash any data passed to it using SHA-256. We would probably want to remove this and sign a Keccak hash directly.

2 Likes