Glossary
Glossary of terms and definitions for Shinzo Network's decentralized data indexing protocol
- ABI — Application Binary Interface
-
Describes how to encode and decode function calls, arguments, and event data for an EVM contract. Lenses such as
decode_logtake ABI JSON as input to read raw log data. - AccessListEntry
- A document type produced by the indexer for EIP-2930 access list entries attached to Ethereum transactions. Most transactions have no access list, so this collection is usually sparse.
- ACP — Access Control Policy
- A set of rules that controls which identities can read, write, query, or update Shinzo data.
- Assertion
- A cryptographic proof, produced on a source chain, that a validator is who they claim to be. It ties the validator's consensus identity to an operator key. Without a valid assertion, a validator cannot register as an indexer on ShinzoHub.
- AttestationRecord
-
A document a host creates to track how many independent indexers produced the same data for a given block. The
vote_countfield is a P-counter CRDT, so counts converge across hosts without any coordination step. - Bech32
-
An address encoding format used on Cosmos SDK chains. ShinzoHub uses the
shinzoprefix (e.g.,shinzo1ws69...). The same underlying key produces both a hex address and a bech32 address — they are different representations, not different keys. - BIP-44
-
A Bitcoin Improvement Proposal that defines a hierarchical deterministic key derivation path. ShinzoHub uses coin type 60 (the same as Ethereum), so the path
m/44'/60'/0'/0/0produces the same key on both chains. - Block Data
- Raw blockchain data: blocks, transactions, and logs. The indexer fetches this from source chains such as Ethereum and structures it into defraDB documents.
- BlockSignature
- A document the indexer writes after it finishes processing a block. It contains a Merkle root over all document CIDs for that block, signed with the indexer's identity key. Hosts check it to verify the batch came from a known indexer.
- CometBFT
- The BFT consensus engine used by Cosmos SDK chains. ShinzoHub runs CometBFT for block production. Hosts connect to ShinzoHub's CometBFT RPC over WebSocket to receive real-time event notifications.
- Consensus Public Key
- Also called the consensus key. The public key a validator uses to sign blocks and participate in chain consensus, and the field that identifies which validator is asserting on the outpost. The key type is chain-specific: on Ethereum it is a 48-byte BLS12-381 pubkey used on the beacon chain; on Cosmos SDK chains it is typically an Ed25519 CometBFT pubkey. It is distinct from the withdrawal key, which controls stake withdrawals on the execution layer. During an assertion, this key is bound to an operator key so the indexer can act on the validator's behalf on ShinzoHub.
- Content Addressable Data
- A storage approach where data is identified by a cryptographic hash of its content. Changing anything produces a different hash, so you can verify content without trusting the source.
- Content Identifier — CID
- A hash-based identifier derived from content. Used across IPLD and hash-linked data structures to address data by what it is, not where it lives.
- Cosmos SDK
- A Go framework for building app-specific blockchains. ShinzoHub (v0.53.4) and SourceHub are both Cosmos SDK chains. ShinzoHub also bundles an EVM module.
- CRDT — Conflict-free Replicated Data Type
- A data structure that multiple nodes can update independently and then merge without coordination, always reaching the same result. defraDB uses CRDTs — specifically MerkleCRDTs — to merge document updates from peers.
- defraDB
- A peer-to-peer, document-oriented database embedded in every indexer and host. It handles storage, content addressing, CRDT merging, query serving, and P2P replication via libp2p.
- DID — Decentralized Identifier
-
A self-sovereign identifier (e.g.,
did:key:z6Mk...) derived from a public key. Hosts, indexers, and users are identified by DIDs in SourceHub authorization tuples. - DID Key — Digital Identity Key
- A cryptographic key pair that represents a user's or device's identity in Shinzo. It is used for signing, encrypting, and authenticating operations.
- ECDSA — Elliptic Curve Digital Signature Algorithm
- The signature algorithm used by Ethereum and ShinzoHub (secp256k1 curve). Viewkit derives an ECDSA private key from the wallet to sign deploy transactions.
- EIP-2930
-
An Ethereum standard that adds optional access lists to transactions, pre-declaring which storage slots a transaction will read or write. The indexer stores these as
AccessListEntrydocuments. - EIP-712
- An Ethereum standard for signing structured, typed data in a form users can read before approving. The EVM outpost contract uses EIP-712 for the digest that a validator's withdrawal key signs during an assertion.
- Epoch
- A fixed number of blocks treated as one unit of time. On Ethereum, an epoch is 32 blocks.
- EVM — Ethereum Virtual Machine
- The runtime that executes Solidity smart contracts. ShinzoHub embeds an EVM module so its registries are accessible as precompiled contracts at fixed addresses, callable from any EVM tooling.
- EVM Relayer
- A Go process that bridges an external EVM chain (e.g. Ethereum) to ShinzoHub. It subscribes to outpost events, extracts assertion or payment data, and broadcasts the relevant Cosmos SDK messages to ShinzoHub. Not the same as the Hermes IBC relayer.
- Geth
- Go-Ethereum, the Go implementation of an Ethereum node. Each indexer runs alongside a Geth node and connects over WebSocket (port 8546) and JSON-RPC (port 8545) to fetch block data.
- GraphQL
- Hermes
- An IBC relayer written in Rust by Informal Systems. It moves IBC packets between ShinzoHub and SourceHub by fetching Merkle proofs from one chain and submitting them to the other. It is stateless and cannot fabricate packets; SourceHub verifies each one against a state proof.
- Host
- A Shinzo node that receives indexed data from indexers over P2P, verifies it, runs lens transforms to produce view documents, and serves those documents over GraphQL.
- Host Registry
-
The ShinzoHub EVM precompile at
0x0211that tracks registered hosts. View.sol contracts check it before acceptingreport()andconsume()calls. - IBC — Inter-Blockchain Communication
- A protocol for passing authenticated messages between independent blockchains. It works in layers: light clients verify state proofs, connections link two chains, channels carry ordered or unordered packets, and applications (like ICA) run on top. ShinzoHub and SourceHub communicate over IBC.
- ICA — Interchain Accounts
- An IBC application that lets one chain control an account on another. ShinzoHub uses ICA to send policy commands to its account on SourceHub. ICA channels are ordered, meaning a single timed-out packet permanently closes the channel and a new one must be opened.
- Indexer
- A node that reads blockchain data from a source chain, parses it into structured documents, and writes them to defraDB. Indexers are write-only: they push data out over P2P and reject all incoming replication.
- Indexer Registry
-
The ShinzoHub EVM precompile at
0x0212that tracks registered indexers. An indexer cannot register here directly — it must first complete an assertion via an outpost contract. The registry verifies the stored assertion before accepting registration. - Indexing
- The process of parsing blockchain data and storing it as structured, schema-compliant documents in defraDB.
- IPLD — Interplanetary Linked Data
- A data model for decentralized systems (used by IPFS, among others). It structures data as Merkle DAGs so every object is content-addressed and verifiable.
- Keeper
- In Cosmos SDK, a Go object that owns a module's state and provides the only sanctioned way to read or write it. Precompile code on ShinzoHub calls keepers directly — for example, to send an ICA packet — without going through Solidity bytecode.
- Lens
-
A WASM module that transforms primitive documents (e.g., raw
Logrecords) into view documents (e.g.,USDCTransfer). Lenses must be deterministic: the same input always produces the same output. Hosts run them via LensVM. - LensVM
-
The WASM execution environment inside a host that runs lens transforms. It supports Wasmtime, Wasmer, and Wazero runtimes, and can run lenses in both directions if the WASM module exposes an
inverse()function. - libp2p
- A peer-to-peer networking library. defraDB uses it for peer discovery and document replication between indexers and hosts.
- Log
-
A document type the indexer produces for event logs emitted during transaction execution.
topicsholds the indexed parameters anddataholds the non-indexed ones, both as raw hex. ABI decoding happens later, in a lens. - Materialized directive
-
A GraphQL SDL annotation used in view definitions.
@materialized(if: true)tells defraDB to pre-compute and store view data at write time, so queries are fast but storage use is higher.@materialized(if: false)computes results on query. - Merkle DAG
- A directed acyclic graph where each node is identified by a hash of its content and links to parents by their hashes. Unlike a Merkle tree, nodes can have multiple parents. defraDB uses Merkle DAGs to store document history.
- Merkle Tree
- A tree where each internal node is the hash of its children. Changing any leaf changes every hash up to the root, so you can verify any piece of the dataset by checking a small proof.
- MerkleCRDT
- defraDB's core storage primitive. Each document update is a CRDT operation stored as a node in a Merkle DAG. The CRDT part handles conflict-free merging; the Merkle DAG part gives verifiable history and lets peers sync only what they are missing.
- MEV-boost
-
A service on Ethereum that lets validators hand off block construction to external builders. Because those builders control the block's
extraDatafield, Shinzo's assertion design does not rely on it — validator identity is read directly from the outpost event instead. - Module
-
A Cosmos SDK building block that owns a slice of chain state, handles messages, and emits events. ShinzoHub adds five custom modules (
x/admin,x/sourcehub,x/host,x/indexer,x/view) on top of the standard Cosmos set. - Network Gateway
- A coordination service that routes user GraphQL queries to the right host. It never touches the underlying data.
- Node Key
- A node identity key submitted alongside the peer key during host registration. ShinzoHub verifies both signatures and derives the host's DID and PID from them.
- Operator Key
- Also called the delegate key. Generated locally by an indexer operator and bound to a validator's identity through an assertion. The indexer uses it to sign ShinzoHub registrations and protocol actions.
- Orbis
- Shinzo's key management component. It generates, stores, and provides access to the cryptographic keys used for identity, encryption, and signing.
- Outpost
- A smart contract deployed on a source chain. Validators call it to prove their identity before registering as indexers; users call it to pay for view access in the source chain's native currency. Each chain type has its own outpost implementation.
- P-counter — Positive Counter
-
A CRDT that only increments. Each node tracks its own count separately; merging just takes the max per node and sums them.
AttestationRecord.vote_countuses a P-counter so all hosts converge on the same indexer count without coordinating. - Peer Key
- One of two keys submitted during host registration. It identifies the host on the libp2p network.
- PID — Peer ID
- A libp2p peer identifier derived from a host's keys at registration time. Other peers use the PID to address the host on the P2P network.
- Precompile
-
A contract at a fixed EVM address implemented in native Go rather than Solidity bytecode. ShinzoHub's three registries (View
0x0210, Host0x0211, Indexer0x0212) are precompiles so they can call Cosmos SDK keepers directly and trigger ICA packets. - Primitive Prefix
-
A prefix added to document collection names to namespace them by chain and network (e.g.,
Ethereum__Mainnet__Block). Keeps documents from different chains separate in the same defraDB instance. - Re-org
- Short for chain reorganization: the canonical block at a given height changes. When this happens, different indexers may briefly hold different versions of the same block. Hosts store each version as a separate document; applications pick the one with more attestation votes.
- Relayer
- A process that moves data between chains. Shinzo uses two that share nothing but the name: the EVM relayer bridges Ethereum to ShinzoHub, and Hermes bridges ShinzoHub to SourceHub over IBC.
- Scheduler
- A coordination service that reads registrations from ShinzoHub and matches indexers to hosts. Like the gateway, it never handles actual data.
- Schema Definition Language — SDL
- The GraphQL-based schema language used to define document types, fields, constraints, and relationships in defraDB. Views and collections are both defined in SDL.
- ShinzoHub
- Shinzo's coordination chain: a Cosmos SDK chain (v0.53.4) with an integrated EVM, running CometBFT consensus. It holds the view, host, and indexer registries and the economic layer (staking, pricing, payments). It does not store or serve indexed blockchain data.
- SHNZ
-
ShinzoHub's native token. The display denomination; on-chain the base unit is
ushinzo(1 SHNZ = 10^18 ushinzo). Used for staking, transaction fees, view funding, and relayer gas. - Smart Contract
- Deterministic code deployed on a blockchain. The same inputs always produce the same output, and the output is verifiable by anyone.
- SnapshotSignature
-
A document that seals a contiguous range of blocks into a single signed file for faster initial sync. Its Merkle root covers the per-block
BlockSignatureroots within the range, forming a two-level tree: document CIDs roll up to block roots, which roll up to the snapshot root. - Source chain
- Any external blockchain that Shinzo indexes — Ethereum, an L2, a Cosmos chain, etc. A source chain hosts an outpost contract and is read by indexers.
- SourceHub
-
A separate Cosmos SDK chain built by Source Network that handles authorization for Shinzo. It runs the ACP module (based on Google's Zanzibar model) and stores authorization tuples in the form
object#relation@user. Users never call SourceHub directly — ShinzoHub sends commands to it via ICA. - Stream ID
- A unique identifier assigned to a curated data feed when it is registered.
- SVPS-1 — Shinzo View Pricing Standard 1
-
An optional pricing contract interface a view can use instead of the default SVS-1 formula. It exposes a single
price() returns (uint256)function. - SVS-1 — Shinzo View Standard 1
-
A per-view smart contract deployed automatically by the View Registry at registration time. It exposes
stake(),fund(did),consume(did), andreport(). The default price formula israte × complexity × premiumminus a 5% protocol fee. - ushinzo
- The base denomination of SHNZ on ShinzoHub. 1 SHNZ = 10^18 ushinzo. Most user-facing tools display SHNZ; on-chain accounting uses ushinzo.
- Validator
- An entity that participates in a chain's consensus. On Ethereum, a validator's withdrawal key signs an EIP-712 message on the outpost to authorize an operator key as its indexer.
- View
- A curated, SDL-defined representation of defraDB documents. Views transform raw indexed data into a structured output shape.
- View Registry
-
The ShinzoHub EVM precompile at
0x0210. Whenregister(bytes)is called, it decodes the VWL bundle, registers the view in SourceHub via ICA, and deploys an SVS-1 contract for the new view. - ViewBundle
- The packaged form of a view: GraphQL query, SDL, lens metadata, and WASM lens binaries. Viewkit produces a ViewBundle and submits it to the View Registry. The wire format is VWL.
- Viewkit
- A CLI tool for creating, testing, and deploying views. It defines the SDL, attaches lenses, runs local validation using the Wasmer runtime, packages everything into a ViewBundle, and submits a deploy transaction to the View Registry.
- VWL — View Wire Language
-
The binary format for view bundles. It is a single byte stream: a
"VWL"magic header and version byte, then the GraphQL query, SDL, lens metadata, and a lens blob (optionally zstd-compressed) containing the WASM binaries. - WASM — WebAssembly
- A portable, sandboxed bytecode format. Lens transforms compile to WASM — typically from Rust or AssemblyScript — and hosts run them via LensVM.
- Wasmer
- A WASM runtime written in Rust. Viewkit uses it to validate lenses locally before deployment.
- Wasmtime
- A WASM runtime written in Rust. The primary runtime used to execute lenses in production hosts.
- Wazero
- A pure-Go WASM runtime with no CGo dependency. An alternative lens runtime in LensVM, useful when avoiding CGo is a requirement.
- Withdrawal Key
- On Ethereum, the key that controls a validator's stake withdrawals. The outpost requires the withdrawal key to sign the EIP-712 assertion digest — it is the chain's strongest proof that a given party controls the validator.