-
Team or ProjectNo response Module Affected
Rust Version1.84.1 Operating System
Issue DescriptionI follow the zkStack documents and started the new zkChain (all the sequencer and prover components) running on the Sepolia testnet with the base token is my ERC20 token. The installation was with the new shared bridge. All services were up and seem running fine until I bridge the ERC20 token. Here is the brief of log messages:
Here are the logs:
2025-02-28T17:28:14.156090Z INFO run_routine_task{service_name=L1BatchMetricsReporter}: zksync_db_connection::instrument: Slow query get_sealed_l1_batch_number called at /root/amplifydigital/zksync-era/core/lib/dal/src/blocks_dal.rs:118 [requested by house_keeper at node/house_keeper/src/blocks_state_reporter.rs:27] has finished after 124.584947ms 2025-02-28T17:28:14.197757Z INFO zksync_metadata_calculator::updater: Next L1 batch for Merkle tree: 1, current Postgres L1 batch: L1BatchNumber(0), last L1 batch with metadata: Some(L1BatchNumber(0)) 2025-02-28T17:28:14.198517Z INFO zksync_metadata_calculator: Merkle tree is initialized and ready to process L1 batches: MerkleTreeInfo { mode: Full, root_hash: 0xd8c9be7efb705e7dcf529c14fce7048ea99dea9eab6a6b4e5f8de1ebf4f2ebf2, next_l1_batch_number: L1BatchNumber(1), min_l1_batch_number: Some(L1BatchNumber(0)), leaf_count: 67 } 2025-02-28T17:28:14.198543Z DEBUG zksync_health_check: Changed health of 2025-02-28T17:28:14.198565Z INFO zksync_metadata_calculator::updater: Initialized metadata calculator with 20 max L1 batches per iteration. Next L1 batch for Merkle tree: 1 2025-02-28T17:28:14.218712Z WARN zksync_base_token_adjuster::base_token_ratio_provider: No latest price found in the database. Using default ratio. 2025-02-28T17:28:14.266368Z INFO zksync_vm_executor::storage: Getting previous L1 batch hash for batch #0 2025-02-28T17:28:14.316980Z INFO zksync_state_keeper::keeper: Starting state keeper. Next l1 batch to seal: 1, next L2 block to seal: 2 2025-02-28T17:28:14.316984Z INFO zksync_state_keeper::keeper: There exists a pending batch consisting of 1 L2 blocks, the first one is 1 2025-02-28T17:28:14.335043Z INFO zksync_state_keeper::keeper: There is a protocol upgrade in batch #1, 2025-02-28T17:28:14.335095Z INFO access_storage{l1_batch_number=L1BatchNumber(0)}: zksync_state_keeper::state_keeper_storage: RocksDB cache (initial state: InitialRocksdbState { l1_batch_number: Some(L1BatchNumber(1)) }) doesn't need to catch up to L1 batch #0, waiting for it to become available 2025-02-28T17:28:14.335819Z DEBUG access_storage{l1_batch_number=L1BatchNumber(0)}: zksync_state::storage_factory: Catching up RocksDB synchronously Caused by: We are scratching our head for 2 days... Expected BehaviorThe bridged transactions got processed successfully to L2 and the proof is saved to L1 Current Behaviorstate_keeper crashes with error "Failed to publish pubdata via L1Messenger for: Error function_selector = 0x, data = 0x" Repository Link (if applicable)No response Additional DetailsNo response Prior Research
|
Beta Was this translation helpful? Give feedback.
Answered by
cytadela8
Mar 6, 2025
Replies: 2 comments 4 replies
-
|
Hi, I have some questions about your setup:
Please mark as unanswered when you comment with the answers |
Beta Was this translation helpful? Give feedback.
2 replies
-
ecosystem_contracts: native_token_vault_addr: 0xf787037ffebd82afa23936c833838930ad33bb52
|
Beta Was this translation helpful? Give feedback.
-
|
So it's kind of hard to debug such issues unfortunately. Some things/possible reasons I see:
Overall I would recommand to redeploy your chain as it broke immediately after deployement. This will be the fastest solution here. I would like to encourage you to exercise deploying chain to local reth node if you did not do this before. Please mark this an unanswered if you have further questions. |
Beta Was this translation helpful? Give feedback.
-
|
I followed your recommendation and redeployed a branch new chain with the new ecosystem, new chain ID. I still used the same wallets.yaml file. Noted that during the deployment, I got the errors about "Root hash mismatched" & "Commitment mismatched" between calculated value and in genesis.yaml config file. After I update these values in the genesis.yaml file and re-run the failed command, the deployment went through. However, when I run the server for the first time, it crashed immediately with the error message: "ERROR zksync_node_framework::service: Task eth_tx_manager panicked: We can't operate after tx fail". Should I open this new error in a new discussion thread? Here is the logs: |
Beta Was this translation helpful? Give feedback.
2 replies
-
|
We figured it out. The error with new deployment was because of the genesis block tried to look back in the blockchain and add previous transactions to it (Most probably they are transactions related to the operator wallet we reused ?!?) We fixed that by temporarily setting the constant |
Beta Was this translation helpful? Give feedback.
-
|
Hi, glad you were able to find a workaround, overall I would like to end this with 2 points:
|
Beta Was this translation helpful? Give feedback.
Answer selected by
cytadela8
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi, glad you were able to find a workaround, overall I would like to end this with 2 points: