DOCSEARCHbyAlgolia
Submit Docs

gonka-ai/gonka

repository·main·Indexed 20 days ago

https://github.com/gonka-ai/gonka

A repository featuring the Genesis Transfer module for secure account ownership transfer and a decentralized-api with a broker for managing distributed ML node lifecycles. It includes an OnNewBlockDispatcher for block-driven reconciliation and a devshard E2E testing framework using Docker-backed simulations of mock chains and participant hosts.

Tokens
474.4K
Snippets
898
Records
1.9K
Agent score
70%

What's inside gonka

  1. Overview of v0.2.5 Changes

    main

    The v0.2.5 upgrade introduces several major features and fixes:

    New Features

    • Native Bridge: Primitives and contracts for Ethereum blockchain integration.
    • Random Confirmation PoC: A new layer to verify that inference-serving nodes maintain computational capacity throughout an epoch.
    • SPRT (Continuous Inactive Participant Exclusion): A mechanism to continuously exclude inactive participants from the EpochGroup.
    • Improved PoC Scheduling: For nodes with POC_SLOT=true, the system now allocates participants based on model weight percentages using a random subset of previous epoch participants, rather than a simple 50% weight per participant.

    Key Fixes

    • BLS Signatures: Fixed bugs in Group Public Key generation and improved partial signature aggregation to align with Ethereum pre-compiles.
    • Account Transfers: Fixed a bug where full balances were used for transfers; now, locked coins and spendable amounts are transferred separately.
    • MLNode Reliability: Improved status checks (assigning FAILED if unresponsive) and added a retry mechanism for hosts with multiple MLNodes per model.
    • Data Integrity: Fixed GetMembers pagination and corrected reward distribution logic to exclude invalid participants.

  2. Overview of Training Removal in v0.2.12

    main

    As of version v0.2.12, the Gonka project has removed the training subsystem from its product direction. This subsystem previously spanned inference-chain and decentralized-api, involving chain messages, queries, off-chain coordination, broker execution flows, and ML-node integrations.

    Key impacts for developers:

    • Hard Removal: Training-related features are being deleted, not deprecated. This includes runtime behavior, public endpoints, chain RPCs, proto definitions, generated artifacts, and tests.
    • No Backward Compatibility: Old training routes, RPCs, and generated types will no longer be available. Clients relying on training-specific surfaces must migrate to the new product surface.

  3. Overview of the Gonka Network Roadmap

    main

    Gonka is a decentralized AI inference network designed to connect distributed GPU resources with AI application developers. The network aims to provide scalable inference on open models without centralized cloud dependency, while allowing hosts to earn rewards for contributing GPU capacity.

    The roadmap is structured around three strategic horizons:

    1. Horizon 1 (Lead DeAI): Focuses on becoming the leading decentralized AI compute network with high H100-equivalent capacity, multi-model/multi-modality support, and reliable inference usage.
    2. Horizon 2 (Compete with neoclouds): Aims to compete with providers like Nebius or CoreWeave by scaling to 100K–250K H100-equivalent capacity and providing stable APIs and enterprise inference paths.
    3. North Star (Frontier-scale decentralized compute): The long-term goal of providing 1M+ H100-equivalent capacity with trusted execution, verification, and the ability to train/fine-tune models on a distributed network.

  4. Overview of the devshard testenv v2 plan

    main

    The devshard testenv v2 is a proposed local protocol laboratory using Docker Compose and Go-controlled integration tests. It aims to rewrite the test environment topology to match production architecture, specifically using versiond → devshardd, versiond-router, and the current devshardctl gateway.

    Key architectural shifts from previous versions:

    • Mock-chain: Instead of a custom-proto gRPC stub, the production devshardd is hard-wired to the real Cosmos gRPC + CometBFT RPC node surface. The plan uses a 'faithful fake mock-chain' (D1).
    • Long-poll Server: The server is coupled to dapi internals; extraction must be interface-shaped rather than a direct copy.
    • Mockdapi: The old mockdapi was an in-process client noop. The new version includes a params/epoch oracle.
    • Chain Query Transport: The plan aims to unify all consumers (including mock-dapi) on the common/chain transport to ensure consistent fetching across edge-api, devshardd bridge, devshardd-params, and the gateway.

  5. Overview of the Multi Model and GPU Uptime System

    main

    The Multi Model and GPU Uptime System is an implementation for the inference network designed to support multiple models and optimize GPU uptime. It enhances model governance by introducing per-MLNode tracking, throughput-based economic incentives, and intelligent GPU allocation during Proof-of-Compute (PoC) periods.

    Key Concepts

    • PoC Period: The duration spanning from the Start of the PoC Stage through the Set New Validators stage (the complete epoch transition).
    • Nonce: Individual proof-of-work units that are recorded and validated during the PoC period.
    • MLNode: An individual ML compute node managed by a participant controller.

  6. Overview of the Ethereum Bridge Smart Contract

    main
    The Ethereum Bridge Smart Contract serves as the bridge endpoint for cross-chain token transfers. It is designed to facilitate secure, decentralized withdrawal validation using BLS threshold signatures (natively supported by Ethereum). The system balances decentralization with safety by incorporating admin failsafe mechanisms for emergency scenarios.

  7. Overview of the Transfer Restrictions Module (x/restrictions)

    main
    The x/restrictions module provides temporary restrictions on user-to-user token transfers during blockchain bootstrap periods. It is designed to be reusable across any Cosmos SDK chain. It allows essential network operations (like gas fees and module transfers) to continue while blocking direct user-to-user transfers until a specified block height is reached. Once the restriction_end_block is reached, the module automatically unregisters itself to eliminate performance overhead.

  8. Overview of Early Network Protection through Power Distribution Limits

    main

    The Early Network Protection system implements configurable power distribution limits designed for the bootstrap period of the Gonka network. Its primary purpose is to prevent centralization attacks and ensure network stability before the network reaches full maturity.

    In the Gonka network, the Staking Module Power determines critical consensus behaviors, including:

    • Block production
    • Governance voting
    • Validator selection

    This protection system uses genesis-level constraints that automatically phase out as the network matures, mitigating risks associated with low total stake and small participant counts.

  9. What is Testermint?

    main

    Testermint is a Kotlin-based end-to-end integration testing framework designed for the blockchain and decentralized API (DAPI) components. It simulates realistic production environments by orchestrating Docker containers for blockchain nodes and API binaries, alongside WireMock instances to simulate external systems like customers or third-party APIs.

    It is used to test complex interactions that unit tests cannot capture, such as:

    • Multi-node consensus and communication.
    • Epoch transitions.
    • Responses (or failures) from external systems.

  10. Overview of Tokenomics V2 Proposals

    main
    The proposals/tokenomics-v2/ directory contains documentation for the second version of the project's economic model. These proposals aim to improve network stability, security, and economic incentives through four primary mechanisms: dynamic pricing, fixed reward systems, vesting schedules, and collateralized participation.

  11. Overview of Transfer Restrictions V1 Proposal

    main

    The Transfer Restrictions V1 proposal implements native coin transfer restrictions during the network's initial bootstrapping phase to prevent speculative trading. These restrictions are active for the first 1,555,000 blocks (approximately 90 days from genesis).

    Key Operational Details

    • Automatic Expiration: Restrictions are automatically lifted after block height 1,555,000 without requiring governance action.
    • Exemptions: Essential network operations are exempt from these restrictions, specifically:
      • Gas fee payments
      • Inference fee payments
    • Governance Override: An emergency mechanism exists to allow governance to override restrictions for critical operations.

  12. Use the versiond Version Manager

    main

    The versiond binary is a lightweight version manager that manages child processes and provides a built-in reverse proxy. It polls the decentralized API to ensure the correct binary versions are running.

    Core Responsibilities:

    • Polling: Checks GET /versions (default every 30s) to determine the desired state.
    • Lifecycle Management: Downloads, verifies (via sha256), and runs binaries. It performs zero-downtime swaps by downloading new binaries before stopping old processes.
    • Reverse Proxy: Listens on :8080 and routes traffic to child processes based on path prefixes.
    • Signal Forwarding: Forwards signals (like SIGTERM) to child processes for graceful shutdown.

    Directory Layout:

    • /opt/versiond/bin/{name}/devshard: Extracted binaries.
    • /opt/versiond/data/{name}/: Version-specific data directories passed via --data-dir to the child.