WO2022206430A1

WO2022206430A1 - Method and apparatus for processing bill data by using off-chain trusted device

Info

Publication number: WO2022206430A1
Application number: PCT/CN2022/081699
Authority: WO
Inventors: 邱鸿霖; 闫莺; 张辉
Original assignee: 支付宝(杭州)信息技术有限公司; 蚂蚁区块链科技(上海)有限公司
Priority date: 2021-03-30
Filing date: 2022-03-18
Publication date: 2022-10-06
Also published as: CN112801797A

Abstract

The embodiments of the present specification provide a method and apparatus for processing bill data by using an off-chain trusted device. The method is executed by a blockchain node and comprises: executing a first transaction, the first transaction comprising at least one bill identifier, so as to allocate the at least one bill identifier to a first off-chain trusted device; and executing a second transaction sent by the first off-chain trusted device, the second transaction comprising at least one bill respectively corresponding to the at least one bill identifier, so as to acquire the at least one bill.

Description

Method and device for bill data processing using off-chain trusted equipment

technical field

The embodiments of this specification relate to the technical field of blockchain, and more particularly, to a method and apparatus for processing bill data using an off-chain trusted device.

Background technique

Blockchain technology, also known as distributed ledger technology, is a decentralized distributed database technology characterized by decentralization, openness, transparency, immutability, and trustworthiness. Each transaction of the blockchain will be broadcast to the blockchain nodes of the entire network, and each full node has full and consistent data. Due to the above-mentioned characteristics of the blockchain, the blockchain can be developed into an invoice chain, for example, for the invoicing and circulation business of invoices. However, in the existing invoice chain architecture, all invoicing operations are carried out through smart contracts deployed in the blockchain, which is limited by the performance of blockchain smart contract execution, resulting in limited invoicing throughput of the invoice business, which is difficult to expand. Business demands may not be met during peak business hours (eg, Double Eleven). Therefore, there is a need for a more efficient ticket processing scheme.

SUMMARY OF THE INVENTION

The embodiments of this specification aim to provide a more effective solution for using off-chain trusted devices to process bill data, so as to solve the deficiencies in the prior art.

In order to achieve the above object, one aspect of this specification provides a method for processing bill data using an off-chain trusted device, the method being executed by a blockchain node, including: executing a first transaction, where the first transaction includes at least A ticket identifier for assigning the at least one ticket identifier to the first off-chain trusted device; executing a second transaction sent by the first off-chain trusted device, the second transaction including The at least one bill identifies the corresponding at least one bill, so as to obtain the at least one bill.

In one embodiment, executing the first transaction includes executing the first transaction such that at least one ticket identification associated with the first off-chain trusted device is deposited in the blockchain.

In one embodiment, the first contract is invoked in the first transaction, and bill information corresponding to each bill identifier is recorded in the account status of the first contract, wherein executing the first transaction includes executing the first contract. contract such that the assignment of the at least one ticket identification is recorded in the account state of the first contract.

In one embodiment, executing the first transaction further includes executing the first contract, so that the at least one ticket identifier is allocated to the first off-chain trusted device among the plurality of off-chain trusted devices.

In one embodiment, allocating the at least one ticket identifier to a first off-chain trusted device among the multiple off-chain trusted devices includes, based on a value range corresponding to the at least one ticket identifier, assigning the at least one off-chain trusted device. A ticket identifier is allocated to the first off-chain trusted device among the multiple off-chain trusted devices.

In one embodiment, allocating the at least one ticket identifier to the first off-chain trusted device among the multiple off-chain trusted devices includes, based on the identifier of the invoicing subject corresponding to the at least one ticket identifier, assigning all the off-chain trusted devices. The at least one ticket identifier is allocated to a first off-chain trusted device among the multiple off-chain trusted devices.

In one embodiment, invoking the first contract in the second transaction, and executing the second transaction sent by the trusted device off the first chain further includes executing the first contract, so that when obtaining After the at least one bill, the at least one bill is stored in the bill information of the corresponding bill identifier in the account state of the first contract.

In one embodiment, the method further includes, after executing the second transaction, executing a third transaction, in which the first contract is called in the third transaction, so that the waiting period is determined based on the ticket information identified by each ticket. For the first ticket identifier processed by the trusted device under the first chain, the allocation information is deleted from the ticket information of the first ticket identifier.

In one embodiment, a second contract is invoked in the second transaction, and the first contract is invoked in the second contract, wherein executing the second transaction sent by the trusted device off the first chain also further Including, executing the second contract such that the at least one ticket is verified, and the verified at least one ticket is provided to the first contract.

In an embodiment, the first off-chain trusted device is a TEE device, and the second transaction further includes a signature of the TEE device on the at least one ticket, wherein the at least one ticket is signed The verification includes using the preset public key of the TEE device to verify the signature.

Another aspect of this specification provides a method for processing bill data using an off-chain trusted device, the method being performed by a first off-chain trusted device, including: obtaining from a blockchain and assigning it to the first off-chain trusted device obtain at least one bill information corresponding to the at least one bill identification; generate at least one bill corresponding to the at least one bill identification based on the at least one bill information; send to the blockchain A second transaction is sent, the second transaction including the at least one ticket.

In an embodiment, the first off-chain trusted device is a TEE device, and the second transaction further includes a signature of the TEE device on the at least one ticket.

Another aspect of this specification provides an apparatus for processing bill data using an off-chain trusted device, the apparatus is deployed on a blockchain node, and includes: a first execution unit configured to execute a first transaction, the first The transaction includes at least one ticket identifier for assigning the at least one ticket identifier to the first off-chain trusted device; the second execution unit is configured to execute the first off-chain trusted device sent by the first off-chain trusted device. Second transaction, the second transaction includes at least one bill corresponding to the at least one bill identifier, so as to obtain the at least one bill.

In one embodiment, the first execution unit is further configured to execute the first transaction so that at least one ticket identifier associated with the trusted device under the first chain is stored in the blockchain.

In one embodiment, a first contract is invoked in the first transaction, and bill information corresponding to each bill identifier is recorded in the account status of the first contract, wherein the first execution unit is further configured to execute the first contract such that the assignment of the at least one ticket identifier is recorded in the account state of the first contract.

In an embodiment, the first execution unit is further configured to execute the first contract, so that the at least one ticket identifier is allocated to the first off-chain trusted device among the multiple off-chain trusted devices equipment.

In an embodiment, the first execution unit is further configured to, based on the value range corresponding to the at least one ticket identifier, assign the at least one ticket identifier to the first chain among the multiple off-chain trusted devices under Trusted Devices.

In an embodiment, the first execution unit is further configured to, based on the identifier of the invoicing subject corresponding to the at least one ticket identifier, assign the at least one ticket identifier to the first one of the multiple off-chain trusted devices An off-chain trusted device.

In one embodiment, the first contract is invoked in the second transaction, and the second execution unit is further configured to execute the first contract, so that after acquiring the at least one ticket, all The at least one bill is stored in the bill information of the corresponding bill identifier in the account state of the first contract.

In one embodiment, the apparatus further includes a third execution unit configured to, after executing the second transaction, execute a third transaction, in which the first contract is invoked, so that based on each The ticket information of the ticket identifier is determined, the first ticket identifier waiting to be processed by the trusted device under the first chain is determined, and the allocation information is deleted from the ticket information of the first ticket identifier.

In an implementation manner, the second contract is invoked in the second transaction, and the first contract is invoked in the second contract, wherein the second execution unit is further configured to execute the second contract, The verified at least one ticket is provided to the first contract so that the at least one ticket is verified.

In an embodiment, the first off-chain trusted device is a TEE device, the second transaction further includes a signature of the TEE device on the at least one ticket, wherein the second execution unit further It is configured to use the preset public key of the TEE device to verify the signature.

Another aspect of this specification provides a device for processing bill data using an off-chain trusted device, the device is deployed on a first off-chain trusted device, and includes: a first obtaining unit configured to obtain distribution from the blockchain at least one ticket identifier for the trusted device under the first chain; a second acquiring unit, configured to acquire at least one ticket information corresponding to the at least one ticket identifier; a generating unit, configured to, based on the at least one ticket The information generates at least one ticket corresponding to the at least one ticket identifier; the sending unit is configured to send a second transaction to the blockchain, where the second transaction includes the at least one ticket.

Another aspect of the present specification provides a computer-readable storage medium on which a computer program is stored, when the computer program is executed in a computer, the computer is made to execute any one of the above methods.

Another aspect of the present specification provides a computing device, including a memory and a processor, where a computer program is stored in the memory, and the processor implements any one of the above methods when executing the computer program.

Through the two-layer blockchain architecture of the main invoice chain plus trusted devices under the chain according to the embodiment of this specification, the main chain can be dynamically expanded through the devices under the chain, so as to meet the business needs during peak business hours; Record the bill information in the account status of the contract, so that the user, the main invoice chain and the off-chain device can coordinate the bill processing based on the bill information; Writing multiple tickets to the main invoice chain at one time before disconnection can greatly reduce the number of transactions on the main invoice chain, thereby improving the overall business throughput.

Description of drawings

By describing the embodiments of the present specification in conjunction with the accompanying drawings, the embodiments of the present specification can be made clearer:

FIG. 1 shows a schematic diagram of an invoicing system according to an embodiment of the present specification;

FIG. 2 shows a flowchart of a method for invoicing through an off-chain device according to an embodiment of the present specification;

FIG. 3 shows a schematic diagram of transaction 1 (Tx1) according to an embodiment of the present specification;

Figure 4 shows a table of invoice information including respective invoice numbers recorded in the account status of the main contract C1;

FIG. 5 shows a schematic diagram of transaction 2 (Tx2) according to an embodiment of the present specification;

FIG. 6 shows a schematic diagram of transaction 3 (Tx3) according to an embodiment of the present specification;

FIG. 7 shows an apparatus 700 for using off-chain trusted devices to process ticket data according to an embodiment of the present specification;

Fig. 8 shows an apparatus 800 for processing ticket data using an off-chain trusted device according to an embodiment of the present specification.

Detailed ways

The embodiments of the present specification will be described below with reference to the accompanying drawings.

FIG. 1 shows a schematic diagram of an invoicing system according to an embodiment of the present specification. As shown in FIG. 1 , the invoicing system includes an invoice chain 11 , an off-chain device cluster 12 , and a user terminal 13 . The invoice chain 11 is, for example, a consortium chain, in which the main contract C1 (the contract name is "Main", for example) and the communication contract C2 (the contract name is "Layer2", for example) are deployed. The main contract C1 is a contract for invoicing, which includes, for example, a ticket number function (Num()), a ticket distribution function (Assign()), an invoicing function (Invoice()), and a receiving function (Receipt()) and a check function (Check()). The communication contract C2 is used to send the pending invoice number segment to the off-chain device cluster 12, which includes, for example, a data sending function (Data()), a result returning function (Result()), and a disconnecting function (Close() . )). The main contract C1 can use the off-chain device for billing by calling the communication contract C2.

The off-chain device cluster 12 includes a plurality of off-chain trusted devices for invoicing. The figure schematically shows device D1, device D2 and device D3. The off-chain trusted devices include, for example, a Trusted Execution Environment (TEE) and the client of the invoice chain is set in the trusted off-chain device. For example, device D1 can read the ledger data (such as transactions, receipts, account status, etc.) and its proof data (such as Spv proof) in the invoice chain from any node of the invoice chain through its client, and verify the ledger data, thereby Ensure the credibility of the ledger data. After acquiring the invoice number segment assigned to it based on the acquired ledger data, the device D1 can receive a plurality of invoice information corresponding to the invoice number segment from the user terminal 13, and generate a plurality of invoice information corresponding to the number segment based on the plurality of invoice information. , digitally sign the issued multiple invoices using its hardware private key, and provide the multiple invoices and digital signatures to the invoice chain 11 by sending a transaction to the invoice chain 11 . After obtaining the multiple invoices and digital signatures issued from the device D1, the invoice chain 11 can verify the above digital signatures through the pre-stored hardware public key of the device D1, so as to ensure the credibility of the invoice, and obtain the invoice and store it in the invoice. chain 11.

The user terminal 13 is, for example, a terminal device of the merchant 1, in which the client terminal of the invoice chain is set. When merchant 1 wishes to conduct invoicing business through the invoice chain, merchant 1 applies for the invoice number segment (for example, invoice number 1-500) in the invoice chain by sending a transaction to the invoice chain node (for example, node P1) in advance. In the transaction, for example, calling The Num() function in the main contract C1, thereby causing the transaction to send the invoice number segment 1-500 to Merchant 1 when the transaction is executed. After the transaction is executed, the merchant corresponding to each ticket number can be recorded in the account status of the main contract C1, as shown in FIG. 4 which will be described below.

Nodes in the invoice chain 11 can set the invoice number segment to be processed by the off-chain device by sending a transaction, for example, by calling the Assign() function in the main contract C1 in the transaction, and assigning the predetermined invoice number segment (eg, invoice number 1- 1000) is allocated to the off-chain device for processing, and the information is recorded in the account status of the main contract C1.

When the merchant 1 wishes to issue an invoice for a certain invoice number through the invoice chain 11, it queries the account status of the main contract C1 to determine whether the invoice number is issued by the invoice chain 11 or the off-chain device. If it is determined based on the account status of the main contract C1 that the invoice chain 11 issues the invoice, the invoice chain 11 can issue the invoice by sending a transaction calling the Invoice() function of the main contract C1. If it is determined that the device D1 is issued based on the account status of the main contract C1, the device D1 can be connected through the interface of the device D1 provided by the invoice chain 11 to issue the invoice through the device D1.

After the device D1 issues an invoice, it can send a transaction to the invoice chain 11 through its client, wherein in the transaction, the communication contract C2 is called with at least one invoice as an incoming parameter, and the main contract C1 is called in the communication contract C2, so that the At least one invoice is provided to the main contract C1 in the invoice chain 11 . After acquiring the at least one invoice, the main contract C1 can deposit the at least one invoice into its account status for use in the subsequent invoice business.

