go-cyber

[Edit section]

[Copy link]

• • •

The go-cyber repository implements a decentralized search engine and knowledge graph called Cyber. It allows users to create and query a distributed web of content by linking IPFS content identifiers (CIDs). The core functionality revolves around ranking content, managing network bandwidth, and allocating resources.

The main components of the Cyber blockchain are:

• Ranking system: Calculates relevance scores for content using a custom algorithm. The Rank struct in …/rank.go stores rank values, entropy, and karma for CIDs. Rank calculation is performed by the CalculateRank() function in …/calculate.go, with options for CPU or GPU-based computation.

• Bandwidth management: Tracks and prices network bandwidth usage. The BandwidthMeter in …/keeper.go handles bandwidth accounting, pricing, and updates to account bandwidth.

• Resource allocation: Manages network resources like VOLT and AMPERE. The Keeper in …/keeper.go implements "investmint" operations to convert staked tokens into these resources.

• Graph system: Manages relationships between content. The GraphKeeper in …/graph.go handles storage and retrieval of links between CIDs.

Key design choices include:

• Use of Cosmos SDK for blockchain infrastructure • Custom ranking algorithm with CPU and GPU implementations • Bandwidth metering and dynamic pricing • Resource system for allocating network capacity • WebAssembly integration for smart contract functionality

The application is initialized in …/app.go, which sets up the various modules and configures the blockchain. Transaction processing occurs through the ante handler defined in …/ante.go.

For more details on specific components, see the Ranking System, Bandwidth Management, and Resource Management sections.

Blockchain Core

[Edit section]

[Copy link]

References: app, cmd, types, utils

The App struct serves as the main entry point for the Cyber Consensus Computer application, extending baseapp.BaseApp and implementing runtime.AppI and servertypes.Application interfaces. It orchestrates the core blockchain functionality through the following key components:

Application Setup and Configuration

[Edit section]

[Copy link]

References: app/app.go, app/params, app/keepers

• • •

The NewApp() function in …/app.go is the main entry point for initializing the Cyber blockchain application. It performs the following key tasks:

Transaction Processing

[Edit section]

[Copy link]

References: app/ante.go

• • •

Transaction processing in the Cyber blockchain is handled primarily by the ante handler defined in …/ante.go. The ante handler is responsible for validating transactions, deducting fees, and preparing transactions for execution. Key components include:

State Management

[Edit section]

[Copy link]

References: app/encoding.go, app/export.go, app/genesis.go

• • •

The application state is managed through several key components:

Upgrade Handling

[Edit section]

[Copy link]

References: app/upgrades

• • •

The upgrade handling functionality is implemented in the …/upgrades directory. It contains subdirectories for each version upgrade (v2, v3, v4) and a types.go file defining common types.

Command Line Interface

[Edit section]

[Copy link]

References: cmd/cyber

• • •

The Cyber blockchain's command-line interface is implemented in the …/cyber directory. The main entry point is the main.go file, which sets up and executes the root command using NewRootCmd() and svrcmd.Execute().

Utility Functions

[Edit section]

[Copy link]

References: app/helpers, utils

• • •

The …/helpers and utils directories provide utility functions and types used throughout the Cyber project:

Ranking System

[Edit section]

[Copy link]

References: x/rank

• • •

The ranking system in the Cyber network is implemented primarily through the StateKeeper struct in …/keeper.go. This struct manages the core functionality of rank calculation, search index management, and state updates.

Rank Calculation Algorithm

[Edit section]

[Copy link]

References: x/rank/keeper, x/rank/cuda

• • •

The rank calculation algorithm is implemented in both CPU and GPU versions to provide flexibility and performance optimization. The main entry point is the CalculateRank function in …/calculate.go, which determines whether to use CPU or GPU computation based on the provided ComputeUnit.

State Management and Querying

[Edit section]

[Copy link]

References: x/rank/keeper, x/rank/types

• • •

The StateKeeper struct in …/keeper.go is the primary interface for managing rank-related data. It provides methods for:

Parameter Management

[Edit section]

[Copy link]

References: x/rank/types, x/rank/keeper

• • •

The Params struct in …/params.go defines the configuration parameters for the ranking algorithm:

WASM Integration

[Edit section]

[Copy link]

References: x/rank/wasm

• • •

The Querier struct in …/interface.go serves as the main entry point for WebAssembly integration with the ranking functionality. Key aspects include:

Client Interface

[Edit section]

[Copy link]

References: x/rank/client/cli

• • •

The command-line interface for interacting with the ranking system is implemented in the …/cli directory. The main entry point is the GetQueryCmd() function, which returns a cobra.Command containing various sub-commands for querying rank-related data:

Bandwidth Management

[Edit section]

[Copy link]

References: x/bandwidth

The BandwidthMeter struct in …/keeper.go is the central component for managing bandwidth allocation and pricing. It handles:

Bandwidth Accounting and Pricing

[Edit section]

[Copy link]

References: x/bandwidth/keeper

