0xpolygonhermez / zkevm-contracts

Polygon zkEVM Smart Contracts

zkevm-contracts

Smart contract implementation which will be used by the polygon zkevm

Mainnet Contracts:

Contract Name	Address
PolygonRollupManager	0x5132A183E9F3CB7C848b0AAC5Ae0c4f0491B7aB2
PolygonZkEVMBridgeV2	0x2a3DD3EB832aF982ec71669E178424b10Dca2EDe
PolygonZkEVMGlobalExitRootV2	0x580bda1e7A0CFAe92Fa7F6c20A3794F169CE3CFb
FflonkVerifier	0x4F9A0e7FD2Bf6067db6994CF12E4495Df938E6e9
PolygonZkEVMDeployer	0xCB19eDdE626906eB1EE52357a27F62dd519608C2
PolygonZkEVMTimelock	0xEf1462451C30Ea7aD8555386226059Fe837CA4EF

zkEVM Contracts:

Contract Name	Address
PolygonZkEVMBridgeV2	0x2a3DD3EB832aF982ec71669E178424b10Dca2EDe
PolygonZkEVMTimelock	0xBBa0935Fa93Eb23de7990b47F0D96a8f75766d13

Requirements

• node version: 16.x
• npm version: 7.x

Install repo

npm i

Run tests

npm run test

Deploy on hardhat

npm run deploy:ZkEVM:hardhat

Build dockers

npm run docker:contracts

Or if using new docker-compose version

npm run dockerv2:contracts

A new docker hermeznetwork/geth-zkevm-contracts will be created This docker will contain a geth node with the deployed contracts The deployment output can be found in: docker/deploymentOutput/deploy_output.json To run the docker you can use: docker run -p 8545:8545 hermeznetwork/geth-zkevm-contracts

Note

In order to test, the following private keys are being used. These keys are not meant to be used in any production environment:

• private key: 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80
  • address:0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266
• private key: 0xdfd01798f92667dbf91df722434e8fbe96af0211d4d1b82bbbbc8f1def7a814f
  • address:0xc949254d682d8c9ad5682521675b8f43b102aec4

Verify Deployed Smart Contracts

To verify that the smartcontracts of this repository are the same deployed on mainnet, you could follow the instructions described document

The smartcontract used to verify a proof, it's a generated contract from zkEVM Rom and Pil (constraints). To verify the deployment of this smartcontract you could follow the instructions described in this document

Activate github hook

git config --local core.hooksPath .githooks/

zkevm-contracts's Issues

memdb does not handling null values when key does not exist

Maybe we should do some wrapper to return null instead

zkevm-proverjs buildsetup returns immediately without generating the verifier contract

I am trying to reproduce the Mainnet verifier contract using the guide here:
https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/verifyMainnetDeployment/verifyMainnetProofVerifier.md

For this I have created a simple Docker container to perform the steps outlined in the doc. However, I think there might be a bug with the following step:

tmux -c "npm run buildsetup --bctree=../zkevm-prover/build/bctree"

as it immediately returns with the following output:

> @0xpolygonhermez/[email protected] buildsetup
> tools/build_all.sh ${npm_package_config_steps_setup}

Using 13565 MB

The document says this step should take a few hours since it involves downloading the power of tau file (288 GB) , however this is not happening for me as the command returns immediately instead.

This is my Dockerfile ( zkevm-prover and zkevm-proverjs are checked out locally at the appropriate commits, and copied to the image) :

# Use Ubuntu 22.04 LTS as the base image
FROM --platform=linux/amd64 ubuntu:22.04

WORKDIR /root

# Set environment variables
ENV DEBIAN_FRONTEND=noninteractive
ENV NODE_OPTIONS="--max-old-space-size=230000"

# Basic OS preparation
RUN apt-get update && \
    apt-get install -y git tmux git curl jq && \
    tee -a /etc/sysctl.conf && \
    sysctl -w vm.max_map_count=655300

