(Cross posted from Imaginea Labs).

The distributed ledger protocol used by blockchains has resulted in systems where we do not have to place trust in particular parties involved in maintaining these ledgers. Moreover the ledgers are programmable with “smart contracts” - transactors whose state changes are recorded and validated on the blockchain. A collection of smart contracts describes a system that is expected to ensure certain invariants relevant to the domain are upheld. For example, an election system is expected to maintain voter confidentiality. While the code that describes these “smart contracts” is open for anyone to read, those who’re participating in the systems run by these smart contracts are not in general competent to evaluate them, with the OSS community being the sole eyes on the contracts being deployed. In this post, I examine how these smart contracts can provide “warranties” that are easier to ratify and describe clear and automatic consequences of violating the warranted properties.

Introduction

When you buy a common appliance like a refrigerator or a car, you as a user do not necessarily understand the details of how they work internally. The only thing you get to see is what they are advertised as being able to do. A refrigerator will certainly be advertised to keep its interiors cool, but may in addition provide properties such as “the set temperature will be maintained to within 0.5 degrees celsius”, “consumes no more than 120W”, or in the case of a car, “gives at least 10 km of travel for every litre of unleaded petrol”.

The consumers purchasing these products have no way to validate what is advertised. They’re often not interested in the specifics of these claims made but only in the fact that refrigerators keep their insides “cool enough” and cars manage to get them to where they want to go without breaking down. These base functionalities are usually warranted for a period of time by the companies that manufacture such products. A warranty runs along the lines of “if your car’s A/C stops working, we will either repair it or replace it free of charge.” That is something that car buyers can easily understand.

Smart contract systems can potentially control much larger sums of money than the cost of appliances and yet they offer no such warranties today. We examine what form such warranties might take.

Warranties for smart contracts

Since contract systems are extremely hard for a normal user to understand, it does seem to be a good idea for contracts to offer similar warranties about the behaviours being claimed. Here I’m referring to them as “warranties for smart contracts” - or WSC for short - so I don’t confuse it with smart contracts that implement real product warranties.

• Warranties for smart contracts are assertions that can be expressed within the smart contracts themselves.

• Invoking these assertions is not part of normal contract flow as running them will incur costs that the contract system may not be willing to place on every transaction.

• A user is free to invoke these assertions for a reasonably small fee to check the claims being made at any point in time.

• If the assertion is valid, then the fee is consumed and the contract call returns true.

• If the assertion turns out to be invalid, then the fee is refunded to the user and the promised remedial action is taken on behalf of the user.

Individual warranties

One kind of such contract warranty is in which a participant in the smart contract system invokes to insure herself of what she’s participating in.

In this case, if the participant suspects that a promise or advertisement made to her is not being upheld, she can invoke these warranties to check them, perhaps even periodically. The fee paid for these checks therefore serves as a kind of insurance against the contract going rogue.

Watchdogs

A second kind of contract warranty is in which a third party “watchdog” is incentivized to check and validate smart contracts and invoke warranties on behalf of its subscribed users. While invoking warranties can be an automatic function of these watchdogs, they may also be systems that validate smart contracts through more elaborate means such as code simulation or having human participants review smart contract code.

Wouldn’t warranties need warranties?

Well, if we’re replacing the task of validating contract code with validating a warranty function in contract code, wouldn’t we need warranties that warrant things about these warranties?

Not really, because warranties are intended to be simple to understand.

Contract code can be complex, but at the end of the day, people who buy into what the contract system is offering will be happy with just a single blanket statement that is clearly to the effect of “if we misbehave, you get your money back”. If a vendor offers a “no questions asked” policy for returns, you’ll be comfortable experimenting with products without having the faintest idea of whether the thinglet you’re buying meet your needs or not.

Warranties could, however, be more fine grained. The more detailed they are, the harder it would be to gain the user’s trust about the contract that they’re protecting the users from.

So what exactly is a “warranty”?

A warranty is a combination of an assertion and a remedial action that can be offered by a smart contract as a function with the following properties -

• The function takes no input parameters.
• It returns a boolean.
• It checks the current state of the contract for a specific violation.
• If no violation occurred, it returns true without changing the contract state.
• If the violation was detected, then it executes a remedial action and returns false. The remedial action will usually have to change the contract state.

Additionally -

• The warranty function may charge a fee for running it.
• On detecting a violation, the fee must be refunded along with the gas required to execute the contract that the invoker paid.
• On detecting no violation, the fee is retained.

These latter properties are flexible. They roughly reflect the real world notion of a warranty where the entity providing the warranty assumes all the cost of executing the remedial action.

An example

The BatteryInsurancePolicy contract supposedly offers a payout if your battery wears out quicker than expected.¹ To achieve that, it must at any time be able to execute the payout. This is usually not a strict property of the system since, of course, suddenly everyone’s batteries might fail right now. However, the low probability of that happening is accounted for by holding enough funds usually decided by regulation.

So it might give confidence to its users to provide a warranty of the form -

function warrantClaim() returns (bool) {
	// We charge you a small fee for doing this so you don't abuse the checks.
	require(msg.value >= warrantyFee);
	
	var userPolicy = insurancePolicies[msg.sender];

	// Validate the user and ensure user hasn't claimed already.
	require(userPolicy.endDateTimestamp != 0 && !userPolicy.claimed);
	
	// ASSERTION: We think our system can ensure that we're very unlikely
	// to run out of money to pay you out.
	if (this.balance > userPolicy.maxPayout) {
		// We're good to payout if you have a problem and you've
		// not already claimed your due.
		return true;
	}
	
	if (this.balance > userPolicy.totalPrice) {
		// CONSEQUENCE: Oops! We don't have enough money if you claim now,
		// but we didn't anticipate that and that's our fault.
		// Sorry! We'll refund your policy price.
		msg.sender.transfer(userPolicy.totalPrice);
	} else {
		// CONSEQUENCE: Shoot! We don't even have your policy price value!
		// Maybe we were hacked! The least we can do is to 
		// transfer all of our balance to you. REALLY SORRY!
		msg.sender.transfer(this.balance);
	}
	
	// Remove the insured from the contract and declare failure.
	delete insurancePolicies[msg.sender];
	return false;
}

With such a warranty in place, the insured don’t need to worry about not being paid, no matter how the rest of the contract was constructed. Of course, even the warranty accounts for the possibility that there may not be enough funds. However, the presence of the warranty indicates enough of a commitment from the policy vendors to give the insured a degree of trust.

Conclusion

Given the financial impact that smart contracts can potential have, it seems to be a good idea to have them provide warranties to increase the trust placed by participants in the contract ecosystem, without having to understand all of the contract code.