matter-labs / era-system-contracts Goto Github PK

Implementation of the system contracts

License: MIT License

Yul 34.36% Solidity 36.68% TypeScript 26.36% JavaScript 0.04% Shell 0.17% Rust 2.38%

era-system-contracts's Introduction

zkSync Era: System Contracts

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 write smart contracts in C++, Rust and other popular languages.

system-contracts

To keep the zero-knowledge circuits as simple as possible and enable simple extensions, we created the system contracts. These are privileged special-purpose contracts that instantiate some recurring actions on the protocol level. Some of the most commonly used contracts:

ContractDeployer This contract is used to deploy new smart contracts. Its job is to make sure that the bytecode for each deployed contract is known. This contract also defines the derivation address. Whenever a contract is deployed, a ContractDeployed event is emitted.

L1Messenger This contract is used to send messages from zkSync to Ethereum. For each message sent, the L1MessageSent event is emitted.

NonceHolder This contract stores account nonces. The account nonces are stored in a single place for efficiency (the tx nonce and the deployment nonce are stored in a single place) and also for the ease of the operator.

Bootloader For greater extensibility and to lower the overhead, some parts of the protocol (e.g. account abstraction rules) were moved to an ephemeral contract called a bootloader.

We call it ephemeral because it is not physically deployed and cannot be called, but it has a formal address that is used on msg.sender, when it calls other contracts.

Building

This repository is used as a submodule of the zksync-era.

Compile the solidity and yul contracts: yarn build

Check the system contracts hashes: yarn calculate-hashes:check

Update the system contracts hashes: yarn calculate-hashes:fix

Update Process

System contracts handle core functionalities and play a critical role in maintaining the integrity of our protocol. To ensure the highest level of security and reliability, these system contracts undergo an audit before any release.

Here is an overview of the release process of the system contracts which is aimed to preserve agility and clarity on the order of the upgrades:

`main` branch

The main branch contains the latest code that is ready to be deployed into production. It reflects the most stable and audited version of the protocol.

`dev` branch

The dev branch is for active development & the latest code changes. Whenever a new PR with system contract changes is created it should be based on the dev branch.

Creating a new release

Whenever a new release is planned, a new branch named release-vX-<name> should be created off the dev branch, where X represents the release version, and <name> is a short descriptive name for the release. The PR with the new release should point to either the main branch or to the release branch with a lower version (in case the previous branch has not been merged into main for some reason).

Once the audit for the release branch is complete and all the fixes from the audit are applied, we need to merge the new changes into the dev branch. Once the release is final and merged into the main branch, the main branch should be merged back into the dev branch to keep it up-to-date.

Updating Unaudited Code

Since scripts, READMEs, etc., are code that is not subject to audits, these are to be merged directly into the main branch. The rest of the release branches as well as the dev branch should merge main to synchronize with these changes.

License

The zkSync Era system-contracts are distributed under the terms of the MIT license.

See LICENSE-MIT for details.

Official Links

Disclaimer

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.

era-system-contracts's People

Contributors

Stargazers

Watchers

Forkers

wadelu big-aaron gacwr sync-pad dto-simba snapchain joshfisidi valewael thomas-nguy z1-gif crryptoyeppeuda 42mariacalderon marius-bc-dev bilyuner-man beachmannix cb-defi-notifs erica3yina3 vigenterzian lumoz-protocol melanie4291 wickchad lisuxiaoqi chaddockvanwykel2376 deppnerkeiswetteroljx9432 lovelean80 pahepeha huntermans manipulation44 mouzzarr defconpro imhunterand daniellrra manyalal rodaber006 fatyfa288 idea404 distributedstatemachine ylmin stanislavbreadless yanggaoning0527 eliahfink tommie8193 lambdaclass gmh5225 dklupov nonfungible777 4nnnn saladerl sala72 yszmz martinkong1990 beifeng5 hqg012 nftboy07 bondarkost turkinkolette darrigojoelly idexo shimmering2 timosanmaz neotheprogramist oxjean toddfil yilimin999 truongnusta kalasforever erisisudem saba0021 limonatavax connoteame jules octavioti robocups mrcryptooo maxxoon kirilladept naazart noyou75 s1miii nikita0708 emrahqundoqan arjen30 7murat kerimzend bawer30 kasimzadeh mirserkan excitatio kalomes metin31sen msn9189 eantoladar mrpoou farzanfrd groupapple ttherules pakeloki xiaoxianboy 0xdefine kervsalz

