Network bandwidth gas estimations #8214
Labels
A-network
Area: Network
A-params-estimator
Area: runtime params estimator
A-transaction-runtime
Area: transaction runtime (transaction and receipts processing, state transition, etc)
Comments
jakmeier
added
A-transaction-runtime
|
Worth pointing out: Data dependencies could be particularly expensive. But in today's data receipt estimations we only look at the cost to create it, store it, and load it again. No cross-shard delays (avoidable or unavaoidable) are considered. |
jakmeier
added a commit
to jakmeier/nearcore
that referenced
this issue
Dec 20, 2022
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.
near-bulldozer bot
pushed a commit
that referenced
this issue
Dec 22, 2022
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.
nikurt
pushed a commit
to nikurt/nearcore
that referenced
this issue
Dec 23, 2022
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
According to the original whitepaper, network costs are also to be paid by gas. This makes sense to me. But reality is we have never measured any such cost.
Up until sharding phase 1, this wasn't a big deal anyway. As long as all validators track all shards, the network delay for cross-shard traffic does not delay block or chunk production. But in sharding phase 2, chunk producers will have to wait for cross-shard receipts. For that, we need to somehow measure the network cost of traffic for transactions and ensure it does not become a bottleneck.
The text was updated successfully, but these errors were encountered: