| Proposal Type | ZIP |
|---|---|
| One Sentence Summary: | ZIP-13 proposes to add a ZKsync OS based ChainTypeManager (CTM) |
| Proposal Author | Matter Labs |
| Proposal Sponsor: | TBC |
| Date Created: | TBC |
| Version | v1 |
| Summary of Action | Adding a ZKsync OS based CTM inside the Bridgehub. |
| Link to contracts | GitHub - matter-labs/era-contracts at draft-v29 |
Abstract
ZIP-13 proposes to add a new ZKsync OS based ChainTypeManager (CTM) to our ecosystem. This will serve as the first milestone towards adoption of the ZKsync OS, which enables chains to have full EVM equivalence, while enjoying much cheaper and faster proofs.
Motivation
ZKsync OS introduces a new Airbender prover for ZKsync Chains that can prove arbitrary RISC-V execution.
The above not only opens doors for easier system upgrades (as we only need to amend the Rust code), but also much quicker and cheaper proof generation.
Due to the large difference in the internal structure between the currently existing ZKsync chains and the new ZKsync OS architecture, we want to release ZKsync OS chains on a separate CTM first, controlled by a temporary development multisig to ensure the ability to quickly patch any fixes if necessary. Once ZKsync OS is considered mature enough, the ownership will be transferred to the decentralized governance in a subsequent ZIP.
Specification
Matter Labs will deploy the CTM for ZKsync OS chains, while the ZKsync Governance will conduct a single operation to register the CTM inside the Bridgehub.
Rationale
The approach above allows to get early feedback on the new ZKsync OS architecture on mainnet, while allowing quick upgrades to ensure prompt bug fixes during the initial phase of the system.
Due to the existing architecture, ZKsync Chains’ balances and messages are separated from each other, so even if the ZKsync OS based chains became completely malicious, they would not be able to affect other ZKsync Chains.
Implementation & Backwards Compatibility
The implementation does not involve any breaking changes for the existing chains.
For the new ZKsync OS chains, one limitation will apply: they will not be able to connect to ZKsync Gateway. This is done for security reasons to ensure maximal isolation between the existing chains and the ZKsync OS ones.
Security Considerations
Our current architecture already allows for addition of untrusted chains without the ability of those affecting the existing chains in any way. Starting from v29, there will be two mechanisms that ensure that:
- In v29 an assertion was added that ensures that chains can only connect to ZKsync Gateway, only if they belong to the same CTM as ZKsync Gateway.
- The
chainBalancemapping that has been present in our system for quite some time already ensures that a chain can never withdraw more than it had deposited into the shared bridge (L1NativeTokenVault contract).