The above-mentioned ticket processing process will be described in detail below.

FIG. 2 shows a flowchart of a method for invoicing through an off-chain device according to an embodiment of the present specification.

As shown in FIG. 2 , the method is executed jointly by the node P2 in the invoice chain 11 and the off-chain device D1, for example. As mentioned above, the main contract C1 in the invoice chain 11 can issue invoices by itself, and can also issue invoices through off-chain devices by invoking the communication contract C2. The invoice chain 11 can use the off-chain device for billing processing by opening the connection with the off-chain device (for example, the connection with the off-chain device D1) during peak business hours, so that a faster bill processing speed can be achieved. After the business peak period, the transaction volume drops, and the invoice chain 11 itself can execute each transaction and complete the invoicing in a timely manner, that is, the off-chain equipment is no longer required, and thus the use of the off-chain equipment can be terminated. The individual steps in the method will be described in detail below.

First, in step S202, node P2 locks the invoice number segment (eg, 1-1000) by executing transaction 1.

Invoice Chain 11 can set the use of off-chain device clusters based on business peak hours. For example, for the Double Eleven period, it can be set to open the connection with each device in the off-chain device cluster before 0:00 on November 11, and on November 11. The said connection is disconnected at 24:00 on May 11 to end the use of the off-chain device.

After the invoice chain 11 establishes the connection with the off-chain device, the nodes in the invoice chain 11 can send transaction 1 to the invoice chain 11 to assign the invoice number segment to the off-chain device. In this transaction 1, the invoice number segment (for example, 1-1000) is used as the incoming parameter to call the dispatch function (Assign()) in the main contract C1, so that the invoice with the invoice number of 1-1000 is allocated to the off-chain device cluster 12 is processed. FIG. 3 shows a schematic diagram of transaction 1 (Tx1) according to an embodiment of the present specification. As shown in Figure 3, the transaction 1 is sent by the node P1, which calls the dispatch function (Assign(a, b)) in the main contract C1 (Main), where a is the starting number parameter of the invoice number segment, and b is the invoice The last number parameter of the number segment is called with "1,1000" as the incoming parameter when calling the ticket dispatch function, which means that 1 is assigned to a and 1000 is assigned to b.

When executing the Assign function in the main contract C1 in the transaction 1, the node P2 first allocates the invoice number 1-1000 to multiple off-chain devices according to a predetermined allocation rule. In one embodiment, the predetermined allocation rule is to allocate based on the range of the invoice number segment of the invoice, for example, assign the ticket with the value after the invoice number modulo 100 less than 20 to the device D1, and assign the value after the invoice number modulo 100 to the device D1. Between 20-40 tickets are allocated to device D2 and so on. In one embodiment, the predetermined allocation rule is based on the merchant name of the invoice (that is, the invoicing unit). The invoice number corresponding to the invoicing unit of the flow is assigned to device D2, and so on. It can be understood that the allocation rules are not limited to the above two allocation rules, and can also be allocated based on the invoice number based on other algorithms, or can also be allocated based on other fields in the invoice (such as commodity names, etc.), which are not limited here.

FIG. 4 shows a table of invoice information including respective invoice numbers recorded in the account status of the main contract C1. As shown in FIG. 4 , after distributing the invoice number segment 1-500 to the merchant 1 as described above, the invoice chain 11 may record in the table shown in FIG. 4 : the merchant with the invoice number 1-500 is the merchant 1 (User1 ), it is also recorded in FIG. 4 that the merchant corresponding to the invoice number 501-1000 is merchant 2 (User2). For example, in the Assign function of the main contract C1, it is set that the corresponding merchant based on the invoice number will be allocated to the off-chain device. The invoice number of 2 is assigned to device D2. Therefore, when executing the Assign function of the main contract C1 in the transaction 1, the merchants corresponding to the invoice numbers 1-1000 are first determined based on the table shown in FIG. After 1000 corresponds to Merchant 2, assign invoice numbers 1-500 to Device D1 (Device1), assign invoice numbers 501-1000 to Device D2 (Device2), and check each item in the invoice status in the table shown in Figure 4. The invoice number is recorded with the corresponding device identifier to indicate that the invoice number is waiting for the corresponding off-chain device to issue, that is, these invoice numbers are locked so that the invoice chain 11 will not issue the invoices corresponding to these invoice numbers. . In addition, as shown in Figure 4, the invoice status corresponding to the invoice number 1001 is the invoice with the invoice number 1001 that has been issued, which means that the invoice has been issued by the invoice chain 11 or the off-chain device, and the invoice status corresponding to the invoice number 1002 is empty. Indicates that the invoice corresponding to the invoice number will be issued by the invoice chain 11 itself.