RUN apt install -y build-essential libomp-dev libgmp-dev nlohmann-json3-dev libpqxx-dev nasm libgrpc++-dev libprotobuf-dev grpc-proto libsodium-dev uuid-dev libsecp256k1-dev vim

# Install Node.js version 18
RUN curl -sL https://deb.nodesource.com/setup_18.x -o nodesource_setup.sh && \
    bash nodesource_setup.sh && \
    apt-get install -y nodejs

# Verify Node.js version
RUN node -v

# Download and prepare circom
RUN cd ~ && \
    git clone https://github.com/iden3/circom.git && \
    cd circom && \
    git checkout v2.1.8 && \
    git log --pretty=format:'%H' -n 1

# Install and compile circom (RUST)
RUN cd ~  && \
apt install -y cargo  && \
cd circom  &&  \ 
cargo build --release && \
cargo install --path circom 

ENV PATH="$PATH:~/.cargo/bin" 

## Prepare fast build constant tree tool

COPY ./zkevm-prover /root/zkevm-prover

RUN  cd ~ &&  \
cd zkevm-prover && \
make -j bctree
# git checkout 40cde45deacede2b10a91ce2dd926abd2ba67541 && \
# git submodule init && \
# git submodule update && \


## Prepare and launch setup (zkevm-proverjs)
COPY ./zkevm-proverjs /root/zkevm-proverjs

RUN cd zkevm-proverjs && \
npm install 


ENTRYPOINT ["/bin/bash", "-c", "cd zkevm-proverjs && tmux -c 'npm run buildsetup --bctree=../zkevm-prover/build/bctree'"]

Support for exit via `forceBatch`

I am currently working on deploying a rollup with Polygon CDK in the most trustless manner possible. I am investigating whether users can exit (withdraw) without the permission of trusted sequencers.

It appears that the GlobalExitRoot in forceBatch always contains the latest value.

zkevm-contracts/contracts/PolygonZkEVM.sol

Lines 1035 to 1048 in 1ad7089

	// Get globalExitRoot global exit root
	bytes32 lastGlobalExitRoot = globalExitRootManager
	.getLastGlobalExitRoot();
	// Update forcedBatches mapping
	lastForceBatch++;
	forcedBatches[lastForceBatch] = keccak256(
	abi.encodePacked(
	keccak256(transactions),
	lastGlobalExitRoot,
	uint64(block.timestamp)
	)
	);

Therefore, it seems that users cannot change the GlobalExitRoot via forceBatch and thus cannot withdraw. Is my understanding correct?

`etherMan.PolygonBridge.NetworkID` panic with error: "invalid opcode %!s(MISSING)"

Problem

I was following https://wiki.polygon.technology/docs/zkevm/step3-fullzkevm/ and deployed the full zkEVM but I see zkevm-bridge-service exit with code 1.

Root Cause Analysis

By examining the contain logs, I see

zkevm-bridge-service       | 2023-09-18T04:03:57.386Z   ERROR   cmd/run.go:52   failed to execute the unsigned transaction

and

zkevm-json-rpc | 2023-09-18T06:59:18.199Z   ERROR   jsonrpc/server.go:397   failed to execute the unsigned transaction: invalid opcode %!s(MISSING) {"pid": 1, "version": "v0.3.1"}
zkevm-json-rpc             | 2023-09-18T06:46:58.257Z   INFO    jsonrpc/handler.go:144  failed call: [-32000]failed to execute the unsigned transaction. Params: [{"data":"0xbab161bf","from":"0x0000000000000000000000000000000000000000","to":"0x5798cfa36832d17b5074e462ef234c75afe884ba"},"latest"]     {"pid": 1, "version": "v0.3.1", "method": "eth_call", "requestId": 1}

I also verified that I can repro with:

$ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{"to": "0x5798cfa36832d17b5074e462ef234c75afe884ba", "data": "0xbab161bf", "from": "0x0000000000000000000000000000000000000000"}, "latest"],"id":1}' -H "Content-Type: application/json" http://3.81.29.192:8123

