ArFleet dispute: Arweave builds its own IPFS, is it an innovation or a deviation from its original intention?

Once ArFleet was launched, there were many different opinions in the market. Some people thought it was a compromise and degeneration of the Arweave concept, while others saw it as a major technological breakthrough and the evolution of the decentralized storage ecosystem. However, to avoid blindly following these views, we first need to fully understand what ArFleet is.

This article will analyze in detail how ArFleet works, evaluate the effectiveness of its mechanism, and explore its impact on the Arweave ecosystem.

ArFleet Protocol Overview

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. At the same time, ArFleet relies on the decentralized AO computing environment to achieve automatic transactions and storage verification between multiple nodes, and the entire process does not require the intervention of a third party or centralized server.

In this decentralized “storage rental market”, there are two types of participants:

• Provider : A node that provides storage space and promises to store data for a specific period of time, that is, someone who rents out their own hard drive space.
• Client : An entity that has a need for data storage and is willing to pay for services, that is, a person or company that pays for storage services.

Both parties can freely negotiate and choose the payment method, not limited to any specific token. The payment is deposited into the ArFleet protocol, and the provider needs to pay a deposit and submit storage proofs regularly to ensure the integrity of the data. This mechanism does not require any third party to participate, thereby ensuring the trustworthiness of the system and ensuring that the interests of providers and clients are fairly protected.

In addition, the operational details of the ArFleet protocol are relatively complex, including how to ensure data redundancy and the mechanism for verifying storage proofs. We will explore these details in depth to help readers understand the operational process of ArFleet more comprehensively.

Detailed explanation of the ArFleet protocol operation process

The operation process of the ArFleet protocol involves multiple steps. It is like an automated storage service contract, from demand matching to data verification, ensuring that data is stored safely and reliably. Let’s disassemble its process step by step.

1. Customer places an order: complete task assignment

When users need to store data, they create a storage assignment through the ArFleet client software and set specific requirements:

• The amount you are willing to pay .
• The length of time to store (for example, 30 days).
• The level of redundancy (how many copies of data you want to have).

The client software will find storage providers that meet these requirements on the network. When a suitable provider is found and matched successfully, it is called "Storage Placement". The client will complete N matches based on the user's redundancy requirements (for example, if 3 redundancies are required, 3 providers need to be matched).

2. Market Query: Matching Providers

There is a global AO process called "Marketplace" in the ArFleet network for clients to query providers and the services they provide. Providers can publish, update, and delete service announcements in the market. Each advertisement contains at least the following key information:

• Protocol Version : Lists the ArFleet protocol version used by the provider to ensure compatibility.
• Contact information : Arweave wallet address (as provider ID), IP address and port pair.
• Storage Price : The provider's fee per unit of storage.
• Storage period : The storage period set by the provider.
• Authentication Challenge Period : The most frequent authentication period that the provider can handle (eg, once every 24 hours).

In other words, when clients use Marketplace to query and filter providers, the query criteria can include price range, storage duration, verification frequency requirements, etc. In addition, Marketplace is only responsible for listing qualified providers and their service information, and cannot fully guarantee the following situations:

• Whether the provider is online.
• Is there any storage space available?
• Whether the ad content is up to date.

Therefore, the client still needs to contact the provider directly to confirm their service status. If the provider is online and meets the requirements, the client will start the storage matching process.

3. Executing transactions: storage matching

Ideally, the state of a storage match would progress as follows:

• Creation and initialization : After matching begins, the client connects to the provider, sends a request and gets a confirmation.
• Data encryption and process creation : The data is split, encrypted, and a Merkle tree is generated to verify data integrity. At the same time, the network will start a dedicated AO process to record contract information.
• Fund injection and transaction acceptance : The client deposits the payment fee into the AO process named "Deal". After the provider confirms the transaction, the transaction is officially initiated.
• Data transmission and transaction completion : The encrypted data block is transmitted to the provider, and the provider completes the transaction setup. At the same time, the deposit is pledged to the AO process named "Deal" as agreed, and the transaction is officially completed.

When the above process is successfully completed, the storage matching phase ends and the system enters the data verification phase. But before discussing the verification mechanism in depth, we need to first solve a security problem faced by the ArFleet system - the Sybil attack.

As an open decentralized network, ArFleet is subject to the risk of Sybil attacks during storage matching. If it is "compromised", the ArFleet system will not be able to ensure high redundancy of data, thereby increasing the risk of data loss. This not only threatens the overall reputation of the system, but may also lead to a decrease in user trust. To solve this problem, ArFleet uses RSA encryption technology to prevent providers from disguising themselves as multiple nodes, thereby avoiding Sybil attacks.

RSA encrypted copy scheme

RSA is an asymmetric encryption algorithm that works with a public key and a private key pair: the public key is used to encrypt data or verify signatures, and the private key is used to decrypt data or generate signatures. However, ArFleet uses the reverse RSA operation: encrypt with the private key (similar to signing) and decrypt with the public key (similar to verification). This also means that each copy is encrypted by the customer using a different private key, and finally the provider uses the public key to decrypt the copy and provide it to the user.

As a result, ArFleet has formed a powerful defense mechanism:

• Generating a “legitimate” copy requires the customer’s private key, and even if the provider has the encrypted copy, the original data, and the public key, it cannot forge a new copy.
• The client uses a different private key to encrypt each copy, ensuring that each copy is unique. The provider's only option is to properly store each copy, otherwise the correct data block cannot be submitted during the verification process and the deposit will be lost.

4. Verification Challenge: Preventing Cheating

After the transaction is initiated, the network will periodically initiate verification challenges**, and the provider needs to continuously submit storage proofs throughout the transaction to prove that they are indeed storing data. The system will generate a string of random "0" and "1", which guides the provider to find the specified data block in the Merkle tree. "0" means going left from the current branch, and "1" means going right from the current branch. The provider follows the instructions until he finds the leaf node (that is, the specific data block).

To complete verification, providers need to submit two parts:

• Merkle path : contains the hash values of each layer from the root node of the tree to the target leaf node.
• Data block content : specific data corresponding to the leaf node.

These proofs are used to show that the data block does exist and is consistent with the root hash recorded by the system. Therefore, the provider may face three situations during the data verification phase:

• If the storage proof is valid : the network sends a reward to the provider.
• If the storage certificate is invalid or not submitted within the deadline : the provider's deposit will be deducted.
• If you fail to submit multiple times in a row : all deposits will be forfeited.

In the ArFleet protocol, the verification mechanism mainly prevents storage providers from cheating by deleting data through continuous random verification of small blocks of data. Specifically, this mechanism actually uses the principles of game theory to make providers face high risks in each challenge, ensuring that they have enough motivation not to delete data. Then the question arises: If a user stores 20 TB of data, and the system only checks a small block of 4 KB every 1-2 hours, can it really detect the provider's cheating?

Why does the verification mechanism work?

The effectiveness of this verification mechanism can be explained through a simple example. Suppose a provider attempts to delete 1/4 of the data (5 TB) from 20 TB of data to free up storage space. The probability that they will be caught by the system is as follows:

It can be seen that as the number of verifications accumulates, the risk of cheaters increases and they will almost certainly be discovered in the end. The reasons why this verification mechanism can effectively prevent cheating can be roughly summarized as follows:

• Randomness : During each verification, the system randomly selects data blocks for inspection, and the provider cannot predict which blocks will be checked.
• Cumulative risk : As the number of challenges increases, the probability of being discovered increases rapidly, and even deleting a small amount of data will result in a high risk.
• The economic consequences are serious : once the verification fails, the deposit will be deducted, and multiple failures may result in the confiscation of the deposit. The loss of the deposit will be far greater than the benefits of releasing storage space, and the provider will be more willing to store all data according to the agreement rather than risk cheating.

How does ArFleet complement the Arweave ecosystem?

ArFleet combines with Arweave to build a dual storage system, providing users with temporary and permanent storage options. Users can flexibly adjust storage strategies based on the importance and usage scenarios of the data to achieve efficient management.

For developers, the temporary storage solution provided by ArFleet greatly reduces storage costs, especially for data that does not need to be stored for a long time. This flexibility can effectively reduce storage pressure and related costs. For ordinary users, data can be flexibly managed according to personal needs. Regardless of the type of user, when long-term storage is required, temporary data can be stored in Arweave with one click to ensure long-term access.

ArFleet's temporary storage has faster access speed and data exchange efficiency, which is suitable for scenarios with high-frequency data flow. Through the dual storage system, ArFleet plays a complementary role in the existing Arweave ecosystem, especially in the following application scenarios:

• Collaborative document editing : When multiple people are editing a document in real time, only the final version needs to be saved, and temporary data from the editing process can be placed on ArFleet without having to be permanently stored.
• GameFi : Arweave can store key information such as game assets, codes, and player data, while ArFleet can store temporary status during the game, player interaction data, etc., to improve game performance and response speed.
• Decentralized video platform : Arweave is responsible for long-term preservation of video content to ensure its permanent availability. ArFleet is similar to CDN, used to cache popular videos and reduce bandwidth consumption for repeated visits.
• Large-scale data migration : ArFleet’s temporary storage function is suitable as a transit storage when gradually migrating large amounts of data to Arweave. It performs particularly well in scenarios where large files need to be saved for a short period of time, ensuring a smooth migration process.
• Application settings synchronization : User settings (such as application preferences) are stored on ArFleet and can be synchronized between multiple devices without having to permanently save each modification.
• Decentralized identity management system (DID) : Arweave can store important data such as user identity information, certificates and credentials, while ArFleet can store temporary data such as user access tokens and session information.

The combination of ArFleet and Arweave not only greatly enhances the flexibility and efficiency of storage, but also provides strong support for building various applications, helping developers create more diverse and efficient applications.

Summarize

The launch of ArFleet does not mean a compromise or regression of Arweave, but a positive response to the market's storage needs. ArFleet not only forms a complementary relationship with Arweave, but also collaborates with AO to jointly build a truly full-stack decentralized network.

In this system, ArFleet provides flexible short-term storage, Arweave focuses on permanent storage, and AO is responsible for decentralized computing. The three complement each other to form an efficient and scalable solution, creating a complete ecosystem with both permanent and short-term storage, which can lay a solid foundation for the future decentralized Internet.