-
Notifications
You must be signed in to change notification settings - Fork 10
Glossary
Quick definitions for every term you'll run into while reading these docs and building on Xaya. Each entry links to the page that covers the concept in depth — if a definition raises more questions than it answers, follow the link. Entries are alphabetical.
Game logic whose output depends only on its inputs — no randomness without an on-chain seed, no wall-clock time, no floating-point ambiguity, no external I/O. Determinism is what lets everyone running the same GSP code compute bit-identical game state from the same chain. See What-Makes-a-GSP and Blockchain-Gaming-Basics.
The on-chain escape hatch in a game channel: if your opponent stalls or cheats, you publish your latest signed state on-chain, and they must answer with a newer one or lose on timeout. See Game-Channels.
A technique that moves gameplay off-chain for speed: two players exchange signed state updates directly, while the chain only sees channel open/close and dispute/resolution moves. The GSP still arbitrates by replaying the same rules in C++. See Game-Channels.
The short string that identifies a game inside the move envelope — for example mv for the mover tutorial game. A GSP only processes moves addressed to its own game ID. See What-Makes-a-GSP and Names-and-Moves.
The complete current world of a game (player positions, inventories, scores), derived deterministically from the ordered sequence of moves on the chain. Internally it might be a protobuf blob or an SQLite database; clients see it as JSON via the GSP's RPC interface. See What-Makes-a-GSP and GSP-RPC-Interface.
A daemon that embeds libxayagame plus your game's own logic and deterministically derives the game state from on-chain moves. Anyone can run one, everyone running the same GSP code gets identical state, and the GSP never writes to the chain. See What-Makes-a-GSP and Xaya-Architecture.
The block height (and optionally hash) where a game's history begins, returned by the game's GetInitialState callback. Moves sent before this height are invisible to the game. See What-Makes-a-GSP and Tutorial-Mover-Part-1-Setup.
The C++ library that does the heavy lifting for a GSP: chain connection, reorg detection and rewind, initial sync, storage transactions, pruning, and the GSP's own JSON-RPC server. You supply the game rules; DefaultMain wires up the rest. See What-Makes-a-GSP.
A game action sent by a player, expressed as JSON and stored on-chain via the XayaAccounts contract's move() call. Invalid moves are ignored by the GSP, not rejected by the chain — your game rules decide what counts. See Names-and-Moves.
The outer JSON wrapper that routes move data to games: {"g":{"mv":{...}}}, where keys under "g" are game IDs and values are game-specific move data. One transaction can target multiple games at once. See Names-and-Moves.
A Xaya identity such as p/alice, minted as an ERC-721 NFT by the XayaAccounts contract for a flat 1 WCHI fee. Names are permanent (no renewal), and one name can play any game. See Names-and-Moves.
The prefix before the / in a Xaya name, indicating its purpose. Player names always use the p namespace (p/alice). See Names-and-Moves.
Moves that have been broadcast but not yet confirmed in a block. libxayagame can track them so clients can react before confirmation, but XayaX does not currently provide a pending feed, so the pending state stays empty on Polygon. See GSP-RPC-Interface.
Polygon's native gas token, used to pay transaction fees (18 decimals). A typical move transaction costs well under $0.01 in POL. See Tutorial-Mover-Part-2-Playing.
The EVM Proof-of-Stake chain where Xaya games currently run, chosen for cheap, fast (~2-second block) transactions. The XayaAccounts contract lives here, and XayaX bridges it to GSPs. See Xaya-Architecture.
Discarding undo data for blocks older than a configured depth to save disk space — --enable_pruning=1000 keeps undo data for the last 1000 blocks. A pruned GSP can only rewind that far during a reorg. See What-Makes-a-GSP.
A chain reorganization: the blockchain temporarily forks and a different branch wins, so recent blocks are replaced. libxayagame detects this and rewinds the game state using undo data, then reapplies the new branch's moves. See What-Makes-a-GSP and Blockchain-Gaming-Basics.
A libxayagame base class for games that keep their state in an SQLite database instead of a single in-memory blob — the practical choice for larger games. Such games can also expose extra game-specific RPC methods. See What-Makes-a-GSP.
A chain of signed moves that proves the latest agreed state of a game channel. The GSP can verify a state proof by replaying the same C++ game rules, which is how on-chain disputes get settled. See Game-Channels.
Per-block information a GSP produces while processing moves forward, sufficient to reverse that block during a reorg. The cheap hack is storing the whole previous state; the proper way is a minimal per-block diff. See What-Makes-a-GSP and Tutorial-Mover-Part-3-Code-Walkthrough.
A long-polling GSP RPC method: pass the block hash you last saw, and the call blocks until the state changes, returning the new best block hash (~2–3 seconds on Polygon). The standard client loop is waitforchange → getcurrentstate → repeat. See GSP-RPC-Interface.
The Xaya token as an ERC-20 on Polygon (8 decimals), at 0xE79feAAA457ad7899357E8E2065a3267aC9eE601. It pays name registration fees (flat 1 WCHI) and can optionally be attached to moves as a payment. See Names-and-Moves.
The original Xaya blockchain, where names and moves are native chain features rather than contract calls. It still works today via XayaX's core connector, and its regtest mode is a way to do fully local deterministic testing. See Other-Chains.
The ERC-721 contract on Polygon (0x8C12253F71091b9582908C8a44F78870Ec6F304F) that owns the Xaya name system: it mints names as NFTs and records game moves via its move() function. See Names-and-Moves.
The bridge daemon that subscribes to a blockchain (Polygon via its eth connector, or Xaya Core via core) and translates blocks and moves into the Xaya-Core-style JSON-RPC/ZMQ interface that GSPs consume. GSPs don't know or care which chain is behind it. See Running-XayaX and Other-Chains.
Missing a term? The architecture overview in Xaya-Architecture and the concept deep-dive in What-Makes-a-GSP cover most of these in context.
Xaya developer documentation — verified on Polygon mainnet. Questions? Xaya Development Discord