{"jsonrpc":"2.0","id":1,"error":{"code":-32000,"message":"failed to execute the unsigned transaction"}}

By digging deeper to the code at here and here, I suspect that the problem might be due to the L2 bridge contract was not deployed correctly so the bytecode was corrupted in the genesis file (why the NetworkID call failed):

Additional Context 1

When I was deploying the contracts, npm run deploy:testnet:ZkEVM:goerli failed (likely due to the infura free tier RPC) so I had to redeploy. Then I increased the salt field and reran the command.

contracts seems to have deployed successfully but when I verify I got some failures (full output)

Failed to link proxy 0xdFe29aD5aF07D5a95B7cc23D023ab2e7b16Ff452 with its implementation. Reason: The implementation contract at 0x41de7ed8e9e5fd924a0919ab5ff22e81eafb3cdf does not seem to be verified. Please verify and publish the contract source before proceeding with this proxy verification.
Verifying proxy admin: 0x3BF649126307334c60718362a607975ba552886d
Failed to verify ProxyAdmin contract at 0x3BF649126307334c60718362a607975ba552886d: Bytecode does not match with the current version of ProxyAdmin in the Hardhat Upgrades plugin.

I checked those "failed to verify" contract on etherscan and they seem correct. not sure if that's related since it's the L1 contracts.

Additional Context 2

The tutorial was too old so I did some customizations to use the newer code / docker images:

• hermeznetwork/zkevm-node:v0.3.1
• hermeznetwork/zkevm-prover:v2.2.3
• hermeznetwork/zkevm-bridge-service:2.0

Failed tests

I get the failures when I run npm run test. It seems the solidity and JS code are not consistent when calculate stark input

Proof of efficiency snark stark input test
Check commonjs unit test:

  AssertionError: expected '0x55f4c373d62dd577ef6160a1980130db83f…' to equal '0xd072c5e95f2a1aa8dee6f1e0667f72f9e66…'
  + expected - actual

  -0x55f4c373d62dd577ef6160a1980130db83f0686dab8afe5e32e641ca6abeab4c
  +0xd072c5e95f2a1aa8dee6f1e0667f72f9e66ed47f7ff5f5e3ad6f504379c73c26
  
  at Context.<anonymous> (test/contracts/snark_stark_input.test.js:77:36)
  at processTicksAndRejections (node:internal/process/task_queues:95:5)
  at runNextTicks (node:internal/process/task_queues:64:3)
  at listOnTimeout (node:internal/timers:533:9)
  at processTimers (node:internal/timers:507:7)

Docker Deployment script throwing with latest version of docker compose v2

Docker Deployment script throwing with latest version of docker compose v2

Description

The current docker deployment script will not work with docker compose v2 installed and throws an error of unknown command "docker-compose"

Your environment

• Linux (ubuntu 20.04).
• main.
• Running Locally.

Steps to reproduce

• On running the docker build command "npm run docker:contracts" the deploy-docker.sh script throws the error that docker-compose command is not recognized.
• The issue is in deploy-docker.sh script which works with docker-compose version v1 not with v2.
• Which commands triggered the issue: npm run docker:contracts.

Expected behavior

• We should be able to successfully create a docker image.
• Script throws error.

Proposed solution

Either restrict the docker-compose version to be used or update the script to latest docker compose command

I could not find a contribution guide so opened a pull request with the above mentioned change. Would be happy to learn more about this and take this forward

Unable to verify signature on L1 hermeznetwork/geth-zkevm-contracts:v2.0.0-fork.5-geth1.13.1

version:

• https://github.com/0xPolygon/cdk-validium-node
• https://github.com/0xPolygon/cdk-validium-contracts
• https://github.com/0xPolygonHermez/zkevm-bridge-service.git v0.2.0
• L1 blockchain geth-zkevm-contracts:v2.0.0-fork.5-geth1.13.1

steps:

