CN112714157B - Asset contract issuing method and device, electronic equipment and readable storage medium - Google Patents
Asset contract issuing method and device, electronic equipment and readable storage medium Download PDFInfo
- Publication number
- CN112714157B CN112714157B CN202011507358.5A CN202011507358A CN112714157B CN 112714157 B CN112714157 B CN 112714157B CN 202011507358 A CN202011507358 A CN 202011507358A CN 112714157 B CN112714157 B CN 112714157B
- Authority
- CN
- China
- Prior art keywords
- contract
- transaction
- asset
- message
- constraint file
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/562—Brokering proxy services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Business, Economics & Management (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Finance (AREA)
- Accounting & Taxation (AREA)
- General Engineering & Computer Science (AREA)
- General Health & Medical Sciences (AREA)
- Strategic Management (AREA)
- Computer Hardware Design (AREA)
- Bioethics (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Software Systems (AREA)
- Technology Law (AREA)
- General Business, Economics & Management (AREA)
- Computing Systems (AREA)
- Health & Medical Sciences (AREA)
- Data Mining & Analysis (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
The embodiment of the invention provides a method and a device for issuing an asset contract, electronic equipment and a readable storage medium. The method for issuing the asset contract comprises the following steps: the message middleware receives a first service message, wherein the first service message carries an asset type identifier and contract parameters for constructing an asset contract; the message middleware determines a target contract module corresponding to the asset type identifier from a plurality of preset contract templates according to the asset type identifier carried by the first service message; the message middleware constructs an asset contract to be issued according to the target contract template and contract parameters carried by the first service message; and the message middleware generates contract issuing transaction and submits the contract issuing transaction to a block chain network for execution, wherein the contract issuing transaction comprises the asset contract to be issued.
Description
Technical Field
The present invention relates to the field of communications technologies, and in particular, to a method and an apparatus for issuing an asset contract, an electronic device, and a readable storage medium.
Background
The block chain technology is realized on a block chain network, distributed node equipment (hereinafter referred to as nodes) in the block chain network realizes generation and consensus of block data by operating a block chain program, finally realizes a tamper-proof mechanism of the data, and provides 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, a user may issue digital assets to a blockchain through intelligent contracts, or may host digital assets through intelligent contracts, and these intelligent contracts combined with digital assets may be referred to as asset contracts for short. In order to deploy an asset contract in a blockchain network, a user generally needs to write the asset contract in advance, and then issue the written asset contract to the blockchain network in a trading manner. However, since there may be discrepancies in the asset contracts written by different users, when users issue asset contracts on the blockchain network, there is no uniform standard between the assets of each of the plurality of asset contracts, thus limiting the exchange of assets.
Disclosure of Invention
The embodiment of the invention aims to provide a method and a device for issuing an asset contract, electronic equipment and a readable storage medium. The specific technical scheme is as follows:
in a first aspect of embodiments of the present invention, a method for issuing an asset contract is provided, where the method includes:
the message middleware receives a first service message, wherein the first service message carries an asset type identifier and contract parameters for constructing an asset contract;
the message middleware determines a target contract module corresponding to the asset type identifier from a plurality of preset contract templates according to the asset type identifier carried by the first service message;
the message middleware constructs an asset contract to be issued according to the target contract template and contract parameters carried by the first service message;
and the message middleware generates contract issuing transaction and submits the contract issuing transaction to a block chain network for execution, wherein the contract issuing transaction comprises the asset contract to be issued.
In a second aspect of the embodiments of the present invention, an apparatus for issuing an asset contract is provided, which is applied to message middleware, and the apparatus includes:
the system comprises a service message receiving module, a first service message sending module and a second service message sending module, wherein the service message receiving module is used for receiving a first service message, and the first service message carries an asset type identifier and contract parameters for constructing an asset contract;
a contract module determining module, configured to determine, according to the asset type identifier carried in the first service packet, a target contract module corresponding to the asset type identifier from multiple preset contract templates;
the asset contract construction module is used for constructing an asset contract to be issued according to the target contract template and contract parameters carried by the first service message;
and the contract issuing transaction generating module is used for generating a contract issuing transaction and submitting the contract issuing transaction to the block chain network for execution, wherein the contract issuing transaction comprises the asset contract to be issued.
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 method for issuing the asset contract provided by any embodiment of the invention when the program stored on the memory is executed.
In a fourth aspect of embodiments of the present invention, there is provided a computer-readable storage medium on which is stored a computer program that, when executed by a processor, implements a method of issuing an asset contract as provided by any of the embodiments of the present invention.
In the invention, a plurality of contract templates are preset in the message middleware, and when any user needs to issue an asset contract, a first service message can be sent to the message middleware through a client side of the user. After receiving the first service message, the message middleware determines a target contract module corresponding to the asset type identifier from a plurality of preset contract templates according to the asset type identifier carried in the first service message, and then constructs an asset contract to be issued according to the target contract template and contract parameters carried in the first service message. Therefore, the asset contract is constructed for each user through the message middleware according to the contract template, so that the asset contract has a unified standard.
In addition, the message middleware also automatically generates a contract issuing transaction, and the contract issuing transaction comprises the asset contract to be issued. And the message middleware submits the contract issuing transaction to a blockchain network for execution, so that the blockchain network issues the asset contract to be issued.
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 business processing system that may be used to publish an asset contract according to one embodiment of the present invention;
FIG. 2 is a flow diagram of a method for issuing an asset contract as set forth in one embodiment of the present invention;
FIG. 3 is a schematic diagram of an asset contract issuing device according to an embodiment of the present invention;
fig. 4 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 obtained by a person skilled in the art without making any creative effort based on the embodiments in the present invention, belong to the protection scope of the present invention.
The block chain technology is realized on a block chain network, distributed node equipment (hereinafter referred to as nodes) in the block chain network realizes generation and consensus of block data by operating a block chain program, finally realizes a tamper-proof mechanism of the data, and provides a safe and reliable new technical idea for business development.
In the related art, a user may issue digital assets to a block chain through an intelligent contract, or may host the digital assets through the intelligent contract, and these intelligent contracts combined with the digital assets may be referred to as asset contracts for short. In order to deploy an asset contract in a blockchain network, a user generally needs to write the asset contract in advance, and then issue the written asset contract to the blockchain network in a trading manner. However, since there may be differences in the asset contracts written by different users, when users issue asset contracts over the blockchain network, there is no uniform standard between the assets of each of the plurality of asset contracts, thereby limiting the exchange of assets.
In view of the above, the present invention provides a method, an apparatus, an electronic device and a readable storage medium for issuing an asset contract, which are provided by the following embodiments and are intended to form a unified standard when issuing an asset contract.
Referring to FIG. 1, FIG. 1 is a schematic diagram of a business processing system that may be used to publish an asset contract according to one embodiment of the invention. As shown in fig. 1, the service processing system includes: the system comprises a block chain network, a plurality of message middleware and a plurality of user terminals. The client may be communicatively coupled to message middleware, which may in turn be communicatively coupled to any node or designated node within the blockchain network. Thus, the user terminal realizes indirect communication with the block chain network through the message middleware.
Specifically, the user side transmits the service message to the message middleware, so that information is transferred to the message middleware. The message middleware analyzes the service message sent by the user side into one or more transactions, and submits the analyzed transactions to the block chain network, so that information is transmitted to the block chain network. In addition, the message middleware acquires information from the block chain network through blocks generated by the synchronous block chain network or an account book database of the synchronous block chain network. The message middleware assembles the information acquired from the blockchain network into a service message, and then returns the assembled service message to the user side, thereby realizing the information transmission to the user side. Thus, the user terminal realizes indirect communication with the block chain network through the message middleware.
The message middleware encapsulates the complex interface of the blockchain network into a simple and standard financial service interface and provides the interface to the user side, so that the interaction difficulty between the user side and the blockchain network is reduced.
In the service processing system, the user side, the message middleware and the block chain network are three technical layers from top to bottom, and the three technical layers can be represented as a hardware layer or a software layer, which is not limited in the present invention.
For example, the message middleware may be a software program or a hardware device. In the case that the message middleware is a software program, the message middleware may run in a certain node device of the blockchain network, may run in a computer on the user side, and may run in a certain computer between the blockchain network and the user side.
For example, the user terminal may be a software program or a hardware device. In the case that the user terminal is a software program, the user terminal may operate in a certain node device of the blockchain network, or may operate in a computer separately outside the blockchain network.
Optionally, in some embodiments, the information is transferred between the user terminal and the message middleware based on the communication message. When the user end transmits the service information to the message middleware, the user end packages the service message in the message body of the communication message, and the service message is sent to the message middleware by the user end along with the communication message. Similarly, when the message middleware transmits service information to the user terminal, the message middleware encapsulates the service message in the message body of the communication message, and the service message is sent to the user terminal by the message middleware along with the communication message. The communication message may be selected from: hypertext transfer protocol messages (HTTP), user datagram protocol messages (UDP), and the like. It should be noted that the present invention does not limit the type of the communication packet.
Optionally, in some embodiments, each ue corresponds to one message middleware, and one message middleware may correspond to a plurality of ues. Each user terminal realizes indirect communication with the block chain network through the corresponding message middleware.
In specific implementation, different user groups respectively correspond to different message middleware, so that each user group can independently manage and maintain the message middleware, and the safety of the message middleware is improved. For ease of understanding, multiple branches of a bank may, for example, be considered a group of users. For example, a plurality of branches of bank a correspond to message middleware a, a plurality of branches of bank B correspond to message middleware B, and a plurality of branches of bank C correspond to message middleware C. In this scenario, by implementing the following information transfer method, when each bank processes the service using the blockchain network, information can be conveniently transferred between different banks (for example, between bank a and bank B) through the blockchain network.
In the above, the present invention has been described with respect to the business processing system shown in fig. 1, which can be used to implement the method for issuing an asset contract according to the present invention. It should be noted, however, that the implementation of the method for issuing an asset contract is not dependent on the business processing system shown in fig. 1, and the business processing system shown in fig. 1 should not be considered as limiting the present invention.
Referring to fig. 2, fig. 2 is a flow chart of a method for issuing an asset contract according to an embodiment of the present invention. As shown in fig. 2, the method for issuing an asset contract comprises the steps of:
step S21: the message middleware receives a first service message, wherein the first service message carries an asset type identifier and contract parameters for constructing an asset contract.
Wherein the asset type identifier is used to characterize the asset type. For ease of understanding, an asset type identifier, illustratively "bond", is used to characterize bond assets and an asset type identifier, illustratively "fund", is used to characterize fund assets.
The contract parameters used to construct the asset contract may be business related parameters such as the quantity of assets, the blockchain address of the asset owner, etc.
Optionally, in some embodiments, the first service packet may be sent by the user end to the message middleware, and the specific sending process may refer to fig. 1 and related contents of fig. 1.
Optionally, in other embodiments, the first service packet may also be sent to the message middleware by the message conversion system. For example, the user side may first send a swift message to the message conversion system, where the swift message carries the asset type identifier and the contract parameters for constructing the asset contract. And after receiving the swift message, the message conversion system converts the swift message into a service message supported by the message middleware, wherein the service message inherits the asset type identification carried by the swift message and contract parameters for constructing an asset contract. And the message middleware sends the converted service message to the message middleware.
Step S22: and the message middleware determines a target contract module corresponding to the asset type identifier from a plurality of preset contract templates according to the asset type identifier carried by the first service message.
In the invention, a plurality of contract templates are preset in the message middleware, and the plurality of contract templates respectively correspond to different asset type identifications. And after receiving the first service message, the message middleware reads the asset type identifier from the first service message, and determines a target contract module corresponding to the asset type identifier from a plurality of preset contract templates by taking the read asset type identifier as an index.
Optionally, in some specific embodiments, the first service packet may further carry a service type identifier, where the service type identifier is used to represent a service type used by the first service packet for processing.
For convenience of understanding, for example, assuming that a user currently wants to publish an asset in a blockchain network, the user may send a first service packet for publishing the asset to the message middleware through the user side of the user, where a service type carried in the first service packet is identified as SMTA, and the SMTA indicates that the first service packet is used for publishing the asset. Or exemplarily, assuming that a user currently wants to rollback all assets hosted in a certain intelligent contract to a self account, the user may send a first service packet for asset rollback to a packet middleware through a user side of the user, where a service type identifier carried in the first service packet is SMTC, and the SMTC indicates that the first service packet is used for rolling back assets. The user may be an individual user or an enterprise user (e.g., a financial institution such as a bank or a stock exchange).
Each contract template preset in the message middleware corresponds to not only a corresponding asset type identifier, but also a corresponding service type identifier. And after receiving the first service message, the message middleware reads the service type identifier and the asset type identifier from the first service message, and determines a target contract module which simultaneously corresponds to the service type identifier and the asset type identifier from a plurality of preset contract templates by taking the read service type identifier and the read asset type identifier as indexes.
For understanding, the message middleware illustratively reads the service type identifier and the asset type identifier from a certain first service message after receiving the first service message. Assuming that the service type identifier and the asset type identifier read by the message middleware are in the form of "SMTA-bond", where the service type identifier is SMTA and indicates that the first service message is used for issuing assets, and the asset type identifier is bond and indicates that the asset type required to be issued by the first service message is bonds. Therefore, the message middleware takes the SMTA-bond as an index and inquires a contract template corresponding to the SMTA-bond from a plurality of preset contract templates. It should be noted that when the block chain network is used to develop the asset publishing service, a new asset contract needs to be deployed in the block chain network, so the contract template corresponding to the "SMTA-bond" is preset in the message middleware, and the message middleware can query the contract template corresponding to the "SMTA-bond".
Or exemplarily, after receiving another first service packet, the packet middleware reads the service type identifier and the asset type identifier from the first service packet. The service type identifier and the asset type identifier read by the message middleware are assumed to be like 'SMTC-fund', wherein the service type identifier is SMTC, which indicates that the first service message is used for fallback of an asset, the asset type identifier is fund, which indicates that the asset type of the first service message that needs to be fallback is a fund. Therefore, the message middleware takes the SMTC-fund as an index and inquires a contract template corresponding to the SMTC-fund from a plurality of preset contract templates. It should be noted that when a fallback asset service is developed in a block chain network, it is usually not necessary to deploy a new asset contract, so that the message middleware does not preset a contract template corresponding to the "SMTC-fund", and the message middleware cannot query the contract template corresponding to the "SMTC-fund".
Step S23: and the message middleware constructs an asset contract to be issued according to the target contract template and contract parameters carried by the first service message.
In particular implementations, each contract template may define the contract parameters it needs to fill in. After the message middleware determines the target contract template, corresponding contract parameters can be read from the first service message according to the contract parameters required to be filled in the target contract template and are filled in the target contract template, so that the asset contract to be issued is constructed.
Step S24: and the message middleware generates a contract issuing transaction and submits the contract issuing transaction to a block chain network for execution, wherein the contract issuing transaction comprises the asset contract to be issued.
Optionally, in some specific embodiments, a plurality of message parsing policies for parsing the service message are further preset in the message middleware, and each message parsing policy corresponds to one service type identifier, and is used for parsing the service message including the corresponding service type identifier, so as to obtain one or more transactions related to the corresponding service type.
And after the message middleware receives the service message, reading the service type identification from the service message, and searching a message analysis strategy corresponding to the service type identification from a plurality of preset message analysis strategies by taking the read service type identification as an index. And the message middleware analyzes the service message into a plurality of transactions based on the searched message analysis strategy.
In a specific implementation, 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 analysis strategy is at least used for limiting the message analysis operation as follows:
1. the transaction quantity of the transaction 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.
When the message analysis strategy corresponding to part of the service type identification analyzes the corresponding service message, the obtained multiple transactions include contract issuing transactions for issuing asset contracts. For example, when a message parsing policy corresponding to the service type identifier SMTA (used for issuing assets) parses the first service message used for issuing assets, the first service message is parsed to obtain a contract issuance transaction.
And when the message analysis strategy corresponding to other service type identifications is used for analyzing corresponding service messages, the obtained multiple transactions do not contain contract issuing transactions for issuing asset contracts. For example, when a message parsing policy corresponding to a service type identifier SMTC (for fallback assets) parses a first service message for fallback assets, a plurality of transactions are parsed, but the transaction does not include a contract issuance transaction.
For convenience of understanding, the message middleware illustratively reads the service type identifier SMTA from a certain first service message after receiving the first service message. Then, the message middleware uses the service type identifier SMTA as an index to find out a message analysis policy X corresponding to the service type identifier SMTA from a plurality of preset message analysis policies. And then, the message middleware analyzes the first service message based on the message analysis strategy X.
The message analysis strategy X makes the following limitations on the message analysis operation:
1. analyzing the service message into 1 transaction, wherein the transaction is a contract issuing transaction;
2. when a contract issuing transaction f is constructed, reading the identity of a user initiating the service message from the 5 th field and the 6 th field of the service message, and filling the read identity into the 3 rd field and the 4 th field of the transaction template f; when a contract issuance transaction f is constructed, an asset contract also needs to be constructed and populated at the 5 th to 100 th fields of the transaction template f.
Thus, when the message middleware analyzes the first service message based on the message analysis policy X, the identity identifier is firstly read from the 5 th field and the 6 th field of the first service message, and the read identity identifier is filled in the 3 rd field and the 4 th field of the transaction template f.
Since the message parsing policy X defines that an asset contract needs to be constructed, the message middleware then further performs the following steps (i.e., step S22 and step S23):
and reading a service type identifier and an asset type identifier from the first service message, and assuming that the service type identifier and the asset type identifier read by the message middleware are in the shape of an SMTA-bond, wherein the service type identifier is an SMTA and indicates that the first service message is used for issuing assets, and the asset type identifier is a bond and indicates that the asset type required to be issued by the first service message is bonds. Therefore, the message middleware takes the SMTA-bond as an index and inquires a contract template corresponding to the SMTA-bond from a plurality of preset contract templates. And then, the message middleware reads contract parameters from the first service message and fills the read contract parameters into the inquired contract template, thereby constructing the asset contract to be issued. And the message middleware fills the asset contract to be issued to the 5 th to 100 th fields of the transaction template f so as to form a contract issuing transaction f.
It should be noted that the specific data (e.g., service type identifier, asset type identifier, transaction amount, transaction data, field number, etc.) referred to in the above examples are only illustrative examples. During actual implementation of the invention, the actual data involved may be the same as or different from the data in the above examples.
It should be further 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.
By performing the above steps S21 to S24, the following advantageous effects can be achieved:
because a plurality of contract templates are preset in the message middleware, any user can send a first service message to the message middleware through the client when needing to issue an asset contract. After receiving the first service message, the message middleware determines a target contract module corresponding to the asset type identifier from a plurality of preset contract templates according to the asset type identifier carried by the first service message, and then constructs an asset contract to be issued according to the target contract template and contract parameters carried by the first service message. Therefore, the asset contract is constructed for each user through the message middleware according to the contract template, so that the asset contract has a unified standard.
In addition, the message middleware also automatically generates a contract issuing transaction, and the contract issuing transaction comprises the asset contract to be issued. And the message middleware submits the contract issuing transaction to a blockchain network for execution, so that the blockchain network issues the asset contract to be issued.
Optionally, in some specific embodiments, the first service packet further carries a constraint file ID, and the contract issuance transaction generated by the packet middleware inherits the constraint file ID. When executing contract issuing transaction, the node of the block chain network specifically executes the following steps:
the node takes a constraint file ID carried by a contract issuing transaction as an index, and inquires a target constraint file corresponding to the constraint file ID from an account book database; the node judges whether the contract issuing transaction meets the execution condition limited by the target constraint file or not according to the target constraint file; in the case where the contract issuance transaction does not satisfy the execution condition, the node does not execute the contract issuance transaction.
The execution conditions defined by the target constraint file include, but are not limited to: the transaction initiator (i.e. the user initiating the corresponding first service message) should have the property contract issuing authority permission, and the contract issuing transaction should pass the endorsement of the endorsement node.
During specific implementation, a plurality of identity identifications are recorded in the target constraint file, and users corresponding to the identity identifications have the property contract issuing authority permission. In addition, the target constraint file also records an endorsement verification policy, and under which endorsement condition the contract issuing transaction is agreed, the contract issuing transaction is passed. Illustratively, referring to Table 1, table 1 is a schematic table of the target constraint file. It should be noted that the specific contents in table 1 are only exemplary and are not intended to limit the present invention.
TABLE 1 schematic table of object constraint files
As shown in table 1, user ID3601, user ID5308, user ID6773, and the like have authority to issue asset contracts. As shown in table 1, the contract issuance transaction is only computed through the endorsement node when more than 50% of the endorsement nodes agree to execute the contract issuance transaction.
In this way, after querying the target constraint file shown in table 1 from the ledger database, the node of the blockchain network determines whether the contract issuance transaction satisfies the execution condition defined by the target constraint file. When the node judges, specifically: on one hand, reading an identity from the contract issuing transaction, and then inquiring whether the identity is recorded in a target constraint file; on the other hand, according to the endorsement result of each endorsement node for the contract issuing transaction, whether more than 50% of the endorsement results are agreeing to execute the contract issuing transaction is judged.
And if the identity is recorded in the target constraint file and more than 50% of endorsement results are that the execution of the contract issuing transaction is agreed, determining that the contract issuing transaction meets the execution condition defined by the target constraint file. Otherwise, it is determined that the contract issuance transaction does not satisfy the execution condition defined by the target constraint file. Further, if the contract issuance transaction does not satisfy the execution condition defined by the target constraint file, the node does not execute the contract issuance transaction.
It should be noted that the invention does not limit how the block chain network endorses the contract issuance transaction through the endorsement node. For example, after the message middleware submits the contract issuance transaction to a designated node of the block chain network, the designated node may send the contract issuance transaction to a plurality of endorsement nodes for endorsement, and receive endorsement results returned by the respective endorsement nodes. And the designated node fills a plurality of endorsement results into the contract issuing transaction and then sends the contract issuing transaction to the sequencing node of the block chain network. The sequencing node sequences and packages the plurality of transactions received within a segment to generate a transaction package. And the sequencing node distributes the generated transaction package to each node of the block chain network, and after each node receives the transaction package, each node can read a contract issuing transaction from the transaction package and further read a plurality of endorsement results from the contract issuing transaction.
In the invention, the execution of the contract issuing transaction is restricted by the restriction file, so that the compliance of the asset contract issuing period can be effectively improved. In addition, since a plurality of constraint files are stored in the node, the user can specify the ID of the constraint file in the first service message, so that the selection of the constraint file can meet the requirement of service diversity.
Optionally, in some specific embodiments, the asset contract to be issued constructed by the message middleware includes one or more contract methods, and the target constraint file determined by the node records one or more key contract methods and the sub-execution condition corresponding to each key contract method.
In specific implementation, each sub-execution condition records a plurality of identity identifications, and users corresponding to the identity identifications have the property contract issuing authority permission. In addition, each sub-execution condition also records an endorsement verification policy, and under the endorsement condition that is agreed, the contract method corresponding to the sub-execution condition carries out endorsement through the endorsement node. Illustratively, referring to Table 2, table 2 is a schematic table of the target constraint file. It should be noted that the specific contents in table 2 are only exemplary and are not intended to limit the present invention.
TABLE 2 schematic Table of the target constraint File
As shown in table 2, user ID3601, user ID5308, user ID6773, user ID 7541, and user ID7987, etc. have the authority to invoke key contract method 1. As shown in table 2, for a transaction that invokes the key contract method 1, the transaction is endorsed by the endorsement node only if more than 50% of the endorsement nodes agree to perform the transaction.
As shown in table 2, user ID3601, user ID5308, user ID6773, user ID 1356, user ID 5926, and the like have authority to invoke key contract method 2. As shown in table 2, for a transaction that invokes key contract method 2, the transaction is endorsed only through the endorsement node if more than 50% of the endorsement nodes agree to perform the transaction.
If the node of the blockchain network determines that the contract issuing transaction meets the execution condition defined by the target constraint file through the above specific implementation manner, the node of the blockchain network further determines whether the asset contract to be issued contains all the key contract methods recorded in the target constraint file. If so, the node executes the contract issuance transaction to issue the asset contract in the blockchain. If not, the node does not execute the contract issuance transaction, and therefore does not issue asset contracts in the blockchain.
For ease of understanding, assume by way of example that 3 contract methods are included in the contract issuance transaction, two of the 3 contract methods being key contract method 1 and key contract method 2 in Table 2, respectively. Thus, the contract issuance transaction contains all of the key contract methods recorded in the target constraint file. Thus, the node may execute the contract issuance transaction.
In the present invention, the key contract methods are defined by the constraint file, and the contract issuance transaction can be executed only when all of the key contract methods defined by the constraint file are included in the asset contract. Therefore, the asset contract issued to the blockchain network must contain the key contract method, so that the integrity of the asset contract can be effectively ensured, and the normalization and the unified standard of the asset contract are further improved.
Optionally, in some specific embodiments, the method for issuing an asset contract may further include a step of deploying the constraint file, where the specific deploying step is as follows:
the message middleware receives a second service message, wherein the second service message carries a constraint file to be deployed; the message middleware generates a constraint file ID for the constraint file to be deployed; and the message middleware generates a constraint file deployment transaction according to the second service message, submits the constraint file deployment transaction to the blockchain network for execution, wherein the constraint file deployment transaction comprises the constraint file to be deployed, and also carries the constraint file ID of the constraint file to be deployed.
In a specific implementation, the constraint file to be deployed carried by the second service packet may be in the form of a constraint file shown in table 1 or table 2, and the execution conditions in the constraint file and the like are filled into the specified field of the second service packet.
In specific implementation, in order to generate a Unique constrained file ID, the message middleware may input data such as a timestamp, a number of the message middleware itself, and a Universal Unique Identifier (UUID) into the hash algorithm model to 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 values as the constrained file ID.
In specific implementation, the second service packet may carry a service type identifier SMTBD, where the SMTBD indicates that the second service packet is used to deploy the constraint file. In order to generate the constrained file deployment transaction according to the second service packet, as described above, the message middleware may read the service type identifier SMTBD from the second service packet, search a packet parsing policy corresponding to the service type identifier SMTBD from a plurality of preset packet parsing policies by using the service type identifier SMTBD as an index, and parse the second service packet into the constrained file deployment transaction based on the determined packet parsing policy. The constraint file deployment transaction can be a json-format file, the constraint file ID generated by the message middleware is filled in the specified field of the constraint file deployment transaction, and the constraint file to be deployed carried in the second service message is filled in the other specified fields of the constraint file deployment transaction. For a specific analysis example, reference may be made to the foregoing contents, and details are not described herein to avoid repetition.
During specific implementation, the node of the block chain network records the constraint file to be deployed carried by the constraint file deployment transaction to the account book database by executing the constraint file deployment transaction, so that the deployment of the constraint file is completed. After the node of the block chain network successfully deploys the constraint file, an execution result in the form of "yes" is generated, and the execution result yes represents that the node successfully executes the constraint file deployment transaction.
Optionally, in some specific embodiments, the message middleware may further obtain an execution result of the constrained file deployment transaction by the blockchain network; and under the condition that the execution result represents that the block chain network has successfully executed the constraint file deployment transaction, the message middleware sends the generated constraint file ID to a target user side.
In specific implementation, after the nodes of the blockchain network execute the transactions in the transaction package, a new block may be generated, where the block records the transactions included in the transaction package and the execution result of each transaction, and the nodes of the blockchain network mutually identify the respective generated blocks. And when the designated node of the block chain network determines that the generated blocks pass the consensus, the designated node sends the generated blocks to the message middleware. After the message middleware receives the block, the constraint file deployment transaction and the execution result of the constraint file deployment transaction can be read from the block.
If the execution result of the constraint file deployment transaction is yes, the constraint file deployment transaction is successfully executed. In this way, the message middleware can fill the pre-generated constraint file ID and the execution result yes into the pre-received second service message, and then send the second service message to the target user side, so that the target user side can read the constraint file and the constraint file ID thereof from the second service message after receiving the second service message, so that when asset contracts need to be issued subsequently, the corresponding constraint file ID can be specified. Wherein, the target client may refer to: all clients in communication connection with the message middleware.
Optionally, in some embodiments, the method of issuing the asset contract may further include a step for signing the asset contract transaction. Specifically, the first service packet may also carry an identity of a user initiating the first service packet. The user's id may be the user's blockchain address. Before submitting the contract issuing transaction to the blockchain network for execution, the message middleware can also submit the contract issuing transaction and the identity in the first service message to the key management system in advance, so that the key management system queries the corresponding private key according to the identity and signs the contract issuing transaction by using the queried private key. And the message middleware receives the signed contract issuing transaction returned by the key management system and submits the signed contract issuing transaction to the block chain network for execution.
Each node of the block chain network stores a public key of a user, before processing a contract issuing transaction, the node can firstly use the public key of the user to perform signature verification on the contract issuing transaction, and then execute subsequent steps (for example, judge whether the contract issuing transaction meets the execution condition defined by a target constraint file) under the condition that the signature verification is passed.
In the invention, the number of the key management systems is multiple, the multiple key management systems are respectively operated and maintained by different organizations, and the key management system of one organization is used for storing the private key of the user under the organization. For ease of understanding, bank a illustratively serves as an organization for the operation and maintenance of a key management system. A plurality of branches and branch lines of the bank A and financial institutions cooperating with the bank A belong to users interfacing with the bank A, and a key management system of the bank A is used for storing private keys of the users. While bank B acts as another institution for maintaining another key management system. A plurality of branches and branches of the bank B and financial institutions cooperating with the bank B belong to users docked with the bank B, and a key management system of the bank B is used for storing private keys of the users.
It should be noted that, a plurality of key management systems are established, and the plurality of key management systems are operated and maintained by different organizations respectively. And the key management system of each organization is used for storing the private key of the user under the organization. In this way, the private key of each user is securely stored in the key management system operated and maintained by the corresponding organization, but not in the key management systems operated and maintained by other organizations, so that the security of the private key can be ensured.
After the message middleware generates the contract issuing transaction, in order to submit the contract issuing transaction to the key management system for signature, the message middleware can submit the contract issuing transaction and the identity to the key management system corresponding to the identity according to the identity carried by the first service message. The key management system corresponding to the identity identification means: and the key management system is used for storing the private key corresponding to the identity.
During specific implementation, the message middleware stores the corresponding relationship between each identity and the corresponding mechanism, and the message middleware can query the corresponding mechanism according to the identity carried by the first service message, so that a contract issuing transaction and the identity are submitted to a key management system operated and maintained by the corresponding mechanism.
Alternatively, the prefix of the user identity is equal to the number of the institution to which the user is docked. The message middleware determines the corresponding mechanism according to the prefix of the identity, so that contract issuing transaction and the identity are submitted to a key management system operated and maintained by the corresponding mechanism.
Based on the same inventive concept, the embodiment of the invention also provides a device for issuing the asset contract. Referring to fig. 3, fig. 3 is a schematic diagram of an asset contract issuing apparatus according to an embodiment of the present invention, which is applied to message middleware. As shown in fig. 3, the apparatus includes:
a service message receiving module 31, configured to receive a first service message, where the first service message carries an asset type identifier and a contract parameter for establishing an asset contract;
a contract module determining module 32, configured to determine, according to the asset type identifier carried in the first service packet, a target contract module corresponding to the asset type identifier from multiple preset contract templates;
the asset contract construction module 33 is configured to construct an asset contract to be issued according to the target contract template and the contract parameters carried in the first service message;
and the contract issuing transaction generating module 34 is configured to generate a contract issuing transaction, and submit the contract issuing transaction to the blockchain network for execution, where the contract issuing transaction includes the asset contract to be issued.
Optionally, in some specific embodiments, the first service packet further carries a constraint file ID, and the contract issuance transaction inherits the constraint file ID.
Optionally, in some embodiments, the asset contract to be issued includes one or more contract methods.
Optionally, in some specific embodiments, the service packet receiving module is further configured to receive a second service packet, where the second service packet carries a constraint file to be deployed;
the device further comprises:
the constraint file ID generation module is used for generating a constraint file ID for the constraint file to be deployed;
and the constraint file deployment transaction generating module is used for generating a constraint file deployment transaction according to the second service message, submitting the constraint file deployment transaction to the blockchain network for execution, wherein the constraint file deployment transaction comprises the constraint file to be deployed, and the constraint file deployment transaction also carries the constraint file ID of the constraint file to be deployed.
Optionally, in some embodiments, the apparatus further comprises:
an execution result obtaining module, configured to obtain an execution result of the constrained file deployment transaction by the blockchain network;
and the information sending module is used for sending the constrained file ID generated by the constrained file ID generating module to a target user side under the condition that the execution result represents that the block chain network has successfully executed the constrained file deployment transaction.
Optionally, in some specific embodiments, the first service packet further carries an identity of a user initiating the first service packet; the device further comprises:
the contract issuing transaction generation module is used for generating a contract issuing transaction according to the identity, submitting the contract issuing transaction and the identity to a block chain network for execution, and generating a contract issuing transaction according to the contract issuing transaction; the key management system is also used for receiving the signed contract issuing transaction returned by the key management system;
optionally, in some specific embodiments, the number of the key management systems is multiple, the multiple key management systems are respectively operated and maintained by different organizations, and the key management system of one organization is used for storing a private key of a user under the organization;
the transaction signature module is specifically used for submitting the contract issuing transaction and the identity to a key management system corresponding to the identity according to the identity; the key management system corresponding to the identity refers to: and the key management system is used for storing the private key corresponding to the identity.
For the device 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. 4, including a processor 401, a communication interface 402, a memory 403, and a communication bus 404, where the processor 401, the communication interface 402, and the memory 403 complete communication with each other through the communication bus 404.
The memory 403 is used for storing computer programs;
the processor 401 is configured to implement the following steps when executing the program stored in the memory 403:
the message middleware receives a first service message, wherein the first service message carries an asset type identifier and contract parameters for constructing an asset contract;
the message middleware determines a target contract module corresponding to the asset type identifier from a plurality of preset contract templates according to the asset type identifier carried by the first service message;
the message middleware constructs an asset contract to be issued according to the target contract template and contract parameters carried by the first service message;
and the message middleware generates a contract issuing transaction and submits the contract issuing transaction to a block chain network for execution, wherein the contract issuing transaction comprises the asset contract to be issued.
Alternatively, processor 401 may be configured to perform the method steps of issuing asset contracts provided by other method embodiments of the present invention above, when executing a program stored in memory 403.
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. Alternatively, the memory may be at least one memory device located remotely from the processor.
The Processor may be a general-purpose Processor, including 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 yet another embodiment of the present invention, there is also provided a computer-readable storage medium having stored therein instructions, which when run on a computer, cause the computer to perform the method of issuing an asset contract as 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 phrases "comprising a," "8230," "8230," or "comprising" does not exclude the presence of additional like 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 (9)
1. A method of issuing an asset contract, the method comprising:
the message middleware receives a first service message, wherein the first service message carries an asset type identifier and contract parameters for constructing an asset contract, and the first service message also carries a constraint file ID;
the message middleware determines a target contract template corresponding to the asset type identifier from a plurality of preset contract templates according to the asset type identifier carried by the first service message;
the message middleware constructs an asset contract to be issued according to the target contract template and contract parameters carried by the first service message;
the message middleware generates contract issuing transaction, and submits the contract issuing transaction to a block chain network for execution, wherein the contract issuing transaction comprises the asset contract to be issued, and the contract issuing transaction inherits the ID of the constraint file; when executing the contract issuance transaction, the node of the blockchain network includes: the node takes a constraint file ID carried by the contract issuing transaction as an index, and inquires a target constraint file corresponding to the constraint file ID from an account book database; the node judges whether the contract issuing transaction meets the execution condition limited by the target constraint file or not according to the target constraint file; in the event that the contract issuance deal does not satisfy the execution condition, the node does not execute the contract issuance deal.
2. The method of claim 1, wherein the asset contract to be issued comprises one or more contract methods; one or more key contract methods and sub-execution conditions corresponding to each key contract method are recorded in the target constraint file; when executing the contract issuance transaction, the node of the blockchain network further includes:
under the condition that the contract issuing transaction meets the execution condition, the node judges whether all key contract methods recorded in the target constraint file are contained in the asset contract to be issued or not;
if yes, the node executes the contract issuing transaction;
if not, the node does not execute the contract issuing transaction.
3. The method according to any one of claims 1 or 2, further comprising:
the message middleware receives a second service message, wherein the second service message carries a constraint file to be deployed;
the message middleware generates a constraint file ID for the constraint file to be deployed;
and the message middleware generates a constraint file deployment transaction according to the second service message, submits the constraint file deployment transaction to the blockchain network for execution, wherein the constraint file deployment transaction comprises the constraint file to be deployed, and also carries the constraint file ID of the constraint file to be deployed.
4. The method of claim 3, further comprising:
the message middleware obtains the execution result of the block chain network on the constrained file deployment transaction;
and under the condition that the execution result represents that the block chain network has successfully executed the constraint file deployment transaction, the message middleware sends the generated constraint file ID to a target user side.
5. The method according to claim 1, wherein the first service packet further carries an identity of a user originating the first service packet; before the message middleware submits the contract issue transaction to a blockchain network for execution, the method further comprises the following steps:
the message middleware submits the contract issuing transaction and the identity to a key management system, so that the key management system inquires a corresponding private key according to the identity and signs the contract issuing transaction by using the inquired private key; the message middleware receives the signed contract issuing transaction returned by the key management system;
the message middleware submits the contract issuing transaction to a block chain network for execution, and the method comprises the following steps:
and the message middleware submits the signed contract issuing transaction to a block chain network for execution.
6. The method according to claim 5, wherein the number of the key management systems is plural, a plurality of key management systems are respectively maintained by different organizations, and the key management system of one organization is used for storing the private key of the user under the organization; the message middleware submits the contract issuing transaction and the identity to a key management system, and the method comprises the following steps:
the message middleware submits the contract issuing transaction and the identity to a key management system corresponding to the identity according to the identity; the key management system corresponding to the identity refers to: and the key management system is used for storing the private key corresponding to the identity.
7. An apparatus for issuing an asset contract, applied to message middleware, the apparatus comprising:
a service message receiving module, configured to receive a first service message, where the first service message carries an asset type identifier and a contract parameter for establishing an asset contract, and the first service message also carries a constraint file ID;
a contract module determining module, configured to determine, according to the asset type identifier carried in the first service packet, a target contract template corresponding to the asset type identifier from multiple preset contract templates;
the asset contract construction module is used for constructing an asset contract to be issued according to the target contract template and contract parameters carried by the first service message;
the contract issuing transaction generating module is used for generating a contract issuing transaction and submitting the contract issuing transaction to a block chain network for execution, the contract issuing transaction comprises the asset contract to be issued, and the contract issuing transaction inherits the ID of the constraint file; when executing the contract issuance transaction, the node of the blockchain network includes: the node takes a constraint file ID carried by the contract issuing transaction as an index, and inquires a target constraint file corresponding to the constraint file ID from an account book database; the node judges whether the contract issuing transaction meets the execution condition defined by the target constraint file or not according to the target constraint file; in the event that the contract issuance transaction does not satisfy the execution condition, the node does not execute the contract issuance transaction.
8. The electronic equipment 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 the communication between the processor and 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 configured to perform the method steps of claim 1 or to perform the method steps of any of claims 3 to 6.
9. 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 claim 1 or carries out the method steps of any one of claims 3 to 6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011507358.5A CN112714157B (en) | 2020-12-18 | 2020-12-18 | Asset contract issuing method and device, electronic equipment and readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011507358.5A CN112714157B (en) | 2020-12-18 | 2020-12-18 | Asset contract issuing method and device, electronic equipment and readable storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112714157A CN112714157A (en) | 2021-04-27 |
| CN112714157B true CN112714157B (en) | 2022-11-11 |
Family
ID=75544578
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011507358.5A Active CN112714157B (en) | 2020-12-18 | 2020-12-18 | Asset contract issuing method and device, electronic equipment and readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112714157B (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110046522A (en) * | 2018-11-28 | 2019-07-23 | 阿里巴巴集团控股有限公司 | Method for processing business and device, electronic equipment based on block chain |
| CN111445244A (en) * | 2020-03-24 | 2020-07-24 | 安徽高山科技有限公司 | Intelligent contract management system for block chain |
| CN111565173A (en) * | 2020-04-12 | 2020-08-21 | 链农(深圳)信息科技有限公司 | Intelligent contract management method and device for block chain system and hardware equipment |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108805707A (en) * | 2018-05-21 | 2018-11-13 | 阿里巴巴集团控股有限公司 | Works copyright revenue distribution method and device based on block chain |
| JP7090903B2 (en) * | 2018-11-09 | 2022-06-27 | 国立大学法人東北大学 | Information processing system, data provision method, and manufacturing method of information processing system |
-
2020
- 2020-12-18 CN CN202011507358.5A patent/CN112714157B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110046522A (en) * | 2018-11-28 | 2019-07-23 | 阿里巴巴集团控股有限公司 | Method for processing business and device, electronic equipment based on block chain |
| CN111445244A (en) * | 2020-03-24 | 2020-07-24 | 安徽高山科技有限公司 | Intelligent contract management system for block chain |
| CN111565173A (en) * | 2020-04-12 | 2020-08-21 | 链农(深圳)信息科技有限公司 | Intelligent contract management method and device for block chain system and hardware equipment |
Non-Patent Citations (1)
| Title |
|---|
| 基于区块链的去中心化物品共享交易服务系统;范吉立等;《计算机应用》;20190131(第05期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112714157A (en) | 2021-04-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20200320514A1 (en) | Digital Contracts in Blockchain Environments | |
| CN108416577B (en) | Block chain service system | |
| Zhang et al. | Towards Dependable, Scalable, and Pervasive Distributed Ledgers with Blockchains. | |
| US20210051027A1 (en) | User identity information authentication and verification methods and devices | |
| TW202101440A (en) | Cross-blockchain resource transmission | |
| CN111066047B (en) | Implementing blockchain-based workflows | |
| US11870847B2 (en) | Decentralized data flow valuation and deployment | |
| US20160342977A1 (en) | Device, method and system for virtual asset transactions | |
| US9020949B2 (en) | Method and system for centralized issue tracking | |
| US11397919B1 (en) | Electronic agreement data management architecture with blockchain distributed ledger | |
| CN114445010B (en) | Block chain-based multi-mode intermodal system and method | |
| Pasdar et al. | Blockchain oracle design patterns | |
| JP2022553674A (en) | Chaincode recommendations based on existing chaincodes | |
| CN111538757B (en) | Data storage method, query method, device, server and medium | |
| CN110471982B (en) | Data processing method and device based on block chain | |
| CN112035542B (en) | Information query method, device, electronic equipment and readable storage medium | |
| US12086272B2 (en) | Systems and methods for conducting blockchain actions based on network mappings of self-executing program characteristics | |
| JP2023535605A (en) | E-wallets that allow expiry of cryptocurrencies | |
| CN110955724A (en) | Data processing method and device based on block chain, node equipment and storage medium | |
| CN112488835A (en) | Service processing method, electronic device and readable storage medium | |
| CN113706313A (en) | Financing method, system and computer readable storage medium based on block chain | |
| CN115994771A (en) | Real-time acquisition and tracing method and system for commodity transaction evidence-preserving data | |
| CN112671842B (en) | Information transmission method and device, electronic equipment and readable storage medium | |
| CN112269915B (en) | Service processing method, device, equipment and storage medium | |
| CN111563083B (en) | Report data query method, device and system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |