Description
Steps to reproduce:
- deploy the following SC:
// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.7.0 <0.9.0;
contract ZkCounters {
uint256 public count = 0;
// set number and gas limit
function steps100() public {
count = 0;
for (uint i = 0; i < 100; i++) {
assembly {
mstore(0x0, 1234)
}
}
}
function steps1000() public {
count = 0;
for (uint i = 0; i < 1000; i++) {
assembly {
mstore(0x0, 1234)
}
}
}
function steps10000() public {
count = 0;
for (uint i = 0; i < 10000; i++) {
assembly {
mstore(0x0, 1234)
}
}
}
}
- estimate counters for each method
{"jsonrpc":"2.0","id":1,"method":"zkevm_estimateCounters","params":[{"From":"0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266","Gas":"0x1c9c380","GasPrice":"0x989680","Input":"0x018b0aa6","To":"0x0c3dCa7865203A9bbdC83942a3f1B1567D331Aa6","Value":"0x0"}]}
{"jsonrpc":"2.0","id":1,"method":"zkevm_estimateCounters","params":[{"From":"0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266","Gas":"0x1c9c380","GasPrice":"0x989680","Input":"0x173fcd38","To":"0x0c3dCa7865203A9bbdC83942a3f1B1567D331Aa6","Value":"0x0"}]}
{"jsonrpc":"2.0","id":1,"method":"zkevm_estimateCounters","params":[{"From":"0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266","Gas":"0x1c9c380","GasPrice":"0x989680","Input":"0x44446453","To":"0x0c3dCa7865203A9bbdC83942a3f1B1567D331Aa6","Value":"0x0"}]}
Actual result:
The response has the countersUsed.steps
equal for all methods execution.
Expected result:
The response should have the countersUsed.steps
different for each method, given the number of operations.
Metadata
Assignees
Labels
No labels
Activity
praetoriansentry commentedon Jan 29, 2025
I took a look at this one. Adding some addition details.
SMT Depth
The method
getSmtDepth
has a bug which will cause it to always return0
instead of the value returned byhermezDb.GetClosestSmtDepth(blockNum)
. In the code below, the assignments on lines 313 and 317 don't actually impact the value returned in the end becausesmtDepth
is declared twice and shadowed.cdk-erigon/turbo/jsonrpc/zkevm_counters.go
Lines 302 to 322 in 2a22c67
Example Case
On the Bali network, the transaction
0x6d0f4b598c1ac7f0c294e1b79534359ed4324e3065cd7e0ff0377d7b1077498e
takes up an entire batch. The batch the batch has only a single block. If I rundebug_traceTransactionCounters
these are the counter values I get:These values make sense to me because the test is meant to push the poseidon counters and this is very close to the limit of
1028275
.The issue is, if we use
zkevm_getBatchCountersByNumber
to check the counters for this batch, we get very different numbers:The amount of gas used looks right and aligns with the receipt:
1386010
. But the other counters do not look right. If there were so few counters used, I assume the batch would not have been closed with one block in it.As far as I can tell, both
zkevm_getBatchCountersByNumber
andzkevm_estimateCounters
make use of the methodBatchCounterCollector.CombineCollectors
defined here:cdk-erigon/core/vm/zk_batch_counters.go
Lines 218 to 271 in 5626125
It seems like this method collects counters for blocks, l2 data, rlp, and stuff like that, but I'm not seeing where it actually accounts for the counters used by transactions. There is a similar function in the package called
CombineCollectorsNoChanges
which seems to add transaction counters:cdk-erigon/core/vm/zk_batch_counters.go
Lines 296 to 305 in 5626125
If I switch to using this method, I can see the counter value increases a lot but seems to be about 3x higher than expected.
tclemos commentedon Jan 29, 2025
Complementary to this, I can have a TX mined using Bali, but when I estimate its counters, I get an
out of gas
issue.Steps to reproduce:
GasLimit=30000000
(this is the TX on Bali 0xfb47aafffe6a281aa0707b3a3f2da292e660bb97158463d7c06abb56439364cb)zkevm_estimateCounters
Here are the logs showing the response I'm getting from the zkevm_estimateCounters for this test:
This shows the counters:
This shows the TX was already mined, as we have
blockHash
andblockNumber
in the response foreth_getTransactionByHash
revitteth commentedon Jan 29, 2025
Thanks for all the detail! Working on it now :)
tclemos commentedon Feb 12, 2025
Any news about it?