WO2019040712A1 - Method and system for a decentralized marketplace auction - Google Patents

Abstract

A method of conducting a decentralized auction includes accessing a data set with at least one oracle. At least one auction private key and an auction public key are created. The data set is encrypted with the at least one oracle using the public key. The encrypted data set is submitted on a blockchain to at least one auctioneer. Bids for the at least one private key are received by the auctioneer from a plurality of smart contracts on the blockchain. The at least one private key is configured to decrypt the encrypted data set. a winning smart contract of the plurality of smart contracts is determined by the auctioneer from the bids. A payment associated with the winning smart contract is received. The at least one private key is provided to the winning smart contract.

Description

METHOD AND SYSTEM FOR A DECENTRALIZED MARKETPLACE AUCTION

PRIORITY CLAIM

[0001] The present application claims priority to U.S. Prov. Pat. Appl. No. 62/549,071 filed August 23, 2017, the contents of which are hereby incorporated by reference as if fully set forth herein.

BACKGROUND

[0002] Blockchain today is comparable to the internet in the early 1990s, where 9,600 bits per second modems were just entering the market. Today Ethereum runs at a mere -13 transactions per second. Blockchain developer tools and protocols today are similarly comparable to web developer tools in the early 1990s before Stripe created a standardized simple protocol to accept credit card payments and Amazon AWS introduced simple cloud computing that made it easy for anyone to deploy a web application.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

[0003] The details of the present invention, both as to its structure and operation, can best be understood by referring to the accompanying drawings, in which, where applicable, like reference numbers and designations refer to like elements.

[0004] FIG. 1 is a graphical illustration of expected market participants in a decentralized application store according to an embodiment;

[0005] FIG. 2 is a functional schematic illustration of components employed in a decentralized auction according to an embodiment;

[0006] FIG. 3 is a functional schematic illustration of components employed in a decentralized auction according to an embodiment;

[0007] FIG. 4 is a tabular illustration of the results of a decentralized auction according to an embodiment;

[0008] FIG. 5 is a tabular illustration of the results of a decentralized auction according to an embodiment;

[0009] FIG. 6 is a tabular illustration of the results of a decentralized auction according to an embodiment; [0010] FIG. 7 is a tabular illustration of the results of a decentralized auction according to an embodiment;

[0011] FIG. 8 is a functional schematic illustration of components employed in a decentralized auction according to an embodiment;

[0012] FIG. 9 is a timeline illustration of the results of a decentralized cloud-file storage market auction according to an embodiment;

[0013] FIG. 10 is a timeline illustration of the results of a decentralized cloud-file storage market auction according to an embodiment; and

[0014] FIG. 11 is a supply-and-demand illustration of the results of a decentralized cloud-file storage market auction according to an embodiment.

DETAILED DESCRIPTION

[0015] This patent application is intended to describe one or more embodiments of the present invention. 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 invention may omit, or include a modification of, one or more features or functionalities described in the context of such absolute terms.

[0016] Embodiments of the present invention 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 invention 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.

[0017] 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 invention can comprise at least two distinctly different kinds of computer-readable media: non-transitory computer-readable storage media (devices) and transmission media.

[0018] 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.

[0019] 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.

[0020] 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.

[0021] 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 invention. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code.

[0022] 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.

[0023] 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.

[0024] 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.

[0025] The present protocol token blockchain according to an embodiment runs protocols that provide standards for cross-blockchain login, payment, governance, and oracles such as the novel universal proof of stake oracle. Today there are 18.2 million software developers in the world but there is an extreme shortage of blockchain developers. A strong developer community and open APIs have been key to the success of Facebook®, Salesforce, and eBay® and will similarly be key to the success of blockchain and expanding it to the masses. In an embodiment, every developer can be a blockchain developer through cross-blockchain and internet bridging protocols. An embodiment similarly streamlines blockchain integration through a set of protocol APIs that bridge the gap between blockchains and internet-connected applications.

[0026] When developers are able to easily integrate blockchain technology into their applications and devices blockchain technology will experience exponential growth similar to the telephone system because of positive network effects and feedback loops, which will develop and become stronger with each blockchain integration. At a macro level, blockchain will become the fastest growing technology of all time because it is a network system that rides on top of, and leverages, the most powerful network to date— the internet.

[0027] Today there are over 800 tokens with many created this year by organizations that have sold them to collectively raise almost $1.3 billion in the first half of 2017. Some have questioned why a company needs its token when it can accept Bitcoin. The answer is community and governance. A company can accept Bitcoin for payment but Bitcoin does not allow an organization to be run by a decentralized community with a vested interest in its success.

[0028] When a company creates its own token, it creates a cryptographically secure decentralized organizing utility upon which it can self-govern and moderate its platform through an open community of members. For example, an organization with its own token can hold secure community votes in which each token represents one vote. If the organization relied on Bitcoin it would open its proposal voting to all Bitcoin holders, the vast majority of which would have no vested stake or interest in the organization and its platform. When an organization creates its own token, the holders of the token have a specific vested interest in the organization and platform and therefore a token acts as a form of proof of membership to ensure that only people that are a part of the community can vote.

[0029] The concept of token-based voting can be broadened and used for additional vested proof of stake required micro-actions throughout a platform. For example, Wikipedia could require that editors have some tokens at stake before editing an article. Such a proof of stake requirement can help reduce spam and other unwanted behavior. This could additionally be broadened to reward community members who contribute positively to the community and additionally penalize members that harm the community by taking away some of their at-stake tokens. This type of decentralized self-governance and moderation will result in significant value creation and disintermediation. [0030] Today's legacy global payment infrastructure is centralized, convoluted, and expensive. Accepting credit and debit cards involves a three-step authorization, clearing, and settlement process that depends on payment gateways, terminals, merchant banks, credit card associations, cardholder banks, and other stakeholders resulting in high fees and slow payment finalization. Legacy payments are also expensive often costing approximately $0.30 + 2.9% per transaction.

[0031] Blockchain technology has the potential to simplify global payments by disintermediating large financial institutions and thus significantly reducing transaction costs. However, current blockchain developer APIs and frameworks are in their infancy and are very hard to use. Blockchain developer technology today is similar to payment developer frameworks before Stripe.

[0032] The present system's API according to an embodiment provides a universal interface to accepting any blockchain token. Currently, it is very complicated to accept, manage, and secure tokens. For example, if a video game developer creates an Ethereum ERC20 token that acts as their in-game credits, it is complicated to move tokens between the Ethereum network and their backend accounting system.

Current Token Developer Process:

1. Run a full Ethereum node

2. Create a unique Ethereum address for each user

3. Monitor every user Ethereum address for incoming token transactions

4. Secure the private keys

5. Manage token accounting in their backend

[0033] The present system's API according to an embodiment simplifies all this by providing a REST API that returns (JavaScript Object Notation) JSON and uses secure webhooks to alert developers of incoming token transfers.

[0034] The present system's API according to an embodiment currently works with any ERC20 token such as: Golem, Augur, Iconomi, Bancor, Storj, Status, Credo, etc.

[0035] Tokens can be used to represent membership to a service and can be used as a login mechanism. Any service that uses tokens as a login mechanism has similar technical infrastructure needs analogous to token payment infrastructure. An embodiment provides a simple REST API that abstracts low-level blockchain development required to verify token ownership at time of login and facilitate verified login. [0036] Using a token to represent a subscription provides several benefits including increased anonymity, lower transaction fees, and the potential for an independent secondary market to develop providing greater value for subscribers and incentive to purchase a subscription or membership early. The secondary market will allow people to anonymously buy and sell their membership without ever transacting over centralized financial institutions such as credit cards, debit cards, or bank accounts allowing for completely anonymity assuming an anonymous protocol such as PIVX is used.

[0037] Multiple tiers of membership can also be represented through tokens by requiring a different number of tokens to access different levels. For example, a basic membership might only require one token to login while the plus membership might require five tokens, for example, to login.

[0038] Organizations that create a token and use it for platform governance will have similar use cases. For example, if Wikipedia and Reddit each create a token they are likely to have similar governance and proof of stake platform integration needs. On the governance side, both organizations may allow token holders to vote on proposals that dictate how the communities develop. On the platform integration side, both may require advanced users such as editors or moderators to have some vested tokens at stake in order to reduce spam and harmful community behavior. Both organizations may also want to reward community members that improve the community and add value. These similar use cases can be abstracted much as web frameworks and databases, the building blocks of web applications, have been abstracted. The vast majority of developers do not create their own web framework such as Ruby on Rails or their own database server such as PostgreSQL. Instead they use one of the existing web frameworks or database servers to save time. Blockchain based governance will follow the same model and be offered to developers by the present system via standard protocols and APIs that they can use to facilitate token-based voting and vested at-stake micro-actions that result in token rewards or penalties based on community feedback.

[0039] One of the biggest problems hindering mass adoption of Decentralized Applications (DApps) and cryptocurrencies is consumer discovery and adoption. Currently there is no widely used DApp Store. Embodiments of the invention may include a universal DApp Store that will be similar to the Apple® App Store and Google® Play Store. Any app that accepts the present token will be listed in the DApp Store. The DApp Store will also integrate the present token for a universal decentralized credit system. [0040] DApps can be incentivized to accept the present token in the DApp Store because of the network effects of the DApp Store and present token. The present token can experience similar network effects to the Internet in which the token becomes more valuable as more people use it. This is in parallel to a developer having its own token primarily for governance reasons. A developer that has its own token will still want to accept the easiest to use and cheapest form of payment from transient users so they are not turned away. Simultaneously, a developer with its own token will want to limit governance and at-stake based micro-actions to users with a vested stake in their community and platform. The DApp Store and present Network provide a platform to easily support both use cases.

[0041] In the past two decades, a nation's economic vitality, and increasing swaths of GDP, became progressively dependent on internet access, which revolutionized communication. In much the same way, blockchain adoption - with well defined smart contracts in place - will prove to be equally indispensable for the vitality of a nation's GDP: transforming centralized legacy systems based on institutional trust into more global, trustless, and decentralized vending-machine like transactions. Well-defined smart contracts on public blockchains have the potential to turn noisy big data into value-added insights via prediction markets, create immutable public records, power decisions of autonomous AI actors, and much more in the years ahead. Apps of today will be very different than the DApps of tomorrow because there will be a progressive wave of decentralization of the app economy. Existing apps will need to find an easy way to connect to the blockchain ecosystem. Blockchain "content" in the form of apps will only come to fruition if the best developers are given an economic incentive in advance of mass market adoption by end users. Such an option is only accessible by major enterprises with significant funding.

[0042] There is a classic chicken and egg problem for marketplaces: for the DApp Store, developers are more inclined to add content only when users are present, and users will adopt such content depending on its availability, unique value, and stickiness. As a result, if developers are incentivized to add content to the platform, then early adopting end users will gradually adopt the platform.

[0043] Based on the Lotka Volterra population models we can model the dynamics underlying the present token and the DApp Store as follows: Where:

® x is the number of market participants in the DApp store, which represents the demand or consumer Side

® y is the number of developers in the DApp store

® t represents time

® dx/dt is the growth rate of market participants with respect to time

• dy/dt is the growth rate of developers with respect to time

® a, β, γ, δ are positive real parameters that describe the interactions of the developers and market participants.

[0044] Essentially the rate of change of market participants is dependent on the number of current market participants and the number of developers, similarly this is true for developers.

[0045] This leads to a virtuous cycle. As more market participants start using the DApp, more developers are encouraged to participate. This further incentivizes new market participants to start using the DApp store.

[0046] Let us assume that a fraction ζοΐ the potential population is already using the DApp store.

[0047] Any individual pays a price, measured here in terms of the present system to become a market participant of the DApp store; in fact any potential individual will have a maximum limit on the price the individual would be willing to pay to participate.

[0048] This reserve price may be represented as follows:

reserve price = g(x)f(Q

Where:

• g(x) as before is the desire of some person x in becoming a market participant

• f(Q is the measure of the benefit that each new market participant derives from having a ζ fraction of the total population already being market participants

• ί(ζ )is an increasing function in terms of ζ: it tells us how much more valuable the DApp store is when more people are using it.

• g(x)¾) comes from the Lotka Volterra population models.

[0049] For the reserve price, the term g(_x)f^) represents the fact that market participants who derive a larger benefit, benefit more from an increase in the fraction of the population becoming market participants than those market participants that have smaller values.

[0050] As elucidated by the virtuous cycle, not only does the number of market participants and developers increase but also the quality; that is, market participants who spend more of the present tokens and developers who list better apps.

[0051] Individuals derive a shared expectation that the fraction of population that are market participants is ζ, and if each of these individuals then makes a decision to become a market participants by purchasing the present tokens based on the above expectation, then the fraction of people who actually end up purchasing the present tokens is ζ.

[0052] This is the self-fulfilling expectations equilibrium for the quantity of purchasers: if the community expects that a percentage of the population of potential consumers will become market participants of the DApp store and spend to buy the present tokens, then this expectation is in turn fulfilled by their behavior.

[0053] Referring to FIG. 1, we can define a function ^ as follows:

If potential consumers expect a ζ fraction of the population to become market participants of the DApp Store then a 1ι(ζ) fraction will become market participants of the DApp Store. The function 1ι(ζ) is the real-world adoption rate based on networking effects.

[0054] Furthermore, if the potential consumer base expects a ζζ fraction of the population will commit and become market participants, then there is potential market participant x who will want to become a market participant provided the reserve price for participation is higher than the amount the potential customer has to pay.

If g(x)¾)≥m* where m* is the cost that the individual must pay.

[0055] Hence, if anyone wants to participate, the set of people who will participate will be between 0 and ζ,

where: ζ is the solution of the following equations Taking the inverse we can obtain ζ:

[0056] This gives us a relationship between the price to be paid to become a market participant and the adoption rate based on network effects. Thus we can drive adoption of the DApp store based on a greater understanding of the dynamics of the relationship between users and developers.

[0057] One or more embodiments give community members the power to vote on important proposals for the network's developmental roadmap. Legacy commerce and social network ecosystems disenfranchise their existing user base, both developers and end users. Instead, these centralized networks of the old internet often leverage user generated data for profit using targeted-ads. As a result, virtually none of the value created by the user is shared with them. That said, blockchain governance can provide utilitarian outcomes if deployed cautiously and strategically.

[0058] An embodiment gives its community of developers and end users the right to actively participate, propose, and vote on the future development of the underlying software.

[0059] Any developer or end user in the present community can submit a proposal for other community members to vote on. In order to generate a proposal for community consideration a minimum is required.

[0060] The amount of token a community member holds is directly proportional to their voting power at any given time. It does not cost tokens to exercise a vote for proposals. The community shall define the cadence for proposal calls and votes.

[0061] Blockchains exist in the digital world and only have access to data that is fed into them. In the blockchain ecosystem, oracles are specialized applications that provide access to external data, essentially feeding the blockchain with information, which is consumed by well-defined smart contracts.

[0062] Oracles setup tunnels for data streams from any viable source ranging from the Bloomberg price feeds to IoT devices. [0063] Smart contracts are built to consume information from oracles. Smart contracts are designed to be triggered depending on events, which are reported to them by oracles, performing pre-programmed tasks based on data inputs. Thus, one of the primary tasks of an oracle is to provide information to smart contracts.

[0064] Most importantly, data provided by any oracle must be trustworthy, essentially this means that smart contracts must be able to trust the reliability of the data source before executing. In the blockchain world transaction rollbacks are not an option. This central issue of data reliability is not dealt with adequately at the moment. Further, there currently is no standard secure oracle protocol that allows oracles to operate cross-blockchain and feed their valuable data into multiple blockchain systems. The present system solves these problems by creating a standardized proof of stake-based protocol that enables developers to easily create oracles that securely input data into the blockchain ecosystem, particularly into smart contracts.

[0065] A proof of stake protocol is used to incentivize oracles to provide correct data and penalize oracles that provide incorrect data. The present system's Universal proof of stake oracle Protocol (PSOP) will require oracles to vest and stake the present tokens before inputting data into the blockchain ecosystem. Oracles that provide incorrect data will be penalized, losing their vested present tokens while oracles that provide correct data will be compensated with the present tokens by data consumers. Any oracles found to be providing incorrect data will lose some portion of their vested and staked tokens. Market designs that incentivize authentication, validation and ultimately successful aggregation of information will be implemented as part of the Proof of Stake Protocol.

[0066] The broad adoption and deployment of oracles will create an additional blockchain monetization method through oracle devices. Oracle pools analogous to mining pools will also develop in which people all around the world combine their oracles into a pool of oracles in order to provide more data to the blockchain ecosystem and better monetize it.

[0067] For example, farmers in Yuanyang County, Yunnan, China could purchase and install temperature sensor oracles to provide distributed and verified temperature data to the blockchain ecosystem. The temperature readings will receive a score based on the number of oracles that agree on the reading. When the temperature data is purchased through an open marketplace the providers and verifiers of the data will receive tokens as compensation. Any farmer providing a single point of temperature data may rarely be compensated for their data if they provide it alone because much like successfully mining a Bitcoin is rare it is rare someone will want a specific temperature data point. However, a temperature oracle pool with world wide temperature coverage will become the standard temperature provider and thus even those that provide rarely used data can be compensated based on how they help complete the dataset instead of just providing a single data point.

[0068] If quality is difficult to ascertain due to information asymmetry, then lower quality oracles will seek to masquerade as higher quality oracles. Smart contracts will take this adverse incentive into consideration and assume that the quality of oracles as a whole is uncertain. Smart contracts would then only pay the present tokens considering the overall average quality of oracles. Thus, if the market fails to distinguish between higher and lower quality oracles, it leads to the higher quality oracles being underpaid and driven out of the market. To overcome this issue will have segmented auctions where only oracles above a predefined quality threshold would be allowed to participate.

[0069] If smart contracts had the ability to tell wheat from chaff, then fair payment could be achieved. There would be segmented markets for higher and lower quality data. If smart contracts can not tell the quality differences, then a single market would form where the smart contracts would be willing to pay only average prices.

[0070] One way to overcome quality issues is to devise a rating mechanism like a quality score. In the forward auction, the smart contracts would be provided with a quality rating based on the oracles past performance and price. Quality scores are aggregated based on past performance, price, and proof of verification. The present system allows audits of oracles. Prequalifying oracle's entry into the auction helps set up a segmented market for oracle data. High fidelity oracles would participate in a separate market from low fidelity and newly minted oracles. One format would run a high-fidelity auction where entry would require a minimum quality score.

[0071] Software oracles provide access to online data like an oracle to trending twitter handles while Hardware oracles provide access to real world data like IoT or RFID data. A further classification is the direction of the data flow with Inbound oracles providing data to the block chain and Outbound oracles providing data to the real world from the block chain. An important subclass are the Consensus oracles which as the name suggests work by consensus. With multiple oracles providing similar data which may have reliability issues, consensus-based rules are used to parse and aggregate the data provided. Example multiple weather IoT devices provide temperature readings and a consensus temperature reading is calculated. [0072] Consider a game theoretic viewpoint. Here we are interested in the private information that oracles hold and their actions as self-interested rational agents while participating in a market to sell their data.

[0073] Let N = {0,1, njdenote a list of oracles in an auction of data on the blockchain. In one embodiment this would be a reverse or procurement auction, where '0' denotes the auctioneer. Let t be a vector of the type profiles of all the oracles. So t =

(t¹, t², , t^N ) includes a type for each oracle. Type t^l represents all the value, information, beliefs, utility and preferences of the oracle i.

[0074] Oracles with independent private values: In game theory parlance oracles whose valuations of the data they supply only depends on their own typet and the types are statistically independent. Further the valuations are privately held by the oracles and not publicly known. They are not affected by other competing oracles during participation in the data smart market. This independence in valuation leads to a strong dependence between the bids placed in the reverse auction and the private valuations of the oracle.

[0075] Oracles with interdependent values do not know their own valuations themselves, they are prone to mimic valuations of competing oracles, more strongly the distribution of types tof the oracles are statistically dependent. This leads to a weaker relationship between the bids placed and the actual valuations. Oracles who want to supply data may be required to sign a contract with an ancillary staker that verifies, validates and authenticates the oracle's data and then stakes the present system on behalf of the oracle, to participate in the auction. In case of issues in the data, the ancillary staker is held responsible.

[0076] Ancillary Stakers: Ancillary stakers are essentially a kind of smart contract with a specialized role in the proof of stake oracle Protocol. Stakers are third parties: independent from the oracles, whose primary job is to validate oracle data and stake their present tokens reputation on the data, for which they can charge oracles a percentage cut of the proceeds from the sale of the data. Stakers are like reverse insurance agents. This is the scenario where the oracle may not be willing to stake on its own.

[0077] Some other situations and kinds of smart contracts arise and are also part of the proof of stake oracle Protocol. Intermediary smart contracts who buy data from oracle, process it and resell to other smart contracts or outbound oracles. This may take place under the intermediary's brand and represents a kind of white labeling. Insurance smart contracts provide insurance to other smart contracts with the underlying being the quality of data they are buying.

[0078] Premium auctions: A bid specifies the premium rate that a smart contract can add in addition to the onward sale of data supplied by newly minted oracles. New oracles sell their data at such auctions which are bought by ancillary stakers and intermediary smart contracts for processing and onwards sale under a white-label equivalent arrangement. The white labeled data would have a higher quality rating.

[0079] These are implemented as combinatorial or package auctions.

[0080] Referring to FIG. 2, Blockchain smart markets are auctions harnessing blockchain technology that clear periodically. Transactions take place between distinct pools of smart contracts acting as buyer and sellers rather than bilaterally. Pools of oracles may also participate but may be restricted to being sellers. Decentralized smart contracts submit bids to buy and offers to sell data or services in a commoditized manner. The whole process is managed by an 'auctioneer'. Clearing the market usually involves the auctioneer solving complex mathematical optimization problems with arbitrary constraints periodically to maximize the gains from trade. Smart markets are designed to reduce transaction costs significantly and eliminate externalities while allowing for competition not possible in more traditional settings.

[0081] Smart markets allow for coordination between diverse smart contracts which is usually only possible under monopoly conditions. This coordination ability is a natural complement to the blockchain world.

[0082] The use of cryptocurrencies and distributed ledgers allows for the implementation and operation of complex smart markets with ever larger number of participants.

[0083] The time period of smart markets is the time between successive instances of the market clearing. It may range from a few milliseconds to a few days. Markets include one sided forward auctions (demand only), one sided reverse auctions (supply only) and two- sided auctions with supply and demand components.

[0084] An embodiment implements blockchain smart markets protocol that allow auctioneers, market designers and game theorist to work in sync with developers to easily design and quickly deploy smart markets to enable the trade of commoditized data and services in a secure and transparent manner. [0085] A smart market for the sale of oracle data may rely on both the Oracle Proof of Stake Protocol and the blockchain smart markets protocol. A blockchain smart markets protocol implements and runs markets for decentralized cloud services including file storage and cloud computing.

[0086] Game theory is concerned with the mathematical modeling strategic behavior of market participants under specified rules. It is the part of economics concerned with the detailed rules and procedures of economic institutions (like markets and auctions). Contracts are games designed by the principal and played by the agents, which are the other oracles and smart contracts with the monetary transfer being in a crypto-token. Auctions are games designed by the auctioneer and played by the bidders.

[0087] Economists not only analyze markets, but design or engineer them. Mechanism design, often called reverse game theory takes an engineering viewpoint towards designing a market that achieves desired objectives given strategic settings with rational players. Market design: Engineering approach to design markets towards desired objects in strategic settings with rational players. Includes efficiency of the auction design, optimal and equilibrium bidding strategies, and revenue comparison. Fairly accommodating all participants' needs is critical.

[0088] An embodiment provides for the trade or exchange of information, using the blockchain infrastructure, between oracles and smart contracts. This market uses the proof of stake oracle protocol and the blockchain smart markets protocol. One or more embodiments provide the following features:

• Facilitate an efficient exchange of information between oracles and smart contracts

• Minimize false, invalid data. Only authentic, validated data is exchanged.

• Simple to understand and participate. Transparent (or easy to replicate outcomes) and with similar outcomes in repeated trials.

• All monetary transfers are settled in the present system's tokens.

• All data is encrypted and added to the blockchain and information exchange is accomplished through the transfer of encryption keys between oracles and smart contracts.

• Minimize false, invalid data. Only authentic, validated data is exchanged.

• Incentivizes oracles to get data. Auctions are Voluntary or Individually Rational. Bidders incentivized to participate. Participants are at least better off taking part in the auction. • Incentive-Compatible: Minimize strategic behavior, honesty is the best or dominant strategy for all participants. Avoid windfalls for bidders and winner's curse problem.

• Simple to understand and participate in auction. Transparent and easy to replicate.

[0089] Referring to FIG. 3, a two sided auction determines prices with some contractual language that guarantees data authenticity. Information supplied by oracles would be encrypted and fed to the blockchain. The encryption keys would then be sold to smart contracts which want to access the data, after which the oracles would be paid for their information. This is implemented using an auction as follows.

[0090] Information or IoT device data is 'produced' according to predefined terms in the auction contract. Data integrity, authenticity and validity requirements are part of the terms that govern the auction. This is made available by 'oracles', encrypted and added onto the blockchain. Encryption keys are sold at auction. RSA is used to encrypt the data.

[0091] An auction Private and Public key is created. The Public key is declared and added to the blockchain.

[0092] Oracles desiring to take part in the auction add data to the blockchain and encrypt it using the auctioneer's public key (in an embodiment, the auctioneer is the oracle). The winning smart contracts are then provided with private keys to decrypt the data after the auction ends.

[0093] Any and all transfers as part of the auction are settled in tokens. In case the oracle sells multiple copies, then the data is encrypted with a public key and the private key is sold multiple times. Encryption keys are transferred to winning smart contracts after payment in t~'— s. Smart contracts consume the data and have a fixed time to report any violations of terms. Oracles are paid after the expiry of this time period.

[0094] Step 1 : Forward Auction: Incentive Compatible Direct Mechanism for the sale of Information is required and the present system uses a modified Combinatorial VCG Auction is used. The auction allows multiple keys for the same data set to be sold. Smart contracts may bid additional amounts to restrict sale of additional keys.

[0095] Step 2: Reverse Auction: To run a reverse

(procurement auction) to buy data from oracles. Simultaneous Descending (Dutch) auction is used to select oracles which would be selling the data to smart contracts. Reserve price (opening price in case of the dutch auction) is set according to the closing price in the forward auction plus a markup. The initial price (or the effective reserve price) is the clearing price in the forward auction plus a markup.

[0096] Step 3 : Clearing Price: The present system combines bids in the reverse and forward auction to determine how many and which combination of keys to sell.

[0097] Encryption keys would be sold at a forward auction using a modified combinatorial auction version of the weighted Vickrey-Clarke-Groves mechanism. A game set-up for VCG auction of oracle data to smart contracts is below.

[0098] Given the following:

[0099] Consider a list of smart contracts participating in an auction of data. Let N = {0, 1, ... . Ν} denote the smart contracts taking part in the auction, with 0 denoting the auction operator. The auction operator is a type of a smart contract or a combination of a distributed demand and supply side platform.

[0100] Let t be a vector of the type profiles of all the smart contracts.

i = {';·' ≠ ≠* \

[0101] So ^{" * *} includes a type for each smart contract.

[0102] Type t represents all the value, information, beliefs, utility and preferences of the smart contract i.

[0103] Possible outcomes are (X, B):

[0104] Let X denote the set of all possible decisions in the auction.

[0105] An outcome in the auction is denoted as (x, B):

a. where

^~m = (n .. wr* )

1.

[0106] ^>¾* denotes a vector of positive or negative payments between smart contracts including the auctioneer and is measured in the present tokens.

[0107] Every smart contract values the outcome of the auction and we denote smart contract z's value as V(x,t^l). The value is dependent on the outcome of the auction and the type t of the smart contract. Further the utility that the smart contract i derives from auction is:

m). t) = -fjf, f ) - :?is^;

[0108] Given the assumptions and denotations above, and based on our stated market design goals, we must achieve allocative efficiency. Allocative efficiency denoted by the decision x*is achieved if the auction decision maximizes the total value of the allocation. [0109] Further for budget balance, the auction should not produce a net loss. The limiting condition in this case is:

jfj⁵ = Q

* X ' = G

[0110] Therefore the auctioneer denoted as smart contract 0 solves the following optimization problem to determine the outcome of the auction along with the constraints above:

wgm x.^ Y v^!(x, f)

[0111] This represents an incentive compatible direct mechanism that leads to the highest value smart contract winning the auction and paying its negative externality in the form of a payment measured in terms of the present tokens.

[0112] In the VCG auction, If any smart contract i reports a type

the VCG mechanism charges this smart contract a penalty if his report changes the optimal allocation x* thereby hurting other smart contracts.

[0113] This extra payment is specified to compensate the remaining smart contracts N - i for their loss on account of smart contract i. This is exactly the negative externality of the smart contract.

[0114] The auction mechanism at equilibrium is incentive compatible. Weakly dominant strategy for each smart contract is to truthfully bid its true value. This is functionally equal to a second price auction. [0115] An embodiment of the invention maximizes the revenue from the auction. Same data can be sold multiple times or equivalently multiple private encryption keys to the same data can be sold. The analog of this in the non-blockchain world is the sale of mp3 songs at a digital music store. This leads to some fundamental questions. How should bids be combined to determine the quantity transacted? Should the effect of bids on quantity transacted be recognized in the reverse auction incentive analysis?

[0116] This analysis depends on the type of data and the values of the smart contracts bidding for the data.

[0117] Smart contracts will have the ability to be sole consumers of the data available at auction by outbidding the sum of all the competing bids. The number of tokens required to buy oracle data at equilibrium, essentially the clearing price, is set by the oracles as a response to smart contract demand. This endogeneity of the quantity of data traded holds true even in a two-sided auction.

[0118] Referring to FIG. 4, an embodiment conducts a second price auction where the winning smart contract pays the second highest bid. For example: consider 1 oracle selling a single instance of a data set with three smart contracts bidding. Only one copy of the data is to be sold at auction.

[0119] The highest bidder S.C. #1 wins the auction and gets the private encryption key of the oracle data set, but only pays the second highest bid incremented once. In this scenario the highest bidding smart contract is charged the minimum bid it needed to rank above its closest competitor and win the contract.

[0120] This ensures that smart contracts bid their true actual private values and that there are no incentives for smart contracts to place bids much lower than their actual values.

[0121] In an embodiment, and referring to FIG. 5, multiple keys to the same data can be sold. The Oracle may sell the same data multiple times. This can be easily accomplished by selling multiple private encryption keys.

[0122] For example: Forward auction for the sale of IoT data supplied by five distinct oracles, only two encryption keys are to be sold per oracle. Three smart contracts participate.

[0123] Smart contracts place binary demand tuples of the keys that they want, where a 1 indicates wanted and 0 indicates not wanted.

[0124] The winning smart contract pays its bid unless there is a lower winning bidder. If there is a lower winning bidder then the winning smart contract pays the lower bidders price. [0125] Referring to FIGS. 6 and 7, and in an embodiment, the smart contracts can have the option to block further sales by paying an increment called the blocking increment. The blocking increment is the sum of all the blocked bids.

[0126] Only highest value bidders are allowed to block, if the blocking smart contract is not the highest bidder then the blocking bid is treated as a normal bid.

[0127] STEP 1 : The auction is run as if no blocking takes place, and second price payments are calculated.

[0128] STEP 2: Blocking increment is calculated as the sum of all blocked winning bids.

Blocking is iemsnt = y. m*

[0129] STEP 3: All blocked winning bids are then added to the blocking winners payments calculated in STEP 1. The blocked winners bids are decremented appropriately from their payments.

[0130] Blocking Winner Payment = Second price bid + Blocking increment

[0131] Blocked Winner Payment = Second price bid - Blocked increment

[0132] Additionally, in the combinatorial auction, oracle data is priced incrementally.

[0133] Thus, any smart contract buying oracle data will automatically be charged the blocking increment for the section of data that no other smart contract ends up buying.

[0134] Smart contracts place demand tuples of the keys that they want, where 1 indicates wanted, 0 indicates not wanted, X indicates blocking.

[0135] Revenue Equivalence: Both auctions with blocking and without blocking yield the same revenue. This is important to avoid any adverse incentives to manipulate bids by the blocking winner to pay lower amounts.

[0136] If blocking is not an option and only complete sets of oracle data are to be traded. This represents the scenario where k private encryption keys of oracle data are available for sale, with N smart contracts wanting to buy exactly one key. Under VCG auction rules: [0137] In the case of unlimited supply, the keys sell for zero under VCG conditions. Further the VCG mechanism implies that every key is simply sold for the amount of the k + 1st highest bid if we can restrict the number of keys being auctioned to less than the number of bidders.

[0138] The first key may actually be very expensive to produce but oracles can produce additional keys at zero marginal cost hence there is effectively an unlimited supply of encryption keys. The oracles do not have any supply restrictions other than those they voluntarily impose themselves or restrictions imposed by the auctioneer. The oracles and the auctioneer actually will have to artificially reduce supply in order to increase revenues.

[0139] Given a truthful valuation reporting mechanism an optimal single price m* and optimal quantity of encryption keys k* for clearing the auction with maximum revenue is solved as follows:

[0140] Let there be N smart contracts with values V arranged as an ordered set such that:

^: * v

[0141] The optimal singleton price is the k* + 1th highest bid which in the VCG mechanism is the value of the k* + 1th highest bidding smart contract.

[0142] An approximate auction in the absence of a truthful ordering of values or a very large number of smart contracts can be done by randomly sampling valuations.

[0143] The random sampling optimal price auction game may be played as follows:

[0144] Step 1 : Randomly partition the smart contracts N into two sets Nl and N2.

Such that each smart contract has probability = -of being randomly assigned to one of the sets and [0145] Step 2: Using the above procedure find payments ^" the optimal singleton prices for each set.

[0146] Step 3: Clearing prices and allocations are calculated as follows:

Vi≡ m s£ > m ;

Snaast contact i w^' & a single key aed pays = m ΐ

[0147] Similarly,

S:mari contract j wms a single ke and pays m = m

[0148] Random sampling optimal price auctions are dominant-strategy truthful, weakly budget balanced and ex post individually rational.

[0149] If a minimum two keys are sold at auction then it can be shown that in this random sampling optimal price auction game

Expected Total Revenue ≥ _j m^*

[0150] Button auctions are those where the only options for a smart contract is to decide when to withdraw from the auction. The block button auction is a demand side forward auction when static oracle data supply is available. Smart contracts are the participants and are assisted by demand side distributed platforms. All transactions are settled and are settled in the next block created at the end of the auction.

[0151] In the block button auction, any participating smart contract has one choice to make, whether to participate in the next block or drop out. Once a smart contract drops out there is no re-entry. The last smart contract remaining wins the auction. Each round the bids and demand tuples change.

[0152] At the start all interested smart contracts are participants and the oracle data price is its reserve price. After each new block is created the price increments by a fixed amount.

[0153] If a smart contract is willing to pay the current block price it must keep participating, otherwise the smart contract drops out of the auction. Re-entry is strictly prohibited. If in any block there is only one smart contract remaining then that smart contract is the winner. The accounts are settled in the next block created with the exchange of private encryption keys for final display price.

[0154] Suppose a smart contract has a private value v for the data. Then its dominant strategy is to participate till the block price exceeds v.

[0155] This leads to an incentive compatible truthful mechanism: smart contracts will act on their private true value, regardless of other participating smart contracts.

[0156] At equilibrium all smart contracts play their dominant strategies, the outcome is:

• The winning smart contract is the buyer with the highest valuation.

• The final block price is the second highest smart contract's valuation.

[0157] In a simultaneous descending auction, situations may arise where different smart contracts have differing preferences on the packaging of oracle data sets or where auction requirements lead to intractable constraints on the auction optimization problem. In such scenarios a package auction may lead to better results like more participants, higher revenues and more efficient allocations.

[0158] Referring to FIG. 8, an embodiment includes a Real Time Intra-block Bidding arrangement. This arrangement includes applications in an IoT Data Marketplace and Demand and supply side distributed platforms. Real-time block bidding is the buying and selling of oracle data through real-time auctions that occur in the time it takes a new block to be added to the blockchain.

[0159] All transactions are settled in tokens and must complete before the next block is created.

[0160] Those auctions are to be facilitated by supply-side distributed platforms, which are designed to assist oracles to sell their data. Here the entire trade may take place within the time it takes to create a new block.

[0161] An embodiment may include a cloud-file storage market apart from long-term contracts. A simple order matching market suffices for long-term contracts. These may be termed as Look Ahead markets for Cloud file storage.

[0162] Referring to FIG. 9, consider a Day Ahead market. Market to rent and host storage space for the next calendar day in 15 minute blocks. It is a closed double-sided anonymous auction for each 15 minute blocks for the following day. [0163] Referring to FIG. 10, a Term Ahead Market provides for trade in storage 15 min after settlement time. This is carried out for each 15 min block in the term ahead or the day ahead market.

[0164] Buy Side

[0165] Interested buyers specify requested durations, level of data redundancy and maximum buying price.

[0166] Sell Side

[0167] Sellers specify the time blocks, capacity in TB, minimum price and Bandwidth charges.

[0168] All sellers are required to provide stakes as collateral against defaulting on their potential contracts. The stake sizes are fixed by the auctioneer and pro-rated according to TB.

[0169] Market Clearing

[0170] At the end of the current trade/call period, the bid and ask orders are accumulated to determine market clearing price and market clearing volume. Orders are matched after each call period. An equilibrium or clearing price is calculated and all orders are settled at this clearing price.

[0171] Referring to FIG. 11, a supply and demand curve may be plotted: All the asks are ranked in order of increasing price and the supply curve is plotted and all the bids are ranked in decreasing order of price and plotted. This is the supply-demand curve.

[0172] Market clearing is the point of intersection of the demand and supply curves. The price at that point represents the market clearing price or the equilibrium price and the quantity at that point is the market clearing volume. All the bids submitted at a price lower than or equal to the market clearing price are accepted. Similarly, all the offers submitted at a price greater than or equal to the market clearing price are accepted. P* represents the market clearing price, and Q* represents the market clearing volume.

[0173] A swaps agent is also run by the market manager to manage a long term market. The swaps agent enters a contract with a supplier/buyer of storage space to provide a fixed rate while collecting the variable market rate. Swaps may be bought on nominal amounts (actual market participation is not required). Settlement is done on a marginal basis. This allows participants to get fixed prices rather than pay floating daily spot prices.

[0174] While the present disclosure has been described in terms of particular embodiments and applications, summarized form, it is not intended that these descriptions in any way limit its scope to any such embodiments and applications, and it will be understood that many substitutions, changes and variations in the described embodiments, applications and details of the method and system illustrated herein and of their operation can be made by those skilled in the art without departing from the scope of the present disclosure.

Claims

What is claimed is:

1. A method of conducting a decentralized auction, comprising the steps of: accessing a data set with at least one oracle; creating at least one auction private key and an auction public key; encrypting the data set with the at least one oracle using the public key; submitting the encrypted data set on a blockchain to at least one auctioneer; receiving, with the auctioneer, bids for the at least one private key from a plurality of smart contracts on the blockchain, the at least one private key being configured to decrypt the encrypted data set; determining, with the auctioneer, from the bids a winning smart contract of the plurality of smart contracts; receiving a payment associated with the winning smart contract; and providing the at least one private key to the winning smart contract.

2. The method of claim 1 , wherein the auctioneer comprises the at least one oracle.

3. The method of claim 1 , further comprising providing the at least one private key to only the winning smart contract if the bid associated with the winning smart contract exceeds the sum of the bids of all of the other smart contracts of the plurality of smart contracts.

4. The method of claim 1 , wherein: the winning smart contract provides the highest bid; and the payment equals the second highest bid plus a predetermined incremental amount.

5. The method of claim 1, wherein: the at least one auctioneer comprises a plurality of auctioneers, each auctioneer of the plurality of auctioneers providing N private keys of the at least one private key; and the method further comprises receiving from each of the plurality of smart contracts a binary demand tuple indicating the at least one private key on which each of the plurality of smart contracts desires to bid, if, for a given at least one private key there is no lower winning bidding smart contract, the highest-bidding smart contract pays its bid, and if, for the given at least one private key there is a lower winning bidding smart contract, the highest-bidding smart contract pays the lower winning bidding smart contract bid plus a predetermined incremental amount.