WO2022206430A1 - Procédé et appareil de traitement de données de facture au moyen d'un dispositif de confiance hors chaîne - Google Patents

Procédé et appareil de traitement de données de facture au moyen d'un dispositif de confiance hors chaîne Download PDF

Info

Publication number
WO2022206430A1
WO2022206430A1 PCT/CN2022/081699 CN2022081699W WO2022206430A1 WO 2022206430 A1 WO2022206430 A1 WO 2022206430A1 CN 2022081699 W CN2022081699 W CN 2022081699W WO 2022206430 A1 WO2022206430 A1 WO 2022206430A1
Authority
WO
WIPO (PCT)
Prior art keywords
ticket
transaction
chain
contract
identifier
Prior art date
Application number
PCT/CN2022/081699
Other languages
English (en)
Chinese (zh)
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 WO2022206430A1 publication Critical patent/WO2022206430A1/fr

Links

Images

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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network

Definitions

  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the allocation information is deleted from the ticket information of the first ticket identifier.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 1 shows a schematic diagram of an invoicing system according to an embodiment of the present specification.
  • 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 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.
  • TEE Trusted Execution Environment
  • 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.
  • ledger data such as transactions, receipts, account status, etc.
  • proof data such as Spv proof
  • the device D1 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.
  • 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.
  • the invoice chain node for example, node P1
  • 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.
  • 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.
  • the predetermined invoice number segment eg, invoice number 1- 1000
  • the merchant 1 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.
  • 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 .
  • the main contract C1 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.
  • FIG. 2 shows a flowchart of a method for invoicing through an off-chain device according to an embodiment of the present specification.
  • the method is executed jointly by the node P2 in the invoice chain 11 and the off-chain device D1, for example.
  • 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.
  • 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.
  • 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.
  • FIG. 3 shows a schematic diagram of transaction 1 (Tx1) according to an embodiment of the present specification.
  • 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.
  • the node P2 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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. .
  • 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.
  • 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.
  • the invoice number segment eg 1-500
  • 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.
  • 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.
  • proof data eg Spv proof
  • 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.
  • 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.
  • 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.
  • step S206 the device D1 generates an invoice 1-400.
  • the merchant 1 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.
  • the user terminal 13 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.
  • the user terminal 13 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.
  • the device D1 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 .
  • step S208 device D1 sends transaction 2 to send invoice 1 - invoice 400 to invoice chain 11 .
  • the device D1 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.
  • 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.
  • each off-chain device 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 .
  • invoice chain 11 eg, node P2
  • FIG. 5 shows a schematic diagram of transaction 2 (Tx2) according to an embodiment of the present specification.
  • 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.
  • Device D1 Device1
  • Result() result return function
  • Communication contract C2 Layer2
  • node P2 executes transaction 2 to locally deposit invoice 1-400.
  • 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.
  • 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.
  • step S212 the device D1 sends transaction 3 to send connection pre-close information.
  • 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.
  • 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
  • the parameter "400” means assigning value to d 400.
  • 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 .
  • 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.
  • 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.
  • step S216 when the node P2 executes the transaction 3, it also unlocks the invoice status of the uninvoiced invoice number.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the first contract is invoked in the second transaction
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • RAM random access memory
  • ROM read only memory
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Marketing (AREA)
  • Signal Processing (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Les modes de réalisation de la présente invention concernent un procédé et un appareil de traitement de données de facture au moyen d'un dispositif de confiance hors chaîne. Le procédé est exécuté par un nœud de chaîne de blocs et consiste : à exécuter une première transaction, la première transaction comprenant au moins un identifiant de facture, afin d'attribuer ledit identifiant de facture à un premier dispositif de confiance hors chaîne ; à exécuter une seconde transaction envoyée par le premier dispositif de confiance hors chaîne, la seconde transaction comprenant au moins une facture correspondant respectivement audit identifiant de facture, afin d'acquérir ladite facture.
PCT/CN2022/081699 2021-03-30 2022-03-18 Procédé et appareil de traitement de données de facture au moyen d'un dispositif de confiance hors chaîne WO2022206430A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110339765.8A CN112801797A (zh) 2021-03-30 2021-03-30 使用链下可信设备进行票据数据处理的方法和装置
CN202110339765.8 2021-03-30

Publications (1)

Publication Number Publication Date
WO2022206430A1 true WO2022206430A1 (fr) 2022-10-06

Family

ID=75815981

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/081699 WO2022206430A1 (fr) 2021-03-30 2022-03-18 Procédé et appareil de traitement de données de facture au moyen d'un dispositif de confiance hors chaîne

Country Status (2)

Country Link
CN (1) CN112801797A (fr)
WO (1) WO2022206430A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112801797A (zh) * 2021-03-30 2021-05-14 支付宝(杭州)信息技术有限公司 使用链下可信设备进行票据数据处理的方法和装置
US12075269B2 (en) * 2021-09-13 2024-08-27 Guavus, Inc. Measuring QoE satisfaction in 5G networks or hybrid 5G networks

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109034924A (zh) * 2018-08-16 2018-12-18 腾讯科技（深圳）有限公司 电子票据生成方法、装置、存储介质和计算机设备
US20190340266A1 (en) * 2018-05-01 2019-11-07 International Business Machines Corporation Blockchain implementing cross-chain transactions
CN110458631A (zh) * 2019-07-31 2019-11-15 阿里巴巴集团控股有限公司 基于区块链的票据号码分配方法、装置及电子设备
CN110659906A (zh) * 2019-09-20 2020-01-07 腾讯科技（深圳）有限公司 票据信息处理方法、相关设备及介质
CN111585994A (zh) * 2020-04-27 2020-08-25 中国银行股份有限公司 一种数据处理方法及系统
CN112801797A (zh) * 2021-03-30 2021-05-14 支付宝(杭州)信息技术有限公司 使用链下可信设备进行票据数据处理的方法和装置

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108694669A (zh) * 2018-07-18 2018-10-23 矩阵元技术（深圳）有限公司 一种区块链智能合约实现方法及装置
CN110098938B (zh) * 2019-04-17 2022-05-20 上海寅坤科技发展有限公司 一种可信任委托式链下加速解决方法及系统
CN112235383B (zh) * 2020-10-09 2024-03-22 腾讯科技（深圳）有限公司 容器服务集群节点调度方法及装置、服务器、存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190340266A1 (en) * 2018-05-01 2019-11-07 International Business Machines Corporation Blockchain implementing cross-chain transactions
CN109034924A (zh) * 2018-08-16 2018-12-18 腾讯科技（深圳）有限公司 电子票据生成方法、装置、存储介质和计算机设备
CN110458631A (zh) * 2019-07-31 2019-11-15 阿里巴巴集团控股有限公司 基于区块链的票据号码分配方法、装置及电子设备
CN110659906A (zh) * 2019-09-20 2020-01-07 腾讯科技（深圳）有限公司 票据信息处理方法、相关设备及介质
CN111585994A (zh) * 2020-04-27 2020-08-25 中国银行股份有限公司 一种数据处理方法及系统
CN112801797A (zh) * 2021-03-30 2021-05-14 支付宝(杭州)信息技术有限公司 使用链下可信设备进行票据数据处理的方法和装置

Also Published As

Publication number Publication date
CN112801797A (zh) 2021-05-14

Similar Documents

Publication Publication Date Title
WO2022206430A1 (fr) Procédé et appareil de traitement de données de facture au moyen d'un dispositif de confiance hors chaîne
TWI734088B (zh) 基於區塊鏈的交易處理方法及裝置、電子設備
US11645649B2 (en) Resource transfer method and apparatus, storage medium, and computer device
TWI706278B (zh) 基於區塊鏈的交易處理方法及裝置、電子設備
CN104272259B (zh) 用于在事务中间件机器环境中支持基于版本的路由的系统和方法
TW202025045A (zh) 基於區塊鏈的發票報銷方法及裝置、電子設備
WO2020134575A1 (fr) Procédé et appareil d'attribution de ressources basés sur une chaîne de blocs, et dispositif électronique
CN110008665B (zh) 一种区块链的权限控制方法及装置
CN110474863A (zh) 微服务安全认证方法及装置
CN103369038B (zh) 平台即服务PaaS管理平台及方法
CN112764887A (zh) 事务请求的构建方法、处理方法、装置、设备和存储介质
WO2022206438A1 (fr) Procédé et appareil pour fournir un message inter-chaînes
US10326833B1 (en) Systems and method for processing request for network resources
WO2022206439A1 (fr) Procédé et appareil pour fournir un message à chaîne transversale
CN112529709A (zh) 一种基于多签技术的以太坊智能合约实现方法
CN110662210B (zh) 基于区块链的二次或多次手机号的识别方法、系统及设备
CN110851813B (zh) 身份验证方法、区块链系统的节点装置和区块链系统
US10846156B2 (en) Methods, devices and computer program products for managing software function
KR20200014121A (ko) 블록체인 서비스 제공 방법 및 시스템
CN112001800B (zh) 在区块链系统中进行业务处理的方法和装置
CN108989418A (zh) 一种混合云对象存储通用认证的资源额度方法
CN112017052B (zh) 在区块链中部署和调用合约的方法和装置
CN114372280A (zh) 一种基于多签智能合约的区块链业务执行方法及装置
CN112348524A (zh) 反欺诈决策方法、装置、设备及计算机存储介质
CN112907278B (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: 22778613

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: 22778613

Country of ref document: EP

Kind code of ref document: A1