ENS components, the bidding process, and "stale" bids

(This article has been extracted from an upcoming one, as it is somewhat off-topic to the issue discussed there, and overly verbose at that.)

Grossly over-simplified, the Ethereum Name Service is a set of contracts that allow looking up an Ethereum address when given a “name”.

For a human, an address is hard to memorise, but a name is not. For a machine, names are unwieldy, since they vary in length, and are non-homogenous as a set in many other ways.

Specification(s) and clients

• The ERC 137 finalised standard, detailing how human-friendly names (strings) are to be translated to machine-friendly keys (of 32 bytes), along with other details.
• The EIP 162 proposal, describing an approach for name registration.
• ens-registrar-dapp, a browser-based client by the developers of ENS for name registeration and related tasks.

Note that by now, there are many other clients for interacting with ENS.

Some, such as ethers-ens, are stand-alone, tailored specifically for interacting with ENS from the command line.

Others, such as MyEtherWallet, are part of a larger “wallet” software package, meant for casual use by reasonably well-informed users.

Yet others, such as ens-chrome-extension, focus on easy name resolution for next to everybody, without unnecessary details (such as how to acquire one).

Implementation blocks

A lightning talk video (11 minutes) is available that explains the below in a very accessible manner.

The ENS contracts work as a system, with the primary components being:

• The Registry (source), a data store linking keys of 32 bytes to an “owner” address, a “resolver” address, and a “time-to-live” integer value. An entry in this store is called a node.
• The .eth Registrar (source), which allows claiming ownership of a node by participating in an auction. The winner of an auction gets the rights to modify the node.
• The Deed contracts (source), an utility to segregate user funds during and after an auction. A Deed hadles one bid, and can only be interacted with by proxy, through the Registrar that created it.
• A Public Resolver (source), an “example” interface for setting and retrieving data about a node. The data in this particular case is an address that the node resolves to, and/or a content hash (e.g. A Swarm/IPFS link). Custom Resolvers are also possible.
• The .reverse Registrar/Resolver (source), which allows owners of an Ethereum account to link an ENS node to it, and others to look up such links.

The system is experimental, and soft-scheduled for an upgrade within 2 years. A hard limit of 4 years has also been set, at which point the .eth Registrar will no longer allow new auctions, thereby forcing an upgrade if it hasn’t been done by then, or obsoletion.

See the FAQ for many more details.

.eth Registrar auction structure

The auction is a “blind” Vickrey-style one, divided into two stages.

During the “bidding” stage, participants are expected to submit “sealed” bids, without knowing what others bid. The latter is achieved by not sending the bid info in clear text, but hashing it with random data called “salt” that only the bidder knows, and submitting the result of that operation.

In effect, the fact that a bid has been placed becomes publicly known, but the rest does not.

The sealed bid has ether attached to it. It can contain more ether than the bid, to “conceal” the “actual” bid amount.

During the “reveal” stage, previously submitted sealed bids are made public. That is done by making public the name that the bid is for, the actual amount, and the salt.

Auction bidding scenario (almost normal)

Day zero

• Alice is tired of sending her ETH address by encrypted mail every time she wants to share it. She wants to say it out loud, or write it on a napkin, and be done with it. She’s heard of ENS, and that MyEtherWallet supports it, but she hasn’t used either before. She’s downtown, her phone is broken, and she’s got lunch scheduled in an hour. She decides to try her luck, and walks into the closest internet café.
• She goes to MEW’s page, checks to see that aliceinwonderland.eth is unavailable, considers aliceliddell.eth (her full name), then analice.eth (“an alice”), curses, and settles on cancelot.eth (nonsense that is easy to pronounce).
• She checks MEW’s self-help center to see what could go wrong.
• She unlocks her wallet using a mnemonic phrase from her home computer’s MetaMask wallet, and proceeds to fill in the details.
• She shrugs off the fine print, because the display renders letters thinly. When asked to take a screenshot of the bid’s info, she writes it down on a napkin, and folds it to her pocket. She confirms the bid.
• MEW sends out two transactions simultaneously - one opening the auction, another placing a sealed bid. Links are shown for both.
• Alice waits for the transactions to go through. It’s taking a while, so she checks Reddit to see if there’s a DDoS or something. There’s an ICO.
• “How long is forever?”, Alice curses. Her time is up, she logs out, and heads to lunch.
• She tells everyone there how she’ll soon have this easy-to-remember Ethereum name, all the while replenishing her supply of napkins. Mallory seems mildly interested by the description.
• Unbeknownst to her, many Ethereum nodes crash in the ICO aftermath, clearing her transactions from their memory. However, they are routinely re-broadcast by a few hardened nodes, performed as a public service by their operators to ward off support requesters.
• When she gets home, she finds a napkin in her pocket, and puts it by the computer. She makes a mental note to check back when the bidding phase is over, so she can reveal her bid.

Day one

• Next day, Alice checks if the transactions went through. They have, almost 18 hours after being sent.

Day two

• Alice gets her phone repaired. She puts a reminder in a calendar app, with the actual time for the reveal phase, once she comes home and notices the napkin still there by her computer.

