refactor: uses L2Migration.s.sol and simplifies migration script

[arthurgousset]

Description

1. refactors L2 migration into a forge script (MigrationL2.s.sol for everything that can be done as a transaction) and a bash script (create_and_migrate_anvil_l2_devchain.sh for everything that requires "admin-like" priviledges).
2. removes FROM_ACCOUNT_PRIVATE_KEY constant, which was assigned the anvil default private key that triggered false positives by gitguardian.

Other changes

1. fixes activate method signature in ICeloDistributionSchedule.sol interface.
2. adds DEPLOYER_ACCOUNT constant in constants.sol to avoid redefining the same variable.
3. adds setupUsingRegistry() function to simplify script readability (no new feature, just cleaning up script).

Tested

Tested L2 migration script ✅

$ yarn anvil-devchain:start-L2
# ...
Activating L2 on the devchain...
anvil_setCode
null
✨  Done in 10.90s.

(in a separate terminal) Check that proxyAdminAddress has bytecode ✅

$ cast rpc eth_getCode \
0x4200000000000000000000000000000000000018 \
latest \
--rpc-url=http://127.0.0.1:8546

"0x608060405234801561001057600080fd5b506...

(in a separate terminal) Check that isL2() is true on CeloDistributionSchedule.sol. ✅
For context, we can call isL2() on CeloDistributionSchedule.sol and other core contracts because they inherit from IsL2Check.sol

# Get address of CeloDistributionSchedule
$ cast call \
0x000000000000000000000000000000000000ce10 \
"getAddressForStringOrDie(string calldata identifier)(address)" \
"CeloDistributionSchedule" \
--rpc-url=http://127.0.0.1:8546

0xA16cF67AFa80BB9Ce7a325597F80057c6B290fD4

# Call `isL2()` on `CeloDistributionSchedule.sol`
cast call \
0xA16cF67AFa80BB9Ce7a325597F80057c6B290fD4 \
"isL2()(bool)" \
--rpc-url=http://127.0.0.1:8546
true

Since this is only refactoring and there are no new features, the best test for this is to check if the L2 migrations work as before.

Related issues

• Fixes Replace L2 migration bash script with a Foundry script #11139
• Fixes Refactor Anvil private key out of constants.sh to avoid false positive gitguardian alerts #11172

Backwards compatibility

Yes, no new features, only refactors existing migrations.

Documentation

No.

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
10538986	Triggered	Generic High Entropy Secret	df87e3f	packages/protocol/scripts/foundry/constants.sh	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[martinvol]

you can query this from the current chain in EpochRewards contract

[martinvol]

I think all of them

[arthurgousset]

I managed to fetch communityRewardFraction and carbonOffsettingFraction from the EpochRewards.sol contract. I implemented a new interface for this:

celo-monorepo/packages/protocol/contracts/governance/interfaces/IEpochRewards.sol

Lines 3 to 6 in fe05490

	interface IEpochRewards {
	function getCommunityRewardFraction() external view returns (uint256);
	function getCarbonOffsettingFraction() external view returns (uint256);
	}

But couldn't quite work out how to get the carbonOffsettingPartner address, because it's a public variable, and it doesn't have an explicit getter function. I didn't know exactly how to define that in the interface.

celo-monorepo/packages/protocol/contracts/governance/EpochRewards.sol

Line 70 in fe05490

address public carbonOffsettingPartner;

So for now I left the carbonOffsettingPartner address hard-coded:

celo-monorepo/packages/protocol/migrations_sol/MigrationL2.s.sol

Lines 32 to 34 in fe05490

	uint256 communityRewardFraction = getEpochRewards().getCommunityRewardFraction();
	address carbonOffsettingPartner = 0x22579CA45eE22E2E16dDF72D955D6cf4c767B0eF;
	uint256 carbonOffsettingFraction = getEpochRewards().getCarbonOffsettingFraction();

[martinvol]

you'l have to add the getter to IEpochRewards and implement the function on EpochRewards.

[arthurgousset]

I'm not sure we'll need to implement a getter in EpochRewards.sol, because public state variables like this automatically have getter functions:

celo-monorepo/packages/protocol/contracts/governance/EpochRewards.sol

Line 70 in fe05490

address public carbonOffsettingPartner;

Public state variables differ from internal ones only in that the compiler automatically generates getter functions for them, which allows other contracts to read their values.

Source: docs.soliditylang.org

I couldn't find a way to reference this "automatic" getter in the IEpochRewards.sol interface. Without a matching function in the interface, I wasn't able to call this function. A simple way around this would be to import the implementation (EpochRewards.sol) instead of the interface (IEpochRewards.sol) since we'll have all contracts on Solidity >0.8. I think the only reason I'm using an interface is because the implementation is on 0.5 and the interface is on 0.8.

For now, I propose to merge this hard-coded and then a future PR can implement a fix for this if necessary.

[openzeppelin-code]

refactor: uses L2Migration.s.sol and simplifies migration script

Generated at commit: 9009fe696641f841294c8d0174d3e8e3ebb35d03

🚨 Report Summary

	Severity Level	Results
Contracts	Critical High Medium Low Note Total	2 3 0 15 41 61
Dependencies	Critical High Medium Low Note Total	0 0 0 0 0 0

---

For more details view the full report in OpenZeppelin Code Inspector