Infrastructure

Openmesh Core is a crucial piece of software that is responsible for maintaining consensus among different validator nodes in the network. Openmesh-core utilizes the Tendermint consensus protocol, which is a Byzantine Fault Tolerant (BFT) consensus algorithm, to ensure secure and reliable blockchain operations. The specific implementation of Tendermint used by Openmesh-core is CometBFT, written in Go.

Responsibilities of Core

• Block Proposal:

  • Selection of Proposer: The core is responsible for selecting the proposer (validator) for each round in a fair manner, typically using a round-robin or weighted round-robin approach based on stake.

  • Block Creation: The selected proposer creates a new block with valid transactions and broadcasts it to all validators.

• Voting Process:

  • Pre-vote Collection: The core collects pre-votes from all validators for the proposed block. Each validator votes based on the validity of the block.

  • Pre-commit Collection: After pre-votes are collected, the core collects pre-commits from validators who have received sufficient pre-votes.

  • Final Commit: The core ensures that if a block receives more than two-thirds of the pre-commits, it is added to the blockchain.

• Transaction Validation:

  • Transaction Verification: The core verifies the validity of transactions included in the proposed block. This includes checking digital signatures, ensuring no double-spending, and validating any other protocol-specific rules.

  • State Transition: The core applies valid transactions to the current state, producing the new state that will be agreed upon.

• Network Communication:

  • Message Broadcasting: The core handles the broadcasting of proposal, pre-vote, pre-commit, and commit messages to all validators in the network.

  • Synchronizing Nodes: The core ensures that all nodes stay synchronized, resolving any discrepancies in state or blockchain history.

• Fault Tolerance and Security:

  • Byzantine Fault Tolerance: The core implements mechanisms to handle up to one-third of nodes being malicious or faulty, maintaining consensus despite these issues.

  • Punishment and Slashing: The core is responsible for detecting and punishing misbehavior, such as double-signing or other forms of protocol violations, by slashing the stake of malicious validators.

• Consensus Finality:

  • Immediate Finality: The core ensures that once a block is committed, it is final and cannot be reverted, providing security and confidence to users and applications relying on the blockchain.

• State Management:

  • State Updates: The core manages the application of committed transactions to the state, ensuring that all nodes have a consistent view of the blockchain state.

  • Data Integrity: The core ensures the integrity and correctness of the state data, preventing corruption and inconsistencies.

• Protocol Upgrades:

  • Consensus Upgrades: The core may facilitate upgrades to the consensus protocol, ensuring smooth transitions without disrupting the network.

  • Feature Implementation: The core implements new features and improvements in the consensus mechanism, enhancing performance, security, and functionality.

• Data Validation and Seeding:

  • Data Submission: At each block each node is assigned a different data source to fetch data from until the next block. The data is than seeded by the core via IPFS and a CID of the data is submitted as a transaction.

  • Data Seeding: The core is responsible for seeding the Data in the network. The core seeds the data via IPFS.

Decentralized Service Mesh Protocol (DSMP)

Abstract

In active development

The Openmesh Decentralized Service Mesh Protocol (DSMP) is designed to enable decentralized service discovery, communication, and orchestration in the Openmesh network. The protocol allows individuals and organizations to run and manage services (called Service Mesh Workers) on Xnodes—physical or virtualized hardware—while allowing others to consume these services. By fractionalizing service mesh tasks, sharing resources, and enabling decentralized observability, DSMP provides a scalable, resilient, and decentralized alternative to traditional service mesh architectures. This paper outlines the architecture, protocols, consensus mechanisms, and the economic model underlying DSMP.

1. Introduction

Service meshes are a critical component of modern distributed systems, allowing services to communicate, discover, and manage one another. However, traditional service meshes like Istio and Linkerd operate in centralized environments, making them unsuitable for decentralized cloud platforms. The Decentralized Service Mesh Protocol (DSMP) from Openmesh addresses this gap by offering a fully decentralized approach to service communication, resource sharing, and observability.

DSMP allows anyone to run services, known as Service Mesh Workers, on Xnode’s within the Openmesh network, while enabling others to consume these services. Instead of running isolated services or relying on centralized cloud infrastructure, DSMP offers a decentralized environment where service operators can share their resources and offer their services to the network.

