Why Developing for the Blockchain is Hard Part 2: Computing Proper Collateral

Many proposed blockchain solutions use verification games, whether informally as in TrueBit and Plasma, or formally as in Alacris.io. In these systems, an important challenge is for the contract to be able to assess whether participants are putting down sufficient collateral to accompany their claims; and this assessment crucially depends on having a good model for the price of gas.

My Name is Bond, Collateral Bond

In a system based on verification games, participants make claims that others may disprove if they are invalid. Each step of the verification game (or “smart lawsuit”) happens by invoking the “smart contract” on the blockchain with parameters detailing the claim (making a “smart legal argument”). If no one successfully counters the claim with a counter-claim within its challenge period, then the claim is considered validated. To punish those who make spurious claims and reward those that prove their claims invalid, participants who make a claim must accompany it with the deposit of a proper collateral. The claimant is bonded and the collateral is his bond, that will be released back to the claimant if the claim is validated, or to the counter-claimant if the claim is invalidated.

In the normal use pattern, an honest participant making a valid claim only ends up paying the price of making the claim, and pays nothing for proving it correct. It is the dishonest participants, making invalid claims or counter-claims, who end up paying by losing their collateral. This “bad guy pays” property makes verification games cheap and attractive. The downside is that the challenge period is a pain for users when it’s too long, and a security issue when it’s too short. However, there is also a crucial difficulty in computing the proper collateral to deposit: it must be small enough not to be an unbearable burden to the honest participants, but large enough to discourage the dishonest claimants and reward their counter-claimants, by covering any gas paid by the counter-claimant.

If there is no collateral, or if the collateral is too low, a bad actor could “troll” or “grief” an honest party with a large number of frivolous lawsuits. The honest defendant might have to spend a lot of money in gas for “smart court fees,” and might be pushed into making exploitable mistakes, revealing information that enables attacks (such as a DoS attacks based on location information), giving up in rage, or going bankrupt. Collateral amounts should be high enough to discourage bad behavior and to award honest participants damage reparations that cover all the cost of litigation: gas costs of getting the transactions in, operational costs of running and securing computers in redundant data centers, insurance cost to deal with the risk and volatility associated with other costs, moral cost of it all.

On the other hand, collateral amounts should be low enough that honest parties of modest means can afford to defend themselves — although one way around this problem is to allow them to sell their claims to a richer party who has time, money and computer resources enough to afford taking the litigation to its conclusion. Another solution would be borrowing funds to use as collateral, but it cannot be implemented purely on the blockchain. If bad actors could even temporarily cause the contract to require overly high collateral bonds, they could possibly prevent the other parties from defending themselves.

Estimating the Gas Price

The main thing that the bond must cover is “smart court fees” for the other party should the current claimant be the losing party. These fees are transaction fees required for the other party to publish their arguments on the blockchain.

In the case of Ethereum, the cost is proportional to the price of gas, which is not fixed in ETH, but floats depending on supply and demand and market manipulation by unsavory miners and transaction posters. Note, however, that the issue is not specific to Ethereum; it is an essential issue of any blockchain. A limited supply of transaction space is a necessary limitation of any public blockchain, because block verification is massively decentralized, which means that block data must fit in the limited network and cpu bandwidth of those who partake in the verification network. Given this limited supply, the economic value of gas (being a fixed fraction of that transaction space) will naturally vary with the demand, in a way that is largely independent from the value of the tokens themselves; therefore the only economically rational way to ration this supply is by letting the relative price of gas vs tokens float. A fixed price would cause artificial scarcity when it’s higher than the free market equilibrium, and long waiting lines when it’s lower.

Thus, transaction fees will float, and the structure of the contract can only tell you how much you have to pay compared to some floating base price. For the smart contract to ensure that claimants post sufficient fees to support their claim, it must therefore be able to compare those fees to some multiple of an appropriate estimate of the gas price or other base price.

It is therefore important for high-level verification-based contracts to be able to predict the price of gas in the near future, the next few hours or days, however long the longest smart lawsuit may take, which can be statically determined from the number of quantifier alternations in the contract clauses times the duration of one challenge period. The prediction does not have to be very accurate, but it must be a strict upper bound on the price of gas in that window, even accounting for unusual volatility in the market and deliberate market manipulation by some sizeable minority of accomplices among consensus miners.

One formula might consist in observing the price of gas over the last few days of fully confirmed transactions; in each block discard the 33% (by gas limit) most expensive transactions and keep the remaining high price; then discard the 33% (by block) most expensive of those prices, keep the remaining high price, but assume it may shoot up five times (or some other multiple of) the volatility observed among the prices not discarded; further multiply by eight, and use that as a gas price basis. The exact formula will have to be devised by someone with expertise in economic or actuarial modelling — the point being that the formula must reliably overestimate how much gas honest people may have to pay to defend themselves, yet not by such a large factor that it becomes unaffordable.

When using a short term contract that itself expires in a few days, the signatories can agree on the price prediction and include it as an explicit parameter during the creation of the contract. A limit to one complaint per participant, or per pair of participant, as applicable, can also put a cap on how much trouble a dishonest participant can wreak if the prediction becomes too low. But what about long term contracts that may manage assets over many weeks, months, or even years, while the gas price may vary wildly? Whatever formula is used will have to be quite elaborate, and will therefore be too expensive for the low-level contract to recompute every time it is invoked. Unless somehow the blockchain’s low-level contract VM itself supports predicting gas according to this exact same formula. Yet, like all computations, the formula for gas prediction can be verified using our usual interactive proof techniques, so updates to the gas price estimate can be made as claims against the contract, and could be included as part of other claims that are part of the distributed application’s regular operations.

A Protocol to Maintain the Gas Price Estimate

If the distributed application includes side-chains, the side-chain operators may update the price estimate, possibly in conjunction with updates to the state of their side-chain. If there are no privileged parties in the long-running contract to regularly maintain the contract state, then some protocol part of the distributed application may designate whose responsibility it is (e.g. each participant in turn in some order) to update the gas price basis next time the previously registered estimate falls out of some safety range, say below 4 times or over 16 times the current price prediction. In some contracts, is also possible that their own selfish interest in other participants not making spurious claims against them will be incentive enough for some participants to spontaneously make claims to maintain the gas price basis within a safe range. An invalid claim will be verified invalid and rejected, and the wrongful claimant will lose their collateral as well as their operator privilege, if any, which should be enough to incentivize the party that denounces them — as long as the last previously confirmed prediction is still a valid upper bound on the gas price.

A further improvement on the protocol may involve building a futures market for gas price. Insurers will offer insurance against rise of the gas price, possibly available for use in verification games only. Users who wish to protect themselves from gas price fluctuations can then avoid the volatility, at a small premium. The mechanism used by MakerDAO to provide a stable coin indexed on the dollar, the DAI, can also be used to provide future GAS at fixed price in either USD or ETH. Insurers can also leverage the “gas refund” mechanism of Ethereum to buy gas in advance, though these refunds can only cover half of the gas of any given transaction.

There is a lot of complexity involved in such a protocol; to track gas price requires carefully watching a full node on the blockchain validation network. Therefore only professionals should partake in the protocol. But, there could be a common verifiable approximate gas price prediction contract on the blockchain, the estimates of which are shared by all contracts that rely on the same formula, as a public service. As part of developing the Alacris Operating System, we will make it possible for all DApps to use the gas price estimates maintained by our DApps, as well as other verifiable oracles for data about Ethereum and other blockchains.

This article is the second in an ongoing series titled “Why Developing for the Blockchain is Hard.” Keep an eye out for our next article about DoS Attacks.