Socon Hub

Hubs play a central role in the SoCon ecosystem, forming a distributed network of servers designed to store and validate SoCon data. Here's an overview of the key concepts related to SoCon Hubs:

What are Hubs?

Hubs are servers that run software to become part of the SoCon network. They store and validate both onchain Socon data from Ethereum and offchain Socon data from other Hubs. Each Hub maintains a copy of all Socon data, making it accessible through an API. Hubs serve as the gateway for reading and writing data to SoCon, and anyone building a SoCon app needs to interact with them.

Hub Design

1. Syncing Data: A Hub begins by syncing data from Socon contracts on the Optimism blockchain, becoming aware of every user's account and their associated keys.

2. Lifecycle of a SoCon Message:

   • Alice creates a new message (e.g., "Hello World!").
   • Alice or her app signs the message with an account key.
   • Alice or her app uploads the message to a Hub.
   • The Hub validates the message's signature and ensures it adheres to the specified message type requirements.

Validation and Storage

• Validation: Messages are validated by checking for a valid signature from the account key and adherence to message type requirements, as outlined in the protocol spec.

• Storage: Messages are checked for conflicts before being stored. Conflicts may arise due to various reasons, such as an existing copy of the message or rent payment limitations. Conflicts are resolved deterministically and asynchronously using Conflict-Free Replicated Data Types (CRDTs).

Replication

Hubs synchronize using a two-phase process:

• Gossip: Hubs gossip messages to their peers immediately upon receiving and storing them, leveraging libp2p's gossipsub protocol.
• Diff Sync: Periodically, Hubs perform a diff sync with a random peer to identify dropped messages efficiently. The diff sync process compares merkle tries of message hashes.

Consistency

Hubs maintain strong eventual consistency. Even if a Hub is temporarily disconnected, it can safely recover when back online. However, messages may arrive out of order, a trade-off for ensuring robustness.

Peer Scoring

Hubs monitor the behavior of their peers and assign scores based on factors like message acceptance, falling behind, or excessive gossiping. Peers with unfavorable scores may be ignored by their peers.

Explore the detailed guide on setting up and running a Hub.

Architecture

A Hub functions as responsible for receiving data from clients, other hubs, and Socon contracts. It comprises three primary components:

1. Storage Engine: This component validates incoming messages' signatures and schemas. It then merges these messages into a coherent state and stores this state persistently on disk.

2. P2P Engine: Responsible for engaging in gossip with other hubs to exchange the latest messages on the network.

3. Sync Engine: Facilitates synchronization between two hubs in cases where gossip messages fail to deliver.

Storage Engine:

The Storage Engine verifies the signature and schema integrity of each received message. It determines the valid signers for a user by monitoring Socon contract events and employs this information to authenticate each message.

Validated messages are amalgamated into a Set, a data structure representing the user's current data state on the network. This Set utilizes CRDTs (Conflict-Free Replicated Data Types) to ensure that merging messages remains commutative, associative, and idempotent. Consequently, regardless of the order in which two hubs receive a set of messages, they will consistently converge to the same state.

Upon a successful state transition, an event is dispatched to both the sync and P2P engines. The updated state is persisted to disk using RocksDB, ensuring that the Hub can restore its state if it crashes. Additionally, the state can be recovered from an external store, streamlining the process of launching new hubs.

Sync Engine:

The Sync Engine employs a Merkle Patricia Trie to monitor the known set of messages. During communication between two hubs, this engine compares both tries to retrieve any new messages.

Upon the Storage Engine's persistence of a message, a unique timestamp hash key is generated by combining the message's timestamp and hash. These keys ensure that the trie maintains chronological order from left to right. As messages generally arrive chronologically, most insertions occur on the right-hand side of the tree, expediting the process of tree diffing.