WeSendit Nodes: The Concept

Every node needs a key to start working and participate in the ecosystem. Your access key to enable the node ecosystem, is the ERC721 (NFT) you receive in your wallet after you stake.

The participants:

WeSendit MasterNodes

WeSendit MasterNodes are powerful and specialized nodes in the network that play an important role in file transfer. Their main purpose is to ensure a fast and efficient upload process for users.

As soon as a user uploads a file, it is first sent to the WeSendit MasterNodes. There, the file is compressed to optimize transfer time and storage space requirements. Compression is performed using advanced algorithms to achieve the most efficient compression possible without data loss.

This step helps improve transmission speed while reducing resource requirements.

After compression, the file is forwarded to the node balancer, which is responsible for further processing and distribution to the nodes in the network. The WeSendit MasterNodes thus serve as a central hub for the upload process and play an important role in optimizing file transfer.

By using dedicated MasterNodes, WeSendit can ensure that the upload process is fast and reliable, regardless of the number of users and file size. The MasterNodes are powerful and highly available to ensure a seamless user experience.

In addition, WeSendit MasterNodes are also responsible for checking files for viruses and applying security measures to ensure the integrity of the transferred data. They play a crucial role in protecting the privacy and security of user data.

Overall, the WeSendit MasterNodes are an essential part of the decentralized network, as they enable fast and efficient file transfer while ensuring the security and integrity of the data. Through their performance and specialization, they contribute significantly to the smooth functioning of the WeSendit network.

After encryption, each part of the file is assigned a hash code. This code is then used by the indexer to track the location of each part throughout the WeSendit infrastructure. This ensures that the file parts can always be found and correctly assembled if the user wishes to retrieve the file at a later time.

Node Balancer

The Node Balancer has an extensive database of all registered nodes on the network. It regularly indexes and monitors the available nodes to ensure that they meet the requirements and operate reliably. The nodes are evaluated and classified according to criteria such as availability, response time/ping and speed of data transfer.

When the MasterNode reports a file for storage, the Node Balancer contacts the nodes to initiate the upload process. In doing so, it takes into account the current load of the nodes and ensures an even distribution of upload requests in the network.

This load distribution ensures that no node is overloaded and that an optimal transmission speed is achieved.

The node balancer also acts as a source of information for other components of the network. It stores the current storage capacities of the nodes to ensure that the available storage space is used efficiently. It also regularly updates the status of the nodes [Mainnet / Testnet

/ Checknet] to ensure that only reliable and active nodes participate in the file transfer.

Indexer

The Indexer is a powerful database server in the WeSendit network that plays a central role in managing and linking data to the corresponding nodes. Its main task is to link hashes of files to their corresponding nodes in order to know which data is located on which nodes and in which storage blocks.

The indexer acts as a kind of intermediary between the users and the nodes by managing and monitoring the file distribution information. It stores the mapping of the hashes to the corresponding nodes in its database, allowing efficient access to the stored files.

The indexer regularly checks whether all indexed files are available and accessible on the nodes. If a node fails and a file is no longer available, the indexer automatically takes action. It distributes the file in question to other available nodes to ensure that the data remains accessible.

At the same time, the wrong index of the failed node is deleted and the node itself is downgraded to the testnet to check its reachability.

Another important function of the indexer is the verification of data integrity. By using checksums, the indexer regularly compares the files stored on the nodes with the original hashes. If a file has been modified or tampered with, the node in question is blacklisted and the node’s stake is locked. This mechanism ensures that the data remains unaltered and that only trusted nodes participate in the network.

Node

The nodes form the most important basis for the decentralized WeSendit network and provide the storage space for the uploaded files. They serve as data storage and allow users to store and access their files securely and reliably on the network.

Each node provides packets of 1 GB of storage each to cover the need for different file sizes and types. The nodes are managed by the

Node operators and meet certain requirements, including a stable Internet connection around the clock and a minimum data transfer rate of 40 Mbit (5 MB per second).

The nodes actively participate in the network and offer their storage capacity for file transfer. They receive upload requests from the node balancer and securely store the uploaded files. The files are organized into special storage blocks and havehed to ensure data integrity.

As participants in the network, the nodes are subject to various evaluation criteria, such as availability, response time/ping, and speed of data transfer. These criteria are monitored and evaluated by the node balancer to ensure that the nodes operate reliably and meet the requirements of the network.

The nodes in the WeSendit network are classified in different networks: Checknet, Testnet and Mainnet. In Checknet, all nodes are registered, while Testnet and Mainnet must meet stricter criteria to be classified as trusted and high-quality nodes.

Nodes are responsible for keeping uploaded files secure and responding to download requests.

Blacklist

The blacklist reviews reported data and performs rechecks to determine if the data has been altered. It aims to detect technical changes

and to exclude old versions. This helps to ensure that the stored files are unaltered and available in their current version.

If a node is found to have intentionally modified the file, the blacklist takes action. The stake of the node in question is shortened (lashed) and the node is permanently blacklisted. These sanctions are used to protect the network from fraudulent activity and to ensure that only trusted nodes participate in the network.

The lashed stake is sent to the reward pool and thus increases the total rewards distributed to the node operators. This mechanism creates incentives for node operators to follow the rules and operate their nodes properly.

It is important to note that the blacklist is not based on IP addresses, but on hardware IDs. This ensures that nodes with a new IP address cannot simply reconnect to the network.

This reduces the possibility that an operator blacklisted for misbehavior will bypass the system by logging in with new identities.

The decision to remove nodes from the blacklist rests with the CTO. Node operators who end up on the blacklist have the option to request a personal review. This allows them to explain their case and, if necessary, remove their node from the blacklist, provided they meet the required conditions and can restore confidence in its integrity.

Overall, the blacklist plays an important role in maintaining data integrity and compliance with network rules in the WeSendit network. Through its actions, it protects the network from fraudulent activities and contributes to the security and trustworthiness of the system.

The networks:

The WeSendit nodes run across three networks.

1. Checknet
2. Mainnet
3. Testnet

Checknet

The checknet contains all nodes that have been registered in the last 7 days.

The nodes are classified with a “score”.

The score is generated on the basis of three key characteristics.

• Availability (50%)
• Response time / Ping (30%)
• Speed data transfer (20%)

When a score of at least 80% is reached, a node is transferred to the testnet. Every half hour (24x daily) each node from the testnet is checked.

In the checknet, nodes do not receive rewards.

Testnet

All nodes with a score below 90 and permanent availability (99%) are in the test net. The score is created on the basis of three key characteristics.

• Response time / Ping (30%)
• Speed data transfer (40%)
• Memory throughput I/O (30%)

With a score >= 90, which a node must guarantee for 30 days, a node is transferred to the mainnet.

The testnet is also a duplication of the mainnet. Each file from the mainnet is also stored on nodes in the testnet. The testnet thus also serves as security for the mainnet.

Mainnet

Only nodes with scores above >= 90 and permanent reachability (99.80%) are located in the mainnet.

The score is generated on the basis of three key characteristics.

• Response time / Ping (30%)
• Speed data transfer (40%)
• Memory throughput I/O (30%)

The processes:

Upload

The WeSendit service starts with the user uploading files via the browser or an app. These files first land on a WeSendit MasterNode. This MasterNode has the task of compressing the uploaded files and splitting them into ten fragments. Once the compression process is complete, the MasterNode informs the node balancer that data is ready for transmission.

The node balancer then comes into play. As soon as it receives a request to transmit data from a MasterNode, it begins to randomly select free memory locations and allocate them to the data fragments. The data is stored three times in the mainnet and once in the testnet.

Thus, with ten data packets, the balancer requires forty memory locations. If the amount of data exceeds the available storage space of the WeSendit nodes, the balancer falls back on external Web3 projects such as Storj to store the excess data there.

Finally, the nodes come into play. Once they receive an allocation from the node balancer, they download the allocated data and store it in the designated locations. Once the download is complete, the node informs the indexer that the upload was successful.