2. Architecture of DSMP

2.1 Service Mesh Workers

A Service Mesh Worker is an independent service running on an Xnode. It can be a microservice, a compute task, or an application running on the Openmesh network. Service Mesh Workers can be made public or private:

• Public Service Mesh Workers: These are advertised in the network, and anyone can subscribe to use them.

• Private Service Mesh Workers: These are limited to specific users or groups.
  
  

2.2 Xnodes

Xnode’s are the backbone of the Openmesh network. They represent physical servers, virtual machines, or custom hardware owned by individual users or organizations. Xnodes run services, store data, and participate in the Openmesh consensus mechanisms.

2.3 Decentralized Communication and Resource Sharing

At the core of DSMP is a peer-to-peer (P2P) communication model, where each Xnode can discover, communicate, and share resources with other Xnodes. Through this decentralized communication framework, DSMP enables:

• Decentralized Service Discovery: Xnodes can discover available services via the Kademlia Distributed Hash Table (DHT).

• Resource Fractionalization: Services do not need to run in isolation; they can utilize shared compute, storage, or networking resources offered by multiple Xnodes.

• Service Observability: Service Mesh Workers advertise their usage statistics, allowing for network-wide visibility through the Open Observability Protocol.
  
  

2.4 Open Observability Protocol

DSMP integrates an Open Observability Protocol, providing a transparent and decentralized way for Service Mesh Workers to display their metrics:

• Subscription Counts: Anyone can see which Service Mesh Workers are the most subscribed to.

• Performance Metrics: Uptime, response time, and other service performance data are made publicly available.

Fault Detection: Any faults, errors, or failures are tracked and made visible, enabling automatic recovery and fault-tolerance mechanisms.

3. Protocols Enabling DSMP

3.1 Kademlia Distributed Hash Table (DHT) for Service Discovery

The Kademlia DHT provides a decentralized and efficient way for Xnodes to discover Service Mesh Workers within the network:

• Key-Value Store: Each Service Mesh Worker is assigned a unique key in the DHT, mapping to its network location and metadata.

• Efficient Lookup: Kademlia enables quick lookups for services, ensuring low-latency discovery of available Service Mesh Workers.

• Fault Tolerance: The DHT is fault-tolerant, allowing for service discovery even if some nodes in the network go offline.

3.2 Libp2p for Peer-to-Peer Communication

Libp2p is the foundational networking layer that DSMP uses for peer-to-peer communication between Xnodes. Key features include:

• Secure Communication: Provides encrypted communication between nodes to ensure privacy and integrity.

• Transport Flexibility: Supports multiple transport protocols (TCP, QUIC, WebRTC) for efficient networking in different environments.

• Service Discovery: Works in conjunction with Kademlia DHT to enable dynamic service discovery and task delegation.

3.3 Task Delegation with Resource-Aware Distribution

DSMP uses a Delegated Task with Resource-Aware Distribution model for assigning tasks to Service Mesh Workers:

• Resource Awareness: Each Xnode advertises its available compute, memory, and storage resources.

• Task Delegation: Tasks are assigned to Xnodes based on their available resources and capacity. Larger tasks are given to nodes that can handle them, while smaller nodes take on smaller, simpler tasks.

• Load Balancing: Tasks are distributed dynamically to avoid overloading any single Xnode, ensuring even distribution of network workloads.

4. Consensus Mechanisms in DSMP

4.1 Proof of Stake (PoS)

DSMP uses Proof of Stake (PoS) to ensure the correctness of tasks performed by Service Mesh Workers:

• Token Staking: Xnode operators must stake Open tokens to participate in task execution. This ensures accountability, as nodes that fail to perform tasks correctly can lose their staked tokens.

• Task Verification: Other nodes in the network verify the correctness of completed tasks. If a node is found to be acting maliciously or failing to perform its task, it is penalized.

4.2 Proof of Resource (PoR)

Proof of Resource (PoR) is used to validate that Xnodes offering their resources can indeed deliver the promised compute or storage capacity:

• Resource Verification: Before a task is assigned, the Xnode provides proof that it has the necessary resources (CPU, GPU, storage) to complete the task.

• Continuous Proof: Xnodes must provide regular proofs to show that they are maintaining their advertised resources over time.

4.3 Byzantine Fault Tolerance (BFT)

DSMP integrates Byzantine Fault Tolerance (BFT) for task result verification:

• Task Redundancy: For critical tasks, multiple nodes may be assigned the same task. BFT ensures that consensus is reached on the correct task result, even if some nodes behave maliciously or fail.

• Fault-Tolerant Consensus: BFT allows the network to tolerate faulty or malicious nodes without compromising the accuracy of task results or network stability.

5. Service Mesh Worker Operation

5.1 Fractionalizing Services

DSMP enables fractional service operation, where multiple Xnodes share resources to operate a service:

• Compute and Storage Sharing: Instead of dedicating one node to run an entire service, multiple Xnode’s can combine their resources to run the service collaboratively.

• Dynamic Resource Pooling: The Openmesh protocol dynamically allocates compute, storage, and networking resources based on service demand. As the number of consumers increases, additional resources are allocated automatically.

5.2 Service Subscription and Commitment

Consumers can subscribe to public Service Mesh Workers and use their services. DSMP incorporates a commitment mechanism to ensure long-term availability:

• Subscription Mechanism: Consumers can subscribe to Service Mesh Workers and pay a fee in Open tokens. This commitment can be reflected as either a one-time payment or a recurring subscription.

• Staking for Accountability: Service providers can stake Open tokens to signal accountability. The more they stake, the more confidence consumers have in their reliability.

6. Open Observability Protocol

6.1 Transparent Metrics

The Open Observability Protocol in DSMP provides a transparent layer of metrics that are accessible to all nodes:

• Service Usage Statistics: Displays the number of consumers subscribed to a Service Mesh Worker and the resource consumption patterns.

• Performance Metrics: Uptime, response time, and reliability are continuously monitored and made available for public review.

• Fault Reporting: Errors and failures are logged and available for network-wide review, allowing automatic fault detection and recovery.

6.2 Decentralized Monitoring

Monitoring is decentralized, with metrics collected and aggregated by multiple nodes. There is no single point of failure or control, ensuring resilient and reliable monitoring of services in DSMP.

7. Incentive and Economic Model

7.1 Token-Based Payment and Incentive System

DSMP operates on a token-based economy where Service Mesh Workers are compensated in Open tokens for offering their services. Key components include:

• Service Fees: Consumers pay Service Mesh Workers in Open tokens based on their resource usage or subscription model.

• Staking and Rewards: Nodes can earn additional tokens by staking tokens and performing tasks correctly. Misbehaving nodes lose a portion of their stake as a penalty.

7.2 Resource Leasing

Xnode operators can lease their idle resources to other nodes through the DSMP:

• Compute Leasing: Xnodes can lease their unused compute power to other services that need additional capacity.

• Storage Leasing: Xnodes with excess storage can lease it to services that require decentralized storage, receiving Open tokens in return.

8. Fault Tolerance and Recovery Mechanisms

8.1 Automatic Task Reallocation

In the event that a Service Mesh Worker becomes unavailable or fails to complete a task, DSMP automatically reallocates the task to another node:

• Fault Detection: The Open Observability Protocol continuously monitors service health and identifies failures.

• Task Reassignment: Failed tasks are quickly reassigned to healthy Xnodes to ensure seamless service continuity.

8.2 Redundant Service Execution

Critical services can be executed redundantly across multiple Xnodes, ensuring that even if one node fails, the service remains operational:

• Byzantine Fault Tolerance ensures that redundant service execution results are verified for consistency.

9. Conclusion and Future Directions

The Openmesh Decentralized Service Mesh Protocol (DSMP) is a robust, scalable, and fully decentralized service management framework. By leveraging decentralized communication protocols like Kademlia DHT and libp2p, and consensus mechanisms like PoS, PoR, and BFT, DSMP ensures efficient, secure, and fault-tolerant service discovery, communication, and task execution.