PeerSync: Decentralized Data Sync

• PeerSync is a decentralized systems pattern that facilitates selective data synchronization through mechanisms like succinct proof-of-storage and PAKE-based authentication.
• It integrates varied methodologies including edge container image distribution, geo-located replication, and blockchain synchronization to address diverse network conditions.
• PeerSync implementations demonstrate enhanced performance by reducing metadata overhead and optimizing transfer selection through adaptive network and popularity scoring.

Searching arXiv for the cited PeerSync-related papers and terminology. PeerSync is used in recent arXiv literature to denote, or to motivate, decentralized peer-to-peer synchronization systems that identify divergence between replicas and exchange only the data required to restore consistency. Across the cited works, the label spans storage-redundancy maintenance with succinct proofs, serverless file transfer, Docker image distribution at the network edge, geo-located partial replication for mobile applications, and node-level blockchain synchronization analysis. Taken together, these works suggest that PeerSync is best understood not as a single canonical protocol, but as a recurring systems pattern: decentralized discovery, selective data transfer, and synchronization mechanisms designed to reduce metadata overhead, wide-area traffic, and single points of failure (Nygaard et al., 2023, Trautwein et al., 2023, Deng et al., 27 Jul 2025, Silva et al., 2022, Hu et al., 2022).

1. Scope and usages of the term

The literature is heterogeneous. One paper presents PeerSync as a concrete Rust implementation for edge container image distribution, while other papers provide components or blueprints that are explicitly reframed as a PeerSync solution: a succinct proof-of-storage core, a decentralized discovery and encrypted-transfer pipeline, a geo-located replication framework, and a requester/responder synchronization analysis for blockchain systems.

System	Setting	Distinguishing mechanism
"SNIPS: Succinct Proof of Storage for Efficient Data Synchronization in Decentralized Storage Systems" (Nygaard et al., 2023)	Decentralized storage systems / Ethereum Swarm	Succinct proof object $\pi$ over stored chunks using an MPHF
"Introducing Peer Copy -- A Fully Decentralized Peer-to-Peer File Transfer Tool" (Trautwein et al., 2023)	Peer-to-peer file transfer	mDNS + IPFS DHT discovery, PAKE, AEAD
"Accelerating Containerized Service Delivery at the Network Edge" (Deng et al., 27 Jul 2025)	Container image distribution at the network edge	Popularity- and network-aware download engine, embedded tracker, cache manager
"Geo-located data for better dynamic replication" (Silva et al., 2022)	Mobile geo-located replication	GeoLoc Overlay, Objects Bully, delta-CRDT synchronization
"Sync or Fork: Node-Level Synchronization Analysis of Blockchain" (Hu et al., 2022)	Blockchain block synchronization	Pull-based propagation model, large deviation theory, correlated equilibrium

A plausible implication is that PeerSync denotes a design space rather than a fixed wire protocol. The common denominator is synchronization under partial trust, heterogeneous connectivity, or constrained bandwidth.

2. Verification, authentication, and state agreement

In the SNIPS-based formulation, PeerSync uses a succinct proof-of-storage primitive for frequent redundancy checks. The prover holds a chunk set $C_P=\{c_1,\dots,c_N\}$, the verifier holds $C_V=\{d_1,\dots,d_M\}$, and both share an unpredictable $\lambda$-bit nonce. For each chunk identifier $x$, the per-chunk proof is

$cp_x = H(\text{nonce} \Vert x).$

The proof object is $$\pi=(\text{mphf}, \text{nonce}, [\text{start},\text{end}])$$, where the MPHF is built over the set of chunk proofs. The prover runs CreateProof, signs and broadcasts $\pi$, and the verifier runs FindMissingChunks(\pi) to identify missing indices and request the corresponding chunks. The stated proof size is $|\pi|\simeq bN+O(\lambda)$ bits, with $b\approx 3.3$--$C_P=\{c_1,\dots,c_N\}$0 in practical implementations, and membership queries against the MPHF cost $C_P=\{c_1,\dots,c_N\}$1 each (Nygaard et al., 2023).

In the Peer Copy-derived design, verification is not proof-of-storage but password-bootstrapped authenticated key establishment. Two peers derive a rendezvous from four BIP-39 words, then use the full 4-word phrase $C_P=\{c_1,\dots,c_N\}$2 as the low-entropy shared secret for a PAKE such as SPAKE2. Both sides derive

$C_P=\{c_1,\dots,c_N\}$3

followed by challenge MACs $C_P=\{c_1,\dots,c_N\}$4 and $C_P=\{c_1,\dots,c_N\}$5. After PAKE, all libp2p streams are secured under the negotiated session key via an AEAD cipher such as ChaCha20-Poly1305 or AES-GCM. This yields authenticated peers and encrypted subsequent communication without centralized service providers (Trautwein et al., 2023).

These two lines of work embody different trust models. SNIPS verifies set membership of stored chunks under an untrusted-storage assumption, whereas the Peer Copy pipeline authenticates peers and protects confidentiality and integrity of transferred data.

3. Discovery, rendezvous, and decentralized coordination

PeerSync deployments in the literature use layered discovery. In the Peer Copy design, local discovery uses mDNS and wide-area discovery uses entries in the IPFS DHT. The first BIP-39 word maps to a channel identifier $C_P=\{c_1,\dots,c_N\}$6, the current UNIX timestamp is truncated to the last 5-minute slot, and both sides independently compute the discovery key

$C_P=\{c_1,\dots,c_N\}$7

The sender performs DHT.provide(hash("/pcp/t/c")), while the receiver searches adjacent 5-minute slots in parallel to bound clock skew. On LANs, both peers also advertise and look up the same string via RFC-6762 multicast, allowing immediate direct connection without touching the DHT (Trautwein et al., 2023).

In the edge-container PeerSync system, decentralized coordination is handled by an embedded tracker that runs a DHT and, if no live tracker is found, invokes an automated FloodMax-based election. Each node maintains a stability metric $C_P=\{c_1,\dots,c_N\}$8, exchanges maxima with neighbors, and elects the highest-metric node as tracker after a timeout. Path-pruning ensures each network link carries at most one FloodMax message per round, and the election is reported to converge in $C_P=\{c_1,\dots,c_N\}$9 rounds, where $C_V=\{d_1,\dots,d_M\}$0 is LAN diameter (Deng et al., 27 Jul 2025).

The geo-located framework introduces a different coordination model. Mobile peers maintain direct P2P links to the $C_V=\{d_1,\dots,d_M\}$1 closest peers, with $C_V=\{d_1,\dots,d_M\}$2, and form a proximity-driven GeoLoc Overlay. For each replicated object, exactly one designated bully peer proxies updates back to the edge or cloud. The Objects Bully algorithm periodically broadcasts bully claims, resolves them by peer identifier ordering, and resets on timeout. Only bully peers traverse the WAN, which minimizes wide-area connections while maintaining a path from local replicas to durable infrastructure (Silva et al., 2022).

4. Replication, transfer selection, and data locality

The edge-container PeerSync system is centered on an adaptive download engine. Images of size $C_V=\{d_1,\dots,d_M\}$3 are split into blocks of size $C_V=\{d_1,\dots,d_M\}$4 using a piecewise rule that assigns more blocks to larger images and keeps small images intact. Peer selection combines network-awareness and popularity-awareness. For each peer $C_V=\{d_1,\dots,d_M\}$5, a sliding window of recent speeds yields a rescaled network score $C_V=\{d_1,\dots,d_M\}$6, with local-LAN peers automatically assigned $C_V=\{d_1,\dots,d_M\}$7. A popularity score penalizes peers holding many rare layers. Together with an optional custom score $C_V=\{d_1,\dots,d_M\}$8, the final utility is

$C_V=\{d_1,\dots,d_M\}$9

and peers are sampled for each block via a softmax distribution. The system also includes a cache cleaner that extends LRU with a non-uniform cache miss cost and evicts in descending priority when free space falls below a threshold such as $\lambda$0 (Deng et al., 27 Jul 2025).

The geo-located PeerSync framework applies partial replication by distance. Each peer $\lambda$1 at position $\lambda$2 maintains exactly

$\lambda$3

where $\lambda$4 is the interest radius. Every datum is a geo-located object with identifier, location, payload, and version vector; the payload is modeled as a delta-CRDT. As a peer moves, it adds entering objects and discards leaving ones. Updates are propagated by delta-CRDT anti-entropy, and the current bully for an object forwards merged deltas to the edge server (Silva et al., 2022).

In the SNIPS workflow, transfer selection is driven by proof queries rather than heuristics. The verifier hashes each local chunk identifier under the shared nonce, queries the MPHF, decrements a missing-count array, and identifies indices whose count remains $\lambda$5 as missing. It then sends

$\lambda$6

or a sparse index list, after which the prover uses the reverse map $\lambda$7 to stream the missing chunks and signals \UploadDone upon completion (Nygaard et al., 2023).

5. Formal properties and analytical models

SNIPS states three standard properties. Completeness means that if the prover honestly stored all chunks in $\lambda$8 and constructs $\lambda$9 over exactly $x$0, while the verifier has $x$1, then FindMissingChunks returns no missing indices. Soundness is framed as “No False Consistency”: if the verifier believes missingIndices = ∅ even though some chunk in $x$2 is absent, the probability of false consistency is bounded by

$x$3

Succinctness is the bound $x$4 bits. Construction and verification are linear in the number of chunks, with proof queries costing $x$5 each and overall verifier work $x$6 (Nygaard et al., 2023).

The blockchain synchronization analysis supplies a node-level probabilistic model for requester/responder behavior. Requests arrive to a full node as a Poisson process of rate $x$7, responses complete as a Poisson process of rate $x$8, and stability requires $x$9. The queue length evolves as

$cp_x = H(\text{nonce} \Vert x).$0

When the long-run supremum backlog $cp_x = H(\text{nonce} \Vert x).$1 does not exceed the response capacity $cp_x = H(\text{nonce} \Vert x).$2, waiting time in the corresponding $cp_x = H(\text{nonce} \Vert x).$3 queue has expectation

$cp_x = H(\text{nonce} \Vert x).$4

The large-deviation result gives

$cp_x = H(\text{nonce} \Vert x).$5

and the effective response capacity for target failure $cp_x = H(\text{nonce} \Vert x).$6 is

$cp_x = H(\text{nonce} \Vert x).$7

The same paper formulates requester-side synchronization as a correlated-equilibrium problem over binary request vectors and recommends ranking candidate full nodes by

$cp_x = H(\text{nonce} \Vert x).$8

This analytical line suggests that PeerSync need not be purely protocol-centric; it can also be a capacity-dimensioning and path-selection problem (Hu et al., 2022).

6. Empirical results, limitations, and recurrent misconceptions

The strongest direct evidence for metadata-efficient storage synchronization comes from SNIPS. In a 1,000-peer Ethereum Swarm deployment across 81 neighborhoods of size 8–26, SNIPS sends 2–3 orders of magnitude less metadata than Swarm’s Pullsync in chunk-loss scenarios, with figures reported as $cp_x = H(\text{nonce} \Vert x).$9 KB metadata for SNIPS versus $$\pi=(\text{mphf}, \text{nonce}, [\text{start},\text{end}])$$0 KB for Pullsync on 1000 MB neighborhoods. The reported computation overhead is 6 ms for CreateProof over $$\pi=(\text{mphf}, \text{nonce}, [\text{start},\text{end}])$$1 chunks and 3 ms for FindMissing over $$\pi=(\text{mphf}, \text{nonce}, [\text{start},\text{end}])$$2 chunks, corresponding to approximately 60 $$\pi=(\text{mphf}, \text{nonce}, [\text{start},\text{end}])$$3s/chunk and 30 $$\pi=(\text{mphf}, \text{nonce}, [\text{start},\text{end}])$$4s/chunk, while large proofs require approximately 3.3 bits per chunk and about 4 bits amortized when signature and nonce are included (Nygaard et al., 2023).

For edge container distribution, PeerSync is evaluated on both physical edge devices and Docker-based emulations. Under congested and varying network conditions, it is reported to be on average $$\pi=(\text{mphf}, \text{nonce}, [\text{start},\text{end}])$$5 faster than Baseline, $$\pi=(\text{mphf}, \text{nonce}, [\text{start},\text{end}])$$6 faster than Dragonfly, and $$\pi=(\text{mphf}, \text{nonce}, [\text{start},\text{end}])$$7 faster than Kraken. Peak cross-network traffic is reduced by 90.72% compared to Baseline, and average cross-network use is approximately 0.76 Gbps versus 6.34 Gbps for Baseline. On the Raspberry Pi 4B testbed, PeerSync’s P90 distribution time is 190.8 s, with reductions of 60.9% versus Dragonfly, 39.7% versus Kraken, and 75.9% versus Baseline. The same study also reports that Cache Cleaner versus LRU yields 15–30% less total disk usage across 10 nodes while delivering at least $$\pi=(\text{mphf}, \text{nonce}, [\text{start},\text{end}])$$8 faster LAN cache hits. Its stated limitations are static block sizing, an assumption of homogeneous LAN properties, and the need for user insight when defining custom scoring policies (Deng et al., 27 Jul 2025).

The geo-located replication framework reports preliminary results over real-world traces: in the check-in scenario, GLO-partial exchanged approximately 40% fewer peer-to-peer messages than GLO-full and cut the number of open server connections in half compared to the client-server baseline; in the post-review scenario, total byte volume was 25% lower and WAN traffic to the edge was reduced by approximately 50%; under mixed delays, average end-to-end propagation latency was 30–50 ms, compared to 80–120 ms for client-server. In the Peer Copy setting, throughput is described as comparable to centralized tools such as croc or scp, but public-IPFS-DHT lookup time can take on the order of 30–120 seconds, whereas LAN transfers via mDNS occur in sub-second discovery times and encrypted bulk transfer saturates gigabit links in the reported tests (Silva et al., 2022, Trautwein et al., 2023).

A common misconception is that decentralized PeerSync eliminates coordination cost or all infrastructure dependencies. The literature does not support that interpretation. SNIPS may require a repeat only on collision-flag until convergence, though this is described as rare beyond one round. Peer Copy still depends on public bootstrap and relay nodes for peer-dialing when both peers are behind NATs, unless operators run their own local IPFS daemon. Edge PeerSync replaces static trackers with election, but still maintains swarm integrity through an embedded DHT and tracker role. These points suggest that PeerSync shifts coordination away from centralized service providers, yet does not remove the need for discovery state, election logic, or fallback mechanisms (Nygaard et al., 2023, Trautwein et al., 2023, Deng et al., 27 Jul 2025).