Architecture of Stashware

In Stashware, the data is distributed into different chunks and is stored across different nodes of a blockchain based network. The ultimate goal of Stashware is to provide internet service which is decentralized, censorship-resistant, and permanent liveness of the data.

In a decentralized system, even if some of the nodes goes down, the rest of the network will be alive to keep the data safe. The Stashweb is a layer built on top of the Stashwave‘s universal permanent hard drive. When a Stashware node receives a new transaction sent from an edge user or Stashweb application, the node validates the transaction amount and that the previous transaction reference matches that which is found in the Wallet List.

Figure 1: The flow of Stashware network.

For validation of a block PoC and PoA based consensus mechanism is used (see Section 5). In case a node successfully validates the transaction, then propagates the transaction to other nodes as soon as possible to be rewarded by the incentive mechanisms. Stashware encourages the nodes in a ranking system. As a data storage system, Stashware not only requires to be able to store large amounts of data, but also needs to provide access to the information in the most convenient way possible. Stashware creates a ranking system locally on each node, with each peer ranked by its rank, and the overall network blacklists its peers for poor performance. Miners are encouraged to maintain a high reputation to get more reward. It is in a node’s interest to propagate a transaction straightforwardly upon receipt rather than just mining it into a block. This is because the individual transaction needs to be accepted as valid by a majority of other nodes in the network before a block containing that transaction can be accepted. The steps for validating a transaction before entry into the transaction pools are as follows:

Figure 2: The architecture of Stashware and Stashweb for decentralized storage network.

1. Transactions that have already been processed are dropped.
2. Transactions that are not well-formed are ignored by the receiver node.
3. The wallet associated with the transaction must contain a sufficient stash balance in order to process claimed transaction and any additional pending transactions from the same wallet.
4. TXsender and TXreceiver should not refer to the same wallet.
5. The transaction fee must be higher than a minimum variable fee.
6. T Xanchor: TXsender’s last processed transaction ID or the independent hash of one of the last 20 blocks. Empty for the first transaction.
7. The TXanchor should be present in the wallet list of current position as TXsender’s last processed transaction ID, the independent hash of one of the last 20 blocks, or be empty for the first transaction.
8. In case of an unfriendly accessibility, the nodes will get a lower score.
9. Stashware will support both IPv4 and IPv6.
10. Inter-node protocol based on RESTful API