Ergo Modifiers
In Ergo's P2P protocol, the fundamental units of data exchanged between nodes, such as blocks and transactions, are referred to as "modifiers." Modifiers are transmitted as part of the network synchronization process. The Modifier Exchange process encompasses the protocols and systems designed to exchange this information efficiently and securely across the network.
Ergo Block Structure
The Ergo block, a critical structure in the Ergo blockchain, differs from many other blockchain systems by comprising four distinct sections (modifiers):
Header
Contains the minimal information necessary to synchronize the chain and validate Proof-of-Work (PoW) correctness. It includes cryptographic hashes (roots) of the other sections.
Block Transactions
Consists of the ordered sequence of transactions included within the block.
ADProofs
Contains Authenticated Dictionary proofs associated with the transactions in the BlockTransactions section. These proofs allow light clients to validate transactions against the UTXO set state root hash found in the header.
Extension
Holds supplementary information. This includes interlinks (for NiPoPoWs) and, for blocks at the end of a voting epoch, the blockchain parameters resulting from miner voting.
Header Section
The table below details the fields contained within the Header modifier:
| Field | Size (Bytes) | Description |
|---|---|---|
| version | 1 | Block version number, incremented with each soft or hard fork |
| parentId | 32 | Identifier of the parent block |
| ADProofsRoot | 32 | Hash of ADProofs for transactions in the block |
| stateRoot | 32 | Root hash of the authenticated UTXO set state (an AVL+ tree) after applying the block's transactions |
| transactionsRoot | 32 | Root hash of the Merkle tree of transactions included in the block |
| timestamp | 8 | Block timestamp (in milliseconds since the beginning of the Unix Epoch) |
| nBits | 8 | Current difficulty target (encoded in a compressed format) |
| height | 4 | Block height (distance from the genesis block) |
| extensionRoot | 32 | Root hash of the block's extension section |
| powSolution | 75-107 | Solution to the Autolykos v2 Proof-of-Work puzzle |
| votes | 3 | Bytes representing miner votes for changes in system parameters |
Calculable Fields
In specific modes, nodes can calculate certain fields independently:
- parentId: Calculated when
status==bootstrapANDPoPoWBootstrap == false - ADProofsRoot: Calculated when
status==regularANDADState==false AND BlocksToKeep>0 - stateRoot: Calculated when
status==regularANDADState==false AND BlocksToKeep>0
Extension Section
The Extension section functions as a key-value store capable of holding various data relevant to the block or protocol state.
Structure
- • Keys are consistently 2 bytes long
- • Maximum size for a value is 64 bytes
- • Total size must not exceed 32,768 bytes
- • Updated post-EIP-38 (previously 16,384)
Key Prefixes
0x00Parameters (blockchain parameters)
0x01Interlinks (NiPoPoW interlinks vector)
Predefined Meanings
Parameters (0x00 prefix)
If the first byte of the key is 0x00, the second byte identifies a specific blockchain parameter (e.g., block size limit, cost per byte). The value associated with this key represents the parameter's value. These are typically included only in blocks at the end of a voting epoch.
Interlinks (0x01 prefix)
Keys starting with 0x01 are used for storing the NiPoPoW interlinks vector. The second byte indicates the level k of the link. The value contains the actual block ID (32 bytes) representing the link at that level.