In step S204, the node P2 sends the dispatch information for the invoice number segment (eg 1-500) to the device D1 when the transaction 1 is executed.

As described above with reference to FIG. 1 , the data sending function (Data()) in the communication contract C2 is called in the main contract C1 in the transaction 1 with, for example, the device D1 identification and the invoice number segment 1-500 as incoming parameters. When node P2 executes transaction 1, after modifying the account status of the main contract C1 as described above, it executes the communication contract C2, thereby storing the data in the blockchain 11 (that is, the ledger data of the blockchain 11 local to the node P2). Receipt 1 of transaction 1, in which receipt 1 may include the account address of communication contract C2, the identification of device D1 and the invoice number field 1-500.

The device D1 can monitor the receipt in the invoice chain 11 including the account address of the communication contract C2 and the identification of the device D1, so that the information sent to it can be read from the invoice chain 11. For example, after reading receipt 1 and its proof data (eg Spv proof) from the invoice chain 11, the device D1 verifies the receipt 1 through the proof data, and then can read the invoice number segment 1-500 from the receipt 1, thereby It can be determined that the invoice chain 11 has assigned the invoice number segment 1-500 to the device D1.

It can be understood that although it is described in this step that the device D1 obtains the invoice number segment assigned to it by reading the receipt 1, the embodiment of the present specification is not limited thereto. For example, the device D1 can query the invoice number segment assigned to it from the table shown in FIG. 4 by reading the account status of the main contract C1. In addition, although it is described in this step that the information is sent to the device D1 by invoking the communication contract C2, this specification is not limited to this, and the information can be sent to the device D1 by any known means of sending information outside the chain, for example, it can be By executing a transaction that does not invoke the communication contract C2, a receipt including the identification of the device D1 and the assigned invoice number segment is deposited in the invoice chain 11 to send information to the device D1.

In step S206, the device D1 generates an invoice 1-400.

Referring to FIG. 1 again, after the merchant 1 receives the invoice number segment from the invoice chain 11, when it needs to issue an invoice for, for example, the invoice number 1, the merchant 1 first queries the invoice number 1 in the blockchain 11 through its user terminal 13. The invoice status of , that is, the account status of the main contract C1 is queried in the table shown in Figure 4, for example. After determining that the invoice status of the invoice number 1 is "Device1", the user terminal 13 connects to the connection interface provided by the invoice chain 11 to the device D1, thereby connecting with the device D1.

After establishing the connection with the device D1, the user terminal 13 sends the invoice information of the invoice number 1 to the device D1, which includes, for example, the invoice number, customer name, commodity name, and merchant name and other information.

After receiving the invoice information with the invoice number "1", the device D1 determines that the invoice number 1 is allocated to it by the invoice chain 11 for issuing, and then issues an invoice with the invoice number 1 based on the invoice information received from the user terminal 13. By the same process, device D1 issues, for example, invoice 1-400 before disconnecting from invoice chain 11 .

In step S208, device D1 sends transaction 2 to send invoice 1 - invoice 400 to invoice chain 11 .

After generating each of the invoices 1-400, the device D1 does not send each invoice back to the invoice chain 11 separately by sending a plurality of transactions, but can pass a transaction before the connection with the invoice chain 11 is disconnected. One-time send back to Invoice Chain 11. By doing this, for example, for 400 invoices, 400 invoices are provided to the invoice chain 11 at once through only 1 transaction, compared to sending 400 transactions back to the invoice chain 11 separately, which greatly reduces the number of invoices The number of transactions executed on the chain greatly improves the overall processing speed in the invoice chain.

For example, as mentioned above, during the Double Eleven period, it can be set to end the use of each off-chain device at 24:00 on November 11. Thus, device D1 determines before 24:00 on November 11 to stop invoicing after invoicing 400, and sends transaction 2 to invoice chain 11 (eg, node P2) to send invoices 1-400 processed by it to invoice chain 11 .

FIG. 5 shows a schematic diagram of transaction 2 (Tx2) according to an embodiment of the present specification. As shown in Figure 5, transaction 2 is sent by device D1 (Device1), which calls the result return function (Result()) in communication contract C2 (Layer2), and the return parameter to Result() is the invoice issued by device D1 1-400.

At step S210, node P2 executes transaction 2 to locally deposit invoice 1-400.

For example, the node P2 in the invoice chain 11 executes the result return function in the communication contract C2 when executing the above transaction 2 sent by the device D1. The result returning function includes a call to the receiving function (Receipt()) in the main contract C1, so that when Result() is executed, the Receipt() function in the main contract C1 is executed with the invoice 1-400 as the incoming parameter. When the Receipt() function is executed, in the table shown in Figure 4 in the account status in the main contract C1, the corresponding invoice is stored in the invoice status of the corresponding invoice number, for example, the invoice 1 is stored in the invoice number 1 in the invoice status.

