Systems and Methods of Blockchain Platform for Distributed Applications

1. A method of message flow model on a blockchain platform, comprising: verifying in each transaction, using a secure authentication module, identity of a miner, a blobber or a client; uniquely identifying, using a data integrity module, data for a transaction and prevent data corruption using erasure coding; wherein a unique transaction identification from combination of the client, the data and a timestamp is used; locking one or more client tokens for a limited period of time after posting a transaction to a mining network wherein the transaction includes an identity of the client and at least one of: a number of reads, a number of writes, and an amount of storage; selecting the locked tokens to generate a specific number of markers wherein each marker is a pair of a number i and signature comprising at least one of a read marker and a write marker wherein a read marker signature has a form of [READ, trans id, blobber id, block number, i] client and wherein a write marker signature has a form of [WRITE, trans id, blobber id, hash(data), block number, i] client permitting an authenticated, authorized, verified transaction on the blockchain based on three predefined communication messages: a first exchange and confirmation between the client and a selected miner directing connection with one or more selected blobbers with an optional Merkle root of the data, wherein the one or more selected blobbers are assigned the transaction each time on a random basis; a second exchange and confirmation between a client and the one or more of the selected blobbers using the marker and wherein the selected blobbers collect the markers; and a third exchange and confirmation between the selected blobber and the miner confirming the marker, and wherein the blockchain platform is configured to get the selected blobber paid from the locked tokens of the client; wherein the exchange and confirmation communication messages include a transaction of one or more of the following: sending, processing or receiving one or more initiate, update, read, write or delete requests; and forbidding a transaction on the blockchain that is one or more of a group comprising: not authenticated, not authorized, and not verified, and wherein the transaction does not use the corresponding set of two of the three predefined communication messages correspond to each of the miner, the blobber and the client.

2. The method of claim 1 , wherein the sending, processing or receiving of one or more requests further comprises: receiving from one or more miners a confirmation of the request on the blockchain with a list of one or more approved blobbers; initiating the request to one or more approved blobbers from the list using a secure authentication exchange; verifying the identity of each of the approved blobber using secure authentication response from the approved blabber; optionally encrypting the data for the request; applying erasure coding on the data for the request; and sending the data for the request to one or more approved and authenticated blobbers.

3. The method of claim 2 , further comprising: i. the list of one or more approved blobbers is selected; or ii. selecting blobbers from the list of approved blobbers; to geographically distribute data to increase the performance and availability of the data.

4. The method of claim 1 , wherein the sending, processing or receiving of one or more read requests for stored data further comprises: receiving from one or more miners a confirmation of the read request on the blockchain with a selected blobber from a list of blobbers with the stored data and a time period for authorized access of the stored data; and receiving data from the selected blobber within the authorized time period after the selected blobber has verified the read request.

5. The method of claim 1 , wherein the optional Merkle root data is not sent by the client in the first exchange, further comprising: approving or contesting the Merkle root in the second or third exchanges.

6. The method of claim 1 , further comprising: locking the authorized tokens for the authorized time period; releasing the authorized tokens after the authorized time period has expired.

7. The method of claim 1 , wherein either one of the client, miner or blobber monitor for suspicious activity or report an error.

8. The method of claim 7 , wherein the client or the miner can reconstruct a missing slice of the data from other available slices.

9. The method of claim 1 , further comprising: verifying that the blobber is actually storing the data by periodically issuing challenge requests.

10. The method of claim 1 , wherein the blockchain platform is not affected by attacks including one or more of the following: outsourcing, collusion, generation, sybil or replay attacks.

11. A system of message flow model on a blockchain platform, comprising one or more processors; a memory coupled to at least one of the processors; one or more modules stored in the memory and executable by the one or more processors; a network interface that connects the local node to one or more remote nodes; and a set of computer program instructions stored in the memory and executed by at least one of the processors in order to perform actions comprising: securely authenticate in each transaction used to verify identity of a miner, a blobber or a client with an optional Merkle root of the data; uniquely identify data and prevent data corruption using erasure coding for ensuring data integrity; use a unique transaction identification from combination of the client, the data and a timestamp; lock one or more client tokens for a limited period of time after posting a transaction to a mining network wherein the transaction includes an identity of the client and at least one of: a number of reads, a number of writes, and an amount of storage; select the locked tokens to generate a specific number of markers wherein each marker is a pair of a number i and signature comprising at least one of a read marker and a write marker wherein a read marker signature has a form of [READ, trans id, blobber id, block number, i] client and wherein a write marker signature has a form of [WRITE, trans id, blobber id, hash(data), block number, i] client , permitting an authenticated, authorized, verified transaction on the blockchain based on following three predefined communication messages a first exchange and confirmation between the client and a selected miner directing connection with one or more selected blobbers with an optional Merkle root of the data, wherein the one or more selected blobbers are assigned the transaction each time on a random basis; a second exchange and confirmation between a client and one or more of the selected blobbers using the marker and wherein the selected blobbers collect the markers; and a third exchange and confirmation between the selected blobber and the miner confirming the marker, and the blockchain platform is configured to get the selected blobber paid from the locked tokens of the client; wherein the exchange and confirmation communication messages include a transaction of one or more of the following: sending, processing or receiving one or more initiate, update, read, write or delete requests; and forbid a transaction on the blockchain that is one or more of: not authenticated, not authorized, and not verified, and wherein the transaction does not use the corresponding set of two of the three predefined communication messages which correspond to each of the miner, the blobber and the client.

12. The system of claim 11 , wherein the module executable on the one or more hardware processors configured to send, process or receive one or more requests is further configured to: receive from one or more miners a confirmation of the write request on the blockchain with a list of one or more approved blobbers; initiate a storage request to one or more approved blobbers from the list using a secure authentication exchange; verify the identity of each of the approved blobber using secure authentication response from the approved blabber; optionally encrypt the data for the request; apply erasure coding on the data for the request; and send data for storage to one or more approved and authenticated blobbers.

13. The system of claim 12 , wherein the one or more modules executable on the one or more hardware processors is further configured to: (i) select the list of one or more approved blobber; or (ii) select blobbers from the list of approved blobbers; geographically distribute data to increase the performance and availability of the data.

14. The system of claim 11 , wherein the one or more modules executable on the one or more hardware processors is further configured to: receive from one or more miners a confirmation of the read request on the blockchain with a randomly selected blobber from a list of blobbers with the stored data and a time period for authorized access of the stored data; and receive data from the selected blobber within the authorized time period after the selected blobber has verified the read request.

15. The system of claim 11 , wherein the optional Merkle root data is not sent by the client in the first exchange implemented by the one or more modules executable on the one or more hardware processors is, further configured to: approve or contest the Merkle root in the second or third exchanges.

16. The system of claim 11 , wherein the one or more modules executable on the one or more hardware processors is further configured to: lock the authorized tokens for the authorized time period; release the authorized tokens after the authorized time period has expired.

17. The system of claim 11 , wherein either one of the client, miner or blobber monitor for suspicious activity or report an error.

18. The system of claim 17 , wherein the client or the miner can reconstruct a missing slice of the data from other available slices.

19. The system of claim 11 , wherein the one or more modules executable on the one or more hardware processors is further configured to: verify that the blobber is actually storing the data by periodically issuing challenge requests.

20. The system of claim 11 , wherein the blockchain platform is not affected by attacks including one or more of the following: outsourcing, collusion, generation, sybil or replay attacks.