The BandwidthMeter struct in …/keeper.go is the central component for managing bandwidth usage and pricing. It provides methods for:

State Management

[Edit section]

[Copy link]

References: x/bandwidth/keeper, x/bandwidth/types

• • •

The BandwidthMeter struct in …/keeper.go is the central component for managing bandwidth-related data. It provides methods for:

Parameter Management

[Edit section]

[Copy link]

References: x/bandwidth/types

• • •

The bandwidth module's parameters are defined and managed through the Params struct in …/params.go. This struct includes fields for:

WASM Integration

[Edit section]

[Copy link]

References: x/bandwidth/wasm

• • •

The Querier struct serves as the primary interface for WebAssembly integration with the bandwidth module. It encapsulates a BandwidthMeter keeper, allowing WASM contracts to query bandwidth-related information.

Client Interface

[Edit section]

[Copy link]

References: x/bandwidth/client/cli

• • •

The command-line interface for the bandwidth module is implemented in …/query.go. The GetQueryCmd() function serves as the entry point, returning a cobra.Command object that acts as the root command for all bandwidth-related queries. This root command includes several sub-commands:

Resource Management

[Edit section]

[Copy link]

References: x/resources

• • •

The Keeper struct in …/keeper.go is the primary interface for managing network resources like VOLT and AMPERE. It provides methods for:

Investmint Operation

[Edit section]

[Copy link]

References: x/resources/keeper, x/resources/types

• • •

The Investmint operation allows users to invest SCYB (the base resource) to obtain VOLT or AMPERE. This functionality is primarily implemented in the Keeper struct within …/keeper.go.

State Management

[Edit section]

[Copy link]

References: x/resources/keeper, x/resources/types

• • •

The Keeper struct in …/keeper.go is the primary interface for managing resource-related state. Key functions include:

Parameter Management

[Edit section]

[Copy link]

References: x/resources/types, x/resources/keeper

• • •

The Params struct in …/params.go defines the key parameters for the resources module:

WASM Integration

[Edit section]

[Copy link]

References: x/resources/wasm

• • •

The Messenger struct in …/interface.go serves as the primary interface for WebAssembly integration in the resources module. It contains a keeper field, which references a keeper.Keeper instance, allowing access to the module's core functionality.

Client Interface

[Edit section]

[Copy link]

References: x/resources/client/cli

• • •

The command-line interface for the resources module is implemented in …/cli. Two main components are provided:

Liquidity Pools

[Edit section]

[Copy link]

References: x/liquidity

• • •

The liquidity module implements decentralized liquidity pools for token swapping in the Cyber blockchain. It uses a novel economic model called the Equivalent Swap Price Model (ESPM) to determine swap prices and employs a batch execution methodology for processing deposit, withdraw, and swap orders.

Pool Management

[Edit section]

[Copy link]

References: x/liquidity/keeper/liquidity_pool.go, x/liquidity/types/liquidity_pool.go

• • •

The Pool struct in …/liquidity_pool.go represents a liquidity pool, containing essential information such as pool ID, type ID, reserve coin denoms, reserve account address, and pool coin denom. Pool creation and management are handled by functions in …/liquidity_pool.go:

Batch Execution

[Edit section]

[Copy link]

References: x/liquidity/keeper/batch.go, x/liquidity/keeper/swap.go

The batch execution process in the liquidity module is primarily handled by the ExecutePoolBatches function in …/batch.go. This function orchestrates the execution of accumulated messages in pool batches:

Swap Functionality

[Edit section]

[Copy link]

References: x/liquidity/keeper/swap.go, x/liquidity/types/swap.go

• • •

The SwapExecution function in …/swap.go orchestrates the token swapping process within liquidity pools:

State Management

[Edit section]

[Copy link]

References: x/liquidity/keeper/store.go, x/liquidity/types/keys.go

• • •

The Liquidity module's state management is primarily handled in …/store.go and …/keys.go. These files provide a comprehensive set of functions for managing liquidity pools, batches, and message states.

Parameter Management

[Edit section]

[Copy link]

References: x/liquidity/types/params.go, x/liquidity/keeper/keeper.go

• • •

Parameters for the liquidity module are defined in the Params struct within …/params.go. This struct encapsulates key configuration settings such as:

Client Interface

[Edit section]

[Copy link]

References: x/liquidity/client/cli

• • •

The command-line interface for the liquidity module is implemented in the …/cli directory. The main entry point is the GetTxCmd() function, which returns the root CLI command handler for all liquidity-related transactions. It adds several sub-commands:

Grid System

[Edit section]

[Copy link]

References: x/grid

• • •

The Grid System manages energy routes and routed energy in the Cyber network. At its core is the Keeper struct, which handles state management and business logic for the module.

Energy Route Management

[Edit section]

[Copy link]

References: x/grid/keeper, x/grid/types

• • •

Energy routes in the Grid module are managed through the Keeper struct in …/keeper.go. The core functionality includes:

Routed Energy Tracking

[Edit section]

[Copy link]

References: x/grid/keeper, x/grid/types

• • •

The Keeper struct in …/keeper.go manages routed energy accounting through several key methods:

State Management and Queries

[Edit section]

[Copy link]

References: x/grid/keeper, x/grid/types

The Keeper struct in …/keeper.go is the central component for managing the Grid module's state. It provides methods for:

Parameter Management

[Edit section]

[Copy link]

References: x/grid/types, x/grid/keeper

• • •

The Grid module's parameters are managed through the Params struct defined in …/params.go. This struct contains a single field:

Client Interface

[Edit section]

[Copy link]

References: x/grid/client/cli

• • •

The Grid module's command-line interface is implemented in …/cli, providing query and transaction commands for interacting with grid routes.

WASM Integration

[Edit section]

[Copy link]

References: x/grid/wasm

• • •

The WASM integration for the grid module is implemented in …/interface.go. Two main components, Messenger and Querier, facilitate interaction between WebAssembly contracts and the grid module's functionality.

Decentralized Messaging

[Edit section]

[Copy link]

References: x/dmn

• • •

The Decentralized Messaging Network (DMN) module implements a system for executing smart contracts, referred to as "thoughts," in a decentralized manner. The core functionality is implemented in the …/dmn directory.

Thought Management

[Edit section]

[Copy link]

References: x/dmn/keeper, x/dmn/types

• • •

The Keeper struct in …/keeper.go is the central component for managing thoughts in the Decentralized Messaging Network (DMN). It provides methods for:

Message and Query Handling

[Edit section]

[Copy link]

References: x/dmn/keeper/msg_server.go, x/dmn/keeper/grpc_query.go

• • •

The msgServer struct in …/msg_server.go implements the types.MsgServer interface, handling various message types for thought management:

State Management and Migration

[Edit section]

[Copy link]

References: x/dmn/keeper, x/dmn/migrations

• • •

The Keeper struct in …/keeper.go manages the storage and retrieval of DMN-related data. It provides methods for:

WebAssembly Integration

[Edit section]

[Copy link]

References: x/dmn/wasm

• • •

The WebAssembly integration for the DMN module is implemented through two main structures: Messenger and Querier, both defined in …/interface.go.

Client Interface

[Edit section]

[Copy link]

References: x/dmn/client/cli

• • •

The command-line interface for the DMN module is implemented in …/query.go. The GetQueryCmd() function defines the main query command and adds several sub-commands:

Token Factory

[Edit section]

[Copy link]

References: x/tokenfactory

The Token Factory module enables permissionless creation and management of new tokens on the Cyber blockchain. It allows any account to create custom token denominations, mint and burn tokens, and manage token administration.

Token Creation and Management

[Edit section]

[Copy link]

References: x/tokenfactory/keeper

• • •

The Keeper struct in …/keeper.go is the primary implementation for token creation and management. It provides methods for creating new token denominations, minting, burning, and transferring tokens.

State Management and Queries

[Edit section]

[Copy link]

References: x/tokenfactory/keeper, x/tokenfactory/types

The Keeper struct in …/keeper.go manages token-related data storage and retrieval. It provides methods for accessing denomination-specific stores and creator-specific stores:

WebAssembly Integration

[Edit section]

[Copy link]

References: x/tokenfactory/wasm

• • •

The WebAssembly integration for the Token Factory module is implemented in the …/wasm directory. This integration allows smart contracts to interact with custom tokens through a set of message and query handlers.

Client Interface

[Edit section]

[Copy link]

References: x/tokenfactory/client/cli

• • •

The command-line interface for the token factory module is implemented in …/cli. It provides two main sets of commands:

Scheduled Execution

[Edit section]

[Copy link]

References: x/clock

• • •

The x/clock module enables smart contracts to be executed at regular intervals without the need for external bots. This functionality is implemented through the Keeper struct in …/keeper.go, which manages the module's state and core operations.

Contract Registration and Management

[Edit section]

[Copy link]

References: x/clock/keeper, x/clock/types

• • •

The Keeper struct in …/clock.go handles contract registration and management:

Execution Lifecycle

[Edit section]

[Copy link]

References: x/clock/keeper, x/clock/types

• • •

The execution lifecycle of clock contracts is handled at the start and end of each block through the BeginBlockSudoMessage and EndBlockSudoMessage constants defined in …/msgs.go. These messages are likely used to trigger the execution of registered clock contracts at specific points in the block processing cycle.

Jailing and Unjailing

[Edit section]

[Copy link]

References: x/clock/keeper, x/clock/types

• • •

The Keeper struct in …/clock.go manages jailing and unjailing of clock contracts:

CosmWasm Integration

[Edit section]

[Copy link]

References: x/clock/spec

• • •

The x/clock module provides CosmWasm integration for custom contract logic execution at the beginning and end of each block. Contracts must implement two Sudo messages:

Client Interface

[Edit section]

[Copy link]

References: x/clock/client/cli

• • •

The command-line interface for the clock module is implemented in the …/cli directory, providing users with query and transaction commands.