Storage Nodes


4EVER-STORAGE (a client containing Cluster Service and IPFS nodes) is compatible with the IPFS protocol and automatically forms a cluster of nodes (Swarm) as a result of the Smart Contract modules' node auction. Nodes can synchronize content with each other and persist specific content in storage.

Cluster service

Every node follows the same peer-to-peer network protocol. These nodes will automatically form a Swarm network which can be read in the node auction contract and then synchronize data with each other. Any node can synchronize data from the Swarm network.

4EVERLAND follows an additional protocol and stores specific data persistently. These stored data are challenged by Proof of Storage constantly: honest behaviors will be rewarded and malicious behaviors punished.

Node data management

In the 4EVERLAND storage network, since the developers should pay the cost through Ethereum smart contracts, the node needs to know which data CID needs to be stored locally by monitoring an on-chain payment event through the payment contract address and then store it according to the transaction field related to the CID.

The PoSC data of nodes are then synchronized, the data being the key factor to judge whether the node should be punished.

Storage provider capacity expansion

4EVERLAND uses Swarm technology to form a large storage network. Therefore, it is very important to support the scalability of node storage capacity in the 4EVERLAND network.

4EVERLAND utilizes LVM (Logical Volume Manager) technology to achieve this goal. The capacity of the entire storage space can be dynamically adjusted through PV (physical volume), where PV addition and LV management are controlled by VG (volume group). Storage providers can easily add physical disks at the PV level to expand capacity. The provider's storage management logic is as follows:

Proof of storage

4EVERLAND data layer is a global data synchronization network built on IPFS protocol with distributed nodes in which data is constructed and synchronized through the swarm network. Since data availability and integrity are the critical factors of the 4EVERLAND incentive component, the Proof of Storage mechanism needs to address the following issues:

  • The node synchronizes and stores data submitted by Swarm Network users.

  • The pinned data needed by users can be obtained from a 4EVERLAND node at any time.

Therefore, 4EVERLAND proposes the PoSC based on TEE technology to verify the reliability of nodes data.

The PoSC based on TEE

Data will be synchronized between nodes through the IPFS data synchronization mechanism. The purpose of the 4EVERLAND PoSC mechanism is to verify the data consistency of all nodes that are in the same swarm network. Usually, the PoSC mechanism will be used as below:

  • 4EVERLAND node's data availability should be verified before it participates in the node auction.

  • Nodes accept PoSC requests at a random moment during their running time.

To ensure that the nodes in the data network all run following the same challenge logic, the 4EVERLAND PoSC mechanism will utilize the Trusted Execution Environment technology(TEE), such as SGX of Intel. Each node stores the PoSC program in a TEE environment. In the TEE execution environment of each node, there are two main phases:

  • The TEE node running the PoSC program participates in the network.

The node's TEE program will have a mutual authentication process with the node which is already in the network by its hardware certificate information and measurable program information.

  • The TEE network verifies and synchronizes the challenge data issued by other different nodes.

The program running in the node's TEE environment will continuously follow the rules of PoSC. After the challenge request is finished locally, the node sends the challenge request data and result to the TEE executable network.

The nodes in the other TEE trusted environments will verify the request signature and follow the same logic within the node TEE to compute and synchronize the related challenge request data locally.

Assume that there is node A in the network that will place the storage challenge StorageProof program in the TEE for execution. The storage data synchronization network is outside the trusted execution environment, and whenever the local 4EVERLAND data store synchronizes data locally by accepting pin requests, the StorageProof program of Node A will record the data related to the storage network (e.g. cid, merkle, etc.) through the OCALL interface of TEE Enclave.

PoSC request will be sent to the node by a heap of random CIDs to confirm that the node has persistently stored the data. After the verification request is completed, the StorageProof program will send the data related to this challenge request to the other TEE networks of nodes B and node C.

After receiving this request, the TEE Proof of Storage program of other nodes will verify the legitimacy of the challenge request using the node's public key. If the signature is legitimate, it will store the information about the challenge locally. As shown in the figure:

To deal with challenge requests in the TEE network, nodes will synchronize the challenge request data with each other. 4EVERLAND will count the challenge behaviors of the node group, including the number of requests, request parameters, request results, and other information, and display these information to the community. These indicators are key factors to the ecosystem of node reward and punishment mechanism.

You can sign up for a free 4EVERLAND account to get started today.

If you have any questions, please join our Discord server, or send us an email at

Last updated