3.3 SIA Protocol

The SIA Protocol adopts Chain-key Cryptography to generate and manage keys for digital signatures, thereby ensuring secure communication and privacy protection between blockchain subnets and even with external public chains. A crucial component of Chain-key Cryptography is the Threshold Signature Scheme (TSS), whose core advantage is to distribute private keys across various nodes in the subnet, thereby preventing private key theft. When any node receives content transmitted from other nodes via the SIA Protocol, it only needs to simply verify the attached signature, without synchronizing information from all nodes in the network.

Utilizing Chain-key Signature technology, the SIA Protocol can easily and conveniently communicate trustfully with other public chains, such as Ethereum and Solana, without the need for cross-chain bridges or other third-party off-chain signature machines. Blockchain networks built on the SIA Protocol can conduct transactions with Ethereum, Solana, and other public chains, such as receiving, holding, and sending tokens like ETH and SOL.

Based on the SIA Protocol, nodes can quickly join, register, participate in storage and computing, and exit.

Protocol and Algorithm: Adopts the Zookeeper Atomic Broadcast (ZAB) protocol, leveraging its atomic broadcast protocol characteristics to ensure consistency of distributed transactions;
SIA Protocol adopts the Proof of Stake (PoS) consensus algorithm, where nodes compete for block production rights through staking, thereby ensuring network security and consistency. This consensus algorithm makes it difficult for malicious nodes to tamper with blockchain or engage in fraudulent activities. To avoid the “rich get richer” phenomenon, while adopting PoS, a random factor is introduced, where the system, according to certain rules, introduces a certain randomness to select validators, allowing nodes with smaller holdings to also participate in validation;
SIA Blockchain replicates and creates new nodes based on the SIA Protocol. Through the peer-to-peer communication module in the SIA Protocol, nodes can send and receive messages from each other, including task requests triggered by smart contracts. The consensus mechanism module in the SIA Protocol allows nodes to agree on the messages to be processed and their order. The purpose of the consensus protocol is to output the same ordered block of messages on each node of the subnet in a given round, so that each node can perform the same state transitions when deterministically executing these messages;

Each node has message sending and receiving and message caching modules. By placing received messages into a queue, asynchronous message routing and execution, as well as result aggregation and reply, are performed based on execution rules.

3.3.1 Node Lifecycle Management and Consensus-Based State Synchronization Protocol

A distributed node dynamic management solution based on the Token coordination mechanism, which achieves reliable node joining/exiting through Token transmission and confirmation mechanism, while maintaining cluster consistency.

Core functions of Token:

Identity credential: Token serves as proof of node legitimacy, containing metadata such as node ID and term information, used to verify node status;
Coordination signal: The Token transmission path forms a logical “ring,” ensuring all nodes reach consensus on the cluster topology;
Fault detection: Token timeout (e.g., not transmitted within the agreed time) triggers node failure determination.

Authority of the smallest ID node

Election priority: The node with the smallest ID is granted coordination rights, similar to the Leader election logic in the Raft protocol;
Conflict resolution: In a distributed network, ID order can prevent split-brain issues caused by multiple nodes simultaneously claiming to be the primary node.

Two-phase commit mechanism

Broadcast phase: Nodes exchange topology information to build a complete network view;
Commit phase: Final consistency confirmation is achieved through Token transmission.

When a new node joins, it initiates a broadcast JOIN_REQ, carrying its own ID and metadata. Other nodes receiving this information will start broadcasting their INFO_ACK, containing their own ID and topology version. When all nodes exchange information through multiple broadcasts until each node maintains a complete topology table (including IDs and addresses of all live nodes), the node with the smallest ID will generate a Token (including a new term number, topology version number), broadcast TOKEN_COMMIT, and all nodes will confirm it. Other nodes verify the legality of the Token (e.g., increasing term number, consistent topology version) and reply with ACK after confirmation. After receiving the majority of ACKs, the new node is added to the valid list, the cluster state is updated, and the new node completes data synchronization (e.g., through Raft log replication), officially joining the network and starting to process requests.

