WO2019232259A1 - Protocole de vote et de stockage décentralisé de données - Google Patents

Protocole de vote et de stockage décentralisé de données Download PDF

Info

Publication number
WO2019232259A1
WO2019232259A1 PCT/US2019/034728 US2019034728W WO2019232259A1 WO 2019232259 A1 WO2019232259 A1 WO 2019232259A1 US 2019034728 W US2019034728 W US 2019034728W WO 2019232259 A1 WO2019232259 A1 WO 2019232259A1
Authority
WO
WIPO (PCT)
Prior art keywords
challenge
blockchain
data
entity
answer
Prior art date
Application number
PCT/US2019/034728
Other languages
English (en)
Inventor
David GOBAUD
Original Assignee
Mochi, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mochi, Inc. filed Critical Mochi, Inc.
Publication of WO2019232259A1 publication Critical patent/WO2019232259A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G06F16/1834—Distributed file systems implemented based on peer-to-peer networks, e.g. gnutella
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2103—Challenge-response
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2230/00—Voting or election arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • Blockchain technology and its various uses are ever increasing.
  • 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.
  • 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.
  • challenges or questions 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.
  • improvements can be made to systems utilizing blockchain technology to store data.
  • 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.
  • DApp decentralized applications
  • FIG. 1 illustrates an example process for storing data using a blockchain.
  • FIG. 2 illustrates an example process for counting and verifying votes for a voting system using a blockchain.
  • blockchain technology may be adapted or modified and used to create and facilitate a distributed data storage system.
  • 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.
  • 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
  • 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.).
  • IPFS 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) .
  • PoR proof of replication
  • the FileCoin system presents many complexities that can be reduced or eliminated with the present system and techniques.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • the described system contemplates a modification/adaption broadly of Storj and/or Filecon onto Stellar.
  • 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.
  • SDX Stellar Distributed Exchange
  • FileCoin’s on-chain storage and retrievability marketplace provides a method for price discovery and easy way for storage contracts to be formed.
  • 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.
  • 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.
  • 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.
  • 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.
  • process 100 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.
  • time period t may be 24 hours, such that the frequency of verification is once every 24 hours for storage of the data.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • answers to the challenge may be received from the entity requesting storage of the data or determined by the service.
  • the answer to the challenge may be received from the entity storing the data.
  • 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.
  • 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.
  • 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.
  • 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.
  • the blockchain may be used exclusively, or primarily, for processing and verifying rewards or payment.
  • 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.
  • SPub is one of the top X Mobius Public Addresses ranked by
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the set of bytes used to generate the hash may be specified in a data field on the escrow account itself.
  • 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
  • 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.
  • each DApp is accumulated in a list, where the DApp list is loaded from local or remote databases (e.g., it is centralized).
  • 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 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.
  • This technique can be extended to staking, for example for a specific token, such as MOBI.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • votes can be tallied at time X based on token count in accounts with the right vote data fields.
  • 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.
  • 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.
  • a system publishes a voting request at a specific designated location and/or time on a blockchain using a token- verified account.
  • 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.
  • 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.
  • 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.
  • 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
  • accounts that hold a large number of tokens 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.
  • 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.
  • 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.
  • 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).
  • a processor 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.
  • 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.
  • 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.
  • Non-transitory computer-readable storage media 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.
  • SSDs solid state drives
  • PCM phase-change memory
  • 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.
  • 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.
  • a network or another communications connection 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.
  • 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).
  • 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.
  • a network interface module e.g., a "NIC”
  • non-transitory computer-readable storage media (devices) can be included in computer system components that also (or even primarily) utilize transmission media.
  • 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.
  • 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.
  • the combination of software or computer-executable instructions with a computer-readable medium results in the creation of a machine or apparatus.
  • 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.
  • a computer-readable medium is transformed by storing software or computer-executable instructions thereon.
  • a processing device is transformed in the course of executing software or computer-executable instructions.
  • 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 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Software Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Finance (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Un procédé consiste à recevoir, d'une première entité comprenant un ensemble de données d'origine, une demande de stockage par une seconde entité d'une copie de l'ensemble de données d'origine. Au moins une identification de l'emplacement à partir duquel la copie peut être reçue et stockée par la seconde entité est publiée. Un premier défi d'un ensemble de défis est publié, chaque défi de l'ensemble de défis étant basé sur au moins une partie de l'ensemble de données d'origine stocké par la seconde entité. Une réponse correcte au défi est reçue de la première entité. Une première réponse au défi est reçue de la seconde entité. La première réponse est comparée à la réponse correcte. Si la première réponse correspond à la réponse correcte, une récompense est attribuée à la seconde entité. Un défi de l'ensemble de défis est publié uniquement à une fréquence prédéterminée.
PCT/US2019/034728 2018-05-31 2019-05-30 Protocole de vote et de stockage décentralisé de données WO2019232259A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201862678946P 2018-05-31 2018-05-31
US62/678,946 2018-05-31

Publications (1)

Publication Number Publication Date
WO2019232259A1 true WO2019232259A1 (fr) 2019-12-05

Family

ID=68697131

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2019/034728 WO2019232259A1 (fr) 2018-05-31 2019-05-30 Protocole de vote et de stockage décentralisé de données

Country Status (1)

Country Link
WO (1) WO2019232259A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6343361B1 (en) * 1998-11-13 2002-01-29 Tsunami Security, Inc. Dynamic challenge-response authentication and verification of identity of party sending or receiving electronic communication
WO2012174427A2 (fr) * 2011-06-16 2012-12-20 OneID Inc. Procédé et système de détermination de niveaux d'authentification dans des transactions
US20170223007A1 (en) * 2015-01-28 2017-08-03 International Business Machines Corporation Providing data security with a token device
US9876637B2 (en) * 2011-05-14 2018-01-23 Puccini World Limited Cloud file system
US20180121107A1 (en) * 2016-10-27 2018-05-03 International Business Machines Corporation Validation of write data subsequent to destaging to auxiliary storage for completion of peer to peer remote copy

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6343361B1 (en) * 1998-11-13 2002-01-29 Tsunami Security, Inc. Dynamic challenge-response authentication and verification of identity of party sending or receiving electronic communication
US9876637B2 (en) * 2011-05-14 2018-01-23 Puccini World Limited Cloud file system
WO2012174427A2 (fr) * 2011-06-16 2012-12-20 OneID Inc. Procédé et système de détermination de niveaux d'authentification dans des transactions
US20170223007A1 (en) * 2015-01-28 2017-08-03 International Business Machines Corporation Providing data security with a token device
US20180121107A1 (en) * 2016-10-27 2018-05-03 International Business Machines Corporation Validation of write data subsequent to destaging to auxiliary storage for completion of peer to peer remote copy

Similar Documents

Publication Publication Date Title
US11205172B2 (en) Factom protocol in blockchain environments
Pasdar et al. Connect API with blockchain: A survey on blockchain oracle implementation
AU2022226929B2 (en) Advanced non-fungible token blockchain architecture
US20190102163A1 (en) System and Method for a Blockchain-Supported Programmable Information Management and Data Distribution System
US11699202B2 (en) Method and system to facilitate gamified arbitration of smart contracts
JP2020534733A (ja) 分散協調を用いるスマートコントラクトの実行
JP7075393B2 (ja) ブロックチェーンにより実現されるシステム及び方法
WO2018020377A1 (fr) Procédé et système de mis en oeuvre de blockchain
US20220156837A1 (en) Distributed ledger implementation for entity formation and monitoring system
CN112612856B (zh) 基于区块链的数据处理方法和装置
US20230298001A1 (en) Non-fungible token (nft) purchase and transfer system
US20220311611A1 (en) Reputation profile propagation on blockchain networks
CN111368262B (zh) 一种基于区块链的人工智能模型保护、松耦合分布式训练方法
US20230057898A1 (en) Privacy preserving auditable accounts
US20230067556A1 (en) Systems and methods for tokenization, management, trading, settlement, and retirement of renewable energy attributes
US20220036323A1 (en) Electronic wallet allowing virtual currency expiration date
JP2023015223A (ja) 電子ブロックチェーンに組み込まれる取引の妥当性を確認するシステムと方法
Tu et al. Privacy‐Preserving Outsourced Auditing Scheme for Dynamic Data Storage in Cloud
WO2019232259A1 (fr) Protocole de vote et de stockage décentralisé de données
US20230121349A1 (en) Method for securing private structured databases within a public blockchain
CN114978893B (zh) 一种基于区块链的去中心化联邦学习方法及系统
CN112837043B (zh) 基于区块链的数据处理方法、装置及电子设备
CN113987566B (zh) 基于Hyperledger Fabric的内部桥接跨链方法、装置、设备和介质
CN111553683B (zh) 具有智能合同的可验证分析学平台
US20230267457A1 (en) Privacy preserving asset transfer between networks

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19810793

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19810793

Country of ref document: EP

Kind code of ref document: A1