Blockchain-based auction method, apparatus and electronic device

Abstract

The application discloses a blockchain-based auction method, device and electronic equipment. The method is applied to a blockchain node including a first smart contract and a second smart contract, and includes the following steps: receiving a transaction request for calling the first smart contract sent by a buyer, the transaction request including signature information of an auction party and purchase information of the buyer, the signature information including an auction condition of the auction party for a token in the second smart contract, and the purchase information including information that the buyer pays a certain price to the first smart contract to purchase the token in the second smart contract; calling auction transaction logic in the first smart contract, and triggering the auction transaction logic according to the transaction request, wherein the auction transaction logic at least includes the following steps: auctioning the token in the second smart contract according to the auction condition; and the second smart contract authorizing the first smart contract to modify an owner of the token in the second smart contract. The method can improve the flexibility of the blockchain-based auction method.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a blockchain-based auction method apparatus and electronic device. Background Technology

[0002] Blockchain technology refers to a technological solution that collectively maintains a reliable database in a decentralized and trustless manner. It is the underlying technology of digital assets such as Bitcoin and Ethereum. In other words, blockchain technology refers to a way of recording transactions through public participation. Transaction confirmation on the blockchain is achieved through consensus among all nodes on the blockchain. Once consensus is successful, the transaction is packaged and written into a block. The blockchain maintains a public ledger to store all transactions on the blockchain network. Blockchain 2.0, represented by Ethereum, implements more complex distributed contract records, namely smart contracts. A smart contract is a computer protocol designed to disseminate, verify, or execute contracts in an informational way. A smart contract is a set of promises defined in digital form, which control digital assets and contain the rights and obligations agreed upon by the contract participants. It is automatically executed by a computer system. The contract is recorded in the blockchain. Once the contract's triggering conditions are met, the predefined code logic can be executed autonomously, and the result after execution is recorded on the blockchain and cannot be changed. After executing a transaction on a smart contract on the blockchain, the data associated with that transaction can be queried from the ledger maintained by the blockchain and analyzed to obtain details of the transaction. In a business model based on a blockchain network, users can submit business transactions to the blockchain network, triggering each node in the blockchain network to execute the business through smart contracts.

[0003] With the development of blockchain technology, blockchain-based online auctions have gradually become popular. Traditional methods for auctioning objects associated with smart contracts deployed on a blockchain network require deploying an auction contract corresponding to the auction object on the blockchain. This contract includes the auction intent (e.g., auction time and / or auction price), and this intent is pre-defined. If the auctioneer needs to modify the auction object or intent, a new auction contract corresponding to the modified object or intent must be deployed on the blockchain. Therefore, traditional blockchain-based auction methods struggle to flexibly update auction contracts according to actual needs, resulting in an inflexible nature.

[0004] Therefore, there is an urgent need for a blockchain-based auction method that can improve the flexibility of blockchain-based auction methods. Summary of the Invention

[0005] This application provides a blockchain-based auction method, apparatus, and electronic device that improves the flexibility of blockchain-based auction methods.

[0006] A first aspect of this application provides a blockchain-based auction method applied to a blockchain node including a first smart contract and a second smart contract. The method includes: receiving a transaction request from a buyer to invoke the first smart contract, wherein the transaction request includes the auctioneer's signature information and the buyer's purchase information, the signature information including the auctioneer's auction conditions for tokens in the second smart contract, and the purchase information including information that the buyer pays a certain price to the first smart contract to purchase tokens in the second smart contract; invoking auction transaction logic in the first smart contract, and triggering the auction transaction logic according to the transaction request, wherein the auction transaction logic at least includes: auctioning the tokens in the second smart contract according to the auction conditions; and the second smart contract authorizing the first smart contract to modify the owner of the tokens in the second smart contract.

[0007] A second aspect of this application provides a blockchain-based auction method applied to an auctioneer. The method includes: generating auctioneer signature information based on auction conditions for tokens in a second smart contract, wherein the second smart contract is deployed in a blockchain node, and the signature information includes the auction conditions for tokens in the second smart contract; sending the auctioneer's signature information, causing a buyer to send a transaction request to the blockchain node to invoke a first smart contract based on the buyer's purchase information and the obtained auctioneer signature information, thereby invoking auction transaction logic in the first smart contract; wherein the purchase information includes information that the buyer pays a certain price to the first smart contract to purchase tokens in the second smart contract; the auction transaction logic includes at least: auctioning the tokens in the second smart contract according to the auction conditions; and the second smart contract authorizing the first smart contract to modify the owner of the tokens in the second smart contract; the first smart contract is deployed in the blockchain node.

[0008] A third aspect of this application provides a blockchain-based auction method applied to a buyer. The method includes: obtaining the auctioneer's signature information, wherein the signature information includes the auctioneer's auction conditions for tokens in a second smart contract; generating a transaction request to invoke a first smart contract based on the buyer's purchase information and the signature information, wherein the transaction request includes the buyer's purchase information and the auctioneer's signature information, the purchase information including information that the buyer pays a certain price to the first smart contract to purchase tokens in the second smart contract, the first smart contract and the second smart contract being deployed in a blockchain node; and sending the transaction request to invoke the first smart contract to the blockchain node to trigger auction transaction logic in the first smart contract, wherein the auction transaction logic includes at least: auctioning the tokens in the second smart contract according to the auction conditions; and the second smart contract authorizing the first smart contract to modify the owner of the tokens in the second smart contract.

[0009] A fourth aspect of this application provides a blockchain-based auction device applied to a blockchain node including a first smart contract and a second smart contract. The device includes: a transceiver unit configured to: receive a transaction request from a buyer to invoke the first smart contract, wherein the transaction request includes the auctioneer's signature information and the buyer's purchase information; the signature information includes the auctioneer's auction conditions for tokens in the second smart contract, and the purchase information includes information that the buyer pays a certain price to the first smart contract to purchase tokens in the second smart contract; and a processing unit configured to: invoke auction transaction logic in the first smart contract and trigger the auction transaction logic according to the transaction request, wherein the auction transaction logic at least includes: auctioning tokens in the second smart contract according to the auction conditions; and the second smart contract authorizes the first smart contract to modify the owner of the tokens in the second smart contract.

[0010] A fifth aspect of this application provides a blockchain-based auction device applied to an auctioneer. The device includes: a processing unit configured to: generate auctioneer signature information based on the auctioneer's auction conditions for tokens in a second smart contract, wherein the second smart contract is deployed in a blockchain node, and the signature information includes the auctioneer's auction conditions for tokens in the second smart contract; and a transceiver unit configured to: send the auctioneer's signature information, causing a buyer to send a transaction request to the blockchain node to invoke a first smart contract based on the buyer's purchase information and the obtained auctioneer signature information, thereby invoking auction transaction logic in the first smart contract; wherein the purchase information includes information that the buyer pays a certain price to the first smart contract to purchase tokens in the second smart contract; the auction transaction logic includes at least: auctioning the tokens in the second smart contract according to the auction conditions; and the second smart contract authorizing the first smart contract to modify the owner of the tokens in the second smart contract; the first smart contract is deployed in the blockchain node.

[0011] A sixth aspect of this application provides a blockchain-based auction device applied to a buyer. The device includes: a transceiver unit configured to: acquire the auctioneer's signature information, wherein the signature information includes the auctioneer's auction conditions for tokens in a second smart contract; a processing unit configured to: generate a transaction request to invoke a first smart contract based on the buyer's purchase information and the signature information, wherein the transaction request includes the buyer's purchase information and the auctioneer's signature information, the purchase information including information that the buyer pays a certain price to the first smart contract to purchase tokens in the second smart contract, the first smart contract and the second smart contract being deployed in a blockchain node; the transceiver unit is further configured to: send the transaction request to invoke the first smart contract to the blockchain node to trigger auction transaction logic in the first smart contract, wherein the auction transaction logic includes at least: auctioning the tokens in the second smart contract according to the auction conditions; and the second smart contract authorizing the first smart contract to modify the owner of the tokens in the second smart contract.

[0012] A seventh aspect of this application also provides a computer-readable storage medium storing one or more computer instructions, characterized in that the instructions are executed by a processor to implement the method described in any of the above technical solutions.

[0013] An eighth aspect of this application also provides an electronic device, including: a processor; and a memory for storing a data processing program, wherein the server, after being powered on and running the program through the processor, executes the method described above.

[0014] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments disclosed in this application, nor is it intended to limit the scope of this application's disclosure. Other features disclosed in this application will become readily apparent from the following description.

[0015] In the blockchain-based auction method provided in this application embodiment, the buyer's transaction request to invoke the first smart contract carries the auctioneer's signature information and the buyer's purchase information. The signature information includes the auctioneer's auction conditions for the tokens in the second smart contract, and the purchase information includes the buyer's payment of a certain price to the first smart contract to purchase the tokens in the second smart contract. Furthermore, the second smart contract authorizes the first smart contract to modify the owner of the tokens in the second smart contract. Further, after receiving the buyer's transaction request to invoke the first smart contract, the blockchain node invokes the auction transaction logic in the first smart contract, triggering the auction transaction logic according to the transaction request. In the above implementation, the auctioneer's auction conditions for the tokens in the second smart contract are carried by the buyer's transaction request to invoke the first smart contract; in other words, the auctioneer's auction conditions for the tokens in the second smart contract are not set in the first smart contract. Also, the buyer's transaction request to invoke the first smart contract is determined based on the auctioneer's signature information. Based on this setup, when the auctioneer needs to change the auction conditions for tokens in the second smart contract, the buyer only needs to generate a new transaction request based on the modified auction conditions; and then use this new transaction request to trigger the auction transaction logic in the first smart contract to complete the corresponding auction. This implementation eliminates the need to redeploy a new first smart contract corresponding to the modified auction conditions on the blockchain nodes. In summary, this method improves the flexibility of blockchain-based auction methods. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic diagram illustrating an application scenario of the blockchain-based auction method provided in the embodiments of this application.

[0018] Figure 2 This is a schematic diagram illustrating the creation and invocation of a smart contract applicable to the blockchain-based auction method provided in this application embodiment.

[0019] Figure 3 This is a schematic diagram of a blockchain-based auction method provided in an embodiment of this application.

[0020] Figure 4 This is a schematic diagram of another blockchain-based auction method provided in the embodiments of this application.

[0021] Figure 5 This is a schematic diagram of the structure of a blockchain-based auction device provided in an embodiment of this application.

[0022] Figure 6 This is a schematic diagram of the structure of a blockchain-based auction system provided in an embodiment of this application.

[0023] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0024] To enable those skilled in the art to better understand the technical solutions of this application, the application will be clearly and completely described below with reference to the accompanying drawings of the embodiments. However, this application can be implemented in many other ways different from those described above. Therefore, based on the embodiments provided in this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0025] It should be noted that the terms "first," "second," "third," etc., in the claims, specification, and drawings of this application are used to distinguish similar objects and are not used to describe a specific order or sequence. Such data are interchangeable where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that shown or described herein. Furthermore, the terms "comprising," "having," and their variations are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or apparatuses.

[0026] To facilitate understanding, the technical terms involved in the embodiments of this application will be introduced first.

[0027] 1. Blockchain

[0028] A blockchain is a chain of blocks. Each block stores specific information, and these blocks are linked together in chronological order of their creation. This chain is stored on all servers, and as long as at least one server in the system is operational, the entire blockchain is secure. These servers are called blockchain nodes (or simply nodes), and they provide storage space and computing power for the entire blockchain system. To modify information in the blockchain, the consent of more than half of the nodes must be obtained, and the information in all nodes must be modified. Since these nodes are typically controlled by different entities, tampering with information in the blockchain is extremely difficult. Compared to traditional networks, blockchain has two core characteristics: data is difficult to tamper with, and it is decentralized. Based on these two characteristics, the information recorded in the blockchain is more authentic and reliable, helping to solve the problem of mutual distrust.

[0029] Blockchains are generally classified into three types: public blockchains, consortium blockchains, and private blockchains. A public blockchain is defined as follows: any individual or group in the world can send transactions, and these transactions can be effectively confirmed by the blockchain; anyone can participate in its consensus process. A consortium blockchain is defined as follows: a group designates multiple pre-selected nodes as ledger keepers. The generation of each block is jointly decided by all pre-selected nodes (pre-selected nodes participate in the consensus process). Other access nodes can participate in transactions but do not interfere with the ledger process (essentially still escrow ledger management, just distributed; the number of pre-selected nodes and how to determine the ledger keeper for each block are the main risks of this blockchain). Anyone else can perform limited queries through the blockchain's open API. A private blockchain is defined as follows: it only uses the blockchain's ledger technology for record keeping; it can be a company or an individual, and they have exclusive write permissions to the blockchain.

[0030] 2. Blockchain Account

[0031] The three key elements of a blockchain account are: a private key, a public key, and the account's blockchain address.

[0032] Private and public keys are components of asymmetric encryption algorithms in cryptography. Public keys can be publicly shared, while private keys must be securely stored. Private keys are generated from a random seed, and public keys are derived from them using an algorithm. Because public keys are too long, "addresses" were introduced for simplicity and practicality; addresses are derived from public keys. These derivation processes are one-way and irreversible. That is, the public key cannot be derived from the address, and the private key cannot be derived from the public key.

[0033] 3. Smart Contracts

[0034] A smart contract is essentially a program that executes automatically when conditions agreed upon in advance by the contract creator are met. Smart contracts make the transaction process deterministic, the transaction result irreversible, and allow the transacting parties to trust each other even without third-party notarization.

[0035] In Ethereum, a smart contract specifically refers to a collection of code and data created by an external account or other contract account and residing at a specific address. After writing a smart contract using a high-level language (such as Solidity), users need to compile it into bytecode that the Ethereum Virtual Machine (EVM) can run, and then deploy it on Ethereum by initiating a transaction. Once deployed, users can invoke methods within the smart contract by sending transactions to the contract address, implementing the functions pre-defined by the contract creator. Methods within a smart contract must be invoked via a transaction; these can be invoked directly by a transaction initiated by an external account, or indirectly by an internal transaction triggered by another contract account. Although the contract code cannot be modified after deployment, it can be deleted by initiating a transaction to execute EVM opcodes.

[0036] 4. Ethereum

[0037] Ethereum is a public blockchain platform with smart contract functionality. Through Ethereum's smart contract capabilities, developers can build a wide variety of decentralized applications on the blockchain.

[0038] Ethereum has accounts, which are divided into two types: external accounts and contract accounts. External accounts are similar to those in Bitcoin. External accounts can be understood as accounts directly controlled by the user, also known as user accounts. Ethereum contract accounts are created after a smart contract is deployed and contain the contract code. Contract accounts can be understood as accounts created by users through external accounts, containing the smart contract code.

[0039] 5. Non-fungible tokens (NFTs)

[0040] NFTs, also known as non-fungible tokens, are tokens issued by developers on the Ethereum platform according to the ERC-721 standard / protocol. NFTs are unique digital assets characterized by their indivisibility, non-fungibility, and uniqueness. NFTs can be valued against most off-chain real-world items, such as books, electronic vouchers, electronic tickets, art collectibles, and in-game items.

[0041] Because NFTs are implemented through smart contracts, they possess universality, immutability, and programmability. This means anyone can deploy an NFT smart contract according to publishing standards, and NFTs can include more complex functionalities. One NFT in a smart contract corresponds to an NFT identifier (Identity Document, ID, tokenId), meaning the tokenId represents the corresponding NFT. Theoretically, any real-world item can be pegged as an NFT, but publishing NFTs on a blockchain network requires adherence to certain publishing standards, which vary across different blockchain platforms.

[0042] 6. NFT Token Contract

[0043] In an NFT token contract, events and functions can be included. Events are used in the event model, which consists of three components: an event source (also called the object being listened to), the event, and a listener. First, the listener registers a callback function. When the event source triggers the event, the listener receives the event information through the callback function and then processes it accordingly. Functions can be interface functions used to implement specific functionalities, such as querying how many tokens a user owns or authorizing a user to delegate a specific token to another user.

[0044] 7. Consensus Mechanism

[0045] Consensus mechanisms verify and confirm transactions quickly through voting by specific nodes. If several nodes with unrelated interests can reach a consensus on a transaction in a blockchain, we can assume that the entire network can also reach a consensus. Common consensus mechanisms include Proof-of-Work (PoW), Proof-of-Stake (PoS), and Practical Byzantine Fault Tolerance (PBFT).

[0046] 8. Digital signature

[0047] A digital signature, also known as a public-key digital signature, is a unique string of numbers that only the sender of the information can generate and that cannot be forged by others. This string also serves as valid proof of the authenticity of the information sent by the sender. It is similar to a physical signature written on paper, but implemented using public-key cryptography techniques to authenticate digital information. A digital signature typically defines two complementary operations: one for signing and the other for verification. Digital signatures are an application of asymmetric key encryption and digital digest techniques.

[0048] Blockchain technology is a novel distributed infrastructure and computing paradigm built on a peer-to-peer (P2P) network. It utilizes a chain-like data structure to verify and store data, a distributed node consensus algorithm to generate and update data, cryptography to ensure secure data transmission and access, and smart contracts composed of automated script code to program and manipulate data. In a blockchain, consensus data is generated by sending transactions and having nodes execute them. These transactions may include calls to smart contracts, which, upon execution, alter the state of the world, including, for example, account balances and smart contract stored variables.

[0049] Computing devices can construct data into a standard transaction format supported by the blockchain, and then publish it to the blockchain. The nodes in the blockchain will process the received transactions through consensus. After consensus is reached, the nodes in the blockchain that act as ledger nodes will package the transaction into a block and permanently store it in the blockchain.

[0050] Each time a new block is generated on the blockchain, the corresponding states of these executed transactions change after execution. For example, in blockchains built on an account model (such as Ethereum), the state of external accounts or the contract account state of smart contracts typically changes with transaction execution. External accounts are accounts directly controlled by users, also known as user accounts, while contract accounts are accounts created by users through external accounts and contain smart contract code. For instance, after a "transfer transaction" in a block is executed, the balances (i.e., the values ​​of the Balance field in these accounts) of the sender and receiver accounts associated with that "transfer transaction" typically change accordingly. Similarly, a "smart contract call transaction" in a block is used to invoke a smart contract deployed on the blockchain. The EVM corresponding to the node device invokes the smart contract to execute the "smart contract call transaction," and updates the account state of the smart contract account after execution.

[0051] In practical applications, public, private, and consortium blockchains can all provide smart contract functionality. A smart contract on a blockchain is a contract that can be triggered and executed by transactions. Smart contracts can be defined in the form of code. Taking Ethereum as an example, it allows users to create and invoke complex logic within the Ethereum network. As a programmable blockchain, Ethereum's core is the Ethereum Virtual Machine (EVM), which can be run by every Ethereum node. The EVM is a Turing-complete virtual machine that can implement various complex logics. Users publishing and invoking smart contracts in Ethereum are running them on the EVM. In fact, the EVM directly runs virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"), so smart contracts deployed on the blockchain can be bytecode.

[0052] With the development of blockchain technology, blockchain-based online auctions have gradually become popular. Traditional methods for auctioning objects associated with smart contracts deployed on a blockchain network require deploying an auction contract corresponding to the auction object on the blockchain. This contract includes the auction intent (e.g., auction time and price), which is pre-defined. For example, the auction intent might include: an auction duration of 7 days and a gradually decreasing price over time. In this auction process, if the auctioneer needs to modify the auction object or the auction intent, a new auction contract corresponding to the modified auction object or intent must be deployed on the blockchain. Therefore, traditional blockchain-based auction methods are difficult to flexibly update auction contracts according to actual needs, resulting in an inflexible nature.

[0053] To address the aforementioned problems, this application provides a blockchain-based auction method, apparatus, and electronic device.

[0054] The application scenarios and methods of the blockchain-based auction method applicable to the embodiments of this application will be described in detail below with reference to the accompanying drawings. It is understood that, where there is no conflict between the various embodiments provided in this application, the following embodiments and features can be combined with each other. Furthermore, the timing of the steps in the following method embodiments is merely an example and not a strict limitation.

[0055] First, the application scenarios of the blockchain-based auction method applicable to the embodiments of this application are introduced with reference to the accompanying drawings.

[0056] Figure 1 This is a schematic diagram illustrating an application scenario of the blockchain-based auction method provided in the embodiments of this application. For example... Figure 1 As shown, the application scenario includes: client 110, client 120 and blockchain network 130, wherein blockchain network 130 includes nodes 1 to 6.

[0057] For example, see Figure 1 The illustrated application scenario demonstrates the process of creating a smart contract. After Bob sends a transaction (transaction 1) containing information about creating a smart contract to blockchain 130, all nodes within blockchain 130 can execute this transaction in the EVM. Figure 1The From field of transaction 1 shown records the address of the account that initiated the creation of the smart contract. The Data field of transaction 1 stores the contract code, which can be bytecode. The To field of transaction 1 stores a null (empty) account value. Once the nodes in blockchain 130 reach a consensus through the consensus mechanism, the smart contract corresponding to transaction 1 is successfully created on each node of the blockchain 130 package. Users can then call the smart contract corresponding to transaction 1. The Data field of transaction 1, which creates the smart contract, can store the bytecode of that smart contract. Bytecode consists of a series of bytes, each byte representing an operation. For reasons of development efficiency and readability, developers can choose to write smart contract code in a high-level language instead of directly writing bytecode. For example, high-level languages ​​could include Solidity, Serpent, or LLL. Smart contract code written in a high-level language can be compiled by a compiler to generate bytecode that can be deployed to the blockchain. Taking Solidity as an example, contract code written in it is very similar to a class in object-oriented programming languages. A contract can declare various members, including state variables, functions, function modifiers, events, etc. State variables are values ​​that are permanently stored in the smart contract's Storage field and are used to save the contract's state.

[0058] After a smart contract is created, each node in blockchain 130 locally records the contract accounts corresponding to the smart contract for transaction 1. Each contract account corresponds to a specific address. For example, Figure 1 The address "0x68e13f…" recorded locally by each node in the illustrated blockchain 130 represents the address of the contract account of the smart contract corresponding to the created transaction 1; the contract code and account storage will be stored in the account storage of this contract account. The behavior of the smart contract is controlled by the contract code, while the contract account storage of the smart contract preserves the state of the contract. In other words, the smart contract enables the creation of a virtual account on the blockchain that contains contract code and contract account storage.

[0059] For example, see Figure 1 The illustrated application scenario demonstrates the process of invoking a smart contract. After Alice sends a transaction containing smart contract invocation information to blockchain 130, all nodes within blockchain 130 can execute this transaction in the EVM. Figure 1The From field of transaction 2 shown records the address of the account initiating the smart contract call, the To field records the address of the called smart contract, and the Data field records the method and parameters used to call the smart contract. After the smart contract is called, the account state of the contract account may change. Subsequently, a client can view the account state of the contract account through any node included in the connected blockchain 130. For example, the account state can be stored in the smart contract's Storage tree in the form of key-value pairs. The execution result of the smart contract call transaction can be stored in the form of a Merkle patricia trie (MPT) receipt tree as a transaction receipt.

[0060] Smart contracts can be executed independently on each node of the blockchain network in a prescribed manner. All execution records and data are stored on the blockchain. Therefore, once such a transaction is completed, the blockchain stores an immutable and unlost transaction certificate.

[0061] It should be understood that the above Figure 1 The application scenarios shown are for illustrative purposes only and do not constitute any limitation on the application scenarios applicable to the blockchain-based auction method provided in the embodiments of this application.

[0062] Figure 2 This is a schematic diagram illustrating the creation and invocation of a smart contract applicable to the blockchain-based auction method provided in this application embodiment.

[0063] For example, see Figure 2 Creating a smart contract in a blockchain (such as Ethereum) involves writing the smart contract, converting it into bytecode, and deploying it to the blockchain. Calling a smart contract in the blockchain involves initiating a transaction that points to the smart contract's address. The EVMs of the various nodes in the blockchain can execute this transaction separately, distributing the smart contract code across the virtual machines of the various nodes in the blockchain.

[0064] For accounts in a blockchain, an account state is typically maintained through a structure. When a transaction in a block is executed, the state of the account associated with that transaction usually changes. For example, in Ethereum, an account structure typically includes the following fields: Balance, Nonce, Code, and Storage. Specifically: The Balance field maintains the account's current balance. The Nonce field maintains the number of transactions for that account; it's a counter to ensure each transaction can be processed exactly once, effectively preventing replay attacks. The Code field maintains the account's contract code; in practice, the Code field is usually used to maintain the hash value of the contract code. The Storage field maintains the account's stored content (default value is empty); for contract accounts, a separate storage space is typically allocated to store the contract account's stored content; this separate storage space is usually called the contract account's account storage. The contract account's stored content is usually constructed into an MPT tree data structure and stored in the aforementioned separate storage space; the MPT tree built based on the contract account's stored content is also commonly referred to as the Storage tree. The Storage field typically only maintains the root node of the Storage tree; therefore, it is often called the Storage Root field. It should be noted that for externally owned accounts, the Code and Storage fields described above have null values. External accounts are controlled by a key. For example, an external account can be a user account created by a user using a key.

[0065] Next, the blockchain-based auction method provided in the embodiments of this application will be described in conjunction with the accompanying drawings.

[0066] Figure 3 This is a schematic diagram illustrating a blockchain-based auction method provided in an embodiment of this application. For example, Figure 3 The methods shown can be applied, but are not limited to, those described above. Figure 1 In the application scenarios shown, such as... Figure 3 As shown, this blockchain-based auction method includes S301 to S305. Below, S301 to S305 will be described in detail.

[0067] In this application's embodiments, the blockchain node can be any node in the blockchain. For example, the blockchain is... Figure 1When the blockchain 130 is shown, any one of nodes 1 to 6 in the blockchain 130 can serve as a blockchain node in this application embodiment, that is, any one of nodes 1 to 6 has the function of a blockchain node in this application embodiment. The type of blockchain is not specifically limited; for example, the blockchain can be a public blockchain or a consortium blockchain, etc.

[0068] In this embodiment, the blockchain node deploys a first smart contract and a second smart contract. Optionally, the blockchain node may also deploy other smart contracts; no specific limitation is made thereto.

[0069] Before executing S301 to S305 below, this application may also include steps related to deploying a first smart contract and a second smart contract in a blockchain node. The method for deploying the aforementioned first and second smart contracts in a blockchain node is described below. Optionally, in some implementations, the auctioneer sends a transaction to the blockchain node to create a first smart contract, thereby successfully deploying the first smart contract in the blockchain node. The transaction to create the first smart contract includes the auctioneer's address information and the contract code corresponding to the first smart contract. In this implementation, the first smart contract is deployed in the blockchain node by the auctioneer. Based on this, the auctioneer may also perform the following steps: sending authorization information to the blockchain node, wherein the authorization information instructs the second smart contract to authorize the first smart contract to modify the owner of the tokens in the second smart contract. Optionally, in some implementations, the aforementioned address information of the auctioneer is the auctioneer's account address, and the blockchain node records the auctioneer's account address; the aforementioned contract code corresponding to the first smart contract is bytecode. No specific limitations are placed on the implementation of the above-mentioned "the auctioneer sends a transaction to the blockchain node to create a first smart contract, thereby successfully deploying the first smart contract in the blockchain node." For example, see the above text. Figure 1 The described process for creating a smart contract in Blockchain 130 creates the aforementioned first smart contract. This application does not specifically limit the creator of the second smart contract. For example, the second smart contract could be created by the auctioneer sending a transaction to the blockchain node to create the smart contract. Alternatively, the second smart contract could be created by a third user other than the auctioneer and the buyer sending a transaction to the blockchain node to create the smart contract.

[0070] Next, we will introduce S301 to S305 in detail.

[0071] S301, the auctioneer generates the auctioneer's signature information based on the auction conditions for the tokens in the second smart contract. The second smart contract is deployed in the blockchain node, and the signature information includes the auctioneer's auction conditions for the tokens in the second smart contract.

[0072] In this embodiment, the auctioneer is a user of the blockchain node, meaning the blockchain node records the auctioneer's account. The auctioneer's account records at least: the auctioneer's account address information and the balance information corresponding to that account address. Optionally, before executing S301 above, the auctioneer may also perform the following step: sending registration information to the blockchain node, whereby the registration information is the auctioneer's information for registering with the blockchain node to become a user of the blockchain node. The auctioneer can be any type of electronic device, such as, but not limited to, a personal computer, smartphone, tablet, or server.

[0073] The number of tokens in the second smart contract, the item represented by each token, and the type of each token are not specifically limited. For example, the second smart contract may include one or more tokens, each with a different identifier. For example, tokens in the second smart contract may represent virtual items (e.g., a virtual avatar) or real-world items (e.g., a painting or a book). For example, in some implementations, the tokens are non-fungible tokens (NFTs). The auctioneer and the owner of the tokens in the second smart contract are not specifically limited. That is, in this embodiment, the auctioneer is the owner of the tokens in the second smart contract; or, the auctioneer is an auction service agency that acts as an agent for the owner of the tokens in the second smart contract to conduct the auction.

[0074] The signature information includes the auction conditions set by the auctioneer for the tokens in the second smart contract. In some implementations, the signature information specifically includes: auction information corresponding to the auction conditions and signature data corresponding to the auction information. The signature data is generated by the auctioneer using its private key for the auction conditions. It is understood that the auctioneer possesses a public-private key pair. The private key in the public-private key pair is owned by the auctioneer, and the public key is publicly available to all users on the blockchain node. The public key in the public-private key pair can be used to reconstruct data processed by the private key; similarly, the private key in the public-private key pair can be used to reconstruct data processed by the public key. The auction conditions set by the auctioneer for the tokens in the second smart contract represent at least one of the following conditions: the auction period for the tokens in the second smart contract, or the auction price. The auction period is not specifically limited. For example, the auction period could be from November 1, 2022 to November 2, 2022. For example, the auction period could be from 14:00 to 19:00 on November 1, 2022. There is no specific limit on the auction price. For example, the auction price could be a fixed price, such as 1 ETH. Alternatively, the auction price could be a price range, such as 1 to 3 ETH. Optionally, the above auction conditions may also include conditions other than the auction period and price mentioned above, without specific limitations.

[0075] In practical applications, different users in a blockchain can transfer funds using accounts. For example, in the Ethereum blockchain, funds can be transferred from a user's account to the smart contract's contract account. Similarly, funds can be transferred from user A's account to user B's account. Based on this, in some implementations, the blockchain node records: the first contract account of the first smart contract, the second contract account of the second smart contract, the auctioneer's account (as a user of the blockchain node), and the tokens in the second smart contract are recorded in the second contract account. The second contract account authorizes the first contract account to modify the ownership of the tokens in the second contract account. The auction conditions include the auction price at which the auctioneer's account auctions the tokens in the second contract account. The signature information specifically includes: auction information corresponding to the auction conditions and signature data corresponding to the auction information, where the signature data is generated by the auctioneer using their private key for the auction information. The auction information includes the address of the second contract account and the token identifier. The purchase information specifically includes: the buyer's account, the price paid by the buyer's account, and the first contract account.

[0076] The implementation of "the auctioneer generates the auctioneer's signature information based on the auction conditions for the tokens in the second smart contract" described in S301 above is not specifically limited. For example, the following describes the method by which the auctioneer generates this signature information, assuming the auctioneer's signature information includes: auction information corresponding to the auction conditions and signature data corresponding to the auction information. Specifically, the process of generating the auctioneer's signature information based on the auction conditions for the tokens in the second smart contract includes: the auctioneer hashing the auction information corresponding to the auction conditions to obtain digest information 1; the auctioneer using its private key and an asymmetric encryption algorithm to encrypt digest information 1 to obtain signature data corresponding to the auction information; and the auctioneer packaging the auction information corresponding to the auction conditions and the signature data corresponding to the auction information to generate the auctioneer's signature information. The hashing process can also employ a hash algorithm, and the hash algorithm is not specifically limited. For example, the hash algorithm can be, but is not limited to, a secure hash algorithm (SHA).

[0077] S302, the auctioneer sends its signature information, enabling the buyer to send a transaction request to the blockchain node to invoke the first smart contract based on the buyer's purchase information and the obtained auctioneer's signature information, thereby triggering the auction transaction logic in the first smart contract. Correspondingly, the buyer obtains the auctioneer's signature information.

[0078] S302 above describes the process of the auctioneer sending its signature information so that the buyer can obtain the auctioneer's signature information. In this embodiment, the specific implementation method of the auctioneer sending its signature information so that the buyer receives the signature information is not limited. In some implementations, sending the auctioneer's signature information includes: sending the signature information to the buyer; or sending the signature information to a third-party platform so that the buyer can obtain the signature information by accessing the third-party platform. The type of the third-party platform is not specifically limited. For example, the third-party platform can be a web page or an application, etc.

[0079] In this embodiment, the auctioneer's signature information includes the auction conditions for the tokens in the second smart contract. In practical applications, after the auctioneer sends the signature information including the auction conditions for the tokens in the second smart contract, the auctioneer may need to modify the auction conditions for the tokens in the second smart contract. Therefore, optionally, in some implementations, after the auctioneer executes S302 above, the following steps can also be performed: the auctioneer generates new signature information, wherein the new signature information includes auction condition #1 for the tokens in the second smart contract, which is different from the aforementioned auction conditions; the new signature information is sent to the buyer to obtain the new signature information. The difference between auction condition #1 and the aforementioned auction conditions is not specifically limited. For example, the auction information corresponding to auction condition #1 includes: a preset time period of 1 day and an auction price of 1 Ether; the auction information corresponding to the aforementioned auction conditions includes: a preset time period of 1 day and an auction price of 2 Ether. For example, the auction information corresponding to auction condition #1 includes: a preset time period from November 1st to November 2nd, 2022, and an auction price of 1 Ether; the auction information corresponding to the above auction condition includes: a preset time period from November 2nd to November 5th, 2022, and an auction price of 2 Ether. It is understandable that after the auctioneer sends new signature information, the signature information sent by the auctioneer in S302 above will expire. That is, after executing S302 above, if the step of sending new signature information is executed, the signature information in S303 to S305 below needs to be replaced with the new signature information.

[0080] S303, the buyer generates a transaction request to invoke the first smart contract based on the buyer's purchase information and signature information. The transaction request includes the buyer's purchase information and the auctioneer's signature information. The purchase information includes the information that the buyer pays a certain price to the first smart contract to purchase tokens in the second smart contract.

[0081] Optionally, before executing step 303 above, the buyer may also perform the step of obtaining the auctioneer's signature information. This application embodiment does not limit the method by which the buyer obtains the auctioneer's signature information. In some implementations, obtaining the auctioneer's signature information includes: receiving signature information sent by the auctioneer; or obtaining signature information from a third-party platform, wherein the third-party platform stores the auctioneer's signature information.

[0082] Optionally, before executing S303 above, the buyer may also generate purchase information. In some implementations, the signature information specifically includes: auction conditions and signature data corresponding to the auction conditions, wherein the signature data is signature data generated by the auctioneer using the auctioneer's private key for the auction conditions; before generating a transaction request to call the first smart contract based on the purchase information and signature information, the method further includes: verifying the legitimacy of the signature information based on the auctioneer's public key, wherein the auctioneer's private key and the auctioneer's public key are a public-private key pair; if the signature information passes the legitimacy verification, purchase information is generated based on the auction information corresponding to the auction conditions.

[0083] In this embodiment, the buyer is a user of the blockchain node, meaning the blockchain node records the buyer's account. The buyer's account records at least: the buyer's account address information and the balance information corresponding to that account address. Optionally, before executing step 303 above, the buyer may also perform the following steps: sending registration information to the blockchain node, wherein the registration information is information used by the buyer to register with the blockchain node to become a user of the blockchain node.

[0084] Understandably, after executing S303 above, the first smart contract records a certain price paid by the buyer.

[0085] S304, the buyer sends a transaction request to the blockchain node to invoke the first smart contract, thereby triggering the auction transaction logic within the first smart contract. Correspondingly, the blockchain node receives the transaction request from the buyer to invoke the first smart contract.

[0086] The aforementioned purchaser can be any type of electronic device, such as, but not limited to, personal computers, smartphones, tablets, or servers.

[0087] The aforementioned blockchain node can be any node in the blockchain. Executing S304 means that the buyer sends a transaction request to any node in the blockchain to invoke the first smart contract. The specific implementation method of "the buyer sending a transaction request to any node in the blockchain to invoke the first smart contract" is not limited. For example, the buyer could send the transaction request to one node in the blockchain; after receiving the transaction request, that node could then forward it to other nodes in the blockchain besides itself.

[0088] S305, the blockchain node calls the auction transaction logic in the first smart contract and triggers the auction transaction logic according to the transaction request. The auction transaction logic includes at least: auctioning the tokens in the second smart contract according to the auction conditions; and the second smart contract authorizes the first smart contract to modify the owner of the tokens in the second smart contract.

[0089] In this embodiment, the blockchain node invokes the auction transaction logic in the first smart contract and triggers the auction transaction logic according to the transaction request. This includes: if the signature information passes the legality verification, triggering the auction transaction logic in the first smart contract based on the signature information and purchase information. The above-mentioned triggering of the auction transaction logic based on the transaction request can be understood as passing the information carried by the transaction request into the auction transaction logic in the first smart contract to execute the process corresponding to that auction transaction logic. The above-mentioned determination that the signature information passes the legality verification means that the signature information has not been tampered with by others during transmission, and that the auction conditions carried by the signature information for the tokens in the second smart contract are genuine and credible. The method for the blockchain node to determine that the signature information passes the legality verification is described below. Optionally, in some implementations, the signature information specifically includes: auction information corresponding to the auction conditions and signature data corresponding to the auction information. The signature data is generated by the auctioneer using their private key in relation to the auction conditions. Before triggering the auction transaction logic in the first smart contract based on the signature information and purchase information, the blockchain node can also perform the following steps: call the auction transaction logic in the first smart contract, use the auctioneer's publicly disclosed public key to verify the legality of the signature information, and confirm that the signature information passes the legality verification. Here, the private key and public key are a public-private key pair. It is understood that the blockchain node can obtain the auctioneer's publicly disclosed public key. The auctioneer's private key is owned by the auctioneer themselves.

[0090] The auction transaction logic in the first smart contract includes: if it is determined that the price transferred by the buyer to the first smart contract meets the auction price indicated by the auctioneer for the tokens in the target smart contract, then the price transferred by the buyer to the first smart contract is transferred to the target smart contract; and the owner of the tokens indicated by the auctioneer for the tokens in the target smart contract is changed to the buyer. The target smart contract includes the aforementioned second smart contract. Below, based on the auction transaction logic in the first smart contract, the implementation method for executing S305 is described. Optionally, in some implementations, the blockchain node records: a first contract account for the first smart contract, a second contract account for the second smart contract, the auctioneer's account (as a user of the blockchain node), and the tokens in the second smart contract are recorded in the second contract account. The second contract account authorizes the first contract account to modify the ownership of the tokens in the second contract account. The auction conditions include: the auction price at which the auctioneer's account auctions the tokens in the second contract account. The signature information specifically includes: auction information corresponding to the auction conditions and signature data corresponding to the auction information, wherein the signature data is signature data generated by the auctioneer using the auctioneer's private key for the auction information. The auction information includes the address of the second contract account and the token identifier. The purchase information specifically includes: the buyer's account, the price paid by the buyer's account, and the first contract account. In the above implementations, the blockchain node records the accounts of the blockchain node's users and the accounts of the smart contracts deployed in the blockchain node. Based on this, users of the blockchain node and smart contracts can perform transfer operations based on accounts. Based on the above implementation, if the signature information included in the transaction request passes the legality verification, the auction transaction logic in the first smart contract is triggered according to the transaction request. This includes: determining that a certain price paid by the buyer's account to the first contract account matches the auction price corresponding to the auction conditions included in the signature information; transferring the certain price paid by the buyer's account to the first contract account from the first contract account to the second contract account; and changing the owner of the tokens held in the second contract account recorded in the second contract account to the buyer's account. In the above implementation, taking the auction price where the auction conditions include the auctioneer's account auctioning the tokens in the second contract account as an example, the auction transaction logic in the first smart contract triggered according to the transaction request is described. Optionally, in other implementations, the auction conditions specifically include the auction price where the auctioneer's account auctions the tokens in the second contract account within a preset time period; the auction information also includes a preset time period; before determining that the certain price paid by the buyer's account to the first contract account matches the auction price corresponding to the auction conditions indicated by the signature information, the blockchain node can also perform the following steps: determining that the current time has not exceeded the preset time period.The aforementioned preset time period is not specifically limited and can be set according to the actual auction needs of the auctioneer. In this embodiment, the second smart contract authorizes the first smart contract to modify the owner of the tokens in the second smart contract. That is, the first smart contract has the authority to modify the owner of the tokens in the second smart contract. Optionally, the aforementioned blockchain node can also perform the following steps: receiving authorization information sent by the auctioneer, wherein the authorization information instructs the second smart contract to authorize the first smart contract to modify the owner of the tokens in the second smart contract; modifying the authorization information corresponding to the tokens in the second smart contract according to the authorization information to obtain the modified authorization information, wherein the modified authorization information instructs the second smart contract to authorize the first smart contract to modify the owner of the tokens in the second smart contract.

