The words you need

Blockchain writing uses a small vocabulary. Here is all of it, in plain words; the rest of the book assumes these. Entries marked * simplify where the full rule would weigh more than the book needs; each links the appendix that carries the complete version.

• Kaspa: the proof-of-work network this book runs on; its coin is KAS. What matters here is its blockdag and its UTXO model, both below.
• Blockdag*: the shape of Kaspa’s history: a web, not a line. Where a classic chain discards parallel blocks, a Kaspa block names several parents, so blocks mined at nearly the same time all count, and consensus orders the web into one agreed order of transactions, roughly ten blocks a second. The machine consumes that order; the shallow reorg churn the web leaves behind is why the confirmation window exists (the Reorg entry below). The appendix has the ordering in full.
• Sompi: the smallest unit of KAS; one KAS is 100,000,000 sompi.
• DAA score*: a depth counter every block carries, counting blocks in its past. It only moves forward, so the program reads it as its clock: deadlines are differences in DAA score, not wall-clock time (The transaction vocabulary). Kaspa also paces mining difficulty and emission by it. Its sibling, the blue score, is the number of blue blocks in a block’s past, the blockdag’s version of block height; Kaspa counts confirmations in it, and the program sees it only as block context (The transaction vocabulary). The appendix separates the two exactly.
• L1: “layer 1”, the Kaspa network itself. The layer that holds the funds.
• L2: “layer 2”: a system that does its work off the L1 while depending on the L1 for what must be trusted: ordering, data availability, and settlement. A rollup is the common L2 shape: execute off-chain, then prove or commit the results back on-chain. The machine in this book is one.
• KIP: Kaspa Improvement Proposal: the process by which the network proposes, reviews, and activates protocol changes. The proposals themselves live in the KIP repository.
• Output (UTXO): a piece of KAS at a lock. Every Kaspa transaction consumes earlier outputs (as its inputs) and creates new outputs; one that no transaction has consumed yet is an unspent transaction output. “Your money” is the set of UTXOs your key can unlock. And an output lives in exactly one transaction: once spent it is gone, and no other transaction can reference it. That one-way rule is why shared on-chain state is hard here (Based rollup on Kaspa).
• SPK, P2PK, P2SH: the locking half of an output is its SPK (script public key), a small program stored inside the output. A later transaction spends that output by supplying input data that satisfies the SPK. P2PK: the SPK demands a signature from one specific public key, and the address is derived from that key. P2SH: the SPK stores only the hash of a script; the spender reveals the script, shows its hash matches, and the revealed script then runs and must succeed. P2SH is how this machine puts its own rules onto Kaspa: the program is committed from the moment the output exists, but only seen at spend time.
• Settlement: the transaction that commits one new state digest of the program’s off-chain (L2) state to Kaspa, spends the output only a valid settlement can spend, and chains to the settlement before it. The transaction vocabulary is about it.
• State digest: a short fingerprint of the program’s whole off-chain state: one 32-byte number that changes whenever the state does. Settlements commit it on L1. The transaction vocabulary builds it.
• Lane: the program’s public inbox: a labeled stream (a Kaspa subnetwork) of ordinary transactions carrying users’ signed actions. Miners mine them like any other payment; there is no gatekeeper to refuse an entry.
• Covenant: Kaspa’s mechanism (KIP-20) for scripts that bind outputs to one program instance: a covenant transaction carries the instance’s id, consensus enforces the binding, and a script can demand that its spender run under a named covenant. Settlements and exit claims are covenant transactions. The id, the blake2b hash of the covenant’s redeem script, is the 32-byte name of the instance: that one script pins the guest image ids (the exact rule-set version), the lane, and the state digest and lane tip the instance chains from, so it commits to code, lane, and settlement chain together, and the deposit address derives from it in turn.
• Guest: the program’s own code, running inside the proving machine (the zkVM), as opposed to the framework around it.
• Image id: the cryptographic hash of one guest program binary. Pinning image ids fixes the exact code and proof stack an instance runs (The transaction vocabulary and The zkVM, briefly).
• Mempool: the set of transactions announced to the network but not yet included in a block.
• Execution: the guest program doing its work: reading confirmed L1 data, checking and applying each action, crediting deposits, and moving the state from one root to the next. It runs off-chain inside the zkVM; the proof is what makes its result trustworthy (How it all chains).
• Witness: the confirmed L1 data execution reads: lane entries, deposits, block context. How it all chains builds the pipeline around it.
• Journal: the fixed-format record inside each proof: the state before, the state after, how far the lane had been read, which L1 blocks execution saw, and the deposit and exit commitments where the step carried any. vprogs writes three levels of them, transaction, batch, bundle; The zkVM, briefly lays them side by side. Used from How it all chains on.
• Proof, receipt: a few kilobytes of mathematics that convince anyone, without re-running the program, that a specific guest produced a specific journal.
• Runtime: the layer of code that checks and applies each action. Solana: the real difference is about who owns it.
• Reorg (reorganization): now and then the network briefly agrees on one block order, then switches to another; the switched-away blocks “vanish”. Shallow churn like this is normal and expected; deeply buried blocks essentially never reorganize, which is why the machine waits out a confirmation window before trusting fresh blocks (How it all chains).
• Confirmation window: the number of blocks of depth the machine waits before treating an L1 block as final; widened adaptively when the network looks reorg-prone (How it all chains).
• Safety: the guarantee that nothing invalid ever becomes settled state: no one can forge, steal, or pay twice, whatever the operator does.
• Liveness: the guarantee that someone keeps executing, proving, and settling, so actions and exits keep processing. Safety says no one can steal; liveness says the machine does not stop. The machinery owns it.
• Data availability*: the guarantee that you can fetch the full record of what was published, yourself, from the network, rather than trusting someone’s summary of it. Ordinary nodes prune old block bodies, so data from far enough back is served by archival peers, and what they serve checks against the chain’s own headers (the appendix).
• Mass: the weight of a transaction that fees are priced on: the larger of compute mass (verification work) and storage mass (the unspent-set growth the transaction leaves behind; it rises when value is split into many small outputs). The appendix has the formula and what nodes store.
• Dust: outputs too small to be worth spending. The network’s minimum-relay rules floor how small an output may be, which limits how far the deposit pile can be split.