The ArFleet Debate: Breakthrough Innovation or Departure from Arweave's Permanent Storage Vision?

Abstract

ArFleet is a decentralized temporary storage protocol that establishes a trustless storage marketplace, allowing users to purchase time-limited storage services on demand. The protocol leverages RSA encryption and a random verification mechanism to effectively prevent Sybil attacks and ensure providers behave honestly. Together, ArFleet and Arweave form a dual storage system, offering users flexible short-term and permanent storage solutions to meet various data storage needs. Potential use cases of the ArFleet protocol include collaborative document editing, game state synchronization, and large-scale data migration. ArFleet collaborates with Arweave and AO to jointly build a truly fullstack decentralized network, laying a solid foundation for the future decentralized Internet.

Author: Kyle

Translator: Kyle

Reviewer: Marshal Orange

Source: Content Guild - Research

The release of ArFleet has sparked significant debate. Some see it as a departure from Arweave's vision of storage, while others view it as an important technical breakthrough — a step forward for decentralized storage. But before taking a side, it's important to understand what ArFleet is all about.

This article provides an in-depth analysis of how ArFleet operates, evaluates the effectiveness of its mechanisms, and explores its impact on the Arweave ecosystem.

Introduction to the ArFleet Protocol

ArFleet is a decentralized temporary storage protocol that builds a storage market without intermediaries. In simple terms, it allows users to purchase time-limited storage services on demand. Using the AO decentralized computing environment, ArFleet automates transactions and storage verification across multiple nodes, eliminating the need for third-party intermediaries or central servers.

This decentralized “storage rental marketplace” involves two types of participants:

Provider: Nodes that offer storage space for a specified period, renting out their local storage.
Client: Entities that need storage and are willing to pay for it, such as individuals or companies purchasing temporary storage services.

Payments can be made using any method both parties agree on, without being limited to specific tokens. The funds are stored within the ArFleet protocol, while providers must submit collateral and periodically provide proof of storage to ensure data integrity. This mechanism eliminates the need for third-party involvement, creating a trustless system that fairly protects both providers and clients.

Furthermore, the ArFleet protocol involves intricate operational details, including methods for ensuring data redundancy and mechanisms for validating storage proofs. In the following sections, we’ll explore these details to provide a comprehensive understanding of how the ArFleet protocol functions.

How ArFleet Operates: A Step-by-Step Breakdown

ArFleet's operation works like an automated storage contract. It ensures that data is securely stored, from matching storage requests to verifying the data’s presence.

1. Client Assignment: Completing Task Allocation

When users need storage, they create a Storage Assignment using the ArFleet client software, specifying details like:

Amount they are willing to pay.
Storage duration (e.g., 30 days).
Redundancy level (e.g., the number of data replicas required).

The client software searches for providers that match these criteria. If the redundancy requirement is three replicas, the software matches the user with three suitable providers. This process is known as Storage Placement.

2. Market Query: Finding Providers

ArFleet includes a global AO process called the Marketplace, where clients can search for providers and their services. Providers post, update, and delete Announcements, which include the following details:

The version of the ArFleet protocol they are using.
Contact information, such as their Arweave wallet address, IP address, and port pairs.
The prices they offer for storage.
The duration limits placed on new deals.
The verification challenge duration limits placed on new deals.

While the Marketplace allows clients to filter providers based on price, duration, and proof submission frequency, it cannot guarantee:

A provider’s online status.
Available storage space.
Whether advertisements reflect the most recent information.

Clients are still responsible for contacting providers directly to confirm their availability. Once a provider meets the client's requirements, the Storage Placement process begins.

3. Executing Deal: Storage Placement

The storage matching process unfolds as follows:

Creation and Initialization: The client sends a request to the selected provider, who confirms it.
Encryption and Process Spawning: Data is encrypted and divided into chunks, forming a Merkle tree to verify data integrity. An AO process is spawned to encapsulate and execute the deal contract.
Funding and Deal Acceptance: The client deposits the payment into an AO process called “Deal.” Once the provider confirms the transaction, the deal is officially initiated.
Data Transfer and Deal Completion: Encrypted data blocks are transmitted to the provider, who finalizes the transaction setup. Simultaneously, the provider deposits the agreed-upon collateral into the Deal AO process, marking the official conclusion of the deal.

Upon completion, the system transitions into the proof-of-storage verification phase. Before diving into the verification process, however, let’s address a key security risk—Sybil attacks.

RSA Encryption Replica Scheme

