Merge pull request #768 from matter-labs/kl/sync-layer-reorg

feat: multiple fixes - Kl/sync layer reorg

.github/workflows/l1-contracts-ci.yaml

@@ -113,6 +113,57 @@ jobs:
         working-directory: ./l1-contracts
         run: FOUNDRY_PROFILE=default yarn test:foundry
 
+  test-foundry-zksync:
+    needs: [build, lint]
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout the repository
+        uses: actions/checkout@v4
+        with:
+          submodules: recursive
+
+      - name: Use Node.js
+        uses: actions/setup-node@v3
+        with:
+          node-version: 18.18.0
+          cache: yarn
+
+      - name: Install dependencies
+        run: yarn
+
+      - name: Build system contract artifacts
+        run: yarn sc build
+
+      - name: Restore artifacts cache
+        uses: actions/cache/restore@v3
+        with:
+          fail-on-cache-miss: true
+          key: artifacts-l1-${{ github.sha }}
+          path: |
+            l1-contracts/artifacts
+            l1-contracts/artifacts-zk
+            l1-contracts/cache
+            l1-contracts/typechain
+            l2-contracts/artifacts-zk
+            l2-contracts/cache-zk
+            l2-contracts/typechain
+            l1-contracts/lib
+
+      - name: Install foundry zksync
+        run: |
+          wget https://github.com/matter-labs/foundry-zksync/releases/download/nightly-f908ce43834bc1ffb4de6576ea5600eaab49dddb/foundry_nightly_linux_amd64.tar.gz -O foundry-zksync.tar.gz
+          tar -xzf foundry-zksync.tar.gz
+          sudo mv forge /usr/local/bin/forge
+          sudo mv cast /usr/local/bin/cast
+          sudo chmod +x /usr/local/bin/forge
+          sudo chmod +x /usr/local/bin/cast
+          forge --version
+
+      - name: Run tests
+        working-directory: ./l1-contracts
+        run: FOUNDRY_PROFILE=default yarn test:zkfoundry
+
   test-hardhat:
     needs: [build, lint]
     runs-on: ubuntu-latest

.github/workflows/l1-contracts-foundry-ci.yaml

@@ -88,7 +88,7 @@ jobs:
 
       - name: Copy configs from template
         working-directory: ./l1-contracts
-        run: cp -r deploy-script-config-template script-config
+        run: cp -r deploy-script-config-template/. script-config
 
       - name: Run anvil
         run: |
@@ -119,11 +119,11 @@ jobs:
         working-directory: ./l1-contracts
         run: forge script ./deploy-scripts/DeployErc20.s.sol --ffi --rpc-url $ANVIL_RPC_URL --broadcast --private-key $ANVIL_PRIVATE_KEY
 # TODO restore scripts verification
-#      - name: Run RegisterHyperchain script
+#      - name: Run RegisterZKChain script
 #        working-directory: ./l1-contracts
 #        run: |
-#          cat ./script-out/output-deploy-l1.toml >> ./script-config/register-hyperchain.toml
-#          forge script ./deploy-scripts/RegisterHyperchain.s.sol --ffi --rpc-url $ANVIL_RPC_URL --broadcast --private-key $ANVIL_PRIVATE_KEY
+#          cat ./script-out/output-deploy-l1.toml >> ./script-config/register-zk-chain.toml
+#          forge script ./deploy-scripts/RegisterZKChain.s.sol --ffi --rpc-url $ANVIL_RPC_URL --broadcast --private-key $ANVIL_PRIVATE_KEY
 #      - name: Run InitializeL2WethToken script
 #        working-directory: ./l1-contracts-foundry
 #        run: forge script ./deploy-scripts/InitializeL2WethToken.s.sol --ffi --rpc-url $ANVIL_RPC_URL --broadcast --private-key $ANVIL_PRIVATE_KEY

.gitignore

