WO2019232259A1

WO2019232259A1 - Decentralized data storage and voting protocol

Info

Publication number: WO2019232259A1
Application number: PCT/US2019/034728
Authority: WO
Inventors: David GOBAUD
Original assignee: Mochi, Inc.
Priority date: 2018-05-31
Filing date: 2019-05-30
Publication date: 2019-12-05

Abstract

A method includes receiving from a first entity having an original data set a request for storage by a second entity of a copy of the original data set. At least one identification of the location from which the copy can be received and stored by the second entity is published. A first challenge of a set of challenges, each challenge of the set of challenges being based on at least a portion of the original data set stored by the second entity, is published. A correct answer to the challenge is received from the first entity. A first answer to the challenge is received from the second entity. The first answer is compared to the correct answer. If the first answer matches the correct answer, a reward is allocated to the second entity. A challenge of the set of challenges is published only at a predetermined frequency.

Description

DECENTRALIZED DATA STORAGE AND VOTING PROTOCOL

COPYRIGHT NOTICE

[0001] This disclosure is protected under United States and/or International Copyright Laws. © 2019 Mochi, Inc. All Rights Reserved. A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and/or Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

PRIORITY CLAIM

[0002] The present application claims priority from U.S. Provisional Patent Appl. No. 62/678,946 titled“SYSTEM AND METHOD FOR DECENTRALIZED DATA STORAGE AND VOTING PROTOCOL” filed May 31, 2018, the contents of which are hereby incorporated by reference in their entirety.

BACKGROUND

[0003] Blockchain technology and its various uses are ever increasing. For example, blockchain technology can be used to facilitate storing data by multiple and/or anonymous users, through various verification protocols. The verification protocols are implemented to ensure that the data is being stored in its original form for a given period of time. However, these systems typically require constant monitoring by a third party of the data being stored, such as through sending challenges or questions concerning the data to the entity storing the data. Upon correctly answering the challenge or question, which is typically based on the underlying data to be stored, the storing entity receives some form of compensation. This constant or near-constant monitoring and challenge-based approach is very resource intensive. As a result, improvements can be made to systems utilizing blockchain technology to store data.

[0004] Blockchain ecosystems are merging, such as application or decentralized applications (DApp) stores. Given the fact that many of these ecosystems are at least in part open source, it is relatively easy for nefarious users to manipulate these systems, particularly in the case of providing feedback or voting for certain issues, such as improvements to the system, rating DApps, and so on. Similarly, improvements can be made to these systems to ensure that stakeholders in a given ecosystem are given more stake in such feedback operations.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] FIG. 1 illustrates an example process for storing data using a blockchain.

[0006] FIG. 2 illustrates an example process for counting and verifying votes for a voting system using a blockchain.

DETAILED DESCRIPTION

Distributed File Storage

[0007] In some aspects, blockchain technology may be adapted or modified and used to create and facilitate a distributed data storage system. For example, links to or locations of data to be stored in a distributed file storage system can be published on a blockchain. These links may be specifically identified via certain types of naming conventions, entries, or URLs, for example. Users of the blockchain may monitor the new blockchain entries to identify an entry that indicates a file or other data structure to be stored. Multiple users can access the same data file and store it in different locations. The storage of the data indicated via the entries may be incentivized through a payment or reward system that is implemented in the blockchain itself. [0008] This system presents the problem of verifying that the data, which is stored via access from the blockchain, is stored in multiple places, uncorrupted, for a period of time In some cases, this problem may be addressed using a protocol/network designed to create a content-addressable, peer-to-peer method of storing and sharing content in a distributed file system (e.g., sharing some aspects of systems implemented by FileCoin / Interplanetary File System (IPFS), etc.). FileCoin proposed a way to solve the problem of proving that a file is stored in X places, not just in one place, labeled proof of replication (PoR) . However, the FileCoin system presents many complexities that can be reduced or eliminated with the present system and techniques. In some aspect, the described system is designed to prove that data is stored in one or multiple locations for a given period of time, in a less complex, and more effective way. In some cases, this type of system could be implemented as a decentralized backup as part of a larger backup set, such that it would not be primarily relied upon for access and retrieval.

