Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Chain registrar #1064

Open
wants to merge 14 commits into
base: release-v25-protocol-defense
Choose a base branch
from

Conversation

Deniallugo
Copy link
Contributor

@Deniallugo Deniallugo commented Nov 14, 2024

What ❔

Add Chain registrar contracts, that allow partners to register their chains and then configure their chain from L1

Why ❔

For making our registration process a bit more transparent and later on make it even easier

Checklist

  • PR title corresponds to the body of PR (we generate changelog entries from PRs).
  • Tests for the changes have been added / updated.
  • Documentation comments have been added / updated.

Copy link

Coverage after merging deniallugo-chain-registrator into release-v25-protocol-defense will be

85.95%

Coverage Report
FileStmtsBranchesFuncsLinesUncovered Lines
contracts/bridge
   L1ERC20Bridge.sol81.82%80%75%83.87%62, 70, 70–71, 73–74
   L1SharedBridge.sol79.59%66.23%84.21%83.41%101–102, 109–110, 117–118, 125, 125–126, 133, 177, 190–191, 199–200, 212–213, 215–216, 227, 227, 227–231, 231–232, 234, 239–241, 241–242, 244–246, 246–247, 249, 261, 270, 270–271, 279–280, 290, 444–445, 447–448, 579–580, 596–597, 607–608, 623–624, 720–721, 962, 967
contracts/bridgehub
   Bridgehub.sol89.29%74.07%100%91.49%100–101, 112–113, 132–133, 155–156, 158–159, 332–333, 49, 63–64
contracts/chain-registrar
   ChainRegistrar.sol48.08%11.11%50%56.76%103–104, 106, 106–107, 114–115, 119–120, 126–127, 130, 130–131, 134–135, 139, 142–143, 68–70, 98–99
contracts/common
   ReentrancyGuard.sol90%66.67%100%92.86%78–79
contracts/common/libraries
   L2ContractHelper.sol42.86%0%50%52.63%25–26, 31–32, 35–36, 50, 52, 52–53, 57, 57–58, 66
   SemVer.sol100%100%100%100%
   UncheckedMath.sol100%100%100%100%
   UnsafeBytes.sol100%100%100%100%
contracts/governance
   ChainAdmin.sol0%0%0%0%27, 27–28, 30, 32–33, 39–40, 47–48, 56, 56–57, 60, 62–63, 63, 66, 69, 78, 78–79, 81
   Governance.sol91.67%94.74%95%89.86%44, 44–45, 48, 50–51, 53–54
contracts/state-transition
   StateTransitionManager.sol59.48%35.71%50%65.42%101, 106–110, 116, 149–150, 152–153, 155–156, 158–159, 201, 203–204, 209, 211, 211–212, 215–217, 219–220, 255, 275, 289, 294, 299, 304, 309, 314, 319, 386, 386–387, 390, 455–456, 79, 92, 92–93
   TestnetVerifier.sol44.44%33.33%50%50%16, 16, 16, 32
   ValidatorTimelock.sol95.89%83.33%100%95.83%241, 82–83
   Verifier.sol89.88%35.71%96.30%90.93%1673–1674, 287–302, 305–308, 311–318, 321–328, 331–332, 335–336, 339, 384–385, 395–396, 406–407, 417–418, 428–429, 444–445, 454, 454–455, 904–905
contracts/state-transition/chain-deps
   DiamondInit.sol77.55%45.45%100%86.11%34–35, 37–38, 40–41, 43–44, 46–47, 71
   DiamondProxy.sol92.31%75%100%100%16, 27
contracts/state-transition/chain-deps/facets
   Admin.sol86.21%72.73%92.31%87.30%109, 109–110, 112–113, 178, 180, 83–84, 94–95
   Executor.sol82.04%63.41%84.38%87.90%137–138, 192, 197, 202, 207, 212, 217, 222, 227, 230–231, 235–236, 240–242, 244–245, 260–261, 280, 294–295, 361–362, 425, 447–449, 469, 48, 48–49, 519–520, 528–529, 549, 556–557, 57, 59, 59–60, 619, 62, 620, 63, 646–647, 696–697, 70, 700–701, 71, 74–75, 775
   Getters.sol92.08%100%90.24%93.10%153, 206, 72, 77
   Mailbox.sol100%100%100%100%
   ZkSyncHyperchainBase.sol92.86%85.71%100%92.86%55–56
contracts/state-transition/libraries
   Diamond.sol93.33%80.77%100%95.96%109–110, 113, 115, 117, 120, 198–199, 316
   LibMap.sol100%100%100%100%
   Merkle.sol100%100%100%100%
   PriorityQueue.sol100%100%100%100%
   TransactionValidator.sol94.44%88.24%100%96%66–67, 69–70
