CN112785434A

CN112785434A - Selling information issuing method and system, electronic device and readable storage medium

Info

Publication number: CN112785434A
Application number: CN202110123088.6A
Authority: CN
Inventors: 李立夫; 邓柯; 黄胜利; 李成才
Original assignee: Chengdu Quality Starker Technology Co Ltd
Current assignee: Chengdu Quality Starker Technology Co Ltd
Priority date: 2021-01-29
Filing date: 2021-01-29
Publication date: 2021-05-11

Abstract

The embodiment of the invention provides a selling information issuing method, a selling information issuing system, electronic equipment and a readable storage medium, and aims to improve the flexibility of asset selling business. The selling information issuing method is applied to any node in a block chain network, and comprises the following steps: in response to a contract deployment request, deploying a trading contract in which selling information is declared; establishing an account for the transaction contract in an asset contract that records seller assets; transferring a target quantity of seller assets in the asset contract to an account of the transaction contract. In the present invention, assets are recorded via an asset contract. When asset sales are to be conducted, nodes of the blockchain network deploy corresponding trading contracts to declare corresponding sales information. Therefore, each intelligent contract is not overstaffed, and corresponding trading contracts can be deployed in a personalized mode, so that the flexibility of asset selling services can be improved, and selling information can be issued more flexibly.

Description

Selling information issuing method and system, electronic device and readable storage medium

Technical Field

The present invention relates to the field of communications technologies, and in particular, to a method and a system for issuing selling information, an electronic device, and a readable storage medium.

Background

The block chain technology is realized based on a block chain network, distributed node equipment (hereinafter referred to as nodes) in the block chain network realizes generation, consensus and storage of block data by operating a block chain program, and finally achieves a tamper-proof mechanism of the data, thereby providing a safe and reliable new technical idea for business development.

The block chain technology can be applied to various service scenes, such as the financial field, the electronic commerce field, the commodity or raw material tracing field, the electronic evidence storage field and the like.

In the related art, in order to develop services based on a blockchain network more flexibly and more variously, an intelligent contract may be deployed in the blockchain network, and then service development may be implemented by calling service logic declared in the intelligent contract. In specific implementation, a business end may create an intelligent contract in advance, and then deploy the intelligent contract in a blockchain network, wherein one or more accounts are recorded in the intelligent contract, and multiple business logics and execution conditions of each business logic are stated in the intelligent contract. For example, various business logic includes: transfer service logic, delivery service logic, buyback service logic, interest service logic, asset freeze service logic, asset thaw service logic, and the like. Typically, in order to be able to perform as many business types as possible in the future for the account assets recorded by the intelligent contract, it is necessary to declare as much business logic as possible in the intelligent contract. However, this results in an overly cumbersome intelligent contract and a loss of flexibility in business development.

Disclosure of Invention

The embodiment of the invention aims to provide a selling information issuing method, a selling information issuing system, electronic equipment and a readable storage medium, and aims to improve the flexibility of asset selling business. The specific technical scheme is as follows:

in a first aspect of an embodiment of the present invention, a method for publishing selling information is provided, where the method is applied to any node in a blockchain network, and the method includes:

in response to a contract deployment request, deploying a trading contract in which selling information is declared;

establishing an account for the transaction contract in an asset contract that records seller assets;

transferring a target quantity of seller assets in the asset contract to an account of the transaction contract.

In a first aspect of an embodiment of the present invention, a method for issuing vending information is provided, where the method is applied to a message middleware, and the method includes:

receiving a service message which is sent by a service end and used for selling assets, and analyzing the service message into a plurality of transactions, wherein the plurality of transactions comprise contract deployment transactions and selling transactions;

submitting the contract deployment transaction to a blockchain network such that nodes of the blockchain network deploy a transaction contract in response to the contract deployment transaction; the transaction contract declares selling information and selling logic, the selling logic comprises a calling relation, the calling relation is used for calling transfer logic declared in a corresponding asset contract, and the corresponding asset contract is an asset contract recording seller assets;

submitting the sale transaction to the blockchain network, so that nodes of the blockchain network respond to the sale transaction and call the sale logic stated in the transaction contract, and further call the transfer logic stated in the corresponding asset contract according to the call relation contained in the sale logic, so as to transfer the target number of seller assets in the asset contract to an account of the transaction contract.

In a third aspect of the embodiments of the present invention, an electronic device is provided, which includes a processor, a communication interface, a memory, and a communication bus, where the processor, the communication interface, and the memory complete communication with each other through the communication bus;

the memory is used for storing a computer program;

the processor is used for realizing the selling information issuing method provided by any embodiment of the invention when the program stored in the memory is executed.

In a fourth aspect of the embodiments of the present invention, there is provided a computer-readable storage medium on which a computer program is stored, the program, when executed by a processor, implementing the selling information issuing method provided by any of the embodiments of the present invention.

In the invention, the node of the block chain network responds to the contract deployment request to deploy the corresponding trading contract, and the trading contract declares the selling information. The nodes of the blockchain network also establish accounts for the transaction contract in an asset contract that records the seller's assets. The nodes of the blockchain network also transfer a target number of seller assets in the asset contract to an account of the transaction contract. In the present invention, assets are recorded by asset contracts. When a seller needs to develop an asset selling service, a node of the blockchain network deploys a corresponding trading contract to declare corresponding selling information, so that the selling information of the asset selling service is issued. Therefore, each intelligent contract is not overstaffed, and each trading contract can be individually deployed, so that the flexibility of the asset selling service can be effectively improved, and the selling information can be more flexibly issued.