[0009] In some cases, FileCoin can be adapted to move more off-chain to a reputation-based system/market run by game theory. Generally, enforcement would not be as strict as on a blockchain, but a reputation system can account for that. In some aspect, an embodiment of the described system combines and modifies aspects of Stoq, as described in “Storj A Peer-to-Peer Cloud Storage Network,” December 15, 2016 (littps:/7storj io/stori .pdf), Sia, as described in“Sia: Simple Decentralized Storage,” Nebulous Inc., David Vorick et al, November 29, 2014 (ahttpsri/sia.tech/sia.pdf), and FileCoin, as described in“Filecoin: A Decentralized Storage Network,” Protocol Labs, January 2, 2018

((https://fiiecoin.io/fiiecoin.pdf), the contents of which are hereby incorporated by reference in their entirety as if fully set forth herein. An embodiment of the present system removes blockchain aspects, replaces them with a market-driven reputation system, and places the system on top of a blockchain, such as Stellar. In some cases, the described system contemplates a modification/adaption broadly of Storj and/or Filecon onto Stellar.

[0010] Sia describes verifying proofs on chain. The advantage of this technique is that the customer doesn't have to keep the file stored or actively verify hashes. It does so by storing a merkle tree on-chain (which could also be stored in the account key/value pairs). Then when a storage provider submits a proof, it submits the chunk data, byte range, and hash and the data can be confirmed on-chain via the merkle tree. FileCoin improves upon both Storj and Sia primarily with algorithms for proof of replication (PoR) and proofs of spacetime (PoST). PoR guarantees you have N copies stored. PoST guarantees you have the data stored over some time without requiring the online constant verification checks from Storj and Sia. FileCoin also implements an on-chain marketplace for storage and retrievability similar to the Stellar Distributed Exchange (SDX) and proposes running general smart contracts just like Ethereum. FileCoin’s on-chain storage and retrievability marketplace provides a method for price discovery and easy way for storage contracts to be formed.

[0011] The described system has reduced complexity compared to FileCoin because it does not support running general smart contracts. The proposed system is limited to a protocol for decentralized file storage and payment and runs on top of other blockchains, such as Stellar, instead of running natively on its own blockchain. Compared to Stoij, the present system provides a significant improvement in not requiring the party or entity requesting file storage to constantly be online asking storage providers to prove they have the file stored. Compared to Sia, the present system provides a significant improvement in not having to constantly submit data to the network for verification by other users. Rather, the present system uses PoST, from which a derived small value can be posted to the network for verification that proves the file has been stored for the entire time period.

[0012] FIG. 1 illustrates a process 100 for storing data according to an embodiment of the invention. The process 100 is implementable in an electronic system coupled to or including a storage device. The process 100 is illustrated as a set of operations shown as discrete blocks. The process 100 may be implemented in any suitable hardware, software, firmware, or combination thereof. The order in which the operations are described is not to be necessarily construed as a limitation.

[0013] One of the primary advantages of process 100 is the ability to enable third- party storage of data off of the blockchain, while still ensuring accountability through verification on the blockchain. Process 100 does not require constant challenge/verification to ensure that data is being stored for a period of time, as is the case with previous systems described above. For example, time period t, as discussed in further detail below, may be 24 hours, such that the frequency of verification is once every 24 hours for storage of the data. In other cases, time period t may vary from as little as 1 hour up to 36 or more hours, depending on the sensitivity of data to be stored, and other factors determined by the entity requesting that the data be stored. In addition, the complexity of process 100 is reduced as some of process 100 can be performed off of the blockchain. Process 100 enables one entity to store multiple copies of data and be rewarded/compensated for storage of each copy. This feature is enabled via PoR testing, to ensure that in fact, multiple copies of the data are stored by a single entity.

[0014] Process 100 may begin at operation 102, in which the service, application, or system performing process 100 may receive a request for decentralized data storage for data from a first entity looking to have data stored for a time period Tl. In some cases, the request may be associated with one or more PoR derived versions of the data to be stored, for example, when the requestor requests the data to be stored multiple times. At operation 104, the location(s) of or link(s) to the data to be stored (e.g., off chain, in one or more databases, cloud resources, etc.) may be published. Operation 104 may include publishing the location(s) or link(s) on the blockchain itself or via other media that enable access for entities wishing to store the data. In one or more embodiments, the data location(s) may indicate a request for other entities to store the data, such as explicitly, via a certain format of the published location, other data appended to or published with the data locations, or via other means. In one or more embodiments, the service may receive a request to store the data, for example by another user or entity. In some cases, this may be optional, such that another entity accesses the data at the specified data location without submitting a request or directly interacting with the service.

[0015] Once at least one request to store the data has been received, an access of the stored data has been detected, at operation 106 a challenge based on a portion of the data to be stored may be published, for example, at time t. The challenge may be published on blockchain, where the challenged is based on PoST. Next, at operation 108, answers to the challenge may be received from the entity requesting storage of the data or determined by the service. At operation 110 the answer to the challenge may be received from the entity storing the data. In one or more embodiments, only answers received at the end of time t, or within a certain predetermined time after the end of time t, may be considered valid answers, whereby they will be compared to the answer that is received from the entity requesting the data to be stored/determined by the service. Next, the service may compare the answers at operation 112. If they are the same, proving that the entity has stored the data for time t, then a reward may be allocated to the entity at operation 114. Otherwise, the entity may be given another or multiple chances or may be blacklisted at operation 120. In some cases, process 100 may iterate through operations 106 through 116 until period T1 expires, as determined at operation 116, with each iteration incrementing by time t, at operation 118 until period T1 expires. Once time period T1 has expired, process 100 may end or restart.

[0016] In some cases, one or more of operations 106, 108, 110, and 112 may be wholly or in part performed by the entity requesting the data to be stored. In one or more embodiments, the blockchain may be used exclusively, or primarily, for processing and verifying rewards or payment. In one or more embodiments, the blockchain may be used to carry out more operations of process 100. It should be appreciated that process 100 is only given by way of example. One or more operations may be omitted from process 100 in different aspects or embodiments of process 100.

[0017] Another exemplary protocol/process for utilizing a blockchain to create a decentralized storage system is provided below. Aspects of the below protocol may be implemented in conjunction with process 100 described above.

Storage Request Protocol

1. Assume a user U wants to store ImportantFile with hash HIF

2. U’s Mobius Public Address (UPub)

3. U’s Mobius Private Key (UPriv)

4. U keeps a Server Bad Actor List (SBAL) of Mobius Public Addresses

5. Set the following data fields on a Mobius account:

a) Protocol: MDSP

b) Source URL: ht|>s.//lmgortan File

