Skip to content

Commit

Permalink
Upgrade the BalanceTracker contract to reduce target balances
Browse files Browse the repository at this point in the history
  • Loading branch information
@mdehoog
mdehoog committed Jul 25, 2024
1 parent 65b8deb commit ebb6d7c
Show file tree
Hide file tree
Showing 7 changed files with 407 additions and 0 deletions.
11 changes: 11 additions & 0 deletions mainnet/2024-07-24-reduce-batcher-proposer-balance-targets/.env
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
OP_COMMIT=e87e5ef2b96893eb8b446da420f7ba7f3e3c5985
BASE_CONTRACTS_COMMIT=3e9314d57f453077606b4768094cae3f287af72b

CB_INCIDENT_SAFE_ADDR=0x14536667Cd30e52C0b458BaACcB9faDA7046E056
PROFIT_WALLET=0xEc8103eb573150cB92f8AF612e0072843db2295F
BALANCE_TRACKER_PROXY=0x23b597f33f6f2621f77da117523dffd634cdf4ea
BALANCE_TRACKER_IMPLEMENTATION=0xB00FB2ead6C6150b11fC8b3A8CF7F8944C7dba7b
OUTPUT_PROPOSER=0x642229f238fb9dE03374Be34B0eD8D9De80752c5
BATCH_SENDER=0x5050F69a9786F081509234F1a7F4684b5E5b76C9
OUTPUT_PROPOSER_TARGET_BALANCE=50000000000000000000
BATCH_SENDER_TARGET_BALANCE=550000000000000000000
24 changes: 24 additions & 0 deletions mainnet/2024-07-24-reduce-batcher-proposer-balance-targets/Makefile
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
include ../../Makefile
include ../.env
include .env

ifndef LEDGER_ACCOUNT
override LEDGER_ACCOUNT = 0
endif

.PHONY: deploy
deploy:
forge script --rpc-url $(L1_RPC_URL) DeployBalanceTracker \
--ledger --hd-paths "m/44'/60'/$(LEDGER_ACCOUNT)'/0/0" --broadcast


.PHONY: sign
sign:
$(GOPATH)/bin/eip712sign --ledger --hd-paths "m/44'/60'/$(LEDGER_ACCOUNT)'/0/0" -- \
forge script --rpc-url $(L1_RPC_URL) UpgradeBalanceTracker \
--sig "sign()"

.PHONY: execute
execute:
forge script --rpc-url $(L1_RPC_URL) UpgradeBalanceTracker \
--sig "run(bytes)" $(SIGNATURES) --ledger --hd-paths "m/44'/60'/$(LEDGER_ACCOUNT)'/0/0" --broadcast
184 changes: 184 additions & 0 deletions mainnet/2024-07-24-reduce-batcher-proposer-balance-targets/README.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,184 @@
# Transfer ownership of L1 `BalanceTracker` from the CB Upgrade multisig to the CB Incident multisig

Status: READY TO SIGN

## Objective

Upgrade the L1 `BalanceTracker` contract to modify the batcher target balance to 550 ETH and the proposer to 50 ETH.

## Approving the transaction

### 1. Update repo and move to the appropriate folder:
```
cd contract-deployments
git pull
cd mainnet/2024-07-24-reduce-batcher-proposer-balance-targets
make deps
```

### 2. Setup Ledger

Your Ledger needs to be connected and unlocked. The Ethereum
application needs to be opened on Ledger with the message "Application
is ready".

### 3. Simulate and validate the transaction

Make sure your ledger is still unlocked and run the following.

``` shell
make sign
```

Once you run the `make sign` command successfully, you will see a "Simulation link" from the output.

Paste this URL in your browser. A prompt may ask you to choose a
project, any project will do. You can create one if necessary.

Click "Simulate Transaction".

We will be performing 1 validation, and then we'll extract the domain hash and
message hash to approve on your Ledger then verify completion:

1. Validate the proxy implementation has been updated correctly.
2. Validate the initializer variable has been incremented.
3. Validate the two target balance values have been modified.


#### 3.1. Validate integrity of the simulation.

Make sure you are on the "Overview" tab of the tenderly simulation, to
validate integrity of the simulation, we need to check the following:

1. "Network": Check the network is Ethereum Mainnet.
2. "Timestamp": Check the simulation is performed on a block with a
recent timestamp (i.e. close to when you run the script).
3. "Sender": Check the address shown is your signer account. If not,
you will need to determine which “number” it is in the list of
addresses on your ledger.
4. "Success" with a green check mark


#### 3.2. Validate correctness of the state diff.

Now click on the "State" tab. Verify that:

1. Verify that the nonce is incremented for the Upgrade Multisig under the "GnosisSafeProxy" at address `0x14536667Cd30e52C0b458BaACcB9faDA7046E056`. We should see the nonce increment from 24 to 25:

```
Key: 0x0000000000000000000000000000000000000000000000000000000000000005
Before: 0x0000000000000000000000000000000000000000000000000000000000000018
After: 0x0000000000000000000000000000000000000000000000000000000000000019
```

