Skip to content

Conversation

@0xValera
Copy link
Contributor

@0xValera 0xValera commented Nov 27, 2025

What ❔

There was still some documentation present in era-contracts repository.

We want to contain all of the documentation in zksync-era repository, so in this PR the missing pieces that were present there but not here are being moved, and some small refactoring/fixes are being applied.

The respective PR in era-contracts is here.

Why ❔

Is this a breaking change?

  • Yes
  • No

Operational changes

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.
  • Code has been formatted via zkstack dev fmt and zkstack dev lint.

Copy link
Member

@zkzoomer zkzoomer left a comment

Choose a reason for hiding this comment

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

Looks good overall, just some suggestions. The dead links CI from era-contracts should also be added in as a new workflow.

- [Precompiles](../contracts/zkevm/precompiles.md)
- [Account abstraction](../contracts/zkevm/account_abstraction.md)
- [Fee model](../contracts/zkevm/zksync_fee_model.md)
- [EVM Emulation](../contracts/evm_emulation/technical_overview.md)
Copy link
Member

Choose a reason for hiding this comment

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

This file mentions "L3" which I was told was a big no-no. Not sure if it should be changed

@@ -0,0 +1,18 @@
# EVM predeploys

Some important EVM contracts can be deployed to predefined addresses if EVM emulation is enabled on the chain. It can be done using [DeployEvmPredeploys.s.sol](https://github.com/matter-labs/era-contracts/blob/8222265420f362c853da7160769620d9fed7f834/l1-contracts/deploy-scripts/evm-predeploys/DeployEvmPredeploys.s.sol) script.
Copy link
Member

Choose a reason for hiding this comment

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

We might want to point to the main branch which contains the most up to date changes in the (unlikely) case the script is modified. If the link breaks because the script is moved elsewhere, the dead links CI should catch it.

Suggested change
Some important EVM contracts can be deployed to predefined addresses if EVM emulation is enabled on the chain. It can be done using [DeployEvmPredeploys.s.sol](https://github.com/matter-labs/era-contracts/blob/8222265420f362c853da7160769620d9fed7f834/l1-contracts/deploy-scripts/evm-predeploys/DeployEvmPredeploys.s.sol) script.
Some important EVM contracts can be deployed to predefined addresses if EVM emulation is enabled on the chain. It can be done using [DeployEvmPredeploys.s.sol](https://github.com/matter-labs/era-contracts/tree/main/l1-contracts/deploy-scripts/evm-predeploys/DeployEvmPredeploys.s.sol) script.

This document assumes that the reader is already aware of how [L2→L1 logs](../settlement_contracts/priority_queue/l1_l2_communication/l2_to_l1.md) are aggregated into the [MessageRoot](../interop/message_root.md) and what the [Gateway](../gateway/overview.md) is. To reduce interactions with L1, the Gateway gathers all the `ChainBatchRoot`s from all the chains into the tree with following structure:
This document assumes that the reader is already aware of what SyncLayer (or how it is now called Gateway) is. To reduce the interactions with L1, on SyncLayer we will gather all the batch roots from all the chains into the tree with following structure:

![NestedL2GWL1Messaging.png](./img/nested_l2_gw_l1_messaging.png)
Copy link
Member

Choose a reason for hiding this comment

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

This file is missing:

Suggested change
![NestedL2GWL1Messaging.png](./img/nested_l2_gw_l1_messaging.png)
![NestedL2GWL1Messaging.png](./img/nested_l2_gw_l1_messaging.png)
![NestedL2GWL1Messaging.png](./img/nested_l2_gw_l1_messaging_2.png)

The execution delay is dynamically read from the contract's `executionDelay()` function by the node, eliminating the need for manual configuration management.

The owner of the ValidatorTimelock contract is the decentralized governance. Note, that all the chains share the same ValidatorTimelock for simplicity.
# Settlement Contracts
Copy link
Member

Choose a reason for hiding this comment

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

I think this file is missing

Comment on lines +5 to +6
The V27 upgrade happened after the gateway preparation upgrade, but before the gateway was deployed. As such the upgrade
process did not involve the Gateway parts (upgrading the CTM on GW, etc), it was an L1-only upgrade.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
The V27 upgrade happened after the gateway preparation upgrade, but before the gateway was deployed. As such the upgrade
process did not involve the Gateway parts (upgrading the CTM on GW, etc), it was an L1-only upgrade.
The V27 upgrade happened after the gateway preparation upgrade, but before the gateway was deployed. As such the upgrade process did not involve the Gateway parts (upgrading the CTM on GW, etc), it was an L1-only upgrade.

Comment on lines +8 to +10
Additionally this was not a bridge upgrade, as the bridge and ecosystem contracts didn't have new features, so L1<>L2
bridging was not affected. This meant that only the system components, the Verifiers, Facets and L2 contracts needed to
be upgraded.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
Additionally this was not a bridge upgrade, as the bridge and ecosystem contracts didn't have new features, so L1<>L2
bridging was not affected. This meant that only the system components, the Verifiers, Facets and L2 contracts needed to
be upgraded.
Additionally this was not a bridge upgrade, as the bridge and ecosystem contracts didn't have new features, so L1<>L2 bridging was not affected. This meant that only the system components, the Verifiers, Facets and L2 contracts needed to be upgraded.

## Structure of the pubdata

Rollups maintain the same structure of pubdata and apply the same rules for compression as those that were used in the previous versions of the system. These can be read [here](./state_diff_compression_v1_spec.md).
Rollups maintain the same structure of pubdata and apply the same rules for compression as those that were used in the previous versions of the system. These can be read [here](./compression.md).
Copy link
Member

Choose a reason for hiding this comment

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

This file differs a lot from the analogous one that was removed in the contracts PR

@@ -1,3 +0,0 @@
# Consensus
Copy link
Member

Choose a reason for hiding this comment

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

I'm guessing these docs were removed as consensus was deprioritized, but not sure if we want to get rid of them completely?

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