165 lines
11 KiB
Markdown
165 lines
11 KiB
Markdown
# Glossary
|
|
|
|
This glossary defines technical terms used throughout the Zenith documentation that may be unfamiliar to the average reader.
|
|
|
|
---
|
|
|
|
## A
|
|
|
|
### ABCI / ABCI++
|
|
**Application Blockchain Interface** - The interface between the consensus engine (CometBFT) and the application logic in Cosmos SDK blockchains. ABCI++ is an enhanced version that adds features like vote extensions for collecting external data during consensus rounds and optimistic execution for improved performance.
|
|
|
|
### Attestation
|
|
A cryptographic proof that links an Azimuth point owner's Ethereum address to their Zenith address. Participants submit nested attestations during onboarding, with both Ethereum and Zenith signatures proving ownership and identity.
|
|
|
|
### Azimuth
|
|
Urbit's identity registry system deployed on Ethereum. It serves as the source of truth for Urbit point ownership, maintaining a hierarchical structure of cryptographic identities (galaxies, stars, and planets). Zenith uses Azimuth as the basis for validator eligibility and network participation. See [Azimuth](documentation/azimuth.md) for detailed information.
|
|
|
|
---
|
|
|
|
## B
|
|
|
|
### Bundle / Bundling
|
|
The process of aggregating multiple individual transactions into a single batch for efficient processing and MEV opportunities. Stars' Janus server collect transactions from Planets and bundle them before submitting to their sponsoring Galaxys' Janus server.
|
|
|
|
---
|
|
|
|
## C
|
|
|
|
### Comet
|
|
The lowest tier in the Urbit identity hierarchy, representing a temporary, disposable identity. Comets have unlimited supply and currently have no specific role in the Zenith network.
|
|
|
|
### Consensus
|
|
The process by which distributed nodes in a blockchain network agree on the current state of the ledger. Zenith uses Cosmos SDK's Tendermint-based consensus mechanism where validators propose, validate, and finalize blocks.
|
|
|
|
### Cosmos SDK
|
|
An open-source framework for building custom blockchain applications in Go. It provides modular architecture with pre-built modules for common blockchain features, fast finality, seamless upgrades without hard forks, and extensive developer tools.
|
|
|
|
---
|
|
|
|
## E
|
|
|
|
### EndBlocker
|
|
A lifecycle hook in Cosmos SDK that executes logic at the end of each block. Zenith uses EndBlocker to apply state changes like validator jailing and slashing and ownership transfers after consensus has been reached.
|
|
|
|
### ePBS (Enshrined Proposer-Builder Separation)
|
|
A protocol-level mechanism that separates the roles of block proposers (who choose which transactions to include) and block builders (who construct the actual blocks). Zenith implements ePBS through a lane-based architecture that ensures fair block space allocation and improves censorship resistance. Stars build bundles from transactions and Galaxies build blocks from bundles.
|
|
|
|
---
|
|
|
|
## G
|
|
|
|
### Galaxy
|
|
The top tier in the Urbit identity hierarchy, limited to exactly 256 total identities. In Zenith, only galaxies can be validators who build blocks and participate in consensus. Galaxy validators must also own an "associated star" (a star sponsored by and owned by the same account as their galaxy).
|
|
|
|
### Genesis / Genesis File
|
|
The initial state of a blockchain at launch, encoded in a genesis.json file. It contains all starting balances, validator information, and module configurations. Zenith's genesis is created during the Token Generation Event (TGE), following the Stage 0 Lockdrop Onboarding.
|
|
|
|
---
|
|
|
|
## J
|
|
|
|
### Jailing
|
|
A validator punishment mechanism where a validator is removed from the active validator set and stops earning new token rewards. Jailing typically happens together with slashing. In Zenith, validators are automatically jailed when they transfer ownership of their Azimuth point or fail to maintain uptime requirements.
|
|
|
|
### Janus
|
|
Named after the two-faced Roman god, Janus is the transaction aggregation layer across address space. Stars run Janus to collect transactions from planets, bundle them, and submit to galaxy validators. Galaxy validators run zenithd in validator mode which accepts bundles from both their associated star and independent sponsored stars. Independent star owners run zenithd in star mode which includes the Janus bundling service.
|
|
|
|
---
|
|
|
|
## L
|
|
|
|
### Lane
|
|
A dedicated channel for block construction in Zenith's ePBS implementation. The lane-based architecture splits block space across multiple lanes with different priorities: the associated star lane (15%), sponsored stars lane (75%), and default lane (remaining space).
|
|
|
|
### Lockdrop
|
|
A token distribution mechanism where participants lock assets (Azimuth points) in a smart contract for a specified duration (1-5 years) to earn rights to initial token allocations. Participation in Zenith's lockdrop guarantees an initial $Z allocation at TGE, with longer lock periods potentially offering greater rewards. Lockdrop participation is not required for operators who join later in Stage 2 to earn $Z through active participation. Simulation tools are available at [lockdrop-simulation](https://github.com/Zenith-Foundation/lockdrop-simulation).
|
|
|
|
---
|
|
|
|
## M
|
|
|
|
### MEV (Maximal Extractable Value)
|
|
The maximum value that can be extracted from block production beyond standard block rewards and transaction fees, typically through transaction reordering, insertion, or censorship. Zenith's ePBS implementation helps distribute MEV more fairly.
|
|
|
|
### Moon
|
|
A lower-tier identity in the Urbit hierarchy. Each planet can spawn up to 65,535 moons. Moons currently have no specific role in the Zenith network.
|
|
|
|
### Module
|
|
A self-contained unit of blockchain functionality in the Cosmos SDK architecture. Zenith includes custom modules for onboarding, scry oracle, point tracking, and immutable treasury management, alongside standard Cosmos SDK modules.
|
|
|
|
---
|
|
|
|
## O
|
|
|
|
### Oracle
|
|
A system that brings off-chain data onto the blockchain. Zenith's scry oracle aggregates data from the Urbit network through a decentralized consensus process, making it available for on-chain applications to query.
|
|
|
|
---
|
|
|
|
## P
|
|
|
|
### Planet
|
|
The third tier in the Urbit identity hierarchy. Planets have a sponsorship relationship with stars. In Zenith, planets are the exclusive transaction submitters - only planets can submit transactions to the network. They submit transactions to their sponsoring star's Janus service, which bundles them for galaxy validators. When onboarding to Zenith, planets receive $Z from a faucet operated by their sponsoring star. Planets cannot participate in the lockdrop but are critical network participants starting from Stage 1.
|
|
|
|
### Point
|
|
A cryptographic identity in the Urbit/Azimuth system. Points come in hierarchical classes (galaxies, stars, planets, moons, comets) and represent ownership of a network identity with specific privileges and responsibilities.
|
|
|
|
### Proposer
|
|
The validator selected to construct and propose the next block during a consensus round. In Zenith's ePBS system, the proposer follows lane-based rules to ensure fair inclusion of bundles from different stars.
|
|
|
|
---
|
|
|
|
## S
|
|
|
|
### Scry
|
|
In Urbit, a read-only query mechanism for accessing data stored on Urbit ships. Scry paths point to specific pieces of data (e.g., `/~zen/metadata-store/associations/groups/random-group/json`). Zenith's scry oracle stores mappings from scry paths to their data hashes on-chain.
|
|
|
|
### Ship
|
|
A personal server in the Urbit network, identified by a point. Each ship has a cryptographic identity registered in Azimuth and can communicate with other ships in the network.
|
|
|
|
### Slashing
|
|
The penalty mechanism where validators lose existing tokens for malicious behavior or failure to meet operational requirements. Slashing is more severe than jailing and typically happens together with it. Slashing is usually the consequence of double-signing. In Zenith, validators face automatic slashing when they transfer their Azimuth point ownership or fail to maintain uptime per the protocol requirements.
|
|
|
|
### Sponsorship
|
|
The hierarchical relationship in Urbit where higher-tier points sponsor lower-tier points, providing infrastructure and routing services. Sponsorship relationships can be changed via mutual agreement using Bridge. In Zenith, stars submit transaction bundles to their sponsoring galaxy.
|
|
|
|
### Stakez
|
|
A non-transferable token in Zenith used during Stage 1 for validator mechanics, chain operations, and claiming accrued $Z tokens. In Stage 2, stakez is migrated to Zenith Staking NFTs (ZSN).
|
|
|
|
### Star
|
|
The second tier in the Urbit identity hierarchy. Stars have a sponsorship relationship with galaxies. In Zenith, stars bundle transactions from planets and send them to galaxy validators. There are two types: "associated stars" owned by galaxy validators whose Janus servers run in-process within zenithd validator mode, and independent stars that run zenithd in star mode (which includes the Janus bundling service).
|
|
|
|
---
|
|
|
|
## T
|
|
|
|
### TGE (Token Generation Event)
|
|
The moment when the full supply of $Z tokens is created and allocated. TGE marks the transition from Stage 0 (onboarding) to Stage 1 (mainnet), includes verification of all attestations, and generates the genesis file for mainnet launch.
|
|
|
|
---
|
|
|
|
## V
|
|
|
|
### Validator
|
|
A node operator responsible for participating in consensus, validating bundles, and producing blocks. In Zenith, only galaxies can be validators. Galaxy validators must also own an associated star (sponsored by and owned by the same account as their galaxy) whose Janus server runs in-process within zenithd.
|
|
|
|
### Vote Extension
|
|
An ABCI++ feature that allows validators to attach additional data to their votes during consensus rounds. Zenith uses vote extensions to collect external data (e.g., scry bindings) before reaching consensus.
|
|
|
|
---
|
|
|
|
## Z
|
|
|
|
### zenithd
|
|
The main blockchain daemon (server software) for the Zenith network. Built on Cosmos SDK, zenithd includes custom modules for onboarding, oracle functionality, point tracking, and treasury management, plus a built-in Janus server for accepting transaction bundles.
|
|
|
|
### znt (Zenith Onboarding Token)
|
|
A utility token used exclusively during Stage 0 for making transactions on the Stage 0 zenithd testnet. Delivered via faucet in the onboarding application, znt has no monetary value and is used solely for transaction fees during the onboarding phase.
|
|
|
|
### ZSN (Zenith Staking NFT)
|
|
Tradable NFTs introduced in Stage 2 that represent validation and bundling rights. Each stakez position converts 1:1 to a corresponding ZSN, with galaxies receiving validator rights NFTs and stars receiving bundling rights NFTs. ZSNs add economic weight to Urbit's sponsorship relationships.
|
|
|
|
### $Z
|
|
The native token of the Zenith blockchain, used for transaction fees, governance, and as the base currency for the network. $Z is distributed to lockdrop participants based on their committed Azimuth points and network participation, with vesting schedules determined by individual cliff dates.
|