In this way, the WeSendit system ensures that all uploaded data is properly stored and indexed, with extensive redundancy helping to ensure data integrity and continuous availability.

Download

When a user wants to download data, the process starts with the request to the indexer, which is triggered by the call to the website. The indexer searches for the requested data in its index and contacts all associated nodes. In this process, the nodes with the best response time are determined in real time and the download process is started at the user’s site. During this process, the data packets are merged so that the user ends up with a single zip file.

After the download is successfully completed, the rewards, also known as “rewards”, are calculated. All these rewards are stored in a database. The amount of the incentive depends on the score set by the node balancer.

To give a concrete example: Suppose there are three mainnet nodes with scores of 95, 85, and 80, and one testnet node with a score of 70. If the total reward for the successful download is 1 WSI, the distribution of the reward based on the scores would be as follows:

The total score is 358 (95+93+90+80).

Node 1 with a score of 95 would receive 27% of the total reward, which is equivalent to 0.27 WSI (95/358 * 1 WSI).

Node 2 with a score of 93 would receive 26% of the total reward, or 0.26 WSI (93/358 * 1 WSI).

Node 3 with a score of 90 would receive 25% of the reward, i.e. 0.25 WSI (90/358 * 1 WSI).

And finally, the Testnet Node with a score of 80, would receive 22% of the reward, or 0.22 WSI (80/358 * 1 WSI).

In this way, the WeSendit system ensures that those nodes that contribute to the accessibility and fast access to the data are appropriately rewarded. The amount of the reward is determined by the score achieved by the nodes, which in turn is a function of their performance and reliability.

Schematic view (in German)

Technical details:

WeSendit MasterNode

The WeSendit Masternode is developed using the Go programming language, which is known for its efficiency, strong performance and simplicity. Go is particularly well suited for network applications and enables efficient and secure handling of processes and threads, which is crucial in this context.

The masternode implements a RESTful API that allows uploading and downloading files, interacting with the node balancer and other necessary functions. The API is developed using the “net/http” package built into Go, which provides rich functionality for developing HTTP servers and clients.

When a file is uploaded to the masternode, it is first compressed using Go’s “compress/gzip” package. This package provides functions for reading and writing gzip- compressed data.

After compression, the file is split into several parts using a utility written in Go that works similarly to the Unix “split” tool. Each part of the file is then encrypted individually. The encryption is done with Go’s “crypto/aes” package, which implements the AES encryption algorithm.

Once the file is split and encrypted, it is stored in the masternode’s file system. The path information and metadata of the file are stored in a

PostgreSQL database managed with Go’s “database/sql” package and a PostgreSQL driver like “lib/pq” or “pgx”.

The master node then communicates with the node balancer via the RESTful API to communicate the availability of the new file fragments. The node balancer then distributes these fragments among the various nodes in the WeSendit network.

Based on the Go platform, the WeSendit Masternode is capable of efficiently and securely processing complex tasks such as file compression, splitting and encryption.

The database structure for the WeSendit Masternode could look like this: Table: Files

• ID (primary key): A unique identifier for each uploaded file.
• File hash: hash of the file name that will be encrypted.
• File size: The size of the file.
• Upload time: The time when the file was uploaded.

This table stores basic information about each uploaded file. Each entry represents one file. Table: Fragments

• ID (primary key): A unique identifier for each fragment.
• File_ID (foreign key): A link to the entry in the Files table to which the fragment belongs.
• Fragment number: The number of the fragment within the file.
• Storage status: The status of the fragment, e.g. “Waiting”, “Processed”, “Transferred”.

This table stores information about the individual fragments of each file. Each entry represents one fragment. The File_ID is a foreign key that refers to the ID in the Files table.

Using this database structure, WeSendit Masternode can efficiently store and manage information about uploaded files and their fragments. As a result, it is able to properly perform the upload process, fragmentation and storage of files, and ensure reliable data management.

Node Balancer

The Node Balancer receives the requests from the MasterNode and starts the process of allocating file fragments to different nodes in the network. To ensure efficient and balanced distribution of the data load, the node balancer uses a specially developed algorithm.

