Efficient Blockspace Allocation Mechanisms

Updates:

  • 10/7/22: Looking at the inherently multidimensional nature of the resources consumed: Block Space paper
  • 5/7/22: Found out about Foundations of Transaction Fee Mechanism Design which has pointers to the wider literature, asks and answers many of the questions I had, and establishes an interesting impossibility result.

The gas cost of different operations is fixed in the code of the clients.

The relative marginal costs of operations are unlikely to be unchanging, given changes in technology and client implementations. The discrepancies between relative gas prices and measures of execution time have already been noted to be an order of magnitude off: Broken Metre: Attacking Resource Metering in EVM.

What would an efficient mechanism look like? Interactions between operations in a transaction, in terms of both the value they provide to a user and the costs they impose on block producers, make preferences not additively separable over operations. A linear price per operation can’t be efficient. So we would like to price the entire transaction. Users could submit their maximum potential payment fee for the transaction, and block producers would then be incentivized to fit as many as they can.

How can block sizes be limited in this world? One option: add a constraint that a block be executable by a given spec machine in a given time. Are there more flexible ways to trade off centralizing pressure and performance?

A naive measure of utility of the network could be the value of the fees being paid. This seems inefficient from a welfare perspective since it would encourage monopolistic pricing of the resources. How can we track something closer to total surplus? Using randomization to estimate elasticities?

Started on April 19, 2022