c) Hash: HIF

d) Number of Copies: X

e) Payment Rate per Copy: Y MOBI per Z seconds f) Payment Amount for Download: DL MOBI

g) Minimum Revenue for Download: R

h) Proofs of Spacetime (PoSt) Payment Interval: PoStPI seconds

Storage Response Protocol

1. Assume a server S wants to store ImportantFile

2. S keeps a User Bad Actor List (UBAL) of Mobius Public Addresses

3. S’s Mobius Public Address (SPub)

4. S’s Mobius Private Key (SPriv)

5. Set the following data fields on a Mobius account:

a) Protocol: MDSP

b) Source URL: https: //ImportantFile

c) Proof of Storage URL: https ://ImportantFileCopy

Initial File Download Protocol

1. S submits POST request to https ://ImportantFile with params:

a) SPub

b) https://ImportantFile signed by SPriv

2. U responds with ImportantFile iff:

a) SPub is not in BAL

b) The signature on https://ImportantFile came from SPriv

c) SPub is one of the top X Mobius Public Addresses ranked by

amount of MOBI in the account, that has advertised it wants to store the file

[0018] In some cases, files or other data structures are stored as encoded via the Proof of Replication (PoR) encoding algorithm where the encoding key ( ek ) is equal to SPub, as further described in“Proof of Replication, Technical Report (WIP)”, Protocol Labs, July 27, 2017, Juan Benet, David Dalrymple, Nicola Greco (https ://filecoin i o/proof-of- replication.pdf). the contents of which are hereby incorporated by reference in their entirety as if fully set forth herein. The ImporantFileS represents the PoR encoded file unique to S.

[0019] An exemplary protocol/process for implementing a reward or payment system, which may be performed in conjunction with one or more of the distributed data storage processes described, is provided below:

Payment Protocol 1

1. Every Z seconds U submits a POST request to each https ri/ImportantFileCopy for which SPub is one of the top X Mobius Public Addresses ranked by amount of MOBI in the account with params:

a) StartByte b) EndByte