RSA is an asymmetric encryption algorithm using a public-private key pair. Typically, the public key encrypts data or verifies signatures, while the private key decrypts data or generates signatures. However, ArFleet uses an inverted RSA approach: the client encrypts each replica with a private key (similar to signing), while the provider decrypts it with the public key (similar to verification). This method ensures that each replica is uniquely encrypted by the client, with the provider using the public key to verify and deliver the replica to the user.

This setup strengthens ArFleet’s defense mechanisms:

Only the client’s private key can generate a valid replica. Thus, even if the provider has access to the encrypted replica, original data, and public key, they cannot forge new replicas.
The client encrypts each replica with a unique private key, ensuring distinctiveness. This leaves the provider with one option: securely store each replica, as failing to present the correct data blocks during verification results in the loss of their deposit.

4. Verification Challenges: Preventing Cheating

Once the Deal begins, verification challenges are automatically triggered by the Deal process at predefined intervals. Providers must submit valid verification proofs to demonstrate that the data remains intact. These challenges involve:

Merkle paths: The hash sequence from the Merkle tree’s root to the target leaf node (data block).
The chunk data: The specific data corresponding to the leaf node.

The goal is to prove that the data block exists and matches the root hash stored on the network. Depending on the outcome, the provider faces the following scenarios:

Valid proof: The provider receives rewards.
Invalid or missed proof: A portion of the collateral is forfeited.
Repeated failures: The entire collateral is lost.

While only small portions of data (e.g., 4 KB blocks) are checked at a time, ArFleet’s randomized challenges ensure that providers are highly likely to be caught if they attempt to delete or neglect stored data.

Why Is the Verification Mechanism Effective?

The effectiveness of this verification mechanism can be explained through a simple example. Suppose a provider deletes 25% of the stored data to save space. The probability of avoiding detection decreases with each challenge:

Number of Challenges	Probability of Not Getting Caught	Probability of Getting Caught
1	75%	25%
2	56.25%	43.75%
3	42.19%	57.81%
4	31.64%	68.36%
...	...	...
20	0.32%	99.68%

This example shows how repeated verification significantly increases the risk for providers attempting to cheat. The system’s effectiveness lies in:

Randomization: Providers cannot predict which data blocks will be checked.
Accumulating risk: The probability of being caught increases with each challenge.
Severe penalties: The financial consequences of failure far outweigh the benefits of cheating.

How ArFleet Complements the Arweave Ecosystem

ArFleet works with Arweave to create a dual-storage system, offering users both temporary and permanent storage options. This allows users to flexibly adjust their storage strategies based on the importance and use cases of their data, enabling more efficient management.

For developers, ArFleet's temporary storage solution helps cut costs, especially for data that doesn't need to be kept long-term. This flexibility reduces storage pressure and cuts associated costs. Regular users can also manage their data based on their needs. When long-term storage is needed, temporary data can be moved to Arweave with a single click, ensuring permanent access.

ArFleet’s temporary storage offers faster access speeds and higher data exchange efficiency, making it ideal for scenarios involving frequent data transfers. Through the dual-storage system, ArFleet complements the Arweave ecosystem, excelling in the following use cases:

Collaborative Document Editing: During real-time collaborative editing, only the final version needs to be saved. Temporary data from the editing process can be stored on ArFleet without requiring permanent storage.
GameFi: Arweave can store essential assets, code, and player data, while ArFleet handles temporary game states and player interaction data, improving game performance and responsiveness.
Decentralized Video Platforms: Arweave ensures the permanent availability of video content, while ArFleet functions like a CDN, caching popular videos to reduce bandwidth consumption from repeated access.
Large-Scale Data Migration: ArFleet’s temporary storage serves as an intermediate layer for migrating large datasets to Arweave incrementally. It’s particularly useful for short-term storage of large files, ensuring a smooth migration process.
Application Settings Synchronization: User preferences, such as app settings, can be stored on ArFleet for synchronization across multiple devices, without the need for permanent storage of each change.
DID Management: Arweave stores user data, such as identity information, certificates, and credentials. Meanwhile, ArFleet stores temporary data like access tokens and session information.

Combining ArFleet and Arweave boosts storage flexibility and efficiency while providing strong support for building a variety of applications, empowering developers to create diverse and effective solutions.

Conclusion

The launch of ArFleet isn't a step back or a compromise for Arweave; it's a thoughtful response to the growing demand for diverse storage solutions. ArFleet seamlessly complements Arweave and works in tandem with AO to build a truly full-stack decentralized network.

In this ecosystem, ArFleet provides flexible short-term storage, Arweave ensures reliable permanent storage, and AO powers decentralized computation. Together, they form an efficient, scalable solution, creating a well-rounded storage ecosystem that integrates both temporary and permanent options — paving the way for the future of a decentralized internet.