WO2021017437A1 - 基于区块链的票据核销方法及装置、电子设备、存储介质 - Google Patents

基于区块链的票据核销方法及装置、电子设备、存储介质 Download PDF

Info

Publication number
WO2021017437A1
WO2021017437A1 PCT/CN2020/072136 CN2020072136W WO2021017437A1 WO 2021017437 A1 WO2021017437 A1 WO 2021017437A1 CN 2020072136 W CN2020072136 W CN 2020072136W WO 2021017437 A1 WO2021017437 A1 WO 2021017437A1
Authority
WO
WIPO (PCT)
Prior art keywords
bill
blockchain
electronic bill
amount
account
Prior art date
Application number
PCT/CN2020/072136
Other languages
English (en)
French (fr)
Inventor
杨雪清
青龙生
孙震
金戈
孟振中
楚俞
Original Assignee
创新先进技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 创新先进技术有限公司 filed Critical 创新先进技术有限公司
Priority to US16/783,075 priority Critical patent/US11049115B2/en
Publication of WO2021017437A1 publication Critical patent/WO2021017437A1/zh
Priority to US17/359,900 priority patent/US11429983B2/en

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
    • 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/10—Tax strategies

Definitions

  • One or more embodiments of this specification relate to the field of blockchain technology, and in particular to a method and device for verifying a bill based on a blockchain, an electronic device, and a storage medium.
  • Blockchain technology also known as distributed ledger technology, is an emerging technology in which several computing devices participate in "bookkeeping" and jointly maintain a complete distributed database. Because the blockchain technology has the characteristics of decentralization, openness and transparency, each computing device can participate in database records, and the rapid data synchronization between computing devices, the blockchain technology has been widely used in many fields. To apply.
  • one or more embodiments of this specification provide a blockchain-based bill verification method and device, electronic equipment, and storage medium.
  • a blockchain-based bill verification method is proposed, which is applied to a blockchain node; the method includes:
  • the blockchain includes a multi-level account used to maintain the electronic bill number segment
  • the method also includes:
  • the claim transaction including the account identifier of the account of the issuer;
  • the allocated electronic bill number is added to the blockchain account of the billing party.
  • the bill content of the target electronic bill includes the bill amount
  • the further verification of the legality of the bill content of the target electronic bill includes:
  • the blockchain node connects with the server of the electronic bill issuance supervisor through an oracle oracle machine;
  • the checking whether the bill amount of the target electronic bill matches the entry amount of the target electronic bill includes:
  • the obtaining a comparison result of the bill amount of the target electronic bill and the entry amount of the target electronic bill from the server of the billing supervisor through the oracle oracle machine includes:
  • a verification pass event for the bill number is generated to enable the
  • the server of the billing supervisor monitors the verification pass event, it compares the bill amount recorded in the verification pass event with the credited amount, and returns the comparison result through the oracle oracle machine.
  • the obtaining a comparison result of the bill amount of the target electronic bill and the entry amount of the target electronic bill from the server of the billing supervisor through the oracle oracle machine includes:
  • the oracle oracle machine sends a request for obtaining the result of the comparison between the bill amount and the entry amount to the server of the billing supervisor, so that the server of the billing supervisor will compare the bill amount with the Compare the entry amount of the target bill;
  • the blockchain is a consortium chain; the alliance members of the consortium chain include financial institutions at all levels that are supervisors of billing, and billing institutions that are billing parties.
  • a blockchain-based bill verification device which is applied to a blockchain node; the device includes:
  • the verification receiving unit receives the target transaction used for verification processing of the target electronic bill
  • the ticket number verification unit in response to the target transaction, calls the verification logic declared in the smart contract published on the blockchain, obtains the ticket number of the target electronic ticket, and verifies the ticket number and the Whether the electronic note number segment maintained in the blockchain account corresponding to the target electronic note is matched; wherein the electronic note number segment maintained in the blockchain account is allocated to the blockchain account for issuance The electronic bill number segment of the electronic bill;
  • the legitimacy verification unit if yes, further verifies the legitimacy of the bill content of the target electronic bill, and generates a verification completion event corresponding to the target electronic bill after the legitimacy verification is passed, and The completion event of the verification processing is posted to the blockchain for certification.
  • the blockchain includes a multi-level account used to maintain the electronic bill number segment
  • the device also includes:
  • the claim receiving unit receives the claim transaction sent by the issuer, the claim transaction includes the account identifier of the account of the issuer;
  • the allocation unit in response to the claim transaction, calls the number claim logic declared in the smart contract published on the blockchain, determines the upper-level account of the blockchain account corresponding to the account identifier, and Allocate an electronic bill number to the billing party from the electronic bill number segment maintained by the upper-level account;
  • the allocated electronic bill number is added to the blockchain account of the billing party.
  • the bill content of the target electronic bill includes the bill amount
  • the legality verification unit is specifically configured to:
  • the blockchain node connects with the server of the electronic bill issuance supervisor through an oracle oracle machine;
  • the legality checking unit is further used for:
  • the legality checking unit is further configured to:
  • a verification pass event for the bill number is generated to enable the
  • the server of the billing supervisor monitors the verification pass event, it compares the bill amount recorded in the verification pass event with the credited amount, and returns the comparison result through the oracle oracle machine.
  • the legality checking unit is further configured to:
  • the oracle oracle machine sends a request for obtaining the result of the comparison between the bill amount and the entry amount to the server of the billing supervisor, so that the server of the billing supervisor will compare the bill amount with the Compare the entry amount of the target bill;
  • the blockchain is a consortium chain; the alliance members of the consortium chain include financial institutions at all levels that are supervisors of billing, and billing institutions that are billing parties.
  • an electronic device including:
  • a memory for storing processor executable instructions
  • the processor executes the executable instruction to implement the blockchain-based bill verification method described in any of the foregoing embodiments.
  • a computer-readable storage medium having computer instructions stored thereon, and when the instructions are executed by a processor, the blockchain-based bill core as described in any of the above embodiments is implemented. The steps of the pin method.
  • the electronic bill number segment is pre-maintained on the blockchain for the blockchain account to claim the bill number, and each blockchain account can use the received bill number to issue an electronic bill number. bill.
  • the bill number of the target electronic bill is verified by calling the smart contract with the electronic bill number maintained in the blockchain account corresponding to the issuer of the target electronic bill Whether the segments match or not can avoid the verification of forged electronic bills by the verification initiator. Further, when the bill number passes the verification, the legality of the bill content of the target electronic bill is verified through the smart contract, so that the target electronic bill can be fully verified.
  • Fig. 1 is a schematic diagram of creating a smart contract according to an exemplary embodiment
  • Fig. 2 is a schematic diagram of invoking a smart contract provided by an exemplary embodiment
  • Fig. 3 is a schematic diagram of creating a smart contract and invoking a smart contract provided by an exemplary embodiment
  • FIG. 4 is a flowchart of a method for verifying and canceling a bill based on a blockchain according to an exemplary embodiment
  • Figure 5 is a schematic diagram of the overall architecture of a blockchain-based bill verification solution provided by an exemplary embodiment
  • Fig. 6 is an interactive diagram of applying for an electronic bill number according to an exemplary embodiment
  • FIG. 7 is a schematic diagram of distributing and issuing electronic bill numbers according to an exemplary embodiment
  • Fig. 8 is an interactive diagram of verifying electronic bills according to an exemplary embodiment
  • Fig. 9 is a schematic structural diagram of a device provided by an exemplary embodiment.
  • Fig. 10 is a block diagram of a block chain-based bill verification device provided by an exemplary embodiment.
  • the steps of the corresponding method may not be executed in the order shown and described in this specification.
  • the method includes more or fewer steps than described in this specification.
  • a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step in other embodiments. description.
  • Blockchain is generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain. In addition, there can also be a combination of the above types, such as private chain + alliance chain, alliance chain + public chain, etc.
  • the public chain is represented by Bitcoin and Ethereum. Participants who join the public chain (also known as nodes in the blockchain) can read the data records on the chain, participate in transactions, and compete for the accounting rights of new blocks, etc. . Moreover, each node can freely join or exit the network and perform related operations.
  • the private chain is the opposite.
  • the write permission of the network is controlled by an organization or institution, and the data read permission is regulated by the organization.
  • a private chain can be a weakly centralized system with strict restrictions on nodes and a small number of nodes. This type of blockchain is more suitable for internal use by specific institutions.
  • the alliance chain is a block chain between the public chain and the private chain, which can achieve "partial decentralization".
  • Each node in the alliance chain usually has a corresponding entity or organization; nodes are authorized to join the network and form a stakeholder alliance to jointly maintain the operation of the blockchain.
  • the blockchain is usually composed of several blocks.
  • a time stamp corresponding to the creation time of the block is recorded in these blocks, and all the blocks strictly follow the time stamp recorded in the block to form a time-ordered data chain.
  • the real data generated in the physical world it can be constructed into a standard transaction format supported by the blockchain, and then published to the blockchain, and the node devices in the blockchain will perform consensus processing on the received transactions , And after reaching a consensus, the node device as the accounting node in the block chain will package the transaction into the block and carry out persistent storage in the block chain.
  • the consensus algorithms supported in the blockchain can include:
  • the first type of consensus algorithm that is, the consensus algorithm that node devices need to compete for the accounting right of each round of accounting cycle; for example, Proof of Work (POW), Proof of Stake (POS), appointment Consensus algorithms such as Delegated Proof of Stake (DPOS);
  • POW Proof of Work
  • POS Proof of Stake
  • DPOS Delegated Proof of Stake
  • the second type of consensus algorithm is a consensus algorithm that pre-selects accounting nodes for each round of accounting cycles (without competing for accounting rights); for example, consensus algorithms such as Practical Byzantine Fault Tolerance (PBFT) are used.
  • PBFT Practical Byzantine Fault Tolerance
  • all node devices that compete for the right to bookkeeping can execute the transaction after receiving the transaction.
  • one node device may win this round of contention for the right to bookkeeping and become the bookkeeping node.
  • the accounting node can package the received transaction with other transactions to generate the latest block, and send the generated latest block or the block header of the latest block to other node devices for consensus.
  • the node device with the right to book accounts has been agreed before this round of bookkeeping. Therefore, after the node device receives the transaction, if it is not the billing node of the current round, it can send the transaction to the billing node. For this round of billing nodes, the transaction can be executed during or before the process of packaging the transaction with other transactions to generate the latest block. After the accounting node generates the latest block, it can send the latest block or the block header of the latest block to other node devices for consensus.
  • the accounting node in this round can package the received transaction to generate the latest block, and the generated latest block or the latest block
  • the header of the block is sent to other node devices for consensus verification. If other node devices receive the latest block or the block header of the latest block, and there is no problem after verification, the latest block can be appended to the end of the original blockchain to complete the blockchain accounting process. In the process of verifying the new block or block header sent by the accounting node, other nodes can also execute the transactions contained in the block.
  • an important concept is Account; taking Ethereum as an example, Ethereum usually divides accounts into external accounts and contract accounts; external accounts are accounts directly controlled by users, also called It is a user account; and a contract account is an account created by a user through an external account and contains the contract code (ie smart contract).
  • Ethereum usually divides accounts into external accounts and contract accounts; external accounts are accounts directly controlled by users, also called It is a user account; and a contract account is an account created by a user through an external account and contains the contract code (ie smart contract).
  • the account types supported by the blockchain can also be further extended, which is not particularly limited in this specification.
  • a structure is usually used to maintain the account status of the account.
  • the state of the account related to the transaction in the blockchain usually changes.
  • the structure of an account usually includes fields such as Balance, Nonce, Code, and Storage. among them:
  • the Balance field is used to maintain the current account balance of the account
  • the Nonce field is used to maintain the number of transactions of the account; it is a counter used to ensure that each transaction can be processed and can only be processed once, effectively avoiding replay attacks;
  • the Code field is used to maintain the contract code of the account; in practical applications, the Code field usually only maintains the hash value of the contract code; therefore, the Code field is usually also called the Codehash field.
  • the Storage field is used to maintain the storage content of the account (the default field value is empty); for contract accounts, an independent storage space is usually allocated to store the storage content of the contract account; the independent storage space is usually Call it the account storage of the contract account.
  • the storage content of the contract account is usually constructed as an MPT (Merkle Patricia Trie) tree and the data structure is stored in the above independent storage space; among them, the MPT tree constructed based on the storage content of the contract account is usually also called the Storage tree .
  • the Storage field usually only maintains the root node of the Storage tree; therefore, the Storage field is usually also called the StorageRoot field.
  • the field values of the Code field and the Storage field shown above are all null values.
  • Merkle trees are usually used; or, based on the Merkle tree data structure, to store and maintain data.
  • Ethereum uses the MPT tree (a variant of Merkle tree) as a form of data organization to organize and manage important data such as account status and transaction information.
  • Smart contracts on the blockchain are contracts that can be triggered and executed by transactions on the blockchain. Smart contracts can be defined in the form of codes.
  • Ethereum Taking Ethereum as an example, it supports users to create and call some complex logic in the Ethereum network.
  • Ethereum is a programmable blockchain, and its core is the Ethereum Virtual Machine (EVM).
  • EVM Ethereum Virtual Machine
  • Each Ethereum node can run the EVM.
  • EVM is a Turing complete virtual machine, through which various complex logic can be realized.
  • Users publish and call smart contracts in Ethereum run on the EVM.
  • the EVM directly runs virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode”), so the smart contract deployed on the blockchain can be bytecode.
  • bytecode virtual machine code
  • each node can execute the transaction in the EVM.
  • the From field of the transaction in Figure 1 is used to record the address of the account that initiated the creation of the smart contract
  • the contract code saved in the field value of the Data field of the transaction can be bytecode
  • the field value of the To field of the transaction is a null( Empty) account.
  • a contract account corresponding to the smart contract appears on the blockchain and has a specific address; for example, "0x68e12cf284" in each node in Figure 1 represents the address of the created contract account ; Contract code (Code) and account storage (Storage) will be stored in the account storage of the contract account.
  • the behavior of the smart contract is controlled by the contract code, and the account storage of the smart contract saves the state of the contract.
  • smart contracts enable virtual accounts containing contract codes and account storage to be generated on the blockchain.
  • the Data field containing the transaction for creating the smart contract can store the bytecode of the smart contract.
  • the bytecode consists of a series of bytes, and each byte can identify an operation.
  • developers can choose a high-level language to write smart contract code instead of directly writing bytecode.
  • high-level languages such as Solidity, Serpent, LLL, etc. can be used.
  • smart contract code written in a high-level language it can be compiled by a compiler to generate bytecode that can be deployed on the blockchain.
  • the contract code written with it is very similar to the class in the object-oriented programming language.
  • a variety of members can be declared in a contract, including state variables, functions, function modifiers, and events.
  • State variables are values permanently stored in the storage (Storage) field of the smart contract and are used to save the state of the contract.
  • each node can execute the transaction in the EVM.
  • the From field of the transaction in Figure 2 is used to record the address of the account that initiated the invocation of the smart contract
  • the To field is used to record the address of the smart contract being called
  • the Data field of the transaction is used to record the method and parameters of invoking the smart contract.
  • the account status of the contract account may change. Later, a certain client can view the account status of the contract account through the connected blockchain node (for example, node 1 in Figure 2).
  • Smart contracts can be independently executed on each node in the blockchain network in a prescribed manner. All execution records and data are stored on the blockchain, so when such transactions are executed, the blockchain cannot be saved. Falsified, non-lost transaction vouchers.
  • FIG. 3 The schematic diagram of creating and calling smart contracts is shown in Figure 3.
  • To create a smart contract in Ethereum it needs to go through the process of writing a smart contract, turning it into bytecode, and deploying it to the blockchain.
  • Invoking a smart contract in Ethereum is to initiate a transaction pointing to a smart contract address.
  • the EVM of each node can execute the transaction separately, and the smart contract code can be distributed in the virtual machine of each node in the Ethereum network.
  • the traditional blockchain model represented by Ethereum usually supports the conversion of real-world currencies into virtual tokens that can be circulated on the chain in order to achieve "value transfer” on the blockchain.
  • the conversion of physical assets with non-monetary attributes in the real world into virtual assets on the blockchain usually refers to "anchoring" the physical assets with virtual assets on the blockchain, as The value support of these virtual assets, in turn, produces a process of virtual assets that match the value of physical assets on the blockchain and can circulate between blockchain accounts on the blockchain.
  • the account types supported by the blockchain can be expanded.
  • an asset account also called an asset object
  • an asset account is expanded; the expanded asset account means that non-monetary physical assets in the real world can be used as value support and can be used in the blockchain Virtual assets circulating between accounts.
  • a value matching the real-world non-monetary physical assets can be created on the blockchain.
  • virtual assets circulate on the blockchain;
  • users can convert non-monetary physical assets such as real estate, stocks, loan contracts, bills, accounts receivable, etc., into virtual assets with matching value to circulate on the blockchain.
  • non-monetary physical assets such as real estate, stocks, loan contracts, bills, accounts receivable, etc.
  • a structure can also be used to maintain the account status of the account.
  • the content contained in the structure of the above asset account can be the same as that of Ethereum, of course, it can also be designed based on actual needs;
  • the structure of the asset account may also include the fields of Balance, Nonce, Code, and Storage described above.
  • the Balance field is usually used to maintain the current account balance of the account; and for the blockchain model derived from the Ethereum architecture, it may not support real-world Currency is converted into virtual tokens that can be circulated on the chain. Therefore, in this type of blockchain, the meaning of the Balance field can be expanded. It no longer represents the "balance" of the account, but is used to maintain the "balance” of the account.
  • the address information of the asset account corresponding to the virtual asset Among them, in practical applications, the Balance field can maintain address information of asset accounts corresponding to multiple “virtual assets”.
  • the external accounts, contract accounts and asset accounts shown above can all be held by adding the address information of the asset account corresponding to the "virtual asset" that needs to be held in the Balance field to hold this virtual asset . That is, in addition to external accounts and contract accounts, the asset account itself can also hold virtual assets.
  • the field value of the Nonce and Code fields can be empty (or not empty); the field value of the Storage field can no longer be empty; the Storage field can be used to maintain the corresponding asset account
  • the specific method of maintaining the asset status of the "virtual asset” corresponding to the asset account in the Storage field can be flexibly designed based on requirements, and will not be repeated.
  • users can create a virtual asset on the blockchain that matches the value of real-world non-monetary physical assets through the following implementation methods:
  • the transaction types supported by the blockchain can be expanded to expand a transaction for creating virtual assets; for example, the transaction types supported by Ethereum usually include ordinary transfer transactions and smart contract creation On the basis of the above three types of transactions, transactions and transactions that call smart contracts can be extended to create a virtual asset transaction.
  • the user can post a transaction for creating virtual assets to the blockchain network through the client, and the node device in the blockchain will execute the transaction in the local EVM to provide the user with Create virtual assets.
  • the virtual asset is successfully created, and an asset account corresponding to the virtual asset appears on the blockchain and has a specific address.
  • a smart contract for creating virtual assets can also be deployed on the blockchain; wherein, the process of deploying a smart contract for creating virtual assets will not be repeated.
  • the user can publish a transaction for invoking the smart contract to the blockchain network through the client, and the node device in the blockchain will execute the transaction in the local EVM, and the transaction will be executed in the EVM.
  • multiple blockchains can achieve cross-chain docking through cross-chain relays.
  • the cross-chain relay can be connected to multiple blockchains through the bridge interface, and based on the implemented data handling logic, the synchronization of the cross-chain data between the multiple blockchains can be completed.
  • cross-chain technology used in the implementation of the above-mentioned cross-chain relay is not particularly limited in this specification; for example, in practical applications, cross-chain mechanisms such as side-chain technology and notary technology can be used to combine multiple blocks The chains are connected.
  • the blockchains can read and authenticate data on other blockchains, and they can also call deployments on other blockchains through cross-chain relays. Smart contract.
  • the smart contracts deployed on the blockchain can not only use the data stored on the blockchain, but also use the Oracle oracle to reference data on data entities outside the chain, thereby realizing smart contracts and real-world data entities Data exchange between.
  • Data entities outside the chain may include centralized servers or data centers deployed outside the chain, and so on.
  • Oracle Oracle unlike cross-chain relay, the function of Oracle Oracle is not to synchronize data on one blockchain to another blockchain, but to synchronize data on data entities outside the chain to blocks.
  • the function of Oracle Oracle is not to synchronize data on one blockchain to another blockchain, but to synchronize data on data entities outside the chain to blocks.
  • the cross-chain relay is used to connect two blockchains
  • the Oracle oracle is used to connect the blockchain with data entities outside the chain to realize the data interaction between the blockchain and the real world.
  • FIG. 4 is a flowchart of a method for verifying and canceling a bill based on a blockchain according to an exemplary embodiment. As shown in Figure 4, this method is applied to blockchain nodes and can include the following steps:
  • Step 402 Receive a target transaction for verifying the target electronic bill.
  • the financial institution can create multi-level accounts in advance, and configure the corresponding electronic bill number segments for the accounts at all levels for the billing institutions under the accounts at all levels to issue electronic bills; in other words, the electronic bill number and the electronic bill There is a "one-to-one correspondence" relationship.
  • multi-level accounts can be established according to "provincial department, municipal level, district/county", and the province’s fiscal account will pre-configure the province’s electronic bill number segments, and then allocate the configured electronic bill number segments to each city. After the corresponding electronic bill number segment is applied to the municipal fiscal account, the electronic bill number segment is allocated to the district/county fiscal account.
  • the issuing party can obtain the electronic bill number by applying to the higher-level account.
  • the blockchain contains a multi-level account for maintaining the electronic bill number segment, and the billing party can package a claim transaction (including the account identification of the billing party’s account) and send it to the blockchain node Send the claim transaction to obtain the electronic note number.
  • the blockchain node After the blockchain node receives the claim transaction sent by the issuer, it can respond to the claim transaction and call the number claim logic declared in the smart contract published on the blockchain to determine the area corresponding to the account identifier.
  • the upper-level account of the blockchain account, and the electronic note number is allocated to the issuer from the electronic note number segment maintained by the upper-level account; and the assigned electronic note number is added to the blockchain account of the issuer.
  • the billing party is a municipal-level billing institution
  • the corresponding upper-level account is the blockchain account of the provincial financial institution.
  • the ticket-using institutions under the accounts at all levels can apply for the electronic note number through the financial institution at the level to which they belong, and the financial institution at the corresponding level will return the electronic note number.
  • the blockchain account of the municipal financial institution can apply for the electronic bill number segment from the blockchain account of the provincial financial institution, and then allocate the electronic bill number segment to the municipal billing institutions.
  • the electronic bill can be issued offline by the issuer, and after issuance, the issuer will publish it to the blockchain for deposit.
  • the smart contract for issuing electronic invoices using electronic bills can be pre-released on the blockchain, and the electronic bill numbers applied by each issuer can be published on the blockchain for deposit. Then, after calling the smart contract to issue an electronic bill, the issued electronic bill can be published on the blockchain for certification.
  • the billing party or the billing supervisor of the electronic bill can initiate the verification operation of the electronic bill.
  • a target transaction for the verification of the target electronic bill can be packaged, and the target transaction contains the bill identification of the target electronic bill; among them, the bill code, check code, etc. can be used as the bill identification, and The bill number can be directly used as the bill identification.
  • Step 404 In response to the target transaction, call the verification logic declared in the smart contract published on the blockchain to obtain the bill number of the target electronic bill, and verify the bill number and the target electronic bill Whether the electronic note number segment maintained in the blockchain account corresponding to the issuing party matches; wherein the electronic note number segment maintained in the blockchain account is the one assigned to the blockchain account for issuing electronic notes Electronic bill number segment.
  • the verification of the electronic note number can be used to prevent the initiating party from writing off The issue of the verification of counterfeit electronic bills.
  • Step 406 If yes, further verify the legality of the bill content of the target electronic bill, and generate a verification completion event corresponding to the target electronic bill after the legality verification is passed, and verify the verification
  • the sales processing completion event is posted to the blockchain for certification.
  • the bill content can be bill details, bill amount, etc.
  • the entry amount is maintained by the billing supervisor.
  • the billing supervisor can be a financial institution at all levels. When an electronic bill is issued, the financial institution at all levels is the bill entry party.
  • the blockchain node can connect with the server of the electronic bill issuance supervisor through the oracle oracle machine, so the blockchain node can obtain the bill amount and target electronic bill of the target electronic bill from the server of the invoicing supervisor through the oracle oracle machine.
  • the comparison result of the bill entry amount when the obtained comparison result is that the bill amount is consistent with the entry amount, it can be determined that the bill amount matches the entry amount.
  • the blockchain node can interact with the server of the billing supervisor through an event mechanism. For example, after verifying that the bill number matches the electronic bill number segment maintained in the blockchain account corresponding to the issuer of the target electronic bill, the blockchain node can generate a verification pass event for the bill number (including the target The bill amount of the electronic bill), so that when the server of the billing supervisor monitors the verification pass event, it compares the bill amount recorded in the verification pass event with the entry amount, and returns the comparison result through the oracle oracle machine.
  • an event mechanism For example, after verifying that the bill number matches the electronic bill number segment maintained in the blockchain account corresponding to the issuer of the target electronic bill, the blockchain node can generate a verification pass event for the bill number (including the target The bill amount of the electronic bill), so that when the server of the billing supervisor monitors the verification pass event, it compares the bill amount recorded in the verification pass event with the entry amount, and returns the comparison result through the oracle oracle machine.
  • the blockchain node can actively obtain data from the server of the billing supervisor through the oracle oracle machine. For example, the blockchain node sends an obtaining request for the comparison result of the bill amount of the target electronic bill and the entry amount to the server of the billing supervisor through the oracle oracle, so that the server of the billing supervisor can compare the bill amount with the target The entry amount of the bill is compared, and the comparison result is returned through the oracle oracle machine.
  • the blockchain in one or more embodiments of this specification may be a consortium chain.
  • the alliance members of the alliance chain include all levels of financial institutions as the billing supervisor and the billing institution as the billing party.
  • the types of requests initiated on the blockchain by users who access the blockchain may specifically refer to transactions used in traditional blockchains.
  • the type of request initiated on the blockchain by a user who accesses the blockchain can also be other than a transaction, other forms of instructions, messages, etc. with a standard data structure, one or more embodiments of this specification It is not particularly limited.
  • the request initiated on the blockchain by a user accessing the blockchain is taken as an example for description.
  • the electronic bill number segment is pre-maintained on the blockchain for the blockchain account to claim the bill number, and each blockchain account can use the received bill number to issue an electronic bill number. bill.
  • the bill number of the target electronic bill is verified by calling the smart contract with the electronic bill number maintained in the blockchain account corresponding to the issuer of the target electronic bill Whether the segments match or not can avoid the verification of forged electronic bills by the verification initiator. Further, when the bill number passes the verification, the legality of the bill content of the target electronic bill is verified through the smart contract, so that the target electronic bill can be fully verified.
  • FIG. 5 is a schematic diagram of the overall architecture of a blockchain-based bill verification solution provided by an exemplary embodiment.
  • a blockchain client is running on the server 52, so that the server 55 is configured as a blockchain node.
  • the verification initiator 50 can register an account at the server 52 through the client 51 in advance, and obtain a registered account uniquely corresponding to itself. Then, the verification initiator 50 can log in the registered account on the client 51, and the server 52 determines the registered account (corresponding to the verification initiator based on the login information of the registered account on the client 51). ) Establishes a binding relationship with the client 51.
  • the binding relationship that needs to be established is the binding relationship between the account information of the verification initiator 50 and the device information of the client 51. Based on the binding relationship, when the server 52 receives the target transaction subsequently sent by the client 51, it can confirm that the transaction corresponds to the verification initiator 50.
  • the verification initiator 50 can log in to the registered account on the client 51, package a target transaction for verification of the target electronic bill through the client 51, and send it to the server through the client 51 52.
  • the server 52 (as a blockchain node) calls the smart contract to verify the bill number and bill content of the target electronic bill after receiving the target transaction, and generates a write-off processing completion event after the verification is passed and publishes it to the blockchain Make a deposit.
  • Fig. 6 is an interactive diagram for applying for an electronic bill number according to an exemplary embodiment. As shown in Figure 6, the interaction process may include the following steps:
  • Step 602 the client of the billing party packs a claim transaction.
  • the issuer can package a claim transaction through the client to claim the ticket number for issuing electronic notes.
  • the claim transaction includes the account identifier of the billing party's account; for example, it is the registered account of the billing party.
  • Financial institutions can create multi-level accounts in advance, and configure corresponding electronic bill number segments for accounts at all levels for use by billing institutions under each lower-level account to issue electronic bills. In other words, there is a "one-to-one correspondence" relationship between the electronic bill number and the electronic bill.
  • Step 604 The client of the issuer sends a claim transaction to the blockchain node.
  • step 606 the blockchain node determines the upper-level account of the issuer.
  • multi-level accounts can be established according to "provincial department, municipal level, district/county"; among them, the provincial department is the upper-level account at the city level, and the city-level is the upper-level account at the district/county level.
  • step 608 the blockchain node assigns an electronic bill number to the issuer.
  • Step 610 Add the assigned electronic bill number to the blockchain account of the issuer.
  • the blockchain node can generate an event for recording the distribution result, so when the issuer client monitors the event, it can obtain the claim
  • the electronic bill number (it can be an electronic bill number or an electronic bill number segment).
  • the electronic bill number segment 00000001 ⁇ 99999999 is added to the blockchain account of the financial department of the provincial government for bill storage; among them, the electronic bill number segment 00000001 ⁇ 99999999 can be used as available inventory. It is divided into multiple electronic bill number segments and issued to the province and each city (the following are the names of each city, district/county to represent the corresponding blockchain account).
  • the electronic note number segment 00000001 ⁇ 50000001 is allocated to the provincial level, and the note number contained in the electronic note number segment 00000001-50000000 is used to distribute to various ticket institutions under the provincial level, and the remaining electronic note number segment 50000001 ⁇ 99999999 are used to distribute to various cities (Wenzhou, Taizhou, Hangzhou, etc.). Taking Taizhou as an example, the bill number segment 80000001 ⁇ 89999999 can be divided from the remaining electronic bill number segments for Taizhou to use.
  • one part can be distributed to the city-level use, and the other part can be distributed to the lower administrative districts (districts/counties) .
  • the electronic bill number segment 80000001 to 80999998 is used for distribution to the city level, while the remaining electronic bill number segment 80999999 to 83000000 is used for delivery to Sanmen County, and 8300001 to 83999999 is used for delivery to Linhai City.
  • the electronic note number segment (or electronic note number) applied for by accounts at all levels can be maintained in the structure of accounts at all levels.
  • the meaning of fields such as Balance, Nonce, Code and Storage can be expanded.
  • the Balance field is used to maintain the electronic note number segment that the account can distribute
  • the Storage field is used to maintain the electronic note number segment that the account can issue.
  • the Balance field is used to maintain the electronic bill number segment that the account can distribute
  • the Storage field is empty.
  • the Balance field is used to maintain the electronic note number segment that the account can issue
  • the Storage field is used to maintain the electronic note number segment that the account can issue.
  • the specific expansion mode of each field can be flexibly designed based on requirements, and one or more embodiments of this specification do not limit this.
  • the issuing party can use the electronic bill number to issue an electronic bill; among them, the electronic bill and the electronic bill number have a "one-to-one correspondence" relationship. Then, when the subsequent issuance party or the issuance supervisor verifies the electronic bill to be verified based on the electronic bill number, the verification of the forged electronic bill by the verification initiator can be avoided.
  • FIG. 8 is an interactive diagram for canceling electronic bills according to an exemplary embodiment. As shown in Figure 8, the interaction process may include the following steps:
  • Step 802 the blockchain node receives the verification transaction.
  • the members of the consortium chain can declare the verification logic in the smart contract to perform verification processing on the target electronic bill.
  • the members of the alliance chain can publish the smart contract to the alliance chain through any node device in the alliance chain, and the smart contract is designated by the member node device in the alliance chain. (For example, several authoritative node devices with accounting authority designated in the consortium chain) After the consensus is completed, the proof is stored in the block of the consortium chain.
  • the issuing party or the billing supervisor needs to write off the target electronic bill, it can be used as the write-off initiator to package a write-off transaction that includes the bill identification of the target electronic bill and the issuance of the target electronic bill
  • the account identification of the party's blockchain account among them, the bill code, check code, etc. can be used as the bill identification, or the bill number can be directly used as the bill identification.
  • Step 804 the blockchain node verifies the bill number of the target electronic bill.
  • the blockchain node after receiving the verification transaction, calls the verification logic declared in the smart contract published on the blockchain to obtain the bill number of the target electronic bill, and Check whether the bill number matches the electronic bill number segment maintained in the blockchain account corresponding to the issuer of the target electronic bill.
  • the blockchain node needs to first query the corresponding electronic bill (ie, the target electronic bill) stored on the blockchain according to the bill identifier. To read the ticket number.
  • the blockchain node can determine the electronic bill number segment maintained in the blockchain account of Linhai City (that is, the "distributable" electronic bill number segment maintained in the account) based on the account identifier contained in the verification transaction, and then determine the target Whether the bill number of the electronic bill belongs to the number segment of the electronic bill; if it belongs, the verification is passed.
  • the write-off initiator is a ticketing unit belonging to Linhai City
  • the electronic bill number range maintained by the blockchain account in Linhai City is 8300001-83999999
  • the bill number of the target electronic bill is 83001001 (belonging to the above electronic Note number segment)
  • the verification can be determined to pass.
  • Step 806 After the bill number is verified, the blockchain node sends to the oracle oracle a request for obtaining a comparison result between the bill amount of the target electronic bill and the credited amount.
  • the legality of the bill content of the target electronic bill can be further verified, so as to achieve a more comprehensive verification of the target electronic bill.
  • the bill content can be bill details, bill amount, etc.
  • the credit amount of the electronic bill is maintained by the billing supervisor.
  • the billing supervisor can be a financial institution at all levels.
  • the financial institution at all levels is the bill entry party. Therefore, the blockchain node can obtain the comparison result of the bill amount and the credited amount through the oracle oracle machine connected to the server of the billing supervisor.
  • step 808 the oracle oracle machine forwards the acquisition request to the billing supervisor.
  • Step 810 The billing supervisor compares the bill amount with the entered amount.
  • the acquisition request may include the bill ID and bill amount of the target electronic bill.
  • the billing supervisor reads the locally recorded amount of the target electronic bill according to the bill ID, compares it with the bill amount, and then passes the comparison result.
  • the oracle oracle machine returns to the blockchain node.
  • the acquisition request may include the bill identification of the target electronic bill
  • the billing supervisor reads the locally recorded amount of the target electronic bill according to the bill identification, and returns the comparison result to the blockchain node through the oracle oracle machine , To compare by blockchain nodes.
  • Step 812 the billing supervisor returns the comparison result to the oracle oracle machine.
  • step 814 the oracle oracle forwards the comparison result to the blockchain node.
  • step 816 when the result of the comparison is that the bill amount is consistent with the credited amount, the blockchain node generates a verification completion event.
  • the verification initiator when the verification initiator detects the verification completion event corresponding to the target electronic bill, it can be determined that the verification of the target electronic bill is completed. Further, the verification initiator may also maintain a state machine corresponding to the target electronic bill locally, and when it is determined that the verification of the target electronic bill is completed, the state machine is switched to the verification completion state.
  • this application also provides an embodiment of an apparatus.
  • this specification also provides an embodiment of a bill verification device based on blockchain.
  • the embodiment of the bill verification device based on blockchain in this specification can be applied to electronic equipment.
  • the device embodiments can be implemented by software, or by hardware or a combination of software and hardware. Taking software implementation as an example, as a logical device, it is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory through the processor of the electronic device where it is located.
  • FIG. 9 is a schematic structural diagram of a device provided by an exemplary embodiment.
  • the device includes a processor 902, an internal bus 904, a network interface 906, a memory 908, and a non-volatile memory 910, and of course, it may also include hardware required by other services.
  • the processor 902 reads the corresponding computer program from the non-volatile memory 910 to the memory 908 and then runs it to form a blockchain-based bill verification device on a logical level.
  • one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., which means that the execution body of the following processing flow is not limited to each
  • the logic unit can also be a hardware or logic device.
  • the blockchain-based bill verification device is applied to a blockchain node, and may include:
  • the verification receiving unit 1001 receives the target transaction used to perform verification processing on the target electronic bill
  • the ticket number verification unit 1002 in response to the target transaction, calls the verification logic declared in the smart contract published on the blockchain, obtains the ticket number of the target electronic ticket, and verifies the ticket number and the Whether the electronic note number segment maintained in the blockchain account corresponding to the target electronic note is matched; wherein, the electronic note number segment maintained in the blockchain account is the number segment that is allocated to the blockchain account The number segment of the electronic bill number for issuing electronic bills;
  • the legitimacy verification unit 1003 if yes, further verifies the legitimacy of the bill content of the target electronic bill, and generates a verification completion event corresponding to the target electronic bill after the legitimacy verification is passed, and Publish the verification process completion event to the blockchain for certification.
  • the blockchain includes a multi-level account used to maintain the electronic bill number segment
  • the device also includes:
  • the claim receiving unit 1004 receives the claim transaction sent by the issuer, where the claim transaction includes the account identifier of the account of the issuer;
  • the allocation unit 1005 in response to the claim transaction, calls the number claim logic declared in the smart contract published on the blockchain to determine the upper-level account of the blockchain account corresponding to the account identifier, And assign an electronic bill number to the billing party from the electronic bill number segment maintained by the upper-level account; and
  • the allocated electronic bill number is added to the blockchain account of the billing party.
  • the bill content of the target electronic bill includes the bill amount
  • the legality verification unit 1003 is specifically configured to:
  • the blockchain node connects with the server of the electronic bill issuance supervisor through an oracle oracle machine;
  • the legality checking unit 1003 is further configured to:
  • the legality checking unit 1003 is further configured to:
  • a verification pass event for the bill number is generated to enable the
  • the server of the billing supervisor monitors the verification pass event, it compares the bill amount recorded in the verification pass event with the credited amount, and returns the comparison result through the oracle oracle machine.
  • the legality checking unit 1003 is further configured to:
  • the oracle oracle machine sends a request for obtaining the result of the comparison between the bill amount and the entry amount to the server of the billing supervisor, so that the server of the billing supervisor will compare the bill amount with the Compare the entry amount of the target bill;
  • the blockchain is a consortium chain; the alliance members of the consortium chain include financial institutions at all levels that are supervisors of billing, and billing institutions that are billing parties.
  • a typical implementation device is a computer.
  • the specific form of the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, and a game control A console, a tablet computer, a wearable device, or a combination of any of these devices.
  • the computer includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.
  • processors CPU
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • the memory may include non-permanent memory in computer readable media, random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer readable media.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash memory
  • Computer-readable media include permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology.
  • the information can be computer-readable instructions, data structures, program modules, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical storage, Magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
  • first, second, third, etc. may be used in one or more embodiments of this specification to describe various information, the information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other.
  • first information may also be referred to as second information, and similarly, the second information may also be referred to as first information.
  • word “if” as used herein can be interpreted as "when” or “when” or "in response to determination”.

Abstract

一种基于区块链的票据核销方法，应用于区块链节点；该方法包括：接收用于对目标电子票据进行核销处理的目标交易（402）；响应于所述目标交易，调用发布在区块链上的智能合约中声明的核销逻辑，获取所述目标电子票据的票据号码，并校验所述票据号码与所述目标电子票据的开票方对应的区块链账户中维护的电子票据号段是否匹配；其中，所述区块链账户中维护的电子票据号段为分配至所述区块链账户的用于开具电子票据的电子票据号码号段（404）；如果是，进一步对所述目标电子票据的票据内容进行合法性校验，并在合法性校验通过后生成与所述目标电子票据对应的核销处理完成事件，以及将所述核销处理完成事件发布至所述区块链进行存证（406）。

Description

基于区块链的票据核销方法及装置、电子设备、存储介质 技术领域
本说明书一个或多个实施例涉及区块链技术领域，尤其涉及一种基于区块链的票据核销方法及装置、电子设备、存储介质。
背景技术
区块链技术，也被称之为分布式账本技术，是一种由若干台计算设备共同参与“记账”，共同维护一份完整的分布式数据库的新兴技术。由于区块链技术具有去中心化、公开透明、每台计算设备可以参与数据库记录、并且各计算设备之间可以快速的进行数据同步的特性，使得区块链技术已在众多的领域中广泛的进行应用。
发明内容
有鉴于此，本说明书一个或多个实施例提供一种基于区块链的票据核销方法及装置、电子设备、存储介质。
为实现上述目的，本说明书一个或多个实施例提供技术方案如下：
根据本说明书一个或多个实施例的第一方面，提出了一种基于区块链的票据核销方法，应用于区块链节点；所述方法包括：
接收用于对目标电子票据进行核销处理的目标交易；
响应于所述目标交易，调用发布在区块链上的智能合约中声明的核销逻辑，获取所述目标电子票据的票据号码，并校验所述票据号码与所述目标电子票据的开票方对应的区块链账户中维护的电子票据号段是否匹配；其中，所述区块链账户中维护的电子票据号段为分配至所述区块链账户的用于开具电子票据的电子票据号码号段；
如果是，进一步对所述目标电子票据的票据内容进行合法性校验，并在合法性校验通过后生成与所述目标电子票据对应的核销处理完成事件，以及将所述核销处理完成事件发布至所述区块链进行存证。
可选的，所述区块链包含用于维护电子票据号段的多级账户；
所述方法还包括：
接收开票方发送的申领交易，所述申领交易中包含所述开票方账户的账户标识；
响应于所述申领交易，调用发布在所述区块链上的智能合约中声明的号码申领逻辑，确定与所述账户标识对应的区块链账户的上一级账户，并从所述上一级账户维护的电子票据号段中为所述开票方分配电子票据号码；以及
将所分配的电子票据号码添加至所述开票方的区块链账户中。
可选的，所述目标电子票据的票据内容包括票据金额，所述进一步对所述目标电子票据的票据内容进行合法性校验，包括：
校验所述目标电子票据的票据金额是否与所述目标电子票据的入账金额相匹配；
如果是，确定合法性校验通过。
可选的，所述区块链节点通过oracle预言机与电子票据的开票监管方的服务端对接；
所述校验所述目标电子票据的票据金额是否与所述目标电子票据的入账金额相匹配，包括：
通过所述oracle预言机从所述开票监管方的服务端中获取所述目标电子票据的票据金额和所述目标电子票据的入账金额的比较结果；
当得到的比较结果为所述票据金额与所述入账金额一致时，确定所述票据金额与所述入账金额相匹配。
可选的，所述通过所述oracle预言机从所述开票监管方的服务端中获取所述目标电子票据的票据金额和所述目标电子票据的入账金额的比较结果，包括：
在校验出所述票据号码与所述目标电子票据的开票方对应的区块链账户中维护的电子票据号段相匹配后，生成针对所述票据号码的校验通过事件，以使所述开票监管方的服务端在监听到所述校验通过事件时，将所述校验通过事件中记录的所述票据金额与所述入账金额进行比较，并通过所述oracle预言机返回比较结果。
可选的，所述通过所述oracle预言机从所述开票监管方的服务端中获取所述目标电子票据的票据金额和所述目标电子票据的入账金额的比较结果，包括：
通过所述oracle预言机向所述开票监管方的服务端发送针对所述票据金额与所述入账金额的比较结果的获取请求，以使所述开票监管方的服务端将所述票据金额与所述目标票据的入账金额进行比较；
接收所述开票监管方的服务端通过所述oracle预言机返回的比较结果。
可选的，所述区块链为联盟链；所述联盟链的联盟成员包括作为开票监管方的各级财政机构、作为开票方的用票机构。
根据本说明书一个或多个实施例的第二方面，提出了一种基于区块链的票据核销装置，应用于区块链节点；所述装置包括：
核销接收单元，接收用于对目标电子票据进行核销处理的目标交易；
票号校验单元，响应于所述目标交易，调用发布在区块链上的智能合约中声明的核销逻辑，获取所述目标电子票据的票据号码，并校验所述票据号码与所述目标电子票据的开票方对应的区块链账户中维护的电子票据号段是否匹配；其中，所述区块链账户中维护的电子票据号段为分配至所述区块链账户的用于开具电子票据的电子票据号码号段；
合法性校验单元，如果是，进一步对所述目标电子票据的票据内容进行合法性校验，并在合法性校验通过后生成与所述目标电子票据对应的核销处理完成事件，以及将所述核销处理完成事件发布至所述区块链进行存证。
可选的，所述区块链包含用于维护电子票据号段的多级账户；
所述装置还包括：
申领接收单元，接收开票方发送的申领交易，所述申领交易中包含所述开票方账户的账户标识；
分配单元，响应于所述申领交易，调用发布在所述区块链上的智能合约中声明的号码申领逻辑，确定与所述账户标识对应的区块链账户的上一级账户，并从所述上一级账户维护的电子票据号段中为所述开票方分配电子票据号码；以及
将所分配的电子票据号码添加至所述开票方的区块链账户中。
可选的，所述目标电子票据的票据内容包括票据金额，所述合法性校验单元具体用于：
校验所述目标电子票据的票据金额是否与所述目标电子票据的入账金额相匹配；
如果是，确定合法性校验通过。
可选的，所述区块链节点通过oracle预言机与电子票据的开票监管方的服务端对接；
所述合法性校验单元进一步用于：
通过所述oracle预言机从所述开票监管方的服务端中获取所述目标电子票据的票据金额和所述目标电子票据的入账金额的比较结果；
当得到的比较结果为所述票据金额与所述入账金额一致时，确定所述票据金额与所述入账金额相匹配。
可选的，所述合法性校验单元进一步用于：
在校验出所述票据号码与所述目标电子票据的开票方对应的区块链账户中维护的电子票据号段相匹配后，生成针对所述票据号码的校验通过事件，以使所述开票监管方的服务端在监听到所述校验通过事件时，将所述校验通过事件中记录的所述票据金额与所述入账金额进行比较，并通过所述oracle预言机返回比较结果。
可选的，所述合法性校验单元进一步用于：
通过所述oracle预言机向所述开票监管方的服务端发送针对所述票据金额与所述入账金额的比较结果的获取请求，以使所述开票监管方的服务端将所述票据金额与所述目标票据的入账金额进行比较；
接收所述开票监管方的服务端通过所述oracle预言机返回的比较结果。
可选的，所述区块链为联盟链；所述联盟链的联盟成员包括作为开票监管方的各级财政机构、作为开票方的用票机构。
根据本说明书一个或多个实施例的第三方面，提出了一种电子设备，包括：
处理器；
用于存储处理器可执行指令的存储器；
其中，所述处理器通过运行所述可执行指令以实现如上述任一实施例中所述基于区块链的票据核销方法。
根据本公开实施例的第四方面，提供一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如上述实施例中任一所述基于区块链的票据核销方法的步骤。
在以上技术方案中，在区块链上预先维护电子票据号段供区块链账户申领票据号码，而各区块链账户在申领到票据号码后，可利用申领到的票据号码开具电子票据。
基于上述申领票据号码的机制，在对目标电子票据进行核销时，通过调用智能合约校验目标电子票据的票据号码与目标电子票据的开票方对应的区块链账户中维护的电子票据号段是否匹配，可避免对核销发起方伪造的电子票据进行核销。进一步的，在票据号码通过校验时，再通过智能合约对目标电子票据的票据内容进行合法性校验，从而可实现对目标电子票据进行全面的核销。
附图说明
图1是一示例性实施例提供的一种创建智能合约的示意图；
图2是一示例性实施例提供的调用智能合约的示意图；
图3是一示例性实施例提供的创建智能合约和调用智能合约的示意图；
图4是一示例性实施例提供的一种基于区块链的票据核销方法的流程图；
图5是一示例性实施例提供的一种基于区块链的票据核销方案的整体架构示意图；
图6是一示例性实施例提供的一种申领电子票据号码的交互图；
图7是一示例性实施例提供的分发和下发电子票据号码的示意图；
图8是一示例性实施例提供的一种核销电子票据的交互图；
图9是一示例性实施例提供的一种设备的结构示意图。
图10是一示例性实施例提供的一种基于区块链的票据核销装置的框图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。
需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个 步骤进行描述。
区块链一般被划分为三种类型：公有链(Public Blockchain)，私有链(Private Blockchain)和联盟链(Consortium Blockchain)。此外，还可以有上述多种类型的结合，比如私有链+联盟链、联盟链+公有链等。
其中，去中心化程度最高的是公有链。公有链以比特币、以太坊为代表，加入公有链的参与者(也可称为区块链中的节点)可以读取链上的数据记录、参与交易、以及竞争新区块的记账权等。而且，各节点可自由加入或者退出网络，并进行相关操作。
私有链则相反，该网络的写入权限由某个组织或者机构控制，数据读取权限受组织规定。简单来说，私有链可以为一个弱中心化系统，其对节点具有严格限制且节点数量较少。这种类型的区块链更适合于特定机构内部使用。
联盟链则是介于公有链以及私有链之间的区块链，可实现“部分去中心化”。联盟链中各个节点通常有与之相对应的实体机构或者组织；节点通过授权加入网络并组成利益相关联盟，共同维护区块链运行。
基于区块链的基本特性，区块链通常是由若干个区块构成。在这些区块中分别记录有与该区块的创建时刻对应的时间戳，所有的区块严格按照区块中记录的时间戳，构成一条在时间上有序的数据链条。
对于物理世界产生的真实数据，可以将其构建成区块链所支持的标准的交易(transaction)格式，然后发布至区块链，由区块链中的节点设备对收到的交易进行共识处理，并在达成共识后，由区块链中作为记账节点的节点设备，将这笔交易打包进区块，在区块链中进行持久化存证。
其中，区块链中支持的共识算法可以包括：
第一类共识算法，即节点设备需要争夺每一轮的记账周期的记账权的共识算法；例如，工作量证明(Proof of Work,POW)、股权证明(Proof of Stake，POS)、委任权益证明(Delegated Proof of Stake，DPOS)等共识算法；
第二类共识算法，即预先为每一轮记账周期选举记账节点(不需要争夺记账权)的共识算法；例如，实用拜占庭容错(Practical Byzantine Fault Tolerance，PBFT)等共识算法。
在采用第一类共识算法的区块链网络中，争夺记账权的节点设备，都可以在接收 到交易后执行该笔交易。争夺记账权的节点设备中可能有一个节点设备在本轮争夺记账权的过程中胜出，成为记账节点。记账节点可以将收到的交易与其它交易一起打包以生成最新区块，并将生成的最新区块或者该最新区块的区块头发送至其它节点设备进行共识。
在采用第二类共识算法的区块链网络中，具有记账权的节点设备在本轮记账前已经商定好。因此，节点设备在接收到交易后，如果自身不是本轮的记账节点，则可以将该交易发送至记账节点。对于本轮的记账节点，在将该交易与其它交易一起打包以生成最新区块的过程中或者之前，可以执行该交易。记账节点在生成最新区块后，可以将该最新区块或者该最新区块的区块头发送至其它节点设备进行共识。
如上所述，无论区块链采用以上示出的哪种共识算法，本轮的记账节点都可以将接收到的交易打包以生成最新区块，并将生成的最新区块或者该最新区块的区块头发送至其它节点设备进行共识验证。如果其它节点设备接收到最新区块或者该最新区块的区块头后，经验证没有问题，可以将该最新区块追加到原有的区块链末尾，从而完成区块链的记账过程。其它节点验证记账节点发来的新的区块或区块头的过程中，也可以执行该区块中的包含的交易。
在区块链领域，有一个重要的概念就是账户(Account)；以以太坊为例，以太坊通常将账户划分为外部账户和合约账户两类；外部账户就是由用户直接控制的账户，也称之为用户账户；而合约账户则是由用户通过外部账户创建的，包含合约代码的账户(即智能合约)。当然，对于一些基于以太坊的架构而衍生出的区块链模型(比如蚂蚁区块链)，还可以对区块链支持的账户类型，进行进一步的扩展，在本说明书中不进行特别限定。
对于区块链中的账户而言，通常会通过一个结构体，来维护账户的账户状态。当区块中的交易被执行后，区块链中与该交易相关的账户的状态通常也会发生变化。
以以太坊为例，账户的结构体通常包括Balance，Nonce，Code和Storage等字段。其中：
Balance字段，用于维护账户目前的账户余额；
Nonce字段，用于维护该账户的交易次数；它是用于保障每笔交易能且只能被处理一次的计数器，有效避免重放攻击；
Code字段，用于维护该账户的合约代码；在实际应用中，Code字段中通常仅维护 合约代码的hash值；因而，Code字段通常也称之为Codehash字段。
Storage字段，用于维护该账户的存储内容(默认字段值为空)；对于合约账户而言，通常会分配一个独立的存储空间，用以存储该合约账户的存储内容；该独立的存储空间通常称之为该合约账户的账户存储。合约账户的存储内容通常会构建成MPT(Merkle Patricia Trie)树的数据结构存储在上述独立的存储空间之中；其中，基于合约账户的存储内容构建成的MPT树，通常也称之为Storage树。而Storage字段通常仅维护该Storage树的根节点；因此，Storage字段通常也称之为StorageRoot字段。
其中，对于外部账户而言，以上示出的Code字段和Storage字段的字段值均为空值。
对于大多数区块链模型，通常都会使用Merkle树；或者，基于Merkle树的数据结构，来存储和维护数据。以以太坊为例，以太坊使用了MPT树(一种Merkle树变种)，作为数据组织形式，用来组织和管理账户状态、交易信息等重要数据。
在实际应用中，不论是公有链、私有链还是联盟链，都可能提供智能合约(Smart contract)的功能。区块链上的智能合约是在区块链上可以被交易触发执行的合约。智能合约可以通过代码的形式定义。
以以太坊为例，支持用户在以太坊网络中创建并调用一些复杂的逻辑。以太坊作为一个可编程区块链，其核心是以太坊虚拟机(EVM)，每个以太坊节点都可以运行EVM。EVM是一个图灵完备的虚拟机，通过它可以实现各种复杂的逻辑。用户在以太坊中发布和调用智能合约就是在EVM上运行的。实际上，EVM直接运行的是虚拟机代码(虚拟机字节码，下简称“字节码”)，所以部署在区块链上的智能合约可以是字节码。
如图1所示，Bob将一笔包含创建智能合约信息的交易(Transaction)发送到以太坊网络后，各节点均可以在EVM中执行这笔交易。其中，图中1中交易的From字段用于记录发起创建智能合约的账户的地址，交易的Data字段的字段值保存的合约代码可以是字节码，交易的To字段的字段值为一个null(空)的账户。当节点间通过共识机制达成一致后，这个智能合约成功创建，后续用户可以调用这个智能合约。
智能合约创建后，区块链上出现一个与该智能合约对应的合约账户，并拥有一个特定的地址；比如，图1中各节点中的“0x68e12cf284…”就代表了创建的这个合约账户的地址；合约代码(Code)和账户存储(Storage)将保存在该合约账户的账户存储中。 智能合约的行为由合约代码控制，而智能合约的账户存储则保存了合约的状态。换句话说，智能合约使得区块链上产生包含合约代码和账户存储的虚拟账户。
前述提到，包含创建智能合约的交易的Data字段保存的可以是该智能合约的字节码。字节码由一连串的字节组成，每一字节可以标识一个操作。基于开发效率、可读性等多方面考虑，开发者可以不直接书写字节码，而是选择一门高级语言编写智能合约代码。例如，高级语言可以采用诸如Solidity、Serpent、LLL语言等。对于采用高级语言编写的智能合约代码，可以经过编译器编译，生成可以部署到区块链上的字节码。
以Solidity语言为例，用其编写的合约代码与面向对象编程语言中的类(Class)很相似，在一个合约中可以声明多种成员，包括状态变量、函数、函数修改器、事件等。状态变量是永久存储在智能合约的账户存储(Storage)字段中的值，用于保存合约的状态。
如图2所示，仍以以太坊为例，Bob将一笔包含调用智能合约信息的交易发送到以太坊网络后，各节点均可以在EVM中执行这笔交易。其中，图2中交易的From字段用于记录发起调用智能合约的账户的地址，To字段用于记录被调用的智能合约的地址，交易的Data字段用于记录调用智能合约的方法和参数。调用智能合约后，合约账户的账户状态可能改变。后续，某个客户端可以通过接入的区块链节点(例如图2中的节点1)查看合约账户的账户状态。
智能合约可以以规定的方式在区块链网络中每个节点独立的执行，所有执行记录和数据都保存在区块链上，所以当这样的交易执行完毕后，区块链上就保存了无法篡改、不会丢失的交易凭证。
创建智能合约和调用智能合约的示意图如图3所示。以太坊中要创建一个智能合约，需要经过编写智能合约、变成字节码、部署到区块链等过程。以太坊中调用智能合约，是发起一笔指向智能合约地址的交易，各个节点的EVM可以分别执行该交易，将智能合约代码分布式的运行在以太坊网络中每个节点的虚拟机中。
以以太坊代表的传统的区块链模型，为了在区块链上实现“价值转移”，通常都支持将现实世界的货币转换为能够在链上流通的虚拟代币。
而在区块链领域，对于一些基于以太坊的架构而衍生出的区块链模型(比如蚂蚁区块链)，通常不再支持将现实世界的货币转换为能够在链上流通的虚拟代币的功能；取而代之的是，在这些区块链模型中，可以将现实世界中的一些非货币属性的实体资产， 转化成为能够在区块链上流通的虚拟资产。
其中，需要说明的是，将现实世界中的非货币属性的实体资产转化为区块链上的虚拟资产，通常是指将该实体资产与区块链上的虚拟资产进行“锚定”，作为这些虚拟资产的价值支撑，进而在区块链上产生与实体资产的价值匹配，且能够在区块链上的区块链账户之间进行流通的虚拟资产的过程。
在实现时，可以对区块链支持的账户类型进行扩展，在区块链支持的账户类型的基础上，再扩展出一种资产账户(也称之为资产对象)；比如，可以在以太坊支持的外部账户、合约账户的基础上，再扩展出一种资产账户；扩展出的该资产账户，即为可以将现实世界中的非货币属性的实体资产作为价值支撑，且可以在区块链账户之间流通的虚拟资产。
对于接入这类区块链的用户而言，除了可以在区块链上完成用户账户、智能合约的创建以外，在区块链上创建一笔与现实世界的非货币属性的实体资产价值匹配的虚拟资产，在区块链上进行流通；
例如，用户可以将持有的房产、股票、贷款合同、票据、应收账款等非货币属性的实体资产，转换为价值匹配的虚拟资产在区块链上流通。
其中，对于上述资产账户而言，具体也可以通过一个结构体，来维护账户的账户状态。上述资产账户的结构体所包含的内容，可以与以太坊相同，当然也可以基于实际的需求进行设计；
在一种实现方式中，以上述资产账户的结构体所包含的内容与以太坊相同为例，上述资产账户的结构体也可以包括以上描述的Balance，Nonce，Code和Storage等字段。
需要说明的是，在以太坊中，Balance字段通常用于维护账户目前的账户余额；而对于基于以太坊的架构而衍生出的区块链模型而言，由于其可能并不支持将现实世界的货币转换为能够在链上流通的虚拟代币，因此在这类区块链中，可以对Balance字段的含义进行扩展，不再表示账户的“余额”，而是用于维护账户持有的“虚拟资产”对应的资产账户的地址信息。其中，在实际应用中，Balance字段中可以维护多笔“虚拟资产”对应的资产账户的地址信息。
在这种情况下，以上示出的外部账户、合约账户和资产账户，均可以通过在Balance字段中添加需要持有的“虚拟资产”对应的资产账户的地址信息，来持有这笔虚拟资产。即除了外部账户和合约账户以外，资产账户本身也可以持有虚拟资产。
对于资产账户而言，Nonce，Code字段的字段值可以为空值(也可以不为空)；而Storage字段的字段值可以不再是空值；Storage字段可以用于维护与该资产账户对应的“虚拟资产”的资产状态。其中，在Storage字段中维护与该资产账户对应的“虚拟资产”的资产状态的具体方式，可以基于需求灵活的进行设计，不再赘述。
在基于以太坊的架构而衍生出的区块链模型中，用户可以通过以下示出的实现方式，在区块链上创建一笔与现实世界的非货币属性的实体资产价值匹配的虚拟资产：
在一种实现方式中，可以对区块链支持的交易类型进行扩展，扩展出一种用于创建虚拟资产的交易；比如，以太坊支持的交易类型通常包括普通的转账交易、创建智能合约的交易和调用智能合约的交易，则可以在以上三种类型的交易的基础上，再扩展出一种用于创建虚拟资产的交易。
在这种情况下，用户可以通过客户端向区块链网络中发布一笔用于创建虚拟资产的交易，由区块链中的节点设备在本地的EVM中执行这笔交易，来为该用户创建虚拟资产。当各节点设备通过共识机制达成一致后，这笔虚拟资产成功创建，区块链上出现一个与这笔虚拟资产对应的资产账户，并拥有一个特定的地址。
在另一种实现方式中，也可以在区块链上部署用于创建虚拟资产的智能合约；其中，部署用于创建虚拟资产的智能合约的过程不再赘述。
在这种情况下，用户可以通过客户端向区块链网络中发布一笔用于调用该智能合约的交易，由区块链中的节点设备在本地的EVM中执行这笔交易，并在EVM中运行智能合约相关的合约代码，来为该用户创建虚拟资产。当各节点设备通过共识机制达成一致后，这笔虚拟资产成功创建，区块链上出现一个与这笔虚拟资产对应的资产账户，并拥有一个特定的地址。
当然，对于一些基于以太坊的架构而衍生出的区块链模型，如果其也支持将现实世界的货币转换为能够在链上流通的虚拟代币的功能，那么仍然可以将现实世界中的一些非货币属性的实体资产，转化成为能够在区块链上流通的虚拟代币的形式，在区块链上流通，在本说明书中不再赘述。
在跨链场景下，多个区块链可以通过跨链中继实现跨链对接。
其中，跨链中继，可以通过桥接接口与多个区块链分别进行对接，并基于实现的数据搬运逻辑，完成该多个区块链之间的跨链数据同步。
在实现上述跨链中继时所采用的跨链技术，在本说明书中不进行特别限定；例如， 在实际应用中，可以通过侧链技术、公证人技术等跨链机制，将多个区块链连接起来。
当多个区块链通过跨链中继实现对接之后，区块链之间就可以去读取并认证其它区块链上的数据，也可以通过跨链中继去调用其它区块链上部署的智能合约。
区块链上部署的智能合约，除了可以使用区块链上存证的数据以外，也可以通过Oracle预言机，来引用链外的数据实体上的数据，进而实现智能合约与真实世界的数据实体之间的数据交互。链外的数据实体，可以包括诸如部署在链外的中心化的服务器或者数据中心，等等。
其中，与跨链中继不同的是，Oracle预言机的功能并不是将一个区块链上的数据同步到另一个区块链上，而是将链外的数据实体上的数据同步到区块链上；
也即，跨链中继用于连接两个区块链，而Oracle预言机用于连接区块链与链外的数据实体，实现区块链与真实世界的数据交互。
请参见图4，图4是一示例性实施例提供的一种基于区块链的票据核销方法的流程图。如图4所示，该方法应用于区块链节点，可以包括以下步骤：
步骤402，接收用于对目标电子票据进行核销处理的目标交易。
在本实施例中，财政机构可预先建立多级账户，针对各级账户配置对应的电子票据号段以供各级账户下的用票机构开具电子票据使用；换言之，电子票据号码与电子票据之间为“一一对应”的关系。例如，可按照“省厅、市级、区/县”来建立多级账户，由省厅的财政账户预先配置全省的电子票据号段，再将配置好的电子票据号段分配至各个市级的财政账户，而市级的财政账户申领到相应的电子票据号段后，再向区/县的财政账户分配电子票据号段。
基于上述“多级账户维护电子票据号段”的体系，开票方可通过向上一级账户申领的方式来获取电子票据号码。作为一示例性实施例，区块链上包含用于维护电子票据号段的多级账户，开票方可打包一笔申领交易(包含开票方账户的账户标识)，并通过向区块链节点发送该申领交易来获取电子票据号码。区块链节点在接收到开票方发送的申领交易后，可响应于该申领交易，调用发布在区块链上的智能合约中声明的号码申领逻辑，确定与该账户标识对应的区块链账户的上一级账户，并从该上一级账户维护的电子票据号段中为开票方分配电子票据号码；以及将所分配的电子票据号码添加至开票方的区块链账户中。比如，开票方为市级的用票机构，那么对应的上一级账户为省厅的财政机构的区块链账户。或者，各级账户下的用票机构可通过所属级别的财政机构向上一 级财政账户申领电子票据号码，再由所属级别的财政机构返回申领到的电子票据号码。例如，由市级财政机构的区块链账户向省厅财政机构的区块链账户申领电子票据号段，再将申领到的电子票据号段分配至市级的各个用票机构。
在一种情况下，电子票据可由开票方在线下开具，开具以后再由开票方发布至区块链上进行存证。在另一种情况下，可预先在区块链上发布用于利用电子票据开具电子发票的智能合约，而各个开票方申领到的电子票据号码可发布至区块链上进行存证。那么，在调用智能合约开具电子票据后，开具的电子票据可发布至区块链上进行存证。
在利用申领到的电子票据号码开具电子票据后，该电子票据的开票方或者开票监管方可发起对该电子票据的核销操作。具体而言，可打包一笔用于对目标电子票据进行核销处理的目标交易，该目标交易中包含目标电子票据的票据标识；其中，可采用票据代码、校验码等作为票据标识，也可直接采用票据号码作为票据标识。
步骤404，响应于所述目标交易，调用发布在区块链上的智能合约中声明的核销逻辑，获取所述目标电子票据的票据号码，并校验所述票据号码与所述目标电子票据的开票方对应的区块链账户中维护的电子票据号段是否匹配；其中，所述区块链账户中维护的电子票据号段为分配至所述区块链账户的用于开具电子票据的电子票据号码号段。
在本实施例中，由于开票方申领到的电子票据号码被添加至开票方的区块链账户中，基于区块链不可篡改的特点，可通过校验电子票据号码来防止核销发起方对伪造的电子票据进行核销的问题。
步骤406，如果是，进一步对所述目标电子票据的票据内容进行合法性校验，并在合法性校验通过后生成与所述目标电子票据对应的核销处理完成事件，以及将所述核销处理完成事件发布至所述区块链进行存证。
在本实施例中，在校验目标电子票据的票据号码通过以后，对目标电子票据的票据内容进行合法性校验，从而实现对目标电子票据进行较为全面的核销。其中，票据内容可以是票据明细、票据金额等。
例如，在对目标电子票据的票据内容进行合法性校验时，可校验目标电子票据的票据金额是否与目标电子票据的入账金额相匹配；如果是，则确定合法性校验通过。其中，入账金额由开票监管方来维护，比如，可以是各级财政机构，在开具电子票据时，各级财政机构正是作为票据的入账方。
而区块链节点可通过oracle预言机与电子票据的开票监管方的服务端对接，因此区 块链节点可通过oracle预言机从开票监管方的服务端中获取目标电子票据的票据金额和目标电子票据的入账金额的比较结果；当得到的比较结果为票据金额与入账金额一致时，可确定票据金额与入账金额相匹配。
在一种情况下，区块链节点可通过事件机制来与开票监管方的服务端进行交互。比如，在校验出票据号码与目标电子票据的开票方对应的区块链账户中维护的电子票据号段相匹配后，区块链节点可生成针对该票据号码的校验通过事件(包含目标电子票据的票据金额)，以使开票监管方的服务端在监听到校验通过事件时，将校验通过事件中记录的票据金额与入账金额进行比较，并通过oracle预言机返回比较结果。
在另一种情况下，区块链节点可通过oracle预言机主动向开票监管方的服务端获取数据。比如，区块链节点通过oracle预言机向开票监管方的服务端发送针对目标电子票据的票据金额与入账金额的比较结果的获取请求，以使开票监管方的服务端将该票据金额与该目标票据的入账金额进行比较，并通过oracle预言机返回比较结果。
需要说明的是，本说明书一个或多个实施例中的区块链可以是联盟链。其中，该联盟链的联盟成员包括作为开票监管方的各级财政机构、作为开票方的用票机构。而接入区块链的用户在区块链上发起的请求的类型，具体可以是指传统的区块链中所采用的交易(transaction)。当然，接入区块链的用户在区块链上发起的请求的类型，具体也可以是交易以外的，其它形式的具有标准的数据结构的指令、消息等，本说明书一个或多个实施例并不进行特别限定。在以下的各实施例中，将以接入区块链的用户在区块链上发起的请求为交易为例进行说明。
在以上技术方案中，在区块链上预先维护电子票据号段供区块链账户申领票据号码，而各区块链账户在申领到票据号码后，可利用申领到的票据号码开具电子票据。
基于上述申领票据号码的机制，在对目标电子票据进行核销时，通过调用智能合约校验目标电子票据的票据号码与目标电子票据的开票方对应的区块链账户中维护的电子票据号段是否匹配，可避免对核销发起方伪造的电子票据进行核销。进一步的，在票据号码通过校验时，再通过智能合约对目标电子票据的票据内容进行合法性校验，从而可实现对目标电子票据进行全面的核销。
图5是一示例性实施例提供的一种基于区块链的票据核销方案的整体架构示意图。如图5所示，服务器52上运行有区块链的客户端，使得该服务器55被配置为一区块链节点。核销发起方50可以预先通过客户端51在服务器52处进行账号注册，得到与自 身唯一对应的已注册账号。然后，核销发起方50可以通过在客户端51上登录该已注册账号，而服务器52基于该已注册账号在客户端51上的登录信息，确定该已注册账号(对应于该核销发起方)与客户端51之间建立了绑定关系。所需建立的绑定关系为核销发起方50的账户信息与客户端51的设备信息之间的绑定关系。基于该绑定关系，使得服务器52在接收到客户端51后续发送的目标交易时，可以确认该交易对应于核销发起方50。
以核销为例，核销发起方50可在客户端51上登录已注册账号，通过客户端51打包一笔用于对目标电子票据进行核销的目标交易，并通过客户端51发送至服务器52。服务器52(作为区块链节点)在接收到目标交易后调用智能合约对目标电子票据的票据号码和票据内容进行校验，并在校验通过后生成核销处理完成事件发布至区块链上进行存证。
为了便于理解，下面针对客户端51、服务器52(作为区块链节点)分别在核销过程中实现的操作和功能，结合图6-8对本说明书的技术方案进行详细说明。图6是一示例性实施例提供的一种申领电子票据号码的交互图。如图6所示，该交互过程可以包括以下步骤：
步骤602，开票方客户端打包一笔申领交易。
在本实施例中，以开票方作为核销发起方为例进行说明，开票方可通过客户端打包一笔申领交易以申领用于开具电子票据的票据号码。其中，申领交易中包含开票方账户的账户标识；比如，为开票方的已注册账号。
财政机构可预先建立多级账户，针对各级账户配置对应的电子票据号段以供各个下级账户下的用票机构开具电子票据使用。换言之，电子票据号码与电子票据之间为“一一对应”的关系。
步骤604，开票方客户端向区块链节点发送申领交易。
步骤606，区块链节点确定开票方的上一级账户。
例如，可按照“省厅、市级、区/县”来建立多级账户；其中，省厅为市级的上一级账户，市级为区/县的上一级账户。
步骤608，区块链节点为开票方分配电子票据号码。
步骤610，将所分配的电子票据号码添加至开票方的区块链账户中。
在本实施例中，在完成对电子票据号码的分配之后，区块链节点可生成用于记录分配结果的事件，那么开票方客户端在监听到该事件时，可获取到本次申领到的电子票据号码(可以是一个电子票据号码，或者为电子票据号段)。
举例而言，如图7所示，票据入库省厅财政部门的区块链账户中，添加电子票据号段00000001～99999999；其中，可将电子票据号段00000001～99999999作为可用库存，用于分别划分为多个电子票据号段下发至省本级和各个市(以下均以各个市、区/县的名称来代表相应的区块链账户)。例如，电子票据号段00000001～50000001分配至省本级使用，进而电子票据号段00000001～50000000中包含的票据号码用于分发至省本级下的各个用票机构，而剩余的电子票据号段50000001～99999999用于下发至各个市(温州市、台州市、杭州市等)使用。以台州市为例，可从剩余的电子票据号段中划分出票据号段80000001～89999999供台州市使用。
类似的，市级财政部门的区块链账户在申领到相应的电子票据号段后，一部分可分发至市本级使用，而另一部分可下发至位于下级的各个行政区(区/县)。例如，电子票据号段80000001～80999998用于分发至市本级使用，而剩余的电子票据号段中80999999～83000000用于下发至三门县，83000001～83999999用于下发至临海市。
需要说明的是，各级账户申领到的电子票据号段(或电子票据号码)可维护于各级账户的结构体中。举例而言，可对Balance，Nonce，Code和Storage等字段的含义进行扩展。例如，Balance字段用于维护账户可分发的电子票据号段，Storage字段用于维护账户可下发的电子票据号段。特别的，位于多级账户中最底层的账户(比如临海市、三门县等)，Balance字段用于维护账户可分发的电子票据号段，而Storage字段为空。
或者，Balance字段用于维护账户可下发的电子票据号段，Storage字段用于维护账户可分发的电子票据号段。当然，各个字段具体的扩展方式，可以基于需求灵活的进行设计，本说明书一个或多个实施例并不对此进行限制。
开票方在申领到电子票据号码后，可利用申领到的电子票据号码开具电子票据；其中，电子票据和电子票据号码为“一一对应”的关系。那么，后续开票方或者开票监管方在对电子票据进行核销时，可基于电子票据号码对待核销的电子票据进行校验，从而可避免对核销发起方伪造的电子票据进行核销。
请参见图8，图8是一示例性实施例提供的一种核销电子票据的交互图。如图8所示，该交互过程可以包括以下步骤：
步骤802，区块链节点接收核销交易。
以联盟链为例，联盟链成员可在智能合约中声明核销逻辑，用于对目标电子票据进行核销处理。当完成对该智能合约的开发后，该联盟链成员可以通过联盟链中的任一节点设备将该智能合约发布至联盟链，并在该智能合约由该联盟链中的部分指定的成员节点设备(比如，联盟链中指定的若干个具有记账权限的权威节点设备)完成共识后，存证至该联盟链的区块中。
那么，当开票方或者开票监管方需要对目标电子票据进行核销时，可作为核销发起方打包一笔核销交易，该核销交易中包含目标电子票据的票据标识和目标电子票据的开票方区块链账户的账户标识；其中，可采用票据代码、校验码等作为票据标识，也可直接采用票据号码作为票据标识。
步骤804，区块链节点校验目标电子票据的票据号码。
在本实施例中，区块链节点在接收到核销交易后，响应于该目标交易，调用发布在区块链上的智能合约中声明的核销逻辑，获取目标电子票据的票据号码，并校验该票据号码与目标电子票据的开票方对应的区块链账户中维护的电子票据号段是否匹配。其中，当采用票据代码或校验码等作为票据标识时，区块链节点需先根据票据标识查询区块链上存证的相应电子票据(即目标电子票据)，在从查询到的电子票据中读取票据号码。
区块链节点可根据核销交易中包含的账户标识确定出临海市的区块链账户中维护的电子票据号段(即账户中维护的“可分发”的电子票据号段)，进而确定目标电子票据的票据号码是否属于该电子票据号段中；如果属于，则校验通过。承接于上述举例，假定核销发起方为属于临海市的用票单位，临海市的区块链账户维护的电子票据号段为83000001～83999999，而目标电子票据的票据号码为83001001(属于上述电子票据号段)，则可判定校验通过。
步骤806，在票据号码校验通过后，区块链节点向oracle预言机发送针对目标电子票据的票据金额与入账金额的比较结果的获取请求。
在本实施例中，在校验目标电子票据的票据号码通过以后，可进一步对目标电子票据的票据内容进行合法性校验，从而实现对目标电子票据进行较为全面的核销。其中，票据内容可以是票据明细、票据金额等。
以票据内容为票据金额为例，电子票据的入账金额由开票监管方来维护，比如， 可以是各级财政机构，在开具电子票据时，各级财政机构正是作为票据的入账方。因此，区块链节点可通过与开票监管方的服务端对接的oracle预言机来获取票据金额与入账金额的比较结果。
步骤808，oracle预言机向开票监管方转发获取请求。
步骤810，开票监管方比较票据金额和入账金额。
在一种情况下，获取请求可包含目标电子票据的票据标识和票据金额，开票监管方根据票据标识读取本地记录的目标电子票据的入账金额，并与票据金额进行比较，进而将比较结果通过oracle预言机返回至区块链节点。
在另一种情况下，获取请求可包含目标电子票据的票据标识，开票监管方根据票据标识读取本地记录的目标电子票据的入账金额，并将比较结果通过oracle预言机返回至区块链节点，以由区块链节点进行比较。
步骤812，开票监管方向oracle预言机返回比较结果。
步骤814，oracle预言机向区块链节点转发比较结果。
步骤816，当比较结果为票据金额和入账金额一致时，区块链节点生成核销处理完成事件。
在本实施例中，当核销发起方监听到对应于目标电子票据的核销处理完成事件时，可判定目标电子票据核销完成。进一步的，核销发起方还可在本地维护对应于目标电子票据的状态机，当判定目标电子票据核销完成时，将该状态机切换为核销完成状态。
与上述方法实施例相对应，本申请还提供了装置的实施例。
与上述方法实施例相对应，本说明书还提供了一种基于区块链的票据核销装置的实施例。
本说明书的基于区块链的票据核销装置的实施例可以应用在电子设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在电子设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。
从硬件层面而言，请参考图9，图9是一示例性实施例提供的一种设备的示意结构图。如图9所示，在硬件层面，该设备包括处理器902、内部总线904、网络接口906、内存908以及非易失性存储器910，当然还可能包括其他业务所需要的硬件。处理器902 从非易失性存储器910中读取对应的计算机程序到内存908中然后运行，在逻辑层面上形成基于区块链的票据核销装置。当然，除了软件实现方式之外，本说明书一个或多个实施例并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
请参考图10，在软件实施方式中，该基于区块链的票据核销装置应用于区块链节点，可以包括：
核销接收单元1001，接收用于对目标电子票据进行核销处理的目标交易；
票号校验单元1002，响应于所述目标交易，调用发布在区块链上的智能合约中声明的核销逻辑，获取所述目标电子票据的票据号码，并校验所述票据号码与所述目标电子票据的开票方对应的区块链账户中维护的电子票据号段是否匹配；其中，所述区块链账户中维护的电子票据号段为分配至所述区块链账户的用于开具电子票据的电子票据号码号段；
合法性校验单元1003，如果是，进一步对所述目标电子票据的票据内容进行合法性校验，并在合法性校验通过后生成与所述目标电子票据对应的核销处理完成事件，以及将所述核销处理完成事件发布至所述区块链进行存证。
可选的，所述区块链包含用于维护电子票据号段的多级账户；
所述装置还包括：
申领接收单元1004，接收开票方发送的申领交易，所述申领交易中包含所述开票方账户的账户标识；
分配单元1005，响应于所述申领交易，调用发布在所述区块链上的智能合约中声明的号码申领逻辑，确定与所述账户标识对应的区块链账户的上一级账户，并从所述上一级账户维护的电子票据号段中为所述开票方分配电子票据号码；以及
将所分配的电子票据号码添加至所述开票方的区块链账户中。
可选的，所述目标电子票据的票据内容包括票据金额，所述合法性校验单元1003具体用于：
校验所述目标电子票据的票据金额是否与所述目标电子票据的入账金额相匹配；
如果是，确定合法性校验通过。
可选的，所述区块链节点通过oracle预言机与电子票据的开票监管方的服务端对接；
所述合法性校验单元1003进一步用于：
通过所述oracle预言机从所述开票监管方的服务端中获取所述目标电子票据的票据金额和所述目标电子票据的入账金额的比较结果；
当得到的比较结果为所述票据金额与所述入账金额一致时，确定所述票据金额与所述入账金额相匹配。
可选的，所述合法性校验单元1003进一步用于：
在校验出所述票据号码与所述目标电子票据的开票方对应的区块链账户中维护的电子票据号段相匹配后，生成针对所述票据号码的校验通过事件，以使所述开票监管方的服务端在监听到所述校验通过事件时，将所述校验通过事件中记录的所述票据金额与所述入账金额进行比较，并通过所述oracle预言机返回比较结果。
可选的，所述合法性校验单元1003进一步用于：
通过所述oracle预言机向所述开票监管方的服务端发送针对所述票据金额与所述入账金额的比较结果的获取请求，以使所述开票监管方的服务端将所述票据金额与所述目标票据的入账金额进行比较；
接收所述开票监管方的服务端通过所述oracle预言机返回的比较结果。
可选的，所述区块链为联盟链；所述联盟链的联盟成员包括作为开票监管方的各级财政机构、作为开票方的用票机构。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
在一个典型的配置中，计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法 或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任 何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。

Claims (16)

  1. 一种基于区块链的票据核销方法，应用于区块链节点；所述方法包括：
    接收用于对目标电子票据进行核销处理的目标交易；
    响应于所述目标交易，调用发布在区块链上的智能合约中声明的核销逻辑，获取所述目标电子票据的票据号码，并校验所述票据号码与所述目标电子票据的开票方对应的区块链账户中维护的电子票据号段是否匹配；其中，所述区块链账户中维护的电子票据号段为分配至所述区块链账户的用于开具电子票据的电子票据号码号段；
    如果是，进一步对所述目标电子票据的票据内容进行合法性校验，并在合法性校验通过后生成与所述目标电子票据对应的核销处理完成事件，以及将所述核销处理完成事件发布至所述区块链进行存证。
  2. 根据权利要求1所述的方法，所述区块链包含用于维护电子票据号段的多级账户；
    所述方法还包括：
    接收开票方发送的申领交易，所述申领交易中包含所述开票方账户的账户标识；
    响应于所述申领交易，调用发布在所述区块链上的智能合约中声明的号码申领逻辑，确定与所述账户标识对应的区块链账户的上一级账户，并从所述上一级账户维护的电子票据号段中为所述开票方分配电子票据号码；以及
    将所分配的电子票据号码添加至所述开票方的区块链账户中。
  3. 根据权利要求1所述的方法，所述目标电子票据的票据内容包括票据金额，所述进一步对所述目标电子票据的票据内容进行合法性校验，包括：
    校验所述目标电子票据的票据金额是否与所述目标电子票据的入账金额相匹配；
    如果是，确定合法性校验通过。
  4. 根据权利要求3所述的方法，所述区块链节点通过oracle预言机与电子票据的开票监管方的服务端对接；
    所述校验所述目标电子票据的票据金额是否与所述目标电子票据的入账金额相匹配，包括：
    通过所述oracle预言机从所述开票监管方的服务端中获取所述目标电子票据的票据金额和所述目标电子票据的入账金额的比较结果；
    当得到的比较结果为所述票据金额与所述入账金额一致时，确定所述票据金额与所述入账金额相匹配。
  5. 根据权利要求4所述的方法，所述通过所述oracle预言机从所述开票监管方的 服务端中获取所述目标电子票据的票据金额和所述目标电子票据的入账金额的比较结果，包括：
    在校验出所述票据号码与所述目标电子票据的开票方对应的区块链账户中维护的电子票据号段相匹配后，生成针对所述票据号码的校验通过事件，以使所述开票监管方的服务端在监听到所述校验通过事件时，将所述校验通过事件中记录的所述票据金额与所述入账金额进行比较，并通过所述oracle预言机返回比较结果。
  6. 根据权利要求4所述的方法，所述通过所述oracle预言机从所述开票监管方的服务端中获取所述目标电子票据的票据金额和所述目标电子票据的入账金额的比较结果，包括：
    通过所述oracle预言机向所述开票监管方的服务端发送针对所述票据金额与所述入账金额的比较结果的获取请求，以使所述开票监管方的服务端将所述票据金额与所述目标票据的入账金额进行比较；
    接收所述开票监管方的服务端通过所述oracle预言机返回的比较结果。
  7. 根据权利要求1所述的方法，所述区块链为联盟链；所述联盟链的联盟成员包括作为开票监管方的各级财政机构、作为开票方的用票机构。
  8. 一种基于区块链的票据核销装置，应用于区块链节点；所述装置包括：
    核销接收单元，接收用于对目标电子票据进行核销处理的目标交易；
    票号校验单元，响应于所述目标交易，调用发布在区块链上的智能合约中声明的核销逻辑，获取所述目标电子票据的票据号码，并校验所述票据号码与所述目标电子票据的开票方对应的区块链账户中维护的电子票据号段是否匹配；其中，所述区块链账户中维护的电子票据号段为分配至所述区块链账户的用于开具电子票据的电子票据号码号段；
    合法性校验单元，如果是，进一步对所述目标电子票据的票据内容进行合法性校验，并在合法性校验通过后生成与所述目标电子票据对应的核销处理完成事件，以及将所述核销处理完成事件发布至所述区块链进行存证。
  9. 根据权利要求8所述的装置，所述区块链包含用于维护电子票据号段的多级账户；
    所述装置还包括：
    申领接收单元，接收开票方发送的申领交易，所述申领交易中包含所述开票方账户的账户标识；
    分配单元，响应于所述申领交易，调用发布在所述区块链上的智能合约中声明的号 码申领逻辑，确定与所述账户标识对应的区块链账户的上一级账户，并从所述上一级账户维护的电子票据号段中为所述开票方分配电子票据号码；以及
    将所分配的电子票据号码添加至所述开票方的区块链账户中。
  10. 根据权利要求8所述的装置，所述目标电子票据的票据内容包括票据金额，所述合法性校验单元具体用于：
    校验所述目标电子票据的票据金额是否与所述目标电子票据的入账金额相匹配；
    如果是，确定合法性校验通过。
  11. 根据权利要求10所述的装置，所述区块链节点通过oracle预言机与电子票据的开票监管方的服务端对接；
    所述合法性校验单元进一步用于：
    通过所述oracle预言机从所述开票监管方的服务端中获取所述目标电子票据的票据金额和所述目标电子票据的入账金额的比较结果；
    当得到的比较结果为所述票据金额与所述入账金额一致时，确定所述票据金额与所述入账金额相匹配。
  12. 根据权利要求11所述的装置，所述合法性校验单元进一步用于：
    在校验出所述票据号码与所述目标电子票据的开票方对应的区块链账户中维护的电子票据号段相匹配后，生成针对所述票据号码的校验通过事件，以使所述开票监管方的服务端在监听到所述校验通过事件时，将所述校验通过事件中记录的所述票据金额与所述入账金额进行比较，并通过所述oracle预言机返回比较结果。
  13. 根据权利要求11所述的装置，所述合法性校验单元进一步用于：
    通过所述oracle预言机向所述开票监管方的服务端发送针对所述票据金额与所述入账金额的比较结果的获取请求，以使所述开票监管方的服务端将所述票据金额与所述目标票据的入账金额进行比较；
    接收所述开票监管方的服务端通过所述oracle预言机返回的比较结果。
  14. 根据权利要求8所述的装置，所述区块链为联盟链；所述联盟链的联盟成员包括作为开票监管方的各级财政机构、作为开票方的用票机构。
  15. 一种电子设备，包括：
    处理器；
    用于存储处理器可执行指令的存储器；
    其中，所述处理器通过运行所述可执行指令以实现如权利要求1-7中任一项所述的方法。
  16. 一种计算机可读存储介质，其上存储有计算机指令，其特征在于，该指令被处理器执行时实现如权利要求1-7中任一项所述方法的步骤。
PCT/CN2020/072136 2019-07-31 2020-01-15 基于区块链的票据核销方法及装置、电子设备、存储介质 WO2021017437A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US16/783,075 US11049115B2 (en) 2019-07-31 2020-02-05 Blockchain-based bill write-off method, apparatus, electronic device, and storage medium
US17/359,900 US11429983B2 (en) 2019-07-31 2021-06-28 Blockchain-based bill write-off method, apparatus, electronic device, and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910704689.9A CN110458677A (zh) 2019-07-31 2019-07-31 基于区块链的票据核销方法及装置、电子设备、存储介质
CN201910704689.9 2019-07-31

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/783,075 Continuation US11049115B2 (en) 2019-07-31 2020-02-05 Blockchain-based bill write-off method, apparatus, electronic device, and storage medium

Publications (1)

Publication Number Publication Date
WO2021017437A1 true WO2021017437A1 (zh) 2021-02-04

Family

ID=68484403

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/072136 WO2021017437A1 (zh) 2019-07-31 2020-01-15 基于区块链的票据核销方法及装置、电子设备、存储介质

Country Status (3)

Country Link
CN (1) CN110458677A (zh)
TW (1) TW202107375A (zh)
WO (1) WO2021017437A1 (zh)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10846765B2 (en) 2019-07-31 2020-11-24 Advanced New Technologies Co., Ltd. Blockchain-based e-bill number application method, apparatus, and electronic device
CN110458677A (zh) * 2019-07-31 2019-11-15 阿里巴巴集团控股有限公司 基于区块链的票据核销方法及装置、电子设备、存储介质
US11049115B2 (en) 2019-07-31 2021-06-29 Advanced New Technologies Co., Ltd. Blockchain-based bill write-off method, apparatus, electronic device, and storage medium
CN111507815B (zh) * 2020-04-20 2021-07-27 腾讯科技（深圳）有限公司 基于区块链的信息获取方法、装置、设备及存储介质
CN115239446A (zh) * 2021-05-25 2022-10-25 支付宝(杭州)信息技术有限公司 基于区块链的数据处理方法及装置
CN115187320B (zh) * 2022-08-01 2024-01-30 港航纵横(上海)数字科技有限公司 电子发票的送账方法/系统、设备、介质及财务系统
CN115470292B (zh) * 2022-08-22 2023-10-10 深圳市沃享科技有限公司 区块链共识方法、装置、电子设备及可读存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001086558A1 (en) * 2000-05-09 2001-11-15 Metavante Corporation Electronic bill presentment and payment system
CN109146583A (zh) * 2018-07-24 2019-01-04 腾讯科技（深圳）有限公司 票据处理方法和装置、存储介质及电子装置
CN110046999A (zh) * 2019-02-28 2019-07-23 阿里巴巴集团控股有限公司 区块链交易方法和装置
CN110060096A (zh) * 2019-03-26 2019-07-26 阿里巴巴集团控股有限公司 一种基于区块链的核销奖励发放方法及装置
CN110458677A (zh) * 2019-07-31 2019-11-15 阿里巴巴集团控股有限公司 基于区块链的票据核销方法及装置、电子设备、存储介质

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102608099B1 (ko) * 2016-04-11 2023-12-01 엔체인 홀딩스 리미티드 블록체인에서 안전한 피어-투-피어 통신을 위한 방법
CN106952094B (zh) * 2017-03-10 2018-09-04 腾讯科技（深圳）有限公司 电子票据管理方法及装置
CN107977811A (zh) * 2017-11-22 2018-05-01 合肥维天运通信息科技股份有限公司 一种基于区块链技术的物流融资管理系统及方法
CN109325812B (zh) * 2018-08-24 2023-02-07 深圳市智税链科技有限公司 关于电子票据的数据处理方法、装置、存储介质和设备

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001086558A1 (en) * 2000-05-09 2001-11-15 Metavante Corporation Electronic bill presentment and payment system
CN109146583A (zh) * 2018-07-24 2019-01-04 腾讯科技（深圳）有限公司 票据处理方法和装置、存储介质及电子装置
CN110046999A (zh) * 2019-02-28 2019-07-23 阿里巴巴集团控股有限公司 区块链交易方法和装置
CN110060096A (zh) * 2019-03-26 2019-07-26 阿里巴巴集团控股有限公司 一种基于区块链的核销奖励发放方法及装置
CN110458677A (zh) * 2019-07-31 2019-11-15 阿里巴巴集团控股有限公司 基于区块链的票据核销方法及装置、电子设备、存储介质