c) htps ://ImportantFile signed by UPriv

2. S responds with the hash of StartByte to EndByte of ImportantFileS iff:

a) The signature on htps://ImportantFile came from UPriv

3. U sends Y MOBI to SPub iff the hash is correct Else it adds SPub to SBAL a) In payment transaction include htps://ImportantFile signed by UPriv so payment can be atributed to ImportantFile

4. S deletes the file and adds U to UBAL iff it does not receive payment

Payment Protocol 2 (Proof of Spacetime Interval - PoStPI)

1. S starts calculating a proof-chain (see https://filecQm.io/proof-of- replication.pdf) at time tO on ImportantFileS and continuously grows it.

2. Every Z seconds S saves the head of the proof-chain to its Stellar account in a data field

3. Every PoStPI seconds U verifies the proof-chain heads in S’s Stellar account and iff they are correct sends PoStPI * Y MOBI to SPub Else it adds SPub to SBAL

a) In payment transaction include htps://ImportantFile signed by UPriv so payment can be atributed to ImportantFile

5. S deletes the file and adds U to UBAL iff it does not receive payment

Download Protocol

1. Before requesting download, U submits a MOBI payment of (R - SPaymentsToDateForlmportantFile) iff (SPaymentsToDateForlmportantFile < R)

2. At will U can submit a POST request to a htps://irnporiantFileCopy for which SPub is one of the top X Mobius Public Addresses ranked by amount of MOBI in the account with params:

a) StartByte

b) EndByte

c) Download=l

d) htps ://ImportantFile signed by UPriv

3. U responds with ImportantFile iff:

a) The signature on htps://ImportantFile came from UPriv

b) AND

c) SPaymentsToDateForlmportantFile >= R

4. U sends DL MOBI to SPub iff the hash of the returned data is HIF Else it adds SPub to SBAL

5. S deletes the file and adds U to UBAL iff it does not receive payment

[0020] In some cases, a ranking tie is broken by earlier account creation date. A minimum balance for an escrow account may be implemented to prevent or deter spamming the system with fraudulent requests (e.g., 1.5 or other value of XLM or other crypto currency, or fiat currency, such as $1.50). Additionally, or alternatively, addresses may be banned for submitting one or more fraudulent requests or other bad actions.

[0021] In some cases, the decentralized storage system described above can be extended to decentralized web hosting with file location lookup via a blockchain system, such as the Stellar blockchain. A first user’s (Ul) public key is PUB on an account. The user (Ul) may publish a list of files and hashes to be stored, such as index.html. Another user (U2), who desires Ul’s index.html, can look it up on the blockchain to get the hash and a list of other users serving it. U2 may request the file from a server and verify that the file is correct. On successful download U2 could send a payment to the server from which it downloaded the file. The concept of black lists can be extended to this system so that servers could black list users that download files and do not pay.

[0022] In some aspects, payment or reward for decentralized data storage may be provided through one or more escrow accounts, with access to the escrow accounts being derived from the actual data to be stored. In one example, certain portions of the data to be stored may be used to derive a secret key that may be used to unlock an account, such as an escrow account, having an amount of currency or other commodity or valuable asset that is to be traded or conveyed in exchange for storing the data. For example, an escrow account may be set up and a certain sum of money deposited in the account periodically (e.g., daily). A hash of a specific portion of the data to be stored may be used to derive a secret key that unlocks or grants access to the escrow account. In one or more embodiments, the set of bytes used to generate the hash may be specified in a data field on the escrow account itself. In this way, actors may be incentivized to store data in one or more locations. If the escrow account stops paying, people or other actors would lose incentive to store the file and so will delete it. An embodiment also provides assurances that the entity wishing to store the data will not claim the money for itself, because that would disincentive others from storing the data in other locations. Decentralized Application Staking

[0023] Decentralized applications or DApps are applications that are run by multiple users via a decentralized network and/or implement decentralized payment systems. DApps are designed to avoid any single point of failure or“middleman,” and can prevent censorship or other users or entities gaining data about usage of the application through the middleman. DApps are built on top of blockchain technology typically using open source software, and generally have tokens to reward users for providing computing power.

