# Optimistic Rollup Glossary

This document is for settling on a set of terms related to Optimistic Rollups.

Once agreed we should make include in the design so that it can serve as a reference.

- ORU - Optimistic Rollup
- SCORU - Smart-contrct Optimistic Rollup
- TORU - Transactional Optmistic Rollup
- L1 - Layer 1 (Tezos base layer/Tezos protocol)
- **L2** - Layer 2 (ORU implementation)
- Hans: L2 is more general: any rollup. Maybe OK in context.
- Thomas H.: We should use L2 if we are talking about L2 whatever is the kind (state channel, ORU, zk-rollup, sidechain) and `ORU node` if we are talking about ORU L2 to avoid confusion accros the community whith other L2 projects
- Joel: I think talking about L2 in the context of ORU is OK. Also part of Arbitrum's vocabulary
- **L2 VM** - a virtual machine running off chain, similar to a Smart Contract from the L1 point of view.
- Call this ORU VM?
- Joel: Same here, I think it's OK in the context
- **L2 node** - A process implementing L2 VMs and related aspects like commitments and refutation.
- Call this ORU node?
- Joel: Same here, I think it's OK in the context
- **L2 gas** - Fees charged for executing transactions on L2.
- Hans: Maybe a different term?
- David: gas is charged in tez regardless, so "l2 gas" is really just about l2 operation pricing
- Hans: Note both TORU and SCORU design do not charge L2 fees in tez/xtz.
- Thomas H.: Not only transactions pricing, we would charge fees for L2 Storage
- How about we call these L2 fees? (it's outside the scope of the L1 protocol anyway)
- Inbox - A set of operations submitted to a particular ORU.
- Previously (pre-block):
- Hans: Is this the same as an Input/Deposit, or a sequence of them?
- David: No. It can include these, but also other transactions (e.g. transfers). A pre-block becomes a block after the Tezos block closes.
- Benjamin: Inbox
- Hans: Input messages
- L2 operation - An operation included in an inbox
- **Input, Deposit** - L2 operations
- Do we nee these?
- Effect - Operations emitted by L2 that can be executed on L1.
- Withdrawal - An effect that moves assets to some L1 contract
- **Output**
- Same as effect, should we remove?
- [Ticket](https://tezos.gitlab.io/michelson-reference/#type-ticket)
- L2 node - A node that executes a specific rollup.
- Notes
- ORU node -
- Hans: Same as an L2 node?
- **Aggregator** - a node that aggregates and bundles rollup operations before submitting to L1.
- Thomas H.: Called `Batcher` in TORU
- Shall we change to *Batcher*?
- Commitment - A claim about the results of some rollup operations
- Refutation
- Notes:
- Thomas H.: Called `Rejection` in TORU
- Hans: In SCORU, Rejection is one possible result of a Refutation
- Rejection - An outcome of a refutation game where the committed hash was proven incorrect
- [Merkle tree](https://en.wikipedia.org/wiki/Merkle_tree)
- [Merkle proof](https://medium.com/crypto-0-nite/merkle-proofs-explained-6dd429623dc5)
- [Traced Storage](https://hackmd.io/kkg75blSRnS8zCcOyDM4Mw?view): A storage based on a Merkle tree capable of outputed a “trace proof” (compact/optimized in terms of memory space sequences of Merkle proofs)
- VM - Virtual machine
- PVM - Proof-generating Virtual Machine. A VM that can generate proofs for all of its state transition.
- Merkleized VM - A PVM generating Merkle proofs.
- [Trie/Prefix tree](https://en.wikipedia.org/wiki/Trie)
- [Plebeia](https://gitlab.com/dailambda/plebeia/)
- Segment
- Key
- Value
- Tick
- A state transition in a PVM. Typically corresponds to an instruction in some Instruction Set, but this is not required.
- PVM ISA - Instruction Set Architecture with mapping to PVM
- State
- Durable state: State committed to by regular (fast) execution.
- Non-durable state: State committed to in proof-generating execution. Typically containing stack, continuation stacks, heap etc.
- [BLS signatures](https://en.wikipedia.org/wiki/BLS_digital_signature) -- we follow [this draft](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-04) with the "message augmentation" scheme
- L1 arbiter: the component of the protocol which is able to validate or invalidate a refutation proof.