This algorithm works with controlled randomness, where nodes are selected randomly, but taking into account certain parameters such as their current workload, available memory and network bandwidth. This means that every node has a chance of being selected, but nodes with more available resources have a higher probability. This ensures that the load is distributed across the entire network while achieving optimal resource utilization.

Once the node balancer has selected the appropriate nodes, it checks whether there is enough storage space to hold the file fragments. If not, and the amount of data exceeds the available storage on the WeSendit network, the balancer activates a process to request additional storage from external service providers such as Sia or Filecoin.

In the case of such an external storage request, the balancer generates a unique hash for each file fragment to be stored. This hash serves as a reference point and enables the node balancer to identify each file fragment and track its location, regardless of whether it is stored within the WeSendit network or on an external platform.

Through these processes, the Node Balancer ensures that file fragments are efficiently and reliably distributed across the network and that all files, regardless of size, can be stored securely and accessibly.

The Node Balancer database plays a crucial role in managing the nodes and storing the information about the file fragments and their locations.

Here is a suggestion for a possible database structure:

Table Nodes:

• node_id: unique ID for each node in the network (primary key)
• node_status: Current status of the node (active, inactive, maintenance, etc.)
• available_space: Current available space in the node
• network_bandwidth: Current network bandwidth of the node
• last_ping_time: Last response time of the node to a ping test.

FileFragments table:

• fragment_id: Unique ID for each file fragment (primary key).
• file_id: ID of the file to which the fragment belongs
• fragment_size: size of the file fragment
• hash: Unique hash of the file fragment for the external storage.

FragmentLocations table:

• location_id: Unique ID for each location (primary key).
• node_id: ID of the node on which the fragment is stored (foreign key, refers to node_id in the nodes table)
• fragment_id: ID of the fragment stored at this location (foreign key, points to
• fragment_id in the FileFragments table).
• external_storage_hash: hash of the file fragment if it is stored on external storage

In the Go programming language, the database schema could be defined using the ORM (Object-Relational Mapping) package GORM.

This scheme allows the node balancer to efficiently manage and track nodes and file fragment locations. It also allows easy identification and retrieval of file fragments stored on external storages based on their unique hash.

Node

The node is programmed in Go and consists of various modules and functions that are required for the operation of the node. When the node is initialized, the required dependencies and configurations are loaded.

The node communicates with the node balancer via defined interfaces (APIs) to receive instructions and exchange information. An API request is used to retrieve the assignments from the node balancer. The received assignments contain information about the file fragments that the node should store.

After receiving the assignments from the node balancer, the node receives the file fragments via a data connection (e.g. TCP/IP). The received file fragments are stored on the node’s local storage. Storage can be in special memory blocks to facilitate organization and access to the data.

After a file fragment is successfully downloaded and saved, the node sends a message to the indexer. The message contains information about the node, the saved file fragment and possibly other relevant data. Communication with the indexer is done via a defined API interface.

The node contains mechanisms for error detection and handling. In case of errors or failures, the node can take appropriate actions, such as re-requesting the node balancer or recovering data from other nodes.

During operation, the Node logs important events, errors and information in log files. This enables tracking of activities and error analysis when needed.

The Node is able to use a database to store and manage various information. A possible database structure for the node includes tables such as the node table, the allocations table, and the log table. The node table contains information about each node, such as its ID, IP address, available memory, response time, speed, and availability. The allocations table is used to track the allocated file fragments for each node. The log table is used to log important events, errors and information.

The initialization process of the node starts with loading the configuration, in which various settings for the node are defined. These include, for example, connection information to the node balancer and the indexer. A connection to the smart contract is then used to check whether the required stake for operating the node is available. This is done by comparing the node address with the address stored in the smart contract and checking the paid-in stake.

After successful verification, the node registers with the node balancer and indexer. A connection is established to retrieve information about current file fragments and allocations. The node provides the node balancer and indexer with relevant information such as IP address, storage capacity, response time and speed in order to be integrated into the system.

