What an Ethereum “account” is and what it is not

In a recent post, I contemplated about the limits of the coin metaphor.
In this write-up I’m going to dissect the account metaphor and explain the significant differences between an Ethereum account and an account in a conventional client/server system.

Blockchain / database perspective

First, remember that Ethereum can be described as a decentralized database. The Ethereum Whitepaper describes an account as an entry in that database, uniquely identified by a 20-byte address.
Such an account entry consists of a nonce (basically a transaction counter), its Ether balance, optional contract code and optional storage.
For the sake of simplicity, lets look only at externally owned accounts for now — that is, accounts controlled by private keys.

User application / wallet perspective

Lets switch to an outside view, that of an application interacting with the blockchain. Lets look at the documentation of the go-ethereum (aka geth) client. The section Managing your accounts explains how you can create, list etc. accounts.

In a conventional system, creating an account roughly involves this steps:

1. pick a unique identifier (username / email address which is not yet occupied)
2. pick a password (trying the impossible balance of it being memorable, secure and compliant with random rules imposed by the service provider)
3. Click/tap some confirmation action button which under the hood has your application connect to a remote service, sending the unique identifier and a (hopefully) hashed version of your password, leading to the creation of an entry in a remote database.

Creating an account with an Ethereum application usually goes like this:

1. Click/tap some action button (or enter a CLI command). Under the hood this triggers the following operations:

• a request to a random number generator (abbr. as RNG — a piece of software on your system which hopefully produces high-quality randomness — a surprisingly difficult task for Computers). The 32 bytes of data returned by the RNG become the private key of the new account.

In theory, we could be done here. Just save the private key to a file (or write it onto a paper, or remember it) and account creation is done.

In practice, some more steps follow, but none of them are essential. Lets see:

• Out of the private key, a 64 byte public key is calculated, following a procedure (Elliptic curve point multiplication) defined by the ECDSA (Elliptic Curve Digital Signature Algorithm).
• Out of the public key, a 20 byte address is calculated. This is done by first hashing the public key and then picking the trailing 20 out of 32 bytes. Encoded as hex string (as is common in Ethereum), this leads to a 40 character string (42 chars if prefixed with ‘0x’).

A nice visualization of this steps can be found here.

2. Choose a password. It is used to encrypt the private key (usually with the scrypt algorithm). At this point the encryped private key is saved to a local file together with some metadata, e.g. as specified by the Web3 Secret Storage definition.

It’s important to understand that this password is NOT essential for account creation. It does not have the role a password has in a conventional system. It’s more comparable to a password you use to unlock a password manager.
Also, saving the public key and address isn’t really necessary as they can be deterministically calculated from the private key alone anytime.

not synced

If you compare the sequence of actions, you may notice that in the blockchain scenario, there was no communication with a remote system (or with a local node).
In fact, creating an Ethereum account could in essence be broken down to

1. “pick 32 bytes” or “pick a number between 1 and 2²⁵⁶-1” or “pick a hex string with 64 characters”
2. Done

But — you may ask — how can the blockchain know if a specific account was created and whom it belongs to?
In fact, it doesn’t!

Now lets go discover some contradictions in the 2 definitions of account:
Initially we’ve seen that an account from the blockchain’s perspective (lets name it blockchain account) is essentially a storage entry, while from the outside perspective (lets name that user account) it’s basically just a private key. But how do this two perspectives connect?

A new blockchain account is created by a transaction with the recipient set to an address for which no account entry existed yet.

So how can the blockchain know if a matching user account exists for that new account? It doesn’t!
Any valid address (that is, any 20 byte value) is a valid account identifier. As long as it didn’t see a valid transaction (that is, one signed with a matching private key) for that account (which this account as sender, not as recipient), it’s unknown if a user account matching that blockchain accounts exists anywhere in the world.

The other way round, we have a similar situation:
When creating a user account, how can I know that the account is still “free” and not yet claimed by somebody else on the blockchain? E.g. what happens if I pick 1 as the private key, because that’s easy to remember?
Well, then there’s a good chance that you’re not the first one trying that private key and will thus end up using a blockchain account which other people (or bots, or fridges) can also access. Looking at the address which is derived from that key (0x7E5F45…), this seems to be indeed the case (hard to say if people send Ether to this address for the lulz or by mistake).

not unique

What’s more: the private key 1 is very probably not the only key able to create valid signatures for address 0x7E5F45…
Since there exist 2²⁵⁶ possible private keys and 2¹⁶⁰ possible addresses, there’s on average 2⁹⁶ private keys mapping to one address — still a pretty huge number.

In principle the same (several passwords able to access one account) could happen in the conventional model, especially if the address space of possible passwords is bigger than that of possible hashes (but even if not, there’s no guarantee of the mapping being collision-free).

The whole point is: cryptography relies on probabilities and blockchain account design doesn’t try to hide that.
If a good random number generator (and let me remind you: that’s not a trivial prerequisite) creates a private key, the probability of anybody else to find a private key mapping to the same address is so small that it’s considered a safe assumption being the sole person on earth able to sign valid transactions for that account — for many years to come.
This is the reason why user wallets don’t even bother checking if a newly created user account does already exist as a blockchain account.

no recovery

Which has another important implication:
In the conventional model, one may lose or forget the password (happens to most of us). In that case, you usually just click “forgot password” and will get mailed a link to a password reset form.
Even if you lost both your password and access to your Email account, there’s a chance for you to convince the service provider that you’re the legitimate account owner and re-gain access that way (such last-resort recovery processes also happen to be a dangerous attack vector).

In the case of a blockchain account, there’s no recovery. None!
If you lost the private key, you lost access to that account (and the valuables potentially held by it).
Basically the only way to recover is to convince the network to bail you out with a hardfork (as happened e.g. here, but did not happen in other cases of huge losses as e.g. here). Won’t happen.

Designing ARTIS, we are putting a lot of focus on this aspect because we believe it to be one of the big unsolved challenges on the way of making blockchain based applications safe and usable for normal human beings.

All the keys

In order to check if you got it, go to http://www.ethersecret.com/ and see if it’s confusing or amusing.

PS: If you liked the article, clap 2²⁵⁶ times 😉