era-system-contracts's Issues

`CURRENT_MAX_PRECOMPILE_ADDRESS` does not include `keccak256` precompile

I'm referring to the Constants:

address constant ECRECOVER_SYSTEM_CONTRACT = address(0x01);
address constant SHA256_SYSTEM_CONTRACT = address(0x02);

/// @dev The current maximum deployed precompile address.
/// Note: currently only two precompiles are deployed:
/// 0x01 - ecrecover
/// 0x02 - sha256
/// Important! So the constant should be updated if more precompiles are deployed.
uint256 constant CURRENT_MAX_PRECOMPILE_ADDRESS = uint256(uint160(SHA256_SYSTEM_CONTRACT));

I might be confused, but shouldn't this be 3 contracts? The keccak256 precompile is deployed at the address 0x0000000000000000000000000000000000008010 if am not wrong.

SEQUERTY

CAN GATE A PAGE WITCH DAPP IS FULLY AUDITED WICH CONTRACT VALU SCORE

🌟 Feature Request

📝 Description

Provide a clear and concise description of the feature you'd like to see.

🤔 Rationale

Explain why this feature is important and how it benefits the project.

📋 Additional Context

Add any other context or information about the feature request here.

Pamcake

Pls fix fess
They are charging 2 to 3 usd a simpale swap fess
Sync swap charging on that time .10 cent
How can reduce if not possible from update contract

🌟 Feature Request

📝 Description

Provide a clear and concise description of the feature you'd like to see.

🤔 Rationale

Explain why this feature is important and how it benefits the project.

📋 Additional Context

Add any other context or information about the feature request here.

How to get official's ContractDeployer address? Already found

Holdstation (perps) - Very high fees

I invite the Zksync team to intervene on the behavior of holdstation.com (perps). The rates are exorbitant. A few days ago I paid $4.6 for a transaction.

This behavior suggests that there is a bit of anarchy within the ecosystem, I hope this is not the case.

🐛 Script Bug Report

📝 Description

Provide a clear and concise description of the bug.

🔄 Reproduction Steps

Steps to reproduce the behaviour

🤔 Expected Behavior

Describe what you expected to happen.

😯 Current Behavior

Describe what actually happened.

🖥️ Environment

Any relevant environment details.

📋 Additional Context

Add any other context about the problem here. If applicable, add screenshots to help explain.

📎 Log Output

Paste any relevant log output here.

For `EmptyContract` `payable` could be generally removed

So my understanding of EmptyContract is that this contract is put into some system contracts by default. Could you quickly elaborate on "some"?

What I don't understand is why you make it payable. There could be some users trying (for whatever) reason to send ETH to one of those contracts. Right now these contracts can receive ETH and this could be prevented, however (an additional guardrail). It makes sense in one case where you define a system address as a burn address, but not generally IMHO. My recommendation would be to remove the receive function completely and define a non-payable fallback function, except for the burn address.

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.0;

/**
 * @author Matter Labs
 * @notice The "empty" contract that is put into some system contracts by default.
 * @dev The bytecode of the contract is set by default for all addresses for which no other bytecodes are deployed.
 */
contract EmptyContract {
    fallback() external {}
}

matter-labs / era-system-contracts Goto Github PK

era-system-contracts's Introduction

zkSync Era: System Contracts

system-contracts

Building

Update Process

main branch

dev branch

Creating a new release

Updating Unaudited Code

License

Official Links

Disclaimer

era-system-contracts's People

Contributors

Stargazers

Watchers

Forkers

era-system-contracts's Issues

🌟 Feature Request

📝 Description

🤔 Rationale

📋 Additional Context

🌟 Feature Request

📝 Description

🤔 Rationale

📋 Additional Context

🐛 Script Bug Report

📝 Description

🔄 Reproduction Steps

🤔 Expected Behavior

😯 Current Behavior

🖥️ Environment

📋 Additional Context

📎 Log Output

Recommend Projects

Recommend Topics

Recommend Org

`main` branch

`dev` branch