Safe/Finalized Block is always 0x0 on X Layer Mainnet
#441
Comments
|
The issue is that the finalized block is also |
|
comparing the logs from testnet and mainnet, we observed a few diffs related with testnet logs: mainnet: |
andreclaro
changed the title
0x0 on X Layer Mainnet0x0 on X Layer Mainnet
|
Because Added a few logs to confirm: This was done using https://github.com/0xPolygonHermez/cdk-erigon/tree/v1.0.7 with this commit 4e89b13 and a few more logs. |
|
I will try to fix it |
|
You sure your L1 sync reads verifications from L1 correctly? |
|
Doesn't seem like a problem just with @andreclaro's set-up, we're currently facing the same issue on XLayer mainnet. |
|
hi @mandrigin @giskook , thanks for looking into this issue, which is impacting also other node operators as well. I see the following log messages every second: Querying the latest block: explorer: https://www.oklink.com/xlayer/block/1524612 querying finalized block: |
Hi @mandrigin, how can I verify that? |
|
ran the following commands against our etherum mainnet node, used by xlayer: finalized - safe - |
|
I also tried using an eth node from a 3rd party node provider. |
|
ETH stuff is not related at all with that. This is finality on L2 we are talking about here. “Safe” and “finalized” on CDKs are based on L1 verifications posted by the prover. So basically your node needs to be points to the right RollupManager contract on L1 and also have the correct index there, to be able to parse verifications. Then it will verify the state root that was submitted by the prover, and match it with what it gets locally. If matches — it will move “safe” and “finalized” because it guarantees that this hash never changes. |
|
Check how it works on Cardona and zkEVM Mainnet. |
@mandrigin, How can I verify?
@mandrigin, We don't run zkEVM nodes yet... and the issue is only observed on X Layer Mainnet. XLayer Testnet is running as expected and returning finalized block. |
We are following the same configuration shared here (#441 (comment)), which we got from the configuration in cdk-erigon repo: https://github.com/0xPolygonHermez/cdk-erigon/blob/zkevm/xlayerconfig-mainnet.yaml.example @giskook and @mandrigin anything wrong? |
It's correct. |
|
Your network is an AggLayer network, I guess, what’s your rollup id for mainnet? |
|
Okay, first thing first — rollupID should be 3 and not 1 for mainnet. Please fix it in our repo too, it is wrong, I just confirmed. |
|
If that doesn’t help — ping me again — that means that Erigon doesn’t work well with AggLayer networks and we need to fix it. |
Yes, the rollup id should be set to 3 @andreclaro |
fixed pr #451 |
|
Hi @mandrigin, can you make sure these commits including this fix safe block made as finilized is included in the next release of cdk-erigon? Thanks a million everyone! |
|
@andreclaro yep, we are always releasing based on “zkevm” branch, so it should be included in the next release for sure. |
|
Up We would like this feature in the next release cycle since it's important for our operations at Triton One |
|
+1 |
|
+1 |
|
+1 |
|
everybody wants it |
|
+1 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
Safe Block is always
0x0on X Layer Mainnet. On testnet is reporting the correct block. This was observed using Using https://github.com/okx/xlayer-erigon/tree/rpc-fix-safe branch, which contains the commit in this PR okx#11However, I also tried the latest version v1.0.7 of cdk-erigon and the finalized block is also always 0x0 on X Layer mainnet.
This is a follow-up to #388 and okx#10
System information
Erigon version:
OS & Version: Linux
Erigon Command (with flags/config):
Chain/Network: X Layer - Mainnet
Expected behaviour
Report correct block information:
Actual behaviour
Reports always block number "0x0":
Steps to reproduce the behaviour
curl -s http://localhost:8545 -X POST -H "Content-Type: application/json" --data '{"method":"eth_getBlockByNumber","params":["safe",false],"id":1,"jsonrpc":"2.0"}'The text was updated successfully, but these errors were encountered: