Increase max_gas_burnt to 300Tgas #305
Replies: 2 comments 11 replies
-
|
I have been working on a way to replay past Aurora mainnet transactions in a local environment where I have control over
Based on these initial findings, it looks like increasing the gas limit will immediately unblock Aurora's partners and therefore is very helpful to us. For continued work on this: I will expand the number of transactions I am checking, and also look in more detail at the gas profiles of the transactions that pass with the 300 Tgas limit to get statistics on what components of the gas cost are most expensive for them when they are allowed to run to completion. |
Beta Was this translation helpful? Give feedback.
-
I'm sorry, I do not understand the question. Compare in what sense?
A more complete analysis of the data is on-going. I will absolutely post here when it is finished. You want a histogram which shows the frequency of gas used by transactions on Aurora if run without any gas limit? I could generate such a plot, yes.
I am not doing any native profiling. The way I run these transactions is via the Aurora Engine compiled to wasm and executing within Near's runtime. I have only change the |
Beta Was this translation helpful? Give feedback.
-
If you replay all transactions from Ethereum from genesis til now - what was the gas usage histogram?
Exactly. because failed transactions don't have a part of the cost - so it's not representative as well.
Can we do the native profiling to see cost split inside the Aurora Engine then? Because currently WASM costs are not detailed enough but I would expect them to be relatively correlated. |
Beta Was this translation helpful? Give feedback.
-
That is a harder task than it sounds. It's something we've worked on before (called the "evm-bully"), but it is blocked on an issue related to checking the correctness of the result on Aurora vs the original result on Ethereum. I suppose we could forgo the correctness check and assume the result is going to be the same on both, but there is still complexity there due to the various Ethereum hardforks over the years so having a correctness check to know the results are accurate would be nice. In any case, I would expect a histogram of gas usage by actual Aurora traffic compared to generated from Ethereum traffic to look very different. This is because the distribution of the kinds of transactions users are doing on the two networks is very different. For example, Aurora is almost entirely dominated by defi-related transactions, while Ethereum has a greater variety of transactions (NFT minting, direct [non-defi] ERC-20 transfers, etc.). Perhaps the argument you wish to make is that looking at Ethereum's traffic will give us an idea of where Aurora is going, even if it is not where it is now. @artob has also made this argument. I agree with the idea behind it, but I think in practice Aurora will look quite different from Ethereum for years to come. So while I agree it is an important endeavor to measure what Ethereum traffic would look like if run through Aurora, I do not think it is an urgent one, so it'll need to stay on the backlog for the short to medium term.
Yes, getting more detailed profiles of the Engine execution is something we are interested in doing. We don't need to do it in native, there are (crude) ways to profile the wasm execution and correlate it with higher level source code. I have done this previously to improve the performance of SputnikVM (see this and this). @mfornet has taken up this work since then and is actively working on it now I think. |
Beta Was this translation helpful? Give feedback.
-
This is understandable, but the point of this exercise is to understand which contract will fit into what limits as more partners come from Ethereum (e.g. can drill down into Aave/Curve/1inch/etc contracts to highlight on average how much NEAR gas they will take). And to give easy benchmark tooling to Protocol Team as they are optimizing various components to easily rerun and see which types of apps are starting to work and how this histogram is changing. May be this benchmark with all of the important contracts from Ethereum under their normal usage actually exists and I just don't know about it? @bowenwang1996 what are guys using right now to benchmark the improvements for Aurora?
Honestly, this answer should have been either "we have done it and it's not useful" or "we going to do it and get back if it's useful". |
Beta Was this translation helpful? Give feedback.
-
|
We at Aurora have started collaborating with @olonho and @nagisa on profiling Aurora as part of the contract runtime team's Q1 OKRs. Their ask was to start with one particular transaction to optimize. I have provided them with a benchmark performing on a multi-hop swap on uniswap. We also have tests that use 1inch. We absolutely want to leverage the expertise of NEAR's team members and appreciate that they are being made available to us. Keeping them unblocked and providing them the resources they need is one of our highest priorities. |
Beta Was this translation helpful? Give feedback.
-
|
Regarding https://github.com/near/nearcore/blob/18558c582165db4bcda1d9d25b93d8ce61c55eba/runtime/runtime/src/lib.rs#L1346 should we actually send the currently left gas in the block as a limit into the execution function as a current limit? This seems like a simple change that can avoid these kinds of issues |
Beta Was this translation helpful? Give feedback.
-
Do you mean doing this while keeping some max_gas_burnt or getting rid of max_gas_burnt? The former would have weird effect: a receipt may fail simply because it is included at the end of the block and if the same transaction is submitted again, it may succeed. This will lead to undesirable developer experience. |
Beta Was this translation helpful? Give feedback.
-
|
It doesn't fail - you just don't include it in processed for this block. Literally next line is "delay_receipt" |
Beta Was this translation helpful? Give feedback.
-
Then essentially you can make a node do work without paying? |
Beta Was this translation helpful? Give feedback.
-
|
The node is budgeted to run for 1Pgas per chunk, that is what all token holders are paying for economically via inflation - remember that tx fees are anti spam mechanism not a payment. So albeit it would mean that if that receipt doesn't fit into the block it will get executed in the next one again so there is a bit of duplicate work - that seems like a better approach that node running for longer. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah that makes sense. This potentially also allows us to increase the maximum gas burnt per function call even further. cc @mm-near |
Beta Was this translation helpful? Give feedback.
-
Currently
max_gas_burnt, which specifies the maximum amount of gas that can be used in a single function call receipt, is 200Tgas whilemax_prepaid_gas, which specifies the maximum amount of gas that can be attached to a function call action, is 300Tgas. With an increasing demand to run larger transactions on NEAR, it behooves us to reconsider these limits that were set several years ago before NEAR was live. I suggest that we increasemax_gas_burntto 300Tgas while keepingmax_prepaid_gasthe same. This should allow us to increase Aurora single transaction capacity by 50% without much downside. One potential issue is that now the maximum amount of gas that can be burnt in one block is 1300Tgas due to this logic https://github.com/near/nearcore/blob/18558c582165db4bcda1d9d25b93d8ce61c55eba/runtime/runtime/src/lib.rs#L1346. However, coincidentally the block speed on mainnet is now 1.3s and therefore the increase inmax_gas_burntis unlikely to cause any issues with block speed.In general, we may want to reconsider how we set these limits. For reference, Ethereum allows a transaction to use the entirety of the block gas limit.
Beta Was this translation helpful? Give feedback.
All reactions