Whitepaper

Abstract

Fragma is dedicated to building the most secure, user-friendly, and efficient decentralized private storage solution, driving its adoption at scale. Every technology, method, and system we leverage is in service of this singular mission.

We are not a VC-backed research lab chasing the next flashy protocol. Nor do we need to reinvent wheels that already roll. Instead, we are pragmatic builders who stand on the shoulders of brilliant mathematicians, blockchain pioneers, and visionary researchers. By combining their proven innovations with our own practical ingenuity, we aim to deliver real, usable solutions where others have fallen short.

With respect and gratitude toward those who paved the way, we embrace our role as the next generation of entrepreneurs. We innovate where needed but take pride in optimizing and deploying established technologies to meet market demands.

Whitepaper v2.0 outlines Fragma’s technical architecture and the core technologies we deploy to realize our decentralized storage platform. It details our use of Web3 wallet authentication for secure file access and management, as well as improvements to cryptographic models, data integrity systems, and performance optimization mechanisms. Key challenges addressed include nonce reuse, key management complexities, erasure coding limitations, and dependencies on node reliability.

Let’s dive into Resonator Whitepaper 2.0 and explore the vision, technology, and solutions driving us forward.

0 Introduction

In decentralized storage systems, particularly those integrated with web3 technologies, it’s crucial to address cryptographic vulnerabilities, ensure robust data recovery methods, and
guarantee privacy while offering a smooth user experience. Fragma utilizes a layered architecture to provide decentralized, private, and user-controlled file storage.

The system prioritizes key security concepts such as secure web3 wallet integration, fault-tolerant storage, and reliable data retrieval.



The system architecture is composed of three primary layers:

Web3 Wallet Authentication Layer
Decentralized Storage and Redundancy Layer
File Retrieval and Data Verification Protocol

Each layer is cryptographically secure and decentralized to minimize the risk of data breaches, while ensuring efficient data storage and retrieval.

1 Web3 Wallet Authentication

Authentication is handled exclusively through Web3 wallets, such as MetaMask or WalletConnect, which rely on elliptic curve digital signature algorithms (ECDSA). This section introduces an enhanced version of the authentication process to prevent known vulnerabilities, such as nonce reuse and improper hashing techniques.

1.1 Cryptographic Enhancements

ECDSA signatures are generated using a nonce, 𝑘, that must be unique for each signature. To prevent the vulnerabilities of nonce reuse, we adopt a deterministic signature generation scheme such as the one defined in RFC 6979. This approach generates the nonce deterministically from the message and private key, ensuring no reuse:



The value k is calculated using the following equation:

The value "kseed" is a secret value derived from the private key, eliminating the risks associated with random nonce generation.

The signed message is hashed using SHA-256 for consistency with most blockchain systems.

The signature is generated using the ECDSA algorithm, applied to the SHA-256 hash of the message, along with the private key.



The verification process remains standard but with stricter hash requirements to ensure security against potential hash collisions.

2 Decentralized Storage Architecture

2.1 Advanced Erasure Coding and Redundancy

Fragma operates files that are encrypted, split into multiple shards, and distributed across a network of storage nodes using erasure coding. However, to address concerns regarding node failure dependencies and excessive computational overhead, we enhance
the storage system with Reed-Solomon encoding optimized for performance.

Given a file F, we split it into n data blocks and generate mm parity blocks using erasure coding. To prevent data loss due to correlated node failures (such as regional outages), we incorporate geographically-aware storage distribution, ensuring that no two redundant blocks are stored in close proximity.

The formula for file recovery is updated to reflect this redundancy:

Where n is the minimum number of shards required for reconstruction. Additionally, the storage nodes are monitored via a distributed reputation system to ensure they behave honestly and provide accurate data when requested. Misbehaving nodes are penalized and eventually excluded from the network.

Data Reconstruction Limitations:

To prevent data loss from excessive node failures, the system constantly monitors the availability of the n+mn+m blocks. If the number of nodes falls below a predefined threshold, a re-sharding protocol is initiated to redistribute the existing blocks across more stable nodes. This prevents a scenario where too many nodes are lost, making data recovery impossible.

