This is part 1/2 of a series on accounts & wallets, find part 2 here.
Blockchains introduce new software constructs and paradigms. One difference with the web2 world is how accounts are defined, registered, and controlled.
Accounts
Blockchain state – at its simplest – is a set of account balances and the transactions between them. Each account has a publicly known address, a public key to which also exists a counterpart private key. The public key is shared publicly, while the private key should be kept securely by the account owner. Examples of public addresses are 0x1dA4FDf7029bDf8ff11f28141a659f6563940642 on Ethereum or bc1q3yz87mhky7c30y9v38aggypw8jrda7ettefxgr on bitcoin.
There are 2 types of blockchain accounts:
Externally Owned Accounts (EOAs)
Contract Accounts (only exist on smart contract chains like Ethereum & Solana, not bitcoin)
Externally Owned Accounts (EOAs)
EOAs are not registered to blockchains like you’d register a gmail address to a centralized provider (google). Instead, they simply already exist: there is a space of trillions of billions of public keys, and “creating” an account means generating a new random private key, and then deriving its public key (or address). Knowing the private key allows to sign transactions (proving ownership) and therefore control the account.
Note: Losing the private keys means that controlling that account is no longer possible, and the currency in it is inaccessible forever.
How does one know how to generate a new random private key? With conventionally adopted standard cryptography algorithms, that have been proposed and approved by the community. This approach avoids the need of a central authority in charge of account management in favor of shared cryptography methods (which is permissionless and censorship resistant). Most of these algorithms went through the BIP (bitcoin improvement proposal) mechanism.
You might have heard of “seed phrases” or “mnemonics”, these are from BIP39: a proposed method of generating private keys in a more human friendly way. From the seed phrase (12 to 24 english words), we derive a private key (optionally using an extra passphrase), then from that private key we derive a root key. Finally, we can create multiple public/private key pairs (accounts) from this single root key. This technique was proposed in BIP32, and is called Hyper Deterministic (HD) wallets.
The idea is that remembering mnemonics is hard, but one might still want many accounts for privacy and security reasons. This gives us the best of both worlds! This also allows interoperability, you can use the same passphrase in any wallet client for that ecosystem and everything works, and you can deterministically re-create all of your accounts from a passphrase.
Contract Accounts
Contract Accounts are programs (smart contracts) which simulate EOAs. They can therefore only exist on smart contract chains like ethereum or Solana, as code.
What’s their purpose? Arbitrary functionality makes them safer, more powerful, and can improve the user experience.
For example, it allows techniques like “multisig”, requiring multiple confirmations before using the private key to sign transactions (similar to 2FA auth, in web2): see Argent or Gnosis-Safe.
A major drawback from Contract Accounts today (in Ethereum) is that they cannot sign transactions like EOAs can, making them less useful. This is an active area of proposed improvement for Ethereum, called “Account Abstraction” (see EIP-2938 and EIP-4337), a sizable opportunity to improve web3 UX and security.