This article explains how distributed systems maintain trust and consistency using gossip-based replication, partial and multi-signature proofs, and M-of-N network connections. The gossip protocol ensures efficient data sharing among peers without redundancy. Proof of correctness validates signatures mathematically, while multi-signatures aggregate trust across nodes. Finally, M-of-N networking reduces overhead while preserving consensus guarantees. Together, these mechanisms form the backbone of scalable, resilient, and secure decentralized systems.This article explains how distributed systems maintain trust and consistency using gossip-based replication, partial and multi-signature proofs, and M-of-N network connections. The gossip protocol ensures efficient data sharing among peers without redundancy. Proof of correctness validates signatures mathematically, while multi-signatures aggregate trust across nodes. Finally, M-of-N networking reduces overhead while preserving consensus guarantees. Together, these mechanisms form the backbone of scalable, resilient, and secure decentralized systems.

Gossip Protocol Replication, Multi-Signatures, and M-of-N Consensus Explained

2025/10/02 17:30

Abstract and 1. Introduction

  1. System model

  2. Initial node state

  3. Append process

    4.1 Local append

    4.2 Append from another node

    4.3 Record validation

    4.4 State consistency

  4. Replication process

  5. Proof of correctness

  6. M-of-N connections

  7. Extensions and optimizations

References

5. Replication process

The algorithm uses Gossip-like approach for replication and works as follows:

\

  1. Gossiping happens in an infinite loop. On each loop (let’s call it round) node (let’s call it node A) choose randomly one peer (let’s call it node B) with which it should gossip.

    \

  2. Then node A sends message to node B. The message includes timestamp and timestamp index from which node A expects to get updates from node B. It’s like a pagination (i.e. give me all records, which timestamp is higher than ). Also keep in mind, that node A should store last requested timestamp and timestamp index for node B (in order not to request the same records again). If there wasn’t communication before, then node A sends timestamp = 0 and timestampIndex = 0

    \

  3. Node B prepare an array of records which satisfy the provided timestamp and timestampIndex from node A (i.e. filter 𝑟𝑒𝑐𝑜𝑟𝑑𝐵.𝑡𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝 > 𝑟𝑒𝑐𝑜𝑟𝑑𝐴.𝑡𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝|| (𝑟𝑒𝑐𝑜𝑟𝑑𝐴.𝑡𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝 === 𝑟𝑒𝑐𝑜𝑟𝑑𝐵.𝑡𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝 && 𝑟𝑒𝑐𝑜𝑟𝑑𝐵.𝑡𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝𝐼𝑛𝑑𝑒𝑥 > 𝑟𝑒𝑐𝑜𝑟𝑑𝐴.𝑡𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝𝐼𝑛𝑑𝑒𝑥))

    \

  4. Node B sends records back to Node A as array of records with some limit (like no more than 10 records in one request, to prevent traffic flooding). The limit option can be set in algorithm parameters

    \

  5. Node A receive these records, sort them in ASC order, and apply them (the logic is described in “Append process / append from another node”)

    \

  6. After append, node A updates last requested timestamp and timestampIndex for node B to the timestamp and timestampIndex from the last record received from node B (sorted in ASC order)

    \

  7. Then protocol awaits for random amount of milliseconds taken from range (the minimum and maximum time is specified in consensus parameters, check section 2). Once timeout expires – the process starts over

\

6. Proof of correctness

6.1 Partial signature

  1. The general formula for obtaining partial signature is: 𝑝𝑎𝑟𝑡𝑖𝑎𝑙𝑆𝑖𝑔𝑛𝑎𝑡𝑢𝑟𝑒 = 𝑝𝑟𝑖𝑣𝑎𝑡𝑒𝐾𝑒𝑦 ∗ ℎ𝑎𝑠ℎ

    \

  2. The validation is: 𝑝𝑎𝑟𝑡𝑖𝑎𝑙𝑆𝑖𝑔𝑛𝑎𝑡𝑟𝑢𝑒 ∗ 𝐺 = 𝑝𝑢𝑏𝑙𝑖𝑐𝐾𝑒𝑦 ∗ ℎ𝑎𝑠ℎ

    \

  3. The correctness: 𝑝𝑢𝑏𝑙𝑖𝑐𝐾𝑒𝑦 = 𝑝𝑟𝑖𝑣𝑎𝑡𝑒𝐾𝑒𝑦 ∗ 𝐺 => 𝑝𝑟𝑖𝑣𝑎𝑡𝑒𝐾𝑒𝑦 ∗ ℎ𝑎𝑠ℎ ∗ 𝐺 = 𝑝𝑢𝑏𝑙𝑖𝑐𝐾𝑒𝑦 ∗ ℎ𝑎𝑠ℎ => 𝑝𝑎𝑟𝑡𝑖𝑎𝑙𝑆𝑖𝑔𝑛𝑎𝑡𝑢𝑟𝑒 ∗ 𝐺 = 𝑝𝑢𝑏𝑙𝑖𝑐𝐾𝑒𝑦 ∗ ℎ𝑎𝑠ℎ

