Methods and devices for providing privacy-preserving blockchain-based auctions
By generating and dividing private key fragments on the blockchain and using smart contracts to manage the bidding process, the problems of privacy protection and automated settlement in Dutch auctions are solved, enabling a secure and fair IPO process.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-01-29
- Publication Date
- 2026-03-10
AI Technical Summary
Existing Dutch auctions rely on trusted third parties for secure and fair processing during a company's initial public offering (IPO), lack privacy protection, and cannot automate the bidding process.
By using blockchain technology, public and private key pairs are generated, the private key is divided into multiple fragments and shared with multiple key holders, the bidding process is managed by smart contracts, and the auction results are automatically settled by reconstructing the private key at the end of the auction, thus ensuring data security and privacy protection.
It enables the secure and immutable recording and processing of the bidding process on the blockchain, protecting bidder privacy, ensuring the fairness and automation of auctions, and reducing reliance on trusted third parties.
Smart Images

Figure CN115280352B_ABST
Abstract
Description
Technical Field
[0001] This specification relates generally to computer technology, and more specifically to methods and devices for providing privacy protection in blockchain-based auctions. Background Technology
[0002] A Dutch auction refers to a public offering auction, in which the price of the item is set after all bids have been received and the highest possible price for the item to be sold has been determined. Dutch auctions can be used for other types of items for sale, including, for example, financial statements, notes, bonds, and properties.
[0003] When using a Dutch auction for an initial public offering (IPO), the company offering shares does not set a fixed price for its shares. Instead, the company decides the number of shares to be issued and allows bidders (investors) to determine the price. Investors submit bids indicating the number of shares they wish to purchase and a specific bid price. All bids received during the auction period are collected and processed to determine the highest price at which all the shares offered by the company can be sold. Once the price is determined, the company can allow investors to purchase the issued shares at the determined price. All investors can pay the same price for the issued shares.
[0004] Currently, IPOs conducted using the Dutch auction method are handled by a trusted third party. This trusted third party must be trusted by both the company offering the IPO and the investors bidding on it. The trusted third party is also responsible for ensuring that each auction is conducted securely and fairly. Summary of the Invention
[0005] In one aspect, a computer-implemented method for providing privacy-preserving blockchain-based auctions includes: receiving data representing one or more assets offered for auction and a set of parameters for the auction from a first user; receiving one or more cryptographic bids from one or more second users; receiving multiple shared fragments of a private key from multiple third users; reconstructing the private key based on the multiple shared fragments received from the multiple third users, the reconstructed private key being configured to decrypt the received cryptographic bids; and automatically settling the auction based on the parameters for the auction, the received cryptographic bids, and the submission time of receiving the cryptographic bids.
[0006] On the other hand, an apparatus for providing privacy-preserving blockchain-based auctions includes: one or more processors; and one or more computer-readable storage devices coupled to the one or more processors and having instructions stored thereon, the instructions being executable by the one or more processors to: receive from a first user data representing one or more assets offered for auction and a set of parameters for the auction; receive one or more cryptographic bids from one or more second users; receive multiple shared fragments of a private key from multiple third users; reconstruct the private key based on the multiple shared fragments received from the multiple third users, the reconstructed private key being configured to decrypt the received cryptographic bids; and automatically settle the auction based on the parameters for the auction, the received cryptographic bids, and the submission time of receiving the cryptographic bids.
[0007] In another aspect, a non-transient computer-readable medium has instructions stored therein that, when executed by a device's processor, cause the device to perform a method for providing privacy-preserving blockchain-based auctions. The method includes: receiving from a first user data representing one or more assets offered for auction and a set of parameters for the auction; receiving one or more cryptographic bids from one or more second users; receiving multiple shared fragments of a private key from multiple third users; reconstructing the private key based on the multiple shared fragments received from the multiple third users, the reconstructed private key being configured to decrypt the received cryptographic bids; and automatically settling the auction based on the parameters for the auction, the received cryptographic bids, and the submission time of receiving the cryptographic bids. Attached Figure Description
[0008] The accompanying drawings are incorporated in and form a part of this specification, and illustrate embodiments. In the following description with reference to the accompanying drawings, unless otherwise indicated, the same reference numerals in different drawings denote the same or similar elements.
[0009] Figure 1 This is a schematic diagram of a blockchain system according to an embodiment.
[0010] Figure 2 This is a schematic diagram of a computing device for implementing nodes in a blockchain system, according to an embodiment.
[0011] Figure 3 This is a flowchart of a blockchain-based auction method for providing privacy protection, according to an embodiment.
[0012] Figure 4 This is a flowchart of a blockchain-based auction method for providing privacy protection, according to an embodiment.
[0013] Figure 5 This is a block diagram of an apparatus for providing privacy protection for a blockchain-based auction, according to an embodiment. Detailed Implementation
[0014] This specification provides embodiments of a method and apparatus for providing privacy-preserving blockchain-based auctions. The method and apparatus allow a first user of the blockchain system (referred to as the offeror) to generate a public-private key pair to facilitate the bidding process. The method and apparatus allow the offeror to divide the private key into N fragments and share these fragments with multiple third users of the blockchain system (referred to as key holders). The method and apparatus also allow the offeror to set parameters for the auction and record the auction on the blockchain system. The method and apparatus can record the auction in a smart contract, which can be used to collect bids submitted by one or more second users of the blockchain system (referred to as bidders) during the bidding process. At the end of the bidding process, the method and apparatus can request at least a subset of the key holders to provide fragments of their shared private keys to the smart contract, enabling the smart contract to reconstruct the private keys to decrypt the bids submitted by the bidders and settle the auction results.
[0015] The embodiments disclosed in this specification have one or more technical effects. In some embodiments, the methods and devices record and facilitate auctions on a blockchain system. This allows the methods and devices to ensure that auction-related data can be stored securely and immutably. In some embodiments, the methods and devices allow the offeror to divide their private key into N fragments and, for example, share fragments of the private key with multiple key holders using Shamir's secret sharing scheme. This allows the methods and devices to provide protection for the private key generated by the offeror. In some embodiments, the methods and devices utilize smart contracts to manage the bidding process and collect cryptographic bids submitted by one or more bidders during the bidding process. This allows the methods and devices to automate the bidding process without relying on the trust of any single party. This also allows the methods and devices to record and track all bids in a secure and immutable manner and allows for efficient auctions. In some embodiments, the methods and devices may request at least a subset of key holders to provide their shared private key fragments to the smart contract, such that the smart contract can reconstruct the private key and use the reconstructed private key to settle the auction results. This allows the method and apparatus to protect privacy and the confidentiality of received bids, as no key holder can independently decrypt any received bid. In this way, bidders are not allowed to see the bids of other bidders, thus effectively protecting bidder privacy and ensuring the fairness of the auction.
[0016] A blockchain system, also known as a distributed ledger system (DLS) or consensus system, enables participants to store data securely and immutably. A blockchain system can include any DLS without referencing any specific use case and can be used in public, private, and consortium blockchain networks. Public blockchain networks are open to all entities to use the system and participate in the consensus process. Private blockchain networks are provided to specific entities, which centrally control read and write permissions. Consortium blockchain networks are provided to a selected group of entities, which control the consensus process, and consortium blockchain networks include an access control layer.
[0017] Blockchain systems are implemented using peer-to-peer (P2P) networks, where nodes communicate directly with each other, eliminating the need for a fixed central server. Each node in a P2P network can initiate communication with another node in the network. A blockchain system maintains one or more blockchains.
[0018] A blockchain is a data structure that stores data (e.g., transactions) in a way that prevents malicious parties from tampering with and manipulating the data. Transactions stored in this way can be immutable and subsequently verified. A blockchain consists of one or more blocks. Each block is linked to the preceding block in the blockchain by including the cryptographic hash of the block immediately preceding it. Each block may also include a timestamp, its own cryptographic hash, and one or more transactions. Transactions that have typically been verified by nodes in the blockchain system can be hashed and encoded into a data structure such as a Merkle tree. In a Merkle tree, the data at the leaf nodes of the tree is hashed, and all hashes in each branch of the tree can be concatenated at the root of the branch. This process continues upwards along the tree to the root, which stores hashes representing all the data in the tree. The hash of a transaction claimed to be stored in the tree can be quickly verified by determining whether it is consistent with the structure of the tree.
[0019] A blockchain system comprises a network of computing nodes that manage, update, and maintain one or more blockchains. This network can be a public blockchain network, a private blockchain network, or a consortium blockchain network. For example, many entities (such as hundreds, thousands, or even millions of entities) can operate in a public blockchain network, and each entity operates at least one node in the public blockchain network. Therefore, a public blockchain network can be considered a public network concerning participating entities. Sometimes, a majority of entities (nodes) must sign each block for it to be valid and added to the blockchain network. Examples of public blockchain networks include specific peer-to-peer payment networks that utilize distributed ledgers, referred to as blockchains.
[0020] Typically, public blockchain networks support public transactions. Public transactions are shared by all nodes in the public blockchain network and stored in the global blockchain. The global blockchain is a blockchain replicated across all nodes, and all nodes reach a consensus on a perfect state regarding the global blockchain. To achieve consensus (e.g., agreeing to add a block to the blockchain), consensus protocols are implemented in public blockchain networks. Examples of consensus protocols include Proof-of-Work (PoW) (e.g., implemented in some cryptocurrency networks), Proof-of-Stake (PoS), and Proof-of-Authority (PoA).
[0021] Typically, a private blockchain network can be provided to a specific entity, which centrally controls read and write permissions. This entity controls which nodes are allowed to participate in the blockchain network. Therefore, private blockchain networks are often referred to as permissioned networks, which impose restrictions on who is allowed to participate in the network and their level of participation (e.g., only in certain transactions). Various types of access control mechanisms can be used (e.g., existing participants vote on adding new entities, and the governing body controls access).
[0022] Typically, consortium blockchain networks can be private among participating entities. In a consortium blockchain network, the consensus process is controlled by an authorized set of nodes, one or more of which are operated by the respective entities (e.g., financial institutions, insurance companies). For example, a consortium of ten (10) entities (e.g., financial institutions, insurance companies) can operate a consortium blockchain network, with each entity operating at least one node within the consortium blockchain network. Therefore, a consortium blockchain network can be considered a private network with respect to the participating entities. In some examples, each entity (node) must sign each block to make the block valid and added to the blockchain. In some examples, at least a subset of the entities (nodes) (e.g., at least seven entities) must sign each block to make the block valid and added to the blockchain.
[0023] Figure 1 A schematic diagram of a blockchain system 100 according to an embodiment is shown. (Reference) Figure 1 The blockchain system 100 may include multiple nodes, such as nodes 102-110, configured to operate on the blockchain 120. Nodes 102-110 may form a network 112, such as a peer-to-peer (P2P) network. Each node 102-110 may be a computing device, such as a computer or computer system, configured to store a copy of the blockchain 120, or may be software, such as a process or application, running on the computing device. Each node 102-110 may have a unique identifier.
[0024] Blockchain 120 can include a growing list of records in the form of data blocks, such as Figure 1Blocks B1-B5 in the block. Each block B1-B5 may include a timestamp, the cryptographic hash of the previous block, and the data of the current block, which may be transactions such as currency transactions. For example, ... Figure 1 As shown, block B5 may include a timestamp, a cryptographic hash of block B4, and transaction data for block B5. Furthermore, for example, a hash operation can be performed on a previous block to generate a cryptographic hash of that previous block. The hash operation can use a hash algorithm (such as SHA-256) to convert inputs of various lengths into a fixed-length cryptographic output.
[0025] Nodes 102-110 can be configured to perform operations on blockchain 120. For example, when a node (e.g., node 102) wants to store new data on blockchain 120, it can generate a new block to be added to blockchain 120 and broadcast that new block to other nodes in network 112 (e.g., nodes 104-110). Based on the validity of the new block, such as the validity of its signature and transactions, other nodes can determine to accept the new block, allowing node 102 and other nodes to add the new block to their respective copies of blockchain 120. As this process is repeated, more and more data blocks can be added to blockchain 120.
[0026] Figure 2 An example of implementing a node (e.g., node 102) in a blockchain system is shown according to an embodiment. Figure 1 A schematic diagram of the computing device 200. (See reference) Figure 2 The computing device 200 may include a communication interface 202, a processor 204, and a memory 206.
[0027] Communication interface 202 facilitates communication between computing device 200 and other nodes in the network (e.g., nodes 104-110). Figure 1 Communication between devices. In some embodiments, communication interface 202 is configured to support one or more communication standards, such as Internet standards or protocols, Integrated Services Digital Network (ISDN) standards, etc. In some embodiments, communication interface 202 may include one or more of the following: local area network (LAN) card, cable modem, satellite modem, data bus, cable, wireless communication channel, radio-based communication channel, cellular communication channel, Internet Protocol (IP) based communication device, or other communication device for wired and / or wireless communication. In some embodiments, communication interface 202 may be based on public cloud infrastructure, private cloud infrastructure, or hybrid public / private cloud infrastructure.
[0028] Processor 204 may include one or more dedicated processing units, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or various other types of processors or processing units. Processor 204 is coupled to memory 206 and configured to execute instructions stored in memory 206.
[0029] Memory 206 can store processor-executable instructions and data, such as copies of blockchain 120. Figure 1 Memory 206 may include any type of volatile or non-volatile memory device or combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, or magnetic disk or optical disk. When instructions in memory 206 are executed by processor 204, computing device 200 can perform operations on blockchain 120.
[0030] Figure 3 A flowchart of a blockchain-based auction method 300 for providing privacy protection, according to an embodiment, is shown. (Reference) Figure 3 Multiple users can access the blockchain (e.g., Blockchain 120). Figure 1 It has accounts. Blockchain can be implemented to support various types of users or parties, including individuals, businesses, banks, financial institutions, investors, and other types of companies and organizations.
[0031] For illustrative purposes, Figure 3 The document describes multiple users, including offerors, multiple key holders, and multiple bidders, such as first bidder and second bidder. An offeror can be a party offering to sell its assets (such as shares, bonds, or other types of property) through a Dutch auction, such as a company or organization. An offeror can also be an auction house or a broker selling assets on behalf of another entity.
[0032] In step 302, the offeror may generate a public and private key pair to facilitate the bidding process. The offeror may use various types of key generation schemes or cryptographic algorithms to generate the public and private keys. In some embodiments, the public key (PK) may be publicly distributed, while the private key (SK) may be kept secret by the offeror.
[0033] In step 304, the offeror may divide the private key into N fragments and send them to N key holders. In some embodiments, the offeror may divide the private key into N fragments with a threshold k, such that the private key can be reconstructed by knowing k of the N fragments using Shamir's secret sharing scheme. Shamir's secret sharing is a cryptographic algorithm in which a secret is divided into multiple fragments, and each participant is given a secret fragment uniquely shared with themselves. Shamir's secret sharing scheme allows a subset of such participants (e.g., k of the N participants) to reconstruct the original secret. To this end, the offeror may distribute the N fragments to N different key holders. As described below, at the end of the auction, the smart contract can reconstruct the original private key and settle the auction results as long as k of the N key holders provide their shared private key fragments to the smart contract executing on the blockchain.
[0034] In some embodiments, the offeror may choose any user on the blockchain to act as the key holder, and the key holder may or may not be a trusted user. In some embodiments, to ensure that the private key can be reconstructed at the end of the auction, the offeror may require that the total number L of key holders considered honest is greater than half N of the total number of key holders, and L is greater than a threshold k (L>1 / 2×N and L>k). In some embodiments, the offeror may set k to one-third of the total number of key holders (k=1 / 3×N), and the total number of honest key holders is greater than or equal to two-thirds of the total number of key holders (L≥2 / 3×N).
[0035] In some embodiments, the offeror may maintain a list of users whom the offeror considers dishonest (e.g., users who have maliciously or prematurely released their shared secret fragments in the past). Alternatively or additionally, the offeror may maintain a list of users whom the offeror considers honest (e.g., users who have honestly stored their shared secret fragments and participated in the reconstruction of the private key in the past). In step 304, the offeror may use these lists to determine which users can act as key holders. However, it should be understood that the Shamir secret sharing scheme and the relationship between L, k, and N as described above are provided as examples and are not intended to be limiting. It is contemplated that other secret sharing schemes and other configurations can be used to implement step 304.
[0036] In step 306, the offeror may submit a transaction to deposit the assets to be auctioned into a smart contract executed on the blockchain. A smart contract is a computer protocol implemented in the form of computer code incorporated into the blockchain to facilitate, verify, or enforce the negotiation or execution of a contract. For example, blockchain users can program the terms of the agreement into a smart contract using programming languages such as C++, Java, Solidity, Python, etc., and when the terms are met, the smart contract can be automatically executed on the blockchain, for example, to execute a transaction. Also, a smart contract may include multiple subroutines or functions, each of which may be a sequence of program instructions to perform a specific task. A smart contract may be operational code that executes fully or partially without human interaction. In this way, when the auction settles, the smart contract may automatically transfer the deposited assets to one or more bidders.
[0037] In step 306, bidders may also specify parameters for the auction and record these parameters on the blockchain. In some embodiments, the parameters may include S, T n P0 and P t S can represent the total amount provided, which can be expressed as, for example, the total number of shares. T n The auction period can be represented as a duration (e.g., 8 hours after the auction begins) or a specific end time (e.g., an instance of the time when the auction ends). P0 can represent the starting price, which is typically the high bid in a Dutch auction. The smart contract can gradually decrease the price throughout the auction period, and in some embodiments, the smart contract can decrease the price so that the price at the end of the auction is reduced to a specified final price P. t In some embodiments, once the auction begins, the price can linearly decrease from P0 to P during the auction period. t .
[0038] At step 308, the offeror can trigger the smart contract to begin the auction. For example, the offeror can issue a command to start the auction via a function call. The start time of the auction can be represented as T0, after which bidders can instantiate T at any time. i Submit your bid to the smart contract, where T0 <T i <T n In some embodiments, bidders may be required to encrypt their bids using a public key (PK) generated by the offeror at step 302.
[0039] In some embodiments, bidders may submit their bids to indicate the quantity they wish to purchase (e.g., the number of shares). In some embodiments, bidders are not required to indicate a price in their bids. Instead, bidders may choose to submit their bids at a specific time instance Ti, and the smart contract determines the price to be associated with the bid based on its corresponding time instance Ti. In this way, bids submitted at different times can be associated with different prices as the smart contract gradually lowers the price throughout the auction period. In some embodiments, bidders may know the rate at which the price decreases relative to time, as it is T. n P0 and P t The functions, all of which are recorded on the blockchain. In this way, bidders can submit their bids at an appropriate time of their choosing.
[0040] For example, in step 310 and at time instance T1, the smart contract may receive a first encrypted bid from the first bidder. The smart contract may also obtain a first encrypted value R1 from the first encrypted bid, which may represent the encrypted value of a first quantity Q1 that the first bidder wants to purchase. However, because R1 is an encrypted value, no other bidder can determine the actual value of Q1, thus effectively protecting the privacy of the first bidder.
[0041] Subsequently, in step 312 and at time instance T2, the smart contract can receive a second encrypted bid from the second bidder. The smart contract can also obtain a second encrypted value R2 from the second encrypted bid, which can represent the encrypted value of the second quantity Q2 that the second bidder wants to purchase (Q1 and Q2 may be the same or different). Because R2 is an encrypted value, no other bidder can determine the actual value of Q2, thus effectively protecting the privacy of the second bidder.
[0042] The smart contract can continue to receive additional crypto bids from additional bidders. The smart contract can also continue to receive the crypto value R from additional crypto bids. i It indicates that additional bidders want to purchase Q i The encrypted value. In some embodiments, the smart contract can continue to receive additional encrypted bids until the auction period ends at time T. n End. At time T n Afterward, the auction can end, and the smart contract can stop accepting additional bids.
[0043] At step 314, the key holder who has received the shared private key fragment in step 304 can submit the shared private key fragment to the smart contract. In some embodiments, this can be done at time T. n Step 314 is triggered automatically.
[0044] At step 316, the smart contract can collect shared private key fragments from the key holder. Once at least k shared fragments have been collected, the smart contract can reconstruct the original private key, which can then be used by the smart contract to settle the auction.
[0045] To settle the auction, the smart contract can do so based on its corresponding submission time T. i R i All encrypted values are arranged in an ordered list. In some embodiments, the smart contract can, according to R... i The received items are arranged in the order of R. i The encrypted value. The smart contract can then set the cumulative bid quantity Q to 0, and for each encrypted value R... i For i∈{1,2,3,…}, the smart contract can use the reconstructed private key to decrypt R. i Get Q i The value of Q, and Q i The value is added to the cumulative bid quantity Q. The smart contract can repeat this process until Q is reached. i The current value is added to Q so that Q is greater than or equal to the total amount S provided. The smart contract can then determine the value received from Q. i The time instance T of the current value i Smart contracts can also use time instances T. i Determine the price P i And once the price P is determined... i In T i Or in T i Each bidder who previously submitted its bid may enter into a contract to purchase the property at the determined price P. i The number of shares to be bid. In some embodiments, the smart contract can automatically execute the purchase transaction and transfer ownership of the assets stored in the smart contract to the bidder to settle the auction.
[0046] Figure 4 A flowchart illustrating a blockchain-based auction method 400 for providing privacy protection according to an embodiment is shown. Method 400 can be executed by one or more nodes in a blockchain system, for example, nodes 102-110 in blockchain system 100. Figure 1 Nodes 102-110 in blockchain system 100 can interact with the blockchain (e.g., blockchain 120). Figure 1 )) Perform the operation. Blockchain 120 can be implemented as the blockchain in the example above.
[0047] At step 402, a node (e.g., node 102) may receive data representing one or more assets offered for auction using a blockchain-based auction and a set of parameters for the auction. Node 102 may receive data from a first user (e.g., the offeror). Figure 3 )) Receive assets and parameters. In some embodiments, the assets offered for auction may include, for example, shares, bonds, or other types of properties. Parameters may include the total amount of assets offered (S), the auction period (T) n ), starting price (P0) and ending price (P t In some embodiments, node 102 may receive a start command from the offeror and begin the auction.
[0048] In step 404, node 102 can obtain data from one or more users (e.g., bidders). Figure 3 )) Receive one or more crypto bids. In some embodiments, crypto bids are received after the auction begins and before the auction period ends.
[0049] At step 406, node 102 can obtain data from multiple users (e.g., key holders). Figure 3 )) Receive multiple shared fragments of the private key. In some embodiments, multiple shared fragments of the private key may be received after the auction period has ended.
[0050] In step 408, node 102 may reconstruct the private key based on multiple shared fragments received from the key holder. Node 102 may then use the reconstructed private key to decrypt the received cryptographic bid.
[0051] In step 410, node 102 can automatically settle the auction based on the parameters used for the auction, the received crypto bids, and the submission time of the received crypto bids. In some embodiments, node 102 can arrange the received crypto bids based on their corresponding submission times. Node 102 can also decrypt the received crypto bids using the reconstructed private key and identify the i-th bid whose cumulative bid amount (Q) is equal to or exceeds the total amount of assets (S) offered. Then, node 102 can determine the price P. i It can correspond to the time T when the i-th bid is submitted. i Node 102 can be based on the determined price P. i To settle the auction.
[0052] In some embodiments, node 102 can automatically execute transactions and transfer ownership of assets stored in a smart contract to the bidding party to settle the auction. For example, node 102 can identify at time T i Or at time T i The previously received bids, and regarding time T i Or at time T i For each bid received previously, node 102 can determine the specified quantity in the bid, automatically transfer the specified quantity of assets from the offeror to the bidder who submitted the bid, and automatically set the price P equal to the determined price. iThe amount, multiplied by a specified quantity, is transferred from the bidder to the offeror. In some embodiments, node 102 may determine the price P based on the auction period, the starting price, and the ending price. i In some embodiments, the determined price Pi may decrease linearly from the starting price to the ending price during the auction period after the auction begins.
[0053] Figure 5 This is a block diagram of a privacy-preserving blockchain-based auction device 500 according to an embodiment. Device 500 may be a software-processed implementation and may correspond to method 400 ( Figure 4 ). refer to Figure 5 The device 500 may include a receiving module 502, a reconstructing module 504, and a settlement module 506.
[0054] The receiving module 502 can receive data representing one or more assets offered for auction using a blockchain-based auction, and a set of parameters for the auction. The receiving module 502 can also receive one or more cryptographic bids from one or more bidders, and at the end of the auction, receive multiple shared fragments of private keys from multiple key holders. The receiving module 502 can provide the received shared fragments of private keys to the reconstruction module 504, which can reconstruct the private keys. The reconstructed private keys can be used by the settlement module 506 to decrypt the received cryptographic bids and settle the auction.
[0055] In some embodiments, the settlement module 506 can automatically settle the auction based on parameters used for the auction, received crypto bids, and the submission time of the received crypto bids. In some embodiments, the settlement module 506 can arrange received crypto bids based on their corresponding submission times. The settlement module 506 can also decrypt received crypto bids using the reconstructed private key and identify the i-th bid whose cumulative bid quantity (Q) is equal to or exceeds the total amount of assets (S) offered. The settlement module 506 can then determine the price P. i It can correspond to the time T when the i-th bid is submitted. i As described above, the settlement module 506 can base its settlement on the determined price P. i To settle the auction.
[0056] Each of the above modules can be implemented as software, hardware, or a combination of software and hardware. For example, each of the above modules can be implemented using a processor that executes instructions stored in memory. Furthermore, each of the above modules can be implemented, for example, by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the described methods. Additionally, for example, each of the above modules can be implemented using a computer chip or entity, or by using a product with specific functionality. In one embodiment, device 500 can be a computer, and the computer can be a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email receiving and sending device, game console, tablet computer, wearable device, or any combination of these devices.
[0057] The implementation process of the function and role of each module in device 500 can be referred to the corresponding steps in the above method. For simplicity, details are omitted here.
[0058] In some embodiments, a computer program product may include a non-transitory computer-readable storage medium having computer-readable program instructions thereon for causing a processor to perform the methods described above.
[0059] A computer-readable storage medium can be a tangible device capable of storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices (e.g., punch cards or recessed protrusions on which instructions are recorded), and any suitable combination thereof.
[0060] The computer-readable program instructions used to perform the above methods can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages (including object-oriented programming languages and conventional procedural programming languages). The computer-readable program instructions can be executed entirely as a standalone software package on the computing device, or partially on the first computing device and partially on a second computing device located remotely from the first computing device. In the latter case, the second remote computing device can be connected to the first computing device via any type of network, including a local area network (LAN) or a wide area network (WAN).
[0061] Computer-readable program instructions may be provided to the processor of a general-purpose or special-purpose computer or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the methods described above.
[0062] The flowcharts and illustrations in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this specification. In this regard, blocks in the flowcharts or illustrations may represent software programs, code segments, or portions of code, including one or more executable instructions for implementing a specific function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than indicated in the figures. For example, two blocks shown consecutively may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the illustrations and / or flowcharts, and combinations of blocks in the illustrations and flowcharts, may be implemented by a dedicated hardware-based system that performs the specified function or action, or by a combination of dedicated hardware and computer instructions.
[0063] It should be understood that, for clarity, certain features of this specification described in the context of a single embodiment may also be provided in combination in a single embodiment. Conversely, for brevity, various features of this specification described in the context of a single embodiment may also be provided individually or in any suitable sub-combination or suitably in any other described embodiment of this specification. Certain features described in the context of various embodiments are not essential features of those embodiments unless otherwise indicated.
[0064] Although this specification has been described in conjunction with specific embodiments, many alternatives, modifications, and variations will be apparent to those skilled in the art. Therefore, the appended claims encompass all such alternatives, modifications, and variations falling within the terms of the claims.
Claims
1. A computer-implemented method for providing a privacy-protected blockchain-based auction, the method comprising: receiving, from a first user, data representing one or more assets offered for auction and a set of parameters for the auction; receiving, from one or more second users, one or more encrypted bids; receiving, from a plurality of third users, a plurality of shared pieces of a private key; reconstructing the private key based on the plurality of shared pieces received from the plurality of third users, the reconstructed private key configured to decrypt the received encrypted bids; and automatically settling the auction based on the parameters for the auction, the received encrypted bids, and times of submission of the encrypted bids.
2. The method of claim 1, wherein, The set of parameters for the auction includes a total amount of the assets offered, an auction period, a starting price, and an ending price.
3. The method of claim 2, further comprising: receiving a command to start the auction; and starting the auction in response to receiving the command.
4. The method of claim 3, further comprising: receiving the one or more encrypted bids after the auction starts and before the auction period ends.
5. The method of claim 4, further comprising: receiving the plurality of shared pieces of the private key after the auction period ends. Automatically settling the auction further comprises:
6. The method of any one of claims 2 to 5, wherein, arranging the received encrypted bids based on their corresponding times of submission; decrypting the received encrypted bids using the reconstructed private key; identifying an i-th bid whose cumulative bid amount equals or exceeds the total amount of the offered assets; determining a price Pi corresponding to a time Ti at which the i-th bid is submitted; and settling the auction based on the determined price Pi. Settling the auction based on the determined price Pi further comprises:
7. The method of claim 6, wherein, for each encrypted bid received at or before the time Ti: determining an amount specified in a decrypted bid corresponding to the encrypted bid; automatically transferring the specified amount of assets from the first user to a second user who submitted the bid; and automatically transferring an amount equal to the determined price Pi multiplied by the specified amount from the second user to the first user. The determined price Pi is determined as a function of the auction period, the starting price, and the ending price.
8. The method of claim 6, wherein, The determined price Pi decreases linearly from the starting price to the ending price over the auction period after the auction starts.
9. The method of claim 8, wherein, 10. An apparatus for providing a privacy-protected blockchain-based auction, comprising: one or more processors; and one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executable by the one or more processors to perform the method of any one of claims 1 to 9.
11. An apparatus for providing a privacy-protected blockchain-based auction, the apparatus comprising a plurality of modules for performing the method of any one of claims 1 to 9. 12. A non-transitory computer-readable medium having stored therein instructions that, when executed by a processor of a device, cause the device to perform the method of any one of claims 1 to 9.
Citation Information
Patent Citations
McAfee bidirectional auction privacy protection method and auction method
CN107392743A
Digitally encrypted security platform, and methods and systems for the same
CN108292403A