[0024] One of the biggest problems hindering mass adoption of DApps and cryptocurrencies is consumer discovery and adoption. Currently there is no widely used DApp Store. One implementation of a universal DApp Store is described in U.S. Provisional Patent App. No. 62/549,071 and Intl. App. No. PCT/US2018/047691 titled“METHOD AND SYSTEM FOR A DECENTRALIZED MARKETPLACE AUCTION,” the contents of each of which are hereby incorporated by reference in their entirety. This DApp store is similar to the Apple App Store and Google Play Store in ability and functionality. Basically, any app that accepts one or potentially multiple tokens, can be listed in the DApp Store. The DApp Store also integrates one or multiple tokens for a universal decentralized credit system.

[0025] Systems and techniques for better and more efficiently storing and accessing DApps on a DApp Store are described herein. In some cases, the front end of the DApp store is open source, such that anyone can replicate or copy the DApp store. Currently, each DApp is accumulated in a list, where the DApp list is loaded from local or remote databases (e.g., it is centralized). However, efficiency gains may be made by storing the DApp list on the blockchain itself in one or more specified data fields. Each DApp has a public address associated with it. Each DApp may be listed in the DApp Store by setting data fields on the blockchain itself with a specified format of key/value pairs. The network can be monitored by the system to search for these data fields, and ultimately utilized to populate the DApp store with discovered DApps. The main benefit of storing the DApp properties on a blockchain (basically a publicly verifiable and accessible database) is that even if the host of the DApp store exits, goes bankrupt, etc., and its version of the DApp Store goes offline, others can create alternative interfaces for visualizing the apps and recreate the DApp Store. [0026] This technique can be extended to staking, for example for a specific token, such as MOBI. For example, the system can require that to actually list a DApp (e.g., on the decentralized list maintained on the blockchain), the address associated with the DApp has to hold at least a certain value of a specified token. In some implementations, if there is a conflict in names of DApps, the entity with the most of a certain token will obtain and be able to continue to use the name (e.g., similar to a deposit).

[0027] This technique can also be used to resolve naming conflicts for DApp names, such that the address that is associated with the largest number of tokens is entitled to the conflicted name. In one or more embodiments, a voting system may be implemented to resolve naming conflicts, and for a large number of other uses. For example, votes for a certain topic can be recorded through the data fields with the number of votes equal to the number of tokens at the time the vote is cast. In one or more embodiments, tokens may be locked up in some type of escrow transaction to prevent infinite voting by constantly moving tokens around and setting the data field again. In one or more embodiments, votes can be tallied at time X based on token count in accounts with the right vote data fields.

[0028] It should be appreciated that the above DApp storing, name conflict resolution, and voting processes may be built on top of any number of blockchain technologies, including Stellar, Ethereum, etc.

Voting Protocol

[0029] In one or more embodiments, a voting system may be built on top of the Stellar or other blockchain network. In some aspects, only some parts or aspects of the voting protocol need to actually be on chain. For example, with the decentralized storage concept and system described above, a number of functions and processes may be moved off-chain and Stellar or other blockchain may be used as a decentralized payment protocol and database. In a similar way, voting and other governance protocols (certain actions for “members” of an ecosystem that are enabled via the use or proving possession of a token specific to the ecosystem) may benefit from a voting protocol that utilizes off-chain elements. [0030] In some aspects, the described voting system may be used for a build challenge for DApps for example. A build challenge may be announced with an end date and time on which votes will be counted. FIG. 2 illustrates a process 200 for verifying votes using a blockchain according to an embodiment of the invention. The process 200 is implementable in an electronic system coupled to or including a storage device. The process 200 is illustrated as a set of operations shown as discrete blocks. The process 200 may be implemented in any suitable hardware, software, firmware, or combination thereof. The order in which the operations are described is not to be necessarily construed as a limitation.

[0031] At an operation 202, a system according to an embodiment publishes a voting request at a specific designated location and/or time on a blockchain using a token- verified account. At an operation 204, the system receives/publishes a vote from an account A on the blockchain. The vote may comprise or include an answer responsive to a resource intensive function f(U, A) having an associated predetermined answer, in which U is a unique number associated with account A. At an operation 206, a check is performed to determine whether the answer associated with the boat matches the predetermined answer associated with resource intensive function f(U, A). If there is no such match then, at operation 208, the vote is discarded. Otherwise, at an operation 210, a check is made as to whether the vote was received at the designated location and/or time on the blockchain. If the vote was not received at the designated location and/or time on the block chain then, at operation 208, the vote is discarded. Otherwise, at operation 212, a check is made to determine whether account A contains a number of tokens greater than a predetermined maximum number of tokens. If account A does contain a number of tokens greater than the predetermined maximum number then, at operation 208, the vote is discarded. Otherwise, at an operation 214, the vote is counted and recorded. Operations 204 through 212 may be repeated for every account that submits a vote using the described system.

