A Mechanism for Pricing Non-fungible Resources: Toward Multi-dimensional Fee Markets

foreign [Music] I think I'm going to steal proof of optimality in this talk from Felix's talk because I really loved that but today we are not going to talk about D5 we're going to talk about multi-dimensional fee markets or kind of the fancy term is how to do Dynamic pricing for non-fungible resources and this is Joint work with Alex Evans True and chitra and guillermaranjaris all right so the first thing I hope to convince you of is that fee markets with the joint unit of account like gas are actually pretty inefficient and what we're going to slowly work towards in this talk is a framework to optimally set multi-dimensional fees so first part of this is like why are transactions so expensive why is having one market not necessarily something that you want to do and first a little bit of an aside um one of the things that we actually do sometimes see with one-dimensional fee markets are these types of denial of service attacks and this is because all op codes have fixed relative prices to each other and whenever you have a potential mismatch between a relative price and the resources that that op code consumes you can get something that takes down a network so these have been termed resource exhaustion exhaustion attacks in the literature and there is a famous one back in 2016 that took down the ethereum network or essentially made it unusable did not take it down but made it very hard to use for quite some time and this was essentially due to a disk read mispricing and of course this was patched in a subsequent EIP but if we had a multi-dimensional rather than a single dimensional Market we might have been able to adjust prices such that there was no need to actually reprice the op codes after the fact however what we're going to concentrate a little bit more on today is um throughput is why having a single dimension Market is actually bad from kind of the network designer's perspective and so this is a very very stylized example that is not at all like close to in practice but I hope it illustrates the idea let's assume that we have a bunch of users that are submitting transactions some only consume CPU some only consume bandwidth the CPU ones have some utility of four so that's kind of how much utility they give to the user that submits it and the bandwidth ones have utility of two and let's imagine we have a block each of these transactions cost one gas the gas price is three and the block can fit four CPU transactions and four bandwidth transactions well in a single dimensional Market what happens we fill this up with CPU transactions but actually we have a lot of block space that's not used because these bandwidth transactions aren't high enough utility and something like this can happen say with like an nft mint however if we have a 2d market and say CPU has that cost of three but bandwidth has a cost of one we would actually end up filling up all the CPU transactions in this block and filling up all the bandwidth transactions as well like I said this is a very stylized example but it does illustrate when you price things separately or in other words if resources are orthogonal they should be priced separately however that of course uh needs we need a mechanism for Price Discovery to do this so how do we decide that you know CPU is three and bandwidth is one or what are those prices uh what do those prices even mean how do we get to those prices and I'm going to do a little bit of an aside in that uh I've been throwing around this term resource a lot and there's a question of like what exactly do I mean by that the working definition we're going to use for this talk is anything that can be metered so a resource is anything that I can say how much of uh this thing a transaction uses so for example um one thing right now roll up data however we could also talk about like kind of big resources like compute memory and storage we could go down to the op code level and think of each individual opcode as a resource however we could also say you know sequences of op codes are resources for instance if you're calling like a hot storage slot versus a cold storage slot that's going to be um cheaper so maybe if we have several storage op codes um all in a row that's actually a different resource than calling these one by one furthermore if we're running uh full nodes on multi-core machines maybe compute on like node or on core one is a different resource than compute on core 2. and and so on you can imagine this is a very general construction resources can be very dependent on each other um and so as long as they can be metered or we can say how much of a trend of a resource a transaction uses uh that fits into our framework so to formalize this and this is kind of where we get a little bit into the math we're going to say a transaction J consumes some Vector of resources and there's so M resources and this Vector is AJ so essentially the ith element of that Vector is going to be the amount of resource I consumed by this transaction J and now that we're uh starting to build blocks we're going to denote this Vector X that essentially is the zero one vector and we have n transactions XJ is going to be one if that transaction is included in a block and zero otherwise so this allows us to very easily write kind of the quantity of resources that's consumed by a given block and we're going to