Alias: A value that can be associated with an account, and used in some circumstances instead of the account id triplet.
Most often used to indicate a 20-byte value that can be used in smart contracts to refer to a Hedera account.
All accounts will have a (derived) account num alias, but all accounts may have a single EVM address alias or key alias.
The different kinds of alias are detailed in HIP-5831. HIP-322 also describes a _key alias.
- Account num alias: The account ID triplet, encoded as a 64-bit
longin the usual way, then prefixed with 12 bytes of0to form a 20-byte value- a.k.a. "long zero address" (though this term is somewhat deprecated)
- EVM address alias: An EVM address - the rightmost 20 bytes of the 32 byte Keccak-256 hash of an ECDSA sep25661 public key; that is, an "address" on an Ethereum-like chain as defined in the Ethereum Yellow Paper.
- Key alias: Available if an account's key is a "primitive" key - not a
threshold key or keylist. These are protobuf serialized keys of ED25519 or ECDSA
Keys.- AKA Account Alias in the earlier HIP-322
Address Book: The network address book is data structure that contains information (such as node ID, alias, IP address, and weight) for all nodes in the network, not just consensus, but also block nodes, future validator nodes and more. The address book is stored as a file on disk at the moment but will be stored purely in state as part of Dynamic Address Book phase 3. Disambiguation: There is also an "address book" in files 0.0.101 and 0.0.102 which is different to the "network address book" which are manually managed by devops.
Admin Transaction: A HAPI transaction which requires the transaction fee payer to be a Privileged System Account. Some examples of Admin Transactions include the following:
- Freeze Transactions
- System Delete
- System Undelete
- Address Book File 0.0.101/102 updates
- Exchange Rate File 0.0.111 updates
- Dynamic Properties File 0.0.121 updates
Application Accounts: Used by developers and users interacting with applications deployed on Hedera. These accounts enable users to interact with the functionality provided by dApps, such as gaming, finance, or other decentralized services.
Auto Associations: The ability of accounts to automatically associate with tokens. An auto
association is one or more slots you approve that allow tokens to be sent to your contract or
account without explicit authorization for each token type. If this property is not set, you must
approve each token manually (via the TokenAssociateTransaction in the SDKs) before it can be
received, held, or sent by that account. https://hips.hedera.com/hip/hip-904 - currently in
progress, will represent a significant change which allows for the number of "automatic association"
slots to be set to -1 which represents infinite slots.
AutoRenewal: Is a feature designed to automatically renew the lifecycle of certain entities ( like accounts, files, smart contracts, topics, or tokens) by funding their renewal fees. This is particularly useful for entities that require continuous operation over long periods, as it automates the process of keeping these entities active by periodically charging a linked auto-renew account. See https://hips.hedera.com/hip/hip-16 and https://hips.hedera.com/hip/hip-372 for more information. Note that rent and expiration are not currently enabled but will be in the future.
Boneh-Lynn-Shacham (BLS): A paired-elliptic-curve based signature algorithm with attractive characteristics for aggregate signatures (signatures produced by aggregating many individual signatures, and verifiable with a single public key). BLS comes from the names of the authors of the initial research paper (Dan Boneh, Ben Lynn, Hovav Shacham). Authors Paper here: Link
Block Proof: Cryptographic proof that a particular block contains a given block item. Block proofs will also be the basis of State Proofs as the root hash of states will be included in each block. see
Block Signature: Aggregated (BLS) signature of the hash of Block stream merkle root. Appended to the end of a block stream it is used to verify the block was produced by the majority weight of the network. These signatures will also be used for Invalid State Detection.
Block Stream: A fully verifiable stream of data consisting of individual blocks corresponding to consensus rounds. Each block contains all events, transactions, and state changes that occurred within one consensus round. A block is transmitted from consensus node to block nodes as a stream of individual block items, which form a merkle tree that is verified by a Block Signature. Each block is connected to the previous block by a Block Hash which, together form a block chain.
Child Transaction: A Synthetic Transaction that the EVM or Services initiates as a result of fulfilling a user-initiated transaction ( e.g. Hollow Accounts creation, auto-account creation, or a scheduled execution).
Civilian Accounts: User accounts that are not associated with any special roles or permissions beyond standard user functionality. These are mostly used for testing purposes. By contrast, System Accounts and Node Accounts are accounts that have specific roles and responsibilities within the infrastructure and governance of the Hedera network.
Config.txt: A text file loaded by the platform on startup if no valid state is found on disk. This file contains the address book to use when starting from genesis.
Congestion Pricing: A mechanism designed to manage network congestion by dynamically adjusting transaction fees based on network demand. The primary goal of congestion pricing is to discourage excessive network usage during peak times. Refer to Congestion Pricing and Fees.
Consensus Time: The timestamp assigned by the Platform to a transaction once it has reached consensus across the network. This timestamp indicates the moment when the network agrees on the order and validity of the transaction, ensuring that all participants have a consistent view of the transaction sequence.
Delegate Call: Used to call a function in another contract, but with the context of the calling contract. This allows for the execution of functions in one contract as if they were part of another but retains the original caller’s context (msg.sender and msg.value). See Delegate Call for more information.
EOA (Externally Owned Accounts): Accounts that are controlled by private keys and are not associated with smart contracts. These accounts are used to send and receive transactions on the network and interact with smart contracts. In contrast to contract accounts or token accounts, EOAs are typically owned by individual users and are used to manage their assets and participate in the network. Some examples of these are Application Accounts and Civilian Accounts
Hollow Accounts: An account that has been created with an account number and alias but lacks an account key. This term is specifically used to describe accounts are auto-created by doing a CryptoTransfer to an alias that is of EVM address size, which allows applications to create user accounts instantly, even without an internet connection, by assigning an account alias. See also Account Aliases, https://hips.hedera.com/hip/hip-32 and https://hips.hedera.com/hip/hip-583.
Leaky Tests: Are unit or other tests that should not be run in parallel because they can “leak” some of their state or data out into the global state.
Precompiles: Behave as if they were contracts deployed at specific addresses (with one exception: The EIP-4788 "beacon roots contract" which is a real contract deployed at a specific address) In Ethereum, they are very low addresses, 0x00 .. 0x0F). They are not implemented as contracts because that would be far too slow, instead they are built-in to the code of the Ethereum EVM, which checks to see if the address you're calling is one of the precompiles and then just runs the related code. We call our equivalent System Contracts but there may still some legacy references to "precompiles" in the codebase and older documentation.
Privileged System Accounts: An account with an entity ID of 0.0.1000 or lower. These are accounts that are authorized to handle Admin Transactions. Some privileged accounts, like account 0.0.2 or 0.0.58, are owned by the Hedera Council. This means their keys are on the account and their signatures would be required if the account is being modified or used to pay for - Admin Transactions
Security Model v2: Hedera introduced the HSCS Security Model v2 to enhance the security of its network building with improved features to better safeguard against potential vulnerabilities and attacks. By incorporating enhanced cryptographic techniques, robust consensus mechanisms, decentralized governance, and continuous monitoring. Key features include - Restrictions on Smart contracts Storage; Prohibition on Delegate Calls to System Smart Contracts; Limited Access to EOAs' Storage; Token Allowance Requirement for Balance Changes. Refer to this official blog post for more information.
Sidecars: In Services, a sidecar refers to additional records that are created alongside the main transaction records. These sidecar records provide more detailed information about the transactions, making it easier to debug and understand the state changes that occur as a result of the transactions. Note that these are related to the current record stream implementation and will be replaced by block streams in the future.
Synthetic Transaction: Any transaction that is neither submitted through HAPI nor created by the
platform. An example of which is the the deletion of an expired entity that did not pay rent.
Synthetic transactions are presented in the block stream (and record files) as a non-system
transaction with a non-zero nonce or scheduled = true in the TransactionID value. Note that
the use of a scheduled flag instead of a non-zero nonce for scheduled transactions is for legacy
reasons.
System Contracts: Smart contracts that have a permanent address in the network, meaning they will always be available at the same contract address. One example is the Token Service System Contract which allows smart contracts on Hedera to interact with the Hedera Token Service, offering functionalities like token creation, burning, and minting through the EVM
System Transaction: A transaction created by the platform (not services) software. An example of which is a node's signature on a state. Inside an event, every transaction has a flag saying whether it is a system transaction or not.
Token Allowance: A feature that allows an account (the owner) to authorize another account (the spender) to transfer tokens on its behalf up to a specified limit. This mechanism is similar to the ERC-20 allowance mechanism used in Ethereum. The amount of tokens that a user has authorized another user or smart contract to spend on their behalf. This allowance is set by the user and can be modified or revoked at any time. It allows the spender to spend tokens on behalf of the owner without requiring explicit approval for each transaction.
Triplet: An id for some Hedera semantic object (e.g., Account, Token Type, File) of the
form shard.realm.num.
- For a standard entity id:
- The display format shows
shard,realm, andnumin base-10 - E.g.,
0.0.12345678 - Each of
shard,realm, andnumare 8-bytelongvalues - Currently
shardandrealmare always0 - For aliases - where the triplet form is used for user input/output only and not used internally in the code:
numcan be a hex-encoded value of:- The entity ID encoded as an account num alias (i.e., long-zero)
- E.g.,
0.0.00000000000000000000000000000000004D67FB - EVM address
- E.g.,
0.0.b794f5ea0ba39494ce839613fffba74279579268 - Key alias
- E.g.,
0.0.1220d75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f707511a
WeiBar: 1 hbar is equivalent to 100,000,000 (100 million) weibars. The unit of hbar used when you come in via an ethereum transaction - it's like wei is to ether.