WIP: Inomurko/vault integration

[InoMurko]

This is a step towards integration Hashicorp Vault into Sequencer and Proposer nodes (batch-submitter) to gatekeep privatekey accounts.

[InoMurko]

Whats left to do:

• [x] Vault integration testing with l1_chain and deployer The APIs needed testing (with curl examples and data): Write tests in smoke.ovm.sh

curl -X PUT -H "X-Vault-Token: $(vault print token)" -H "X-Vault-Request: true" -d '{"batch":["0x1111111111111111111111111111111111111111111111111111111111111111","0x1111111111111111111111111111111111111111111111111111111111111111"],"contract":"<contract address>","gas_price":"37000000000","nonce":"0","should_start_at_element":"0"}' https://127.0.0.1:8900/v1/immutability-eth-plugin/wallets/OVM-wallet/accounts/0x888a65279D4a3A4E3cbA57D5B3Bd3eB0726655a6/ovm/appendStateBatch


curl -X PUT -H "X-Vault-Request: true" -H "X-Vault-Token: $(vault print token)" -d '{"contexts":"{\"num_sequenced_transactions\": 2, \"num_subsequent_queue_transactions\": 1, \"timestamp\": 100, \"block_number\": 200}","contract":"","gas_price":"37000000000","nonce":"0","should_start_at_element":"10","total_elements_to_append":"1","transactions":["0x45423400000011","0x45423400000012"]}' https://127.0.0.1:8900/v1/immutability-eth-plugin/wallets/OVM-wallet/accounts/0x888a65279D4a3A4E3cbA57D5B3Bd3eB0726655a6/ovm/appendSequencerBatch

You need to feed the contract addresses to the docker-compose-vault-test.yml but also provision contracts with sequencer and proposer accounts.

• [x] Sequencers (batch_submitter) nodes need to OAuth2 authenticate so that they acquire a token that is later used to communicate with Vault (X-Vault-Token). Important reading material:

• https://learn.hashicorp.com/tutorials/vault/oidc-auth

• https://www.vaultproject.io/docs/auth/jwt

• https://www.vaultproject.io/docs/auth/aws

• https://learn.hashicorp.com/tutorials/vault/tokens Decide how this is tested.

• [x] When Vault is unsealed, Wallets for the Sequencer and/or (could be the same account) Proposer need to be created. I suggest single account wallets:

vault write  -format=json immutability-eth-plugin/wallets/sequencer
vault write  -format=json immutability-eth-plugin/wallets/proposer
vault write -format=json immutability-eth-plugin/wallets/sequencer/accounts
vault write -format=json immutability-eth-plugin/wallets/proposer/accounts

• [x] Contract deployer needs sequencer and proposer account addresses. Decide if you feed them into the node manually or give it a policy to fetch it from list of accounts:

vault list -f -field=address immutability-eth-plugin/wallets/sequencer/accounts
vault list -f -field=address immutability-eth-plugin/wallets/proposer/accounts

• [x] Sequencer and Proposer accounts need to be funded with ETH! Monitor balances!

• [x] Policy setup. Policy purpose is that when Sequencers acquire OAuth2 they get a token that only allows them to use certain Vault APIs, for example: Reading material: https://www.vaultproject.io/docs/concepts/policies

tee submit-state-batch.hcl <<EOF
path "immutability-eth-plugin/wallets/sequencer/accounts/$SEQUENCER_ADDRESS/ovm/appendStateBatch" {
    capabilities = ["create"]
}
EOF

vault policy write submit-state-batch submit-state-batch.hcl

• [ ] Vault RAFT setup (but not for docker compose!)
• [ ] Vault sealing/unsealing process laid out (for example auto unsealing https://www.vaultproject.io/docs/platform/k8s/helm/run#google-kms-auto-unseal and have the manual unsealing discussion so that tradeoffs are understood!)

If you want to test Vault locally:

~/opt/optimism/ops$ rm -rf vault/ && docker build ../ --file /Users/inomurko/opt/optimism/ops/docker/Dockerfile.omgx_vault --tag omgx/vault:latest && docker-compose -f docker-compose-omgx.yml -f docker-compose-omgx-services.yml -f ../packages/omgx/immutability/docker/docker-compose-vault-test.yml up l1_chain vault

[InoMurko]

More details on the batch-submitter integration:

• BatchSubmitter class that both StateBatchSubmitter and TransactionBatchSubmitter extend reference signer field, which is initialised with a private key from sequencer and proposer and l1 Provider

new Wallet(SEQUENCER_PRIVATE_KEY, l1Provider)

The integration assumes that either a private key (64 bytes) or a simple address (20byte) is feed into the container (as env var).

On lots of places, the Signer wrapper is used. This wrapper gives easy access to methods that needs to be wrapped and used only with https://docs.ethers.io/v5/api/providers/ .

this.signer.getAddress()
this.signer.getBalance()
this.signer.getGasPrice()
this.signer.getTransactionCount()
this.signer.provider.waitForTransaction
this.signer.provider.getBlockNumber()

Contract instances, like for example:

const manager = new ethers_1.Contract(this.addressManagerAddress, contracts_1.getContractInterface('Lib_AddressManager'), this.signer.provider);

should be rewritten to use a ethers_1.ethers.providers.Provider instance.

new Contract(addressOrName: string, contractInterface: ethers_1.ethers.ContractInterface, signerOrProvider?: ethers_1.ethers.Signer | ethers_1.ethers.providers.Provider): ethers_1.ethers.Contract
export Contract

[codecov-commenter]

Codecov Report

Merging #188 (6c55731) into develop (c0a3f3f) will decrease coverage by 0.45%. The diff coverage is 62.85%.

@@             Coverage Diff             @@
##           develop     #188      +/-   ##
===========================================
- Coverage    76.10%   75.64%   -0.46%     
===========================================
  Files           81       83       +2     
  Lines         3038     3100      +62     
  Branches       469      479      +10     
===========================================
+ Hits          2312     2345      +33     
- Misses         726      755      +29     

Flag	Coverage Δ
batch-submitter	58.94% <62.85%> (-0.66%)	:arrow_down:
contracts	86.05% <ø> (ø)
core-utils	68.16% <ø> (ø)
data-transport-layer	37.68% <ø> (ø)
message-relayer	72.22% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
.../batch-submitter/src/transaction-chain-contract.ts	81.81% <ø> (-0.80%)	:arrow_down:
...ic-ethereum/OVM/chain/OVM_StateCommitmentChain.sol	87.50% <ø> (ø)
packages/batch-submitter/src/utils/vault.ts	14.28% <14.28%> (ø)
...h-submitter/src/batch-submitter/provider-helper.ts	78.57% <78.57%> (ø)
...ubmitter/src/batch-submitter/tx-batch-submitter.ts	44.03% <82.35%> (+1.55%)	:arrow_up:
...ackages/batch-submitter/src/utils/tx-submission.ts	84.21% <85.71%> (-4.26%)	:arrow_down:
...h-submitter/src/batch-submitter/batch-submitter.ts	83.67% <100.00%> (+0.34%)	:arrow_up:
...itter/src/batch-submitter/state-batch-submitter.ts	75.30% <100.00%> (+1.28%)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update c0a3f3f...6c55731. Read the comment docs.

[petardenev]

PLEASE DON'T MERGE, YET! there are changes in the github workflows that must be reverted prior to merging this to develop

[InoMurko]

Removing appendQueueBatch calls to conform https://github.com/ethereum-optimism/optimism/pull/1346