Gas Metering and Use on Casper | CasperLabs

Introduction

CasperLabs aims to build the world’s best cryptocurrency platform for real business. Our feature set explicitly targets compatibility with existing business processes, such as complex forms of internal financial controls and enterprise development toolchains. However, one of the greatest obstacles to enterprise adoption of public blockchain technologies is perceived to be the unpredictability and volatility of Ethereum-like gas markets. Gas, of course, is the oil of blockchain, and, in this blog post, we will explore what gas is, why it is here to stay and how we intend to make users’ experience with gas less frustrating.

Resource accounting

The general principle we must start with is that any finite resource on a publicly accessible computer network must be rate-limited. Any resource made available without limit to anonymous participants is a denial of service attack vector. This is a security argument for rate limiting, but an argument for any particular form of rate limiting has to appeal to economics. The simplest economically-justified means of rate limiting is performed by Ethereum, which allows users to bid on the key blockchain resource.

The resource in question, in this blog post, is computation time. Casper blocks must be produced on a relatively predictable schedule, and only so much computation can be performed between blocks. Because it is not technically feasible to credibly monitor time use of a particular computation on a particular machine, blockchains use the abstraction of gas. Gas is a measure of relative time used by different primitive operations of the virtual machine at the heart of a blockchain. The measure is relative because the abstraction implicitly assumes that if operation A takes one unit of time and operation B takes three, this ratio remains roughly the same on any machine building blocks on the platform. Further, it is also implicitly assumed that these costs are additive, or that the relative time costs of different virtual machine programs can be measured by adding up the individual gas costs of the sequence of primitive operations they perform.

Casper assigns gas costs both to primitive WASM opcodes and to certain more complex “host side” functions that are callable from within the WASM virtual machine context. Costs for individual operations can depend on arguments, while operations that store data in global state assign a gas cost to bytes. These costs are part of the platform definition and are loaded directly from the chainspec, a configuration file that defines each particular instance of a Casper network.

Economics of gas

The Ethereum model is attractive as a starting point. A gas auction tends to allocate gas to parties that have the highest value for performing computations at any given time. Unfortunately, the direct consequences of having this singular market are extreme volatility and astronomical prices in times of high demand for highly valuable, typically DeFi-like, computations. This makes blockchains unusable for traditional businesses.

The apparent difficulties posed by the apparent downsides of allocating gas to highest value uses, however, can be resolved by adding more markets, or perhaps by partially converting price volatility into time to execution volatility by using variable block limits (as a certain Ethereum proposal suggests). These proposed market mechanisms are complex and require significant research and design work to make sure they do not introduce new existential problems for businesses, while keeping user experience comfortable.

The solution Casper chose for mainnet launch is unorthodox and requires an explanation. We retain most of the infrastructure for operating a first-price gas auction, with separate “lanes” for native transfers and general computations. However, we will not be implementing the auction, leaving this decision to the validators. Instead, we will launch with a basic first-in, first-out priority system, or a simple queue. While this is not economically efficient, it poses only a low risk of denial of service attacks and provides casual users ready access to the platform at minimal cost, at least until serious congestion develops. However, we fully expect the problem of gas allocation to be solved by the time congestion becomes a problem.

Who pays for gas and who gets the payment?

Payers only need to specify the amount of motes (smallest definable sub-units of the token) they will pay for their computation when using the client. While functionality to specify a gas price is retained for future use, it is best left set to a default of one mote per unit of gas, as it does not affect the priority of deploys. Note that Casper will not refund any amount of unused gas. This is a necessary consequence of the consensus-before-execution model Casper employs, where block contents are determined before execution takes place and true gas use becomes known. Allowing refunds would enable malicious agents to fill the blocks with deploys that have a large claimed gas use, at no cost. Additionally, this incentivizes users to estimate their true gas use, eventually minimizing wasted gas in each block. If a computation runs out of gas before termination, it is reverted. All fees go to the proposer of the protoblock that lists the deploy. Eventually, we expect this to become a significant source of revenue for validators.

Potential future changes in pricing

CasperLabs is committed to working on our gas market futures concept, which should allow businesses to reserve gas ahead of time at known prices, as well as a link to fiat that will eliminate cryptocurrency price volatility risk from business budgeting decisions. The community may choose to implement the simple first-price gas auction, mostly equivalent to the one used by Ethereum, after mainnet launch, using retained infrastructure in the codebase.