-
Team or ProjectSystem has failed L1 transactions Module Affected
Rust Versionnightly-2024-09-01 Operating System
Issue DescriptionI'm running core v27.3.0. It does not take long before I get a "System has failed L1 transaction". I used the block_reverter trying to fix: $ block_reverter print-suggested-values \
--config-path $ZK_CHAIN_CONFIG_ROOT/configs/general.yaml \
--contracts-config-path $ZK_CHAIN_CONFIG_ROOT/configs/contracts.yaml \
--secrets-path $ZK_CHAIN_CONFIG_ROOT/configs/secrets.yaml \
--wallets-path $ZK_CHAIN_CONFIG_ROOT/configs/wallets.yaml \
--genesis-path $ZK_CHAIN_CONFIG_ROOT/configs/genesis.yaml \
--operator-address 0x51CB16Da4E15332a9Fa9e111ec81A7a3F3323B35
Suggested values for reversion: SuggestedRevertValues {
last_executed_l1_batch_number: L1BatchNumber(
33,
),
nonce: 261,
priority_fee: 1000000000,
}
$ block_reverter send-eth-transaction \
--l1-batch-number 33 \
--nonce 261 \
--priority-fee-per-gas 1000000000 \
--config-path $ZK_CHAIN_CONFIG_ROOT/configs/general.yaml \
--contracts-config-path $ZK_CHAIN_CONFIG_ROOT/configs/contracts.yaml \
--secrets-path $ZK_CHAIN_CONFIG_ROOT/configs/secrets.yaml \
--wallets-path $ZK_CHAIN_CONFIG_ROOT/configs/wallets.yaml \
--genesis-path $ZK_CHAIN_CONFIG_ROOT/configs/genesis.yaml
$ block_reverter rollback-db \
--config-path $ZK_CHAIN_CONFIG_ROOT/configs/general.yaml \
--contracts-config-path $ZK_CHAIN_CONFIG_ROOT/configs/contracts.yaml \
--secrets-path $ZK_CHAIN_CONFIG_ROOT/configs/secrets.yaml \
--wallets-path $ZK_CHAIN_CONFIG_ROOT/configs/wallets.yaml \
--genesis-path $ZK_CHAIN_CONFIG_ROOT/configs/genesis.yaml \
--l1-batch-number 33 \
--rollback-postgres \
--rollback-tree \
--rollback-sk-cache \
--rollback-vm-runners-cache
$ block_reverter clear-failed-transactions \
--config-path $ZK_CHAIN_CONFIG_ROOT/configs/general.yaml \
--contracts-config-path $ZK_CHAIN_CONFIG_ROOT/configs/contracts.yaml \
--secrets-path $ZK_CHAIN_CONFIG_ROOT/configs/secrets.yaml \
--wallets-path $ZK_CHAIN_CONFIG_ROOT/configs/wallets.yaml \
--genesis-path $ZK_CHAIN_CONFIG_ROOT/configs/genesis.yamlWhen I then re-start the system, soon batch 34 is created (looking at explorer has Expected BehaviorShould run without encountering failed L1 transactions Current BehaviorIt often enters the "System has failed L1 transaction" error and block_reverter does not help. Repository Link (if applicable)No response Additional DetailsNo response Prior Research
|
Beta Was this translation helpful? Give feedback.
Answered by
ly0va
Apr 25, 2025
Replies: 1 comment 6 replies
-
|
Hi @eierina! You are correct, the transactions from the reverted blocks are not cleared permanently from the DB, but are instead returned to the mempool to be included into future blocks. The reason for that is the server's statekeeper should never create such a block that would be impossible to commit/prove/execute. If it happens, it is a bug that should be investigated (e.g. in-circuit VM vs out-of-circuit VM behavior inconsistency). If needed, the problematic transactions can be deleted manually from the mempool, but that is very rarely necessary. Could you please provide the revert reason of the failing L1 transaction? |
Beta Was this translation helpful? Give feedback.
6 replies
-
|
Thanks for the update @eierina. This looks like an error with the generated proof/public input. Are you running anything custom or is this the default setup? The command to purge the mempool manually so that transactions won't be re-included is: DELETE FROM transactions WHERE in_mempool = TRUE; |
Beta Was this translation helpful? Give feedback.
-
|
@ly0va Running default mainnet setup but using a custom L1 testnet. |
Beta Was this translation helpful? Give feedback.
-
|
weirdly enough: docker exec -it zkhouse-postgres-1 psql -U postgres zksync_server_mainnet_zkchain -c "DELETE FROM transactions WHERE in_mempool = TRUE;"
DELETE 0looks like no transactions in mempool. I did block_reverter steps print-suggested-values, send-eth-transaction, rollback-db, clear-failed-transactions, then lastly DELETE FROM transactions WHERE in_mempool = TRUE; but got zero deletes. |
Beta Was this translation helpful? Give feedback.
-
|
@eierina thanks for the update, can you please try DELETE FROM transactions WHERE miniblock_number IS NULL;
|
Beta Was this translation helpful? Give feedback.
Answer selected by
antonbaliasnikov
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@eierina thanks for the update, can you please try
in_mempooldenotes whether the tx is in the node's in-memory mempool, while the above command should work while the node is offline.