-
Notifications
You must be signed in to change notification settings - Fork 2.2k
docs: migrate docs from era-contracts #4579
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
base: main
Are you sure you want to change the base?
Conversation
zkzoomer
left a comment
There was a problem hiding this 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) |
There was a problem hiding this comment.
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. | |||
There was a problem hiding this comment.
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.
| 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: | ||
|
|
||
|  |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is missing:
|  | |
|  | |
|  |
| 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 |
There was a problem hiding this comment.
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
| 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 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. |
| 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 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). |
There was a problem hiding this comment.
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 | |||
There was a problem hiding this comment.
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?
What ❔
There was still some documentation present in
era-contractsrepository.We want to contain all of the documentation in
zksync-erarepository, 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-contractsis here.Why ❔
Is this a breaking change?
Operational changes
Checklist
zkstack dev fmtandzkstack dev lint.