meta-tx gas cost estimation #8114
Comments
|
To figure out the cost split between But disk and network costs aren't reflect well. Network costs and disk write are in completely separate parts of the code. And disk reads in this experiment have the same problem as any IO estimations have today. (See also #5995 and #8214) Based on these imperfect measurements, here is a summary table for what the split between send and exec costs should be (instead of 50-50).
The good news is that most costs have less than 50% of the cost in The stake action is an outlier with almost all costs in Based on this, I would tentatively conclude that we should just charge 2x the send cost to ship meta transactions. We can maybe reduce costs later. Missing data:
|
Add action cost estimations that measure send and exec separately in isolation from all other costs. These new costs do not replace existing estimations. They are only used to inform the decision for send/exec gas split, which today is almost always fifty-fifty. The new estiamtions show that often times the send costs should be cheaper. But we have to be careful before we reduce any costs because we unfortunately ignore network costs in all our estimations. (See near#8214.) The main purpose of the new estimations is to verify the gas cost strategy for meta transactions. (See near#8114.) There, we execute the send step twice, so we want to ensure this side of the action cost is not undercharged. It seems to be overcharged at the moment, so we should be safe to move forward with the proposed strategy.
|
The last two point here are blocked on merging #7497 so I can actually not work on this right now. |
Add action cost estimations that measure send and exec separately in isolation from all other costs. These new costs do not replace existing estimations. They are only used to inform the decision for send/exec gas split, which today is almost always fifty-fifty. The new estiamtions show that often times the send costs should be cheaper. But we have to be careful before we reduce any costs because we unfortunately ignore network costs in all our estimations. (See #8214.) The main purpose of the new estimations is to verify the gas cost strategy for meta transactions. (See #8114.) There, we execute the send step twice, so we want to ensure this side of the action cost is not undercharged. It seems to be overcharged at the moment, so we should be safe to move forward with the proposed strategy.
Add action cost estimations that measure send and exec separately in isolation from all other costs. These new costs do not replace existing estimations. They are only used to inform the decision for send/exec gas split, which today is almost always fifty-fifty. The new estiamtions show that often times the send costs should be cheaper. But we have to be careful before we reduce any costs because we unfortunately ignore network costs in all our estimations. (See near#8214.) The main purpose of the new estimations is to verify the gas cost strategy for meta transactions. (See near#8114.) There, we execute the send step twice, so we want to ensure this side of the action cost is not undercharged. It seems to be overcharged at the moment, so we should be safe to move forward with the proposed strategy.
|
The point with exact gas cost tests is covered in one of my PRs for integration tests. (#8559) The final point, defining the cost of the delegate action itself, is still open. My current thinking is:
|
Base gas cost estimationsApproach 2 + 3 are based on the code here: #8596 Approach 1: TheorySEND: Validation only checks that there is only one delegate action. (Validating inner actions is charged separately from the base.) EXEC: Here the actual checks happen, to ensure the meta transaction is valid.
=> Approach 1 suggests 0 gas send / 210 Ggas exec Approach 2: Measure an empty delegate action in the traditional estimator frameworkIn this approach, the empty delegate action cost is measured and the action creation cost is subtracted from the result. This yields extreme volatility, because both costs move in the range of 1ms. But we can fall back to QEMU based measurements. They aren't as accurate but more stable. Doing this, I get 540k - 580k x86 instructions. Using our 8 instructions / ns norm, this translates to 67.5 Ggas - 72.5 Ggas. Following old practices, we multiply the higher value by 3 for extra safety (=217.5 Ggas) and divide the result evenly between send and exec costs. (= 108.75 Ggas + 108.75 Ggas) Approach 3: Measure exec and send costs separately in estimator frameworkSEND: Again, high volatility, usually betwenn 0 and 50us. But it looks like just measuring noise. EXEC: 71 - 72us with very little variance. Using the usual 3x safety multiplier, we would end up with 216 Ggas Summary
Using 3 completely different approaches, I ended up at a total cost of around 210 Ggas each time. Overall I suggest to go with 200 Ggas in each parameter, knowing that this is probably higher than necessary. But it is still about 11x cheaper than the place holder value. action_delegate: {
send_sir: 200_000_000_000,
send_not_sir: 200_000_000_000,
execution: 200_000_000_000,
}This should also give us some headroom if we need to do more checks on the sender side in the future. |
for estimation data, please refer to near#8114 (comment)
jakmeier
added
A-transaction-runtime
for estimation data, please refer to #8114 (comment)
Meta transactions are interesting for estimation. The key observations are:
sendand anexecpart. This affects all inner actions as well.In the initial implementation we went with the following design:
The reaming work here is:
The text was updated successfully, but these errors were encountered: