Gas Metering: Comparing Appchain Rollups vs. General Purpose Rollups by Felipe Argento | Devcon SEA

Devcon and EF Talks · 26 Feb 2025 · 6:11

Felipe Argento compares gas metering approaches between appchain rollups and general-purpose rollups at Devcon, examining how each model prices computation differently depending on whether a chain is optimized for a single application or built to run arbitrary contracts. He walks through the tradeoffs application-specific chains make to reduce overhead compared to general-purpose EVM rollups. The talk fits within Ethereum's broader modular rollup and appchain research.

Speakers

Topics

From Devcon and EF Talks, hosted by Ethereum Foundation.

Transcript

[Music] so hello everyone I'm Philippi and it's an immense pleasure to be here so thanks for everyone involved at cartesia we've been talking about app chains for a very long time and something that's quite surprising is that we don't hear a lot about gas Ming so I only have 5 minutes but this is my attempt to Kickstart the conversation and maybe maybe give you some intuitions about it so uh there are some reasons uh behind the gas metering system the one that we're interested in in this presentation is gas metering as a defense against resource exhaustion attacks and what do

I mean by that so imagine that ethereum is being attacked uh there's a malicious transaction that is trying to Halt the network or either halt it or slow it down what Would You Do Well you cannot know that the transaction is malicious beforehand because of the holding problem normal servers deal with these with the walk clock so basically you start executing a transaction if it's taking a long time you just ban it or you'll schedule it for later unluckily the walk clock unlike our legal system is not deterministic so we cannot use it because nodes would get confused uh about the validity of transactions so that's a bummer that's why you have the

gas metering system which is basically associating a gas cost to each op code or each instruction that the that that evm transaction executes and this gas cost aims to correctly infer the cost of running that op code on a real computer then we give each transaction an a gas allowance and each block a upper gas limit and we expect the node the reference node to be able to execute a block of gu limit X on time y but what can go wrong because it sounds very simple the problem is is that these estimations are quite hard to do

especially when the architecture that you're emulating differs a lot from the architecture that you're emulating it on which is the case with the evm also it doesn't help that mispriced op codes are quite dangerous and the average case for executing an OP code it's quite different than the worst case for executing it also a quick reminder you have to use the worst case CU otherwise there's a huge security problem on your chain what went wrong so in 2016 I was not around at the time but during Shanghai dcon there was a massive DDOS attack on ethereum uh part of the attack was malicious actors using the

self-destruct opic code to trigger empty accounts and that op code was mispriced uh what made it worse was that attackers were able to deploy custom code to specifically trigger the scenario in which the op code was mispriced and then we had to ask the miners to reduce the gas limit that hurts scalability and we had to hard fork and increase the gas cost of some op codes so let's talk a little bit about app chains so the the difference between app chains and shed rollups regarding the threat model is quite simple on shed rollup we have two possibility of malicious agents you have users that can send malicious data and

you have applications that can send malicious code for application specific rollups the application and the chain are the same thing so the only possibility of attack comes from the malicious users in which can only send malicious code and this is a very important distinction uh just summarizing it real real quick on share chains you have adversarial metering so so the granularity is per op code so you're charging money per op code which is a very small granularity that has a big overhead as you can see on these slides the threat is data and code so that means that it's quite hard to estimate uh the the op code cost and

also that the worst case is much worse than the average case so you can see there the worst case than the average case there's a big difference there and your block size has to be small for oh also uh the re reference computer is quite idle even when the blocks are full in average cuz you you have to go the worst case when your average case is much better on app chains you can actually charge gas per interactions so attack a goblin gather some Loot and the interactions they actually contain millions of instructions so the overhead is much smaller you don't have to calculate the gas cost every single op code the threat model is much easier to

deal with because you can only have malicious data and not malicious code so the worst case it's much closer to the average case which in turns means that we have a much better block size and therefore even more scalability so uh that's it thank you so much and yeah okay cool um there was only one question uh which was how did you become so damn handsome I don't know if you're supposed to answer that I think I know who sent that oh okay cool what about using um oh sorry I got distracted what about using average NR of computer Cycles validators could post

them periodically yeah so the cool thing about app chains is that you can actually customize the best gas metering system for your specific chain so we can even do stuff like cool stuff like subsidize transactions that help the ecosystem you can charge different cently if there's a lot of transactions coming of that type and Etc so that's a possibility for up chains yeah okay cool I think that's everything thank you so much thank you