New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected Panic
Error and Increased Gas Consumption in zkSync Era Transactions
#1260
Comments
This tx is a more extreme example of the curl https://mainnet.era.zksync.io \
-X POST \
-H "Content-Type: application/json" \
--data '{"method":"debug_traceTransaction","params":["0x423cb497f52f5fa40b850f3b83d0c04c184cd92b55a44d84c1bd22aca31096ea", {"tracer": "callTracer"}], "id":1,"jsonrpc":"2.0"}' |
you need to add an input |
@cl3pl4t3 can you elaborate? what do you mean by |
cc: @vladbochok |
Hi @mshakeg
Why do you think that there was enough gas for execution? gas_used < gas_limit is not a strong evidence as some gas is refunded.
Gas per pubdata may fluctuate a lot, so this can't hold. Please refer to https://docs.zksync.io/zk-stack/concepts/fee-mechanism.html for more details |
Hi @perekopskiy
On all other EVM networks that we've deployed to if a tx executes with |
Yes, on zkSync refunds are much higher than on other EVM chains. So, if your transaction runs out of gas you will be refunded some of it (in some cases it can be very close to |
@perekopskiy what's a good practice here for estimating gas then? We have the exact same issue and we use I saw one that Here's our code in web3py for sending transactions, could you please advise on what else we can do? nonce = await self.w3.eth.get_transaction_count(
self.address, block_identifier="latest"
)
unsigned_txn_estimate = contract_function.build_transaction(
{
"nonce": nonce,
"from": self.address,
"maxFeePerGas": hex(100000000),
}
)
estimated_fees = self.zk_w3.zksync.zks_estimate_fee(unsigned_txn_estimate)
unsigned_txn = contract_function.build_transaction(
{
"nonce": nonce,
"from": self.address,
"gas": estimated_fees.gas_limit,
"maxFeePerGas": estimated_fees.max_fee_per_gas,
"maxPriorityFeePerGas": estimated_fees.max_priority_fee_per_gas,
}
)
signed_txn = self.w3.eth.account.sign_transaction(
unsigned_txn, private_key=self.private_key
)
txn_hash = await self.w3.eth.send_raw_transaction(signed_txn.rawTransaction) |
@perekopskiy I see, what is the max gas refund percentage, on Ethereum mainnet it's 50%. |
@mshakeg max gas refund percentage is 100%. |
@perekopskiy does gas estimation work internally? i.e. if I'm estimating gas for calls using a static |
@mshakeg sorry, I don't understand the question |
@perekopskiy so to estimate gas instead of using |
I see, they won't be same but should be pretty close, estimate gas will add intristic tx gas, tx overhead, etc. Note, there are cases where they will differ much, so it's recommended to use |
@perekopskiy hmm, could you please elaborate on the cases where they will differ much? |
|
@mshakeg can we close this ticket, or do you need further assistance? |
@EmilLuta haven't had to test if the issue still persists recently, might have to in future. But if no changes have been made to address this issue I suspect it's still an issue. |
👍👍 |
🐛 Bug Report:
📝 Description
I'm encountering two main issues with transactions on the zkSync Era mainnet.
First, some transactions exit with a
Panic
error such as this transaction, even though they have been allocated sufficient gas for execution. This error occurs under conditions that do not traditionally indicate an out-of-gas situation, as the gas used is significantly below the gas limit specified. Regarding this issue more detail is provided under Additional Context. NOTE: the aforementioned transaction and the 2 transactions mentioned below perform essentially the same operations(with slightly different state that shouldn't significantly change the gas requirement).Secondly, there's a noticeable increase in gas consumption for transactions that execute essentially the same logic(which can be verified by observing similar call traces), observed over a span of 4 weeks, without any apparent changes to the transaction logic or smart contract code or state changes to warrant such a drastic increase in gas cost.
🔄 Reproduction Steps
debug_traceTransaction
method to analyze the transaction.Panic
error in the debug trace and compare gas consumption with similar transactions over time.🤔 Expected Behavior
Transactions with sufficient gas limits should not exit prematurely with a
Panic
error. Similarly, transactions executing the same logic and interacting with the same contracts should have consistent gas consumption, allowing for minor fluctuations.😯 Current Behavior
Panic
error, despite having sufficient gas allocated.🖥️ Environment
📋 Additional Context
The issue was identified through the analysis of transaction outcomes and gas consumption patterns. The
Panic
error was specifically observed in a transaction debug trace, indicating an unexpected termination of the transaction execution.📎 Log Output
I executed the following command to retrieve the debug trace for the transaction exhibiting the
Panic
error:This issue raises concerns about potential underlying problems with gas estimation or execution logic on the zkSync Era mainnet.
The text was updated successfully, but these errors were encountered: