BTA CBDE key terms

An Ethereum account controlled by a private key rather than contract code. It can initiate transactions, hold ether, and is identified by its derived address. EOAs cannot execute logic on their own.

An Ethereum account that carries bytecode and has no private key. It runs its code when called, keeps its own storage, and can only act by sending messages in response to received transactions or calls.

The smallest denomination of ether, equal to 10^-18 ETH. Gas prices and balances are usually expressed in wei or gwei, a unit of 10^9 wei, to avoid floating-point rounding in protocol calculations.

A unit measuring the computational work a transaction or call consumes. Every opcode has a gas cost, and the total limits how much execution a block or transaction may perform before halting.

The maximum gas a sender authorizes for a transaction, or the maximum gas a block may contain. If execution exhausts the transaction limit, all state changes revert and the gas is still charged.

The amount of ether paid per unit of gas. Under EIP-1559 it splits into a base fee burned by the protocol and an optional priority fee paid to the block proposer as an incentive.

A counter on each externally owned account that increments with every sent transaction. It enforces ordering and prevents replay, so a gap in nonces blocks all later transactions from that account.

The low-level instruction set executed by the Ethereum Virtual Machine. Solidity source compiles to this bytecode, which is deployed on-chain and interpreted opcode by opcode during contract calls.

A JSON description of a contract's functions, events, and types. Tooling uses it to encode calldata and decode return values and logs when interacting with deployed bytecode.

The read-only, non-persistent byte input attached to a message call, containing the function selector and encoded arguments. It is cheaper to read than storage and cannot be modified by the receiving contract.

The first four bytes of the Keccak-256 hash of a function signature, such as transfer(address,uint256). It tells the contract which function to dispatch when calldata arrives.

Data declared at contract scope and written permanently to contract storage. Each write costs significant gas, so designs often cache values in memory within a single call.

A 32-byte position in a contract's persistent storage. Variables are packed into slots in declaration order, and mappings and dynamic arrays use hashed keys to locate their entries.

Memory is a temporary, per-call byte area that is cheap to use and discarded afterward. Storage is persistent and costly to modify. Choosing the correct data location affects both gas and correctness.

A Solidity keyword on functions and state variables, such as public, external, internal, or private, that controls who may call or read them. It shapes the generated ABI and access rules.

A reusable Solidity construct that wraps a function body with preconditions or postconditions, commonly used for ownership or reentrancy checks. The underscore placeholder marks where the body runs.

A Solidity event emits a log entry stored by the EVM outside contract storage. Indexed parameters become searchable topics, letting off-chain services efficiently track contract activity.

A Solidity function or address annotation allowing ether to be sent with a call. A function without it rejects value, and the receive or fallback function handles plain transfers.

A special function invoked when calldata matches no selector, or when ether arrives without data if no receive function exists. It must be kept simple to avoid gas and reentrancy problems.

An interface declares function signatures without implementations, while an abstract contract may include some implemented functions but leaves others unimplemented. Both define expectations that concrete contracts must satisfy.

A Solidity mechanism letting a contract reuse and extend another's code. Linearization order determines which implementation wins when functions are overridden across multiple parents.

A JavaScript and TypeScript development environment offering a local Ethereum network, compilation, scripting, and a testing runner. Its plugins add coverage, verification, and deployment helpers.

A Rust-based Ethereum toolchain whose Forge component compiles and tests Solidity contracts written in Solidity itself. It emphasizes fast fuzz testing and scripted deployments.

A private, disposable blockchain node run on a developer machine, often pre-funded with test accounts. It enables rapid iteration and deterministic testing before deploying to a public network.

A service that dispenses small amounts of valueless test ether to a specified address so developers can pay gas while exercising contracts on a public test network.

An endpoint exposing Ethereum node methods over HTTP or WebSocket, such as eth_call and eth_sendRawTransaction. Wallets and DApp front ends use it to read state and submit signed transactions.

The step where a browser wallet injects a provider and the user approves account access. The DApp then reads the selected address and requests signatures for transactions.

The web interface that reads contract state and submits transactions through a wallet or RPC provider. It must handle pending states, errors, and network mismatches gracefully.

A numeric identifier for a blockchain network, embedded in signed transactions to prevent replay across chains. Front ends compare it with the wallet's network to detect mismatches.

An automated check exercising a single contract function or small behavior in isolation, usually against a local chain. Fast unit tests catch logic errors before broader integration testing.

A test that exercises multiple contracts or the full transaction flow together, verifying interactions, event emission, and state transitions across components rather than one function in isolation.

An automated technique feeding many generated or random inputs into a function to find edge cases and invariant violations. It complements hand-written unit tests by exploring unexpected value combinations.

Running tests against a copy of a live network's state, so contracts can interact with real deployed protocols. It reveals integration issues that isolated local tests cannot reproduce.

An attack where a called contract re-enters the caller before its state is updated, draining funds or corrupting balances. Checks-effects-interactions ordering and reentrancy guards are standard defenses.

A coding pattern that validates inputs first, updates state second, and performs external calls last. Following it prevents reentrancy from observing stale state during a callback.

A design where recipients withdraw funds themselves instead of being paid during a loop. It avoids one failing recipient blocking others and reduces reentrancy and gas-griefing exposure.

Rules restricting who may invoke privileged functions, implemented with ownership checks, role-based modifiers, or multi-signature approval. Weak access control is a leading cause of contract exploits.

A pattern separating storage from logic so a contract's implementation can be replaced while its address and state persist. It requires careful storage layout discipline to avoid slot collisions.

A failure raised when execution consumes its entire gas allowance. The transaction reverts, state changes are undone, and the sender still pays for the gas spent.

Publishing source code and compiler settings to a block explorer so its bytecode can be matched to the deployed contract. Verification lets users audit behavior and interact through a readable interface.