[0032] In another example, votes may be counted as follows: at a given time or block location on the blockchain (e.g., 11 :59 am or say block X - 1 etc.) the system can publish under a Stellar account a unique number U. Such Stellar account is verified because it is the issuer of the MOBI (this is a reason for not locking the account). A Stellar account A votes by publishing in their account the result of some resource intensive function f(U, A). Votes need to be in by l2:0lpm or maybe block Y - thus limited by computation power. We then go through the blockchain and count all the valid votes - 1 vote per Mobius account with MOBI

>= M

[0033] In some aspects, accounts that hold a large number of tokens (e.g., MOBI Whales) don't automatically dominate the vote because they also need significant computation power and votes are limited to 1 per account A and tied to the output of f(U, A) which is unique per account. In some cases, vote spamming is also limited by the fact that each A has to have an XLM reserve of probably at least 3-4 XLM which is $l-$2 so that can also get expensive.

[0034] This patent application is intended to describe one or more embodiments of the present disclosure. It is to be understood that the use of absolute terms, such as“must,” “will,” and the like, as well as specific quantities, is to be construed as being applicable to one or more of such embodiments, but not necessarily to all such embodiments. As such, embodiments of the disclosure may omit, or include a modification of, one or more features or functionalities described in the context of such absolute terms.

[0035] Embodiments of the present disclosure may comprise or utilize a special- purpose or general-purpose computer including computer hardware, such as, for example, one or more processors and system memory, as discussed in greater detail below. Embodiments within the scope of the present disclosure also include physical and other computer-readable media for carrying or storing computer-executable instructions or data structures. In particular, one or more of the processes described herein may be implemented at least in part as instructions embodied in a non-transitory computer-readable medium and executable by one or more computing devices (e.g., any of the media content access devices described herein). In general, a processor (e.g., a microprocessor) receives instructions, from a non-transitory computer-readable medium, (e.g., a memory, etc.), and executes those instructions, thereby performing one or more processes, including one or more of the processes described herein. [0036] Computer-readable media can be any available media that can be accessed by a general purpose or special-purpose computer system. Computer-readable media that store computer-executable instructions are non-transitory computer-readable storage media (devices). Computer-readable media that carry computer-executable instructions are transmission media. Thus, by way of example, and not limitation, embodiments of the disclosure can comprise at least two distinctly different kinds of computer-readable media: non-transitory computer-readable storage media (devices) and transmission media.

[0037] Non-transitory computer-readable storage media (devices) includes RAM, ROM, EEPROM, CD-ROM, solid state drives ("SSDs") (e.g., based on RAM), Flash memory, phase-change memory ("PCM"), other types of memory, other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special-purpose computer.

[0038] A "network" is defined as one or more data links that enable the transport of electronic data between computer systems or modules or other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a transmission medium. Transmissions media can include a network or data links which can be used to carry desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special-purpose computer. Combinations of the above should also be included within the scope of computer-readable media.

[0039] Further, upon reaching various computer system components, program code means in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to non-transitory computer-readable storage media (devices) (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a "NIC"), and then eventually transferred to computer system RAM or to less volatile computer storage media (devices) at a computer system. Thus, it should be understood that non-transitory computer-readable storage media (devices) can be included in computer system components that also (or even primarily) utilize transmission media.

[0040] Computer-executable instructions comprise, for example, instructions and data which, when executed at a processor, cause a general-purpose computer, special-purpose computer, or special-purpose processing device to perform a certain function or group of functions. In some embodiments, computer-executable instructions are executed on a general- purpose computer to turn the general-purpose computer into a special-purpose computer implementing elements of the disclosure. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code.

[0041] According to one or more embodiments, the combination of software or computer-executable instructions with a computer-readable medium results in the creation of a machine or apparatus. Similarly, the execution of software or computer-executable instructions by a processing device results in the creation of a machine or apparatus, which may be distinguishable from the processing device, itself, according to an embodiment.