• redeploy the cdk-validium-contracts on the L1 chain**(geth-zkevm-contracts:v2.0.0-fork.5-geth1.13.1)**
• config sequencer-sender node config,

       WaitPeriodSendSequence = "35s"
       LastBatchVirtualizationTimeMaxWaitPeriod = "20s"
       MaxBatchesForL1 = 2
  

• reconfiguration the contract and gen nums for the service, eg: sync/sequencer/bridge...
• send some txs on L2, make some batchs to trigger the MaxBatchesForL1=2 condition
• the sequencer-sender will send batch tx error like this
  
• others: but if set MaxBatchesForL1 = 1, that is success.

Possible optimizacion of the bridge, store less globalExitRoots

Store all the merkle roots is costly, and the new roots contain alll the information of the previous ones and more ( since is a incremental merkle tree) but we can't work just with the last one, we need some historic, in order to withdraw.
- Store a merkle root every 40 blocks ( 10 min)
- This approach delays the withdraw in mainnet 10 min, but only 2 roots will be necessary to be stored.
- Previous approach but with 5 minuts, we could save 2 slots + the current one

Bridge gas golfing

• The cost of the deposit can be split in:
  1. Calculate the new leaf and update the root --> 50-60k gas
  2. Calculate the new root --> 80+k gas
  3. Update the root to the globalExitRootManager --> 20-30+k gas

If we could make that the trusted sequencer does the steps 2 and 3, in order to reduce the gas cost of the deposit call to 1/3.
The overall gas cost is so much cheaper.
The flow should be like this:

• Trusted sequencer will do a new call prepareBatch which :
  1. Will calculate the depositRoot and update with it the GlobalExitRoot manager
  2. set the timestamp/globalExitRoot for the following batches.
• This function should be called every X timestamp or batches and will be the way the trusted sequencer has to set the env variables

This branch inteend to do this optimizations: https://github.com/hermeznetwork/contracts-zkEVM/tree/feature/gasGolfingBridge

Maximum number of transactions

• Taking in to account that we are only implementing Ethereum transactions at the very beginning, which is the maximum transactions that a sequencer can add into a single Ethereum transaction ?
• Could we assume several sequencer transactions in the same Ethereum block ?

[Docs] Where i can find docs like this https://docs.polygon.technology/cdk/get-started/quickstart-validium/ for validium consensus

We need deployment flow and running order like that

Its really hard to try with no-document

Some doubt about bridgeAddress

I get some doubt when reading the contract code. Here, when constructing the transaction to initialize the bridge on L2, I don't understand why the bridgeAddress used is the L1 bridge address, or is the bridgeAddress on L1 and L2 the same?

zkevm-contracts/contracts/v2/lib/PolygonRollupBaseEtrog.sol

Line 904 in eecf908

bridgeAddress,

Is there a way to get the smt proof for a "ClaimXXXX" call?

Sorry for the duplication: I asked the same question in the zkevm-node repo: 0xPolygonHermez/zkevm-node#1980 . However I don't know whether it is better to ask it here.