Day three

• When time comes to reveal, Alice is away from home, so her secret-bearing napkin isn’t readily available. She gets to it much later, and uses MEW again, since she doesn’t feel like experimenting with MetaMask.
• She can’t copy-paste from her napkin, so uses the “manual input” boxes instead. The first transaction fails, since she gets the amount wrong - 0.0042 ETH instead of 0.042 ETH.
• She tries again, triple-checking all the input boxes, and submits her second transaction.
• By coincidence, there’s another crowdsale event starting just about then. The second transaction gets “stuck”. Alice curses.
• She wonders how to change gas price in MEW, since there didn’t seem to be an option for that. She looks through the page thoroughly, and finds it in the footer, on the right, surrounded mostly by project trivia.
• She makes a mental note to increase gas price for time-critical transactions, if she ever has a need to do those.

Day four

• The reveal transaction gets included in a block by next morning. Alice feels relieved.

Day five

• The reveal phase for cancelot.eth ends. Alice was the only bidder, or perhaps everyone else failed to reveal their bids.
• She follows the instructions to finalise the auction in the .eth Registrar.
• She sets the resolver in the ENS Registry to the Public Resolver.
• She sets cancelot.eth to resolve to her wallet address in the Public Resolver.
• She sets the reverse name to cancelot.eth for her address in the Reverse Registrar.

Possible pitfalls

There are many things that could have gone wrong for Alice. Most importantly:

• She could have lost the “seed phrase” for her bid, or forgotten the amount that she placed in the sealed bid - e.g., due to losing that napkin, or bidding “about 4 euros” (0.013114754098360656 ETH).
• She could have failed to reveal her bid during the appropriate phase - e.g., due to another unexpected ICO, or a “regular” DDoS, or getting in a car crash with Mallory, or simply forgetting to do it on a hung-over weekend.
• She might have lost the keys to her wallet altogether - e.g. by bidding from a device that got broken later, and not having a backup.
• She might have gotten her bidding account compromised - e.g. by a keylogger at the café.
• Her client of choice might have had a bug, particularly one that mangles the bid/reveal transaction data, screws up transaction nonces, or some similar technicality. So, although she might have done everything “correctly”, the software she used might’ve not.

If you think all of the above are so unlikely that they’d never happen - think again: most of them are “quotes” from the ENS gitter channel, of people confused as to what has happened, exactly, and taking the time to figure it out.

Say Alice fails to reveal?

If she simply couldn’t make it in time, but still had all the necessary information, she could reveal her bid anyway. That would be a sensible thing to do, since the “conceal” amount would be returned in full. As to the actual bid amount, she’d get 0.5% of it back.

19 days after a bid has been placed, the bid “expires”, or becomes “stale” (not official terms). Most probably, that comes 14 days after the related auction’s end.

After bid expiration, anyone becomes eligible to 0.5% of the entire bid amount. (There’s no way to determine what part of that was the actual bid - it’s never been revealed). All they need to perform is a cancellation call, providing a bidder’s address and the unrevealed bid data.

Current state

By now the situation has evolved such that there is a race by multiple third parties to claim the reward discussed above. This, in turn, results in unnecessary stress on the network. Even if very small, this stress can be avoided by re-designing the cancellation mechanism.

(The developers of ENS are aware of all this.)

This is not a bug. It is more of a logical conclusion to the set of rules layed out by the .eth Registrar contract.

Some stats

As of block 3898200, the ENS .eth Registrar is the top account by gas used in transactions sent to it, according to ETH Gas Station. It’s been in that position for the most of its existence, surpassed only occasionally, briefly, and violently by a few crowdsales.

It accounts for 26.05% of gas used in the last 10 thousand blocks. The closest contender is 4.56 times smaller (5.71%), and is the Bittrex exchange.

The above is to demostrate that users of ENS are not a fringe group, but in fact a large constituency among those using this blockchain for computation, at least by this metric.

Over 161 thousand bids have been placed since the launch of ENS on May 4th. Since the start of June, the number of unrevealed bids hovers around 15-17 thousand.

As of this writing (June 19th, block 3898364), the number of bids properly revealed (ever) is 137003, and the number of cancelled ones is 6952. That is 5806.112 ETH in total, of which 29.031 ETH (0.5%) went to those doing the cancelling. (Source: this script.)

At current trading price of 316 ETH/EUR, that’s respectively 1.834 million and 9.173 thousand euros. Another way to look at it is slightly less than the mining revenue for 63 or 6 blocks, respectively, in less than 7 weeks.

About 4.83% of bids are not being revealed in time by the people who placed them. Instead, they are being cancelled by someone else after becoming “stale”. This means a large loss of funds for the original bidders, a sizeable reward for some effort to those cleaning up the mess, and a near-negligible increase in ether valuation for everybody in the ecosystem, including those who lost and gained.

On the other hand, for most of expired bids, there are at least two cancellation transactions that make it into the blockchain, and anywhere up to 20 that get replaced with a higher gas price while still in the unconfirmed transaction pool.

(More on the latter - later.)