2

I'd like to know the EVM gas limit of a single node with modern computing specs. My understanding is that the current gas limit of Ethereum(15m/block or 1m/s) is constrained such that all nodes in the network can verify blocks, hence why more centralised networks such as BSC can have a larger gas limit of ~80m/block or ~27m/s(given a ~3s block time) which is ~27x the Ethereum gas limit. So what would the EVM gas limit be if the network comprised of a single high-performance node?

My understanding is that there are multiple EVM implementations some more performant than others, e.g. Hyperledger Besu EVM > EthereumJ EVM.

4
  • Is the assumption that block time stays the same? If not, a block can take a year and you can have loads of operations. May 13 at 7:50
  • @LauriPeltonen Well the metric is gas per second(gas/s), so Ethereum currently has a gas limit of 15m per block and since the block time is 15s, this equals 1m/s and BSC has 27x this capacity as I described in the question. Hope that makes sense.
    – MShakeG
    May 13 at 12:15
  • I think I understand what you're after, but you need to consider also other factors, such as network difficulty. That plays a big role in the block time - most of the time is not spent on executing transactions, but on solving the PoW puzzle. Or if you choose to ignore the PoW part and are just interested in processing power, then this question is not a very good fit for this community. May 13 at 12:20
  • @LauriPeltonen hmm, why wouldn't it be relevant to this stack exchange? since it's an attempt at understanding the performance of the EVM. I'd like to know if for example running a centralised exchange backend developed in solidity and executed on an EVM is of more or less equal performance to say Coinbase.
    – MShakeG
    May 13 at 12:33

2 Answers 2

1
+50

There's no intrinsic limit; it depends on the hardware and the software implementation.

What limits the EVM is the design choice of the specific community that uses the EVM, because there is always a trade-off between decentralization and performance.

On one side, there's the full centralization. This lets you control all the data and operations and apply all the scaling mechanisms you want to increase the performance. Usually, you split the workloads in parallel to use multiple CPUs and DBs. The amount of gas/sec is only limited by your willingness to spend money on more hardware.

On the other side, there's the full decentralization. This is a game you play with all the other peers, so you need the lightest workload possible to achieve that, so literally, anyone can run it and stay in sync with all the other nodes. Not considering PoW for consensus but only computing power to validate blocks, Bitcoin is a masterpiece on this side: at maximum, your machine needs to elaborate ~1.5Mb of data every ~10 minutes.

In between, there are all the other choices between performance and decentralization. Ethereum poses that choice to a ~15 sec per block, with a max of 30M gas per block (15M gas target, dynamic up to 30M max). This limit is what now (mid-may 2022) the community considers a good balance between speed, decentralization, TPS, and security.

But I also remember when, years ago, the max gas per block was 3.1M, then 4.7M ;) And a lot of people were against more raises to 8M, 10M, etc. Even though a raise alleviates the need to have more space for more applications, you also leave behind more and more nodes that cannot sync without proper hardware - an NVMe SSD is currently mandatory if you want to stay in sync with the network - and you move the decentralization bar towards the centralization.

Note: Vitalik set this as a trilemma, not a dilemma, adding security as one of the elements to consider. For the sake of simplicity, I think this can be left out of the discussion.