[0091] In this embodiment, the auctioneer and the buyer are users of the blockchain node. Optionally, the blockchain node may further perform the following steps: receiving registration information sent by the target user, wherein the registration information is information about the target user registering with the blockchain node to become a user of the blockchain node; generating an account for the target user based on the registration information, wherein the target user is the buyer or the auctioneer. The auctioneer and the buyer become users of the blockchain node by sending registration information to the blockchain node, thereby enabling the auctioneer and the buyer to invoke the smart contracts deployed in the blockchain node.

[0092] It should be noted that S301 to S305 above describes an example of the first smart contract auctioning tokens in the second smart contract. Optionally, in other implementations, the first smart contract can also auction tokens in multiple smart contracts; the principle of the first smart contract auctioning tokens in any one of the multiple smart contracts is the same as the principle of the first smart contract auctioning tokens in the second smart contract. S301 to S305 above describes an example where the auction information corresponding to the auction conditions at least includes the auction price and the tokens being auctioned. Optionally, the auction information corresponding to the auction conditions can also be set according to actual needs; for example, the auction information corresponding to the auction conditions can also include information about the buyer.

[0093] It should be understood that the above Figure 3 The blockchain-based auction method shown is for illustrative purposes only and does not constitute any limitation on the blockchain-based auction method provided in this application.

[0094] In this embodiment, the buyer's transaction request to invoke the first smart contract carries the auctioneer's signature information and the buyer's purchase information. The signature information includes the auctioneer's auction conditions for the tokens in the second smart contract, and the purchase information includes the buyer's payment of a certain price to the first smart contract to purchase the tokens in the second smart contract. Furthermore, the second smart contract authorizes the first smart contract to modify the owner of the tokens in the second smart contract. Further, after receiving the buyer's transaction request to invoke the first smart contract, the blockchain node invokes the auction transaction logic in the first smart contract, triggering the auction transaction logic according to the transaction request. In the above implementation, the auctioneer's auction conditions for the tokens in the second smart contract are carried through the buyer's transaction request to invoke the first smart contract; in other words, the auctioneer's auction conditions for the tokens in the second smart contract are not set in the first smart contract. Also, the buyer's transaction request to invoke the first smart contract is determined based on the auctioneer's signature information. Based on this setup, when the auctioneer needs to change the auction conditions for tokens in the second smart contract, the buyer only needs to generate a new transaction request based on the modified auction conditions; and then use this new transaction request to trigger the auction transaction logic in the first smart contract to complete the corresponding auction. This implementation eliminates the need to redeploy a new first smart contract corresponding to the modified auction conditions on the blockchain nodes. Furthermore, the aforementioned first smart contract can also be used to auction tokens from multiple smart contracts. In summary, this method improves the flexibility of blockchain-based auction methods.

[0095] Below, in conjunction with Figure 4 This application introduces another blockchain-based auction method provided by its embodiments. It is understood that... Figure 4 The blockchain-based auction method described above is as follows. Figure 3 This is a concrete example of the blockchain-based auction method described. Specifically, Figure 4 Therefore Figure 3 The example described is an auction contract associated with an NFT smart contract in the blockchain. Figure 4 The described executing entities include the auctioneer, the blockchain, and the buyer.

[0096] Figure 4 This is a schematic diagram illustrating another blockchain-based auction method provided in an embodiment of this application. It should be understood that... Figure 4 The examples provided are merely to help those skilled in the art understand the embodiments of this application, and are not intended to limit the embodiments to the specific numerical values ​​or specific scenarios illustrated. Those skilled in the art will understand based on the following... Figure 4 The examples provided clearly demonstrate that various equivalent modifications or variations can be made, and such modifications and variations also fall within the scope of the embodiments of this application. For example... Figure 4 As shown, this blockchain-based auction method includes S401 to S408. S401 to S408 are described in detail below.

[0097] S401, the auctioneer creates NFT smart contract A and auction contract X in the blockchain.

[0098] NFT smart contract A and auction contract X are two different smart contracts deployed on the blockchain. These two smart contracts have different contract addresses and different purposes. NFT smart contract A is a smart contract containing NFT1 (also known as the NFT1 token contract). NFT1 can be, but is not limited to, a token issued using the ERC-721 standard / protocol. The contract account #1 of NFT smart contract A contains the NFT1 owner information 1, the NFT1 tokenId, and the NFT1 authorization information 1. Specifically, the NFT1 owner information 1 indicates that the owner of NFT1 is the auctioneer 1; the NFT1 authorization information 1 indicates that the auctioneer has granted the auction contract X the right to modify the owner of NFT1, meaning that auction contract X has the right to modify the owner of NFT1. Auction contract X is used to auction the NFT1 in NFT smart contract A according to the auctioneer's auction intentions, and to transfer the auction proceeds from the auction of NFT1 to the original holder of NFT1. The contract code included in contract account #2 of auction contract X is used to implement the functions of auction contract X described above. In this approach, auction contract X is associated with an NFT smart contract A. Optionally, in other implementations, auction contract X can also be associated with other smart contracts besides NFT smart contract A. For example, other smart contracts may include NFT smart contract B, where NFT smart contract B is a smart contract that includes NFT2 (also known as an NFT2 token contract). In this approach, the modification rights of the owner of NFT2 associated with NFT smart contract B can be granted to auction contract X, meaning auction contract X also has the following functions: auctioning NFT2 in NFT smart contract B according to the auctioneer's auction intentions, and transferring the auction proceeds obtained after auctioning NFT2 to the original holder of NFT2. It should be noted that after deploying the smart contract on the blockchain, a corresponding public-private key pair can be assigned to the contract account corresponding to the smart contract. The administrator corresponding to the contract account can hold the public-private key pair. The private key can be used to digitally sign transactions initiated by the administrator, while the public key can be used to verify the signature. The public key can be broadcast on the blockchain.

[0099] The specific implementation method of the auctioneer creating the aforementioned NFT smart contract A in the blockchain is not limited. For example, the auctioneer creating NFT smart contract A in the blockchain may include the following steps: The auctioneer registers with the blockchain and obtains a public key and a private key assigned to the auctioneer by the blockchain. The public key serves as the auctioneer's account address on the blockchain, and the private key serves as the unique key to operate the auctioneer's account. The auctioneer sends the transaction for creating NFT smart contract A to the blockchain. This transaction includes the auctioneer's address, the contract code of smart contract A, and digital signature 1. The contract code of NFT smart contract A is used to mint NFT 1, and digital signature 1 is the result obtained by the auctioneer using the aforementioned private key to digitally sign NFT smart contract A. After receiving the transaction for creating NFT smart contract A, the nodes in the blockchain reach a consensus through a consensus mechanism, and successfully create NFT smart contract A in the blockchain. After NFT smart contract A is created, each node in the blockchain records the corresponding contract account #1. This contract account #1 has a specific address, and the contract code of NFT smart contract A is stored in contract account #1. Contract account #1 also includes the account balance of NFT smart contract A. The behavior of NFT smart contract A is controlled by its corresponding contract code. In other words, NFT smart contract A creates a virtual account on the blockchain that contains contract code and account storage.

[0100] The specific implementation method of the auctioneer creating the aforementioned auction contract X in the blockchain is not limited. For example, deploying auction contract X in the blockchain may include the following steps: The auctioneer registers with the blockchain and obtains a public key and a private key assigned to them by the blockchain. The public key serves as the auctioneer's account address on the blockchain, and the private key serves as the unique key to operate the auctioneer's account. The auctioneer sends a transaction to the blockchain to create auction contract X. This transaction includes the auctioneer's address, the contract code of auction contract X, and digital signature 2. The contract code of auction contract X is used to implement the aforementioned auction contract X, and digital signature 2 is the result obtained by the auctioneer using the aforementioned private key to digitally sign auction contract X. After receiving the transaction to create auction contract X, the nodes in the blockchain reach a consensus through a consensus mechanism, and successfully create auction contract X in the blockchain. After auction contract X is created, the nodes in the blockchain will record the contract account #2 corresponding to auction contract X. Contract account #2 has a specific address, and the address of contract account #2 is different from the address of contract account #1 mentioned above. Contract account #2 also includes the account balance of auction contract X.

[0101] In this embodiment of the application, the blockchain also records external accounts in each node, namely, the auctioneer's account #1 and the buyer's account #2. Each of the above accounts records at least a mapping between the account address and the corresponding account content, wherein the account content may include at least the account balance.

[0102] In this embodiment, the blockchain includes at least two nodes. The number of nodes in the blockchain can be set according to actual needs and is not specifically limited. For example, the blockchain described in S401 above can be the one described above. Figure 1 Blockchain 130 is shown. No specific limitation is made on the type of blockchain. For example, the blockchain described above could be a public blockchain or a consortium blockchain, etc.

[0103] S402, the auctioneer generates signature information 1 and sends it to buyer 1. Signature information 1 instructs the auctioneer to auction NFT1, included in NFT smart contract A, for 1 ETH within a first preset time period. Accordingly, buyer 1 receives signature information 1 from the auctioneer.

[0104] Signature information 1 instructs the auctioneer to auction NFT1, contained in NFT smart contract A, at a price of 1 Ethereum within a first preset time period. In other words, signature information 1 serves to indicate the auctioneer's intention to auction NFT1. Signature information 1 may include at least: data to be signed 1, and a digital signature 1 obtained by signing the data to be signed 1. Data to be signed 1 may include at least: the auction price of NFT1 (i.e., 1 Ethereum), the auction expiration time (i.e., the first preset time period), the contract address of NFT smart contract A, and the token ID of NFT1, which identifies NFT1. The first preset time period can be set according to the auctioneer's needs and is not specifically limited thereto. For example, the first preset time period could be from November 1, 2022 to November 3, 2022, and the auction price of NFT1 is 1 Ethereum. In this method, signature information 1 is specifically used to instruct the auctioneer to auction NFT1, which is included in NFT smart contract A, for 1 Ethereum during the period from November 1, 2022 to November 3, 2022.

[0105] The method by which the auctioneer generates the aforementioned signature information 1 is not specifically limited. In some implementations, the auctioneer generates the aforementioned signature information 1 by: hashing the data to be signed 1 to obtain a digest of the data to be signed 1; using its own private key and an asymmetric encryption algorithm, the auctioneer encrypts the digest of the data to be signed 1 to obtain a digital signature 1; and the auctioneer packages the data to be signed 1 and the digital signature 1 together to generate signature information 1.

[0106] The specific implementation method for the auctioneer to send signature information 1 to buyer 1 is not limited. For example, Figure 4 The diagram illustrates that the auctioneer directly sends the generated signature information 1 to the buyer. Optionally, after generating signature information 1, the auctioneer can also publish the signature information to a network platform or application; subsequently, buyer 1 obtains the signature information 1 from the network platform or application.

[0107] It should be noted that the aforementioned signature information 1 includes a first preset time period. If the current time has exceeded the first preset time period, the aforementioned signature information 1 will be invalid. For example, if the first preset time period associated with signature information 1 is from November 1st to November 3rd, 2022, and the current time period is November 4th, 2022, then signature information 1 can be considered invalid. In this embodiment, the auctioneer can also generate updated signature information 1 and send it to buyer 1 if signature information 1 becomes invalid. The updated signature information 1 is used to instruct the auctioneer to auction NFT 1 at a price within a second preset time period, where the second preset time period is different from the first preset time period, and the current time has not exceeded the second preset time period. For example, Figure 4 S408 shown describes the steps described above for sending the updated signature information 1.

[0108] The following description will be based on the example that the current time has not exceeded the first preset time period, that is, the example that S403 is executed directly after S402 is executed.

[0109] S403, Buyer 1 generates a call request based on signature information 1. The call request is used to request the auction contract X in the blockchain to execute the bidding step.

[0110] In this embodiment of the application, the call request may include at least: the account address of buyer 1, the contract address of NFT smart contract A, 1 Ethereum transferred by buyer 1 to auction contract X, and signature information 1. The 1 Ethereum transferred by buyer 1 to auction contract X means that buyer 1 transfers 1 Ethereum from account #1 to contract account #2 of auction contract X.

[0111] The process involves Buyer 1 generating a call request based on signature information 1, including: Buyer 1 parsing signature information 1 to obtain signature data 1 and data to be signed 1; Buyer 1 decrypting signature data 1 using the auctioneer's public key to obtain a digest of signature data 1; Buyer 1 hashing data to be signed 1 to obtain a digest of data to be signed 1; Buyer 1 comparing the digest of signature data 1 with the digest of data to be signed 1 to confirm their consistency; Buyer 1 determining the need to purchase NFT 1 associated with data to be signed based on data to be signed 1; and Buyer 1 generating a call request based on Buyer 1's account address, the contract address of NFT smart contract A, the price to be transferred to auction contract X (1 ETH), and signature information 1. It is understood that Buyer 1's consistency comparison process is to confirm whether signature information 1 has been tampered with during transmission and the identity of the sender of signature information 1. If the signature information 1 passes the consistency comparison, the buyer 1 can confirm that the signature information 1 was not tampered with during transmission, that is, the signature information 1 is trustworthy data.

[0112] Understandably, after executing S403 above, the account balance recorded in Buyer 1's account #2 will decrease by 1 ETH, and the account balance recorded in Auction Contract X's contract account #2 will increase by 1 ETH. In other words, after executing S403 above, the price that Buyer 1 needs to pay for NFT1 will be transferred from Buyer 1's account #1 to Auction Contract X's contract account #2.

[0113] S404, Buyer 1 sends a request to the blockchain. Correspondingly, the blockchain receives Buyer 1's request.

[0114] After buyer 1 executes the above S404, all nodes in the blockchain will receive the call request sent by buyer 1.

[0115] S405, the blockchain calls the auction contract X to verify the call request and determine whether the call request passes the verification.

[0116] The execution entity in S405 above is the blockchain, specifically the EVM execution of auction contract X by each node in the blockchain. Auction contract X verifies the call request to determine if it passes verification. This includes: parsing the call request to obtain at least the following: the buyer's account address, the NFT smart contract A's contract address, the 1 Ethereum to be transferred by the buyer to auction contract X, and signature information 1; parsing signature information 1 using the corresponding public key to obtain digest 2; and comparing digest 2 with the digest of the aforementioned data to be signed 1; if digest 2 and digest 1 are equal, it indicates that the signer of signature information 1 is auction contract X; and determining that the auction price of NFT 1 matches the price transferred by the buyer to auction contract X, and that the current time has not exceeded the auction expiration time, confirming that the call request passes verification.

[0117] The above verification process S405 is executed, that is, if the signer of the signature information 1 included in the verification call request is the auction contract X, the price paid by the buyer 1 to the auction contract X for the purchase of NFT 1 is the auction price specified by the auctioneer through the signature information 1, and the current time has not exceeded the auction period indicated by the signature information 1, the above call request passes the verification.

[0118] In this embodiment of the application, if the auction contract X determines that the call request has passed verification, S405 is executed and then S406 is executed; or, if the auction contract X determines that the call request has failed verification, S405 is executed and then S407 is executed.

[0119] S406, the blockchain calls auction contract X to modify the owner information 1 of NFT1 recorded in NFT smart contract A to owner information 2; and transfers 1 Ethereum in contract account #2 of auction contract X to the auctioneer's account #1; owner information 2 indicates that the owner of NFT1 is buyer 1.

[0120] The executing entity in S406 above is the blockchain, that is, the EVM of each node in the blockchain executes the auction contract X.

[0121] Executing S406 above, the auction contract X in the blockchain modifies the owner information 1 of NFT1 recorded in NFT smart contract A to owner information 2, including: the auction contract X in the blockchain obtains the owner information 1 of NFT1 recorded in NFT smart contract A according to the contract address of NFT smart contract A included in the call request; the auction contract X in the blockchain modifies the owner information 1 of NFT1 recorded in NFT smart contract A to owner information 2.

[0122] Understandably, auction contract X transfers 1 Ethereum from its contract account #2 to the auctioneer's account #1. After this operation, the account balance recorded in contract account #2 of auction contract X will decrease by 1 Ethereum, and the account balance recorded in the auctioneer's account #1 will increase by 1 Ethereum. In other words, after executing the above S406, the transaction requested by the call request is successfully completed.

[0123] S407, the request corresponding to the end of the auction contract X in the blockchain.

[0124] After executing S405 above, continue to execute S407 above, that is, if the auction contract X determines that the signature information 1 included in the call request has not passed the signature verification, the auction requested by the call request will be terminated.

[0125] It should be understood that the above Figure 4 The described blockchain-based auction method is merely illustrative and does not constitute any limitation on the blockchain-based auction method provided in the embodiments of this application. For example, in some other implementations, the auction contract X described above can also be associated with a greater number of NFT smart contracts, that is, the auction contract X is used to conduct auctions based on the above-mentioned... Figure 4 The auction principle described applies to auctioning at least one NFT included in the associated larger number of NFT smart contracts.

[0126] In this embodiment, the aforementioned blockchain-based auction method involves an auctioneer, a blockchain, and a buyer (1). At least two smart contracts are deployed on the blockchain: an NFT smart contract A and an auction contract X. The auctioneer authorizes the owner of NFT1 (included in NFT smart contract A) to modify the NFT1 in the auction contract X. The auctioneer publishes signature information 1 to indicate its intention to auction NFT1; that is, signature information 1 indicates the auctioneer's intention to auction NFT1 (e.g., auction price or auction time). After obtaining signature information 1, buyer 1 can generate a call request to auction contract X and send the call request to auction contract X. The call request includes: buyer 1's account address, the contract address of NFT smart contract A, 1 Ethereum transferred by buyer 1 to auction contract X, and signature information 1. After receiving the call request from Buyer 1, Auction Contract X verifies the request. If the call request passes verification, Auction Contract X can change the owner of NFT1 to Buyer 1 and transfer the purchase price paid by Buyer 1 for NFT1 to the auctioneer. Specifically, the auctioneer sends signature information to the Buyer so that the Buyer can know the auctioneer's intention to auction NFT1 within a preset time period (e.g., auction price or quantity). Furthermore, if the auction time indicated by signature information 1 has expired before the Buyer calls Auction Contract X, the auctioneer can republish updated signature information, provided the current time has not exceeded the auction time indicated by the updated signature information. In this method, Buyer 1 can generate a call request corresponding to the updated signature information to invoke Auction Contract X to execute the bidding step. In the aforementioned blockchain-based auction method, the auctioneer's auction intent is carried through the buyer's call request to auction contract X. If the auctioneer needs to modify the auction intent, there is no need to redeploy a new auction contract on the blockchain; only the signature information 1 corresponding to the auction intent needs to be resent to buyer 1. Furthermore, the aforementioned auction contract X can also be used to auction NFTs in other NFT smart contracts besides NFT smart contract A. For example, the aforementioned auction contract X can also be used to auction NFT2 in NFT smart contract B. In this method, only the modification rights of the owner of NFT2 in NFT smart contract B need to be transferred to auction contract X, and the auctioneer needs to publish the signature information corresponding to auctioning NFT2 to the buyer. This signature information is used to indicate the auctioneer's auction intent for NFT2 (e.g., auction time and auction price). In this method, there is no need to redeploy the auction contract corresponding to the auction intent for auctioning NFT2 on the blockchain. In summary, the blockchain-based auction method provided in this application embodiment has higher flexibility.

[0127] The above, combined with Figures 1 to 4This paper details the application scenarios and methods applicable to the blockchain-based auction method provided in this application. Below, we will discuss these methods in conjunction with... Figures 5 to 7 This application introduces a blockchain-based auction device, a blockchain-based auction system, and an electronic device. It should be understood that the blockchain-based auction method described above corresponds to the blockchain-based auction device, system, and electronic device described below. Any content not described in detail below can be found in the relevant descriptions in the above method embodiments.

[0128] Figure 5 This is a schematic diagram of a blockchain-based auction device provided in an embodiment of this application. Figure 5 As shown, the device includes a transceiver unit 501 and a processing unit 502.

[0129] Implementation method one,

[0130] In implementation method one, Figure 5 The blockchain-based auction device shown is applied to a blockchain node. The functions of the transceiver unit 501 and the processing unit 502 in this implementation are described below.

[0131] The transceiver unit 501 is configured to: receive a transaction request from the buyer to invoke the first smart contract, wherein the transaction request includes the auctioneer's signature information and the buyer's purchase information, the signature information including the auctioneer's auction conditions for the tokens in the second smart contract, and the purchase information including information that the buyer pays a certain price to the first smart contract to purchase the tokens in the second smart contract; the processing unit 502 is configured to: invoke the auction transaction logic in the first smart contract, and trigger the auction transaction logic according to the transaction request, wherein the auction transaction logic includes at least: auctioning the tokens in the second smart contract according to the auction conditions; and the second smart contract authorizes the first smart contract to modify the owner of the tokens in the second smart contract.

[0132] Implementation method two

[0133] In implementation method two, Figure 5 The blockchain-based auction device shown is applied to the auctioneer. The functions of the transceiver unit 501 and the processing unit 502 in this implementation are described below.

[0134] Processing unit 502 is configured to: generate auctioneer's signature information based on the auctioneer's auction conditions for the tokens in the second smart contract, wherein the second smart contract is deployed in a blockchain node, and the signature information includes the auctioneer's auction conditions for the tokens in the second smart contract; transceiver unit 501 is configured to: send the auctioneer's signature information, causing the buyer to send a transaction request to the blockchain node to invoke the first smart contract based on the buyer's purchase information and the obtained auctioneer's signature information, thereby invoking the auction transaction logic in the first smart contract; wherein the purchase information includes information that the buyer pays a certain price to the first smart contract to purchase the tokens in the second smart contract; the auction transaction logic includes at least: auctioning the tokens in the second smart contract according to the auction conditions; and the second smart contract authorizes the first smart contract to modify the owner of the tokens in the second smart contract; the first smart contract is deployed in the blockchain node.

[0135] Implementation method three

[0136] In implementation method three, Figure 5 The blockchain-based auction device shown is applied to the buyer. The functions of the transceiver unit 501 and the processing unit 502 in this implementation are described below.

[0137] The transceiver unit 501 is configured to: acquire the auctioneer's signature information, wherein the signature information includes the auctioneer's auction conditions for the tokens in the second smart contract; the processing unit 502 is configured to: generate a transaction request to invoke the first smart contract based on the buyer's purchase information and the signature information, wherein the transaction request includes the buyer's purchase information and the auctioneer's signature information, the purchase information including information that the buyer pays a certain price to the first smart contract to purchase the tokens in the second smart contract, the first smart contract and the second smart contract being deployed in a blockchain node; the transceiver unit 501 is configured to: send the transaction request to invoke the first smart contract to the blockchain node to trigger the auction transaction logic in the first smart contract, wherein the auction transaction logic includes at least: auctioning the tokens in the second smart contract according to the auction conditions; and the second smart contract authorizing the first smart contract to modify the owner of the tokens in the second smart contract.

[0138] Figure 6 This is a schematic diagram of the structure of a blockchain-based auction system provided in an embodiment of this application. Figure 6 As shown, the system includes an auctioneer 601, a blockchain node 602, and a buyer 603, where the blockchain node 602 is any node in the blockchain.

[0139] Specifically, auctioneer 601 is used to execute the various steps of auctioneer execution in the blockchain-based auction method described above, blockchain node 602 is used to execute the various steps of blockchain node execution in the blockchain-based auction method described above, and buyer 603 is used to execute the various steps of buyer execution in the blockchain-based auction method described above. For details not elaborated here, please refer to the relevant descriptions above.

[0140] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 7 As shown, it includes a memory 701, a processor 702, a communication interface 703, and a communication bus 704. The memory 701, processor 702, and communication interface 703 are interconnected via the communication bus 704.

[0141] The memory 701 may be a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 701 may store a program, and when the program stored in the memory 701 is executed by the processor 702, the processor 702 and the communication interface 703 are used to execute the various steps of the blockchain-based auction method of this application embodiment.

[0142] The processor 702 may be a general-purpose central processing unit (CPU), microprocessor, application-specific integrated circuit (ASIC), graphics processing unit (GPU), or one or more integrated circuits, used to execute relevant programs to achieve the functions required by the units in the smart contract-based auction device of this application embodiment, or to execute the various steps of the blockchain-based auction method of this application embodiment.

[0143] The processor 702 can also be an integrated circuit chip with signal processing capabilities. In implementation, each step of the blockchain-based auction method provided in this application can be completed by the integrated logic circuits in the hardware of the processor 702 or by instructions in software form. The aforementioned processor 702 can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in the memory 701. The processor 702 reads the information in the memory 701 and, in conjunction with its hardware, performs the functions required by the units included in the blockchain-based auction device of this application embodiment, or executes the blockchain-based auction method of this application method embodiment.

[0144] The communication interface 703 uses a transceiver device, such as, but not limited to, a transceiver, to implement 7 Figure 7 The device shown communicates with other devices or communication networks.

[0145] Communication bus 704 may be included in Figure 7 The illustrated device shows a pathway for transmitting information between its various components (e.g., memory 701, processor 702, communication interface 703).

[0146] This application provides a computer-readable storage medium, which includes computer instructions. When executed by a processor, the computer instructions are used to implement any of the blockchain-based auction methods described in this application.

[0147] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments disclosed in this application can be embodied in the form of a software product, which can be stored on a computer-readable medium and includes several instructions to cause a computing device (which may be a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments disclosed in this application.

[0148] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0149] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0150] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage media, or any other non-transferable media that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include non-transitory computer-readable media, such as modulated data signals and carrier waves.

[0151] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0152] Although this application discloses preferred embodiments as described above, it is not intended to limit this application. Any person skilled in the art can make possible changes and modifications without departing from the spirit and scope of this application. Therefore, the scope of protection of this application should be determined by the scope defined in the claims of this application.

Claims

1. A blockchain-based auction method, characterized in that, The method, applied to blockchain nodes including those deploying a first smart contract and a second smart contract, includes: The system receives a transaction request from a buyer to invoke the first smart contract. The transaction request includes the auctioneer's signature information and the buyer's purchase information. The signature information includes the auctioneer's auction conditions for the tokens in the second smart contract, and the purchase information includes information about the buyer paying a certain price to the first smart contract to purchase the tokens in the second smart contract. The auctioneer's signature information is either directly sent to the buyer by the auctioneer, or the auctioneer sends the signature information to a third-party platform so that the buyer can obtain the signature information by accessing the third-party platform. The auction transaction logic in the first smart contract is invoked, and the auction transaction logic is triggered according to the transaction request. The auction transaction logic includes at least: auctioning the tokens in the second smart contract according to the auction conditions; and the second smart contract authorizes the first smart contract to modify the owner of the tokens in the second smart contract.

2. The method according to claim 1, characterized in that, The step of invoking the auction transaction logic in the first smart contract and triggering the auction transaction logic according to the transaction request includes: If the signature information passes the legality verification, the auction transaction logic in the first smart contract is triggered based on the signature information and the purchase information.

3. The method according to claim 2, characterized in that, The signature information specifically includes: auction information corresponding to the auction conditions and signature data corresponding to the auction information, wherein the signature data is signature data generated by the auctioneer using the auctioneer's private key for the auction conditions; Before triggering the auction transaction logic in the first smart contract based on the signature information and the purchase information, the method further includes: The auction transaction logic in the first smart contract is invoked, and the signature information is validated using the public key published by the auctioneer. The signature information is then validated to ensure it passes the validation. The private key and the public key are a public-private key pair.

4. The method according to any one of claims 1 to 3, characterized in that, The blockchain node records: the first contract account of the first smart contract, the second contract account of the second smart contract, the auctioneer's account as a user of the blockchain node, and the auctioneer's account as a user of the blockchain node, with the tokens in the second smart contract recorded in the second contract account; The second contract account authorizes the first contract account to modify the ownership of the tokens in the second contract account; The auction conditions include: the auction price at which the auctioneer's account auctions the tokens in the second contract account; The signature information specifically includes: auction information corresponding to the auction conditions and signature data corresponding to the auction information, wherein the signature data is signature data generated by the auctioneer using the auctioneer's private key for the auction information; the auction information includes the address of the second contract account and the identifier of the token; The purchase information specifically includes: the buyer's account, the price paid by the buyer's account, and the first contract account.

5. The method according to claim 4, characterized in that, The step of triggering the auction transaction logic in the first smart contract based on the transaction request, after determining that the signature information included in the transaction request has passed the validity verification, includes: The price paid by the buyer's account to the first contract account is determined to match the auction price corresponding to the auction conditions included in the signature information; The certain price paid from the buyer's account to the first contract account is transferred from the first contract account to the second contract account; Change the owner of the tokens in the second contract account recorded in the second contract account to the buyer's account.

6. The method according to claim 5, characterized in that, The auction conditions specifically include the auction price at which the auctioneer's account auctions the tokens in the second contract account within a preset time period; the auction information also includes the preset time period. Before determining that the certain price paid by the buyer's account to the first contract account matches the auction price corresponding to the auction conditions indicated by the signature information, the method further includes: It is determined that the current time has not exceeded the preset time period.

7. The method according to any one of claims 1 to 3, wherein the method further comprises: The system receives authorization information sent by the auctioneer, wherein the authorization information instructs the second smart contract to authorize the first smart contract to modify the ownership of the tokens in the second smart contract; Based on the authorization information, the authorization information corresponding to the token in the second smart contract is modified to obtain the modified authorization information, wherein the modified authorization information instructs the second smart contract to authorize the first smart contract to modify the owner of the token in the second smart contract.

8. The method according to any one of claims 1 to 3, wherein the method further comprises: Receive registration information sent by the target user, wherein the registration information is the information of the target user registering with the blockchain node to become a user of the blockchain node; An account for the target user is generated based on the registration information, wherein the target user is the buyer or the auctioneer.

9. The method according to any one of claims 1 to 3, The auctioneer is the owner of the tokens in the second smart contract; or... The auctioneer is an auction service agency that acts as an agent for the owner of the tokens in the second smart contract to conduct the auction.

10. The method according to any one of claims 1 to 3, wherein the token is a non-fungible token (NFT).

11. An auction method based on smart contracts, characterized in that, Applied to the auctioneer, the method includes: Based on the auction conditions of the auctioneer for the tokens in the second smart contract, the auctioneer's signature information is generated, wherein the second smart contract is deployed in a blockchain node, and the signature information includes the auction conditions of the auctioneer for the tokens in the second smart contract. The auctioneer's signature information is sent, enabling the buyer to send a transaction request to the blockchain node to invoke the first smart contract based on the buyer's purchase information and the obtained auctioneer's signature information, thereby invoking the auction transaction logic within the first smart contract. The purchase information includes information that the buyer pays a certain price to the first smart contract to purchase tokens in the second smart contract. The auction transaction logic includes at least: auctioning the tokens in the second smart contract according to the auction conditions; and the second smart contract authorizing the first smart contract to modify the ownership of the tokens in the second smart contract. The first smart contract is deployed on the blockchain node. The step of sending the auctioneer's signature information includes: sending the signature information to the buyer; or sending the signature information to a third-party platform so that the buyer can obtain the signature information by accessing the third-party platform.

12. The method according to claim 11, characterized in that, The blockchain node records: the first contract account of the first smart contract, the second contract account of the second smart contract, the auctioneer's account as a user of the blockchain node, and the auctioneer's account as a user of the blockchain node, with the tokens in the second smart contract recorded in the second contract account; The second contract account authorizes the first contract account to modify the ownership of the tokens in the second contract account; The auction conditions include: the auction price at which the auctioneer's account auctions the tokens in the second contract account; The signature information specifically includes: auction information corresponding to the auction conditions and signature data corresponding to the auction information, wherein the signature data is signature data generated by the auctioneer using the auctioneer's private key for the auction information; the auction information includes the address of the second contract account and the identifier of the token; The purchase information specifically includes: the buyer's account, the price paid by the buyer's account, and the first contract account.

13. The method according to claim 12, characterized in that, The auction conditions specifically include the auction price at which the auctioneer's account auctions the tokens in the second contract account within a preset time period; the auction information also includes the preset time period.

14. The method according to any one of claims 11 to 13, characterized in that, The method further includes: Send authorization information to the blockchain node, wherein the authorization information instructs the second smart contract to authorize the first smart contract to modify the ownership of the tokens in the second smart contract.

15. The method according to any one of claims 11 to 13, characterized in that, The method further includes: A transaction to create the first smart contract is sent to a blockchain node to successfully deploy the first smart contract on the blockchain node, wherein the transaction to create the first smart contract includes the address information of the auctioneer and the contract code corresponding to the first smart contract.

16. The method according to any one of claims 11 to 13, characterized in that, The auctioneer is an auction service organization that acts as an agent for the owner of the tokens in the second smart contract to conduct the auction. or, The auctioneer is the owner of the tokens in the second smart contract, and the method further includes: Send a transaction to a blockchain node to create the second smart contract, so as to successfully deploy the second smart contract in the blockchain node.

17. The method according to any one of claims 11 to 13, characterized in that, The method further includes: Send registration information to the blockchain node, wherein the registration information is information on the auctioneer registering with the blockchain node to become a user of the blockchain node.

18. The method according to any one of claims 11 to 13, wherein the token is a non-fungible token (NFT).

19. An auction method based on smart contracts, characterized in that, Applied to the buyer, the method includes: Obtain the auctioneer's signature information, wherein the signature information includes the auctioneer's auction conditions for the tokens in the second smart contract; obtaining the auctioneer's signature information includes: receiving the signature information sent by the auctioneer; or, obtaining the signature information from a third-party platform, wherein the third-party platform stores the auctioneer's signature information; Based on the purchase information of the buyer and the signature information, a transaction request to invoke the first smart contract is generated. The transaction request includes the purchase information of the buyer and the signature information of the auctioneer. The purchase information includes information that the buyer pays a certain price to the first smart contract to purchase tokens in the second smart contract. The first smart contract and the second smart contract are deployed in a blockchain node. A transaction request to invoke the first smart contract is sent to the blockchain node to trigger the auction transaction logic in the first smart contract. The auction transaction logic includes at least: auctioning the tokens in the second smart contract according to the auction conditions; and the second smart contract authorizes the first smart contract to modify the owner of the tokens in the second smart contract.

20. The method according to claim 19, characterized in that, The signature information specifically includes: the auction conditions and the signature data corresponding to the auction conditions, wherein the signature data is the signature data generated by the auctioneer using the auctioneer's private key for the auction conditions; Before generating a transaction request to invoke the first smart contract based on the purchase information and the signature information, the method further includes: The signature information is validated for legality based on the public key disclosed by the auctioneer, wherein the auctioneer's private key and the public key disclosed by the auctioneer are a public-private key pair. If the signature information passes the legality verification, the purchase information is generated based on the auction information corresponding to the auction conditions.

21. The method according to claim 19 or 20, characterized in that, The blockchain node records: the first contract account of the first smart contract, the second contract account of the second smart contract, the auctioneer's account as a user of the blockchain node, and the auctioneer's account as a user of the blockchain node, with the tokens in the second smart contract recorded in the second contract account; The second contract account authorizes the first contract account to modify the ownership of the tokens in the second contract account; The auction conditions include: the auction price at which the auctioneer's account auctions the tokens in the second contract account; The signature information specifically includes: auction information corresponding to the auction conditions and signature data corresponding to the auction information, wherein the signature data is signature data generated by the auctioneer using the auctioneer's private key for the auction information; the auction information includes the address of the second contract account and the identifier of the token; The purchase information specifically includes: the buyer's account, the buyer's account paying the certain price, and the first contract account.

22. The method according to claim 21, characterized in that, The auction conditions specifically include the auction price at which the auctioneer's account auctions the tokens in the second contract account within a preset time period; the auction information also includes the preset time period.

23. The method according to claim 19 or 20, characterized in that, The method further includes: Send registration information to the blockchain node, wherein the registration information is information about the purchaser registering with the blockchain node to become a user of the blockchain node.

24. The method according to claim 19 or 20, The auctioneer is the owner of the tokens in the second smart contract; or... The auctioneer is an auction service agency that acts as an agent for the owner of the tokens in the second smart contract to conduct the auction.

25. The method according to claim 19 or 20, wherein the token is a non-fungible token (NFT).

26. A smart contract-based auction device, applied to a blockchain node including a first smart contract and a second smart contract, the device comprising: The transceiver unit is configured to: receive a transaction request from a buyer to invoke the first smart contract, wherein the transaction request includes the auctioneer's signature information and the buyer's purchase information; the signature information includes the auctioneer's auction conditions for the tokens in the second smart contract; and the purchase information includes information that the buyer pays a certain price to the first smart contract to purchase the tokens in the second smart contract; the auctioneer's signature information is either directly sent to the buyer by the auctioneer, or the auctioneer sends the signature information to a third-party platform so that the buyer can obtain the signature information by accessing the third-party platform. The processing unit is configured to: invoke the auction transaction logic in the first smart contract, and trigger the auction transaction logic according to the transaction request, wherein the auction transaction logic includes at least: auctioning the tokens in the second smart contract according to the auction conditions; and the second smart contract authorizes the first smart contract to modify the owner of the tokens in the second smart contract.

27. An auction device based on a smart contract, applied to an auctioneer, the device comprising: The processing unit is configured to: generate auctioneer's signature information based on the auctioneer's auction conditions for the tokens in the second smart contract, wherein the second smart contract is deployed in a blockchain node, and the signature information includes the auctioneer's auction conditions for the tokens in the second smart contract; The transceiver unit is used to: send the auctioneer's signature information, enabling the buyer to send a transaction request to the blockchain node to invoke the first smart contract based on the buyer's purchase information and the obtained auctioneer's signature information, thereby invoking the auction transaction logic in the first smart contract; wherein, the purchase information includes information that the buyer pays a certain price to the first smart contract to purchase tokens in the second smart contract; the auction transaction logic includes at least: auctioning the tokens in the second smart contract according to the auction conditions; and the second smart contract authorizes the first smart contract to modify the owner of the tokens in the second smart contract; the first smart contract is deployed in the blockchain node; The step of sending the auctioneer's signature information includes: sending the signature information to the buyer; or sending the signature information to a third-party platform so that the buyer can obtain the signature information by accessing the third-party platform.

28. A smart contract-based auction device, applied to a buyer, the device comprising: The transceiver unit is used to: obtain the auctioneer's signature information, wherein the signature information includes the auctioneer's auction conditions for the token in the second smart contract; obtaining the auctioneer's signature information includes: receiving the signature information sent by the auctioneer; or, obtaining the signature information from a third-party platform, wherein the third-party platform stores the auctioneer's signature information; The processing unit is configured to: generate a transaction request to invoke the first smart contract based on the purchase information of the buyer and the signature information, wherein the transaction request includes the purchase information of the buyer and the signature information of the auctioneer, the purchase information includes information that the buyer pays a certain price to the first smart contract to purchase tokens in the second smart contract, and the first smart contract and the second smart contract are deployed in a blockchain node; The transceiver unit is further configured to: send the transaction request to invoke the first smart contract to the blockchain node to trigger the auction transaction logic in the first smart contract, wherein the auction transaction logic includes at least: auctioning the tokens in the second smart contract according to the auction conditions; and the second smart contract authorizes the first smart contract to modify the owner of the tokens in the second smart contract.

29. An electronic device, characterized in that, include: The memory and the processor are coupled; The memory is used to store one or more computer instructions; The processor is configured to execute one or more computer instructions to implement the method as described in any one of claims 1 to 25.

30. A computer-readable storage medium storing one or more computer instructions thereon, characterized in that, The instruction is executed by the processor to implement the method as described in any one of claims 1 to 25.

Images