2.2 Performance vs. Redundancy Trade-off

To balance between redundancy and computational overhead, we adopt a dynamic configuration that adjusts the ratio of data blocks n to parity blocks mm based on real-time network conditions:

• In low-latency, high-reliability environments, the system prefers a higher n/mn/m ratio to minimize storage overhead.
  

• In high-failure or less reliable environments, a more conservative ratio (i.e., more parity blocks) is used to ensure data remains recoverable.
  

3 File Retrieval Protocol and Data Verification

When users request to retrieve a file, their Web3 wallet is used to authenticate the request and securely decrypt the file. The retrieval process follows these steps:

• The system locates the necessary n data blocks from the storage networkn
  

• A Merkle tree is constructed to verify the integrity of the data blocks
  

• The encrypted shards are reassembled and decrypted using the file-specific AES-256 key derived from the user’s wallet.
  

3.1 Merkle Tree Integrity Verification

To ensure that no tampering occurs during file storage and retrieval, we employ Merkle tree hashing for all file shards. The file shards S1,S2,…,SnS1,S2,…,Sn are hashed individually, and these hashes are combined to form a Merkle root:

Where H₁ , H₂ , H_n are the individual hash values of the shards. This Merkle root is stored on-chain, ensuring the file’s integrity can be verified at any point. When retrieving data, a user can recompute the Merkle root and compare it to the onchain value to confirm the data’s authenticity.

A graphical representation of the Merkle tree structure for data verification:

3.2 Zero-Knowledge Proofs for Node Verification

To ensure that storage nodes are correctly holding the data without revealing it, ZeroKnowledge Proofs (ZKPs) are used. Each storage node periodically proves that it holds the correct data by generating a cryptographic proof based on the data shard’s hash, without exposing the data itself.

4 Realistic Node Failure Model

We integrate a correlated failure model. This approach assumes that node failures can occur in clusters due to regional outages or network partitions. The updated formula for availability takes this into account:

Where p(k) represents the failure probability of k nodes, factoring in regional dependencies. This provides a more accurate view of system resilience, especially in large, globally distributed networks.

5 Sharding

Sharding involves splitting large files into smaller, encrypted fragments or shards, which are then
distributed across multiple storage nodes. This approach enhances both data security and redundancy. Each shard is uniquely identified and encrypted, ensuring that even if a shard is intercepted, it cannot be reconstructed or understood without the corresponding cryptographic keys.
‍
Mathematically, a file F is divided into n shards, denoted as

where each s_i is an encrypted fragment of the original file. Redundancy is typically introduced using erasure coding techniques such as Reed-Solomon coding, where additional parity shards m are generated to allow file recovery even if some original shards are lost or corrupted.

The recovery condition is given by:

where k is the number of original shards and m is the number of parity shards.

When a user wants to retrieve the file, the system only requires a subset of these shards (typically 𝑘 original shards) to successfully reconstruct the file. This ensures fault tolerance and data availability even in the case of node failures or malicious activity. This process is integrated with Zero-Knowledge Proofs (ZKPs) to allow storage nodes to prove they possess specific shards without revealing their content, ensuring that no single node can compromise the integrity or confidentiality of the file.


The combination of file sharding, encryption, and ZKP ensures a robust decentralized storage solution with a high level of privacy, security, and fault tolerance.

6 Encryption and Key Management

All data stored is encrypted using AES-256 in GCM mode, a secure encryption method that also provides data integrity checks. To prevent IV (Initialization Vector) reuse, each file upload generates a unique IV through a cryptographically secure random number generator (CSPRNG):

This ensures that even if the same file is uploaded multiple times, the encryption remains secure.The encryption key is derived from the user's Web3 wallet but is never exposed. Instead, weleverage Hierarchical Deterministic (HD) Wallets to generate a file-specific key that is unique toeach storage instance:

This key management approach allows for decentralized and private encryption without involving third-party services.

7 Anyone Protocol Routing

TOR has certain limitations that can strategically constrain our ecosystem's capabilities—Resonator services monetization being one such example.

On the other hand, Anyone Protocol offers an enhanced version of the TOR SDK, along with a proactive community and a strong focus on project onboarding. For the reasons described above, we are considering replacing TOR Onion Routing with the Anyone SDK within the Resonator ecosystem in the near future.

Selective Disclosure: Anyone Protocol allows users to selectively disclose only the necessary information to fulfill a specific request. This approach minimizes data exposure and eliminates unnecessary sharing of personal information, which is often a weakness in traditional verification systems.

Decentralized Trust Network: Anyone Protocol operates on a decentralized network where no single point of failure exists. Nodes within the network handle requests and verifications, but cryptographic protections ensure that no node has complete access to the data, further enhancing privacy and resilience.

Resistance to Traffic Analysis: Unlike traditional routing systems, Anyone Protocol focuses on cryptographic protections rather than relying on obfuscation through multiple nodes. This approach renders traffic analysis ineffective, as no data packets or communication routes can reveal the source or content of the interaction.

Integration with Decentralized Services: Our integration with Anyone Protocol supports decentralized applications and storage solutions, enabling users to verify data, access nodes, or perform operations without compromising their privacy. Anonymous credentials allow seamless interaction across the network, ensuring privacy-first access to services without requiring users to expose their identity or IP address.

By leveraging Anyone Protocol’s privacy-preserving technology, we enable a secure, trustless, and anonymous environment for data exchange, strengthening user privacy and network resilience.

8 Zero-Knowledge Proofs (ZKP)

Zero-Knowledge Proofs (ZKPs) enables one party (the prover) to prove to another party (the verifier) that they know certain information (such as a data shard) without revealing the information itself. In decentralized storage systems, ZKPs enhance trust by allowing storage nodes to prove they are correctly holding data without exposing the data itself.

8.1 Zero-Knowledge Proof Structure

The prover must satisfy three core propertiesV

• Completeness: If the statement is true, the verifier will be convinced by a correct proof from the prover.
  

• Soundness: If the statement is false, the verifier will not be fooled by a false proof.
  

• Zero-Knowledge: The verifier gains no knowledge about the actual data, other than the fact that the statement is true.
  

For storage verification, a node (prover) can use a ZKP to demonstrate that it holds a specific file shard without actually revealing the shard. This prevents dishonest nodes from pretending to hold data they don’t, and it guarantees that even if a node attempts to prove data it does hold, no information is leaked to external observers.

8.2 ZKP Construction

Zero-Knowledge Proofs can be implemented using various techniques such as ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge), which are particularly well-suited for decentralized systems due to their efficiency.

A ZKP can be described mathematically as follows.

• Public Parameters: Let 𝑥 be the public input (e.g., the hash of the data shard) and 𝑤 be the private witness(the actual data shard). The prover knows both 𝑥 and 𝑤, but only reveals 𝑥 to the verifier
  

• Relation Ｒ: A function that defines the conditions under which a proof is valid:
  

In our context, H(w) is the cryptographic hash of the data shard. The prover must demonstrate that w corresponds to the correct data shard without revealing w itself.

ZKP Generation:

• The prover generates a proof π that demonstrates they possess a witness w such that.
  

• This proof π is then sent to the verifier.
  

Verification:

• The verifier checks the proof π by evaluating the function V(x,π) where V is the verification algorithm:
  

• If V(x,π) = True, the verifier is convinced that the prover holds the correct data shard, without learning anything about w.
  

8.3 Practical Application: Proof-of-Retrievability

Fragma storage nodes periodically generate ZKPs that prove they possess the correct data shards. This can be implemented via Proof-of-Retrievability (PoR) or Proof-of-Space (PoS) protocols, enhanced with ZKPs. The core principle is that the storage nodes prove their possession of the data without revealing its contents, thereby maintaining both privacy and security.