Also Published As

Publication number Publication date
CN110458677A (zh) 2019-11-15
TW202107375A (zh) 2021-02-16

Similar Documents

Publication Publication Date Title
TWI707290B (zh) 基於區塊鏈的業務處理方法及裝置、電子設備
WO2021042817A1 (zh) 一种基于区块链的违约资产处理方法、装置及电子设备
WO2021017437A1 (zh) 基于区块链的票据核销方法及装置、电子设备、存储介质
TWI733349B (zh) 基於區塊鏈的票據號碼分配方法、裝置及電子設備
US11195231B2 (en) Transaction processing in a service blockchain
WO2021042809A1 (zh) 一种基于区块链的资产申购方法、装置及电子设备
WO2021008122A1 (zh) 基于区块链的虚拟资源分配方法及装置、电子设备
WO2021017438A1 (zh) 基于区块链的电子票据作废方法及装置、电子设备
CN110009489B (zh) 基于区块链的资产转移方法及装置、电子设备
WO2021042811A1 (zh) 一种基于区块链的资产筛选方法、装置及电子设备
US11429983B2 (en) Blockchain-based bill write-off method, apparatus, electronic device, and storage medium
WO2021017429A1 (zh) 基于区块链的票据实名领取方法、装置及电子设备
WO2021017439A1 (zh) 基于区块链的电子票据号码申领方法及装置、电子设备
WO2021017442A1 (zh) 基于区块链的电子票据报销方法及装置、电子设备
CN111738724B (zh) 跨境资源转移真实性审核方法及装置、电子设备
WO2021042810A1 (zh) 基于区块链的资产清偿方法及装置、电子设备
CN111383119A (zh) 一种基于区块链的资产管理方法、装置及电子设备
WO2021017432A1 (zh) 一种基于区块链的报销费用分割方法、装置及电子设备
US10789628B2 (en) Blockchain-based bill number allocation method, apparatus and electronic device
CN111383118A (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: 20848278

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

Country of ref document: EP

Kind code of ref document: A1