Ethereum contracts, is the design viable?
I went to a workshop run by Ethereum today, to learn about cryptocurrency/virtual currency from a developer’s point of view. Ethereum can be thought of as Bitcoin+contracts; they are also doing various things to address some of the design problems experienced by Bitcoin. This article is about the contract component of Ethereum, which is being promoted as its unique selling point.
The Ethereum people talk so much about contacts that I thought once currency (known as ether, a finney is a thousandth of an ether, with other names going down to 
) had been mined it was not considered legal tender until it was associated with the execution of a contract. In fact people will be free to mine as many ethers as they like without having any involvement with the contract side of things.
Ethereum expect the computational cost of mining to be significantly greater than the cost of executing contracts.
A contract is a self-contained piece of code created by a client and executed by a miner (the client pays the miner for this service). The result of executing the contract is added to the data associated with a block of mined currency (only one contract per block).
How confident can the client, and interested third parties, be that the miner paid to execute the contract is telling the truth and didn’t make up the data included in the mined currency block?
The solution adopted by Ethereum is to require all miners involved in the execution of contracts to execute all contracts that have been associated with mined currency, so that the result posted by the miner who got paid to execute each contract can be validated (51% agreement is required).
For this design to work, the cost of executing contracts to verify the data produced by other miners has to be small relative to paid income received from executing contracts.
If somebody is in the ether mining business, executing contracts has the potential to provide additional income for a small increase in effort, i.e., the currency has been mined why not get paid to execute contracts, adding the resulting data to blocks that have been mined?
Ethereum has specified the relative cost of operations executed by the Ethereum Virtual Machine. The Client specifies a value used to multiply these costs to produce an actual cost per operation that are willing to pay.
Requiring the community of contract executors to execute all contracts creates a possible vulnerability that can be exploited.
To profit from executing contracts the following condition must hold:
where: 
is the ratio of unpaid to paid contracts, 
is the average number of operations performed per contract, 
is the average execution cost per operation and 
is the average amount clients pay per operation.
This simplifies to:
What would be a reasonable estimate for , the ratio of unpaid to paid contracts? Would 1,000 miners offering contract execution services be a reasonable number? If we assume that contracts are evenly distributed among everybody involved in contract execution, then there are disincentives of scale; every new market entrant reduces income and increases costs for existing members.
What if businessman Bob wants to corner the contract market and decides to drive up the cost of executing contracts for all miners except himself? To do this he enlists the help of accomplice Alice as a client offering contracts at extremely poorly paid rates, which Bob is happy to accept and be paid for appearing to execute them (Alice has told him the result of executing the contracts); these contracts are expensive to execute, but Bob and Alice know number theory and don’t need a computer to figure out the results.
So Bob, Alice and all their university chums flood the Ethereum currency world with expensive to compute contracts. What conditions need to hold for them to continue profiting from executing contracts?
Lets assume that expensive contracts dominate, then the profitability condition becomes:
where: 
is the increase in the number of contracts, 
the increase in the average number of operations performed per contract and the increase in average execution cost per operation.
This simplifies to:
What values do we assign to the three multipliers: 
? Lets say 
, which tells us that the price paid has to increase by a factor of 150 for those involved in the market to maintain the same profit level.
Given that Ethereum are making such a big fuss about contracts I had expected the language being used to express contracts to be tailored to that task. No such luck. Serpent is superficially Python-like, with the latest release moving in a Perl-ish direction, not in themselves a problem. The problem is that the languages is not business oriented, let alone contract oriented, and is really just a collection of features bolted together (the self absorbed use case for the new float type: “… elliptic curve signature pubkey recovery code…”, says it all). Another Ethereum language Mutan is claimed to be C-like; well, it does use curly brackets rather than indentation to denote scope.
If Ethereum does fly, then there is an opportunity for somebody to add-on a domain specific language for contracts, one that has the kind of built in checks that anybody involved with contracting will want to use t prevent expensive mistakes being made.
So, what this misses is that there is a per-block gas limit, which is targeted to be 1.2x the long-term exponential moving average of the amount of gas used in blocks. This mechanism is critical; without it, the system would indeed spiral off horribly as you describe.
Now, suppose that p percent of miners are trying to DDoS ethereum by making fake contracts, using shortcut algorithms to execute them themselves as you describe. Let T be the level of “legitimate” gas usage and let L be the gas limit.
In the long term we have the equation:
L = 1.2 * (p * L + (1-p) * T)
Which simplifies to:
L = 1.2 * p * L + 1.2 * (1-p) * T
L * (1 – 1.2p) = 1.2 * (1-p) * T
L = 1.2T * (1 – p) / (1 – 1.2p)
Which only spirals off into infinity if p > 0.83, at which point you have a 51% attack anyway.
PS. Your captcha system is utterly terrible.
@Vitalik Buterin
I appreciate that there are various limits in place to prevent resource costs spiraling out of control.
An attacker motivated by financial gain, or destroying the market, is interested in deterring others entering the market. The motivation for others is profit from executing contracts; the number of people who have other motivations (i.e., altruistic) is not likely to be large enough to ensure smooth operation of the consensus algorithm.
The rough estimate multiplier that changes the profit requirement from:
N*(E/P) < 1 to: 150*N*(E/P) < 1 may be enough to deter miners entering the contract market. By "utterly terrible" I hope you mean you had to scratch your head to figure it out. It does stop most spammers in their tracks, but it probably deters a few legitimate commenters 🙁
> An attacker motivated by financial gain, or destroying the market, is interested in deterring others entering the market
Right, and my argument is that an attacker would have to have 83% of the hashpower in order to have a very large effect. Otherwise, if an attacker has (or is colluding with) 25% of the hashpower, then my argument is that the attacker will indeed be able to deter computation that 25% of the time, but the other 75% of the time the attacker would have to pay the same gas fees as everyone else, so the attack would be rather expensive.
> By “utterly terrible” I hope you mean you had to scratch your head to figure it out. It does stop most spammers in their tracks, but it probably deters a few legitimate commenters 🙁
Actually, I gave up on the first two I got that involved 0b0ll0 as I could not figure out what that was supposed to mean, and just kept hitting refresh until I got an easy one involving arithmetic. So maybe my IQ is not high enough to post here 🙂
@Vitalik Buterin
The attack is very cheap for accomplice Alice because she specifies a gas multiplier so low that only only businessman Bob is willing to execute the contract, who in turn does not pay the cost-to-him price of executing it because he knows what the result is. Bob can charge Alice a suitably small fee, or an estimate of the actual cost and receive a refund via another channel.
Perhaps a miner who randomly chooses to offer to execute a very low prices contract, every now and again, will deter Alice since she may then have to pay the true cost. I will do some sums.
If only Bob&Alice are manipulating the system and have a small share of the market, then the relation becomes:
keeping with:
as 10*3, and, say 
at 3.3% of total market, giving a reduction from 150 to (0.033*30+1) -> 2, i.e., somebody with 3.3% of the market can double the profitability requirement of all other market participants.
I suspect it is your age rather than your IQ that caused you to give up on 0b0ll0. Most older folk have encountered binary literals, which are not so common these days.