[0042] Correspondingly, it is to be understood that a computer-readable medium is transformed by storing software or computer-executable instructions thereon. Likewise, a processing device is transformed in the course of executing software or computer-executable instructions. Additionally, it is to be understood that a first set of data input to a processing device during, or otherwise in association with, the execution of software or computer- executable instructions by the processing device is transformed into a second set of data as a consequence of such execution. This second data set may subsequently be stored, displayed, or otherwise communicated. Such transformation, alluded to in each of the above examples, may be a consequence of, or otherwise involve, the physical alteration of portions of a computer-readable medium. Such transformation, alluded to in each of the above examples, may also be a consequence of, or otherwise involve, the physical alteration of, for example, the states of registers and/or counters associated with a processing device during execution of software or computer-executable instructions by the processing device. [0043] As used herein, a process that is performed“automatically” may mean that the process is performed as a result of machine-executed instructions and does not, other than the establishment of user preferences, require manual effort.

[0044] While the preferred embodiment of the disclosure has been illustrated and described, as noted above, many changes can be made without departing from the spirit and scope of the disclosure. Accordingly, the scope of the described systems and techniques is not limited by the disclosure of the preferred embodiment. Instead, the described systems and techniques should be determined entirely by reference to the claims that follow.

[0045] The embodiments of the present disclosure in which an exclusive property or privilege is claimed are defined as follows:

Claims

What is claimed is:

1. A method, comprising the steps of:

receiving, from a first entity having an original data set, a request for storage of a copy of the original data set by a second entity ;

publishing at least one identification of the location from which the copy can be received and stored by the second entity;

publishing a first challenge of a set of challenges, each challenge of the set of challenges being based on at least a portion of the original data set;

receiving from the first entity a correct answer to the challenge;

receiving from the second entity a first answer to the challenge;

comparing the first answer to the correct answer; and

if the first answer matches the correct answer, allocating a reward to the second entity, wherein a challenge of the set of challenges is published only at a predetermined frequency.

2. The method of claim 1, wherein the request is for decentralized storage of the copy.

3. The method of claim 1, wherein the request for storage of the copy specifies a time period for storage of the copy.

4. The method of claim 3, wherein a challenge of the set of challenges is published only during the time period.

5. The method of claim 1, wherein the at least one identification of the location is published on a blockchain.

6. The method of claim 1, wherein the at least one identification of the location comprises a link.

7. The method of claim 1, wherein the challenge is published on a blockchain.

8. The method of claim 1, wherein the challenge is based on proofs of spacetime

(PoST).

9. The method of claim 1, wherein the request specifies multiple proof of replication (PoR) derived versions of the original data set to be stored, and each of the multiple PoR-derived versions is unique.

10. The method of claim 9, wherein the correct answer is determined for each of the multiple PoR-derived versions.

11. The method of claim 9, wherein the steps of comparing and allocating the reward are performed for each of the multiple PoR-derived versions.

12. The method of claim 11, wherein the request for storage of the copy specifies a time period for storage of the copy.

13. The method of claim 12, wherein a challenge of the set of challenges is published only during the time period.

14. The method of claim 11, wherein the at least one identification of the location is published on a blockchain.

15. The method of claim 11, wherein the at least one identification of the location comprises a link.

16. The method of claim 11, wherein the challenge is published on a blockchain.

17. The method of claim 11, wherein the challenge is based on proofs of spacetime (PoST).

18. A method, comprising the steps of:

publishing a voting request at at least one of a specific location or time on a blockchain using a token-verified account;

receiving a vote from a first account on the blockchain, wherein the vote comprises a first answer;

verifying that the first answer matches a predetermined correct answer; if the first answer matches the correct answer, verifying that the vote is received by a predetermined cutoff time or at a predetermined location on the blockchain;

if the vote is received by the predetermined cutoff time or at the predetermined location on the block chain, verifying that the first account contains a quantity of tokens greater than a predetermined number of tokens; and

if the first account contains a quantity of tokens greater than a predetermined number of tokens, counting and recording the vote.

19. The method of claim 18, wherein the vote comprises an answer to a resource intensive function.

20. The method of claim 18, wherein the predetermined correct answer is a correct answer to the resource intensive function.