7
  • Thanks for the answer, however I think it gives a wholistic explanation regarding how the gas limit is chosen for a given network and not the theoretical gas limit a particular EVM implementation can handle when run on a modern high-end computer. If gas is a primarily a function of "computational work"(as I understand, hence why OPCODEs that require more computationally cost more gas), then if a machine can process X "computational work" you should be able to calculate the amount of gas it can handle Y.
    – MShakeG
    May 17 at 5:56
  • The answer is "there's no intrinsic limit" ;) The explanation wants to detail why. EVM is not an implementation, it's a standard to be implemented, so maximum speed depends on the hardware and the software. How much the software is efficient depends on requisites and the specific implementation. And GAS is not an exact measure of the computational cost, it's just an approximation, real computational cost depends on the implementation. Think of that as if you are asking: "What is the maximum number of sha256sum a machine can handle?" May 17 at 10:36
  • I see, but if you thought about "What is the maximum number of sha256sum a machine can handle?" you could get an estimate like x many TH/s on a particular ASIC model running a particular miner software. So following the same logic couldn't you get an estimate like x gas/s running the Geth EVM on a given EC2 instance?
    – MShakeG
    May 17 at 10:54
  • 1
    You can, but it does not answer your question :) Anyway, if you want an idea of Geth's EVM performance, you can see it directly in the log while it's syncing. As a reference, my laptop (i7-10750H CPU @ 2.60GHz - 32 GB DDR4 3200 MHz - PC SN530 NVMe WDC 512GB, workload among 6 core/12 threads makes each thread busy ~20-40%) runs at 200M~400M GAS per second, peaked ~680M GAS. Again, the computation is limited by the HW and the design choices, based even on other requisites considered during the development, not only performance. Geth was not meant to be an execution layer, but only recently ;) May 17 at 12:58
  • Thanks, so should I reword my question more along the lines of performance benchmarks for different EVM implementations across a variety of ec2 instance types? If you're getting 680m gas/s on Geth, the the Besu EVM could probably sustain at least 1B gas/s as from what I've heard Besu is the most performant EVM.
    – MShakeG
    May 17 at 13:38
0

I think that you may only get an accurate answer by testing this in practice.

One important variable to consider is if your blocks are consistently full for a long period of time or if you only have occasional bursts of full blocks. Even a sub-par server will be able to handle a burst of full blocks, while sustained congestion will cause the node to lose sync.

Experience of running BSC nodes in times of very high congestion

Here is my practical experience with running multiple BSC nodes with different specs.

BSC has a max gas limit of 100M gas per block (when the network is congested), with a block time of 3 seconds, which is likely the highest gas EVM chain. That approximate to 33M gas per second.

In November 2021, the max block limit of 100M gas was reached and sustained for several weeks. At this time, a very large number of nodes became unable to keep sync, including validator nodes. Upon investigation, it was found that the hardware bottleneck is storage, specifically random I/O read and write speed.

At this time, all my nodes that did not have dedicated last-generation NVME SSD were periodically falling out of sync. Only my nodes with the latest dedicated NVME SSD could keep up without issue (example of working SSD that I tested are Samsung 980 Pro and Firecuda 530).

Approximation of current limit

I do not have a precise answer to your question, and even if there was an answer, it would change over time as SSD technology improves.

33M gas per seconds can be sustained with the latest generation NVME SSD in a real POA network with few reorgs.

You could increase that performance on a theoretical network with a single validator node (no reorg), no network latency between nodes (no block/tx propagation delay) and by using Intel Optane storage (fastest storage available).

My guess is that even under this ideal scenario you would not be able to go very far above 33M gas per seconds given that your nodes storage is the bottleneck and BSC has already almost reached that when the network is congested for a sustained period. Perhaps 50M or 60M gas per seconds would be a reasonable estimate to try.

4
  • Thanks for the answer. From what I've gathered the gas/s limit is in excess of the BSC gas limit of 33m gas/s, but you don't know the limit on a network comprised of a single high-performance node in addition to the gas limit across varying EVM implementations on that network. For example the Besu EVM can operate at 672m/block with a 2 second block time(336m gas/s) in a 5 node network(hyperledger.org/blog/2020/08/06/…) which is ~10x the gas bandwidth of BSC. And presumably higher on a single node network.
    – MShakeG
    May 15 at 8:52
  • Yeah but as you can read in the blog post, it also depends on the state size. Presumably, their state was very small in their test since it was a new blockchain. The larger the state, the slower it is to query the database. BSC has a pruned state in excess of 1.5Tb, so that contributes to slow things down. I know that you can find on github a c++ implementation of the geth evm, which is supposed to be faster than go, which is another variable to consider. TBH, I don't think that there is a clear answer to your question because there are too much variables in play.
    – Undead8
    May 15 at 16:49
  • fair enough, but couldn't the same argument be made about traditional backends? Or does the performance of Coinbase's order book matching engine degrade with time? My understanding is that it doesn't at least not significantly, so why would a similar engine implemented in solidity degrade?
    – MShakeG
    May 16 at 15:13
  • I can't answer that question from a technical perspective, but I can tell you that for bsc there is a very noticeable impact on performance as the database grow (for instance in-between prunings)..
    – Undead8
    May 16 at 21:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.