During operation, the node periodically updates its state and available resources to provide the node balancer and indexer with an up-to-date view of its performance. The node receives allocations from the node balancer containing the file fragments to be downloaded and saved. The node then begins downloading and saving the file fragments to local storage.

Indexer

The indexer plays a crucial role in the WeSendit network. This controls and manages the links between the stored file fragments and the storing nodes. The indexer is also responsible for monitoring the availability and integrity of the files stored on the nodes.

The main functions of the indexer include:

1. The management of a database that stores information about all stored files and associated nodes.
2. Performing regular checks on the nodes to ensure that the allocated file fragments are always available.
3. Communicating with the node balancer to ensure that new nodes are added and unavailable or non-compliant nodes are removed from the network.

The indexer’s database could be structured as follows:

• Files table
• FileID (Unique identification of the file)
• FileName (name of the file)
• FileSize (size of the file)
• Checksum (SHA256 hash of the file to verify integrity).
• Fragments table
• FragmentID (Unique identification of the fragment)
• FileID (link to the file to which the fragment belongs).
• NodeID (connection to the node that stores the fragment).
• FragmentSize (size of the fragment)
• FragmentChecksum (SHA256 hash of the fragment to check integrity).
• Nodes table
• NodeID (Unique identification of the node)
• NodeScore (rating of the node)
• AvailableStorage (Available storage space on the node)

When a file is uploaded, the indexer receives the information about the file and the nodes involved from the node balancer. The indexer stores this information in

of its database and performs regular checks to ensure the availability and integrity of the files.

To check the availability of the files, the indexer sends ping requests to the nodes. If the node does not respond within a period of 2–3 seconds, it is considered unavailable. In this case, the indexer informs the node balancer, which then allocates a new node to store the missing file fragment.

To check the integrity of the files, the indexer can calculate a checksum (SHA256 hash) of the file fragments. This checksum is compared with the checksum stored in the database. If the checksums are not

match, this means that the file fragment has been modified. In this case, the node in question is blacklisted and the node balancer is informed to save the file fragment on a new node.

Checking data integrity on another server is technically challenging and not feasible for the indexer for performance reasons. On the nodes, it compares the data with checksums. The checksums contain encrypted data such as the size and modification date. If a file does not pass the test, the node with the respective data packet is written to the blacklist using the REST API.

Blacklist

The blacklist server serves as a central instance for managing all nodes that have violated the network rules.

The blacklist server will also be written in Go to ensure compatibility and efficiency across the network. It can provide a REST API to communicate with other components of the WeSendit network.

The blacklist server database could have the following structure: Table: BlacklistedNodes

• NodeID (string, unique identification of the node)
• FragmentID (string, unique identification of the files)
• DateOfBlacklisting (timestamp, date and time when the node was blacklisted)
• Status (string, “reported”, “under review”, “confirmed”)

To perform a final check of the change, all copies of the data fragment from the remaining three nodes are uploaded to the blacklist server and compared. If no discrepancy is found, the node is removed from the blacklist.

If a mismatch is detected, the node remains on the blacklist with the status confirmed and the node’s stake is deposited to the reward pool.

Node operator

In order to act as a node operator in the WeSendit network, certain system requirements are necessary to ensure that the node can operate effectively and store data securely and reliably.

Please note that these requirements are only minimum requirements. Depending on the amount and type of data to be stored, it may make sense to have a system with higher specifications. In addition, higher Internet speed and larger storage capacity may increase the likelihood of being able to store more data and thus earn higher rewards.

Storage space

Even with as little as 1 GB of available storage, you can run a node and earn rewards in the form of WSI tokens for providing the storage.

Internet connection

A stable Internet connection around the clock (24/7) is essential to ensure continuous availability of the data and to be able to record new data packets promptly. In addition, the data transfer rate should be at least 10 MB/s to ensure efficient data transfer.

Operating system

Nodes can be operated on a Linux system. Ubuntu 22 LTS is recommended for this, as this operating system is particularly suitable due to its stability and user-friendliness.

Hardware

As far as the hardware is concerned, the requirements are quite moderate. Even a Raspberry Pi with 8 GB RAM is sufficient to run a node. This makes it possible even for users with simpler systems to participate in the WeSendit network and contribute to the decentralized storage of data.