2. Verify that the implementation is appropriately updated under "Proxy" at address `0x23B597f33f6f2621F77DA117523Dffd634cDf4ea`.
We should see that the implementation change from 0x54d194faae439fc3f8024801b0b9ebc91ebd39f5 to 0xb00fb2ead6c6150b11fc8b3a8cf7f8944c7dba7b:

```
Key: 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc
Before: 0x00000000000000000000000054d194faae439fc3f8024801b0b9ebc91ebd39f5
After: 0x000000000000000000000000b00fb2ead6c6150b11fc8b3a8cf7f8944c7dba7b
```

3. Verify that the initializer is appropriately updated under "Proxy" at address `0x23B597f33f6f2621F77DA117523Dffd634cDf4ea`.
We should see that the value change from 1 to 2:

```
Key: 0x0000000000000000000000000000000000000000000000000000000000000000
Before: 0x0000000000000000000000000000000000000000000000000000000000000001
After: 0x0000000000000000000000000000000000000000000000000000000000000002
```

4. Verify that the proposer target balance is appropriately updated under "Proxy" at address `0x23B597f33f6f2621F77DA117523Dffd634cDf4ea`.
We should see the value change from 200 ETH to 50 ETH:

```
Key: 0x46bddb1178e94d7f2892ff5f366840eb658911794f2c3a44c450aa2c505186c1
Before: 0x00000000000000000000000000000000000000000000000ad78ebc5ac6200000
After: 0x000000000000000000000000000000000000000000000002b5e3af16b1880000
```

5. Verify that the batcher target balance is appropriately updated under "Proxy" at address `0x23B597f33f6f2621F77DA117523Dffd634cDf4ea`.
We should see the value change from 1000 ETH to 550 ETH:

```
Key: 0x46bddb1178e94d7f2892ff5f366840eb658911794f2c3a44c450aa2c505186c2
Before: 0x00000000000000000000000000000000000000000000003635c9adc5dea00000
After: 0x00000000000000000000000000000000000000000000001dd0c885f9a0d80000
```

#### 3.3. Extract the domain hash and the message hash to approve.

Now that we have verified the transaction performs the right
operation, we need to extract the domain hash and the message hash to
approve.

Go back to the "Overview" tab, and find the
`GnosisSafe.checkSignatures` call. This call's `data` parameter
contains both the domain hash and the message hash that will show up
in your Ledger.

Here is an example screenshot. Note that the value will be
different for each signer:

![Screenshot 2024-03-07 at 5 49 02 PM](https://github.com/base-org/contract-deployments/assets/84420280/1b7905f1-1350-4634-a804-7b4458d0ddc9)


It will be a concatenation of `0x1901`, the domain hash, and the
message hash: `0x1901[domain hash][message hash]`.

Note down this value. You will need to compare it with the ones
displayed on the Ledger screen at signing.

### 4. Approve the signature on your ledger

Once the validations are done, it's time to actually sign the
transaction. Make sure your ledger is still unlocked and run the
following:

``` shell
make sign
```

> [!IMPORTANT] This is the most security critical part of the
> playbook: make sure the domain hash and message hash in the
> following two places match:
1. on your Ledger screen.
2. in the Tenderly simulation. You should use the same Tenderly
simulation as the one you used to verify the state diffs, instead
of opening the new one printed in the console.

There is no need to verify anything printed in the console. There is
no need to open the new Tenderly simulation link either.

After verification, sign the transaction. You will see the `Data`,
`Signer` and `Signature` printed in the console. Format should be
something like this:

```
Data: <DATA>
Signer: <ADDRESS>
Signature: <SIGNATURE>
```

Double check the signer address is the right one.

### 5. Send the output to Facilitator(s)

Nothing has occurred onchain - these are offchain signatures which
will be collected by Facilitators for execution. Execution can occur
by anyone once a threshold of signatures are collected, so a
Facilitator will do the final execution for convenience.

Share the `Data`, `Signer` and `Signature` with the Facilitator, and
congrats, you are done!


## Execute the output

1. Collect outputs from all participating signers.
2. Concatenate all signatures and export it as the `SIGNATURES`
environment variable, i.e. `export
SIGNATURES="0x[SIGNATURE1][SIGNATURE2]..."`.
3. Run `make execute`
20 changes: 20 additions & 0 deletions mainnet/2024-07-24-reduce-batcher-proposer-balance-targets/foundry.toml
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
[profile.default]
src = 'src'
out = 'out'
libs = ['lib']
broadcast = 'records'
fs_permissions = [ {access = "read-write", path = "./"} ]
optimizer = true
optimizer_runs = 999999
solc_version = "0.8.15"
via-ir = true
remappings = [
'@eth-optimism-bedrock/=lib/optimism/packages/contracts-bedrock/',
'@openzeppelin/contracts/=lib/openzeppelin-contracts/contracts',
'@openzeppelin/contracts-upgradeable/=lib/openzeppelin-contracts-upgradeable/contracts',
'@rari-capital/solmate/=lib/solmate/',
'@base-contracts/=lib/base-contracts',
'solady/=lib/solady/src/'
]

# See more config options https://github.com/foundry-rs/foundry/tree/master/config
Loading

0 comments on commit ebb6d7c

Please sign in to comment.