Beacon Chain Node Private Key Management

[terencechain]

Using this issue to open up discussion on how we plan to manage private key from beacon chain node's point of view. Let's explore how to harden the access to the private key for future releases as security is going to be a real consideration. User should have the options to generate new key pair from beacon chain node or import previously owned key pair from main chain. At the same time, we should keep 3rd party use cases in mind.

[rauljordan]

To add more light on this issue:

• It is possible we will migrate away from ECDSA in Ethereum 2.0. In that case, the traditional pubkey/privkey management mechanisms will not apply but this is yet to be finalized. @rawfalafel brought this up on Gitter.
• The same identity that deposited 32ETH into the PoW Chain VRC contract should be the same one that spins up a validator as part of beacon node. This is why it makes sense for the beacon node to have the privKey corresponding to the pubKey that deposited on the mainchain.

[eolszewski]

I think that most people in the security community would disagree with the idea of copying private keys around. In lieu of this, we can create a new key to use on the beacon chain and sign (certify) it with our mainchain key.

[prestonvanloon]

+1 to not copying private keys.

@terenc3t can you clarify the problem up for discussion? Is it that validators are registered with a mainchain wallet address and that the validator is meant to sign attestations with that same wallet address? Can you add some general background for this discussion?

[rauljordan]

@prestonvanloon that approach would require some moving of priv keys around. Would be best to follow a suggestion similar to what @eolszewski mentioned - where we create a new key for attestations that is certified by the validator's mainchain key.

[prestonvanloon]

I understand that. What I don’t understand is the original issue for discussion.

[rawfalafel]

The original issue was that if the private key used to deposit 32ETH to the PoW chain was the same as the private key used to validate on the beacon chain, there would have to be some mechanism to securely move the private key over to the beacon chain.

This shouldn't be an issue. A would-be validator can generate a new private key from the validator client and include the pubkey of the new key in the validator deposit contract (there's a field for this in the 2.1 spec). The original key stays in the PoW chain wallet and the validator key stays in the validator client.

One more note: From what I understand, Eth 2.0 is 100% switching over to a new signature scheme since we're relying on BLS aggregation to scale up the number of attesters.

[eolszewski]

I've seen plenty of talk about CAS and the current lack of on-chain implementation is certainly stymying our plasma efforts. Can you link to where you saw something alluding to this change?

[rawfalafel]

Yep! https://ethresear.ch/t/pragmatic-signature-aggregation-with-bls/2105

Gonna sound ignorant but what's CAS?

[eolszewski]

Cryptographic Aggregate Signatures, it's on that link you posted, haha.

I have seen this and am aware of the bottleneck but didn't think that there was going to be a complete transition - although this is reasonable.

[rawfalafel]

Whoops lol.

Maybe this is obvious but I'll include just in case: We don't require any changes to the EVM because the beacon chain doesn't manage transaction state. BLS aggregation would all be done in whatever language the client implements with.

[rauljordan]

Should we go ahead and use ECDSA to certify a new key in the beacon chain with a validator's powchain key? Or should we hold off on this and just go ahead with BLS? tagging: @terenc3t

[eolszewski]

I think that's a reasonable and well understood path forward for the time being.

[rauljordan]

@nisdas expressed interest in some initial PRs to tackle this issue

[rauljordan]

We are using validator accounts create to leverage geth's keystore for this as of #1436. Closing.