• 2 Cores
• 4 threads
• 8 GB RAM
• 180 MB/s DWS
• 240 EPS Min. Requirements 25 Mb down/up speed
• VPS and ARM64 compatible

Stake

Each node operator must participate in WeSendit Staking. For this purpose, there is a separate entry point at the smart contract for locking for 52 days.

Rewards and Fee Distribution

The WeSendit network offers a transparent and lucrative reward structure for node operators to ensure the security, availability, and integrity of the network. As a recognition for their commitment and participation, node operators receive regular rewards in the form of WSI tokens, allocated based on their active role in the network and the resources they provide.

The reward structure is based on an innovative 3% fee structure that applies during the unstaking process. It is essential to note that these fees are not directly related to the concept of nodes but serve as an additional incentive to encourage active community participation and further enhance the network.

The fees are designed to provide incentives for active node runners while discouraging bots and APY hunters. 0.75% goes to all active users and is allocated to the activity pool and the referral pool. The remaining 1.5% is dedicated to all node runners who contribute to the continuous growth of the ecosystem.

Activity Pool

The Activity Pool serves as an incentive for users who contribute to the improvement and advancement of the WeSendit network. 0.75% of the staking contributions flow into the Activity Pool, which is dedicated to innovative developments within the WeSendit network. WeSendit Pro and Premium users, as well as developers, can apply for financial support from this pool to drive projects that enhance the performance, security, and user-friendliness of the Web3 Transfer and Storage WeSendit platform. They also receive rewards for their activity related to data storage. When funding projects from the Activity Pool, transparent criteria are applied, and the decisions are made democratically through community voting.

Referral Pool

The referral program is a crucial component of community building and growth for WeSendit. 0.75% of the unstaking amounts flow into the Referral Pool to incentivize users to refer our service to others. Existing users who successfully introduce new users to the network receive rewards from this pool. The referral program helps expand the user base, strengthen the network, and foster an active, growing community.

The rewards from the Referral Pool serve as an incentive for existing users to actively recommend WeSendit to their social circles, thus contributing to the network’s growth

Refilling the Staking Pool

The remaining 1.5% of the unstaking amounts are reinvested back into the Staking Pool. This mechanism ensures that the network has a sufficient number of trustworthy nodes to guarantee the integrity and security of the stored data. Reinvesting the fees back into the Staking Pool strengthens the community’s trust in the network and contributes to building a stable and reliable ecosystem.

It is essential to emphasize that all rewards and fees are transparent and traceable. Decisions regarding the allocation of rewards from the Activity Pool and the Referral Pool are made democratically by the community and are based on clear criteria to ensure that the projects and referrals bring real value to the WeSendit network.

Structure

There are three levels of WeSendit Nodes with different stakes

Assuming a WSI rate of 5 cents

Tier 1 — “Seed Nodes

Needed for the small tier and “seed node” is 10,000 WSI ($500) as collateral. Tier 1 Nodes receive 20% of file uploads with a limit of 1 GB per data fragment. This corresponds to a user upload of 10 GB.

Maximum 10 TB of paid storage.

Tier 2 — “Relay Nodes

Required for the middle tier and the “Relay Node” is 30,000 WSI ($1,500) as collateral. Tier 2 Nodes receive 30% of the file uploads with a limit of 2 GB per data fragment. This corresponds to a user upload of 20 GB.

Maximum 20 TB of paid storage.

Tier 3 — “Storage Nodes

Required for the large tier and the “Storage Node” are 100,000 WSI ($5,000) as collateral. Tier 3 Nodes receive 50% of the file uploads with no storage limits.

Maximum 100 TB of paid storage.

Website

As an example serve the Nodes of Myst https://mystnodes.com/onboarding/rpi/existing/0

Onboarding

Onboarding becomes as simple as possible.

After choosing how to provide a node, you will receive instructions.

Interface

Using the IP of his node and a port http://192.168.178.201:6300 (6300 as an allusion to train) the interface loads. After a password request I get an overview.