In step S212, the device D1 sends transaction 3 to send connection pre-close information.

After the device D1 determines that it is about to disconnect from the invoice chain 11 as described above, and sends the invoice 1-400 it issued to the invoice chain 11, the device D1 may send the connection pre-close message by sending transaction 3.

FIG. 6 shows a schematic diagram of transaction 3 (Tx3) according to an embodiment of the present specification. As shown in Figure 6, transaction 3 is sent by device D1, and the disconnection function (Close()) in communication contract C2 (Layer2) is called. The disconnection function includes parameters c and d, where parameter c is device D1 The starting number of the number segment of the invoice issued, the parameter d is the end number of the number segment of the invoice issued by the device D1, the parameter "1" passed in to this function means assigning 1 to c, and the parameter "400" means assigning value to d 400.

In step S214, node P2 executes transaction 3 to determine whether all invoices sent by device D1 are received.

The communication contract C2 (Layer2) includes a call to the Check() function in the main contract C1 with the parameters c and d as the incoming parameters. Therefore, when the transaction 3 is executed, the main contract C1 is executed with 1 and 400 as the incoming parameters. Check() function in . When executing the Check() function, query the table shown in Figure 4 in the account status of the main contract C1, and determine whether the invoice status of each invoice number 1-400 has been stored in the issued invoice, if so, then It is determined that all the invoices sent by the device D1 have been received, and if the invoice status of at least one invoice number in the invoice numbers 1-400 is still "Device1", it is determined that all the invoices sent by the device D1 have not been received. In the event that it is determined that all invoices sent by device D1 have not been received, node P2 may re-receive said unreceived invoices from device D1 by sending a transaction to device D1 as described above by sending the invoice number of the unreceived invoice to device D1 bill.

In step S216, when the node P2 executes the transaction 3, it also unlocks the invoice status of the uninvoiced invoice number.

When the node P2 executes the Check function in the above-mentioned main contract C1, it can also determine that the invoice numbers 401-500 are the invoice numbers assigned to the device D1 but have not been processed based on the parameters 1 and 400 and the table shown in FIG. 4, so that the main The "Device1" in the invoice status of the invoice numbers 401-500 in the table shown in Figure 4 in the account status of the contract C1 is deleted, that is, the lock on the invoice numbers 401-500 is released, so that the invoice chain 11 can itself The issuance of invoices 401-500 is carried out.

After the above process, the node P2 can send the closing information to the device D1 by sending a transaction, so that the connection between the device D1 and the invoice chain 11 is disconnected, that is, the invoice chain 11 ends the use of the device D1. The invoice chain 11 can dispatch and receive invoices from the devices D2 and D3 shown in Figure 1 in the same way.

FIG. 7 shows an apparatus 700 for using off-chain trusted devices to process ticket data according to an embodiment of the present specification. The apparatus is deployed on a blockchain node, including:

The first execution unit 71 is configured to execute a first transaction, where the first transaction includes at least one ticket identifier, so as to assign the at least one ticket identifier to the first off-chain trusted device;

The second execution unit 72 is configured to execute a second transaction sent by the first off-chain trusted device, where the second transaction includes at least one ticket corresponding to the at least one ticket identifier, so as to obtain the at least one ticket.

In one embodiment, the first execution unit 71 is further configured to execute the first transaction so that at least one ticket identifier associated with the trusted device under the first chain is stored in the blockchain.

In one embodiment, the first contract is invoked in the first transaction, and bill information corresponding to each bill identifier is recorded in the account status of the first contract, wherein the first execution unit 71 is further configured to: The first contract is executed such that the assignment of the at least one ticket identification is recorded in the account state of the first contract.

In one embodiment, the first execution unit 71 is further configured to execute the first contract, so that the at least one ticket identifier is allocated to the first off-chain executable among the multiple off-chain trusted devices letter equipment.

In an embodiment, the first execution unit 71 is further configured to, based on the value range corresponding to the at least one ticket identifier, assign the at least one ticket identifier to the first one of the multiple off-chain trusted devices Off-chain trusted devices.

In one embodiment, the first execution unit 71 is further configured to, based on the identifier of the invoicing subject corresponding to the at least one ticket identifier, assign the at least one ticket identifier to a plurality of off-chain trusted devices Trusted devices off the first chain.

In one embodiment, the first contract is invoked in the second transaction, and the second execution unit 72 is further configured to execute the first contract, so that after acquiring the at least one ticket, execute the The at least one bill is stored in the bill information of the corresponding bill identifier in the account state of the first contract.