When a node exits, node failure leads to a broken “token ring” (mechanism or protocol related to Token), and other nodes mark the failed node as SUSPECT, triggering a Token timeout. At this point, the smallest ID node regenerates the Token, broadcasts TOKEN_RECOVER, and live nodes verify the Token, update the topology table, and remove the failed node. The smallest ID node initiates data recovery, and the cluster returns to normal.

This technology, through the Token mechanism and the coordination of the smallest ID node, achieves dynamic node management in distributed systems, ensuring the normal operation and security of the blockchain network. The mechanism design integrates consensus algorithms (such as Raft), information propagation (such as Gossip), and fault tolerance mechanisms, applicable to scenarios requiring high consistency and availability. This technology has the advantages of strong consistency, low-latency joining, and self-healing capabilities:

Strong consistency: Ensures global consistency of cluster state through Token transmission and majority confirmation;
Low-latency joining: Information broadcast and Token submission are separated to avoid synchronous blocking;
Self-healing capability: Automatically detects node failures and triggers recovery processes.

3.3.2 Service Governance and Execution Coordination Protocol

SIA adopts a distributed multi-Agent service mechanism (Agents on different nodes work collaboratively, jointly undertaking service responsibilities) to achieve service registration, discovery, execution, and settlement.

Service Registration Protocol: When an Agent starts, it completes identity verification through Token pre-authentication and automatically registers service instances (e.g., service name, address, port) to the local service registry. Through multi-level verification mechanisms, false service registrations are eliminated.

Local verification: Checks service port occupancy, protocol compatibility;
Cluster verification: Submits RegisterService command via Raft, Leader verifies Token validity to prevent illegal node registration.

Health Check Protocol: Adopts a dynamic monitoring mechanism to perform health checks on registered services. Node failure automatically causes all its service instances to enter the SUSPECT state. The check interval is dynamically adjusted based on service load (longer for low load, shorter for high load) to ensure service availability;

Node-level health: Based on Token transmission status, if the next hop Token is not received, the node is marked as unavailable, automatically removing services associated with the failed node;
Service-level health: Spreads degradation status through Gossip protocol, i.e., mixed detection strategies (TCP/HTTP/custom scripts), detection failure triggers service degradation marking;
Business-level health: Collects business metrics (e.g., QPS/error rate), exceeding thresholds triggers service circuit breaking, combined with settlement protocol to freeze billing for abnormal services.

Service Discovery: Service consumers query SIA to obtain a list of available services. Through context-aware routing, based on the node role in the Token, such as LEADER/WORKER, authoritative nodes are prioritized; topology-aware load balancing, combined with node load data propagated by Gossip, dynamically adjusts request distribution weights. SIA provides multiple efficient query mechanisms that can quickly return service information that meets the conditions;

Precise query: Client directly accesses the Leader node, quickly locating service instances through B+ tree index (O(logN) complexity);
Fuzzy query: Uses Bloom filter to pre-filter nodes, combines Gossip protocol to aggregate results;
Subscription push: Client registers Watcher, service changes are pushed in real-time through Pub/Sub model (supports WebSocket/MQTT).

Service Execution Protocol: Ensures distributed transaction integrity, batch execution, i.e., merging multiple microservice calls into a single network request, and adopting asynchronous pipelines for non-critical path operations (e.g., logging).

Preparation phase: Coordinator (smallest ID Agent) collects pre-execution confirmations from participants (service nodes);
Commit phase: Broadcast EXECUTE TOKEN, each node executes business logic and returns a result summary;

Ensures result consistency through vector clock alignment and compensation transaction mechanisms;

Settlement Protocol

Real-time metering: Agent built-in Prometheus Exporter collects fine-grained resource metrics;
Distributed ledger: Submits billing events via Raft to ensure strong consistency of billing data;
Smart contract liquidation: Automatic deduction based on smart contracts, supports multi-chain payments (ETH/SOL/BSC);
Dispute arbitration: Uses PBFT algorithm to achieve Byzantine fault-tolerant level settlement dispute resolution.