contracts/upgrades
   BaseZkSyncUpgrade.sol58.20%27.27%100%60.23%104, 104–105, 108, 111, 114–115, 126, 126–127, 130, 133, 136–137, 151–153, 171–173, 212–213, 215, 215–216, 232–233, 249–250, 252–253, 258–259, 259–260, 271–272, 278–279, 285–286, 293–294, 298–299, 308–309, 311–312, 75–76
   BaseZkSyncUpgradeGenesis.sol56.67%14.29%100%68.18%25, 25–26, 33–34, 40–41, 52–53, 62–63, 65–66
   DefaultUpgrade.sol100%100%100%100%
   GenesisUpgrade.sol100%100%100%100%
contracts/vendor
   AddressAliasHelper.sol100%100%100%100%

@Deniallugo Deniallugo force-pushed the deniallugo-chain-registrator branch 2 times, most recently from 8b32b48 to 65c9acb Compare November 14, 2024 13:24
Signed-off-by: Danil <[email protected]>
Copy link

@sanekmelnikov sanekmelnikov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

have a feeling that will improve UX by x2 :)

l1-contracts/contracts/chain-registrar/ChainRegistrar.sol Outdated Show resolved Hide resolved
l1-contracts/contracts/chain-registrar/ChainRegistrar.sol Outdated Show resolved Hide resolved
// require(success);
// address chainAdmin = bytesToAddress(returnData);
address chainAdmin = IGetters(diamondProxy).getAdmin();
address l2BridgeAddress = bridgehub.sharedBridge().l2BridgeAddress(chainId);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, you can do that without specifying class?
IL1SharedBridge(bridgehub.sharedBridge()).l2BridgeAddress(chainId);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we can. Because it's already specified.

Comment on lines 151 to 152
emit NewChainDeployed(chainId, diamondProxy, author, chainAdmin);
emit SharedBridgeRegistered(chainId, l2BridgeAddress);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If these are always emitted together - any point of not putting l2BridgeAddress into NewChainDeployed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking about it, but for the future those events, will be most likely independent. because it's two different actions and for not breaking the future interface I think it's better to make it like this from the very beginning

l1-contracts/contracts/chain-registrar/ChainRegistrar.sol Outdated Show resolved Hide resolved
// (bool success, bytes memory returnData) = diamondProxy.call(abi.encodeWithSelector(IGetters.getAdmin.selector));
// require(success);
// address chainAdmin = bytesToAddress(returnData);
address chainAdmin = IGetters(diamondProxy).getAdmin();

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just as alternative:
address chainAdmin = IStateTransitionManager(stm).getChainAdmin(chainId);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we need pendingAdmin... and IGetter is the only way

l1-contracts/deploy-scripts/DeployL2Contracts.sol Outdated Show resolved Hide resolved
l1-contracts/deploy-scripts/RegisterHyperchain.s.sol Outdated Show resolved Hide resolved
baseToken: BaseToken({
tokenAddress: tokenAddress,
tokenMultiplierSetter: tokenMultiplierSetter,
gasPriceMultiplierNominator: gasPriceMultiplierNominator,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe adding more validations on gasPriceMultiplierNominator, I'd say at min check both values are 1, 1 if base token is ETH

uint128 gasPriceMultiplierNominator,
uint128 gasPriceMultiplierDenominator
) public {
ChainConfig memory config = ChainConfig({

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we also think about returning base token once the registration is done ? :D
idk, if it makes sense to keep author there...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, we need some token to operate on chain in the future

revert ChainIsNotYetDeployed();
}
address diamondProxy = IStateTransitionManager(stm).getHyperchain(chainId);
(bool success, bytes memory returnData) = diamondProxy.call(abi.encodeWithSelector(IGetters.getAdmin.selector));
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for some reasons only this way correctly work with tests, meanwhile all selectors are identical

Comment on lines 151 to 152
emit NewChainDeployed(chainId, diamondProxy, author, chainAdmin);
emit SharedBridgeRegistered(chainId, l2BridgeAddress);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking about it, but for the future those events, will be most likely independent. because it's two different actions and for not breaking the future interface I think it's better to make it like this from the very beginning

uint128 gasPriceMultiplierNominator,
uint128 gasPriceMultiplierDenominator
) public {
ChainConfig memory config = ChainConfig({
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, we need some token to operate on chain in the future

// (bool success, bytes memory returnData) = diamondProxy.call(abi.encodeWithSelector(IGetters.getAdmin.selector));
// require(success);
// address chainAdmin = bytesToAddress(returnData);
address chainAdmin = IGetters(diamondProxy).getAdmin();
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we need pendingAdmin... and IGetter is the only way

// require(success);
// address chainAdmin = bytesToAddress(returnData);
address chainAdmin = IGetters(diamondProxy).getAdmin();
address l2BridgeAddress = bridgehub.sharedBridge().l2BridgeAddress(chainId);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we can. Because it's already specified.

@Deniallugo Deniallugo force-pushed the deniallugo-chain-registrator branch 3 times, most recently from 3883f46 to e10fc7a Compare November 14, 2024 16:18
Signed-off-by: Danil <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants