Accounts

An Ethereum account is a digital entity on the Ethereum blockchain that has an ETH balance and can send transactions; either to transfer funds or interact with the network. Accounts are essential for any interaction with the Ethereum ecosystem, such as transferring ETH or invoking smart contracts. We have two types of Ethereum accounts: externally owned accounts (EOAs) and contract accounts (smart contracts).

• Externally Owned Account (EOA)

  Are the most common type of Ethereum account and are controlled directly by the user's private keys. These accounts function similarly to traditional wallets, allowing the user to send transactions such as transferring ETH or tokens to other accounts and interacting with smart contracts for activities like voting or decentralized finance operations. Creating an EOA is free and straightforward; users simply generate a cryptographic key pair. The security of an EOA depends entirely on keeping the private key confidential, as this key grants full control over the account. EOAs are unique in their ability to initiate transactions, meaning only they can start new actions on the blockchain.

• Contract Account

  Are controlled by code rather than an individual or private key. This code, known as a smart contract, is a self-executing program deployed on the Ethereum blockchain which is immutable once deployed. Contract accounts cannot initiate transactions independently; they only respond when triggered by transactions from EOAs or other contracts. These accounts can hold ETH and tokens, execute complex logic, and even create new contracts.

  However, deploying a contract account requires paying gas fees in ETH, as contracts consume blockchain storage space.

Both accounts can store, receive, and send ETH or tokens and also interact with other smart contracts.

Ethereum Account Structure

Every Ethereum account, no matter the type, stores the following information:

• Nonce: Counts outbound transactions (for EOAs) or the number of contracts created (by contract accounts). This prevents replay attacks and maintains order.

• Balance: Amount of ETH (measured in wei; 1 ETH = 10¹⁸ wei)

• codeHash: A hash of the contract’s code, if it’s a contract account. For EOAs, this is just the hash of an empty string

• storageRoot: A hash representing the stored data (smart contract’s persistent storage). In EOAs, this is usually empty

EOAs and Key Pairs

An Externally-Owned Account (EOA) on Ethereum is a type of account controlled by a user holding a cryptographic key pair: a private key and a public key. Read more about keys here

So, why are key pairs important with EOAs?

• They ensure authenticity: Only the person with the private key can initiate transactions from that account.

• They prevent forgery: Since every transaction is digitally signed, malicious actors can't create fake transactions that appear to come from your account.

• They support verification: anyone can verify a transaction's origin by checking the signature against the public key, establishing trust without revealing the private key.

For example, imagine you want to send ETH to a friend

1. You use your private key to sign the transaction request.

2. And broadcast this signed request to the Ethereum network.

3. Network validators check the signature using your public key.

4. If the signature matches, the network verifies that you truly authorized the transaction.

Without this cryptographic system, a malicious actor could falsely request funds from your account, and no one could verify if it was genuine.

Note: You never actually "hold" cryptocurrency. Instead, you hold the private key that grants you access to move funds on Ethereum's global ledger.

How Accounts are Generated

Most Ethereum wallets or libraries automatically generate a random 64-character hex private key for you; this private key can be encrypted with a password for extra security. From the private key, a public key is generated using elliptic curve cryptography (ECDSA); the public address (what you share to receive funds) is derived from the public key.

Unlike traditional banking, no central authority assigns you an account. Simply generating a key pair and address gives you an account that can exist on Ethereum. However, an account is recognized by the network only once it has been involved in at least one transaction; either by sending funds, receiving funds, or deploying/interacting with a smart contract. Until then, the account’s address is simply a potential slot in the global state.

Contract Acounts

Contract accounts represent smart contracts deployed on the Ethereum blockchain. Like externally owned accounts (EOAs), they have a 42-character hexadecimal address beginning with 0x. For example:

0×05012c8cf97beed5deae237070f9587f8e7a266d

Unlike EOAs, whose addresses come from their public keys, contract addresses are systematically computed when deployed. The source of the address is from:

1. The creator's address (the account deploying the contract)

2. The creator's nonce (number of transactions sent from that address)

This combination is processed using Ethereum's specific encoding and hashing methods to produce the unique contract address. This ensures contract addresses cannot be pre-chosen arbitrarily and are reproducible on the network.

Instead of being controlled by a private key, contract accounts are governed by code embedded within the Ethereum Virtual Machine (EVM). When a transaction is sent to a contract address, the contract's code executes automatically, enabling decentralized applications, token management, and complex automated processes on the blockchain.

Transactions

An Ethereum transaction is a cryptographically signed instruction delivered from an externally owned account (EOA) to effect a change on the Ethereum blockchain network. It signifies a state-changing activity, like transferring ETH between accounts or executing a smart contract.

Ethereum transactions are initiated only by externally owned accounts (EOAs), which are controlled via private keys; contract accounts cannot start transactions themselves and only respond to incoming ones.

Ethereum Transaction Object

A typical Ethereum transaction is represented as a JSON object containing key fields such as:

• from: Address of the sender (an externally owned account) signing the transaction.

• to: Recipient’s address (can be an EOA or a contract account). If creating a contract, this is null.

• value: Amount of ETH to transfer, denominated in wei (1 ETH = 10¹⁸ wei).

• nonce: Sequential number of sender’s transactions, preventing replay and ordering them.

• signature: Digital signature generated from the sender’s private key, proving authenticity.

