Below are a list of terms and their definitions that are used throughout the Tari code and documentation. Let's use this glossary to disambiguate ideas, and work towards a ubiquitous language for this project.
Archive node
This is a full history base node. It will keep a complete history of every transaction ever received and it will not implement pruning.
AssetCollateral
The amount of tari coin that a Validator Node must put up on the base layer in order to become part of an asset committee.
Asset Issuer
An entity that creates digital assets on the Tari DAN. The Asset Issuer will specify the parameters of the contract template that defines the rules that govern the asset and the number and nature of its constituent tokens on issuance. The Asset Issuer will, generally, be the initial owner of the tokens.
Bad Actor
A participant that acts maliciously or negligently to the detriment of the network or another participant.
Base layer
The Tari Base layer is a merge-mined blockchain secured by proof-of-work. The base layer is primarily responsible for the emission of new Tari, for securing and managing Tari coin transfers.
Base Node
A full Tari node running on the base layer. It's primary role is validating and propagating Tari coin transactions and blocks to the rest of the network.
Block
A collection of transactions and associated metadata recorded as a single entity in the Tari blockchain. The ordering of Tari transactions is set purely by the block height of the block they are recorded in.
Block Header
A data structure that validates the information contained in a block.
Block Body
A data structure containing the transaction inputs, outputs, and kernels that make up the block.
Block reward
The amount of Tari created by the coinbase transaction in every block. The block reward is set by the emission schedule.
Blockchain
A sequence of tari blocks. Each block contains a hash of the previous valid block. Thus the blocks form a chain with the property that changing anything in a block other than the head block requires rewriting the entire blockchain from that point on.
Blockchain state
The complete state of the blockchain at a specific block height. This means a pruned utxo set, a complete set of kernels and headers up to that block height from the genesis block.
BroadcastStrategy
A strategy for propagating messages amongst nodes in a peer-to-peer network. Example implementations of
BroadcastStrategy include the Gossip protocol and flood fill.
Chain Reorganization
A chain reorganization occurs after a chain split occurs on the network, which commonly occurs due to network latency and connectivity issues. When a chain split occurs one chain will have the higher accumulated proof-of-work, this chain is considered the best chain. Nodes on the poorer chain will need to rewind and resync their chains to best chain. In this process transaction in the mempool could become orphaned or invalid.
Checkpoint
A hash of the state of a Digital Asset that is recorded on the base layer.
Coinbase transaction
The first transaction in every Tari block yields a Block Reward according to the Tari emission Schedule and is awarded to the miner that performed the Proof of Work for the block.
Committee
A group of Validator Nodes that are responsible for managing the state of a specific Digital Asset. A committee is selected during asset issuance and can be updated at Checkpoints.
CommitteeSelectionStrategy
A strategy for an Asset Issuer to select candidates for the committee from the available registered Validator Nodes who responded to the nomination call for that asset.
ConsensusStrategy
The approach that will be taken for a committee to reach consensus on the validity of instructions that are performed on a given Digital Asset.
Commitment
A commitment is a cryptographic primitive that allows one to commit to a chosen value while keeping it hidden from others, with the ability to reveal the committed value later. Commitments are designed so that one cannot change the value or statement after they have committed to it.
Communication Node
A Communication Node is either a Validator Node or Base Node that is part of the Tari communication network. It maintains the network and is responsible for forwarding and propagating joining requests, discovery requests and data messages on the communication network.
Communication Client
A Communication Client is a Wallet or Asset Manager that makes use of the Tari communication network to send joining and discovery requests. A Communication Client does not maintain the communication network and is not responsible for forwarding or propagating any requests or data messages.
Creator Nomination Mode
An asset runs in creator nomination mode when every validator node in a validator committee is a Trusted Node that was directly nominated by the Asset Issuer.
Current head
The last block of the base layer that represents the latest valid block. This block must be from the longest proof-of-work chain to be the current head.
Cut-Through
Cut-through is the process where outputs spent within a single block may be removed without breaking the standard MimbleWimble
validation rules. Simplistically, Alice -> Bob -> Carol may be "cut-through" to Alice -> Carol. Bob's commitments may be removed.
On Tari, for reasons described in RFC-0201_TariScript, cut-through is prevented from ever happening.
Digital asset
Digital assets (DAs) are the sets or collections of native digital tokens (both fungible and non-fungible) that are created by asset issuers on the Tari 2nd layer. For example, a promoter might create a DA for a music concert event. The event is the digital asset, and the tickets for the event are digital asset tokens.
Digital Asset Network
The Tari second layer. All digital asset interactions are managed on the Tari Digital Assets Network (DAN). These interactions (defined in instructions) are processed and validated by Validator Nodes.
DigitalAssetTemplate
A DigitalAssetTemplate is one of a set of contract types supported by the DAN. These contracts are non-turing complete and consist of rigid rule-sets with parameters that can be set by Asset Issuers.
Digital asset tokens
Digital asset tokens (or often, just "tokens") are the finite set of digital entities associated with a given digital asset. Depending on the DA created, tokens can represent tickets, in-game items, collectibles or loyalty points. They are bound to the digital asset that created them.
Hashed Time Locked Contract
A time locked contract that only pays out after a certain criteria has been met or refunds the originator if a certain period has expired.
Emission schedule
An explicit formula as a function of the block height, h, that determines the block reward for the hth block.
Instructions
Instructions are the digital asset network equivalent of transactions. Instructions are issued by asset issuers and client applications and are relayed by the DAN to the validator nodes that are managing the associated digital asset.
Mempool
The mempool consists of the transaction pool, pending pool, orphan pool and reorg pool, and is responsible for managing unconfirmed transactions that have not yet been included in the longest proof-of-work chain. Miners usually draw verified transactions from the mempool to build up transaction blocks.
Metadata Signature
The metadata signature is an aggregated Commitment Signature ("ComSig") signature, attached to a transaction output and signed with a combination of the homomorphic commitment private values \( (v_i \, , \, k_i )\), the spending key known only to the receiver, and sender offset private key \(k_{Oi}\) known only to the sender. This prevents malleability of the UTXO metadata.
Mimblewimble
Mimblewimble is a privacy-centric cryptocurrency protocol. It was dropped in the Bitcoin Developers chatroom by an anonymous author and has since been refined by several authors, including Andrew Poelstra.
Mining Server
A Mining Server is responsible for constructing new blocks by bundling transactions from the mempool of a connected Base Node. It also distributes Proof-of-Work tasks to Mining Workers and verifies PoW solutions.
Mining Worker
A Mining Worker is responsible for performing Proof-of-Work tasks received from its parent Mining Server.
Multisig
Multi-signatures (Multisigs) are also known as N-of-M signatures, this means that a minimum of N number of the M peers need to agree before a transaction can be spent. N and M can be equal; which is a special case and is often referred to as an N-of-N Multisig.
Node ID
A node ID is a unique identifier that specifies the location of a communication node or communication client in the Tari communication network. The node ID can either be obtained from registration on the Base Layer or can be derived from the public identification key of a communication node or communication client.
Non-fungible Token (NFT)
A Non-fungible token is a specific instance of a token issued as part of a digital asset. It is another name for a [digital asset token]. NFTs are contained within specially marked UTXOs on the Tari Base Layer.
Orphan Pool
The orphan pool is part of the mempool and manages all transactions that have been verified but attempt to spend UTXOs that do not exist or haven't been created yet.
Pending Pool
The pending pool is part of the mempool and manages all transactions that have a time-lock restriction on when it can be processed or attempts to spend UTXOs with time-locks.
This is a local setting for each node to help reduce syncing time and bandwidth. This is the number of blocks from the chain tip beyond which a chain will be pruned.
Public Nomination Mode
An asset runs in public nomination mode when the Asset Issuer broadcasts a call for nominations to the network and VNs from the network nominate themselves as candidates to become members of the committee for the asset. The Asset Issuer will then employ the CommitteeSelectionStrategy to select the committee from the list of available candidates.
Range proof
A mathematical demonstration that a value inside a commitment (i.e. it is hidden) lies within a certain range. For Mimblewimble, range proofs are used to prove that outputs are positive values.
Registration Deposit
An amount of tari coin that is locked up on the base layer when a Validator Node is registered. In order to make Sybil attacks expensive and to provide an authorative base layer registry of validator nodes they will need to lock up a amount of Tari Coin on the Base Layer using a registration transaction to begin acting as a VN on the DAN.
Registration Term
The minimum amount of time that a VN registration lasts, the Registration Deposit can only be released after this minimum period has elapsed.
Reorg Pool
The reorg pool is part of the mempool and stores all transactions that have recently been included in blocks in case a blockchain reorganization occurs and the transactions need to be restored to the transaction pool.
Script Keypair
The script private - public keypair, \((k_{Si}\),\(K_{Si})\), is used in TariScript to unlock and execute the script associated with an output. Afterwards the execution stack must contain exactly one value that must be equal to the script public key.
Script Offset
The script offset provides a proof that every script public key \( K_{Si} \) and sender offset public key \( K_{Oi} \) provided for the a transaction's inputs and outputs are correct.
Sender Offset Keypair
The sender offset private - public keypair, (\( k_{Oi} \),\( K_{Oi} \)), is used by the sender of an output to lock all its metadata by virtue of a [sender metadata signature].
Spending Key
A private spending key is a private key that permits spending of a UTXO. It is also sometimes referred to as a Blinding Factor, since is Tari (and Mimblewimble) outputs, the value of a UTXO is blinded by the spending key:
$$ C = v.H + k.G $$
The public key, \(P = k.G\) is known as the public spending key.
SynchronisationState
The current synchronisation state of a Base Node. This can either be
-
starting- The node has freshly started up and is still waiting for first round of chain_metadata responses from its neighbours on which to base its next state change. -
header_sync- The node is in the process of synchronising headers with chosen sync peer. -
horizon_sync- The node is in the process of syncing blocks from the tip to its [pruning horizon] -
block_sync- The node is in the process of syncing all blocks back to the genesis block -
listening- The node has completed its syncing strategy and will continue to listen for new blocks and monitor its neighbours to detect if it falls behind.
SynchronisationStrategy
The generalised approach for a Base Node to obtain the current state of the blockchain from the peer-to-peer network. Specific implementations may differ based on different trade-offs and constraints with respect to bandwidth, local network conditions etc.
Tari Coin
The base layer token. Tari coins are released according to the emission schedule on the Tari base layer blockchain in coinbase transactions.
TariScript
Tari uses a scripting system for transactions, not unlike Bitcoin's scripting system, called TariScript. It is also simple, stack-based, processed from left to right, not Turing-complete, with no loops. It is a list of instructions linked in a non malleable way to each output, specifying its conditions of spending.
Transaction
Transactions are activities recorded on the Tari blockchain running on the base layer. Transactions always involve a transfer of Tari coins. A mimblewimble transaction body consists of one or more blinded inputs and outputs.
Transaction Pool
The transaction pool is part of the mempool and manages all transactions that have been verified, that spend valid UTXOs and don't have any time-lock restrictions.
Trusted Node
A permissioned Validator Node nominated by an Asset Issuer that will form part of the committee for that Digital Asset.
Token Wallet
A Tari Token Wallet is responsible for managing Digital assets and Tokens, and for constructing and negotiating instructions for transferring and receiving Assets and Tokens on the Digital Asset Network.
Transaction Weight
The weight of a transaction / block measured in "grams". See Block / Transaction weight for more details.
Unspent transaction outputs
An unspent transaction output (UTXO) is a discrete number of Tari that are available to be spent. The sum of all UTXOs represents all the Tari currently in circulation. In addition, the sum of all UTXO values equals the sum of the block rewards for all blocks up to the current block height.
UTXO values are hidden by their commitments. Only the owner of the UTXO and (presumably) the creator of the UTXO (either a Coinbase transaction or previous spender) know the value of the UTXO.
Validator Node
Validator nodes (VNs) make up the Tari second layer, or Digital Asset Network. VNs are responsible for creating and updating digital assets living on the Tari network.
Wallet
A Tari Wallet is responsible for managing key pairs, and for constructing and negotiating transactions for transferring and receiving tari coins on the Base Layer.