6.2 multi signature

  1. The general formula for building multisig is: 𝑠𝑖𝑔𝑛𝑎𝑡𝑢𝑟𝑒 = ∑ 𝑝𝑎𝑟𝑡𝑖𝑎𝑙𝑆𝑖𝑔𝑛𝑎𝑡𝑢𝑟𝑒 𝑖

    \

  2. The general formula for building multi public key is: 𝑠ℎ𝑎𝑟𝑒𝑑𝑃𝑢𝑏𝑙𝑖𝑐𝐾𝑒𝑦 = ∑ 𝑝𝑢𝑏𝑙𝑖𝑐𝐾𝑒𝑦𝑖 ∗ ℎ𝑎𝑠ℎ

    \

  3. The validation of signature: 𝑠𝑖𝑔𝑛𝑎𝑡𝑢𝑟𝑒 ∗ 𝐺 = 𝑠ℎ𝑎𝑟𝑒𝑑𝑃𝑢𝑏𝑙𝑖𝑐𝐾𝑒𝑦 ∗ ℎ𝑎𝑠ℎ

    \

  4. The correctness of signature: 𝑠𝑖𝑔𝑛𝑎𝑡𝑢𝑟𝑒 ∗ 𝐺 = 𝑠ℎ𝑎𝑟𝑒𝑑𝑃𝑢𝑏𝑙𝑖𝑐𝐾𝑒𝑦 ∗ ℎ𝑎𝑠ℎ => ∑ 𝑝𝑎𝑟𝑡𝑖𝑎𝑙𝑆𝑖𝑔𝑛𝑎𝑡𝑢𝑟𝑒 𝑖 ∗ 𝐺 = ∑ 𝑝𝑢𝑏𝑙𝑖𝑐𝐾𝑒𝑦𝑖 ∗ ℎ𝑎𝑠ℎ => 𝑝𝑎𝑟𝑡𝑖𝑎𝑙𝑆𝑖𝑔𝑛𝑎𝑡𝑢𝑟𝑒 ∗ 𝐺 = 𝑝𝑢𝑏𝑙𝑖𝑐𝐾𝑒𝑦 ∗ ℎ𝑎𝑠ℎ

\

7. M-of-N connections

The following algorithm allows to build M-of-N connections network. This simply means, that there is no strict requirement, that all nodes should have connections between each other. This approach helps to define more efficient networking. However, keep in mind, that in order to guarantee consensus each node should have at least 𝑓 + 1 connections.

\

:::info Author:

(1) Egor Zuev (zyev.egor@gmail.com)

:::


:::info This paper is available on arxiv under CC0 1.0 UNIVERSAL license.

:::

\

Disclaimer: The articles reposted on this site are sourced from public platforms and are provided for informational purposes only. They do not necessarily reflect the views of MEXC. All rights remain with the original authors. If you believe any content infringes on third-party rights, please contact service@support.mexc.com for removal. MEXC makes no guarantees regarding the accuracy, completeness, or timeliness of the content and is not responsible for any actions taken based on the information provided. The content does not constitute financial, legal, or other professional advice, nor should it be considered a recommendation or endorsement by MEXC.

You May Also Like

Ripple CEO Confirms Privacy as Next Stage for XRP’s Institutional Expansion

Ripple CEO Confirms Privacy as Next Stage for XRP’s Institutional Expansion

Ripple advances XRP privacy to attract major institutional blockchain adoption. Confidential transactions and smart contracts set to reshape XRP Ledger. New privacy features aim to balance compliance with institutional confidentiality. The XRP community witnessed a significant revelation after Ripple CEO Brad Garlinghouse confirmed that privacy will drive the next phase of XRP’s institutional adoption. According to Vet, the discussion between him and Garlinghouse centered on strengthening privacy within the XRP ecosystem. This development aligns with the broader goal of creating a compliant yet confidential environment for institutional transactions. Ripple has progressively built the XRP Ledger into a robust infrastructure for real-world use cases. It has introduced decentralized identifiers, on-chain credentials, and permissioned domains to ensure compliance and security. Moreover, the network now features multipurpose tokens that simplify tokenization while its native decentralized exchange merges AMM liquidity with a traditional order book. Despite these advancements, one crucial element remains—privacy. Also Read: Swift Exec Mocks XRP as “Fax Machine,” Sparks Furious Clash with Crypto Fans Developers and Ripple Leadership Target Privacy Layer for Institutional Use Developers and Ripple executives agree that privacy will complete the ecosystem’s institutional framework. The upcoming privacy layer includes functions under proposal XLS-66, allowing institutions to lend and borrow assets using tokenized collateral. This system leverages zero-knowledge proofs to conceal sensitive balance and transaction data while maintaining compliance visibility for regulators. Hence, institutions can protect competitive data without compromising transparency. Ripple’s Senior Director of Engineering, Ayo Akinyele, emphasized the scale of this transformation. He stated that trillions in institutional assets will likely transition on-chain over the next decade. To achieve this, his team is developing confidential multipurpose tokens scheduled for launch in the first quarter of 2026. These tokens will enable private collateral management and secure asset handling across financial platforms. Smart Contracts and Privacy Bridge to Institutional Era Smart escrows proposed under XLS-100 and upcoming smart contracts in XLS-101 are expected to support these privacy-driven functions. Together, they will form the foundation for private institutional transactions within the XRP Ledger. This strategic focus marks a defining step toward positioning XRP as a trusted infrastructure for large-scale financial institutions. As privacy becomes the bridge connecting compliance with confidentiality, Ripple’s roadmap signals its readiness to lead blockchain adoption in traditional finance. Also Read: Shiba Inu Approaches Critical Price Zone as Bulls and Bears Battle for Control The post Ripple CEO Confirms Privacy as Next Stage for XRP’s Institutional Expansion appeared first on 36Crypto.
Share
Coinstats2025/10/05 22:14