• input data: Optional arbitrary data or instructions to execute smart contract functions.

• gasLimit: Maximum gas units the sender allows for this transaction’s execution.

• maxPriorityFeePerGas: Tip offered to validators to prioritize transaction inclusion.

• maxFeePerGas: Maximum total gas price (including base fee and tip) the sender is willing to pay.

A transaction object looks like this:

{
  from: "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8",
  to: "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a",
  gasLimit: "21000",
  maxFeePerGas: "290",
  maxPriorityFeePerGas: "10",
  nonce: "0",
  value: "10000000000"
}

How Transactions Work in Practice

1. Creation: The sender’s wallet assembles the transaction details, including to, value, and optionally input data.

2. Signing: Using the private key, the sender signs the transaction, producing a unique digital signature (signature) that authorizes the operation.

3. Broadcasting: The signed transaction is broadcast to the Ethereum peer-to-peer network and enters the mempool: a queue of pending transactions.

4. Validation and Execution: Validators pick transactions from the mempool, execute their instructions on the EVM, update the global Ethereum state (balances, contract storage), and add the transaction to a new block.

5. Inclusion in a Block: Validators include transactions in blocks. The transaction is executed, updating state (balances, contract storage).

6. Confirmation: The block containing the transaction undergoes confirmations: first "justified," then "finalized," which makes the transaction irreversibly part of the blockchain unless an extremely costly network attack occurs.

7. Receipt & Effects: The transaction hash can be used to track status and outcome.

The transaction object must be signed by the sender’s private key to prove authenticity and prevent fraud. Signing produces a cryptographic signature proving the sender authorized this transaction. Tools like Ethereum clients (e.g., Geth) automate this signing.

Using the Ethereum JSON-RPC API, a transaction can be signed with a call like:

{
  "id": 2,
  "jsonrpc": "2.0",
  "method": "account_signTransaction",
  "params": [
    {
      "from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db",
      "gas": "0x55555",
      "maxFeePerGas": "0x1234",
      "maxPriorityFeePerGas": "0x1234",
      "input": "0xabcd",
      "nonce": "0x0",
      "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
      "value": "0x1234"
    }
  ]
}

The Data (Input) Field

• When interacting with smart contracts, transactions include a data field carrying encoded instructions.

• The first 4 bytes are the function selector, a hash identifying which contract function to call.

• The rest contains arguments, encoded per the Ethereum ABI specification, each padded to 32 bytes.

• For example, a common function selector 0xa9059cbb corresponds to transfer(address,uint256) in ERC-20 token contracts. The arguments specify the recipient address and token amount.

This allows complex contract interactions beyond simple ETH transfers.

Types of Transactions

Ethereum supports three main types of transactions:

• regular transactions that transfer ETH between accounts;

• contract deployment transactions, which have no recipient address and include the bytecode needed to create a new smart contract;

• and contract interaction transactions, where the sender calls functions on an existing smart contract by including encoded input data in the transaction.

Gas and Fees

• Gas measures computational work in the EVM.

• Simple ETH transfers cost 21,000 gas units.

• Gas fees = gas used × gas price.

For example, sending 1 ETH with a base fee of 190 gwei and a priority tip of 10 gwei:

$$(290+10)×21,000=6,300,000 gwei=0.0063 ETH$$

• The sender pays this fee on top of the value transferred.

• Of the fee, the "base fee (290 × 21,000)” is burned, and the “maxPriorityFeePerGas (10 × 21,000)” is a tip rewarded to validators.

• Unused gas is refunded.

Typed Transaction Envelope

Typed Transaction Envelope is a standard introduced by EIP-2718 that allows Ethereum to support multiple transaction formats while maintaining backward compatibility. Initially, Ethereum had a single transaction format where all transaction fields (nonce, gas price, gas limit, to, value, data, signature parts) were encoded together using Recursive Length Prefix (RLP). This legacy format is now classified as Type 0 transactions.

EIP-2718 changes the transaction format to:

textTransactionType || TransactionPayload

where:

• TransactionType is an 8-bit number (0 to 0x7f), allowing up to 128 different transaction types.

• TransactionPayload is an arbitrary byte array whose structure depends on the transaction type.

This design enables the Ethereum network to introduce new transaction types without breaking older clients or complicating parsing.

There are currently three main transaction types under this scheme:

• Type 0 (Legacy Transactions): The original Ethereum transactions without enhancements like dynamic gas fees or access lists. They lack a type prefix and start with byte 0xf8 in RLP encoding.

• Type 1 (EIP-2930 Transactions): Introduced in the Berlin upgrade, they include access lists specifying which accounts and storage slots the transaction will access, potentially optimizing gas usage. They have a prefix byte 0x01 and include a yParity field related to signature recovery.

• Type 2 (EIP-1559 Transactions): Introduced in the London upgrade, these are now the standard. They implement a new fee market mechanism separating base fee and priority fee, improving fee predictability and network efficiency. They start with the byte 0x02 and include fields like maxPriorityFeePerGas and maxFeePerGas.

This typed envelope approach provides a scalable, flexible framework that simplifies handling new transaction features, improves backward compatibility, and supports ongoing Ethereum protocol evolution.

As Ethereum continues evolving, mastering these core concepts will remain crucial for engaging confidently and securely with the platform’s ecosystem and its rapidly expanding frontier of possibilities.