In one embodiment, the apparatus 700 further includes a third execution unit 73 configured to, after executing the second transaction, execute a third transaction, where the first contract is invoked in the third transaction, so that the Based on the ticket information of each ticket identifier, a first ticket identifier waiting to be processed by the first off-chain trusted device is determined, and allocation information is deleted from the ticket information of the first ticket identifier.

In an implementation manner, the second contract is invoked in the second transaction, and the first contract is invoked in the second contract, wherein the second execution unit 72 is further configured to execute the second contract , so that the at least one ticket is verified, and the verified at least one ticket is provided to the first contract.

In an embodiment, the first off-chain trusted device is a TEE device, and the second transaction further includes a signature of the TEE device on the at least one ticket, wherein the second execution unit 72 It is also configured to use the preset public key of the TEE device to verify the signature.

FIG. 8 shows an apparatus 800 for processing ticket data using an off-chain trusted device according to an embodiment of the present specification. The apparatus is deployed in a first off-chain trusted device, and includes: a first obtaining unit 81 configured to: Acquire at least one ticket identifier assigned to the trusted device under the first chain from the blockchain; the second acquiring unit 82 is configured to acquire at least one ticket information corresponding to the at least one ticket identifier respectively; the generating unit 83 is configured to to generate at least one ticket corresponding to the at least one ticket identifier based on the at least one ticket information; the sending unit 84 is configured to send a second transaction to the blockchain, where the second transaction includes all at least one ticket.

Another aspect of the present specification provides a computing device comprising a memory and a processor, wherein a computer program is stored in the memory, and the processor implements any one of the above methods when executing the computer program.

Each embodiment in this specification is described in a progressive manner, and the same and similar parts between the various embodiments may be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, as for the system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and for related parts, please refer to the partial descriptions of the method embodiments.

The foregoing describes specific embodiments of the present specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that in the embodiments and still achieve desirable results. Additionally, the processes depicted in the figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Those of ordinary skill in the art should further realize that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented by electronic hardware, computer software or a combination of the two, in order to clearly illustrate the hardware and software interchangeability, the components and steps of each example have been generally described in terms of functions in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Persons of ordinary skill in the art may use different methods of implementing the described functionality for each particular application, but such implementations should not be considered beyond the scope of this application. Wherein, the software module can be placed in random access memory (RAM), internal memory, read only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, or technical fields in any other form of storage medium known in the art.

The specific embodiments described above further describe the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above descriptions are only specific embodiments of the present invention, and are not intended to limit the scope of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

A method for bill data processing using off-chain trusted devices, the method being executed by a blockchain node, comprising:

executing a first transaction, where the first transaction includes at least one ticket identifier, so as to assign the at least one ticket identifier to the first off-chain trusted device;

Execute a second transaction sent by the first off-chain trusted device, where the second transaction includes at least one ticket corresponding to the at least one ticket identifier, to obtain the at least one ticket.
The method of claim 1, wherein performing the first transaction comprises performing the first transaction such that at least one ticket identification associated with the first off-chain trusted device is deposited in the blockchain.
The method according to claim 1 or 2, wherein a first contract is invoked in the first transaction, and bill information corresponding to each bill identifier is recorded in the account status of the first contract, wherein executing the first transaction includes: , executing the first contract such that the assignment of the at least one ticket identifier is recorded in the account state of the first contract.
4. The method of claim 3, wherein executing the first transaction further comprises executing the first contract such that the at least one ticket identifier is assigned to the first off-chain accessible one of the plurality of off-chain trusted devices letter equipment.
The method according to claim 4, wherein allocating the at least one ticket identifier to the first off-chain trusted device among the plurality of off-chain trusted devices comprises, based on the value range corresponding to the at least one ticket identifier, The at least one ticket identifier is allocated to a first off-chain trusted device among the plurality of off-chain trusted devices.
The method according to claim 4, wherein allocating the at least one ticket identifier to the first off-chain trusted device among the plurality of off-chain trusted devices comprises: based on the at least one ticket identifier corresponding to the billing subject's identifier, and assign the at least one ticket identifier to the first off-chain trusted device among the multiple off-chain trusted devices.
The method according to claim 3, wherein invoking the first contract in the second transaction, and executing the second transaction sent by the trusted device off the first chain further comprises executing the first contract, So that after the at least one bill is acquired, the at least one bill is stored in the bill information identified by the corresponding bill in the account state of the first contract.
The method according to claim 7, further comprising, after executing the second transaction, executing a third transaction, in which the first contract is called in the third transaction, so that the waiting list is determined based on the ticket information identified by each ticket. The first ticket identifier processed by the trusted device under the first chain is deleted, and the allocation information is deleted from the ticket information of the first ticket identifier.
The method of claim 3, wherein a second contract is invoked in the second transaction, and the first contract is invoked in the second contract, and wherein the execution of the transaction sent by the trusted device off the first chain is performed. The second transaction also includes executing the second contract such that the at least one ticket is verified, providing the verified at least one ticket to the first contract.
The method according to claim 9, wherein the first off-chain trusted device is a TEE device, and the second transaction further includes a signature of the TEE device on the at least one ticket, wherein the Verifying at least one ticket includes verifying the signature by using the preset public key of the TEE device.
A method for using off-chain trusted devices to process bill data, the method being performed by a first off-chain trusted device, comprising:

Obtain at least one ticket identifier assigned to the trusted device under the first chain from the blockchain;

acquiring at least one ticket information corresponding to the at least one ticket identifier;

generating at least one ticket corresponding to the at least one ticket identifier based on the at least one ticket information;

Sending a second transaction to the blockchain, the second transaction including the at least one ticket.
The method according to claim 11, wherein the first off-chain trusted device is a TEE device, and the second transaction further includes a signature of the TEE device on the at least one ticket.
A device for bill data processing using off-chain trusted equipment, the device is deployed on a blockchain node, including:

a first execution unit, configured to execute a first transaction, where the first transaction includes at least one ticket identifier, so as to assign the at least one ticket identifier to the first off-chain trusted device;

a second execution unit configured to execute a second transaction sent by the first off-chain trusted device, where the second transaction includes at least one ticket corresponding to the at least one ticket identifier, so as to obtain the at least one ticket.
The apparatus of claim 13, wherein the first execution unit is further configured to execute the first transaction such that at least one ticket identification associated with the first off-chain trusted device is deposited in the blockchain.
The device according to claim 13 or 14, wherein a first contract is invoked in the first transaction, and bill information corresponding to each bill identifier is recorded in the account status of the first contract, wherein the first execution The unit is further configured to execute the first contract such that the assignment of the at least one ticket identification is recorded in the account status of the first contract.
The apparatus of claim 15, wherein the first execution unit is further configured to execute the first contract such that the at least one ticket identifier is assigned to the first one of the plurality of off-chain trusted devices Off-chain trusted devices.
The apparatus according to claim 16, wherein the first execution unit is further configured to, based on the value range corresponding to the at least one ticket identifier, assign the at least one ticket identifier to a plurality of off-chain trusted devices The first off-chain trusted device.
The apparatus according to claim 16, wherein the first execution unit is further configured to, based on the identification of the invoicing subject corresponding to the at least one ticket identification, assign the at least one ticket identification to a plurality of off-chain trusted The first off-chain trusted device in the device.
The apparatus of claim 15, wherein the first contract is invoked in the second transaction, and the second execution unit is further configured to execute the first contract, so that the at least one ticket is acquired Afterwards, the at least one bill is stored in the bill information of the corresponding bill identifier in the account state of the first contract.
The apparatus according to claim 19, further comprising a third execution unit configured to, after executing the second transaction, execute a third transaction in which the first contract is invoked, so that the first contract is called based on the respective bills The identified ticket information, determine the first ticket identifier waiting to be processed by the first off-chain trusted device, and delete the allocation information from the ticket information of the first ticket identifier.
The apparatus of claim 15, wherein a second contract is called in the second transaction, and the first contract is called in the second contract, wherein the second execution unit is further configured to execute the A second contract, such that the at least one ticket is verified, provides the verified at least one ticket to the first contract.
The apparatus according to claim 21, wherein the first off-chain trusted device is a TEE device, and the second transaction further includes a signature of the TEE device on the at least one ticket, wherein the first The second execution unit is further configured to use the preset public key of the TEE device to verify the signature.
A device for processing bill data using off-chain trusted devices, the device is deployed on a first off-chain trusted device, including:

a first obtaining unit, configured to obtain at least one ticket identifier assigned to the trusted device under the first chain from the blockchain;

a second obtaining unit, configured to obtain at least one piece of bill information corresponding to the at least one bill identifier;

a generating unit, configured to generate at least one ticket corresponding to the at least one ticket identifier based on the at least one ticket information;

A sending unit, configured to send a second transaction to the blockchain, where the second transaction includes the at least one ticket.
The apparatus according to claim 23, wherein the first off-chain trusted device is a TEE device, and the second transaction further includes a signature of the TEE device on the at least one ticket.
A computer-readable storage medium on which computer programs or instructions are stored, which, when executed in a computer, cause the computer to perform the method of any one of claims 1 to 12.
A computing device, comprising a memory and a processor, wherein a computer program or instruction is stored in the memory, and the processor implements the method according to any one of claims 1 to 12 when executing the computer program or instruction .