In addition, by establishing an account for the transaction contract in the asset contract and transferring a target amount of seller assets (i.e., seller assets ready for sale) to the account of the transaction contract, isolation is formed between seller remaining assets and the assets ready for sale, facilitating the subsequent more secure and reliable implementation of a sale operation for the assets ready for sale.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below. It is obvious that the drawings in the following description are only some embodiments of the invention, and that for a person skilled in the art, other drawings can be derived from them without inventive effort.

Fig. 1 is a schematic diagram of a selling information issuing method based on a service processing system according to an embodiment of the present invention;

fig. 2 is a schematic diagram of a node of a blockchain network in performing a transaction according to an embodiment of the present invention;

FIG. 3(a) is a schematic illustration of a trading contract as set forth in an embodiment of the present invention;

FIG. 3(b) is a schematic illustration of an asset contract proposed by an embodiment of the present invention;

FIG. 3(c) is a schematic illustration of an asset contract proposed by an embodiment of the present invention;

FIG. 3(d) is a schematic illustration of an asset contract proposed by an embodiment of the present invention;

fig. 4 is a flowchart of a method for issuing selling information according to an embodiment of the present invention;

fig. 5 is a flowchart of a method for issuing selling information according to an embodiment of the present invention;

fig. 6 is a schematic diagram of an electronic device according to an embodiment of the invention.

Detailed Description

The technical solution in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. It is to be understood that the embodiments described are only a few embodiments of the present invention, and not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

The block chain technology is realized based on a block chain network, distributed node equipment (hereinafter referred to as nodes) in the block chain network realizes generation, consensus and storage of block data by operating a block chain program, and finally achieves a tamper-proof mechanism of the data, thereby providing a safe and reliable new technical idea for business development. The block chain technology is realized based on a block chain network, distributed node equipment (hereinafter referred to as nodes) in the block chain network realizes generation, consensus and storage of block data by operating a block chain program, and finally achieves a tamper-proof mechanism of the data, thereby providing a safe and reliable new technical idea for business development.

In the related art, in order to develop services based on a blockchain network more flexibly and more variously, an intelligent contract may be deployed in the blockchain network, and then service development may be implemented by calling service logic declared in the intelligent contract. In specific implementation, a business end may create an intelligent contract in advance, and then deploy the intelligent contract in a blockchain network, wherein one or more accounts are recorded in the intelligent contract, and multiple business logics and execution conditions of each business logic are stated in the intelligent contract. Typically, in order to be able to perform as many business types as possible in the future for the account assets recorded by the intelligent contract, it is necessary to declare as much business logic as possible in the intelligent contract. However, this results in an overly cumbersome intelligent contract and a loss of flexibility in business development.

In view of this, the present invention provides a method, a system, an electronic device and a readable storage medium for publishing sale information through the following embodiments, which aim to improve the flexibility of asset sale services.

Referring to fig. 1, fig. 1 is a schematic diagram of a selling information issuing method based on a service processing system according to an embodiment of the present invention. As shown in fig. 1, the service processing system includes a message middleware and a blockchain network, where the message middleware is communicatively connected to one or more designated nodes in the blockchain network. In addition, the message middleware is also used for connecting a service end, and the service end realizes indirect communication with the block chain network through the message middleware, in other words, the service end realizes the service development by using the block chain network through the message middleware.

Specifically, when a service end generates a service requirement, a user equipment of the service end may send a corresponding service packet to the message middleware, where the service packet carries service information. After receiving the service message, the message middleware analyzes the service message into one or more transactions, then calls a key management system to sign the transactions, and submits the signed transactions to a block chain network for execution. The blockchain network carries out the transactions submitted by the message middleware, so that corresponding services are developed for the service end. In addition, each message middleware can synchronize the blocks generated by the blockchain network or synchronize the ledger database of the blockchain network, so as to obtain the transaction executed by the blockchain network. And each message middleware recombines the service message according to the transaction executed by the blockchain network and sends the recombined service message to the service end, so that the service developed in the blockchain network is fed back to the service end.

For understanding, as an example, when the service end a generates a service requirement, the user equipment of the service end a sends a corresponding service message to the message middleware a. After the processing flow, the message middleware B obtains a plurality of transactions corresponding to the service message from the blockchain network, recombines the service message according to the transactions, and sends the recombined service message to the service end B corresponding to the message middleware B. Therefore, the service terminal B can acquire the service developed by the service terminal A in the block chain network, thereby realizing the broadcasting and the transmission of the service information while realizing the development of the service.

Optionally, in some specific embodiments, the information is transferred between the user equipment of the service end and the message middleware specifically based on the communication message. When the user equipment transmits the service information to the message middleware, the user equipment firstly encapsulates the service message in the message body of the communication message, and then sends the communication message encapsulated with the service message to the message middleware. Similarly, when the message middleware transmits service information to the user equipment, the message middleware firstly encapsulates the service message in a message body of the communication message, and then sends the communication message encapsulated with the service message to the user equipment. The communication message may be selected from: hypertext transfer protocol messages (HTTP), hypertext transfer security protocol (HTTPs), and the like. It should be noted that the present invention does not limit the type of the communication packet.

The present invention has been described above with respect to the service processing system shown in fig. 1. The invention provides a selling information publishing method in combination with fig. 1, aiming at improving the flexibility of asset selling business.

As shown in fig. 1, when a service end a generates a service demand for selling assets, a user equipment of the service end a may send a service packet to a packet middleware a, where the service packet carries a service type identifier and service data (the service data includes, but is not limited to, selling information, contract method logic, and the like). The service type identifier is used to characterize the service packet for selling the assets, for example, the service type identifier may be in the form of SMTT.

As shown in fig. 1, after receiving a service message, the message middleware a parses the service message into multiple transactions, including contract deployment transaction, credit granting transaction, and sale transaction, where each transaction carries a message identifier of the service message.

In specific implementation, the service message carries the signature data of the service end a to the service message, and the signature data is obtained after the service end a signs the service message by using a private key in a communication key of the service end a. After receiving the service message, the message middleware a first performs signature verification on signature data carried by the service message by using a corresponding public key. And if the signature passes the verification, continuing to execute the analysis operation of the service message. And if the signature verification fails, the analysis operation of the service message is not executed.

In the specific implementation, a plurality of message analysis strategies are preset in the message middleware, and each message analysis strategy corresponds to one service type identifier respectively and is used for analyzing the message carrying the corresponding service type identifier so as to obtain one or more transactions related to the corresponding service type. A message parsing policy is actually a segment of computer program, and the message middleware executes the message parsing policy by running the segment of computer program. The message parsing strategy may make the following restrictions on the message parsing operation:

1. the transaction quantity and the type of each transaction which are required to be analyzed by the service message;

2. for each transaction, defining the transaction data required to be carried by the transaction; and for each transaction data, defining at which field of the transaction message the transaction data is specifically obtained, and defining at which field of the transaction template the transaction data is filled.

It should be noted that the above limitation of the message parsing operation by the message parsing policy is only an example. Any modification, equivalent replacement, improvement, etc. made by those skilled in the art within the spirit and principle of the above examples are included in the scope of protection of the present invention.

And after the message middleware a receives the service message, reading out the service type identifier SMTT from the service message. Then, the message middleware a queries a message analysis strategy corresponding to the service type identifier SMTT from a plurality of preset message analysis strategies by taking the service type identifier SMTT as an index. And then the message middleware a analyzes contract deployment transaction, credit transaction and sale transaction by executing the message analysis strategy. Wherein the contract deployment transaction carries at least contract data and a contract address of a transaction contract to be deployed. The trusted transaction carries at least a seller blockchain address, a trusted amount, and a contract address of the transaction contract. The sale transaction carries at least auxiliary authentication information for identity authentication, and the auxiliary authentication information can be specifically signature data of the sale transaction.

Optionally, in some specific embodiments, after the message middleware a receives the service message, a unique message identifier is generated for the service message. For example, in order to generate a Unique packet Identifier, the packet middleware a may input data such as a timestamp when the service packet is received, a number of the packet middleware a itself, and a Universal Unique Identifier (UUID) as input parameters into the hash algorithm model, obtain a string of hash values output by the hash algorithm model, and then use the first n bits (for example, the first 25 bits) of the hash value as the packet Identifier. And after the message middleware a analyzes the service message into the plurality of transactions, filling a pre-generated message identifier into each transaction.

Or optionally, in other specific embodiments, the service packet sent by the service end a to the packet middleware a carries a packet identifier. And after the message middleware a analyzes the service message into the plurality of transactions, filling the message identification carried by the service message into each transaction.

In addition, after the message middleware a analyzes a plurality of transactions, the transactions are submitted to a key management system for signature. To simplify the drawing, the process of the message middleware a calling the key management system to sign the transaction is not shown in fig. 1.

In specific implementation, the message middleware a generates a signature request, where the signature request carries multiple transactions parsed by the message middleware a and also carries identity information of a service requester, where the identity information may be identity information of the service terminal a or identity information of a certain client of the service terminal a, and the form of the identity information may be a block chain address. In addition, the message middleware a also signs the signature request by using a private key in the communication key of the message middleware a to obtain signature data of the signature request. And the message middleware a sends the signature request and the signature data of the signature request to the key management system.

And after receiving the signature request and the signature data of the signature request, the key management system performs signature verification on the signature data by using the corresponding public key. And if the signature verification is passed, executing signature operation. If the signature verification fails, no signature operation is performed. When executing the signing operation, the key management system specifically reads the identity information of the service requester from the signing request, queries the working key corresponding to the identity information by using the identity information as an index, and signs each transaction in the signing request by using a private key in the queried working key to obtain signature data of each transaction. The key management system sends the signature data of each transaction to the message middleware a.

As shown in fig. 1, for each transaction, the message middleware a submits the transaction and the signature data of the transaction to the blockchain network for processing.

In specific implementation, the message middleware a firstly submits the contract deployment transaction and the signature data thereof to the blockchain network for processing. And after the message middleware a reads the contract deployment transaction from the synchronized block or ledger data, proving that the block chain network has executed the contract deployment transaction. In response, the message middleware a submits the credit transaction and the signature data thereof to the blockchain network for processing. And after the message middleware a reads the credit transaction from the synchronized block or the book data, the block chain network is proved to have executed the credit transaction. In response, the message middleware a submits the selling transaction and the signature data thereof to the blockchain network for processing.

As shown in fig. 1, each message middleware (e.g., message middleware a and message middleware b) synchronizes block or ledger data from the blockchain network, reads transactions from the synchronized block or ledger data, reassembles a service message according to multiple transactions carrying the same message identifier, and pushes the reassembled service message to a corresponding service end.

During specific implementation, the message middleware detects a message identifier carried by each read transaction, and takes a plurality of transactions carrying the same message identifier as a group of transactions.

In the specific implementation, a plurality of message reassembly strategies are preset in the message middleware, and each message reassembly strategy corresponds to a service type identifier and is used for performing reassembly processing on a group of transactions carrying corresponding message identifiers, so as to reassemble corresponding service messages. A message reassembly policy is actually a segment of computer program that is executed by the message middleware by running it. The message reassembly policy may make the following restrictions on the message parsing operation:

1. in order to recombine the transaction quantity required by the service message, the transaction quantity is referred to as transaction demand quantity in the following;

2. message data required to be contained in a message header of the reconstructed service message; and for each message data, defining which field of which transaction the message data is obtained from, and defining which field of the message header the message data is filled in;

3. business data required to be contained in the message body of the reconstructed business message; and for each transaction data, defining at which field of which transaction the transaction data is specifically taken, and defining at which field of the body of the message the transaction data is filled.

It should be noted that the above limitation of the packet reassembly policy on the packet reassembly operation is only an example. Any modification, equivalent replacement, improvement, etc. made by those skilled in the art within the spirit and principle of the above examples are included in the scope of protection of the present invention.

In the specific implementation of the point 1 limitation, after the message middleware searches a corresponding message reassembly strategy according to a service type identifier carried by any transaction in a certain group of transactions, the transaction demand quantity limited by the message reassembly strategy is read. Then, the message middleware counts the transaction quantity contained in the group of transactions. Finally, the message middleware compares the transaction quantity contained in the group of transactions with the transaction demand quantity, thereby judging whether the transaction quantity and the transaction demand quantity are equal.

If the two are equal, the message middleware continues to obtain the message data and the service data for recombining the service message from the group of transactions based on the limitation of the point 2 and the point 3 of the message recombination strategy so as to recombine the service message.

If the two are not equal, the message middleware stops message recombination operation, counts the transaction quantity contained in the group of transactions again after a preset time length, and compares the transaction quantity with the transaction demand. It should be noted that, during the period of suspending the message reassembly operation, the message middleware still continuously synchronizes the block or ledger database, reads the transaction from the synchronized block or ledger data, and adds the transaction to a corresponding group of transactions according to the message identifier carried by the transaction for the read transaction.

In the invention, a service end A puts forward the service requirement of selling assets to a message middleware a in the form of a service message. And the message middleware a analyzes the service message into a plurality of transactions and submits the transactions to the blockchain network for execution. Thereafter, the message middleware a and b synchronize to the transactions from the blockchain network, then recombine the transactions into a service message, and return the recombined service message to the corresponding service end. Therefore, the service end A can know that the asset selling information is successfully issued according to the service message returned by the message middleware a. The service end B can know that the service end A issues the asset selling information according to the service message returned by the message middleware B. Because each service end realizes indirect interaction with the block chain network through the service message without establishing transaction in person, the service can be developed more conveniently based on the block chain network.

Referring to fig. 2, fig. 2 is a schematic diagram of a node of a blockchain network according to an embodiment of the present invention when performing a transaction. As shown in fig. 2, when a node of the blockchain network executes a contract deployment transaction, specifically, a corresponding transaction contract is deployed according to contract data carried by the contract deployment transaction, and the transaction contract declares selling information and a plurality of contract method logics.

Illustratively, the selling information declared in the trading contract includes, but is not limited to: the ID of the sold asset, the blockchain address of the seller (blockchain address may also be referred to as wallet address), the total amount of the sold asset, the unit price of the sold asset, the sale start time, the sale expiration time, the ID of the payment asset, the payment method, and the like.

It should be noted that a plurality of asset contracts are deployed in the blockchain, each asset contract having a contract address and an asset ID. Each asset contract has one or more accounts recorded therein, and also has the balance of the asset under each account recorded therein. Wherein each account name is actually the blockchain address of the corresponding user, and in short, the account name of the user is equal to the blockchain address of the user. In the above example, the asset contract in which the sold asset is located is contracted by declaring the sold asset ID in the trade contract. The account in which the asset is sold is agreed upon by declaring the blockchain address of the seller in the transaction contract. In summary, assets under a respective account of a respective asset contract are determined to be sold assets by declaring in the transaction contract a selling asset ID and a blockchain address of the seller. Further, in the above example, the asset contract in which the payment asset is located is contracted by declaring the payment asset ID in the transaction contract. Wherein, the payment assets refer to: assets available for purchase of the sold asset.

For ease of understanding, assuming, by way of example, that the vending asset ID included in the vending information is bond, the block chain address of the seller is 16U … jvM, and the payment asset ID is DCEP, the vending information specifically reflects the following information: the bond under account 16U … jvM in the bond type asset contract is used as the selling asset; the digital currency recorded in the digital currency-like property contract is used as a payment property for purchasing the bond. The bond-type asset contract is the "asset contract for recording seller assets" according to the present invention, and the digital currency asset contract is the "asset contract for recording buyer assets" according to the present invention.

Illustratively, the sale logic is included in a number of contract method logics in a trading contract, and the sale logic includes a call relation used for calling transfer logic declared in a corresponding asset contract. Wherein the corresponding asset contract is also the asset contract of the record seller asset.

For ease of understanding, and by way of example, with reference to FIG. 3(a), FIG. 3(a) is a schematic illustration of a trading contract as set forth in one embodiment of the present invention. As shown in fig. 3(a), the trading contract has sales information and several contract method logics declared therein. It should be noted that the specific structure of the trading contract in fig. 3(a) is only an example, and should not be construed as a limitation to the present invention.

For ease of understanding, and by way of example, with reference to FIG. 3(b), FIG. 3(b) is a schematic diagram of an asset contract as set forth in an embodiment of the present invention. As shown in fig. 3(b), the asset contract records a plurality of accounts and the number of assets in each account. For ease of understanding, the asset contract shown in fig. 3(B) is specifically a bond-type asset contract, and the asset type recorded in the asset contract is bond, where 500 shares of bond assets are set for account a on business side a, 120 shares of bond assets are set for account B on business side B, and 390 shares of bond assets are set for account C on business side C. In addition, some basic contract method logic, such as credit logic, transfer logic, etc., is also declared in the property contract.

It should be added that, before executing the contract deployment transaction, the node of the blockchain network may perform signature verification on the signature data of the contract deployment transaction in advance, and in the case that the signature verification passes, the contract deployment transaction is executed as shown in fig. 2. To simplify the drawing, the process of signature verification of signature data of a contract deployment transaction by a node is not shown in fig. 2.

As shown in fig. 2, when a node of the block chain network is performing a credit transaction, specifically, an asset contract with a corresponding asset ID may be invoked according to a selling asset ID carried by the credit transaction; or the asset contract with the corresponding contract address can be called according to the asset contract address carried by the credit transaction; or the trading contract can be called according to a trading contract address carried by the credit transaction, and then the asset contract with the corresponding asset ID can be called according to the selling asset ID declared in the trading contract. After the node of the block chain network calls the corresponding asset contract, an account can be established for the transaction contract in the asset contract according to the contract address of the transaction contract carried by the credit transaction, and the account name of the account is the contract address of the transaction contract. And then the nodes of the block chain network credit the corresponding amount of assets under the corresponding accounts in the asset contract to the accounts of the transaction contract according to the seller block chain address and the credit amount carried by the credit transaction.

For ease of understanding, and by way of example, in connection with fig. 3(b), assuming that the credit transaction carries a contract address for a bond-type asset contract, a contract address for the transaction contract, a blockchain address a, and a credit amount 300, a node of the blockchain network first invokes the asset contract shown in fig. 3(b) based on the contract address for the bond-type asset contract carried by the credit transaction. The node of the blockchain network then establishes an account for the transaction contract in the asset contract according to the contract address of the transaction contract carried by the credit transaction, and the account name of the account is the contract address of the transaction contract, as shown in fig. 3 (c). And the nodes of the blockchain network then credit 300 bonds of the corresponding account A to the account of the transaction contract according to the blockchain address A and the credit amount 300 carried by the credit transaction.

It should be noted that, since 300 bonds of account a are currently only credited to the transaction contract and no actual transfer is completed, the bond balance of account a is still 500, and the bond balance of the transaction contract account is 0. In the ledger database and/or the block chain of the node, the credit information "account a credits 300 bonds to the transaction contract account" is recorded.

It should be further added that, before the trust transaction is executed, the node of the blockchain network may perform signature verification on the signature data of the trust transaction by using the public key corresponding to the vendor blockchain address carried in the trust transaction in advance, and execute the trust transaction only when the signature verification passes, as shown in fig. 2. For simplicity of the drawing, the process of signature verification of the signature data of the trusted transaction by the node is not shown in fig. 2.

As shown in fig. 2, the nodes of the blockchain network may pre-sign verify the signature data of the sale transaction before executing the sale transaction. The sale transaction is executed only if the signature verification is passed. As shown in fig. 2, when a node of the blockchain network executes a sale transaction, specifically, a trade contract is first invoked according to a contract address of the trade contract carried by the sale transaction. And then calling the selling logic in the transaction contract according to the method logic ID carried by the selling transaction.

As shown in fig. 2, a node of the blockchain network, when executing the selling logic, first determines whether a signer of signature data of the selling transaction is a seller declared in the transaction contract. If not, the execution of the selling logic is terminated. If yes, transfer logic declared in the corresponding asset contract is called continuously according to the calling relation contained in the selling logic. Wherein the corresponding asset contract is also an asset contract that records the seller's assets.

As shown in fig. 2, when the transfer logic declared in the asset contract is invoked and executed, first, according to the target amount information carried in the sale transaction, it is determined whether the seller account previously credited assets not less than the target amount to the transaction contract account. If not, the execution of the transfer logic is terminated. If yes, continuing to judge whether the asset balance of the seller account is not lower than the target amount. Transferring the target amount of assets to a transaction contract account only if the seller account asset balance is not below the target amount.

For ease of understanding, assuming that the target amount information carried by the sale transaction is 300, the node first determines whether the seller account previously credited no less than 300 assets to the transaction contract account when executing the transfer logic. If yes, the node continues to determine whether the seller account has an asset balance not less than 300. If the seller account asset balance is not less than 300, then 300 assets under the seller account are transferred to the transaction contract account. Thus, the transaction contract account asset balance is increased 300 and the seller account asset balance is deducted 300, as shown in FIG. 3 (d).

In the transaction execution process shown in fig. 2, nodes of the blockchain network deploy, in response to a contract deployment request, corresponding transaction contracts in which selling information is declared. The nodes of the blockchain network also establish accounts for the transaction contract in an asset contract that records the seller's assets. The nodes of the blockchain network also transfer a target number of seller assets in the asset contract to an account of the transaction contract. In the present invention, assets are recorded by asset contracts. When a seller needs to develop an asset selling service, a node of the blockchain network deploys a corresponding trading contract to declare corresponding selling information, so that the selling information of the asset selling service is issued. Therefore, each intelligent contract is not overstaffed, and each trading contract can be individually deployed, so that the flexibility of the asset selling service can be effectively improved, and the selling information can be more flexibly issued.

It is also noted that during execution of the sale transaction, it is necessary to verify whether the signer of the signature data of the sale transaction is the seller declared in the transaction contract. If so, transfer logic in the corresponding asset contract is invoked to transfer the seller asset to the transaction contract account. In this way, users other than the seller may be prevented from mistakenly transferring their assets to the transaction contract account, resulting in their assets being sold.

It is also noted that, during execution of the sale transaction, the transfer logic declared in the asset contract is invoked, dominated by the transaction contract, thereby transferring the seller asset to the transaction contract account. Although the signer selling the transaction has been verified as the seller declared by the transaction contract before invoking the transfer logic declared in the asset contract. I.e., at the business level, it is ensured that the seller is actively transferring its assets to its deployed trading contracts. But for the computer base, it is equivalent to the transaction contract account actively requiring an asset contract to transfer seller assets to the transaction contract account, in short, it is equivalent to some account X actively requiring an asset contract to transfer assets of another account Y to account X. To further eliminate this computer-underlying logic vulnerability, in the present invention, the nodes enable seller assets to be pre-credited to a transaction contract account by performing a credited transaction. Then, during execution of the sale transaction, it is verified whether the seller asset is previously credited to the transaction contract account, and if so, the seller asset credited to the transaction contract account is actually transferred to the transaction contract account.

In the above, the invention provides a selling information issuing method through some preferred embodiments. Hereinafter, the present invention provides another selling information issuing method through another embodiment, aiming at improving the flexibility of the asset selling business. It should be noted that the following embodiments may be referred to with the above embodiments. It should be further noted that the selling information issuing method proposed in the following embodiments is not necessarily dependent on the service processing system shown in fig. 1 during implementation.

Referring to fig. 4, fig. 4 is a flowchart of a method for issuing vending information according to an embodiment of the present invention. The selling information issuing method is applied to any node in the block chain network. As shown in fig. 4, the selling information issuing method includes the steps of:

step S41: in response to a contract deployment request, deploying a trading contract in which selling information is declared;

step S42: establishing an account for the transaction contract in an asset contract that records seller assets;

step S43: transferring a target quantity of seller assets in the asset contract to an account of the transaction contract.

By executing the above-described steps S41 to S42, the nodes of the blockchain network deploy, in response to the contract deployment request, the corresponding trading contracts in which the selling information is declared. The nodes of the blockchain network also establish accounts for the transaction contract in an asset contract that records the seller's assets. The nodes of the blockchain network also transfer a target number of seller assets in the asset contract to an account of the transaction contract. In the present invention, assets are recorded by asset contracts. When a seller needs to develop an asset selling service, a node of the blockchain network deploys a corresponding trading contract to declare corresponding selling information, so that the selling information of the asset selling service is issued. Therefore, each intelligent contract is not overstaffed, and each trading contract can be individually deployed, so that the flexibility of the asset selling service can be effectively improved, and the selling information can be more flexibly issued.

Optionally, in some embodiments, the contract deployment request may be the aforementioned contract deployment transaction that carries contract data for a transaction contract to be deployed. When executing contract deployment transaction, the node deploys corresponding transaction contract according to contract data carried by the contract deployment transaction, and the transaction contract declares selling information and a plurality of contract method logics.

Optionally, in some embodiments, a selling logic is further declared in the trading contract, and the selling logic includes a call relation for calling the transfer logic declared in the asset contract. When the step S43 is executed, the following sub-steps are specifically executed:

substep S43-1: invoking the selling logic declared in the trading contract in response to a selling request;

substep S43-2: invoking the transfer logic declared in the asset contract to transfer a target number of seller assets in the asset contract to an account of the transaction contract in accordance with the call relationship included in the selling logic.

Wherein the vending request may be the aforementioned vending transaction.

In the invention, the nodes further call the transfer logic declared in the corresponding asset contract according to the calling relation contained in the selling logic by calling the selling logic declared in the transaction contract, and finally trigger the assets of the seller to be transferred to the transaction contract account. The beneficial effects are that: the seller asset is only transferred to the account of the transaction contract to ensure that the transaction contract has been successfully deployed and is available for normal use, avoiding the seller asset being transferred to the account of an abnormal transaction contract.

In particular implementations, if the node transfers the seller asset directly to the account of the trading contract without invoking the selling logic of the trading contract during the response to the sell request, the seller asset may be transferred to the account of the trading contract that has not yet been deployed, or to the account of the trading contract that failed to be deployed, or to the account of the trading contract that cannot be normally used. The seller assets are transferred in the mode provided by the invention, and the seller assets can be successfully transferred to the account of the transaction contract only under the condition that the transaction contract is successfully deployed and can be normally used, so that the selling logic stated in the transaction contract is successfully transferred, and further the transfer logic stated in the asset contract is transferred. Therefore, the invention can prevent the seller property from being transferred to the account of the abnormal transaction contract.

Optionally, in some embodiments, the transaction contract further declares vendor information. Wherein the seller information declared in the transaction contract may be a blockchain address of the seller. During the period of invoking and executing the selling logic of the transaction contract statement, the node verifies whether the requester of the selling request is the seller recorded in the transaction contract according to the auxiliary verification information carried by the selling request. If yes, the node continues to call the transfer logic declared in the asset contract according to the call relation contained in the selling logic. If not, the node does not invoke transfer logic declared in the asset contract.

In a specific implementation, the auxiliary verification information carried by the selling request may be the aforementioned signature data, that is, signature data of the selling transaction. The node can carry out signature verification on signature data of the selling transaction in advance before the selling transaction is executed. The sale transaction is executed only if the signature verification is passed. The node may determine whether the signer of the signature data is the seller of the transaction contract statement during the invocation and execution of the selling logic of the transaction contract statement. If yes, the transfer logic declared in the asset contract is called continuously according to the calling relation contained in the selling logic.

In the invention, when another seller needs to develop the asset selling service, a new trading contract needs to be deployed in the blockchain network, so that the asset selling service is developed based on the trading contract.

In the present invention, it is necessary to verify whether the requestor of the sale request (i.e., the signer of the signature data of the sale transaction) is the seller declared in the transaction contract during the response to the sale request. If so, transfer logic in the corresponding asset contract is invoked to transfer the seller asset to the transaction contract account. In this way, users other than the seller may be prevented from mistakenly transferring their assets to the transaction contract account, resulting in their assets being sold.

Optionally, in some embodiments, as previously described, trust logic is also declared in the asset contract. The node of the blockchain network further performs the steps of: and responding to a credit granting request, calling credit granting logic declared in the asset contract, and granting the corresponding amount of assets under the corresponding account in the asset contract to the account of the transaction contract according to the account name and the credit granting amount carried by the credit granting request.

The credit granting request may be the aforementioned credit granting transaction.

When the node of the blockchain network performs the foregoing sub-step S43-2, specifically, the transfer logic declared in the asset contract may be called according to the call relation included in the selling logic, so as to query whether the seller account previously credited no less than a target number of seller assets to the account of the transaction contract; if yes, executing the steps: transferring a target quantity of seller assets in the asset contract to an account of the transaction contract; if not, the step is not executed: transferring a target quantity of seller assets in the asset contract to an account of the transaction contract.

As previously described, the node pre-credits the seller asset to an account of the transaction contract in response to the credit request. When the node executes the transfer logic, whether the account of the seller previously awards the seller assets which are not less than the target number to the account of the transaction contract is inquired, and whether the seller assets which are not less than the target number are transferred to the account of the transaction contract is determined according to the inquiry result. Thus, the computer underlying logic loopholes can be effectively eliminated.

Referring to fig. 5, fig. 5 is a flowchart of a method for issuing vending information according to another embodiment of the present invention, where the method is applied to a message middleware. The method of issuing the selling information shown in fig. 5 may be referred to as the method of issuing the selling information shown in fig. 1, and the method of issuing the selling information shown in fig. 5 will be described only briefly to avoid redundancy. As shown in fig. 5, the selling information issuing method includes the steps of:

step S51: receiving a service message which is sent by a service end and used for selling assets, and analyzing the service message into a plurality of transactions, wherein the plurality of transactions comprise contract deployment transactions and selling transactions;

step S52: submitting the contract deployment transaction to a blockchain network such that nodes of the blockchain network deploy a transaction contract in response to the contract deployment transaction; the transaction contract declares selling information and selling logic, the selling logic comprises a calling relation, the calling relation is used for calling transfer logic declared in a corresponding asset contract, and the corresponding asset contract is an asset contract recording seller assets;

step S53: submitting the sale transaction to the blockchain network, so that nodes of the blockchain network respond to the sale transaction and call the sale logic stated in the transaction contract, and further call the transfer logic stated in the corresponding asset contract according to the call relation contained in the sale logic, so as to transfer the target number of seller assets in the asset contract to an account of the transaction contract.

Optionally, in some embodiments, the plurality of transactions further comprises trusted transactions. Before submitting the implemented selling transaction to the blockchain network, the message middleware can also submit the credit transaction to the blockchain network, so that the node of the blockchain network responds to the credit transaction, establishes an account for the transaction contract in an asset contract for recording the assets of a seller, and calls a credit logic stated in the asset contract, so that the assets with the corresponding number under the corresponding account in the asset contract are credited to the account of the transaction contract according to the account name and the credit amount carried by the credit transaction.

Optionally, in some specific embodiments, the service packet is parsed into a plurality of transactions carrying the same packet identifier. The message middleware may also perform the following steps: synchronizing a block from the blockchain network and reading transactions from the block, wherein the block records the transactions that have been executed by the blockchain network; recombining the service messages according to a plurality of transactions carrying the same message identification; and sending the recombined service message to each user equipment of the service end.

Based on the same inventive concept, an embodiment of the present invention further provides a service processing system, as shown in fig. 1, the service processing system includes: the system comprises message middleware and a blockchain network, wherein the blockchain network comprises a plurality of nodes.

The message middleware is used for receiving a service message which is sent by a service end and used for selling assets, and analyzing the service message into a plurality of transactions, wherein the transactions comprise contract deployment transactions and selling transactions.

The message middleware is further used for submitting the contract deployment transaction to a blockchain network.

The nodes of the blockchain network are configured to deploy a transaction in response to the contract, thereby deploying a transaction contract; the trading contract is declared to have selling information and selling logic, the selling logic comprises a calling relation, the calling relation is used for calling transfer logic declared in a corresponding asset contract, and the corresponding asset contract is an asset contract for recording the assets of a seller.

The message middleware is further used for submitting the selling transaction to the block chain network.

The nodes of the blockchain network are further configured to invoke the selling logic declared in the trading contract in response to the selling transaction to further invoke the transfer logic declared in the corresponding asset contract according to a call relationship included in the selling logic to transfer a target number of seller assets in the asset contract to an account of the trading contract.

Optionally, in some embodiments, the transaction contract further declares vendor information; the node of the blockchain network, when being configured to respond to the sale transaction, is further specifically configured to: according to the auxiliary verification information carried by the selling request, verifying whether a requester of the selling request is a seller recorded in the transaction contract; if yes, the transfer logic declared in the corresponding asset contract is further called; if not, the transfer logic declared in the corresponding asset contract is not invoked.

Optionally, in some specific embodiments, the plurality of transactions parsed from the service packet further include a credit authorization transaction, and the packet middleware is further configured to submit the credit authorization transaction to the blockchain network before being configured to submit the sale transaction to the blockchain network;

the nodes of the block chain network are also used for responding to the credit granting transaction, so as to establish an account for the transaction contract in an asset contract for recording the assets of a seller, and call the credit granting logic declared in the asset contract, so as to grant the corresponding amount of the assets under the corresponding account in the asset contract to the account of the transaction contract according to the account name and the credit granting amount carried by the credit granting transaction;

when responding to the selling transaction, the node of the block chain network is specifically configured to: calling the transfer logic declared in the asset contract according to the calling relation contained in the selling logic so as to inquire whether the account of the seller previously awards no less than a target number of seller assets to the account of the transaction contract; if yes, executing the steps: transferring a target quantity of seller assets in the asset contract to an account of the transaction contract; if not, the step is not executed: transferring a target quantity of seller assets in the asset contract to an account of the transaction contract.

For the system embodiment, since it is basically similar to the method embodiment, the description is simple, and for the relevant points, refer to the partial description of the method embodiment.

Based on the same inventive concept, an embodiment of the present invention further provides an electronic device, as shown in fig. 6, including a processor 601, a communication interface 602, a memory 603, and a communication bus 604, where the processor 601, the communication interface 602, and the memory 603 complete communication with each other through the communication bus 604.

The memory 603 is used for storing computer programs;

the processor 601 is configured to implement the following steps when executing the program stored in the memory 603:

Alternatively, the processor 601 is configured to implement the following steps when executing the program stored in the memory 603:

Alternatively, the processor 601 is configured to implement the steps of the selling information issuing method provided by the above other method embodiments of the present invention when executing the program stored in the memory 603.

The communication bus mentioned in the electronic device may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The communication bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown, but this does not mean that there is only one bus or one type of bus.

The communication interface is used for communication between the electronic equipment and other equipment.

The Memory may include a Random Access Memory (RAM) or a non-volatile Memory (non-volatile Memory), such as at least one disk Memory. Optionally, the memory may also be at least one memory device located remotely from the processor.

The Processor may be a general-purpose Processor, and includes a Central Processing Unit (CPU), a Network Processor (NP), and the like; the Integrated Circuit may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other Programmable logic device, a discrete Gate or transistor logic device, or a discrete hardware component.

In another embodiment of the present invention, a computer-readable storage medium is further provided, which stores instructions that, when executed on a computer, cause the computer to execute the vending information issuing method described in any of the above embodiments.

In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the invention to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, from one website site, computer, server, or data center to another website site, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., Solid State Disk (SSD)), among others.

It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.

All the embodiments in the present specification are described in a related manner, and the same and similar parts among the embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.

The above description is only for the preferred embodiment of the present invention, and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention shall fall within the protection scope of the present invention.

Claims

1. A selling information publishing method is applied to any node in a block chain network, and comprises the following steps:

2. The method of claim 1, wherein a selling logic is further declared in the trading contract, the selling logic comprising a call relationship for calling a transfer logic declared in the asset contract; the transferring of the target quantity of the seller asset in the asset contract to the account of the transaction contract, comprising:

invoking the selling logic declared in the trading contract in response to a selling request;

invoking the transfer logic declared in the asset contract to transfer a target number of seller assets in the asset contract to an account of the transaction contract in accordance with the call relationship included in the selling logic.

3. The method of claim 2, wherein the transaction contract further declares vendor information; before invoking the transfer logic declared in the asset contract according to the invocation relationship contained in the selling logic, the method further comprises:

according to the auxiliary verification information carried by the selling request, verifying whether a requester of the selling request is a seller recorded in the transaction contract;

if not, the transfer logic declared in the asset contract is not invoked.

4. The method of claim 3, wherein trust logic is also declared in the asset contract, the method further comprising:

responding to a credit granting request, calling credit granting logic declared in the asset contract, and granting the corresponding amount of assets under the corresponding account in the asset contract to the account of the transaction contract according to the account name and the credit granting amount carried by the credit granting request;

the invoking the transfer logic declared in the asset contract to transfer the target quantity of seller assets in the asset contract to an account of the transaction contract in accordance with the call relationship contained in the selling logic, comprising:

calling the transfer logic declared in the asset contract according to the calling relation contained in the selling logic so as to inquire whether the account of the seller previously awards no less than a target number of seller assets to the account of the transaction contract;

if yes, executing the steps: transferring a target quantity of seller assets in the asset contract to an account of the transaction contract;

if not, the step is not executed: transferring a target quantity of seller assets in the asset contract to an account of the transaction contract.

5. A selling information issuing method is applied to message middleware and is characterized by comprising the following steps:

6. The method of claim 5, wherein the plurality of transactions further comprises a credit transaction, and wherein prior to submitting the sale transaction to the blockchain network, the method further comprises:

and submitting the credit transaction to the block chain network, so that nodes of the block chain network respond to the credit transaction, establish accounts for the transaction contract in an asset contract for recording the assets of a seller, and call credit logic declared in the asset contract, so as to credit the corresponding amount of assets under the corresponding accounts in the asset contract to the accounts of the transaction contract according to the account names and credit amount carried in the credit transaction.

7. The method according to claim 5 or 6, wherein the service message is parsed into a plurality of transactions carrying the same message identifier, the method further comprising:

synchronizing a block from the blockchain network and reading transactions from the block, wherein the block records the transactions that have been executed by the blockchain network;

recombining the service messages according to a plurality of transactions carrying the same message identification;

and sending the recombined service message to each user equipment of the service end.

8. A service processing system comprising message middleware and a blockchain network, wherein the blockchain network comprises a plurality of nodes;

the message middleware is used for receiving a service message which is sent by a service end and used for selling assets, and analyzing the service message into a plurality of transactions, wherein the transactions comprise contract deployment transactions and selling transactions;

the message middleware is also used for submitting the contract deployment transaction to a block chain network;

the nodes of the blockchain network are configured to deploy a transaction in response to the contract, thereby deploying a transaction contract; the transaction contract declares selling information and selling logic, the selling logic comprises a calling relation, the calling relation is used for calling transfer logic declared in a corresponding asset contract, and the corresponding asset contract is an asset contract recording seller assets;

the message middleware is also used for submitting the selling transaction to the block chain network;

9. An electronic device is characterized by comprising a processor, a communication interface, a memory and a communication bus, wherein the processor and the communication interface are used for realizing mutual communication by the memory through the communication bus;

the memory is used for storing a computer program;

the processor, when executing a program stored in the memory, is adapted to carry out the method steps of any of claims 1 to 4 or to carry out the method steps of any of claims 5 to 7.

10. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the method steps of any one of claims 1 to 4 or carries out the method steps of any one of claims 5 to 7.