WO2021143027A1 - 交易背书处理方法、服务器及计算机可读存储介质 - Google Patents

交易背书处理方法、服务器及计算机可读存储介质 Download PDF

Info

Publication number
WO2021143027A1
WO2021143027A1 PCT/CN2020/093602 CN2020093602W WO2021143027A1 WO 2021143027 A1 WO2021143027 A1 WO 2021143027A1 CN 2020093602 W CN2020093602 W CN 2020093602W WO 2021143027 A1 WO2021143027 A1 WO 2021143027A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
endorsement
original
server
request
Prior art date
Application number
PCT/CN2020/093602
Other languages
English (en)
French (fr)
Inventor
陆陈一帆
陈沐豪
冯世伟
褚镇飞
Original Assignee
平安科技（深圳）有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 平安科技（深圳）有限公司 filed Critical 平安科技（深圳）有限公司
Publication of WO2021143027A1 publication Critical patent/WO2021143027A1/zh

Links

Classifications

    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic 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

Definitions

  • This application relates to the field of blockchain technology, and in particular to a transaction endorsement processing method, server, and computer-readable storage medium.
  • BFT Byzantine Fault Tolerance
  • Hyperledger 1.0 a simple and practical BFT model-digital signature endorsement mechanism has been introduced.
  • the principle of this mechanism is to verify and digitally sign transaction requests through a single or multiple third-party agencies. If a transaction request obtains enough digital signatures, it can be judged as legitimate. The number of digital signatures required to ensure the legitimacy of the transaction depends on the preset "transaction endorsement strategy". The inventor realizes that each transaction initiator needs to send the transaction to the single or multiple third-party institutions to verify and digitally sign the transaction, which itself requires mutual trust and the opening of a firewall.
  • this application proposes a transaction endorsement processing method, a server, and a computer-readable storage medium to solve at least one of the above technical problems.
  • this application proposes a transaction endorsement processing method, which is applied to a server, and the server is connected to all data nodes in the blockchain.
  • the method includes the steps:
  • the present application also provides a server that connects to all data nodes in the blockchain.
  • the server includes a memory and a processor, and the memory is stored on the processor.
  • a running transaction endorsement processing system when the transaction endorsement processing system is executed by the processor, the following steps are implemented:
  • the present application also provides a computer-readable storage medium, the computer-readable storage medium stores computer-readable instructions, and the computer-readable instructions can be executed by at least one processor to achieve the following step:
  • this application also provides a transaction endorsement processing system, which includes:
  • the receiving module is configured to: receive the original transaction request sent by the transaction initiator, the original transaction request containing transaction information;
  • the query module is used to query the transaction endorsement strategy corresponding to the original transaction request
  • the determining module is configured to determine the endorsement node matching the original transaction request according to the transaction endorsement strategy
  • a sending module configured to: send the original transaction request to the determined endorsing node for transaction endorsement;
  • the generating module is used to: receive the transaction results and digital signatures fed back by all the endorsing nodes, package the original transaction request and the transaction results and digital signatures fed back by all the endorsing nodes, generate a complete transaction request, and transfer all The complete transaction request is broadcast to the data node on the blockchain.
  • the transaction endorsement processing method, server, and computer-readable storage medium proposed in this application by establishing a server in the cloud to connect to all the data nodes of the blockchain, the transaction initiator can use the server When docked with other data nodes, each data node can also dock with other data nodes and transaction initiators through the server.
  • the server When any institution (data node) transmits information through the server, the server will judge and transmit the transaction information to the recipient through business logic (for example, transaction endorsement strategy). All data nodes and transaction initiators only need to dock with the server to achieve the effect of docking with all third-party data nodes and transaction devices, avoiding the problem of successful transaction endorsement because the data nodes cannot open the firewall to each other.
  • the usability of the BFT consensus algorithm is enhanced, and the processing efficiency and user experience of blockchain transactions are improved.
  • FIG. 1 is a schematic diagram of an optional application environment architecture of each embodiment of the present application.
  • FIG. 2 is a schematic diagram of an optional hardware architecture of the server in FIG. 1;
  • FIG. 3 is a schematic diagram of program modules of the first embodiment of the transaction endorsement processing system of the present application.
  • FIG. 4 is a schematic diagram of program modules of the second embodiment of the transaction endorsement processing system of the present application.
  • FIG. 5 is a schematic flowchart of the first embodiment of the transaction endorsement processing method of this application.
  • FIG. 6 is a schematic flowchart of a second embodiment of the transaction endorsement processing method of the present application.
  • FIG. 1 is a schematic diagram of an optional application environment architecture of each embodiment of the present application.
  • the application can be applied to a blockchain network, and the blockchain includes at least a server 2 and a plurality of data nodes 4.
  • the server 2 may be a computing device such as a rack server, a blade server, a tower server, or a cabinet server.
  • the server 2 may be an independent server or a server cluster composed of multiple servers.
  • the data node 4 can be a mobile phone, a smart phone, a notebook computer, a digital broadcast receiver, a PDA (personal digital assistant), a pad (tablet computer), a PMP (portable multimedia player), a navigation device, a vehicle-mounted device, etc.
  • Devices, and fixed terminals such as digital TVs, desktop computers, notebooks, servers, etc., can also be servers.
  • a server 2 is added to the existing blockchain architecture.
  • the server 2 is a BFT server established in the cloud, which is connected to all the data nodes 4 in the blockchain (including transaction initiation Parties, transaction recipients, endorsing nodes, etc.).
  • the data node 4 When the data node 4 is located in the institution where the transaction participant (transaction initiator, transaction receiver) is located, it also includes the transaction device 6 corresponding to the data node 4 (or the institution). Transaction initiators, transaction recipients, endorsing nodes and other data nodes can all be connected through the server 2. All data nodes 4 only need to be connected to the server 2 to reach all third-party data nodes 4 and transaction devices 6. The effect of docking.
  • FIG. 2 is a schematic diagram of an optional hardware architecture of the server 2 of the present application.
  • the server 2 may include, but is not limited to, a memory 11, a processor 12, and a network interface 13 that can communicate with each other through a system bus. It should be pointed out that FIG. 2 only shows the server 2 with components 11-13, but it should be understood that it is not required to implement all the components shown, and more or fewer components may be implemented instead.
  • the server 2 may be a computing device such as a rack server, a blade server, a tower server, or a cabinet server.
  • the server 2 may be an independent server or a server cluster composed of multiple servers.
  • the memory 11 includes at least one type of readable storage medium, the readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (for example, SD or DX memory, etc.), random access memory (RAM), static Random access memory (SRAM), read only memory (ROM), electrically erasable programmable read only memory (EEPROM), programmable read only memory (PROM), magnetic memory, magnetic disks, optical disks, etc.
  • the storage 11 may be an internal storage unit of the server 2, for example, a hard disk or a memory of the server 2.
  • the memory 11 may also be an external storage device of the server 2, for example, a plug-in hard disk, a smart memory card (Smart Media Card, SMC), and a secure digital (Secure Digital) equipped on the server 2. Digital, SD) card, flash memory card (Flash Card) and so on.
  • the memory 11 may also include both the internal storage unit of the server 2 and its external storage device.
  • the memory 11 is generally used to store the operating system and various application software installed in the server 2, for example, the program code of the transaction endorsement processing system 200 and so on.
  • the memory 11 can also be used to temporarily store various types of data that have been output or will be output.
  • the readable storage medium may be non-volatile or volatile.
  • the processor 12 may be a central processing unit (Central Processing Unit) in some embodiments. Processing Unit, CPU), controller, microcontroller, microprocessor, or other data processing chip.
  • the processor 12 is generally used to control the overall operation of the server 2.
  • the processor 12 is used to run the program code or processing data stored in the memory 11, for example, to run the transaction endorsement processing system 200.
  • the network interface 13 may include a wireless network interface or a wired network interface, and the network interface 13 is usually used to establish a communication connection between the server 2 and other electronic devices.
  • this application proposes a transaction endorsement processing system 200.
  • FIG. 3 is a program module diagram of the first embodiment of the transaction endorsement processing system 200 of the present application.
  • the transaction endorsement processing system 200 includes a series of computer program instructions stored on the memory 11. When the computer program instructions are executed by the processor 12, the transaction endorsement processing operations of the various embodiments of the present application can be implemented. . In some embodiments, the transaction endorsement processing system 200 may be divided into one or more modules based on specific operations implemented by various parts of the computer program instructions. For example, in FIG. 3, the transaction endorsement processing system 200 can be divided into a receiving module 201, a query module 202, a determining module 203, a sending module 204, and a generating module 205. in:
  • the receiving module 201 is used to receive the original transaction request sent by the transaction initiator.
  • the server 2 is docked with all transaction initiators, and the transaction initiator sends an original transaction request to the server 2 through its own transaction device 6 and can connect to other data nodes 4 through the server 2.
  • the original transaction request only includes transaction information, and there is no transaction result or a digital signature endorsing the transaction result.
  • the transaction information is transaction request parameters, including transaction type, transaction parties, transaction amount, etc. For example, if a transaction is 100 yuan transferred from institution A to institution B, the transaction request parameter (transaction information) in the original transaction request is "transaction type: transfer; transaction parties: A, B; transaction amount: 100".
  • the query module 202 is used to query the transaction endorsement strategy corresponding to the original transaction request.
  • the server 2 stores a set of transaction endorsement strategies formulated when the blockchain system is built, and updates them in real time when the transaction endorsement strategies are changed.
  • the transaction endorsement strategy is used to guide the endorsing node to perform correct endorsement, and the endorsement node determines whether a transaction is correctly endorsed through the transaction endorsement strategy.
  • the transaction endorsement strategy specifies how many third-party data nodes 4 (endorsing nodes) or specific third-party data nodes 4 are required for the original transaction request to endorse the transaction result.
  • the query module 202 After receiving the original transaction request from the transaction initiator, the query module 202 queries the transaction endorsement strategy corresponding to the original transaction request from a set of stored transaction endorsement strategies.
  • the query can be performed according to the transaction type or the transaction initiator, and other methods commonly used in the art can also be flexibly configured to determine the correspondence between the original transaction request and the transaction endorsement strategy, which is not limited in this embodiment.
  • the determining module 203 is configured to determine an endorsement node matching the original transaction request according to the transaction endorsement strategy.
  • the server 2 is connected to all data nodes 4 in the blockchain, and each data node 4 can be connected to other data nodes 4 and the transaction initiator through the server 2.
  • the server 2 stores the identity information of all the data nodes 4 connected to it, including digital certificates, IP addresses, names, and so on.
  • the determination module 203 determines the original transaction request according to the endorsement node information in the transaction endorsement strategy and the stored identity information of all data nodes 4 The matching endorsement node.
  • the transaction endorsement strategy specifies which third-party data nodes 4 (endorsing nodes) are specifically required to endorse the transaction result
  • the determination module 203 directly finds these endorsing nodes through the stored identity information of all the data nodes 4.
  • the transaction endorsement strategy only specifies how many endorsement nodes are required for the original transaction request or the requirements for endorsement nodes, the determination module 203 randomly selects all data nodes 4 according to the transaction endorsement strategy or according to preset rules. Select the endorsement node that meets the requirements. For example, according to the transaction endorsement strategy, it is determined that the original transaction request needs to be endorsed by the endorsing nodes C, D, and E.
  • the sending module 204 is configured to send the original transaction request to the determined endorsing node for transaction endorsement.
  • the sending module 204 sends the received original transaction request to the endorsing node, so that the endorsing nodes can respectively Simulate the transaction and verify that it is legal. For example, the sending module 204 sends the original transaction request to the endorsing nodes C, D, and E, and the endorsing nodes C, D, and E respectively endorse the transaction locally.
  • the receiving module 201 is also used to receive the transaction result and digital signature fed back by the endorsing node.
  • the receiving module 201 receives transaction results and digital signatures from each of the endorsing nodes. For example, after the endorsing nodes C, D, and E respectively complete transaction calculation and verification locally and digitally sign the transaction result, the transaction result and digital signature are fed back to the server 2, and the receiving module 201 receives the endorsing node C , D, E feedback of all transaction results and digital signatures.
  • the generating module 205 is used to package the original transaction request and the transaction result and digital signature to generate a complete transaction request.
  • the generating module 205 sends the original transaction request and all the transaction results corresponding to the original transaction request It is packaged with the digital signature and signed with its own secret key to generate a complete transaction request.
  • the generating module 205 packages and signs the original transaction request and all transaction results and digital signatures fed back by the endorsing nodes C, D, and E to generate the complete transaction request.
  • the sending module 204 is also used to broadcast the complete transaction request to the data node 4 on the blockchain.
  • the sending module 204 broadcasts the generated complete transaction request to the data node 4 on the blockchain, thereby completing the process of endorsing the transaction.
  • the transaction initiator can connect to other data nodes 4 through the server 2, and each data node 4 also The server 2 can be used to interface with other data nodes 4 and transaction initiators.
  • the server 2 judges and transmits the transaction information to the recipient through business logic (for example, a transaction endorsement strategy).
  • All data nodes 4 and transaction initiators only need to connect with the server 2 to achieve the effect of connecting with all third-party data nodes 4 and transaction devices 6, avoiding the failure to successfully proceed because the data nodes 4 cannot open the firewall to each other
  • the issue of transaction endorsement enhances the usability of the BFT consensus algorithm and improves the processing efficiency and user experience of blockchain transactions.
  • the transaction endorsement processing system 200 includes a judgment module 206 in addition to the receiving module 201, query module 202, determining module 203, sending module 204, and generating module 205 in the first embodiment. .
  • the judgment module 206 is configured to judge whether the transaction initiator authorizes the server 2 to send the transaction as an agent after the receiving module 201 receives the transaction result and the digital signature fed back by the endorsing node.
  • the transaction initiator can choose whether to authorize the server 2 to send the transaction as an agent, that is, choose to initiate the complete transaction request by itself, or the server 2 to initiate the complete transaction request as an agent.
  • an authorization instruction may be sent to the server 2, or authorization may be attached to the original transaction request, or other methods commonly used in the art may be used for authorization.
  • the server 2 judges whether it is the transaction initiator sending the transaction as an agent of the transaction initiator according to whether the authorization of the transaction initiator is received (whether the authorization instruction is received, or whether authorization information is attached to the original transaction request).
  • the proxy transaction sending mode If the authorization of the transaction initiator is received, it is the proxy transaction sending mode; if the authorization of the transaction initiator is not received, it is the non-agent transaction sending mode.
  • the processing procedure of the first embodiment is adopted, and the original transaction request and the transaction result and digital signature are packaged by the generating module 205 to generate a complete transaction request, and then the sending module 204 broadcasts the complete transaction request to the data node 4 on the blockchain.
  • the non-agent transaction sending mode the following processing procedure of this embodiment is adopted.
  • the sending module 204 is also configured to send the transaction result and digital signature to the transaction initiator when the transaction initiator does not authorize the server 2 to send the transaction as an agent.
  • the sending module 204 will The transaction result and the digital signature are sent to the transaction initiator.
  • the receiving module 201 is also used to receive a complete transaction request packaged and generated by the transaction initiator.
  • the transaction initiator receives the transaction results and digital signatures fed back by all endorsing nodes sent by the sending module 204
  • its corresponding transaction device 6 will process the original transaction request and all transactions related to the original transaction request.
  • the transaction result and the digital signature corresponding to the transaction request are packaged, and a complete transaction request is generated after signing with its own secret key, and then the complete transaction request is sent to the server 2 again.
  • the sending module 204 broadcasts the complete transaction request to the data node 4 on the blockchain.
  • the transaction initiator can choose whether to authorize the server 2 to send the transaction as an agent, and the server 2 can flexibly adopt different methods to generate a complete transaction request according to whether the transaction initiator is authorized or not. Then broadcast to other data nodes 4 to further enhance the usability of the BFT consensus algorithm and improve user experience.
  • this application also proposes a transaction endorsement processing method.
  • FIG. 5 is a schematic flowchart of the first embodiment of the transaction endorsement processing method of the present application.
  • the execution order of the steps in the flowchart shown in FIG. 5 can be changed, and some steps can be omitted.
  • the method includes the following steps:
  • Step S400 receiving the original transaction request sent by the transaction initiator.
  • the server 2 is docked with all transaction initiators, and the transaction initiator sends an original transaction request to the server 2 through its own transaction device 6 and can connect to other data nodes 4 through the server 2.
  • the original transaction request only includes transaction information, and there is no transaction result or a digital signature endorsing the transaction result.
  • the transaction information is transaction request parameters, including transaction type, transaction parties, transaction amount, etc. For example, if a transaction is 100 yuan transferred from institution A to institution B, the transaction request parameter (transaction information) in the original transaction request is "transaction type: transfer; transaction parties: A, B; transaction amount: 100".
  • Step S402 query the transaction endorsement strategy corresponding to the original transaction request.
  • the server 2 stores a set of transaction endorsement strategies formulated when the blockchain system is built, and updates them in real time when the transaction endorsement strategies are changed.
  • the transaction endorsement strategy is used to guide the endorsing node to perform correct endorsement, and the endorsement node determines whether a transaction is correctly endorsed through the transaction endorsement strategy.
  • the transaction endorsement strategy specifies how many third-party data nodes 4 (endorsing nodes) or specific third-party data nodes 4 are required for the original transaction request to endorse the transaction result.
  • the server 2 After receiving the original transaction request from the transaction initiator, the server 2 queries the transaction endorsement strategy corresponding to the original transaction request from a set of stored transaction endorsement strategies. Wherein, the query can be performed according to the transaction type or the transaction initiator, and other methods commonly used in the art can also be flexibly configured to determine the correspondence between the original transaction request and the transaction endorsement strategy, which is not limited in this embodiment.
  • Step S404 Determine an endorsement node matching the original transaction request according to the transaction endorsement strategy.
  • the server 2 is connected to all data nodes 4 in the blockchain, and each data node 4 can be connected to other data nodes 4 and the transaction initiator through the server 2.
  • the server 2 stores the identity information of all the data nodes 4 connected to it, including digital certificates, IP addresses, names, and so on.
  • the server 2 determines that the original transaction request matches according to the endorsement node information in the transaction endorsement strategy and the stored identity information of all data nodes 4 Endorsement node.
  • the server 2 directly finds these endorsing nodes through the stored identity information of all the data nodes 4.
  • the server 2 selects from all data nodes 4 randomly or according to preset rules according to the transaction endorsement strategy Produce endorsement nodes that meet the requirements. For example, according to the transaction endorsement strategy, it is determined that the original transaction request needs to be endorsed by the endorsing nodes C, D, and E.
  • Step S406 Send the original transaction request to the determined endorsement node for transaction endorsement.
  • the server 2 After the server 2 determines the endorsement node matching the original transaction request, it sends the received original transaction request to the endorsement node, so that the endorsement node simulates the transaction and verifies whether legitimate. For example, the server 2 sends the original transaction request to the endorsing nodes C, D, and E, and the endorsing nodes C, D, and E respectively endorse the transaction locally.
  • Step S408 receiving the transaction result and digital signature fed back by the endorsing node.
  • the transaction result and digital signature are fed back to the server 2.
  • the server 2 receives transaction results and digital signatures from each of the endorsing nodes. For example, after the endorsing nodes C, D, and E respectively complete the transaction calculation and verification locally and digitally sign the transaction results, the transaction results and digital signatures are fed back to the server 2, and the server 2 receives the endorsing nodes C, D and E feedback of all transaction results and digital signatures.
  • Step S410 package the original transaction request and the transaction result and digital signature to generate a complete transaction request.
  • the server 2 After the server 2 receives the transaction results and digital signatures fed back by all endorsing nodes, it packs the original transaction request and all the transaction results and digital signatures corresponding to the original transaction request, And generate a complete transaction request after signing with its own secret key. For example, the server 2 packages and signs the original transaction request and all transaction results and digital signatures fed back by the endorsing nodes C, D, and E to generate the complete transaction request.
  • Step S412 Broadcast the complete transaction request to the data node 4 on the blockchain.
  • the server 2 broadcasts the generated complete transaction request to the data node 4 on the blockchain, thereby completing the process of endorsing the transaction.
  • the transaction initiator can connect to other data nodes 4 through the server 2, and each data node 4 also The server 2 can be used to interface with other data nodes 4 and transaction initiators.
  • the server 2 judges and transmits the transaction information to the recipient through business logic (for example, a transaction endorsement strategy).
  • All data nodes 4 and transaction initiators only need to connect with the server 2 to achieve the effect of connecting with all third-party data nodes 4 and transaction devices 6, avoiding the failure to successfully proceed because the data nodes 4 cannot open the firewall to each other
  • the issue of transaction endorsement enhances the usability of the BFT consensus algorithm and improves the processing efficiency and user experience of blockchain transactions.
  • FIG. 6 it is a schematic flowchart of the second embodiment of the transaction endorsement processing method of the present application.
  • the steps S500-S508 and S516-S518 of the transaction endorsement processing method are similar to the steps S400-S412 of the first embodiment, except that the method further includes steps S510-S514.
  • the method includes the following steps:
  • Step S500 receiving the original transaction request sent by the transaction initiator.
  • the server 2 is docked with all transaction initiators, and the transaction initiator sends an original transaction request to the server 2 through its own transaction device 6 and can connect to other data nodes 4 through the server 2.
  • the original transaction request only includes transaction information, and there is no transaction result or a digital signature endorsing the transaction result.
  • the transaction information is transaction request parameters, including transaction type, transaction parties, transaction amount, etc. For example, if a transaction is 100 yuan transferred from institution A to institution B, the transaction request parameter (transaction information) in the original transaction request is "transaction type: transfer; transaction parties: A, B; transaction amount: 100".
  • Step S502 query the transaction endorsement strategy corresponding to the original transaction request.
  • the server 2 stores a set of transaction endorsement strategies formulated when the blockchain system is built, and updates them in real time when the transaction endorsement strategies are changed.
  • the transaction endorsement strategy is used to guide the endorsing node to perform correct endorsement, and the endorsement node determines whether a transaction is correctly endorsed through the transaction endorsement strategy.
  • the transaction endorsement strategy specifies how many third-party data nodes 4 (endorsing nodes) or specific third-party data nodes 4 are required for the original transaction request to endorse the transaction result.
  • the server 2 After receiving the original transaction request from the transaction initiator, the server 2 queries the transaction endorsement strategy corresponding to the original transaction request from a set of stored transaction endorsement strategies. Wherein, the query can be performed according to the transaction type or the transaction initiator, and other methods commonly used in the art can also be flexibly configured to determine the correspondence between the original transaction request and the transaction endorsement strategy, which is not limited in this embodiment.
  • Step S504 Determine an endorsement node matching the original transaction request according to the transaction endorsement strategy.
  • the server 2 is connected to all data nodes 4 in the blockchain, and each data node 4 can be connected to other data nodes 4 and the transaction initiator through the server 2.
  • the server 2 stores the identity information of all the data nodes 4 connected to it, including digital certificates, IP addresses, names, and so on.
  • the server 2 determines that the original transaction request matches according to the endorsement node information in the transaction endorsement strategy and the stored identity information of all data nodes 4 Endorsement node.
  • the server 2 directly finds these endorsing nodes through the stored identity information of all the data nodes 4.
  • the server 2 selects from all data nodes 4 randomly or according to preset rules according to the transaction endorsement strategy Produce endorsement nodes that meet the requirements. For example, according to the transaction endorsement strategy, it is determined that the original transaction request needs to be endorsed by the endorsing nodes C, D, and E.
  • Step S506 Send the original transaction request to the determined endorsement node for transaction endorsement.
  • the server 2 After the server 2 determines the endorsement node that matches the original transaction request, it sends the received original transaction request to the endorsement node, so that the endorsement node can simulate the transaction and verify whether legitimate. For example, the server 2 sends the original transaction request to the endorsing nodes C, D, and E, and the endorsing nodes C, D, and E respectively endorse the transaction locally.
  • Step S508 receiving the transaction result and digital signature fed back by the endorsing node.
  • the transaction result and digital signature are fed back to the server 2.
  • the server 2 receives transaction results and digital signatures from each of the endorsement nodes. For example, after the endorsing nodes C, D, and E respectively complete transaction calculation and verification locally and digitally sign the transaction result, the transaction result and digital signature are fed back to the server 2, and the server 2 receives the endorsing node C, D and E feedback of all transaction results and digital signatures.
  • Step S510 It is judged whether the transaction initiator authorizes the server 2 to send the transaction as an agent. If it is (agent transaction sending mode), execute step S516; if not (non-agent transaction sending mode), execute step S512.
  • the transaction initiator can choose whether to authorize the server 2 to send the transaction as an agent, that is, choose to initiate the complete transaction request by itself, or the server 2 to initiate the complete transaction request as an agent.
  • an authorization instruction may be sent to the server, or authorization may be attached to the original transaction request, or other methods commonly used in the art may be used for authorization.
  • the server 2 judges whether it is the transaction initiator sending the transaction as an agent of the transaction initiator according to whether the authorization of the transaction initiator is received (whether the authorization instruction is received, or whether authorization information is attached to the original transaction request).
  • the server 2 receives the authorization of the transaction initiator, it is the proxy transaction sending mode; if it does not receive the authorization of the transaction initiator, it is the non-agent transaction sending mode.
  • the proxy transaction sending mode the following steps S516-S518 are used; when it is the non-agent transaction sending mode, the following steps S512-S514 and S518 are used.
  • Step S512 Send the transaction result and digital signature to the transaction initiator.
  • the server 2 will send the transaction result and digital signature after receiving the transaction result and digital signature fed back by all endorsing nodes. Sent to the transaction initiator.
  • Step S514 Receive a complete transaction request packaged and generated by the transaction initiator.
  • the transaction initiator receives the transaction results and digital signatures fed back by all endorsing nodes sent by the server 2, its corresponding transaction device 6 will process the original transaction request and all transactions related to the original transaction request.
  • the corresponding transaction result and digital signature are requested to be packaged, and a complete transaction request is generated after signing with its own secret key, and then the complete transaction request is sent to the server 2 again.
  • Step S516 package the original transaction request and the transaction result and digital signature to generate a complete transaction request.
  • the server 2 packs the original transaction request and all the transaction results and digital signatures corresponding to the original transaction request, and uses A complete transaction request is generated after signing with its own secret key. For example, the server 2 packages and signs the original transaction request and all transaction results and digital signatures fed back by the endorsing nodes C, D, and E to generate the complete transaction request.
  • Step S518 Broadcast the complete transaction request to the data node 4 on the blockchain.
  • the server 2 broadcasts the complete transaction request (proxy transaction sending mode) generated by itself or the complete transaction request (non-proxy transaction sending mode) received from the transaction initiator to the block
  • the data node 4 on the chain thus completes the endorsement process of the transaction.
  • the transaction initiator can choose whether to authorize the server 2 to send the transaction as an agent, and the server 2 can flexibly use different methods to generate a complete transaction request according to whether the transaction initiator is authorized or not. Then broadcast to other data nodes 4 to further enhance the usability of the BFT consensus algorithm and improve user experience.
  • the present application also provides another implementation manner, that is, a computer-readable storage medium is provided with computer-readable instructions stored thereon, and the computer-readable instructions can be executed by at least one processor to The at least one processor is caused to execute the steps of the transaction endorsement processing method as described above.
  • the computer-readable storage medium may be non-volatile or volatile.
  • the technical solution of this application essentially or the part that contributes to the existing technology can be embodied in the form of a software product, and the computer software product is stored in a storage medium (such as ROM/RAM, magnetic disk, The optical disc) includes several instructions to enable a terminal device (which can be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to execute the method described in each embodiment of the present application.
  • a terminal device which can be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Theoretical Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Computer And Data Communications (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种服务器及计算机可读存储介质以及一种交易背书处理方法，应用于服务器，所述服务器对接区块链中的所有数据节点，该方法包括：接收交易发起方发送的原始交易请求（S400）；查询与所述原始交易请求对应的交易背书策略（S402）；根据所述交易背书策略确定匹配的背书节点（S404）；将原始交易请求发送至所确定的背书节点进行交易背书（S406）；接收背书节点反馈的交易结果和数字签名（S408）；打包所述原始交易请求及所有所述背书节点反馈的交易结果和数字签名，生成完整交易请求（S410）；将所述完整交易请求广播至所述区块链上的数据节点（S412）。该方法能够增强BFT共识算法的可用性，提升区块链交易的处理效率和用户体验。

Description

交易背书处理方法、服务器及计算机可读存储介质
本申请要求于2020年01月16日提交中国专利局、申请号为202010046528.8、发明名称为“交易背书处理方法、服务器及计算机可读存储介质”的中国专利申请的优先权，其全部内容通过引用结合在申请中。
技术领域
本申请涉及区块链技术领域，尤其涉及一种交易背书处理方法、服务器及计算机可读存储介质。
 背景技术
联盟链的拜占庭容错共识算法（Byzantine Fault Tolerance，BFT）难以在公共业界使用有多个原因，其中一点是因为数据节点之间无法互相打开防火墙，以供共识算法参与方来进行检测。
从超级账本（Hyperledger）1.0以后，推出了一种简单实用的BFT模式-数字签名背书机制。该机制的原理是通过单个或多个第三方机构对交易请求进行检验和数字签名，如果一个交易请求获得足够的数字签名即可被判定为合法。而需要多少数字签名来保证交易合法性取决于预先设定的“交易背书策略”。发明人意识到，每个交易发起方需要将交易发送到所述单个或多个第三方机构，以对该交易进行检验和数字签名，这本身就需要互相信任并开通防火墙。
 技术问题
因此，如何在尽量减少交易发起方和所有第三方机构之间的对接的情况下实现交易背书，成为一个亟待解决的技术问题。
 技术解决方案
有鉴于此，本申请提出一种交易背书处理方法、服务器及计算机可读存储介质，以解决至少一个上述技术问题。
首先，为实现上述目的，本申请提出一种交易背书处理方法，应用于服务器，所述服务器对接区块链中的所有数据节点，该方法包括步骤：
接收交易发起方发送的原始交易请求，所述原始交易请求包含交易信息；
查询与所述原始交易请求对应的交易背书策略；
根据所述交易背书策略确定与所述原始交易请求匹配的背书节点；
将所述原始交易请求发送至所确定的背书节点进行交易背书；
接收所有所述背书节点反馈的交易结果和数字签名；
打包所述原始交易请求及所有所述背书节点反馈的所述交易结果和数字签名，生成完整交易请求；及
将所述完整交易请求广播至所述区块链上的数据节点。
此外，为实现上述目的，本申请还提供一种服务器，所述服务器对接区块链中的所有数据节点，所述服务器包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的交易背书处理***，所述交易背书处理***被所述处理器执行时实现如下步骤：
接收交易发起方发送的原始交易请求，所述原始交易请求包含交易信息；
查询与所述原始交易请求对应的交易背书策略；
根据所述交易背书策略确定与所述原始交易请求匹配的背书节点；
将所述原始交易请求发送至所确定的背书节点进行交易背书；
接收所有所述背书节点反馈的交易结果和数字签名；
打包所述原始交易请求及所有所述背书节点反馈的所述交易结果和数字签名，生成完整交易请求；及
将所述完整交易请求广播至所述区块链上的数据节点。
此外，为实现上述目的，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可读指令，所述计算机可读指令可被至少一个处理器执行，以实现如下步骤：
接收交易发起方发送的原始交易请求，所述原始交易请求包含交易信息；
查询与所述原始交易请求对应的交易背书策略；
根据所述交易背书策略确定与所述原始交易请求匹配的背书节点；
将所述原始交易请求发送至所确定的背书节点进行交易背书；
接收所有所述背书节点反馈的交易结果和数字签名；
打包所述原始交易请求及所有所述背书节点反馈的所述交易结果和数字签名，生成完整交易请求；及
将所述完整交易请求广播至所述区块链上的数据节点。
此外，为实现上述目的，本申请还提供一种交易背书处理***，所述交易背书处理***包括：
接收模块，用于：接收交易发起方发送的原始交易请求，所述原始交易请求包含交易信息；
查询模块，用于：查询与所述原始交易请求对应的交易背书策略；
确定模块，用于：根据所述交易背书策略确定与所述原始交易请求匹配的背书节点；
发送模块，用于：将所述原始交易请求发送至所确定的背书节点进行交易背书；
生成模块，用于：接收所有所述背书节点反馈的交易结果和数字签名，打包所述原始交易请求及所有所述背书节点反馈的所述交易结果和数字签名，生成完整交易请求，及将所述完整交易请求广播至所述区块链上的数据节点。
 有益效果
相较于现有技术，本申请所提出的交易背书处理方法、服务器及计算机可读存储介质，通过在云端建立一个服务器对接所述区块链的所有数据节点，交易发起方可以通过所述服务器对接到其他数据节点，各个数据节点也可以通过所述服务器对接其他数据节点和交易发起方。当任何机构（数据节点）通过所述服务器传递信息时，所述服务器会通过业务逻辑（例如交易背书策略）判断并传递交易信息给接收方。所有数据节点和交易发起方只需要与所述服务器对接即可达到与所有第三方数据节点和交易装置对接的效果，避免了因为数据节点之间无法互相打开防火墙而无法成功进行交易背书的问题，增强了BFT共识算法的可用性，提升了区块链交易的处理效率和用户体验。
 附图说明
图1是本申请各个实施例一可选的应用环境架构示意图；
图2是图1中的服务器一可选的硬件架构的示意图；
图3是本申请交易背书处理***第一实施例的程序模块示意图；
图4是本申请交易背书处理***第二实施例的程序模块示意图；
图5是本申请交易背书处理方法第一实施例的流程示意图；
图6是本申请交易背书处理方法第二实施例的流程示意图；
本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
 本发明的实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
需要说明的是，在本申请中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。
参阅图1所示，是本申请各个实施例一可选的应用环境架构示意图。
在本实施例中，本申请可应用于区块链网络中，所述区块链中至少包括服务器2及多个数据节点4。其中，所述服务器2可以是机架式服务器、刀片式服务器、塔式服务器或机柜式服务器等计算设备，该服务器2可以是独立的服务器，也可以是多个服务器所组成的服务器集群。所述数据节点4可以是移动电话、智能电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD（平板电脑）、PMP(便携式多媒体播放器)、导航装置、车载装置等可移动设备，以及诸如数字TV、台式计算机、笔记本、服务器等固定终端，也可以是服务器。
在本实施例中，在现有的区块链架构中增加一个服务器2，所述服务器2为建立在云端的BFT服务器，对接所述区块链中的所有所述数据节点4（包括交易发起方、交易接收方、背书节点等）。当所述数据节点4位于交易参与方（交易发起方、交易接收方）所在机构时，还包括所述数据节点4（或所述机构）对应的交易装置6。交易发起方、交易接收方、背书节点和其他数据节点都可以通过所述服务器2进行对接，所有数据节点4只需要与所述服务器2对接即可达到与所有第三方数据节点4和交易装置6对接的效果。
参阅图2所示，是本申请服务器2一可选的硬件架构的示意图。
本实施例中，所述服务器2可包括，但不仅限于，可通过***总线相互通信连接存储器11、处理器12、网络接口13。需要指出的是，图2仅示出了具有组件11-13的服务器2，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。
其中，所述服务器2可以是机架式服务器、刀片式服务器、塔式服务器或机柜式服务器等计算设备，该服务器2可以是独立的服务器，也可以是多个服务器所组成的服务器集群。
所述存储器11至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器（例如，SD或DX存储器等）、随机访问存储器（RAM）、静态随机访问存储器（SRAM）、只读存储器（ROM）、电可擦除可编程只读存储器（EEPROM）、可编程只读存储器（PROM）、磁性存储器、磁盘、光盘等。在一些实施例中，所述存储器11可以是所述服务器2的内部存储单元，例如该服务器2的硬盘或内存。在另一些实施例中，所述存储器11也可以是所述服务器2的外部存储设备，例如该服务器2上配备的插接式硬盘，智能存储卡（Smart Media Card, SMC），安全数字（Secure Digital, SD）卡，闪存卡（Flash Card）等。当然，所述存储器11还可以既包括所述服务器2的内部存储单元也包括其外部存储设备。本实施例中，所述存储器11通常用于存储安装于所述服务器2的操作***和各类应用软件，例如交易背书处理***200的程序代码等。此外，所述存储器11还可以用于暂时地存储已经输出或者将要输出的各类数据。所述可读存储介质可以是非易失性，也可以是易失性。
所述处理器12在一些实施例中可以是中央处理器（Central Processing Unit，CPU）、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器12通常用于控制所述服务器2的总体操作。本实施例中，所述处理器12用于运行所述存储器11中存储的程序代码或者处理数据，例如运行所述的交易背书处理***200等。
所述网络接口13可包括无线网络接口或有线网络接口，该网络接口13通常用于在所述服务器2与其他电子设备之间建立通信连接。
至此，己经详细介绍了本申请的应用环境架构及相关设备的硬件结构和功能。下面，将基于上述介绍提出本申请的各个实施例。
首先，本申请提出一种交易背书处理***200。
参阅图3所示，是本申请交易背书处理***200第一实施例的程序模块图。
本实施例中，所述交易背书处理***200包括一系列的存储于存储器11上的计算机程序指令，当该计算机程序指令被处理器12执行时，可以实现本申请各实施例的交易背书处理操作。在一些实施例中，基于该计算机程序指令各部分所实现的特定的操作，交易背书处理***200可以被划分为一个或多个模块。例如，在图3中，所述交易背书处理***200可以被分割成接收模块201、查询模块202、确定模块203、发送模块204、生成模块205。其中：
所述接收模块201，用于接收交易发起方发送的原始交易请求。
具体地，所述服务器2与所有交易发起方对接，所述交易发起方通过自身的交易装置6向所述服务器2发送原始交易请求，并可以通过所述服务器2对接至其他数据节点4。所述原始交易请求中只包括交易信息，并没有交易结果或对交易结果背书的数字签名。所述交易信息即交易请求参数，包括交易类型、交易双方、交易金额等。例如，某个交易为机构A转给机构B100元，则所述原始交易请求中的交易请求参数（交易信息）为“交易类型：转账；交易双方：A，B；交易金额：100”。
所述查询模块202，用于查询与所述原始交易请求对应的交易背书策略。
具体地，所述服务器2中存储有所述区块链***搭建时制定的一组交易背书策略，并在所述交易背书策略有变更时进行实时更新。所述交易背书策略用于指导背书节点进行正确的背书，背书节点通过所述交易背书策略来确定一个交易是否被正确的背书。具体而言，所述交易背书策略指明原始交易请求需要多少个第三方数据节点4（背书节点）或者具体哪一些第三方数据节点4来对交易结果背书。
当从交易发起方接收到所述原始交易请求后，所述查询模块202从所存储的一组交易背书策略中查询与所述原始交易请求对应的交易背书策略。其中，可以根据交易类型或交易发起方进行查询，也可以灵活配置本领域常用的其他方式确定所述原始交易请求和所述交易背书策略之间的对应关系，在本实施例中不做限制。
所述确定模块203，用于根据所述交易背书策略确定与所述原始交易请求匹配的背书节点。
具体地，所述服务器2与所述区块链中所有数据节点4对接，每个所述数据节点4可以通过所述服务器2与其他数据节点4和所述交易发起方对接。所述服务器2中存储有所有与其对接的数据节点4的身份信息，包括数字证书、IP地址、名称等。
当查询到与所述原始交易请求对应的交易背书策略后，所述确定模块203根据所述交易背书策略中的背书节点信息和所存储的所有数据节点4的身份信息，确定所述原始交易请求匹配的背书节点。当所述交易背书策略指明具体需要哪一些第三方数据节点4（背书节点）来对交易结果背书时，所述确定模块203直接通过所存储的所有数据节点4的身份信息找到这些背书节点。当所述交易背书策略仅指明所述原始交易请求需要多少个背书节点或者对背书节点的要求时，所述确定模块203根据所述交易背书策略随机或者按预先设置的规则从所有数据节点4中挑选出符合要求的背书节点。例如，根据所述交易背书策略，确定所述原始交易请求需要由背书节点C、D、E进行交易背书。
所述发送模块204，用于将所述原始交易请求发送至所确定的背书节点进行交易背书。
具体地，当所述确定模块203确定出所述原始交易请求匹配的背书节点后，所述发送模块204将接收到的所述原始交易请求发送至所述背书节点，以使所述背书节点分别模拟该交易并验证是否合法。例如，所述发送模块204将所述原始交易请求发送至背书节点C、D、E，由背书节点C、D、E分别在本地对该交易进行背书。
所述接收模块201，还用于接收所述背书节点反馈的交易结果和数字签名。
具体地，当各个背书节点完成交易计算和检验并对交易结果进行数字签名后，将所述交易结果和数字签名反馈给所述服务器2。所述接收模块201从每一个所述背书节点接收交易结果和数字签名。例如，背书节点C、D、E分别在本地完成交易计算和检验并对交易结果进行数字签名后，将所述交易结果和数字签名反馈给所述服务器2，所述接收模块201接收背书节点C、D、E反馈的全部交易结果和数字签名。
所述生成模块205，用于打包所述原始交易请求及所述交易结果和数字签名，生成完整交易请求。
具体地，当所述接收模块201接收到所有背书节点反馈的所述交易结果和数字签名后，所述生成模块205将所述原始交易请求以及所有与所述原始交易请求对应的所述交易结果和数字签名进行打包，并用自身的秘钥签名后生成一个完整交易请求。例如，所述生成模块205将所述原始交易请求以及背书节点C、D、E反馈的全部交易结果和数字签名进行打包并签名，生成所述完整交易请求。
所述发送模块204，还用于将所述完整交易请求广播至所述区块链上的数据节点4。
具体地，所述发送模块204将生成的所述完整交易请求广播至所述区块链上的数据节点4，从而完成对该交易的背书过程。
本实施例提供的交易背书处理***，通过在云端建立一个服务器2对接所述区块链的所有数据节点4，交易发起方可以通过所述服务器2对接到其他数据节点4，各个数据节点4也可以通过所述服务器2对接其他数据节点4和交易发起方。当任何机构（数据节点）通过所述服务器2传递信息时，所述服务器2会通过业务逻辑（例如交易背书策略）判断并传递交易信息给接收方。所有数据节点4和交易发起方只需要与所述服务器2对接即可达到与所有第三方数据节点4和交易装置6对接的效果，避免了因为数据节点4之间无法互相打开防火墙而无法成功进行交易背书的问题，增强了BFT共识算法的可用性，提升了区块链交易的处理效率和用户体验。
参阅图4所示，是本申请交易背书处理***200第二实施例的程序模块图。本实施例中，所述的交易背书处理***200除了包括第一实施例中的所述接收模块201、查询模块202、确定模块203、发送模块204、生成模块205之外，还包括判断模块206。
所述判断模块206，用于在所述接收模块201接收到所述背书节点反馈的交易结果和数字签名后，判断所述交易发起方是否授权所述服务器2代理发送交易。
具体地，所述交易发起方可以选择是否授权所述服务器2代理发送交易，即选择由自身发起所述完整交易请求，或者由所述服务器2代理发起所述完整交易请求。其中，当选择授权所述服务器2代理发送交易时，可以向所述服务器2发送一个授权指令，或者在所述原始交易请求中附带进行授权，也可以采用本领域常用的其他方式进行授权。所述服务器2根据是否接收到所述交易发起方的授权（是否接收到所述授权指令，或者所述原始交易请求中是否附带有授权信息），判断是否为所述交易发起方代理发送交易。
若接收到所述交易发起方的授权，即为代理交易发送模式；若未接收到所述交易发起方的授权，则为非代理交易发送模式。当为代理交易发送模式时，采用上述第一实施例的处理过程，由所述生成模块205打包所述原始交易请求及所述交易结果和数字签名，生成完整交易请求，然后由所述发送模块204将所述完整交易请求广播至所述区块链上的数据节点4。当为非代理交易发送模式时，采用本实施例下述的处理过程。
所述发送模块204，还用于当所述交易发起方未授权所述服务器2代理发送交易时，将所述交易结果和数字签名发送至所述交易发起方。
具体地，当所述交易发起方没有授权所述服务器2代理发送交易时，所述接收模块201接收到所有背书节点反馈的所述交易结果和数字签名后，所述发送模块204会将所述交易结果和数字签名发送至所述交易发起方。
所述接收模块201，还用于接收所述交易发起方打包生成的完整交易请求。
具体地，所述交易发起方接收到所述发送模块204发送的所有背书节点反馈的所述交易结果和数字签名后，其对应的交易装置6会将所述原始交易请求以及所有与所述原始交易请求对应的所述交易结果和数字签名进行打包，并用自身的秘钥签名后生成一个完整交易请求，然后将所述完整交易请求再次发送至所述服务器2。所述接收模块201接收到所述完整交易请求后，再由所述发送模块204将所述完整交易请求广播至所述区块链上的数据节点4。
本实施例提供的交易背书处理***中，交易发起方可以选择是否授权所述服务器2代理发送交易，所述服务器2根据所述交易发起方是否授权，可以灵活采用不同的方式生成完整交易请求，然后再广播至其他数据节点4，进一步增强BFT共识算法的可用性和提升用户体验。
此外，本申请还提出一种交易背书处理方法。
参阅图5所示，是本申请交易背书处理方法第一实施例的流程示意图。在本实施例中，根据不同的需求，图5所示的流程图中的步骤的执行顺序可以改变，某些步骤可以省略。
该方法包括以下步骤：
步骤S400，接收交易发起方发送的原始交易请求。
具体地，所述服务器2与所有交易发起方对接，所述交易发起方通过自身的交易装置6向所述服务器2发送原始交易请求，并可以通过所述服务器2对接至其他数据节点4。所述原始交易请求中只包括交易信息，并没有交易结果或对交易结果背书的数字签名。所述交易信息即交易请求参数，包括交易类型、交易双方、交易金额等。例如，某个交易为机构A转给机构B100元，则所述原始交易请求中的交易请求参数（交易信息）为“交易类型：转账；交易双方：A，B；交易金额：100”。
步骤S402，查询与所述原始交易请求对应的交易背书策略。
具体地，所述服务器2中存储有所述区块链***搭建时制定的一组交易背书策略，并在所述交易背书策略有变更时进行实时更新。所述交易背书策略用于指导背书节点进行正确的背书，背书节点通过所述交易背书策略来确定一个交易是否被正确的背书。具体而言，所述交易背书策略指明原始交易请求需要多少个第三方数据节点4（背书节点）或者具体哪一些第三方数据节点4来对交易结果背书。
当从交易发起方接收到所述原始交易请求后，所述服务器2从所存储的一组交易背书策略中查询与所述原始交易请求对应的交易背书策略。其中，可以根据交易类型或交易发起方进行查询，也可以灵活配置本领域常用的其他方式确定所述原始交易请求和所述交易背书策略之间的对应关系，在本实施例中不做限制。
步骤S404，根据所述交易背书策略确定与所述原始交易请求匹配的背书节点。
具体地，所述服务器2与所述区块链中所有数据节点4对接，每个所述数据节点4可以通过所述服务器2与其他数据节点4和所述交易发起方对接。所述服务器2中存储有所有与其对接的数据节点4的身份信息，包括数字证书、IP地址、名称等。
当查询到与所述原始交易请求对应的交易背书策略后，所述服务器2根据所述交易背书策略中的背书节点信息和所存储的所有数据节点4的身份信息，确定所述原始交易请求匹配的背书节点。当所述交易背书策略指明具体需要哪一些第三方数据节点4（背书节点）来对交易结果背书时，所述服务器2直接通过所存储的所有数据节点4的身份信息找到这些背书节点。当所述交易背书策略仅指明所述原始交易请求需要多少个背书节点或者对背书节点的要求时，所述服务器2根据所述交易背书策略随机或者按预先设置的规则从所有数据节点4中挑选出符合要求的背书节点。例如，根据所述交易背书策略，确定所述原始交易请求需要由背书节点C、D、E进行交易背书。
步骤S406，将所述原始交易请求发送至所确定的背书节点进行交易背书。
具体地，当所述服务器2确定出所述原始交易请求匹配的背书节点后，将接收到的所述原始交易请求发送至所述背书节点，以使所述背书节点分别模拟该交易并验证是否合法。例如，所述服务器2将所述原始交易请求发送至背书节点C、D、E，由背书节点C、D、E分别在本地对该交易进行背书。
步骤S408，接收所述背书节点反馈的交易结果和数字签名。
具体地，当各个背书节点完成交易计算和检验并对交易结果进行数字签名后，将所述交易结果和数字签名反馈给所述服务器2。所述服务器2从每一个所述背书节点接收交易结果和数字签名。例如，背书节点C、D、E分别在本地完成交易计算和检验并对交易结果进行数字签名后，将所述交易结果和数字签名反馈给所述服务器2，所述服务器2接收背书节点C、D、E反馈的全部交易结果和数字签名。
步骤S410，打包所述原始交易请求及所述交易结果和数字签名，生成完整交易请求。
具体地，当所述服务器2接收到所有背书节点反馈的所述交易结果和数字签名后，将所述原始交易请求以及所有与所述原始交易请求对应的所述交易结果和数字签名进行打包，并用自身的秘钥签名后生成一个完整交易请求。例如，所述服务器2将所述原始交易请求以及背书节点C、D、E反馈的全部交易结果和数字签名进行打包并签名，生成所述完整交易请求。
步骤S412，将所述完整交易请求广播至所述区块链上的数据节点4。
具体地，所述服务器2将生成的所述完整交易请求广播至所述区块链上的数据节点4，从而完成对该交易的背书过程。
本实施例提供的交易背书处理方法，通过在云端建立一个服务器2对接所述区块链的所有数据节点4，交易发起方可以通过所述服务器2对接到其他数据节点4，各个数据节点4也可以通过所述服务器2对接其他数据节点4和交易发起方。当任何机构（数据节点）通过所述服务器2传递信息时，所述服务器2会通过业务逻辑（例如交易背书策略）判断并传递交易信息给接收方。所有数据节点4和交易发起方只需要与所述服务器2对接即可达到与所有第三方数据节点4和交易装置6对接的效果，避免了因为数据节点4之间无法互相打开防火墙而无法成功进行交易背书的问题，增强了BFT共识算法的可用性，提升了区块链交易的处理效率和用户体验。
如图6所示，是本申请交易背书处理方法的第二实施例的流程示意图。本实施例中，所述交易背书处理方法的步骤S500-S508及S516-S518与第一实施例的步骤S400-S412相类似，区别在于该方法还包括步骤S510-S514。
该方法包括以下步骤：
步骤S500，接收交易发起方发送的原始交易请求。
具体地，所述服务器2与所有交易发起方对接，所述交易发起方通过自身的交易装置6向所述服务器2发送原始交易请求，并可以通过所述服务器2对接至其他数据节点4。所述原始交易请求中只包括交易信息，并没有交易结果或对交易结果背书的数字签名。所述交易信息即交易请求参数，包括交易类型、交易双方、交易金额等。例如，某个交易为机构A转给机构B100元，则所述原始交易请求中的交易请求参数（交易信息）为“交易类型：转账；交易双方：A，B；交易金额：100”。
步骤S502，查询与所述原始交易请求对应的交易背书策略。
具体地，所述服务器2中存储有所述区块链***搭建时制定的一组交易背书策略，并在所述交易背书策略有变更时进行实时更新。所述交易背书策略用于指导背书节点进行正确的背书，背书节点通过所述交易背书策略来确定一个交易是否被正确的背书。具体而言，所述交易背书策略指明原始交易请求需要多少个第三方数据节点4（背书节点）或者具体哪一些第三方数据节点4来对交易结果背书。
当从交易发起方接收到所述原始交易请求后，所述服务器2从所存储的一组交易背书策略中查询与所述原始交易请求对应的交易背书策略。其中，可以根据交易类型或交易发起方进行查询，也可以灵活配置本领域常用的其他方式确定所述原始交易请求和所述交易背书策略之间的对应关系，在本实施例中不做限制。
步骤S504，根据所述交易背书策略确定与所述原始交易请求匹配的背书节点。
具体地，所述服务器2与所述区块链中所有数据节点4对接，每个所述数据节点4可以通过所述服务器2与其他数据节点4和所述交易发起方对接。所述服务器2中存储有所有与其对接的数据节点4的身份信息，包括数字证书、IP地址、名称等。
当查询到与所述原始交易请求对应的交易背书策略后，所述服务器2根据所述交易背书策略中的背书节点信息和所存储的所有数据节点4的身份信息，确定所述原始交易请求匹配的背书节点。当所述交易背书策略指明具体需要哪一些第三方数据节点4（背书节点）来对交易结果背书时，所述服务器2直接通过所存储的所有数据节点4的身份信息找到这些背书节点。当所述交易背书策略仅指明所述原始交易请求需要多少个背书节点或者对背书节点的要求时，所述服务器2根据所述交易背书策略随机或者按预先设置的规则从所有数据节点4中挑选出符合要求的背书节点。例如，根据所述交易背书策略，确定所述原始交易请求需要由背书节点C、D、E进行交易背书。
步骤S506，将所述原始交易请求发送至所确定的背书节点进行交易背书。
具体地，当所述服务器2确定出所述原始交易请求匹配的背书节点后，将接收到的所述原始交易请求发送至所述背书节点，以使所述背书节点分别模拟该交易并验证是否合法。例如，所述服务器2将所述原始交易请求发送至背书节点C、D、E，由背书节点C、D、E分别在本地对该交易进行背书。
步骤S508，接收所述背书节点反馈的交易结果和数字签名。
具体地，当各个背书节点完成交易计算和检验并对交易结果进行数字签名后，将所述交易结果和数字签名反馈给所述服务器2。所述服务器2从每一个所述背书节点接收交易结果和数字签名。例如，背书节点C、D、E分别在本地完成交易计算和检验并对交易结果进行数字签名后，将所述交易结果和数字签名反馈给所述服务器2，所述服务器2接收背书节点C、D、E反馈的全部交易结果和数字签名。
步骤S510，判断所述交易发起方是否授权所述服务器2代理发送交易。若是（代理交易发送模式），则执行步骤S516；若否（非代理交易发送模式），则执行步骤S512。
具体地，所述交易发起方可以选择是否授权所述服务器2代理发送交易，即选择由自身发起所述完整交易请求，或者由所述服务器2代理发起所述完整交易请求。其中，当选择授权所述服务器2代理发送交易时，可以向所述服务器发送一个授权指令，或者在所述原始交易请求中附带进行授权，也可以采用本领域常用的其他方式进行授权。所述服务器2根据是否接收到所述交易发起方的授权（是否接收到所述授权指令，或者所述原始交易请求中是否附带有授权信息），判断是否为所述交易发起方代理发送交易。
若所述服务器2接收到所述交易发起方的授权，即为代理交易发送模式；若未接收到所述交易发起方的授权，则为非代理交易发送模式。当为代理交易发送模式时，采用下述步骤S516-S518的处理过程；当为非代理交易发送模式时，采用下述步骤S512-S514及S518的处理过程。
步骤S512，将所述交易结果和数字签名发送至所述交易发起方。
具体地，当所述交易发起方没有授权所述服务器2代理发送交易时，所述服务器2在接收到所有背书节点反馈的所述交易结果和数字签名后，会将所述交易结果和数字签名发送至所述交易发起方。
步骤S514，接收所述交易发起方打包生成的完整交易请求。
具体地，所述交易发起方接收到所述服务器2发送的所有背书节点反馈的所述交易结果和数字签名后，其对应的交易装置6会将所述原始交易请求以及所有与所述原始交易请求对应的所述交易结果和数字签名进行打包，并用自身的秘钥签名后生成一个完整交易请求，然后将所述完整交易请求再次发送至所述服务器2。
步骤S516，打包所述原始交易请求及所述交易结果和数字签名，生成完整交易请求。
具体地，当所述交易发起方授权所述服务器2代理发送交易时，所述服务器2将所述原始交易请求以及所有与所述原始交易请求对应的所述交易结果和数字签名进行打包，并用自身的秘钥签名后生成一个完整交易请求。例如，所述服务器2将所述原始交易请求以及背书节点C、D、E反馈的全部交易结果和数字签名进行打包并签名，生成所述完整交易请求。
步骤S518，将所述完整交易请求广播至所述区块链上的数据节点4。
具体地，所述服务器2将自身生成的所述完整交易请求（代理交易发送模式）或者从所述交易发起方接收到的所述完整交易请求（非代理交易发送模式）广播至所述区块链上的数据节点4，从而完成对该交易的背书过程。
本实施例提供的交易背书处理方法中，交易发起方可以选择是否授权所述服务器2代理发送交易，所述服务器2根据所述交易发起方是否授权，可以灵活采用不同的方式生成完整交易请求，然后再广播至其他数据节点4，进一步增强BFT共识算法的可用性和提升用户体验。
本申请还提供了另一种实施方式，即提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可读指令，所述计算机可读指令可被至少一个处理器执行，以使所述至少一个处理器执行如上述的交易背书处理方法的步骤。所述计算机可读存储介质可以是非易失性，也可以是易失性。
上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质（如ROM/RAM、磁碟、光盘）中，包括若干指令用以使得一台终端设备（可以是手机，计算机，服务器，空调器，或者网络设备等）执行本申请各个实施例所述的方法。
以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (20)

  1. 一种交易背书处理方法，应用于服务器，其中，所述服务器对接区块链中的所有数据节点，所述方法包括步骤：
    接收交易发起方发送的原始交易请求，所述原始交易请求包含交易信息；
    查询与所述原始交易请求对应的交易背书策略；
    根据所述交易背书策略确定与所述原始交易请求匹配的背书节点；
    将所述原始交易请求发送至所确定的背书节点进行交易背书；
    接收所有所述背书节点反馈的交易结果和数字签名；
    打包所述原始交易请求及所有所述背书节点反馈的所述交易结果和数字签名，生成完整交易请求；及
    将所述完整交易请求广播至所述区块链上的数据节点。
  2. 如权利要求1所述的交易背书处理方法，其中，该方法在所述接收所有所述背书节点反馈的交易结果和数字签名的步骤之后还包括：
    判断所述交易发起方是否授权所述服务器代理发送交易；
    当所述交易发起方授权所述服务器代理发送交易时，执行所述打包所述原始交易请求及所有所述背书节点反馈的所述交易结果和数字签名，生成完整交易请求的步骤；
    当所述交易发起方未授权所述服务器代理发送交易时，将所有所述背书节点反馈的所述交易结果和数字签名发送至所述交易发起方，并接收所述交易发起方打包生成的完整交易请求。
  3. 如权利要求1或2所述的交易背书处理方法，其中，所述交易信息包括交易类型、交易双方、交易金额。
  4. 如权利要求3所述的交易背书处理方法，其中，所述完整交易请求包括所述交易信息以及所有与所述原始交易请求对应的所述背书节点反馈的所述交易结果和数字签名，并且在打包后利用所述服务器或所述交易发起方的秘钥进行签名。
  5. 如权利要求3所述的交易背书处理方法，其中，所述服务器中存储有所述区块链搭建时制定的一组交易背书策略，并在所述交易背书策略有变更时进行实时更新，所述查询与所述原始交易请求对应的交易背书策略的步骤包括：根据所述原始交易请求中的交易类型或交易发起方从所存储的所述一组交易背书策略中查询与所述原始交易请求对应的交易背书策略。
  6. 如权利要求1或2所述的交易背书处理方法，其中，所述服务器中存储有对接的所有数据节点的身份信息，所述根据所述交易背书策略确定与所述原始交易请求匹配的背书节点的步骤包括：根据所述交易背书策略中的背书节点信息以及所存储的所有数据节点的身份信息，确定出与所述原始交易请求匹配的背书节点。
  7. 如权利要求6所述的交易背书处理方法，其中，所述根据所述交易背书策略确定与所述原始交易请求匹配的背书节点的步骤还包括：
    当所述交易背书策略指明所述原始交易请求具体需要哪一些背书节点来对交易结果背书时，直接通过所存储的所有数据节点的身份信息找到所述背书节点；
    当所述交易背书策略仅指明所述原始交易请求需要多少个背书节点或者对背书节点的要求时，根据所述交易背书策略随机或者按预先设置的规则从所有数据节点中挑选出符合要求的背书节点。
  8. 如权利要求2所述的交易背书处理方法，其中，所述判断所述交易发起方是否授权所述服务器代理发送交易的步骤包括：
    根据是否接收到所述交易发起方发送的授权指令或者所述原始交易请求中是否附带有授权信息，判断所述交易发起方是否授权所述服务器代理发送交易。
  9. 一种服务器，其中，所述服务器对接区块链中的所有数据节点，所述服务器包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的交易背书处理***，所述交易背书处理***被所述处理器执行时实现如下步骤：
    接收交易发起方发送的原始交易请求，所述原始交易请求包含交易信息；
    查询与所述原始交易请求对应的交易背书策略；
    根据所述交易背书策略确定与所述原始交易请求匹配的背书节点；
    将所述原始交易请求发送至所确定的背书节点进行交易背书；
    接收所有所述背书节点反馈的交易结果和数字签名；
    打包所述原始交易请求及所有所述背书节点反馈的所述交易结果和数字签名，生成完整交易请求；及
    将所述完整交易请求广播至所述区块链上的数据节点。
  10. 如权利要求9所述的服务器，其中，所述接收所有所述背书节点反馈的交易结果和数字签名的步骤之后还包括：
    判断所述交易发起方是否授权所述服务器代理发送交易；
    当所述交易发起方授权所述服务器代理发送交易时，执行所述打包所述原始交易请求及所有所述背书节点反馈的所述交易结果和数字签名，生成完整交易请求的步骤；
    当所述交易发起方未授权所述服务器代理发送交易时，将所有所述背书节点反馈的所述交易结果和数字签名发送至所述交易发起方，并接收所述交易发起方打包生成的完整交易请求。
  11. 一种计算机可读存储介质，其中，所述计算机可读存储介质存储有计算机可读指令，所述计算机可读指令可被至少一个处理器执行，以实现如下步骤：
    接收交易发起方发送的原始交易请求，所述原始交易请求包含交易信息；
    查询与所述原始交易请求对应的交易背书策略；
    根据所述交易背书策略确定与所述原始交易请求匹配的背书节点；
    将所述原始交易请求发送至所确定的背书节点进行交易背书；
    接收所有所述背书节点反馈的交易结果和数字签名；
    打包所述原始交易请求及所有所述背书节点反馈的所述交易结果和数字签名，生成完整交易请求；及
    将所述完整交易请求广播至所述区块链上的数据节点。
  12. 如权利要求11所述的计算机可读存储介质，其中，所述接收所有所述背书节点反馈的交易结果和数字签名的步骤之后还包括：
    判断所述交易发起方是否授权所述服务器代理发送交易；
    当所述交易发起方授权所述服务器代理发送交易时，执行所述打包所述原始交易请求及所有所述背书节点反馈的所述交易结果和数字签名，生成完整交易请求的步骤；
    当所述交易发起方未授权所述服务器代理发送交易时，将所有所述背书节点反馈的所述交易结果和数字签名发送至所述交易发起方，并接收所述交易发起方打包生成的完整交易请求。
  13. 一种交易背书处理***，其中，所述交易背书处理***包括：
    接收模块，用于：接收交易发起方发送的原始交易请求，所述原始交易请求包含交易信息；
    查询模块，用于：查询与所述原始交易请求对应的交易背书策略；
    确定模块，用于：根据所述交易背书策略确定与所述原始交易请求匹配的背书节点；
    发送模块，用于：将所述原始交易请求发送至所确定的背书节点进行交易背书；
    生成模块，用于：接收所有所述背书节点反馈的交易结果和数字签名，打包所述原始交易请求及所有所述背书节点反馈的所述交易结果和数字签名，生成完整交易请求，及将所述完整交易请求广播至所述区块链上的数据节点。
  14. 如权利要求13所述的交易背书处理***，其中，该***还包括：
    判断模块，用于：判断所述交易发起方是否授权所述服务器代理发送交易；当所述交易发起方授权所述服务器代理发送交易时，执行所述打包所述原始交易请求及所有所述背书节点反馈的所述交易结果和数字签名，生成完整交易请求的步骤；当所述交易发起方未授权所述服务器代理发送交易时，将所有所述背书节点反馈的所述交易结果和数字签名发送至所述交易发起方，并接收所述交易发起方打包生成的完整交易请求。
  15. 如权利要求13或14所述的交易背书处理***，其中，所述交易信息包括交易类型、交易双方、交易金额。
  16. 如权利要求15所述的交易背书处理***，其中，所述完整交易请求包括所述交易信息以及所有与所述原始交易请求对应的所述背书节点反馈的所述交易结果和数字签名，并且在打包后利用所述服务器或所述交易发起方的秘钥进行签名。
  17. 如权利要求15所述的交易背书处理***，其中，所述服务器中存储有所述区块链搭建时制定的一组交易背书策略，并在所述交易背书策略有变更时进行实时更新，所述查询与所述原始交易请求对应的交易背书策略的步骤包括：根据所述原始交易请求中的交易类型或交易发起方从所存储的所述一组交易背书策略中查询与所述原始交易请求对应的交易背书策略。
  18. 如权利要求13或14所述的交易背书处理***，其中，所述服务器中存储有对接的所有数据节点的身份信息，所述根据所述交易背书策略确定与所述原始交易请求匹配的背书节点的步骤包括：根据所述交易背书策略中的背书节点信息以及所存储的所有数据节点的身份信息，确定出与所述原始交易请求匹配的背书节点。
  19. 如权利要求18所述的交易背书处理***，其中，所述根据所述交易背书策略确定与所述原始交易请求匹配的背书节点的步骤还包括：
    当所述交易背书策略指明所述原始交易请求具体需要哪一些背书节点来对交易结果背书时，直接通过所存储的所有数据节点的身份信息找到所述背书节点；
    当所述交易背书策略仅指明所述原始交易请求需要多少个背书节点或者对背书节点的要求时，根据所述交易背书策略随机或者按预先设置的规则从所有数据节点中挑选出符合要求的背书节点。
  20. 如权利要求14所述的交易背书处理***，其中，所述判断所述交易发起方是否授权所述服务器代理发送交易的步骤包括：
    根据是否接收到所述交易发起方发送的授权指令或者所述原始交易请求中是否附带有授权信息，判断所述交易发起方是否授权所述服务器代理发送交易。
PCT/CN2020/093602 2020-01-16 2020-05-30 交易背书处理方法、服务器及计算机可读存储介质 WO2021143027A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010046528.8 2020-01-16
CN202010046528.8A CN111275417B (zh) 2020-01-16 2020-01-16 交易背书处理方法、服务器及计算机可读存储介质

Publications (1)

Publication Number Publication Date
WO2021143027A1 true WO2021143027A1 (zh) 2021-07-22

Family

ID=71003239

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/093602 WO2021143027A1 (zh) 2020-01-16 2020-05-30 交易背书处理方法、服务器及计算机可读存储介质

Country Status (2)

Country Link
CN (1) CN111275417B (zh)
WO (1) WO2021143027A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112199732B (zh) * 2020-09-01 2024-04-05 东方航空物流股份有限公司 一种基于区块链的航空物流电子运单管理方法
CN114938706B (zh) * 2022-01-28 2024-05-03 香港应用科技研究院有限公司 一种在区块链***与非区块链***之间进行数据交换的方法和设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108009917A (zh) * 2017-10-13 2018-05-08 ***股份有限公司 数字货币的交易验证和登记方法及***
CN109167763A (zh) * 2018-08-16 2019-01-08 国网浙江省电力有限公司电力科学研究院 一种基于区块链的电力行业电子数据保全方法及***
CN109493056A (zh) * 2018-12-04 2019-03-19 深圳市链联科技有限公司 一种基于供应链生态应用场景的区块链共识机制
CN110033373A (zh) * 2019-03-12 2019-07-19 平安科技（深圳）有限公司 区块链中背书的装置、方法及存储介质
US20190229927A1 (en) * 2017-02-28 2019-07-25 Tencent Technology (Shenzhen) Company Ltd Method and apparatus for processing account information in block chain, storage medium, and electronic apparatus

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108376368A (zh) * 2018-03-07 2018-08-07 物数（上海）信息科技有限公司 背书策略确定方法、装置、电子设备、存储介质
CN110674128B (zh) * 2018-07-02 2023-12-15 国际商业机器公司 区块链的链上治理
US10819503B2 (en) * 2018-07-03 2020-10-27 International Business Machines Corporation Strengthening non-repudiation of blockchain transactions

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190229927A1 (en) * 2017-02-28 2019-07-25 Tencent Technology (Shenzhen) Company Ltd Method and apparatus for processing account information in block chain, storage medium, and electronic apparatus
CN108009917A (zh) * 2017-10-13 2018-05-08 ***股份有限公司 数字货币的交易验证和登记方法及***
CN109167763A (zh) * 2018-08-16 2019-01-08 国网浙江省电力有限公司电力科学研究院 一种基于区块链的电力行业电子数据保全方法及***
CN109493056A (zh) * 2018-12-04 2019-03-19 深圳市链联科技有限公司 一种基于供应链生态应用场景的区块链共识机制
CN110033373A (zh) * 2019-03-12 2019-07-19 平安科技（深圳）有限公司 区块链中背书的装置、方法及存储介质

Also Published As

Publication number Publication date
CN111275417A (zh) 2020-06-12
CN111275417B (zh) 2024-03-12

Similar Documents

Publication Publication Date Title
CN107438002B (zh) 基于区块链的***以及***中的电子设备和方法
CN112348672B (zh) 跨链交易方法、装置、多区块链***及计算设备
EP3859647A1 (en) Blockchain transaction generation method and device
US10270757B2 (en) Managing exchanges of sensitive data
CN110601816B (zh) 一种区块链***中轻量级节点控制方法及装置
CN111275555B (zh) 区块链交易处理方法、交易节点以及区块链***
US11909728B2 (en) Network resource access control methods and systems using transactional artifacts
CN110070357B (zh) 数据处理方法、装置和***
CN110995408B (zh) 一种基于数据加密的分布式计算方法及***
WO2020037927A1 (zh) 可协商的区块链交易方法、装置、设备及存储介质
CN111125778B (zh) 一种版权交易信息的处理方法及装置
CN111464295A (zh) 银行卡制卡方法及装置
WO2021143027A1 (zh) 交易背书处理方法、服务器及计算机可读存储介质
WO2023005500A1 (zh) 跨链交易处理方法、装置、电子设备以及存储介质
CN116032937A (zh) 一种边缘计算设备算力交易方法及***
KR20210103615A (ko) 블록체인 기반 사용자 인증 방법
WO2022088710A1 (zh) 一种镜像管理方法及装置
CN109544131A (zh) 一种游戏商品管理方法及装置
JP6162260B2 (ja) Ｓｃｅｐ証明書登録要求の正当性を確認するためのシステムおよび方法
CN112242979B (zh) 基于区块链***的ip地址前缀认证方法和设备
US20220353058A1 (en) Conditional offline interaction system and method
CN113362064B (zh) 多重签名方法、计算机设备和存储介质
CN113112269B (zh) 多重签名方法、计算机设备和存储介质
TWM629586U (zh) 基於電子憑證授權銀行伺服器查詢聯徵資料的系統
TWI730549B (zh) 於憑證申請過程中確認金鑰對產生演算法之系統及方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20914495

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20914495

Country of ref document: EP

Kind code of ref document: A1