All pages
Powered by GitBook
1 of 18

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Staking

Learn

UOMI is an interoperable blockchain platform designed for the Polkadot and Ethereum ecosystems, supporting both Wasm and EVM smart contracts. This guide will help you quickly get up to speed with the core components of our platform.

Whether you're managing accounts, deploying smart contracts, you'll find all the essential information here to start building with UOMI. Dive into a new era of decentralized, AI-driven economic agents and explore the limitless possibilities of our innovative blockchain ecosystem!

Architecture

UOMI is a Layer 1 blockchain specialized for:

  • Executing all types of smart contracts

  • Providing a hybrid EVM + Wasm environment with interoperability

  • Seamlessly aggregating features and assets within its ecosystem

  • Running AI-driven economic agents

Understanding the Architecture

UOMI is built with Substrate, inheriting many of its powerful features, including its account system. At its core, UOMI leverages Substrate's technology stack while operating as an independent Layer 1 blockchain.

Core Components

At a high level, a UOMI node provides a layered environment with two main elements:

  1. An outer node that handles:

    • Network activity and peer discovery

    • Transaction request management

    • Consensus mechanisms

FRAME

FRAME (Framework for Runtime Aggregation of Modularized Entities) encompasses numerous modules and support libraries that simplify runtime development. In Substrate, these modules (called pallets) offer customizable business logic for different use cases and features that you might want to include in your runtime.

The framework provides pallets for common blockchain functionalities such as:

  • Staking

  • Consensus

  • Governance

  • Uomi-engine

Smart Contract Execution

UOMI provides a robust environment for smart contract execution through two main Virtual Machine (VM) implementations:

Ethereum Virtual Machine (EVM)

The Ethereum Virtual Machine (EVM) is a virtual computer with components that enable network participants to store data and agree on the state of that data. In UOMI, the core responsibilities of the EVM are implemented in the EVM pallet, which is responsible for executing Ethereum contract bytecode written in high-level languages like Solidity. UOMI EVM provides a fully Ethereum Virtual Machine compatible platform, which you can learn more about in the .

Substrate Virtual Machine for Wasm Contracts

UOMI includes the pallet-contracts module for WebAssembly (Wasm) smart contracts. This implementation supports the execution of Wasm-based smart contracts, providing an alternative to traditional EVM-based contracts. The Wasm environment offers several advantages, including:

  • Improved performance

  • Enhanced security features

  • Greater language flexibility

You can learn more about Wasm contract development in the .

Hybrid Approach

One of UOMI's key features is its hybrid approach to smart contract execution, allowing developers to choose between EVM and Wasm environments based on their specific needs. This flexibility enables:

  • Cross-contract interactions between EVM and Wasm

  • Optimization of different use cases

  • Broader ecosystem compatibility

RPC call responses

  • A runtime containing all the business logic for executing the state transition function of the blockchain. For more detailed information, see the Infrastructure and Security documentation.

  • IPFS
  • Other core activities

  • EVM chapter
    Wasm chapter

    Proof of stake

    Proof of Stake Consensus

    Overview

    UOMI blockchain implements a Proof of Stake (PoS) consensus mechanism utilizing BABE (Blind Assignment for Blockchain Extension) for block production. This consensus mechanism provides a secure, energy-efficient, and scalable foundation for the network.

    How It Works

    Stake-Based Validation

    • Validators are selected based on their UOMI token stake in the network

    • Higher stakes increase the probability of being chosen to produce blocks

    • Participants must meet minimum staking requirements to become validators

    BABE Block Production

    • Utilizes a slot-based block production system

    • Random validator selection for each slot using VRF (Verifiable Random Function)

    • Ensures predictable block times while maintaining security

    • Prevents manipulation through deterministic selection process

    Network Security

    Economic Security

    • Validators must stake tokens as collateral

    • Malicious behavior results in stake slashing

    • Economic incentives align validator interests with network health

    Benefits

    Efficiency

    • Significantly lower energy consumption compared to Proof of Work

    • Faster transaction finality

    • Reduced hardware requirements for participation

    Scalability

    • Supports high transaction throughput

    • Flexible validator set size

    • Efficient block production and validation process

    Decentralization

    • Encourages broad participation through staking

    • Democratic validator selection process

    • Reduced barriers to entry compared to mining

    Participation

    Becoming a Validator

    • Meet minimum stake requirements

    • Run validator node infrastructure

    • Maintain high uptime and performance

    • Follow network protocols and updates

    Staking as a Delegate

    • Participate in network security without running infrastructure

    • Delegate tokens to trusted validators

    • Earn proportional rewards from validation activities

    This consensus mechanism forms the foundation of UOMI's reliable and efficient blockchain infrastructure, enabling secure operation of AI models and agent interactions while maintaining network decentralization.

    Agents

    Agents are a core concept within the UOMI blockchain, representing autonomous entities that perform operations directly on the network. These agents are designed to leverage AI models to process data, execute computations, and interact with the blockchain ecosystem seamlessly. By integrating intelligent behavior with decentralized technology, agents become powerful tools capable of executing complex tasks efficiently.

    An agent’s role extends beyond computation. It has the capability to trigger transactions on the blockchain, enabling it to manage digital assets, interact with smart contracts, and coordinate activities within the decentralized environment. This level of autonomy allows agents to operate as independent entities, driving the execution of on-chain operations without requiring constant human intervention.

    Agents are tightly integrated into the UOMI infrastructure, functioning as the active participants that bridge AI capabilities with blockchain processes. They embody the intelligence of the network, processing inputs deterministically to ensure consistency across all nodes. By combining autonomy, intelligence, and decentralization, agents play a pivotal role in realizing UOMI’s vision of an AI-powered blockchain ecosystem.

    Security

    Security is a fundamental aspect of the UOMI platform, designed to safeguard the integrity and reliability of its decentralized ecosystem. This section introduces the core security principles and mechanisms that ensure the platform's resilience against potential threats.

    Through innovative technologies and protocols, UOMI addresses critical areas such as computation, data integrity, and Model updates Integrity, laying a solid foundation for a secure and trustworthy environment. Explore how these robust security measures work together to protect the platform and its participants.

    Models

    Overview

    AI Models are a fundamental component of the UOMI blockchain infrastructure, enabling the execution of complex operations that power the entire ecosystem. These models encompass a wide variety of architectures supporting different tasks, including:

    • Natural language processing

    • Image generation

    • Data analysis

    • Other AI-driven applications

    Integration and Features

    The direct integration of AI models into the chain's infrastructure provides a seamless platform for autonomous and intelligent computations. Key features include:

    • Open Source: The models used within the UOMI ecosystem are primarily open-source, ensuring transparency and adaptability.

    • Deterministic Execution: To maintain consistency across the network, models are managed deterministically, ensuring that every node:

      • Processes the same input data

      • Produces identical outputs

    Role in the Ecosystem

    AI models in UOMI are responsible for driving the intelligence behind agent interactions. Their role includes:

    • Processing input data

    • Generating meaningful outputs

    • Performing necessary computations for on-chain operations

    This tight integration between AI and blockchain creates a robust environment where autonomous agents can operate effectively, leveraging the power of advanced AI technologies across diverse use cases.

    Model Updates Integrity

    The Model Updates Integrity system ensures seamless and secure transitions between different AI model versions, maintaining the reliability of AI operations across the UOMI network. This process is critical for guaranteeing that AI agents run the appropriate model versions during updates, thereby safeguarding the consistency and accuracy of computations.

    Key Components

    TSS

    TSS, or Threshold Signature Scheme, is a cryptographic protocol that enables a group of nodes to collaboratively generate a shared signature. This scheme ensures that the resulting signature is valid only if a predefined number of nodes (known as the threshold) participate in the signing process.

    Key Concepts

    • Shared Public Key: The group of nodes collectively holds a shared public key.

    Infrastructure

    The UOMI infrastructure is the backbone of our platform, designed to support the seamless integration of AI-driven agents within a decentralized blockchain environment. This section provides an overview of the key components that power UOMI, enabling robust, secure, and efficient operations for AI models and agents.

    Explore how Nodes execute AI computations, delve into the various Models utilized—ranging from large language models (LLMs) to image generation frameworks—and discover how IPFS facilitates decentralized storage. Additionally, learn about the role of Agents in driving autonomous, intelligent economic interactions across the UOMI ecosystem.

    Key Participants

    The success of the UOMI platform relies on the contributions of several key participants:

  • Guaranteed Reliability: This approach ensures reliability and trust in the operations performed by agents.

  • On-Chain Storage

    Two key on-chain storages are utilized to manage model updates:

    1. AiModels:

      • Stores the list of valid AI models that agents can utilize.

      • Each model is identified by a unique UOMI_KEY and includes:

        • LOCAL_NAME: The actual model name installed on the nodes (e.g., llama-2.0.0).

        • USABLE_FROM_BLOCK_NUMBER: The block number from which the model becomes usable.

        • OLD_LOCAL_NAME: The previous version of the model used before the update.

    2. NodesVersions:

      • Contains the version details of each node.

      • Nodes periodically update this storage with their current version via the offchain_worker.

    Update Process

    During the update process, the system ensures that nodes and agents operate on consistent model versions:

    1. Version Identification:

      • At each block validation or after a set number of blocks, nodes identify the version used by the majority by reading from NodesVersions.

    2. Model Transition:

      • The active model for the majority is recorded in AiModels with the corresponding LOCAL_NAME, USABLE_FROM_BLOCK_NUMBER, and OLD_LOCAL_NAME.

      • This allows for a smooth transition where agents can continue using the older model until the majority has switched to the new version.

    Practical Example

    1. Block 15: A request is added to the chain.

    2. Block 16: The initial phase of computation begins, using model llama-2.0.0. The validator updates AiModels to switch to llama-2.1.0 from block 16, keeping llama-2.0.0 as the old model.

    3. Block 18: The computation continues using the older model for requests initiated before block 16.

    4. Block 20: New requests use the updated model llama-2.1.0, as the transition has been completed.

    Transition Handling

    Nodes must be capable of running both the old and new models during transitions to ensure uninterrupted service and accuracy. This dual compatibility is essential to maintain consistent operations throughout the network update process.

    Private Keys: Each node possesses its own private key, which is used in the signature generation process.

  • Threshold: A predefined number of nodes must participate in generating the signature. If the number of participating nodes meets or exceeds this threshold, the signature is considered valid.

  • How TSS Works

    1. Initialization:

      • A shared public key is established for the group.

      • Each node generates its private key, which remains secret.

    2. Signature Generation:

      • When a transaction or message requires signing, nodes collaborate by using their private keys.

      • The signature is only produced if the number of contributing nodes meets the threshold.

    3. Validation:

      • The generated signature can be verified using the shared public key.

      • This ensures that the signature is authentic and originates from the group.

    In the UOMI blockchain, TSS is integrated to provide agents with their own wallets. This allows agents to perform onchain transactions during their execution. The use of TSS enhances security and ensures that transactions are only authorized when a sufficient number of agents agree, thus maintaining the integrity of the process.

  • Developer: The individual responsible for developing and deploying AI-AGENTS, bringing intelligence and functionality to the platform.

  • Staker: Provides the hardware required to run the blockchain nodes, ensuring the stability and performance of the network.

  • Delegator/Nominator: Supplies tokens to support and secure Staker, helping to maintain the network’s integrity.

  • User: Uses the blockchain to run AI-AGENTS, benefiting from the decentralized, AI-powered services that UOMI enables.

  • Together, these participants contribute to building a robust, scalable, and interoperable ecosystem that pushes the boundaries of decentralized AI applications.

    Accounts

    Overview

    A Uomi Network account is composed of a private key and a public key. The public key, often referred to as the account address, is publicly accessible. The private key, on the other hand, is essential for accessing and managing the associated account. While anyone can send tokens to your public address, only the holder of the private key can access and control those tokens. Consequently, safeguarding your private key is of utmost importance.

    Uomi Network is compatible with two types of virtual machines, Wasm VM and EVM, and thus employs two different account formats.

    Substrate Accounts

    Uomi is developed using Substrate, a framework for building blockchains, and it utilizes Substrate accounts. In Substrate-based chains, the public key is used to derive one or more public addresses. Instead of directly using the public key, Substrate enables the generation of multiple addresses and address formats for an account. This means that a single public-private key pair can be used to derive various addresses for different Substrate chains.

    The private key is a cryptographically secure sequence of randomly generated numbers. For easier human readability, the private key can generate a random sequence of words known as a secret seed phrase or mnemonic.

    Substrate-based chains, including Uomi, use the ss58 address format. This format is a variant of Bitcoin's Base-58-check, with some modifications. Notably, ss58 includes an address type prefix to identify the address as belonging to a specific network.

    EVM Accounts

    On the Uomi EVM side, Ethereum-style addresses (H160 format) are supported within the Substrate-based chain. These addresses are 42 hex characters long. Each Ethereum-style address corresponds to a private key, which can be used to sign transactions on the Ethereum side of the chain. Additionally, these addresses are mapped to a storage slot within the Substrate Balance pallet, linking them to Substrate-style addresses (H256 format).

    Finney Testnet RPC Endpoints

    Overview

    The Finney testnet provides robust infrastructure through two dedicated RPC (Remote Procedure Call) endpoints. These endpoints serve as archive nodes, offering developers and users comprehensive access to the network's historical data and current state.

    Available Endpoints

    Smart Contracts

    Overview

    Developers can create and deploy smart contracts on Uomi Network using various programming languages, including Solidity, compatible with Ethereum smart contracts, and ink!, a Rust-based smart contract language for the Polkadot ecosystem. This compatibility ensures a seamless transition for developers from other blockchain ecosystems, fostering interoperability and encouraging the adoption of the Uomi Network.

    OPOC

    OPOC, or Optimistic Proof of Computation, is a mechanism designed to ensure the integrity and security of computational operations that occur outside the blockchain (offchain). This approach leverages both offchain and onchain elements to provide a tamper-proof system where certain operations are validated by multiple nodes to achieve consensus.

    Key Concepts

    • Offchain Operations: These are processes that occur outside the blockchain environment. While they offer scalability and speed, they are susceptible to tampering by malicious nodes.

    Onchain Operations: These are processes executed directly on the blockchain, ensuring tamper-proof and immutable records.

    How OPOC Works

    1. User Interaction

      • A user initiates a request by calling a function in a Solidity contract, providing necessary parameters such as NFT_ID, INPUT_DATA, and INPUT_FILE_CID.

    2. Request Initialization

      • The contract generates a unique REQUEST_ID and invokes a specific function from a precompiled contract, passing critical parameters like REQUEST_ID and the other user parameters.

    3. Data Verification

      • The system checks the input data and retrieves associated NFT information.

      • It stores the request details in the Inputs storage and logs an event indicating the request has been accepted.

    4. Consensus Levels

      • Depending on the NFT specifications, the system start the assignment of the execution to a random node.

    Security Mechanisms

    During Block Validation:

    • Wasm and IPFS File Verification:

      • The system ensures the availability and validity of files required for the execution (the wasm of the AI Agent and the input file).

      • It checks the status of these files through the IPFS pallet, verifying their usability and expiration.

    • Node Assignment and Execution:

      • Nodes are assigned to process requests based on current load and execution requirements.

      • The system monitors the execution and consensus among nodes, escalating to higher levels of OPOC if discrepancies arise.

    Consensus Verification:

    • Level 0: A single node executes the request.

    • Level 1: Multiple nodes are involved to achieve a higher consensus.

    • Level 2: Additional nodes are engaged if discrepancies are found, ensuring a majority consensus.

    Request Completion and Rewards

    • The final result is stored in the Outputs storage.

    • Nodes are rewarded based on their participation and accuracy, with penalties for nodes in the OpocBlacklist or those with timeouts and errors.

    Offchain Worker Execution

    • Nodes continually monitor and execute assigned tasks, ensuring timely processing and consensus.

    • Results are stored, and timeouts are managed to maintain system efficiency.

    WebAssembly smart contracts​

    Uomi runtimes are based on Substrate and incorporate pallet-contracts, a sandboxed environment used to deploy and execute WebAssembly (Wasm) smart contracts. Any language that compiles to Wasm can be deployed and run on this Wasm Virtual Machine, provided the code is compatible with the pallet-contracts API.

    To avoid unnecessary complexity and writing boilerplate code, the most appropriate method of building involves the use of an eDSL specifically targeting pallet-contracts, such as ink! (based on Rust) or ask! (based on AssemblyScript), among others as the ecosystem grows.

    After compilation, a Wasm blob can be deployed and stored on-chain.

    Ethereum Virtual Machine smart contracts​

    The Uomi EVM implementation is based on the Substrate Pallet-EVM, providing a full Rust-based EVM implementation. Smart contracts on Uomi EVM can be implemented using Solidity, Vyper, or any other language capable of compiling smart contracts to EVM-compatible bytecode. Pallet-EVM aims to provide a low-friction and secure environment for the development, testing, and execution of smart contracts that is compatible with the existing Ethereum developer toolchain.

    ​
    Endpoint
    Type
    Status

    https://finney.uomi.ai

    Primary Archive Node

    Active

    https://finney2.uomi.ai

    Secondary Archive Node

    Active

    Features

    Archive Node Functionality

    • Complete historical state access

    • Full block history from genesis

    • State queries at any block height

    • Transaction receipt retrieval for all historical transactions

    Supported Methods

    Both endpoints support the standard JSON-RPC methods including:

    • Ethereum JSON-RPC API (eth_*)

    • Net API (net_*)

    • Web3 API (web3_*)

    • Debug API (debug_*)

    Usage Examples

    Connecting with Web3.js

    Connecting with Ethers.js

    Best Practices

    1. Load Balancing

      • Alternate between both endpoints for optimal performance

      • Implement retry logic with endpoint switching

    2. Rate Limiting

      • Respect rate limits to ensure fair usage

      • Implement appropriate caching strategies

    3. Error Handling

      • Always implement proper error handling

      • Monitor response times and implement timeouts

    Support

    For technical issues or questions:

    • Join our Discord community

    • Open a GitHub issue

    • Contact our developer support team

    Network Parameters

    • Chain ID: 4386

    • Block Time: 3s

    Monitoring

    Both endpoints are continuously monitored for:

    • Uptime

    • Response time

    • Sync status

    • Block height consistency

    const Web3 = require('web3');
    const web3 = new Web3('https://finney.uomi.ai');
    const { ethers } = require('ethers');
    const provider = new ethers.providers.JsonRpcProvider('https://finney.uomi.ai');

    IPFS Integrity

    Overview

    The IPFS pallet provides decentralized storage capabilities to the blockchain through integration with the InterPlanetary File System (IPFS). It manages pinning, unpinning, and retrieval of files while ensuring data persistence and availability through validator consensus.

    Key Features

    Pinning System

    • Persistent Pins: Files that remain pinned indefinitely

    • Temporary Pins: Files with an expiration block number

    • Validator-based Consensus: Content becomes available when pinned by majority of validators

    Pin Types

    Agent Pins

    • Permanent pins associated with NFT IDs

    • Used for storing agent-related data

    • Can be updated with new CIDs

    Temporary Pins

    • Time-limited storage

    • Minimum duration of 28,800 blocks (approximately 1 day)

    • Automatically unpinned after expiration

    Core Mechanisms

    Consensus Process

    1. Validator Pinning:

      • Validators run offchain workers to process pin requests

      • Each validator maintains its own IPFS node

      • Files become "usable" when pinned by majority (50% + 1) of validators

    Pin Lifecycle

    1. Pin Request:

      • User submits CID for pinning

      • System records pin request with expiration time

    2. Processing:

    Storage Management

    Key Storage Items

    Status Tracking

    • ExpirationBlockNumber: When the pin expires (0 for permanent pins)

    • UsableFromBlockNumber: When content becomes available (post-majority pinning)

    Operations

    Pin File

    • Requires minimum duration (28,800 blocks)

    • Creates temporary pin with expiration

    • Triggers validator pinning process

    Pin Agent

    • Creates permanent pin associated with NFT

    • Updates existing pins if necessary

    • Maintains single CID per NFT ID

    Get File

    • Checks pin status and expiration

    • Verifies content is "usable"

    • Returns file content if available

    Block Processing

    Inherent Data

    • Each block processes pin operations

    • Updates usable content status

    • Removes expired pins

    • Updates pin status based on validator consensus

    Offchain Worker

    • Runs after each block

    • Processes pending pin requests

    • Updates local IPFS node

    • Submits pin status updates

    Fees

    Transaction Fees in UOMI

    Overview

    UOMI implements a dual fee system to support both native Substrate transactions and Ethereum-compatible operations. This hybrid approach ensures efficient resource allocation and network stability while maintaining compatibility with both ecosystems.

    IPFS

    IPFS (InterPlanetary File System) serves as the decentralized file system for the UOMI blockchain. It is an integral component of the platform, enabling seamless storage and retrieval of files required for the execution of AI operations.

    • Decentralized Storage: IPFS ensures that files are stored in a distributed network, eliminating single points of failure and improving data availability.

    • Efficient File Access: AI agents require access to various files, including models and data inputs, to perform their computations. IPFS provides a robust mechanism to store and retrieve these files securely.

    • Integration with UOMI: The UOMI blockchain integrates IPFS to handle files referenced by smart contracts and agents, ensuring that essential data is accessible and verifiable throughout the network.

    IPFS acts as the backbone for managing the data lifecycle of AI models and inputs used by agents. By leveraging IPFS, the UOMI blockchain ensures seamless access to files for computations while maintaining their immutability to preserve data integrity. Additionally, the distributed nature of IPFS optimizes performance by efficiently spreading data across the network.

    Offchain workers detect new pin requests

  • Validators attempt to pin the content

  • System tracks pinning status per validator

  • Activation:

    • Content becomes "usable" once majority threshold is reached

    • System updates UsableFromBlockNumber to avoid using the file on requests received on the chain before the availability of the file

  • Expiration:

    • System tracks expiration through ExpirationBlockNumber

    • Automatic cleanup of expired pins

    • Validators remove expired content

  • NodesPins: (CID, AccountId) => bool
    AgentsPins: NFTId => CID
    CidsStatus: CID => (ExpirationBlockNumber, UsableFromBlockNumber)
    pin_file(origin, cid: CID, duration: BlockNumber)
    pin_agent(origin, cid: CID, nft_id: NFTId)
    get_file(cid: CID) => Result<Vec<u8>>

    Native Transaction Fees

    Fee Components

    The native fee calculation follows the standard Substrate model:

    Where:

    • Length Fee: Proportional to transaction byte size

    • Base Fee: Fixed cost per transaction

    • Weight Fee: Computational resources cost

    • Adjustment: Dynamic scaling factor based on network congestion

    • Tip: Optional priority payment

    Implementation Details

    The fee adjustment mechanism ensures network stability by:

    • Scaling fees based on block space utilization

    • Implementing surge pricing during high congestion

    • Maintaining predictable base costs for standard operations

    Ethereum-Compatible Fees

    Dynamic Fee Model

    Based on the provided pallet code, UOMI implements EIP-1559 style fee calculation:

    Key Features

    1. Base Fee Adjustment:

    1. Elasticity Mechanism:

    • Adjusts base fee according to block utilization

    • Implements upper and lower bounds

    • Maintains target block utilization

    Technical Implementation

    The base fee adjusts according to network conditions:

    Fee Market Dynamics

    Network Congestion Response

    • Fees automatically adjust based on block fullness

    • Target block utilization maintained through elasticity

    • Smooth fee transitions prevent sudden spikes

    Economic Incentives

    1. For Users:

      • Predictable base fees

      • Optional priority fees for faster inclusion

      • Protection against fee spikes

    2. For Validators:

      • Stable reward structure

      • Additional incentives during high demand

      • Protection against spam attacks

    Nodes

    Overview

    Nodes are fundamental components of the UOMI ecosystem, serving multiple critical functions including blockchain maintenance, AI computation execution, and system-wide service integration. Each node type is optimized for specific roles within the network architecture.

    Fee = Length Fee + Base Fee + (Weight Fee × Adjustment) + Tip
    Fee = Gas Used × (Base Fee Per Gas + Priority Fee Per Gas)
    let weight_used = Permill::from_rational(
        weight.total().ref_time(), 
        max_weight.ref_time()
    ).clamp(lower, upper);
    if usage > target {
        // Increase base fee when above target utilization
        let coef = Permill::from_parts(
            (usage.deconstruct() - target.deconstruct()) * 2u32
        );
    } else if usage < target {
        // Decrease base fee when below target utilization
        let coef = Permill::from_parts(
            (target.deconstruct() - usage.deconstruct()) * 2u32
        );
    }
    Node Types

    Full Node

    • Core Functions:

      • Maintains complete blockchain copy

      • Performs comprehensive transaction verification

      • Facilitates network transaction propagation

      • Supports network stability and decentralization

    Archive Node

    • Key Features:

      • Stores complete historical state

      • Enables historical block queries

      • Supports data analytics and explorers

      • Maintains network transparency

    Validator Node

    • Capabilities:

      • Operates full node functionality

      • Participates in consensus

      • Implements intelligent state pruning

      • Optimizes storage efficiency

      • Executes Agents

    MainNet Service Architecture

    Core Components

    1. Uomi-node Service

      • Substrate-based blockchain runtime

      • Transaction processing engine

      • State management system

      • Network communication protocol

    2. AI Service

      • Dedicated computation engine

      • Model execution environment

      • Agent interaction interface

    Integration Layer

    The AI-AGENT system interfaces with node services through:

    • Secure proxy functions

    • Protected communication channels

    • Resource allocation controls

    Technical Specifications

    Hardware Requirements

    Node Type
    CPU
    RAM
    Storage
    Network
    GPU

    Full

    4+ cores

    8GB+

    100GB+

    1 Gbps

    -

    Archive

    8+ cores

    16GB+

    Network Parameters

    • Default P2P port: 30333

    • Default RPC port: 9944

    • Default WS port: 9944

    • Default Prometheus port: 9615

    Security Considerations

    1. Network Security

      • Firewall configuration

      • Port access control

      • DDoS protection

      • Secure communication protocols

    2. System Security

      • Regular updates

      • Access control

      • Resource isolation

    3. Data Security

      • State encryption

      • Secure key management

      • Backup procedures

    Best Practices

    1. Deployment

      • Use dedicated hardware

      • Implement monitoring

      • Regular maintenance

      • Performance optimization

    2. Operation

      • Regular backups

      • Update management

      • Resource monitoring

    3. Maintenance

      • Regular updates

      • Security patches

      • Performance monitoring

    This comprehensive guide provides the foundation for understanding and implementing UOMI network nodes. For specific setup instructions, refer to our node deployment documentation.

    Resource management system
    Monitoring and alerting
    Recovery protocols
    Performance tuning
    Capacity planning

    500GB+

    1 Gbps

    -

    Validator

    8+ cores

    16GB+

    100GB+

    1 Gbps

    2 x RTX 4090+