Problem: zksync eth_signer private key loading security concerns

[JayT106]

Solution: trying to add a gCloud KMS signer into SigningEthClientLayer, using google KMS to manage the private key and stores it in the hardware.

There are three environment variables need to be setup before using the Google KMS signer

GOOGLE_APPLICATION_CREDENTIALS - a service account credential file to allow server to access the google KMS services.
GOOGLE_KMS_OP_KEY_NAME - the KMS key path of the eth sender operator. For example:

projects/zkevm-research/locations/northamerica-northeast2/keyRings/gkms_signer_test/cryptoKeys/gkms_signer_op/cryptoKeyVersions/3

The key path format is:

projects/{project}/locations/{region}/keyRings/{keyRing}/cryptoKeys/{key}/cryptoKeyVersions/{version}

It needs to be matched with the google projects setup to able to access the keys in the google kms.

GOOGLE_KMS_OP_BLOB_KEY_NAME(optional) - the KMS key path of the eth sender blob operator.

Note

The zksync V25 start to introduce the node framework for setup the zk node. There for this PR is only for V24.2.0 on our tesetnet for testing purpose. Later on I will migrate it to the upstream and may using zksync config system instead of the environment variables.

Deployment

During the key setup during the network deployment, we can:

1. Let KMS generate key itself, and no one can know the private key.
2. Use ethereum secret key (a 32-bytes seed), convert it into pem format using openssl ec -inform, and then can import it into KMS, it requires setup key_import_job on google cloud console.

Once got keys in the KMS. We can attest/verify the key through the google cloud console.
For the network deploy we will need to setup the converted ethereum address relate to these keys and set into the L1 contracts.

[thomas-nguy]

overall lgtm

[calvinaco]

Overall LGTM, have a small question about the use of unwrap().

[thomas-nguy]

Merging this PR

@JayT106 as an improvement, lets add mode in config such as ETH_SENDER_SENDER_SIGNING_MODE