From a0283a2e02c4e7aecf7895aef7b85a82d1874d58 Mon Sep 17 00:00:00 2001 From: swarnabhasinha Date: Wed, 22 Oct 2025 19:02:13 +0530 Subject: [PATCH] Rename mumP2P to mump2p throughout documentation --- .vitepress/config.mts | 4 +-- docs/guides/02-getting-started-docker.md | 20 +++++++-------- docs/guides/03-parameters.md | 12 ++++----- docs/guides/04-experiments.md | 30 +++++++++++----------- docs/guides/05-faq-glossary.md | 2 +- docs/guides/overview.md | 8 +++--- docs/learn/overview/intro.md | 6 ++--- docs/learn/overview/p2p.md | 32 ++++++++++++------------ 8 files changed, 57 insertions(+), 57 deletions(-) diff --git a/.vitepress/config.mts b/.vitepress/config.mts index 1019bbe..bee1a01 100644 --- a/.vitepress/config.mts +++ b/.vitepress/config.mts @@ -192,7 +192,7 @@ function sidebarHome() { link: "/docs/learn/overview/intro", }, { - text: "mumP2P Protocol", + text: "mump2p Protocol", link: "/docs/learn/overview/p2p.md", }, { @@ -250,7 +250,7 @@ function sidebarHome() { collapsed: false, items: [ { - text: "mumP2P Protocol", + text: "mump2p Protocol", collapsed: true, items: [ { diff --git a/docs/guides/02-getting-started-docker.md b/docs/guides/02-getting-started-docker.md index 77e800f..5773e08 100644 --- a/docs/guides/02-getting-started-docker.md +++ b/docs/guides/02-getting-started-docker.md @@ -3,17 +3,17 @@ Running **Optimum Network** locally with Docker gives you **full control** over configuration, topology, and experiments. You can run the network in two primary ways: -**1. OptimumProxy + mumP2P** — Clients connect to an **Optimum Proxy**, which manages P2P connections for them. +**1. OptimumProxy + mump2p** — Clients connect to an **Optimum Proxy**, which manages P2P connections for them. -![OptimumProxy + mumP2P Architecture](../../static/img/docker_1.png) +![OptimumProxy + mump2p Architecture](../../static/img/docker_1.png) * Simplifies client configuration — only the Proxy address is needed. * Proxy handles shard reassembly, threshold logic, and node selection automatically. * Easier scaling and centralized policy control. -**2. Direct mumP2P** — Clients connect directly to **mumP2P nodes** (each node must run the gRPC API). +**2. Direct mump2p** — Clients connect directly to **mump2p nodes** (each node must run the gRPC API). -![Direct mumP2P Architecture](../../static/img/docker_2.png) +![Direct mump2p Architecture](../../static/img/docker_2.png) * Fewer network hops = potentially lower latency. * Clients must know node addresses and manage failover logic. @@ -32,7 +32,7 @@ local deployment offers: Choose the deployment mode that best fits your use case: -| **Mode A: Proxy + mumP2P** | **Mode B: Direct mumP2P** | +| **Mode A: Proxy + mump2p** | **Mode B: Direct mump2p** | |---|---| | **One endpoint** — simpler client config | **Lowest latency** — fewer network hops | | **Policy control** — rate limiting, auth | **Direct control** — no proxy overhead | @@ -62,7 +62,7 @@ Choose the deployment mode that best fits your use case: | Component | Purpose | Docker Images | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | --------------------------- | -| **mumP2P Node** | RLNC-enabled mesh peer, encodes/decodes message shards, handles peer discovery and subscriptions. Optional gRPC API for direct clients. | `getoptimum/p2pnode:v0.0.1-rc2` | +| **mump2p Node** | RLNC-enabled mesh peer, encodes/decodes message shards, handles peer discovery and subscriptions. Optional gRPC API for direct clients. | `getoptimum/p2pnode:v0.0.1-rc2` | | **Optimum Proxy** | Bridges clients and the mesh, manages subscriptions, shard reassembly, threshold logic, and node selection. | `getoptimum/proxy:v0.0.1-rc3` | @@ -84,8 +84,8 @@ We’ll keep identity in `./identity` folder so you can reuse keys across restar | Recommended mode | Why | | ----------------------------- | ----------------------------------------------------------------------------------------- | -| **OptimumProxy + mumP2P** | One endpoint for clients, proxy handles matching, decoding thresholds, fanout, and policy | -| **Direct mumP2P** | Fewer hops, you control connection/retry logic and node selection | +| **OptimumProxy + mump2p** | One endpoint for clients, proxy handles matching, decoding thresholds, fanout, and policy | +| **Direct mump2p** | Fewer hops, you control connection/retry logic and node selection | ## 3. Environment Configuration @@ -119,7 +119,7 @@ This creates `./identity/p2p.key` with your unique Peer ID. > **Complete Guide:** [Identity generation and Makefile commands](https://github.com/getoptimum/optimum-dev-setup-guide#quick-start) - all make commands, direct binary usage -## 5. Mode A — OptimumProxy + mumP2P (Recommended) +## 5. Mode A — OptimumProxy + mump2p (Recommended) ### Docker Compose Setup @@ -228,7 +228,7 @@ For gRPC bidirectional streaming (higher performance than WebSocket): > * [Setup and Usage Guide](https://github.com/getoptimum/optimum-dev-setup-guide/blob/main/docs/guide.md#grpc-proxy-client-implementation) > * REST subscription + gRPC streaming + flow control settings -## 6. Mode B — Direct mumP2P (Advanced / Lower Latency) +## 6. Mode B — Direct mump2p (Advanced / Lower Latency) In this mode, clients connect directly to node sidecar gRPC (no proxy). diff --git a/docs/guides/03-parameters.md b/docs/guides/03-parameters.md index 118cfa1..7fe1fda 100644 --- a/docs/guides/03-parameters.md +++ b/docs/guides/03-parameters.md @@ -1,8 +1,8 @@ -# Understanding Key Parameters in mumP2P +# Understanding Key Parameters in mump2p > **Complete Reference:** [Full parameter guide and defaults](https://github.com/getoptimum/optimum-dev-setup-guide/blob/main/docs/guide.md#configuration) - all variables, `.env` workflow, production configs -mumP2P nodes can operate in **two distinct protocol modes**, configured via: +mump2p nodes can operate in **two distinct protocol modes**, configured via: ```sh NODE_MODE=optimum # RLNC-enhanced gossip @@ -13,9 +13,9 @@ Each mode has its own parameter set, with some shared configurations. We support **two protocol modes** to let developers and researchers compare **performance, reliability, and bandwidth trade-offs** in real-world scenarios — without changing the rest of their infrastructure. -## mumP2P (RLNC) Mode — `NODE_MODE=optimum` +## mump2p (RLNC) Mode — `NODE_MODE=optimum` -mumP2P extends the gossip protocol with **Random Linear Network Coding**: +mump2p extends the gossip protocol with **Random Linear Network Coding**: * Messages are split into **shards** * Shards can be forwarded early once a threshold is reached @@ -134,7 +134,7 @@ The following table shows the **production defaults**, which are optimized for t ### For Quick Start (Copy-Paste Ready) -**mumP2P Mode (`NODE_MODE=optimum`):** +**mump2p Mode (`NODE_MODE=optimum`):** ```yaml environment: @@ -200,5 +200,5 @@ environment: | `GOSSIPSUB_MESH_MAX` | 12 | gossipsub | Max peers before pruning | | `BOOTSTRAP_PEERS` | [] | Both | List of peer multiaddrs for bootstrap | -> **Note:** These are the production defaults used by mumP2P nodes. For experimental tuning, see [Common Experiments](./04-experiments.md). +> **Note:** These are the production defaults used by mump2p nodes. For experimental tuning, see [Common Experiments](./04-experiments.md). diff --git a/docs/guides/04-experiments.md b/docs/guides/04-experiments.md index 0fbe7bd..4adab61 100644 --- a/docs/guides/04-experiments.md +++ b/docs/guides/04-experiments.md @@ -13,13 +13,13 @@ Each experiment below lists the **goal**, a quick **how-to**, and **what to obse You can run them using: * **mump2p CLI** (see [CLI Guide](./01-getting-started-cli.md)) -* **gRPC client** (with `MessageTraceGossipSub` or `MessageTraceOptimumP2P` for protocol metrics) +* **gRPC client** (with `MessageTraceGossipSub` or `MessageTraceOptimump2p` for protocol metrics) -## 1. GossipSub vs mumP2P +## 1. GossipSub vs mump2p -**Goal:** Compare standard libp2p gossip to RLNC-enhanced gossip to confirm mumP2P is faster. +**Goal:** Compare standard libp2p gossip to RLNC-enhanced gossip to confirm mump2p is faster. **How:** @@ -29,11 +29,11 @@ You can run them using: **Observe:** -* **Delivery latency** (primary metric - mumP2P should be faster) -* **Bandwidth usage** (mumP2P should use less) +* **Delivery latency** (primary metric - mump2p should be faster) +* **Bandwidth usage** (mump2p should use less) * **Success rate** (both should deliver messages successfully) -**Expected Result:** mumP2P should show lower latency and bandwidth usage. +**Expected Result:** mump2p should show lower latency and bandwidth usage. ## 2. Shard Factor Sweep @@ -74,13 +74,13 @@ You can run them using: ## 4. Mesh Density Impact -**Goal:** Compare mumP2P vs GossipSub with different mesh sizes. +**Goal:** Compare mump2p vs GossipSub with different mesh sizes. **How:** * Test both `NODE_MODE=gossipsub` and `NODE_MODE=optimum`. * For GossipSub: try `GOSSIPSUB_MESH_TARGET` = 4, 6, 8. -* For mumP2P: try `OPTIMUM_MESH_TARGET` = 6, 12, 18. +* For mump2p: try `OPTIMUM_MESH_TARGET` = 6, 12, 18. * Run the same publish/subscribe test. **Observe:** @@ -88,7 +88,7 @@ You can run them using: * **Delivery latency** (primary metric) * **Bandwidth usage** -**Expected Result:** mumP2P should perform better with higher mesh targets (around 12) while GossipSub optimal around 6. +**Expected Result:** mump2p should perform better with higher mesh targets (around 12) while GossipSub optimal around 6. @@ -96,7 +96,7 @@ You can run them using: ## 5. Load Test -**Goal:** Find when mumP2P vs GossipSub starts to fail under stress. +**Goal:** Find when mump2p vs GossipSub starts to fail under stress. **How:** @@ -109,13 +109,13 @@ You can run them using: * **When delivery starts to fail** (primary metric) * **Delivery rate degradation** -**Expected Result:** mumP2P should handle higher stress levels before failing compared to GossipSub. +**Expected Result:** mump2p should handle higher stress levels before failing compared to GossipSub. > **Tip:** Enable protocol traces in the gRPC client to get hop-by-hop delivery info: > > * `MessageTraceGossipSub` for GossipSub mode. -> * `MessageTraceOptimumP2P` for mumP2P mode. +> * `MessageTraceOptimump2p` for mump2p mode. ## Metrics Collection @@ -128,7 +128,7 @@ For comprehensive metrics collection during experiments, use the gRPC P2P client The client automatically captures and displays: * **GossipSub traces**: Peer routing, message delivery status, hop counts, latency -* **mumP2P traces**: Shard encoding/decoding, reconstruction efficiency, redundancy metrics +* **mump2p traces**: Shard encoding/decoding, reconstruction efficiency, redundancy metrics * **Message-level data**: Delivery success rates, end-to-end latency, bandwidth usage **Key trace handlers:** @@ -137,8 +137,8 @@ The client automatically captures and displays: case protobuf.ResponseType_MessageTraceGossipSub: fmt.Printf("[TRACE] GossipSub trace received: %s\n", string(resp.GetData())) -case protobuf.ResponseType_MessageTraceOptimumP2P: - fmt.Printf("[TRACE] mumP2P trace received: %s\n", string(resp.GetData())) +case protobuf.ResponseType_MessageTraceOptimump2p: + fmt.Printf("[TRACE] mump2p trace received: %s\n", string(resp.GetData())) ``` Use this client instead of the CLI for detailed performance analysis during experiments. diff --git a/docs/guides/05-faq-glossary.md b/docs/guides/05-faq-glossary.md index bf6dee6..c086b98 100644 --- a/docs/guides/05-faq-glossary.md +++ b/docs/guides/05-faq-glossary.md @@ -107,4 +107,4 @@ When something doesn't work: * **CLI Issues**: [mump2p-cli FAQ](https://github.com/getoptimum/mump2p-cli#faq---common-issues--troubleshooting) * **Setup Issues**: Check [`optimum-dev-setup-guide/docs/guide.md`](https://github.com/getoptimum/optimum-dev-setup-guide/blob/main/docs/guide.md) -* **Protocol Questions**: See [mumP2P Documentation](./p2p.md) +* **Protocol Questions**: See [mump2p Documentation](./p2p.md) diff --git a/docs/guides/overview.md b/docs/guides/overview.md index 7d3e4d2..93b3498 100644 --- a/docs/guides/overview.md +++ b/docs/guides/overview.md @@ -16,7 +16,7 @@ Whether you are an application developer, systems engineer, or hackathon partici Choose your path to get started with Optimum Network: -### **Try mumP2P (≤5 min)** +### **Try mump2p (≤5 min)** **[Using mump2p-cli](01-getting-started-cli.md)** — Connect to hosted proxy, no setup required @@ -30,7 +30,7 @@ Choose your path to get started with Optimum Network: * Complete local network deployment * Experiment with different parameters -* Compare mumP2P vs GossipSub performance +* Compare mump2p vs GossipSub performance ### **Understanding & Experimenting** @@ -77,9 +77,9 @@ Before diving deep, familiarize yourself with these terms and how they relate to | **Direct P2P Mode** | Clients connect directly to P2P nodes via gRPC without going through a proxy. This can reduce latency but requires more configuration. | | **Mesh Parameters** | Settings such as `MESH_TARGET` that define how many peers a node tries to keep in its topic mesh. | | **Fanout** | A temporary set of peers a publisher sends messages to when it is not part of the topic mesh. | -| **Control Messages** | Special messages like GRAFT, PRUNE, IHAVE, IWANT used for GossipSub mesh management. mumP2P integrates similar control flows for RLNC. | +| **Control Messages** | Special messages like GRAFT, PRUNE, IHAVE, IWANT used for GossipSub mesh management. mump2p integrates similar control flows for RLNC. | | **Node Discovery** | The process by which proxies or nodes automatically learn about other nodes to connect to. | | **gRPC API** | The RPC interface provided by either a P2P node or a proxy for client communication. | -For more technical details, see the **[mumP2P Technical Overview](../learn/overview/p2p.md)**. +For more technical details, see the **[mump2p Technical Overview](../learn/overview/p2p.md)**. diff --git a/docs/learn/overview/intro.md b/docs/learn/overview/intro.md index 4d9e9ed..4227a26 100644 --- a/docs/learn/overview/intro.md +++ b/docs/learn/overview/intro.md @@ -12,9 +12,9 @@ Powered by [Random Linear Network Coding (RLNC)](./p2p.md#random-linear-network- ## Products -Builders and operators can adopt **mumP2P** now for measurable latency gains. DeRAM and DeROM are next to unlock low-latency reads/writes. +Builders and operators can adopt **mump2p** now for measurable latency gains. DeRAM and DeROM are next to unlock low-latency reads/writes. -### mumP2P +### mump2p RLNC-accelerated, libp2p/gossipsub-compatible pub/sub for fast, resilient propagation of blocks, blobs, and transactions. **Get started:** [Overview](../../learn/overview/p2p.md) · [Quickstart](../../guides/01-getting-started-cli.md) @@ -40,7 +40,7 @@ A **flexnode** is an operator-run node that participates in Optimum's coded goss ## Start here -* **Try mumP2P (≤5 min):** [Using mump2p-cli](../../guides/01-getting-started-cli.md) +* **Try mump2p (≤5 min):** [Using mump2p-cli](../../guides/01-getting-started-cli.md) * **Run locally:** [Local Setup with Docker](../../guides/02-getting-started-docker.md) * **Integrate:** [Publish/Subscribe via Optimum Proxy endpoints](https://github.com/getoptimum/optimum-dev-setup-guide/blob/main/docs/guide.md#proxy-api) diff --git a/docs/learn/overview/p2p.md b/docs/learn/overview/p2p.md index b825792..4a140c7 100644 --- a/docs/learn/overview/p2p.md +++ b/docs/learn/overview/p2p.md @@ -1,15 +1,15 @@ -# mumP2P Protocol +# mump2p Protocol -**mumP2P** is a next-generation gossip protocol that uses [Random Linear Network Coding (RLNC)](https://x.com/get_optimum/status/1891520664726802439) to revolutionize message dissemination in peer-to-peer networks. Built on [libp2p](https://docs.libp2p.io/), it offers a high-performance alternative to traditional protocols like [GossipSub](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub), delivering faster propagation, better bandwidth efficiency, and better fault tolerance using network coding. +**mump2p** is a next-generation gossip protocol that uses [Random Linear Network Coding (RLNC)](https://x.com/get_optimum/status/1891520664726802439) to revolutionize message dissemination in peer-to-peer networks. Built on [libp2p](https://docs.libp2p.io/), it offers a high-performance alternative to traditional protocols like [GossipSub](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub), delivering faster propagation, better bandwidth efficiency, and better fault tolerance using network coding. -## How mumP2P Works +## How mump2p Works -mumP2P is a gossip mechanism based on RLNC, also known as **Galois Gossip**, that builds upon [libp2p](https://docs.libp2p.io/)'s [GossipSub](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub) protocol. Instead of transmitting complete messages between peers, mumP2P breaks messages into coded shards that can be independently forwarded and mathematically recombined to reconstruct the original data. +mump2p is a gossip mechanism based on RLNC, also known as **Galois Gossip**, that builds upon [libp2p](https://docs.libp2p.io/)'s [GossipSub](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub) protocol. Instead of transmitting complete messages between peers, mump2p breaks messages into coded shards that can be independently forwarded and mathematically recombined to reconstruct the original data. ### Node Architecture -Each mumP2P node is a standard libp2p host enhanced with RLNC logic. Core components include: +Each mump2p node is a standard libp2p host enhanced with RLNC logic. Core components include: * **libp2p Host** – Provides peer discovery, secure communication, and network transport. * **Mesh Topology** – Maintains a configurable gossip mesh with peer degrees similar to GossipSub. @@ -60,7 +60,7 @@ When a node receives a shard: ### Control Messages -mumP2P uses and extends [GossipSub's](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0.md#control-messages) control messages for optimized mesh performance: +mump2p uses and extends [GossipSub's](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0.md#control-messages) control messages for optimized mesh performance: | Message | Purpose | |-------------|-------------------------------------------------------------------------| @@ -71,7 +71,7 @@ mumP2P uses and extends [GossipSub's](https://github.com/libp2p/specs/blob/maste ## Configuration Parameters -mumP2P provides several configurable parameters to tune performance for different network conditions and requirements: +mump2p provides several configurable parameters to tune performance for different network conditions and requirements: ### RLNC Encoding @@ -81,21 +81,21 @@ mumP2P provides several configurable parameters to tune performance for differen ### Mesh Topology Parameters -mumP2P builds upon libp2p's [GossipSub mesh topology](https://docs.libp2p.io/concepts/pubsub/overview/#full-message), where peers maintain **full-message peerings** for reliable data transmission and **metadata-only peerings** for gossip and network maintenance. +mump2p builds upon libp2p's [GossipSub mesh topology](https://docs.libp2p.io/concepts/pubsub/overview/#full-message), where peers maintain **full-message peerings** for reliable data transmission and **metadata-only peerings** for gossip and network maintenance. * **MeshDegreeTarget**: Target number of peers to maintain in the mesh overlay. This controls the trade-off between speed, reliability, resilience and efficiency of the network. A higher peering degree helps messages get delivered faster with better reliability, but increases bandwidth usage due to redundant message copies. * **MeshDegreeMin**: Minimum number of mesh peers before triggering [grafting](https://docs.libp2p.io/concepts/pubsub/overview/#grafting-and-pruning) (converting metadata-only connections to full-message). * **MeshDegreeMax**: Maximum number of mesh peers before triggering [pruning](https://docs.libp2p.io/concepts/pubsub/overview/#grafting-and-pruning) (converting full-message peerings back to metadata-only). -In libp2p's default implementation, the ideal network peering degree is 6 with anywhere from 4–12 being acceptable. mumP2P inherits these mesh management mechanisms while optimizing shard propagation through the established topology. +In libp2p's default implementation, the ideal network peering degree is 6 with anywhere from 4–12 being acceptable. mump2p inherits these mesh management mechanisms while optimizing shard propagation through the established topology. ## Use Cases -mumP2P serves as a foundational, general-purpose data propagation protocol with benefits extending across various blockchain use cases. +mump2p serves as a foundational, general-purpose data propagation protocol with benefits extending across various blockchain use cases. ### Validators and Node Operators -mumP2P supercharges validator and full node performance in bandwidth-constrained and latency-sensitive networks: +mump2p supercharges validator and full node performance in bandwidth-constrained and latency-sensitive networks: * **[Ethereum](https://ethereum.org/)**: Faster mempool propagation, lower uncle rates, and potential integration into both execution and consensus layers. * **[Solana](https://solana.com/)**: Enhances Turbine-style data sharding with fault-tolerant packet loss recovery. @@ -114,7 +114,7 @@ High-frequency trading chains rely on fast, reliable state propagation: AI networks are data-intensive and latency-sensitive: -* mumP2P enables fast gossiping of model weights, gradients, and other updates +* mump2p enables fast gossiping of model weights, gradients, and other updates * Supports high-throughput training/inference coordination across distributed nodes * Reduces straggler nodes and failed task replication due to packet loss @@ -130,7 +130,7 @@ Decentralized physical infrastructure demands reliable node coordination at scal These chains rely on fast event propagation for user interactions: -* mumP2P delivers low-latency, real-time interactions (game state syncs, social updates) +* mump2p delivers low-latency, real-time interactions (game state syncs, social updates) * Improves experience for multiplayer, onchain games and social dApps * Reduces costs of redundant relay infra through efficient data spreading @@ -138,7 +138,7 @@ These chains rely on fast event propagation for user interactions: ## Security Model -mumP2P inherits libp2p's robust security foundation, and adds safeguards specific to network coding. +mump2p inherits libp2p's robust security foundation, and adds safeguards specific to network coding. ### Inherited from libp2p @@ -147,11 +147,11 @@ mumP2P inherits libp2p's robust security foundation, and adds safeguards specifi For a full overview of these protections, refer to the [libp2p security considerations](https://docs.libp2p.io/concepts/security/security-considerations/). -### mumP2P avoids Pollution Attacks +### mump2p avoids Pollution Attacks In **pollution attacks** attack, a malicious actor injects corrupted or invalid coded shards into the network, with the goal of preventing honest nodes from successfully decoding the original message. -mumP2P mitigates this risk through a multi-layered approach centered on **source authentication**. +mump2p mitigates this risk through a multi-layered approach centered on **source authentication**. * The original message data is cryptographically hashed to create a unique identifier. * This identifier, along with the publisher's signature, is bound to the data.