HI, I am trying to send an L1 message to L2. I wonder if there is an API method to get the smt proof for the "claimXXX" calls.

   /**
     * @notice Verify merkle proof and execute message
     * If the receiving address is an EOA, the call will result as a success
     * Which means that the amount of ether will be transferred correctly, but the message
     * will not trigger any execution
     * @param smtProof Smt proof
     * @param index Index of the leaf
     * @param mainnetExitRoot Mainnet exit root
     * @param rollupExitRoot Rollup exit root
     * @param originNetwork Origin network
     * @param originAddress Origin address
     * @param destinationNetwork Network destination
     * @param destinationAddress Address destination
     * @param amount message value
     * @param metadata Abi encoded metadata if any, empty otherwise
     */
    function claimMessage(
        bytes32[_DEPOSIT_CONTRACT_TREE_DEPTH] calldata smtProof,
        uint32 index,
        bytes32 mainnetExitRoot,
        bytes32 rollupExitRoot,
        uint32 originNetwork,
        address originAddress,
        uint32 destinationNetwork,
        address destinationAddress,
        uint256 amount,
        bytes calldata metadata
    ) external ifNotEmergencyState {

I found "https://proof-generator.polygon.technology/" is requested when I use your bridge. But this is not what I want.
Or I have to walk through the branch nodes at specific block height by myself?
Or any other suggestions?

Thanks.

Which commit is used to build test-fork docker image?

Hi all, I'm customize some configuration in this image
https://hub.docker.com/layers/hermeznetwork/geth-zkevm-contracts/test-fork/images/sha256-7373d0f383f31b7af31210cd4709ac5294d26287b82a03674cfd39f6b4716437?context=explore…

But idk which commit to be build to this image, could you give me some information, thanks so much!

Add missing deployer script and verify script for Sepolia

Check every decoded parameter in the executor identically to the zkprover

Review

Review

Originally posted by @LKS121 in 0xPolygon/polygon-cli#52 (review)

unable to deploy the contracts

When it runs the following line:

zkevm-contracts/deployment/deployContracts.js

Line 187 in 5de59e1

await polygonZkEVMGlobalExitRoot.initialize(polygonZkEVMContract.address, polygonZkEVMBridgeContract.address);

it always shows the error as follows：

Matic deployed to: 0xaA3032a68d56A9382ee1eCEf6F34C4fe720F5988
#######################

Verifier deployed to: 0x9fcABD22c5d0537eeBf0a38f153A790bfC09cBA3
#######################

polygonZkEVMGlobalExitRoot deployed to: 0x4dB99947D090467F11Dd0e52FBF8c5Df8713625c
#######################

PolygonZkEVMBridge deployed to: 0x52665A145eCFf537300b6448f96FABE598B51C98
#######################

Polygon ZK-EVM deployed to: 0x1e0121a4EcCfAe4959F2eD3dB5af8ddD71c0aDFF
Error: invalid arrayify value (argument="value", value="-0x0bafd8", code=INVALID_ARGUMENT, version=bytes/5.7.0)
at Logger.makeError (/Users/ton/test/polygon_zkevm/zkevm-contracts/node_modules/@ethersproject/logger/src.ts/index.ts:269:28)
at Logger.throwError (/Users/ton/test/polygon_zkevm/zkevm-contracts/node_modules/@ethersproject/logger/src.ts/index.ts:281:20)
at Logger.throwArgumentError (/Users/ton/test/polygon_zkevm/zkevm-contracts/node_modules/@ethersproject/logger/src.ts/index.ts:285:21)
at arrayify (/Users/ton/test/polygon_zkevm/zkevm-contracts/node_modules/@ethersproject/bytes/src.ts/index.ts:141:19)
at /Users/ton/test/polygon_zkevm/zkevm-contracts/node_modules/@ethersproject/transactions/src.ts/index.ts:234:25
at Array.forEach ()
at _serialize (/Users/ton/test/polygon_zkevm/zkevm-contracts/node_modules/@ethersproject/transactions/src.ts/index.ts:230:23)
at serialize (/Users/ton/test/polygon_zkevm/zkevm-contracts/node_modules/@ethersproject/transactions/src.ts/index.ts:311:16)
at /Users/ton/test/polygon_zkevm/zkevm-contracts/node_modules/@ethersproject/wallet/src.ts/index.ts:124:80
at processTicksAndRejections (node:internal/process/task_queues:95:5) {
reason: 'invalid arrayify value',
code: 'INVALID_ARGUMENT',
argument: 'value',
value: '-0x0bafd8'

How to solve the problem?

Config erc20 in layer1 becomes the native token for layer2

I am working on Validium repo to deploy L2 using matic(erc20) on eth to become native token for my own layer 2, but I haven't found any parameters to configure for it

https://github.com/0xPolygon/cdk-validium-contracts/blob/main/deployment/deploy_parameters.json.example

script path mismatch

package.json

"deploy:deployer:ZkEVM:goerli": "npx hardhat run deployment/2_deployPolygonZKEVMDeployer.js --network goerli",

do we need to fix the path to use deployment/v2/? - needed to know the latest version of the deployment flow.

Also https://docs.polygon.technology/cdk/get-started/deploy-rollup/create-wallets/#deploy-contracts doesnt mention which script to use for the genesis file creation

Add deployment support for `holesky` testnet

For better interoperability with testnets, it'd be nice to have support with holesky. Currently the existing packages.json only has Ethereum testnet support for goerli and sepolia. Since goerli has been recently deprecated it should also be removed from the repo entirely.

Allow any L1 provider

The ENV file requires this parameter:
INFURA_PROJECT_ID
And then builds the L1 URL like that:
https://mainnet.infura.io/v3/${process.env.INFURA_PROJECT_ID}
It would be useful to just accept the whole L1 URL in a var, like this:
L1_URL
So I can use whatever provider I wish, or even my own RPC node, instead of being forced to use Infura.

How to solve the problem when users submit invalid transactions

I see the forceBatch function does not check the validity of transactions, how to solve the problem when users submit invalid transactions, is there any way to revert it?

zkevm-contracts/contracts/PolygonZkEVM.sol

Line 1018 in b1cefea

function forceBatch(

function forceBatch(
        bytes calldata transactions,
        uint256 maticAmount
    )

How to fix the ERC777 re-entrancy attack?

The first weakness mentioned in Hexens audit report：

But the codes are still the same:

               // In order to support fee tokens check the amount received, not the transferred
                uint256 balanceBefore = IERC20Upgradeable(token).balanceOf(
                    address(this)
                );
                IERC20Upgradeable(token).safeTransferFrom(
                    msg.sender,
                    address(this),
                    amount
                );
                uint256 balanceAfter = IERC20Upgradeable(token).balanceOf(
                    address(this)
                );

                // Override leafAmount with the received amount
                leafAmount = balanceAfter - balanceBefore;

I want to learn how we fixed this attack?

Compute MATIC to pay for Sequencers

Topic

When calculating the MATIC fee, how can the contract know hwo many transactions are RPL encoded without decoding them?, could we code at the start some bytes indicating how many transactions will be?

Idea

• We could use the length of the l2TxsData parameter in the smart contract
• There will be a minimal length for l2TxsData, which would be the bytes of the minimal viable transaction
  • This marks the floor of MATIC to spend
• More bytes means more MATIC to spend
  • l2TxsData is considered as a scarce resource, meaning that sequencer pays for byte added. Here, byte added means that the aggregator should put more effort to compute more bytes, so it is rewarded proportionally for bytes procecessed
• This approach has the advantage that penalizes behavior when submitting wrong txs and mitigates adding fake/bad txs

Site

[Inquiry] How to properly make a claimAsset call

I'm developing a bridge/claim library and trying to claim an asset this bridged asset from Cardona Testnet:
https://sepolia.etherscan.io/tx/0x8f776c17ad4c285f4192bfe19f73b49a6cc6605e94b0ddfda43e7e9f340bf140#eventlog

sent from 0x13b58ad52dd0092B29bf4B061D55AE6f973614F6, but I haven't been able to make a successful claimAsset call so far.

From the event log of the bridgeAsset call, I obtained

• depositCount : 10255
• mainnetExitRoot: 0xa78ac5e0aa87b03a27e0447675933a399f771a9bf6b8bbc040df536f1ed9a932
• rollupExitRoot: 0xf55be3aafef8e00498fa97ac5f18a6e2fa5bbd45d451ad10eb6f20c405088b35

and from zkevm-bridge-service (https://bridge-api.cardona.zkevm-rpc.com), I obtained

• globalIndex: 18446744073709561871 (by calling bridges/0x13b58ad52dd0092B29bf4B061D55AE6f973614F6 with params { dest_addr: '0x13b58ad52dd0092B29bf4B061D55AE6f973614F6', offset: 0, limit: 5 })
• smtProofLocalExitRoot (by calling merkle-proof with params { deposit_cnt: 10255, net_id: 0 })
• smtProofRollupExitRoot (by calling merkle-proof with params { deposit_cnt: 10255, net_id: 0 })

Then I call claimAsset on PolygonZkEVMBridgeV2.sol deployed at 0x528e26b25a34a4A5d0dbDa1d57D318153d2ED58.

For other parameters of claimAsset, I used

• originNetwork = 0
• originTokenAddress = ethers.ZeroAddress
• destinationNetwork = 1
• destinationAddress = 0x13b58ad52dd0092B29bf4B061D55AE6f973614F6
• meta data = Uint8Array(0) (empty byte vector)

and my claimAsset calls fail as in:
https://cardona-zkevm.polygonscan.com/tx/0x084ad1caec223aa4ccb4f2e36ba7bdca6bbc440693a62fdf6859e05fa2980733

Could somebody point out where I'm making mistakes?

Typo on require message

Review this sentence: https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/contracts/ProofOfEfficiency.sol#L341

batch does not have been sequenced
==>
batch has not been sequenced

forkId - event and variable declaration does not fit together

The forkId is declared as immutable:
https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/contracts/PolygonZkEVM.sol#L163

But at the same time, we have an event for updates of the forkId.
https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/contracts/PolygonZkEVM.sol#L365

That does not make sense unless you intend to overwrite it with "parent contracts".

Unable to verify proxy contracts after deployment

Hello,
I am getting the following error:

Failed to verify ProxyAdmin contract at 0xdc343C1f453A89B901Fa511D87F4a2eF2Aa36222: Bytecode does not match with the current version of ProxyAdmin in the Hardhat Upgrades plugin.

(this was a goerlie deployment).

Reproduction steps:

git checkout main
modify .env and deploy_parameters.json
npm run deploy:deployer:ZkEVM:goerli
npm run verify:deployer:ZkEVM:goerli
npm run deploy:testnet:ZkEVM:goerli
npm run verify:ZkEVM:goerli

Probably, you guys have an extra trick on how to verify the proxy contracts, after a deterministic deployment. Would you mind share it?

Improve posiedon and F approach

Current approach for using the F conversions and poseidon, requires to build using and async function the poseidon, therefore we can't import it directly, and must be builded or passed as a parameter in every function that is used.

A possible approach could be just build it once and create a Function that retrieves the F and if is not buidled throw an ERROR

Configurable gas token

Would you guys accept an PR that allows to configure the gas token? Currently, it seems like the gas token is hard-coded to eth and these eth need to be exchanged to matic by the operator.

This is suboptimal for some applications:

• some forks might want to have a stable gas token, like dai on gnosis chain
• some forks might actually want to have a gas token that is forkable - this is what we are interested in.

My PR would only touch the zkevm bridge, and would change that the deposit function can account other tokens than ETH as the token that is stored on the evm as the token with address zero. This would then also imply that one could send the new gas-token with the normal eth-sending protocol and does not need to use erc20 protocol.

Error: could not detect network, when deploying contracts

I am currently facing this issue while deploying ZkEVM contracts on an AWS EC2 instance. Below, I have outlined the details of the error and the steps I have taken to troubleshoot it.

Error Details:

During the deployment of the ZkEVM contracts, I encounter the following error:

npm run deploy:deployer:ZkEVM:goerli

> @0xpolygonhermez/[email protected] deploy:deployer:ZkEVM:goerli
> npx hardhat run deployment/2_deployPolygonZKEVMDeployer.js --network goerli

Hardcoded gas used: MaxPriority100 gwei, MaxFee50 gwei
Error: could not detect network (event="noNetwork", code=NETWORK_ERROR, version=providers/5.7.2)
    at Logger.makeError (/home/ubuntu/zkevm-contracts/node_modules/@ethersproject/logger/src.ts/index.ts:269:28)
    at Logger.throwError (/home/ubuntu/zkevm-contracts/node_modules/@ethersproject/logger/src.ts/index.ts:281:20)
    at JsonRpcProvider.<anonymous> (/home/ubuntu/zkevm-contracts/node_modules/@ethersproject/providers/src.ts/json-rpc-provider.ts:483:23)
    at step (/home/ubuntu/zkevm-contracts/node_modules/@ethersproject/providers/lib/json-rpc-provider.js:48:23)
    at Object.throw (/home/ubuntu/zkevm-contracts/node_modules/@ethersproject/providers/lib/json-rpc-provider.js:29:53)
    at rejected (/home/ubuntu/zkevm-contracts/node_modules/@ethersproject/providers/lib/json-rpc-provider.js:21:65)
    at processTicksAndRejections (node:internal/process/task_queues:96:5) {
  reason: 'could not detect network',
  code: 'NETWORK_ERROR',
  event: 'noNetwork'
}

Troubleshooting Steps Taken:

1. Checked the 2_deployPolygonZKEVMDeployer.js file on GitHub (https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/deployment/2_deployPolygonZKEVMDeployer.js) to analyze the potential cause of the error.

2. Reviewed the 3_deployContracts.js file to verify any issues with the expect commands.

Observations:

After a thorough investigation, I found that the error is arising after line 20 in the 2_deployPolygonZKEVMDeployer.js file. However, I have not been able to pinpoint the exact reason for the "noNetwork" error yet.

Request for Assistance:

Any insights or suggestions you can provide for us to fix this would be greatly appreciated!

Outdated geth image caused invalid OPCODE PUSH0 error

Root Cause

when running docker/scripts/v2/deploy-docker.sh to deploy the contracts to create the geth-mock-l1 image

it failed with invalid OPCODE PUSH0 error

root cause is due to PUSH0 was added recently (https://medium.com/coinmonks/push0-opcode-a-significant-update-in-the-latest-solidity-version-0-8-20-ea028668028a)

but docker/docker-compose.yml use ethereum/client-go:v1.12.0 which is a old image

Solution

changing it to ethereum/client-go:latest fixed the issue for us

gsmanwar

System requirements

The README.md file does not contain the system requirements for running the smart contract

Why is the forceBatchTimeout so high?

I am really wondering why the forceBatchTimeout is set to such a high value of 5 days?

This is a challenge:

• since a malicious sequencer could deny price feed updates and withdraws for aave or maker for 5 days. This could have a huge impact on liquidations and the working of the system.
• since some defi applications like UMA or realityETH need to challenge invalid inputs within certain time frames. Usually, these timeframes are smaller than 5 days.

Reasons to set it higher:

• It can break normal sequencing and thereby remove "instant finality" for some users.

Would love to hear, whether you guys think its safe to set it to 30 minutes, to eliminate pricefeed manipulations?
Or do you bet mostly on decentralised sequencer to resolve this issue?(I believe that it improves the situation by a lot, though censorhip of ethereum will stay better for quite a long time than the censorship resistance of Espresso?

[Inquiry] Is claiming asset on the L1 side from a script allowed?

Hello.

I'm a developer developing a Polygon zkEVM bridge/claim library.
Thanks for helping me out the last time for bridging an asset from L1 to L2.

Now I'm trying to bridge and claim an asset in the opposite direction (from L2 to L1) and having a problem.
Althrough I can claim a bridged asset from L1 side through Polygon Portal, I am unable to do so with a claimAsset call from a script.

In order to find out the diffence between the two cases:

1. First I waited until the bridged asset became ready-to-state in Polygon Portal.
2. Next I called claimAsset from a script and failed.
3. Then immediately after I confirmed the failure, I claimed the asset from Polygon Portal and succeded.

After that, comparing the calldata of the failure case and the successful case, I noticed that they were identical.

Does this mean only certain accounts are allowed to make the claimAsset call?