@@ -22,9 +22,13 @@ l1-contracts/lcov.info
 l1-contracts/report/*
 l1-contracts/coverage/*
 l1-contracts/out/*
+l1-contracts/zkout/*
 l1-contracts/broadcast/*
 l1-contracts/script-config/*
+!l1-contracts/script-config/artifacts
 l1-contracts/script-out/*
-l1-contracts/test/foundry/integration/deploy-scripts/script-out/*.toml
+l1-contracts/test/foundry/l1/integration/deploy-scripts/script-out/*.toml
 !l1-contracts/script-out/.gitkeep
 *.timestamp
+l1-contracts/test/foundry/l1/integration/deploy-scripts/script-out/*
+l1-contracts/zkout/*

.solhintignore

@@ -8,6 +8,7 @@ l1-contracts/lib
 l1-contracts/node_modules
 l1-contracts/contracts/dev-contracts
 l1-contracts/test
+l1-contracts/deploy-scripts
 
 # l1-contracts-foundry
 l1-contracts-foundry/cache

CONTRIBUTING.md

@@ -34,7 +34,7 @@ We aim to make it as easy as possible to contribute to the mission. This is stil
 and suggestions here too. Some resources to help:
 
 1. [In-repo docs aimed at developers](docs)
-2. [zkSync Era docs!](https://era.zksync.io/docs/)
+2. [ZKsync Era docs!](https://era.zksync.io/docs/)
 3. Company links can be found in the [repo's readme](README.md)
 
 ## Code of Conduct

README.md

@@ -1,13 +1,13 @@
-# zkSync Era: Smart Contracts
+# ZKsync Era: Smart Contracts
 
 [![Logo](eraLogo.svg)](https://zksync.io/)
 
-zkSync Era is a layer 2 rollup that uses zero-knowledge proofs to scale Ethereum without compromising on security or
+ZKsync Era is a layer 2 rollup that uses zero-knowledge proofs to scale Ethereum without compromising on security or
 decentralization. Since it's EVM compatible (Solidity/Vyper), 99% of Ethereum projects can redeploy without refactoring
-or re-auditing a single line of code. zkSync Era also uses an LLVM-based compiler that will eventually let developers
+or re-auditing a single line of code. ZKsync Era also uses an LLVM-based compiler that will eventually let developers
 write smart contracts in C++, Rust and other popular languages.
 
-This repository contains both L1 and L2 zkSync smart contracts. For their description see the
+This repository contains both L1 and L2 ZKsync smart contracts. For their description see the
 [system overview](docs/Overview.md).
 
 ## Disclaimer
@@ -17,7 +17,7 @@ others may not.
 
 ## License
 
-zkSync Era contracts are distributed under the terms of the MIT license.
+ZKsync Era contracts are distributed under the terms of the MIT license.
 
 See [LICENSE-MIT](LICENSE-MIT) for details.
 
@@ -33,7 +33,7 @@ See [LICENSE-MIT](LICENSE-MIT) for details.
 
 ## Disclaimer
 
-zkSync Era has been through lots of testing and audits. Although it is live, it is still in alpha state and will go
+ZKsync Era has been through lots of testing and audits. Although it is live, it is still in alpha state and will go
 through more audits and bug bounties programs. We would love to hear our community's thoughts and suggestions about it!
 It is important to state that forking it now can potentially lead to missing important security updates, critical
 features, and performance improvements.

docs/Overview.md

@@ -1,6 +1,6 @@
 # Overview
 
-zkSync Era is a permissionless general-purpose ZK rollup. Similar to many L1 blockchains and sidechains it enables
+ZKsync Era is a permissionless general-purpose ZK rollup. Similar to many L1 blockchains and sidechains it enables
 deployment and interaction with Turing-complete smart contracts.
 
 - L2 smart contracts are executed on a zkEVM.
@@ -10,7 +10,7 @@ deployment and interaction with Turing-complete smart contracts.
 - There is no escape hatch mechanism yet, but there will be one.
 
 All data that is needed to restore the L2 state are also pushed on-chain. There are two approaches, publishing inputs of
-L2 transactions on-chain and publishing the state transition diff. zkSync follows the second option.
+L2 transactions on-chain and publishing the state transition diff. ZKsync follows the second option.
 
 See the [documentation](https://era.zksync.io/docs/dev/fundamentals/rollups.html) to read more!
 
@@ -25,13 +25,13 @@ See the [documentation](https://era.zksync.io/docs/dev/fundamentals/rollups.html
   L2 blocks.
 - **Facet** - implementation contract. The word comes from the EIP-2535.
 - **Gas** - a unit that measures the amount of computational effort required to execute specific operations on the
-  zkSync Era network.
+  ZKsync Era network.
 
 ### L1 Smart contracts
 
 #### Diamond
 
-Technically, this L1 smart contract acts as a connector between Ethereum (L1) and zkSync (L2). This contract checks the
+Technically, this L1 smart contract acts as a connector between Ethereum (L1) and ZKsync (L2). This contract checks the
 validity proof and data availability, handles L2 <-> L1 communication, finalizes L2 state transition, and more.
 
 There are also important contracts deployed on the L2 that can also execute logic called _system contracts_. Using L2
@@ -73,7 +73,7 @@ execution of upgrades in the diamond proxy.
 
 This contract manages operations (calls with preconditions) for governance tasks. The contract allows for operations to
 be scheduled, executed, and canceled with appropriate permissions and delays. It is used for managing and coordinating
-upgrades and changes in all zkSync Era governed contracts.
+upgrades and changes in all ZKsync Era governed contracts.
 
 Each upgrade consists of two steps:
 
@@ -122,8 +122,8 @@ function applyL1ToL2Alias(address l1Address) internal pure returns (address l2Ad
 ```
 
 For most of the rollups the address aliasing needs to prevent cross-chain exploits that would otherwise be possible if
-we simply reused the same L1 addresses as the L2 sender. In zkSync Era address derivation rule is different from the
-Ethereum, so cross-chain exploits are already impossible. However, zkSync Era may add full EVM support in the future, so
+we simply reused the same L1 addresses as the L2 sender. In ZKsync Era address derivation rule is different from the
+Ethereum, so cross-chain exploits are already impossible. However, ZKsync Era may add full EVM support in the future, so
 applying address aliasing leave room for future EVM compatibility.
 
 The L1 -> L2 communication is also used for bridging ether. The user should include a `msg.value` when initiating a
@@ -157,7 +157,7 @@ this trick:
 #### L1 -> L2 Transaction filtering
 
 There is a mechanism for applying custom filters to the L1 -> L2 communication. It is achieved by having an address of
-the `TransactionFilterer` contract in the `ZkSyncHyperchainStorage`. If the filterer exists, it is being called in
+the `TransactionFilterer` contract in the `ZkSyncZKChainStorage`. If the filterer exists, it is being called in
 the `Mailbox` facet with the tx details and has to return whether the transaction can be executed or not. The filterer
 has to implement the `ITransactionFilterer` interface. The ones intended to use this feature, have to deploy the
 contract that implements `ITransactionFilterer` and use `setTransactionFilterer` function of `AdminFacet` to set the
@@ -178,12 +178,12 @@ Each L2 -> L1 system log will have a key that is part of the following:
 ```solidity
 enum SystemLogKey {
   L2_TO_L1_LOGS_TREE_ROOT_KEY,
-  TOTAL_L2_TO_L1_PUBDATA_KEY,
-  STATE_DIFF_HASH_KEY,
   PACKED_BATCH_AND_L2_BLOCK_TIMESTAMP_KEY,
   PREV_BATCH_HASH_KEY,
   CHAINED_PRIORITY_TXN_HASH_KEY,
   NUMBER_OF_LAYER_1_TXS_KEY,
+  L2_DA_VALIDATOR_OUTPUT_HASH_KEY,
+  USED_L2_DA_VALIDATOR_ADDRESS_KEY,
   EXPECTED_SYSTEM_CONTRACT_UPGRADE_TX_HASH_KEY
 }
 ```
@@ -253,8 +253,8 @@ the L1 recipient.
 
 #### ValidatorTimelock
 
-An intermediate smart contract between the validator EOA account and the zkSync smart contract. Its primary purpose is
-to provide a trustless means of delaying batch execution without modifying the main zkSync contract. zkSync actively
+An intermediate smart contract between the validator EOA account and the ZKsync smart contract. Its primary purpose is
+to provide a trustless means of delaying batch execution without modifying the main ZKsync contract. ZKsync actively
 monitors the chain activity and reacts to any suspicious activity by freezing the chain. This allows time for
 investigation and mitigation before resuming normal operations.
 
@@ -264,12 +264,12 @@ the Alpha stage.
 This contract consists of four main functions `commitBatches`, `proveBatches`, `executeBatches`, and `revertBatches`,
 that can be called only by the validator.
 
-When the validator calls `commitBatches`, the same calldata will be propagated to the zkSync contract (`DiamondProxy`
+When the validator calls `commitBatches`, the same calldata will be propagated to the ZKsync contract (`DiamondProxy`
 through `call` where it invokes the `ExecutorFacet` through `delegatecall`), and also a timestamp is assigned to these
 batches to track the time these batches are committed by the validator to enforce a delay between committing and
 execution of batches. Then, the validator can prove the already committed batches regardless of the mentioned timestamp,
-and again the same calldata (related to the `proveBatches` function) will be propagated to the zkSync contract. After,
-the `delay` is elapsed, the validator is allowed to call `executeBatches` to propagate the same calldata to zkSync
+and again the same calldata (related to the `proveBatches` function) will be propagated to the ZKsync contract. After,
+the `delay` is elapsed, the validator is allowed to call `executeBatches` to propagate the same calldata to ZKsync
 contract.
 
 ### L2 specifics

docs/gateway/chain-migration.md

@@ -2,11 +2,11 @@
 
 Chain migration uses the Custom Asset Bridging framework:
 
-- STMs can be deployed on the Gateway. Each STM has its own assetId.
-- The STM Deployment Tracker deployed on L1 registers assetId in the L1 and L2 AssetRouters, with the Bridgehub as the AssetHandler. It also registers the L1 and L2 STM contracts to be associated to the assetId in the Bridgehubs.
-- Bridging of a chain happens via the Bridgehub, AssetRouters, and STM.
+- CTMs can be deployed on the Gateway. Each CTM has its own assetId.
+- The CTM Deployment Tracker deployed on L1 registers assetId in the L1 and L2 AssetRouters, with the Bridgehub as the AssetHandler. It also registers the L1 and L2 CTM contracts to be associated to the assetId in the Bridgehubs.
+- Bridging of a chain happens via the Bridgehub, AssetRouters, and CTM.
 
-![STM assetId registration](./chain-asset-id-registration.png)
+![CTM assetId registration](./chain-asset-id-registration.png)
 _Note these are separate calls_
 
 ![Chain migration](./chain-migration.png)

docs/gateway/contracts-review-gateway.md

@@ -10,7 +10,7 @@ List of changes and new features:
 - Custom Data Availability contracts. This is needed to handle the relayed data availability on the Gateway.
 - L1 -> Gateway -> ZKChain transactions. This is done by forwarding transactions to Chain's Mailbox on the Gateway via the Gateway's Mailbox.
 - ZKChain -> Gateway -> L1 transactions. This is done by aggregating the logs of different chains in the MessageRoot contract, and sending a single log to L1.
-- Migration of chains to and from the Gateway. This is done using our Custom Asset Bridging framework, each STM has an assetId and is managed by a shared STMDeploymentTracker, the L2AssetRouter = L2SharedBridge is deployed on the Gateway, but only holds the chains as assets, with the Bridgehub as the AssetHandler.
+- Migration of chains to and from the Gateway. This is done using our Custom Asset Bridging framework, each CTM has an assetId and is managed by a shared CTMDeploymentTracker, the L2AssetRouter = L2SharedBridge is deployed on the Gateway, but only holds the chains as assets, with the Bridgehub as the AssetHandler.
 
 Other smaller changes:
 
@@ -29,7 +29,7 @@ Known issues, and features that still need to be implemented:
 - Bridgehub setAssetHandlerAddress `address sender` might be an issue.
 - MessageRoot should be renamed to MessageRootAggregator
 
-![Untitled](./Hyperchain-scheme.png)
+![Untitled](./ZKChain-scheme.png)
 
 ## Initial Scope
 
@@ -56,13 +56,13 @@ Known issues, and features that still need to be implemented:
 The majority of the rest of the changes. This makes the scope quite big, so please focus on the initial scope in more detail, and if you have time include the later scope.
 
 - MessageRoot.sol
-- STMDeploymentTracker.sol
+- CTMDeploymentTracker.sol
 - Bridgehub.sol
 - Config.sol
 - L2ContractAddresses.sol
-- StateTransitionManager.sol
+- ChainTypeManager.sol
 - ValidatorTimelock.sol
 - DiamondInit.sol
-- ZkSyncHyperchainStorage.sol
+- ZKChainStorage.sol
 - Admin.sol
 - L1GenesisUpgrade.sol

gas-bound-caller/README.md

@@ -46,4 +46,4 @@ Since `GasBoundCaller` would be the contract that calls the `_to` contract, the
 
 It should be deployed via a built-in CREATE2 factory on each individual chain.
 
-The current address on both sepolia testnet and mainnet for zkSync Era is `0xc706EC7dfA5D4Dc87f29f859094165E8290530f5`.
+The current address on both sepolia testnet and mainnet for ZKsync Era is `0xc706EC7dfA5D4Dc87f29f859094165E8290530f5`.

gas-bound-caller/package.json

@@ -14,7 +14,8 @@
     "ethers": "^5.7.0",
     "fast-glob": "^3.3.2",
     "hardhat": "=2.22.2",
-    "preprocess": "^3.2.0"
+    "preprocess": "^3.2.0",
+    "zksync-ethers": "^5.9.0"
   },
   "devDependencies": {
     "@matterlabs/hardhat-zksync-chai-matchers": "^0.2.0",
@@ -56,7 +57,7 @@
     "test-node": "hardhat node-zksync --tag v0.0.1-vm1.5.0",
     "check-canonical-bytecode": "ts-node ./scripts/check-canonical-bytecode.ts",
     "verify": "hardhat run scripts/verify.ts",
-    "deploy-on-hyperchain": "ts-node ./scripts/deploy-on-hyperchain.ts",
+    "deploy-on-zk-chain": "ts-node ./scripts/deploy-on-zk-chain.ts",
     "deploy-on-localhost": "hardhat deploy --network localhost"
   }
 }

gas-bound-caller/scripts/deploy-on-hyperchain.ts

@@ -44,8 +44,8 @@ async function main() {
 
   program
     .version("0.1.0")
-    .name("Deploy on hyperchain")
-    .description("Deploys the GasBoundCaller on a predetermined Hyperchain network")
+    .name("Deploy on ZK chain")
+    .description("Deploys the GasBoundCaller on a predetermined ZK chain network")
     .option("--private-key <private-key>")
     .option("--l2Rpc <l2Rpc>")
     .action(async (cmd) => {

l1-contracts/.env

@@ -24,19 +24,23 @@ CONTRACTS_TRANSPARENT_PROXY_ADMIN_ADDR=0x000000000000000000000000000000000000000
 CONTRACTS_GOVERNANCE_ADDR=0x0000000000000000000000000000000000000000
 CONTRACTS_L1_ERC20_BRIDGE_IMPL_ADDR=0x0000000000000000000000000000000000000000
 CONTRACTS_L1_ERC20_BRIDGE_PROXY_ADDR=0x0000000000000000000000000000000000000000
+CONTRACTS_L1_NULLIFIER_IMPL_ADDR=0x0000000000000000000000000000000000000000
+CONTRACTS_L1_NULLIFIER_PROXY_ADDR=0x0000000000000000000000000000000000000000
 CONTRACTS_L1_SHARED_BRIDGE_IMPL_ADDR=0x0000000000000000000000000000000000000000
 CONTRACTS_L1_SHARED_BRIDGE_PROXY_ADDR=0x0000000000000000000000000000000000000000
+CONTRACTS_L1_BRIDGED_STANDARD_ERC20_IMPL_ADDR=0x0000000000000000000000000000000000000000
+CONTRACTS_L1_BRIDGED_TOKEN_BEACON_ADDR=0x0000000000000000000000000000000000000000
 CONTRACTS_L1_ALLOW_LIST_ADDR=0x0000000000000000000000000000000000000000
 CONTRACTS_CREATE2_FACTORY_ADDR=0x0000000000000000000000000000000000000000
 CONTRACTS_VALIDATOR_TIMELOCK_ADDR=0x0000000000000000000000000000000000000000
 CONTRACTS_VALIDATOR_TIMELOCK_EXECUTION_DELAY=0
 ETH_SENDER_SENDER_OPERATOR_COMMIT_ETH_ADDR=0x0000000000000000000000000000000000000000
 ETH_SENDER_SENDER_OPERATOR_BLOBS_ETH_ADDR=0x0000000000000000000000000000000000000001
 CONTRACTS_SHARED_BRIDGE_UPGRADE_STORAGE_SWITCH=0
-CONTRACTS_MAX_NUMBER_OF_HYPERCHAINS=100
+CONTRACTS_MAX_NUMBER_OF_ZK_CHAINS=100
 L1_CONFIG=/script-config/config-deploy-l1.toml
 L1_OUTPUT=/script-out/output-deploy-l1.toml
 TOKENS_CONFIG=/script-config/config-deploy-erc20.toml
-HYPERCHAIN_CONFIG=/script-config/register-hyperchain.toml
-HYPERCHAIN_OUTPUT=/script-out/output-deploy-hyperchain-era.toml
+ZK_CHAIN_CONFIG=/script-config/register-zk-chain.toml
+ZK_CHAIN_OUTPUT=/script-out/output-deploy-zk-chain-era.toml
 FORCE_DEPLOYMENTS_CONFIG=/script-config/generate-force-deployments-data.toml

l1-contracts/README.md

@@ -1,10 +1,10 @@
-# zkSync Era: L1 Contracts
+# ZKsync Era: L1 Contracts
 
 [![Logo](../eraLogo.svg)](https://zksync.io/)
 
-zkSync Era is a layer 2 rollup that uses zero-knowledge proofs to scale Ethereum without compromising on security or
+ZKsync Era is a layer 2 rollup that uses zero-knowledge proofs to scale Ethereum without compromising on security or
 decentralization. Since it's EVM compatible (Solidity/Vyper), 99% of Ethereum projects can redeploy without refactoring
-or re-auditing a single line of code. zkSync Era also uses an LLVM-based compiler that will eventually let developers
+or re-auditing a single line of code. ZKsync Era also uses an LLVM-based compiler that will eventually let developers
 write smart contracts in C++, Rust and other popular languages.
 
 ## L1 Contracts