CN111026789B - Block chain-based electronic bill query method and device and electronic equipment - Google Patents

Block chain-based electronic bill query method and device and electronic equipment Download PDF

Info

Publication number
CN111026789B
CN111026789B CN201911207011.6A CN201911207011A CN111026789B CN 111026789 B CN111026789 B CN 111026789B CN 201911207011 A CN201911207011 A CN 201911207011A CN 111026789 B CN111026789 B CN 111026789B
Authority
CN
China
Prior art keywords
authorization
identification
ticket
electronic bill
authorized party
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201911207011.6A
Other languages
Chinese (zh)
Other versions
CN111026789A (en
Inventor
段金明
金戈
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ant Blockchain Technology Shanghai Co Ltd
Original Assignee
Ant Blockchain Technology Shanghai Co Ltd
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 Ant Blockchain Technology Shanghai Co Ltd filed Critical Ant Blockchain Technology Shanghai Co Ltd
Priority to CN201911207011.6A priority Critical patent/CN111026789B/en
Publication of CN111026789A publication Critical patent/CN111026789A/en
Application granted granted Critical
Publication of CN111026789B publication Critical patent/CN111026789B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2471—Distributed queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • 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
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Development Economics (AREA)
  • Accounting & Taxation (AREA)
  • Databases & Information Systems (AREA)
  • Finance (AREA)
  • Marketing (AREA)
  • General Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Data Mining & Analysis (AREA)
  • Technology Law (AREA)
  • Computing Systems (AREA)
  • Fuzzy Systems (AREA)
  • Mathematical Physics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Software Systems (AREA)
  • Computational Linguistics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

One or more embodiments of the present specification provide an electronic bill query method and apparatus based on a block chain, and an electronic device, which are applied to an invoice service platform, and include: receiving an electronic bill query request which is sent by a bill user and corresponds to a target electronic bill stored in the block chain; the electronic bill query request comprises an identification of a target electronic bill and an authorization voucher which is uniquely corresponding to a bill user and the target electronic bill; creating an electronic bill query transaction based on the electronic bill query request, issuing the electronic bill query transaction to the blockchain, responding to the electronic bill query transaction by the nodes of the blockchain, calling an intelligent contract deployed on the blockchain, and verifying a bill user based on an authorization certificate; and when the ticket user passes the verification, transmitting the target electronic ticket corresponding to the identification of the target electronic ticket to the ticket user so as to execute business processing based on the target electronic ticket by the ticket user.

Description

Block chain-based electronic bill query method and device and electronic equipment
Technical Field
One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a method and an apparatus for querying an electronic ticket based on a blockchain, and an electronic device.
Background
The block chain technology, also called distributed ledger technology, is an emerging technology in which several computing devices participate in "accounting" together, and a complete distributed database is maintained together. The blockchain technology has been widely used in many fields due to its characteristics of decentralization, transparency, participation of each computing device in database records, and rapid data synchronization between computing devices.
Disclosure of Invention
The present specification provides an electronic bill query method based on a block chain, which is applied to an invoice service platform and includes:
receiving an electronic bill query request which is sent by a bill user and corresponds to a target electronic bill stored in the block chain; the electronic bill query request comprises an identifier of the target electronic bill and an authorization voucher which uniquely corresponds to the bill user and the target electronic bill;
creating an electronic bill query transaction based on the electronic bill query request, issuing the electronic bill query transaction to the blockchain, responding to the electronic bill query transaction by a node of the blockchain, calling an intelligent contract deployed on the blockchain, and verifying the bill user based on the authorization certificate;
and when the ticket user passes the verification, sending a target electronic ticket corresponding to the identification of the target electronic ticket to the ticket user so as to execute business processing based on the target electronic ticket by the ticket user.
Optionally, the electronic ticket inquiry request further comprises an identification of the ticketing party;
the verifying the ticketing party based on the authorization credential comprises:
determining whether the identification of the authorized party in the authorization voucher is matched with the identification of the ticket user, and determining whether the identification of the electronic ticket in the authorization voucher is matched with the identification of the target electronic ticket;
and if the identification of the authorized party in the authorization voucher is matched with the identification of the ticket user and the identification of the electronic ticket in the authorization voucher is matched with the identification of the target electronic ticket, determining that the ticket user passes the verification.
Optionally, the electronic ticket inquiry request further comprises an identification of the ticketing party;
the verifying the ticketing party based on the authorization credential comprises:
determining whether the identification of the authorized party in the authorization voucher is matched with the identification of the ticket user, and determining whether the identification of the electronic ticket in the authorization voucher is matched with the identification of the target electronic ticket;
determining whether the authorization credential is valid based on a validity period in the authorization credential;
and if the identification of the authorized party in the authorization voucher is matched with the identification of the ticket user, the identification of the electronic ticket in the authorization voucher is matched with the identification of the target electronic ticket, and the authorization voucher is valid, determining that the ticket user passes the verification.
Optionally, the sending, to the ticket consumer, the target electronic ticket corresponding to the identifier of the target electronic ticket when the ticket consumer passes the verification, includes:
and in response to the monitored verification passing event which is generated by the intelligent contract and corresponds to the ticket user, searching a target electronic bill which corresponds to the identification of the target electronic bill in the block chain, and sending the target electronic bill to the ticket user.
Optionally, the target electronic bill stored in the block chain is the encrypted target electronic bill obtained by encrypting the target electronic bill based on a preset encryption algorithm;
the sending the target electronic bill corresponding to the identification of the target electronic bill to the ticket user to execute business processing by the ticket user based on the target electronic bill comprises the following steps:
and sending the encrypted target electronic bill to the bill user, so that the bill user decrypts the encrypted target electronic bill based on an encryption algorithm to obtain the target electronic bill, and executing service processing based on the target electronic bill.
Optionally, the method further comprises:
receiving an electronic bill authorization request which is sent by an authorization party and corresponds to the target electronic bill; wherein the electronic bill authorization request comprises the identifier of the authorizing party, the identifier of the authorized party and the identifier of the target electronic bill;
determining whether the authorizer has authorization rights for the target electronic ticket based on the identity of the authorizer;
if the authorizer has the authorization authority of the target electronic bill, generating the authorization voucher based on the identification of the authorized party and the identification of the target electronic bill;
determining a public key of the authorized party based on the identifier of the authorized party, and encrypting the authorization certificate based on the public key of the authorized party;
and sending the encrypted authorization certificate to the authorized party, so that the authorized party decrypts the encrypted authorization certificate based on the private key of the authorized party to obtain the authorization certificate.
Optionally, the determining whether the authorizer has the authorization authority of the target electronic ticket based on the identifier of the authorizer includes:
determining whether the authorized party is a party related to the target electronic ticket based on the identification of the authorized party; wherein the related parties comprise an invoicing party, an invoicee party and a tax bureau;
and if the authorizer is the related party of the target electronic bill, determining that the authorizer has the authorization authority of the target electronic bill.
Optionally, the method further comprises:
and issuing the encrypted authorization certificate to the block chain for storing the certificate.
Optionally, the sending the encrypted authorization credential to the authorized party to decrypt the encrypted authorization credential based on a private key of the authorized party by the authorized party to obtain the authorization credential includes:
receiving an authorization certificate acquisition request which is sent by the authorized party and corresponds to the target electronic bill; wherein the authorization credential acquisition request includes an identification of the authorized party;
determining whether the authorized party has the acquisition right of the authorization credential based on the identification of the authorized party;
and if the authorized party has the acquisition right of the authorization certificate, sending the encrypted authorization certificate to the authorized party so that the authorized party decrypts the encrypted authorization certificate based on the private key of the authorized party to obtain the authorization certificate.
Optionally, the determining whether the authorized party has the right to acquire the authorization credential based on the identifier of the authorized party includes:
determining whether the identification of the authorized party in the authorization certificate acquisition request is matched with the identification of the authorized party in the electronic bill authorization request;
and if the identification of the authorized party in the authorization certificate acquisition request is matched with the identification of the authorized party in the electronic bill authorization request, determining that the authorized party has the acquisition authority of the authorization certificate.
Optionally, the authorization credential obtaining request is sent by the authorized party when receiving a notification message sent by the invoice service platform; the notification message is sent by the invoice service platform when the authorization credential is encrypted.
This specification also provides an electronic bill inquiry apparatus based on a block chain, which is applied to an invoice service platform, and includes:
the first receiving module is used for receiving an electronic bill query request which is sent by a bill user and corresponds to a target electronic bill stored in the block chain; the electronic bill query request comprises an identifier of the target electronic bill and an authorization voucher which uniquely corresponds to the bill user and the target electronic bill;
the verification module is used for creating an electronic bill query transaction based on the electronic bill query request and issuing the electronic bill query transaction to the block chain, responding to the electronic bill query transaction by a node of the block chain, calling an intelligent contract deployed on the block chain and verifying the ticket user based on the authorization certificate;
and the first sending module is used for sending the target electronic bill corresponding to the identification of the target electronic bill to the ticket user when the ticket user passes the verification so as to execute business processing based on the target electronic bill by the ticket user.
Optionally, the electronic ticket inquiry request further comprises an identification of the ticketing party;
the verifying the ticketing party based on the authorization credential comprises:
determining whether the identification of the authorized party in the authorization voucher is matched with the identification of the ticket user, and determining whether the identification of the electronic ticket in the authorization voucher is matched with the identification of the target electronic ticket;
and if the identification of the authorized party in the authorization voucher is matched with the identification of the ticket user and the identification of the electronic ticket in the authorization voucher is matched with the identification of the target electronic ticket, determining that the ticket user passes the verification.
Optionally, the electronic ticket inquiry request further comprises an identification of the ticketing party;
the verifying the ticketing party based on the authorization credential comprises:
determining whether the identification of the authorized party in the authorization voucher is matched with the identification of the ticket user, and determining whether the identification of the electronic ticket in the authorization voucher is matched with the identification of the target electronic ticket;
determining whether the authorization credential is valid based on a validity period in the authorization credential;
and if the identification of the authorized party in the authorization voucher is matched with the identification of the ticket user, the identification of the electronic ticket in the authorization voucher is matched with the identification of the target electronic ticket, and the authorization voucher is valid, determining that the ticket user passes the verification.
Optionally, the first sending module:
and in response to the monitored verification passing event which is generated by the intelligent contract and corresponds to the ticket user, searching a target electronic bill which corresponds to the identification of the target electronic bill in the block chain, and sending the target electronic bill to the ticket user.
Optionally, the target electronic bill stored in the block chain is the encrypted target electronic bill obtained by encrypting the target electronic bill based on a preset encryption algorithm;
the first sending module:
and sending the encrypted target electronic bill to the bill user, so that the bill user decrypts the encrypted target electronic bill based on an encryption algorithm to obtain the target electronic bill, and executing service processing based on the target electronic bill.
Optionally, the apparatus further comprises:
the second receiving module is used for receiving an electronic bill authorization request which is sent by an authorization party and corresponds to the target electronic bill; wherein the electronic bill authorization request comprises the identifier of the authorizing party, the identifier of the authorized party and the identifier of the target electronic bill;
a determination module that determines whether the authorizer has authorization rights for the target electronic ticket based on the identity of the authorizer;
a generation module, for generating the authorization voucher based on the identifier of the authorized party and the identifier of the target electronic bill if the authorized party has the authorization authority of the target electronic bill;
the encryption module is used for determining the public key of the authorized party based on the identifier of the authorized party and encrypting the authorization certificate based on the public key of the authorized party;
and the second sending module is used for sending the encrypted authorization certificate to the authorized party so that the authorized party decrypts the encrypted authorization certificate based on the private key of the authorized party to obtain the authorization certificate.
Optionally, the determining module:
determining whether the authorized party is a party related to the target electronic ticket based on the identification of the authorized party; wherein the related parties comprise an invoicing party, an invoicee party and a tax bureau;
and if the authorizer is the related party of the target electronic bill, determining that the authorizer has the authorization authority of the target electronic bill.
Optionally, the apparatus further comprises:
and the certificate storage module is used for issuing the encrypted authorization certificate to the block chain for certificate storage.
Optionally, the second sending module:
receiving an authorization certificate acquisition request which is sent by the authorized party and corresponds to the target electronic bill; wherein the authorization credential acquisition request includes an identification of the authorized party;
determining whether the authorized party has the acquisition right of the authorization credential based on the identification of the authorized party;
and if the authorized party has the acquisition right of the authorization certificate, sending the encrypted authorization certificate to the authorized party so that the authorized party decrypts the encrypted authorization certificate based on the private key of the authorized party to obtain the authorization certificate.
Optionally, the second sending module:
determining whether the identification of the authorized party in the authorization certificate acquisition request is matched with the identification of the authorized party in the electronic bill authorization request;
and if the identification of the authorized party in the authorization certificate acquisition request is matched with the identification of the authorized party in the electronic bill authorization request, determining that the authorized party has the acquisition authority of the authorization certificate.
Optionally, the authorization credential obtaining request is sent by the authorized party when receiving a notification message sent by the invoice service platform; the notification message is sent by the invoice service platform when the authorization credential is encrypted.
This specification also proposes an electronic device including:
a processor;
a memory for storing processor-executable instructions;
wherein the processor implements the steps of the above method by executing the executable instructions.
The present specification also contemplates a computer-readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the above-described method.
In the above technical solution, on one hand, the authorizing party may issue, to the authorized party, an authorization credential generated based on the identifier of the authorized party and the identifier of the electronic ticket that the authorized party needs to use, so as to realize authorization of the authorized party corresponding to the authorized party and the electronic ticket.
On the other hand, when the ticket user applies for a certain electronic ticket stored in the query block chain, the invoice service platform can verify the ticket user based on an authorization certificate provided by the ticket user to determine whether the ticket user has authorization corresponding to the ticket user and the electronic ticket, and when the ticket user passes the verification, the electronic ticket is sent to the ticket user for the ticket user to use the electronic ticket.
Since the authorization ticket uniquely corresponds to the authorized party and the electronic ticket that the authorized party needs to use, if it is determined that the ticket party is authenticated based on the authorization ticket provided by the ticket party, it can be determined that the ticket party has the authorization corresponding to the ticket party and the electronic ticket, that is, the electronic ticket can be used. If the authorization voucher is leaked, so that other ticket providers provide the authorization voucher when applying for inquiring the electronic ticket, the electronic ticket cannot be acquired because the identification of the authorized party in the authorization voucher is not matched with the identifications of the other ticket providers.
Namely, by adopting the mode, the leakage of the electronic bill caused by the leakage of the authorization voucher can be avoided, and the data security of the electronic bill stored in the block chain is ensured.
Drawings
FIG. 1 is a schematic diagram of a creation flow of an intelligent contract shown herein;
FIG. 2 is a schematic diagram illustrating the call flow of an intelligent contract shown in this specification;
FIG. 3 is a schematic diagram of the creation and invocation flow of an intelligent contract shown in the present specification;
FIG. 4 is a schematic diagram of an electronic ticket interrogation system based on a blockchain as shown in an exemplary embodiment of the present specification;
FIG. 5 is a block chain-based electronic ticket lookup method for authorization flow according to an exemplary embodiment of the present disclosure;
FIG. 6 is a schematic diagram of an electronic ticket authorization interface shown in an exemplary embodiment of the present description;
FIG. 7 is a diagram illustrating an authorization flow in another block chain-based electronic ticket lookup method according to an exemplary embodiment of the present specification;
FIG. 8 is a diagram illustrating a query flow in a blockchain-based electronic ticket querying method in an exemplary embodiment of the present specification;
fig. 9 is a schematic structural diagram of an electronic device shown in an exemplary embodiment of the present specification;
fig. 10 is a block diagram of an electronic ticket querying device based on a block chain according to an exemplary embodiment of the present specification.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.
It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.
Blockchains are generally divided into three types: public chain (Public Blockchain), Private chain (Private Blockchain) and alliance chain (Consortium Blockchain). Furthermore, there may be a combination of the above types, such as private chain + federation chain, federation chain + public chain, and so on.
Among them, the most decentralized is the public chain. The public chain is represented by bitcoin and ether house, and participants (also called nodes in the block chain) joining the public chain can read data records on the chain, participate in transactions, compete for accounting rights of new blocks, and the like. Moreover, each node can freely join or leave the network and perform related operations.
Private chains are the opposite, with the network's write rights controlled by an organization or organization and the data read rights specified by the organization. Briefly, a private chain may be a weakly centralized system with strict restrictions on nodes and a small number of nodes. This type of blockchain is more suitable for use within a particular establishment.
A federation chain is a block chain between a public chain and a private chain, and "partial decentralization" can be achieved. Each node in a federation chain typically has a physical organization or organization corresponding to it; the nodes are authorized to join the network and form a benefit-related alliance, and block chain operation is maintained together.
Based on the basic characteristics of a blockchain, a blockchain is usually composed of several blocks. The time stamps corresponding to the creation time of the block are recorded in the blocks respectively, and all the blocks form a time-ordered data chain according to the time stamps recorded in the blocks strictly.
The real data generated by the physical world can be constructed into a standard transaction (transaction) format supported by a block chain, then is issued to the block chain, the node equipment in the block chain performs consensus processing on the received transaction, and after the consensus is achieved, the node equipment serving as an accounting node in the block chain packs the transaction into a block and performs persistent evidence storage in the block chain.
The consensus algorithm supported in the blockchain may include:
the first kind of consensus algorithm, namely the consensus algorithm that the node device needs to contend for the accounting right of each round of accounting period; consensus algorithms such as Proof of Work (POW), Proof of equity (POS), Proof of commission rights (DPOS), etc.;
the second kind of consensus algorithm, namely the consensus algorithm which elects accounting nodes in advance for each accounting period (without competing for accounting right); for example, a consensus algorithm such as a Practical Byzantine Fault Tolerance (PBFT) is used.
In a blockchain network employing a first type of consensus algorithm, node devices competing for billing rights can execute a transaction upon receipt. One of the node devices competing for the accounting right may win in the process of competing for the accounting right in the current round, and become an accounting node. The accounting node may package the received transaction with other transactions to generate a latest block and send the generated latest block or a block header of the latest block to other node devices for consensus.
In the block chain network adopting the second type of consensus algorithm, the node equipment with the accounting right is agreed before accounting in the current round. Thus, the node device, after receiving the transaction, may send the transaction to the accounting node if it is not the accounting node of its own round. For the accounting node of the current round, the transaction may be performed during or before packaging the transaction with other transactions to generate the latest block. After generating the latest block, the accounting node may send the latest block or a block header of the latest block to other node devices for consensus.
As described above, regardless of which consensus algorithm is used by the blockchain, the accounting node of the current round may pack the received transaction 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 verification. If no problem is verified after other node equipment receives the latest block or the block header of the latest block, the latest block can be added to the tail of the original block chain, so that the accounting process of the block chain is completed. The transaction contained in the block may also be performed by other nodes in verifying the new block or block header sent by the accounting node.
In practical applications, whether public, private, or alliance, it is possible to provide the functionality of a Smart contract (Smart contract). An intelligent contract on a blockchain is a contract on a blockchain that can be executed triggered by a transaction. An intelligent contract may be defined in the form of code.
Taking an Etherhouse as an example, a user is supported to create and call some complex logic in the Etherhouse network. The ethernet workshop is used as a programmable block chain, and the core of the ethernet workshop is an ethernet workshop virtual machine (EVM), and each ethernet workshop node can run the EVM. The EVM is a well-behaved virtual machine through which various complex logic can be implemented. The user issuing and invoking smart contracts in the etherhouse is running on the EVM. In fact, the EVM directly runs virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"), so the intelligent contract deployed on the blockchain may be bytecode.
After Bob sends a Transaction (Transaction) containing information to create a smart contract to the ethernet network, each node can execute the Transaction in the EVM, as shown in fig. 1. In fig. 1, the From field of the transaction is used To record the address of the account initiating the creation of the intelligent contract, the contract code stored in the field value of the Data field of the transaction may be bytecode, and the field value of the To field of the transaction is a null account. After the nodes reach the agreement through the consensus mechanism, the intelligent contract is successfully created, and the follow-up user can call the intelligent contract.
After the intelligent contract is established, a contract account corresponding to the intelligent contract appears on the block chain, and the block chain has a specific address; for example, "0 x68e12cf284 …" in each node in fig. 1 represents the address of the contract account created; the contract Code (Code) and account store (Storage) will be maintained in the account store for that contract account. The behavior of the intelligent contract is controlled by the contract code, while the account storage of the intelligent contract preserves the state of the contract. In other words, the intelligent contract causes a virtual account to be generated on the blockchain that contains the contract code and account storage.
As mentioned above, the Data field containing the transaction that created the intelligent contract may hold the byte code of the intelligent contract. A bytecode consists of a series of bytes, each of which can identify an operation. Based on the multiple considerations of development efficiency, readability and the like, a developer can select a high-level language to write intelligent contract codes instead of directly writing byte codes. For example, the high-level language may employ a language such as Solidity, Serpent, LLL, and the like. For intelligent contract code written in a high-level language, the intelligent contract code can be compiled by a compiler to generate byte codes which can be deployed on a blockchain.
Taking the Solidity language as an example, the contract code written by it is very similar to a Class (Class) in the object-oriented programming language, and various members including state variables, functions, function modifiers, events, etc. can be declared in one contract. A state variable is a value permanently stored in an account Storage (Storage) field of an intelligent contract to save the state of the contract.
As shown in FIG. 2, still taking the Etherhouse as an example, after Bob sends a transaction containing the information of the calling intelligent contract to the Etherhouse network, each node can execute the transaction in the EVM. In fig. 4, the From field of the transaction is used To record the address of the account initiating the invocation of the smart contract, the To field is used To record the address of the invoked smart contract, and the Data field of the transaction is used To record the method and parameters of the invocation of the smart contract. After invoking the smart contract, the account status of the contract account may change. Subsequently, a client may view the account status of the contract account through the accessed block link point (e.g., node 1 in fig. 2).
The intelligent contract can be independently executed at each node in the blockchain network in a specified mode, and all execution records and data are stored on the blockchain, so that after the transaction is executed, transaction certificates which cannot be tampered and lost are stored on the blockchain.
A schematic diagram of creating an intelligent contract and invoking the intelligent contract is shown in fig. 3. An intelligent contract is created in an Ethernet workshop and needs to be subjected to the processes of compiling the intelligent contract, changing the intelligent contract into byte codes, deploying the intelligent contract to a block chain and the like. The intelligent contract is called in the Ethernet workshop, a transaction pointing to the intelligent contract address is initiated, the EVM of each node can respectively execute the transaction, and the intelligent contract code is distributed and operated in the virtual machine of each node in the Ethernet workshop network.
Conventional blockchain projects, represented by etherhouses, typically support conversion of real-world currency into virtual tokens that can be circulated through the chain in order to effect a "value transfer" over the blockchain.
In the blockchain field, for some blockchain items derived from the ethernet-based architecture (such as ant blockchains), the function of converting real-world currency into virtual tokens that can circulate on the chains is generally no longer supported; instead, in these blockchain projects, some non-monetary attributes of the physical assets in the real world may be converted into virtual assets that can be circulated over the blockchain.
It should be noted that converting an entity asset having a non-monetary attribute in the real world into a virtual asset on a blockchain generally refers to a process of "anchoring" the entity asset and a virtual asset on the blockchain to serve as a value support for the virtual assets, and further generating a virtual asset on the blockchain which is matched with the value of the entity asset and can be circulated between blockchain accounts on the blockchain.
In the implementation process, the account types supported by the blockchain can be expanded, and an asset account (also called an asset object) is expanded on the basis of the account types supported by the blockchain; for example, an asset account can be expanded on the basis of an external account and a contract account supported by an Ethernet; the expanded asset account is a virtual asset which can support the real-world non-monetary property of the physical asset as value and can be circulated between the blockchain accounts.
For users accessing such a blockchain, in addition to completing the creation of user accounts and intelligent contracts on the blockchain, a virtual asset matched with the entity asset value of non-monetary attributes of the real world is created on the blockchain, and circulation is performed on the blockchain;
for example, a user may convert physical assets of non-monetary attributes, such as real estate, stocks, loan contracts, notes, accounts receivable, etc., held to value-matched virtual assets for circulation over a blockchain.
The above asset account may be maintained by a structure, specifically, the account status of the account may be maintained by a structure. The content of the structure of the asset account may be the same as that of the ether house, and may be designed based on actual requirements;
in one implementation, for example, the content of the structure body of the asset account is the same as that of an ethernet bay, the structure body of the asset account may also include the fields of Balance, Nonce, Code, and Storage described above.
It should be noted that, in an ethernet, the Balance field is usually used to maintain the current account Balance of the account; for the block chain project derived based on the ethernet framework, since it may not support the conversion of real-world currency into virtual tokens that can be circulated on the chain, in such block chains, the meaning of the Balance field may be extended, and the Balance of the account is no longer represented, but is used to maintain the address information of the asset account corresponding to the "virtual asset" held by the account. In practical application, address information of asset accounts corresponding to multiple virtual assets can be maintained in the Balance field.
In this case, the external account, the contract account, and the asset account shown above can hold the virtual asset by adding address information of the asset account corresponding to the "virtual asset" that needs to be held in the Balance field. That is, in addition to the external account and the contract account, the asset account itself may hold the virtual asset.
For an asset account, Nonce, the field value of the Code field may or may not be null; and the field value of the Storage field may no longer be a null value; the Storage field may be used to maintain the asset status of the "virtual asset" corresponding to the asset account. The specific manner of maintaining the asset state of the "virtual asset" corresponding to the asset account in the Storage field can be flexibly designed based on requirements, and is not described in detail.
In the blockchain project derived based on the framework of the EtherFang, a user can create a virtual asset on the blockchain that matches the value of the real-world non-monetary attribute physical asset by the implementation shown below:
in one implementation, the transaction types supported by the blockchain may be extended to extend a transaction for creating virtual assets; for example, the types of transactions supported by the etherhouse typically include normal transfer transactions, transactions to create smart contracts, and transactions to invoke smart contracts, and a transaction to create virtual assets may be expanded based on the above three types of transactions.
In this case, a user may create a virtual asset for the user by issuing a transaction into the blockchain network by the client, which is performed by a node device in the blockchain in the local EVM. When the node devices reach the agreement through the consensus mechanism, the virtual asset is successfully created, and an asset account corresponding to the virtual asset appears on the blockchain and has a specific address.
In another implementation, intelligent contracts for creating virtual assets may also be deployed on blockchains; the process of deploying the intelligent contract for creating the virtual asset is not described in detail.
In this case, the user may create a virtual asset for the user by issuing a transaction for invoking the intelligent contract into the blockchain network by the client, executing the transaction in the local EVM by the node device in the blockchain, and running a contract code associated with the intelligent contract in the EVM. When the node devices reach the agreement through the consensus mechanism, the virtual asset is successfully created, and an asset account corresponding to the virtual asset appears on the blockchain and has a specific address.
Of course, for some blockchain items derived based on the ethernet framework, if the blockchain items also support the function of converting real-world currency into virtual tokens that can circulate on the chain, some non-currency property entity assets in the real world can still be converted into a form of virtual tokens that can circulate on the blockchain, and the virtual tokens circulate on the blockchain, which is not described in detail in this specification.
In a cross-chain scenario, multiple blockchains may implement cross-chain docking through cross-chain relays.
The cross-link relay can be respectively connected with the block chains through the bridging interfaces, and the cross-link data synchronization among the block chains is completed based on the realized data carrying logic.
The chain-crossing technology used for realizing the chain-crossing relay is not particularly limited in this specification; for example, in practical applications, a plurality of block chains can be connected by a chain-crossing mechanism such as side chain technology, notary technology, and the like.
After a plurality of block chains are connected in a butt joint mode through cross-chain relays, data on other block chains can be read and authenticated between the block chains, and intelligent contracts deployed on other block chains can be called through the cross-chain relays.
The intelligent contract deployed on the block chain can use the data stored on the block chain, and can also use the data on the data entity outside the chain through an Oracle prediction machine, so as to realize the data interaction between the intelligent contract and the data entity of the real world. Data entities outside the chain may include, for example, centralized servers or data centers deployed outside the chain, and so on.
Unlike cross-link relays, the function of the Oracle;
that is, the cross-link relay is used to connect two blockchains, and the Oracle ora.
Referring to fig. 4, fig. 4 is a schematic diagram of an electronic ticket querying system based on a block chain according to an exemplary embodiment of the present disclosure.
In the block chain-based electronic ticket inquiry system as shown in fig. 4, an electronic ticket can be credited in the block chain.
For example, for a certain bill, the payee of the bill may, after confirming receipt of payment, issue an electronic bill corresponding to the bill to the payer of the bill, and issue the electronic bill to the blockchain for deposit; the process of issuing the electronic ticket to the blockchain for storing the certificate may refer to the process of performing persistent certificate storage on the real data generated in the physical world in the blockchain, which is not described herein again. In this case, the payee of the bill is the invoker of the electronic ticket, and the payer of the bill is the payee of the electronic ticket.
The invoice business platform can execute business processing related to the electronic bill based on the electronic bill stored in the block chain, such as: when a user needs to use a certain electronic bill, the electronic bill can be searched in the block chain, and the searched electronic bill is sent to the user so that the user can use the electronic bill.
In practical applications, for a certain electronic ticket, the electronic ticket is generally only allowed to be used by the invoicer, the invoicer and the tax authority of the electronic ticket (collectively referred to as the relevant party of the electronic ticket), i.e. the electronic ticket is generally only visible to the relevant party; if a third party other than the related party of the electronic bill also needs to use the electronic bill, the related party of the electronic bill needs to authorize the third party, and the third party can use the electronic bill after being authorized.
That is, for a certain electronic bill stored in the blockchain, the authorizing party can be a related party of the electronic bill, the authorized party can be a third party of the electronic bill, and the ticket using party is a third party of the electronic bill needing to use the electronic bill; the authorized party of the electronic ticket can also be used as a ticket user of the electronic ticket, and the electronic ticket can have a plurality of authorized parties and a plurality of ticket users.
It should be noted that the invoice service platform and the node of the blockchain may be deployed on the same electronic device, or may be deployed on different electronic devices; the electronic device may be a server, a computer, a mobile phone, a tablet device, a notebook computer or a palmtop computer (PDAs), etc.; this is not limited by the present description.
In the related art, before issuing a certain electronic ticket issued by a biller to the blockchain for deposit, the biller may encrypt the electronic ticket based on a key preset by a technician, and then issue the encrypted electronic ticket to the blockchain for deposit.
That is, all electronic tickets stored in the blockchain may be encrypted electronic tickets.
The invoicing party can be used as an authorizing party and informs a third party of the electronic bill which is used as an authorized party of the key so as to authorize the third party.
When the electronic bill needs to be used, the third party can serve as a bill using party and send an electronic bill query request corresponding to the electronic bill to the invoice service platform so as to trigger the invoice service platform to search the encrypted electronic bill in the block chain and send the searched encrypted electronic bill to the third party, so that the third party can decrypt the encrypted electronic bill based on the authorized key to obtain the electronic bill.
However, in this way, since the authorizer needs to notify the authorized party of the key used for encrypting the electronic ticket during authorization, the leakage of the key and thus the electronic ticket is likely to occur, and the data security is poor.
The present specification is described below in terms of both the authorization of an electronic ticket and the interrogation of an electronic ticket.
(1) Authorization of electronic tickets
Referring to fig. 5, fig. 5 is a schematic diagram illustrating an authorization flow in an electronic ticket querying method based on a blockchain according to an exemplary embodiment of the present disclosure.
The authorization process can be applied to an invoice service platform in the block chain-based electronic bill query system as shown in fig. 4, and comprises the following steps:
step 502, receiving an electronic bill authorization request corresponding to a target electronic bill sent by an authorizing party; wherein the electronic bill authorization request comprises the identifier of the authorizing party, the identifier of the authorized party and the identifier of the target electronic bill;
step 504, determining whether the authorized party has the authorization authority of the target electronic bill based on the identification of the authorized party;
step 506, if the authorizer has the authorization authority of the target electronic bill, generating the authorization voucher based on the identification of the authorized party and the identification of the target electronic bill;
step 508, determining the public key of the authorized party based on the identifier of the authorized party, and encrypting the authorization certificate based on the public key of the authorized party;
step 510, sending the encrypted authorization credential to the authorized party, so that the authorized party decrypts the encrypted authorization credential based on the private key of the authorized party to obtain the authorization credential.
In this embodiment, when an authorizing party authorizes a certain electronic bill (called a target electronic bill) stored in the block chain to a certain authorized party, an electronic bill authorization request corresponding to the target electronic bill may be sent to the invoice service platform; wherein, the electronic bill authorization request can include: an identification of the authorized party; an identification of the authorized party; and, an identification of the target electronic ticket.
In practical application, on one hand, in order to facilitate the invoice service platform to distinguish different users, each user may open an account corresponding to the user on the invoice service platform. In this case, the identifier of the authorizing party may be an identifier (for example, an identifier such as an account name or an account number) of an account opened by the authorizing party on the invoice service platform, and the identifier of the authorized party may be an identifier of an account opened by the authorized party on the invoice service platform.
On the other hand, the identifier of the target electronic bill may be an identifier such as an invoice code or an invoice number of the target electronic bill, or a data segment (for example, data such as an invoicing amount and/or an invoicing date) of the target electronic bill may be used as the identifier of the target electronic bill.
Specifically, when the authorized party needs to authorize the target electronic ticket, the authorized party can execute the operation corresponding to the target electronic ticket on the electronic device used by the authorized party. When the electronic device detects the operation, the electronic device can construct the electronic bill authorization request based on the identifier of the authorizing party, the identifier of the authorized party and the identifier of the target electronic bill, and send the electronic bill authorization request to the invoice service platform.
For example, the invoice service platform may first provide a user login interface to the authorizer, that is, the invoice service platform sends the relevant data of the user login interface to the electronic device used by the authorizer, so that the electronic device displays the user login interface to the authorizer. The authorizing party can input the account name and the password of the account through the user login interface, and the electronic equipment used by the authorizing party sends the account name and the password to the invoice service platform. The invoice service platform can verify the authorized party based on the account name and the password, and provide an electronic bill authorization interface for the authorized party when the authorized party passes the verification, such as: the invoice service platform can judge whether the account name is matched with the password or not based on the corresponding relation between the account name and the password which are locally stored, and if so, the authorization party can be determined to pass the verification, so that the electronic bill authorization interface can be provided for the authorization party.
Taking the electronic ticket authorization interface shown in fig. 6 as an example, the authorizer may input the identifier of the authorized party and the identifier of the target electronic ticket into the electronic ticket authorization interface, and perform a click operation on an "authorization" button in the electronic ticket authorization interface after the input is completed. When the electronic device used by the authorizer detects the click operation, the electronic device can construct the electronic bill authorization request based on the identifier of the authorizer, the identifier of the authorized party and the identifier of the target electronic bill, and send the electronic bill authorization request to the invoice service platform.
In this embodiment, when receiving the electronic ticket authorization request, the invoice service platform may determine whether the authorizer (i.e., the authorizer corresponding to the identifier of the authorizer in the electronic ticket authorization request) has the authorization right of the target electronic ticket based on the identifier of the authorizer in the electronic ticket authorization request.
In one embodiment, the electronic device used by the authorizing party can also digitally sign the electronic bill authorization request when constructing the electronic bill authorization request. When the invoice service platform receives the electronic bill authorization request, the digital signature of the electronic bill authorization request can be verified, and when the digital signature passes the verification, whether the authorizer has the authorization authority of the target electronic bill is determined based on the identifier of the authorizer in the electronic bill authorization request.
In one illustrated embodiment, the invoice service platform can determine whether the authorized party is the relevant party (i.e. the invoicing party, the ticketed party or the tax authority) of the target electronic ticket based on the identification of the authorized party in the electronic ticket authorization request.
Specifically, the invoice service platform may match an identifier of an authorizer in the electronic ticket authorization request with an identifier of a biller of the target electronic ticket (i.e., an identifier of an account opened by the biller on the invoice service platform), an identifier of a ticketed receiver of the target electronic ticket (i.e., an identifier of an account opened by the ticketed receiver on the invoice service platform), and an identifier of a tax bureau (i.e., an identifier of an account opened by the tax bureau on the invoice service platform), respectively. If the identifier of the authorized party in the electronic bill authorization request is matched with any one of the three identifiers, the invoice service platform can determine that the authorized party is the related party of the target electronic bill.
If the authorizer is the related party of the target electronic bill, the invoice service platform can further determine that the authorizer has the authorization authority of the target electronic bill.
In this embodiment, the invoice service platform may generate an authorization credential based on the identifier of the authorized party and the identifier of the target electronic ticket when determining that the authorized party has the authorization authority of the target electronic ticket. In this case, since the authorization ticket includes the identification of the authorized party and the identification of the target electronic ticket, the authorization ticket is an authorization ticket uniquely corresponding to the authorized party that needs to use the target electronic ticket, that is, an authorization ticket uniquely corresponding to the authorized party and the target electronic ticket.
Further, the invoice service platform can determine the public key of the authorized party based on the identifier of the authorized party, and encrypt the generated authorization certificate based on the public key of the authorized party.
In practical application, the invoice service platform may store a corresponding relationship between the user identifier and the user public key. In this case, the invoice service platform may search the public key corresponding to the identifier of the authorized party in the correspondence, and determine the searched public key as the public key of the authorized party, so that the authorization credential may be encrypted based on the public key of the authorized party.
In this embodiment, when the authorization credential is encrypted, the invoice service platform may send the encrypted authorization credential to the authorized party. When the authorized party receives the encrypted authorization certificate, the encrypted authorization certificate can be decrypted based on the private key of the authorized party to obtain the authorization certificate; the public key of the authorized party and the private key of the authorized party form a public and private key pair specified in a pair of asymmetric encryption algorithms.
In an embodiment shown, in order to back up the authorization credential, the invoice service platform may also issue the encrypted authorization credential to the block chain for storage; the process of issuing the authorization credential to the blockchain for storing the credential may refer to the process of performing persistent storage on the real data generated in the physical world in the blockchain, which is not described herein again.
In this way, if the authorization credential held by the authorized party is lost subsequently, the invoice service platform may obtain the encrypted authorization credential stored in the blockchain, and send the obtained encrypted authorization credential to the authorized party.
It should be noted that, when the authorization credential is encrypted, the invoice service platform can actively send the encrypted authorization credential to the authorized party; or the authorized party sends an authorization certificate acquisition request corresponding to the target electronic bill to the invoice service platform so as to trigger the invoice service platform to send the encrypted authorization certificate to the authorized party.
Referring to fig. 7, fig. 7 is a schematic diagram illustrating an authorization flow in another block chain-based electronic ticket querying method according to an exemplary embodiment of the present disclosure.
In the second case, based on the authorization flow shown in fig. 5, the authorization flow may further include the following steps:
step 702, receiving an authorization credential obtaining request corresponding to the target electronic ticket sent by the authorized party; wherein the authorization credential acquisition request includes an identification of the authorized party;
step 704, determining whether the authorized party has the acquisition right of the authorization voucher based on the identification of the authorized party;
step 706, if the authorized party has the authorization credential obtaining right, sending the encrypted authorization credential to the authorized party, so that the authorized party decrypts the encrypted authorization credential based on the private key of the authorized party to obtain the authorization credential.
In this embodiment, the authorized party may send an authorization credential obtaining request corresponding to the target electronic ticket to the invoice service platform, so as to trigger the invoice service platform to send the encrypted authorization credential to the authorized party; wherein the authorization credential acquisition request may include an identification of the authorized party.
In one embodiment shown, the invoice service platform may send a notification message to the authorized party to instruct the authorized party to acquire the authorization credential when the encryption of the authorization credential is completed. When receiving the notification message, the authorized party may send an authorization credential obtaining request corresponding to the target electronic ticket to the invoice service platform to obtain the authorization credential.
In this embodiment, when receiving the authorization credential obtaining request, the invoice service platform may determine whether the authorized party (i.e., the authorized party corresponding to the identifier of the authorized party in the authorization credential obtaining request) has the authorization credential obtaining authority based on the identifier of the authorized party in the authorization credential obtaining request.
In one embodiment shown, the invoice service platform may match the identifier of the authorized party in the authorization document acquisition request with the identifier of the authorized party in the electronic ticket authorization request (i.e. the electronic ticket authorization request in step 702).
If the identifier of the authorized party in the authorization voucher acquisition request is matched with the identifier of the authorized party in the electronic bill authorization request, it indicates that the object to be authorized by the authorized party and the object requesting to acquire the authorization voucher are both the authorized parties, so that the invoice service platform can determine that the authorized party has the authorization voucher acquisition right.
In this embodiment, the invoice service platform may send the encrypted authorization credential to the authorized party when determining that the authorized party has the authorization credential acquisition right. When the authorized party receives the encrypted authorization credential, the authorized party can decrypt the encrypted authorization credential based on the private key of the authorized party to obtain the authorization credential.
(2) Query of electronic tickets
Referring to fig. 8, fig. 8 is a schematic diagram illustrating a query flow in an electronic ticket querying method based on a blockchain according to an exemplary embodiment of the present specification.
The authorization process can be applied to an invoice service platform in the block chain-based electronic bill query system as shown in fig. 4, and comprises the following steps:
step 802, receiving an electronic bill query request sent by a bill user and corresponding to a target electronic bill stored in the block chain; the electronic bill query request comprises an identifier of the target electronic bill and an authorization voucher which uniquely corresponds to the bill user and the target electronic bill;
step 804, creating an electronic bill query transaction based on the electronic bill query request, issuing the electronic bill query transaction to the blockchain, responding to the electronic bill query transaction by a node of the blockchain, calling an intelligent contract deployed on the blockchain, and verifying the ticket user based on the authorization certificate;
and 806, when the ticket user passes the verification, sending the target electronic ticket corresponding to the identification of the target electronic ticket to the ticket user so as to execute business processing based on the target electronic ticket by the ticket user.
In this embodiment, when a ticketing party needs to use a certain electronic ticket (referred to as a target electronic ticket) stored in the block chain, an electronic ticket query request corresponding to the target electronic ticket may be sent to the invoice service platform.
Specifically, when the ticket user needs to use the target electronic ticket, the ticket user can perform an operation corresponding to the target electronic ticket on the electronic device used by the ticket user. When the electronic equipment detects the operation, the electronic equipment can construct the electronic bill query request based on the identification of the target electronic bill and the authorization certificate held by the bill user, and send the electronic bill query request to the invoice service platform.
In this embodiment, when receiving the electronic ticket query request, the invoice service platform may create an electronic ticket query transaction based on the electronic ticket query request, and issue the electronic ticket query transaction to the block chain.
Specifically, when the electronic ticket query transaction is issued to the blockchain, the nodes of the blockchain may receive the electronic ticket query transaction and perform consensus processing on the electronic ticket query transaction. After agreement is reached, the nodes of the blockchain can package the electronic ticket inquiry transaction into blocks for persistent storage in the blockchain.
For the electronic bill query transaction packaged into a block, the node of the block chain may execute the electronic bill query transaction, that is, in response to the electronic bill query transaction, invoke an intelligent contract deployed on the block chain, and authenticate the ticket user based on the authorization credential (i.e., the authorization credential in the electronic bill query transaction).
In one embodiment, the identification of the ticket user and the identification of the target electronic ticket in the electronic ticket inquiring request are matched with the data in the authorization document, so that the ticket user can be authenticated.
Specifically, the node of the blockchain may determine whether the identifier of the authorized party in the authorization credential matches the identifier of the ticketing party in the electronic ticket query request by invoking the intelligent contract, and determine whether the identifier of the electronic ticket in the authorization credential matches the identifier of the target electronic ticket in the electronic ticket query request.
If the identification of the authorized party in the authorization voucher is matched with the identification of the ticket user, and the identification of the electronic ticket in the authorization voucher is matched with the identification of the target electronic ticket, the ticket user can be determined to be verified.
Further, in addition to determining whether the identity of the authorized party in the authorization ticket matches the identity of the ticketing party and whether the identity of the electronic ticket in the authorization ticket matches the identity of the target electronic ticket, the nodes of the blockchain may also determine whether the authorization ticket is valid based on the validity period in the authorization ticket by invoking the intelligent contract.
For example, assuming that the validity period of the authorization credential is before the adjustment of 12/1/23 in 2019 and the current time is at the adjustment of 13/11/30 in 2019, the authorization credential may be determined to be valid because the validity period of the authorization credential is later than the current time.
In another example, assuming that the authorization time in the authorization certificate is 23 o ' clock at 11/24/2019, the validity period is 7 days, and the current time is 13 o ' clock at 11/30/2019, the authorization certificate can be determined to be valid because the expiration time of the authorization certificate is 23 o ' clock at 12/1/2019, which is later than the current time.
In this case, if the identification of the authorized party in the authorization ticket matches the identification of the ticketing party, the identification of the electronic ticket in the authorization ticket matches the identification of the target electronic ticket, and the authorization ticket is valid, it can be determined that the ticketing party is authenticated.
By adopting the mode, the authorization certificate with the valid period can be issued to the third party of the electronic bill stored with the certificate in the block chain, so that the authorization of the third party with the limited time duration is realized, namely, the third party is only allowed to inquire the electronic bill within the time duration of the limited time duration, and the data security of the electronic bill stored with the certificate in the block chain can be improved.
In this embodiment, when the ticket customer is determined to be authenticated, an authentication pass event corresponding to the ticket customer may be generated by the intelligent contract. Specifically, the smart contract may store the generated validation pass event to a transaction log corresponding to the electronic ticket query transaction.
In practical application, the invoice service platform may perform log monitoring, so that when the invoice service platform monitors the verification passing event stored in the transaction log corresponding to the electronic bill query transaction, the target electronic bill (i.e., the electronic bill corresponding to the target electronic bill) is searched in the block chain based on the identifier of the target electronic bill to obtain the target electronic bill.
Or, the node of the blockchain may perform log monitoring, so that when the verification passing event stored in the transaction log corresponding to the electronic bill query transaction is monitored by the node of the blockchain, the target electronic bill is searched in the blockchain based on the identifier of the target electronic bill, and the searched target electronic bill is sent to the invoice service platform.
In this embodiment, when the invoice service platform acquires the target electronic ticket, the invoice service platform may further send the target electronic ticket to the ticket consumer, so that the ticket consumer performs service processing based on the target electronic ticket, for example: accounting, settlement and/or reimbursement, etc.
In one embodiment shown, in order to further improve the data security of the electronic bills stored in the blockchain, when a certain electronic bill is issued to the blockchain for storing, a user (e.g., a invoker of the electronic bill) who issues the electronic bill to the blockchain or the invoice service platform may encrypt a certain electronic bill based on a preset encryption algorithm and then issue the obtained encrypted electronic bill to the blockchain for storing; the encryption algorithm may be preset by a technician, and the encryption algorithm may be a symmetric encryption algorithm, an asymmetric encryption algorithm, or the like.
In this case, the invoice service platform acquires the encrypted target electronic bill, that is, the invoice service platform may send the encrypted target electronic bill to the ticket consumer. The ticket user can decrypt the encrypted target electronic ticket based on the encryption algorithm to obtain the target electronic ticket, so that business processing can be executed based on the target electronic ticket.
In the above technical solution, on one hand, the authorizing party may issue, to the authorized party, an authorization credential generated based on the identifier of the authorized party and the identifier of the electronic ticket that the authorized party needs to use, so as to realize authorization of the authorized party corresponding to the authorized party and the electronic ticket.
On the other hand, when the ticket user applies for a certain electronic ticket stored in the query block chain, the invoice service platform can verify the ticket user based on an authorization certificate provided by the ticket user to determine whether the ticket user has authorization corresponding to the ticket user and the electronic ticket, and when the ticket user passes the verification, the electronic ticket is sent to the ticket user for the ticket user to use the electronic ticket.
Since the authorization ticket uniquely corresponds to the authorized party and the electronic ticket that the authorized party needs to use, if it is determined that the ticket party is authenticated based on the authorization ticket provided by the ticket party, it can be determined that the ticket party has the authorization corresponding to the ticket party and the electronic ticket, that is, the electronic ticket can be used. If the authorization voucher is leaked, so that other ticket providers provide the authorization voucher when applying for inquiring the electronic ticket, the electronic ticket cannot be acquired because the identification of the authorized party in the authorization voucher is not matched with the identifications of the other ticket providers.
Namely, by adopting the mode, the leakage of the electronic bill caused by the leakage of the authorization voucher can be avoided, and the data security of the electronic bill stored in the block chain is ensured.
Corresponding to the embodiment of the block chain-based electronic bill query method, the specification also provides an embodiment of a block chain-based electronic bill query device.
The embodiment of the block chain-based electronic bill query device can be applied to electronic equipment. The device embodiments may be implemented by software, or by hardware, or by a combination of hardware and software. Taking a software implementation as an example, as a logical device, the device is formed by reading, by a processor of the electronic device where the device is located, a corresponding computer program instruction in the nonvolatile memory into the memory for operation.
From a hardware aspect, as shown in fig. 9, the hardware structure diagram of the electronic device where the block chain-based electronic ticket querying device is located in this specification is shown, except for the processor, the memory, the network interface, and the nonvolatile memory shown in fig. 9, the electronic device where the device is located in the embodiment may also include other hardware according to an actual function of the block chain-based electronic ticket querying, which is not described again.
Referring to fig. 10, fig. 10 is a block diagram of an electronic ticket querying device based on a block chain according to an exemplary embodiment of the present disclosure. The apparatus 100 may be applied to the electronic device equipped with the invoice service platform shown in fig. 9, and includes:
a first receiving module 1001, which receives an electronic bill query request sent by a bill user and corresponding to a target electronic bill stored in the block chain; the electronic bill query request comprises an identifier of the target electronic bill and an authorization voucher which uniquely corresponds to the bill user and the target electronic bill;
the verification module 1002 is configured to create an electronic ticket query transaction based on the electronic ticket query request, issue the electronic ticket query transaction to the blockchain, invoke an intelligent contract deployed on the blockchain in response to the electronic ticket query transaction by a node of the blockchain, and verify the ticketing party based on the authorization credential;
the first sending module 1003 is configured to send, when the ticket consumer passes the verification, the target electronic ticket corresponding to the identifier of the target electronic ticket to the ticket consumer, so that the ticket consumer performs service processing based on the target electronic ticket.
In this embodiment, the electronic ticket query request further includes an identifier of the ticketing party;
the verifying the ticketing party based on the authorization credential comprises:
determining whether the identification of the authorized party in the authorization voucher is matched with the identification of the ticket user, and determining whether the identification of the electronic ticket in the authorization voucher is matched with the identification of the target electronic ticket;
and if the identification of the authorized party in the authorization voucher is matched with the identification of the ticket user and the identification of the electronic ticket in the authorization voucher is matched with the identification of the target electronic ticket, determining that the ticket user passes the verification.
In this embodiment, the electronic ticket query request further includes an identifier of the ticketing party;
the verifying the ticketing party based on the authorization credential comprises:
determining whether the identification of the authorized party in the authorization voucher is matched with the identification of the ticket user, and determining whether the identification of the electronic ticket in the authorization voucher is matched with the identification of the target electronic ticket;
determining whether the authorization credential is valid based on a validity period in the authorization credential;
and if the identification of the authorized party in the authorization voucher is matched with the identification of the ticket user, the identification of the electronic ticket in the authorization voucher is matched with the identification of the target electronic ticket, and the authorization voucher is valid, determining that the ticket user passes the verification.
In this embodiment, the first sending module 1003:
and in response to the monitored verification passing event which is generated by the intelligent contract and corresponds to the ticket user, searching a target electronic bill which corresponds to the identification of the target electronic bill in the block chain, and sending the target electronic bill to the ticket user.
In this embodiment, the target electronic bill stored in the block chain is the encrypted target electronic bill obtained by encrypting the target electronic bill based on a preset encryption algorithm;
the first sending module 1003:
and sending the encrypted target electronic bill to the bill user, so that the bill user decrypts the encrypted target electronic bill based on an encryption algorithm to obtain the target electronic bill, and executing service processing based on the target electronic bill.
In this embodiment, the apparatus 100 further includes:
a second receiving module 1004, which receives an electronic ticket authorization request corresponding to the target electronic ticket sent by an authorizing party; wherein the electronic bill authorization request comprises the identifier of the authorizing party, the identifier of the authorized party and the identifier of the target electronic bill;
a determining module 1005, for determining whether the authorizer has authorization authority of the target electronic ticket based on the identifier of the authorizer;
a generating module 1006, if the authorizer has authorization authority of the target electronic ticket, generating the authorization document based on the identifier of the authorized party and the identifier of the target electronic ticket;
an encryption module 1007, configured to determine a public key of the authorized party based on the identifier of the authorized party, and encrypt the authorization credential based on the public key of the authorized party;
the second sending module 1008 sends the encrypted authorization credential to the authorized party, so that the authorized party decrypts the encrypted authorization credential based on the private key of the authorized party to obtain the authorization credential.
In this embodiment, the determining module 1005:
determining whether the authorized party is a party related to the target electronic ticket based on the identification of the authorized party; wherein the related parties comprise an invoicing party, an invoicee party and a tax bureau;
and if the authorizer is the related party of the target electronic bill, determining that the authorizer has the authorization authority of the target electronic bill.
In this embodiment, the apparatus 100 further includes:
the evidence storing module 1009 issues the encrypted authorization credential to the block chain for storing the evidence.
In this embodiment, the second sending module 1008:
receiving an authorization certificate acquisition request which is sent by the authorized party and corresponds to the target electronic bill; wherein the authorization credential acquisition request includes an identification of the authorized party;
determining whether the authorized party has the acquisition right of the authorization credential based on the identification of the authorized party;
and if the authorized party has the acquisition right of the authorization certificate, sending the encrypted authorization certificate to the authorized party so that the authorized party decrypts the encrypted authorization certificate based on the private key of the authorized party to obtain the authorization certificate.
In this embodiment, the second sending module 1008:
determining whether the identification of the authorized party in the authorization certificate acquisition request is matched with the identification of the authorized party in the electronic bill authorization request;
and if the identification of the authorized party in the authorization certificate acquisition request is matched with the identification of the authorized party in the electronic bill authorization request, determining that the authorized party has the acquisition authority of the authorization certificate.
In this embodiment, the authorization credential obtaining request is sent by the authorized party when receiving a notification message sent by the invoice service platform; the notification message is sent by the invoice service platform when the authorization credential is encrypted.
The implementation process of the functions and actions of each module in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.
For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, wherein the modules described as separate parts may or may not be physically separate, and the parts displayed as modules may or may not be physical modules, may be located in one place, or may be distributed on a plurality of network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in the specification. One of ordinary skill in the art can understand and implement it without inventive effort.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.
In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, 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 a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, 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, compact disc read only memory (CD-ROM), Digital Versatile Discs (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 medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.

Claims (24)

1. An electronic bill query method based on a block chain is applied to an invoice service platform and comprises the following steps:
receiving an electronic bill query request which is sent by a bill user and corresponds to a target electronic bill stored in the block chain; the electronic bill query request comprises an identifier of the target electronic bill and an authorization voucher which uniquely corresponds to the bill user and the target electronic bill;
creating an electronic bill query transaction based on the electronic bill query request, issuing the electronic bill query transaction to the blockchain, responding to the electronic bill query transaction by a node of the blockchain, calling an intelligent contract deployed on the blockchain, and verifying the bill user based on the authorization certificate;
when the ticket user passes the verification, sending a target electronic ticket corresponding to the identification of the target electronic ticket to the ticket user so as to execute business processing based on the target electronic ticket by the ticket user;
the method further comprises the following steps:
receiving an electronic bill authorization request which is sent by an authorization party and corresponds to the target electronic bill; wherein the electronic bill authorization request comprises the identifier of the authorizing party, the identifier of the authorized party and the identifier of the target electronic bill;
determining whether the authorizer has authorization rights for the target electronic ticket based on the identity of the authorizer;
and if the authorizer has the authorization authority of the target electronic bill, generating the authorization voucher based on the identification of the authorized party and the identification of the target electronic bill, and sending the authorization voucher to the authorized party.
2. The method of claim 1, the electronic ticket enquiry request further comprising an identification of the party using the ticket;
the verifying the ticketing party based on the authorization credential comprises:
determining whether the identification of the authorized party in the authorization voucher is matched with the identification of the ticket user, and determining whether the identification of the electronic ticket in the authorization voucher is matched with the identification of the target electronic ticket;
and if the identification of the authorized party in the authorization voucher is matched with the identification of the ticket user and the identification of the electronic ticket in the authorization voucher is matched with the identification of the target electronic ticket, determining that the ticket user passes the verification.
3. The method of claim 2, the electronic ticket enquiry request further comprising an identification of the party using the ticket;
the verifying the ticketing party based on the authorization credential comprises:
determining whether the identification of the authorized party in the authorization voucher is matched with the identification of the ticket user, and determining whether the identification of the electronic ticket in the authorization voucher is matched with the identification of the target electronic ticket;
determining whether the authorization credential is valid based on a validity period in the authorization credential;
and if the identification of the authorized party in the authorization voucher is matched with the identification of the ticket user, the identification of the electronic ticket in the authorization voucher is matched with the identification of the target electronic ticket, and the authorization voucher is valid, determining that the ticket user passes the verification.
4. The method of claim 1, said sending a target electronic ticket corresponding to an identification of the target electronic ticket to the ticketing party upon validation of the ticketing party, comprising:
and in response to the monitored verification passing event which is generated by the intelligent contract and corresponds to the ticket user, searching a target electronic bill which corresponds to the identification of the target electronic bill in the block chain, and sending the target electronic bill to the ticket user.
5. The method according to claim 1, wherein the target electronic bill stored in the blockchain is the encrypted target electronic bill obtained by encrypting the target electronic bill based on a preset encryption algorithm;
the sending the target electronic bill corresponding to the identification of the target electronic bill to the ticket user to execute business processing by the ticket user based on the target electronic bill comprises the following steps:
and sending the encrypted target electronic bill to the bill user, so that the bill user decrypts the encrypted target electronic bill based on an encryption algorithm to obtain the target electronic bill, and executing service processing based on the target electronic bill.
6. The method of claim 1, the sending the authorization credential to the authorized party, comprising:
determining a public key of the authorized party based on the identifier of the authorized party, and encrypting the authorization certificate based on the public key of the authorized party;
and sending the encrypted authorization certificate to the authorized party, so that the authorized party decrypts the encrypted authorization certificate based on the private key of the authorized party to obtain the authorization certificate.
7. The method of claim 1, the determining whether the authorizer has authorization for the target electronic ticket based on the authorizer's identity comprising:
determining whether the authorized party is a party related to the target electronic ticket based on the identification of the authorized party; wherein the related parties comprise an invoicing party, an invoicee party and a tax bureau;
and if the authorizer is the related party of the target electronic bill, determining that the authorizer has the authorization authority of the target electronic bill.
8. The method of claim 6, further comprising:
and issuing the encrypted authorization certificate to the block chain for storing the certificate.
9. The method of claim 6, wherein sending the encrypted authorization credential to the authorized party to decrypt the encrypted authorization credential by the authorized party based on a private key of the authorized party to obtain the authorization credential comprises:
receiving an authorization certificate acquisition request which is sent by the authorized party and corresponds to the target electronic bill; wherein the authorization credential acquisition request includes an identification of the authorized party;
determining whether the authorized party has the acquisition right of the authorization credential based on the identification of the authorized party;
and if the authorized party has the acquisition right of the authorization certificate, sending the encrypted authorization certificate to the authorized party so that the authorized party decrypts the encrypted authorization certificate based on the private key of the authorized party to obtain the authorization certificate.
10. The method of claim 9, the determining whether the authorized party has the acquisition right of the authorization credential based on the identification of the authorized party, comprising:
determining whether the identification of the authorized party in the authorization certificate acquisition request is matched with the identification of the authorized party in the electronic bill authorization request;
and if the identification of the authorized party in the authorization certificate acquisition request is matched with the identification of the authorized party in the electronic bill authorization request, determining that the authorized party has the acquisition authority of the authorization certificate.
11. The method of claim 9, the authorization credential retrieval request is sent by the authorized party upon receipt of a notification message sent by the invoice service platform; the notification message is sent by the invoice service platform when the authorization credential is encrypted.
12. An electronic bill inquiry device based on a block chain, which is applied to an invoice service platform, comprises:
the first receiving module is used for receiving an electronic bill query request which is sent by a bill user and corresponds to a target electronic bill stored in the block chain; the electronic bill query request comprises an identifier of the target electronic bill and an authorization voucher which uniquely corresponds to the bill user and the target electronic bill;
the verification module is used for creating an electronic bill query transaction based on the electronic bill query request and issuing the electronic bill query transaction to the block chain, responding to the electronic bill query transaction by a node of the block chain, calling an intelligent contract deployed on the block chain and verifying the ticket user based on the authorization certificate;
the first sending module is used for sending the target electronic bill corresponding to the identification of the target electronic bill to the ticket user when the ticket user passes the verification so as to execute business processing based on the target electronic bill by the ticket user;
the device further comprises:
the second receiving module is used for receiving an electronic bill authorization request which is sent by an authorization party and corresponds to the target electronic bill; wherein the electronic bill authorization request comprises the identifier of the authorizing party, the identifier of the authorized party and the identifier of the target electronic bill;
a determination module that determines whether the authorizer has authorization rights for the target electronic ticket based on the identity of the authorizer;
and the generation module is used for generating the authorization voucher based on the identification of the authorized party and the identification of the target electronic bill and sending the authorization voucher to the authorized party if the authorized party has the authorization authority of the target electronic bill.
13. The apparatus of claim 12, the electronic ticket enquiry request further comprising an identification of the party to ticket;
the verifying the ticketing party based on the authorization credential comprises:
determining whether the identification of the authorized party in the authorization voucher is matched with the identification of the ticket user, and determining whether the identification of the electronic ticket in the authorization voucher is matched with the identification of the target electronic ticket;
and if the identification of the authorized party in the authorization voucher is matched with the identification of the ticket user and the identification of the electronic ticket in the authorization voucher is matched with the identification of the target electronic ticket, determining that the ticket user passes the verification.
14. The apparatus of claim 13, the electronic ticket enquiry request further comprising an identification of the party to ticket;
the verifying the ticketing party based on the authorization credential comprises:
determining whether the identification of the authorized party in the authorization voucher is matched with the identification of the ticket user, and determining whether the identification of the electronic ticket in the authorization voucher is matched with the identification of the target electronic ticket;
determining whether the authorization credential is valid based on a validity period in the authorization credential;
and if the identification of the authorized party in the authorization voucher is matched with the identification of the ticket user, the identification of the electronic ticket in the authorization voucher is matched with the identification of the target electronic ticket, and the authorization voucher is valid, determining that the ticket user passes the verification.
15. The apparatus of claim 12, the first sending module to:
and in response to the monitored verification passing event which is generated by the intelligent contract and corresponds to the ticket user, searching a target electronic bill which corresponds to the identification of the target electronic bill in the block chain, and sending the target electronic bill to the ticket user.
16. The device according to claim 12, wherein the target electronic bill stored in the blockchain is the encrypted target electronic bill obtained by encrypting the target electronic bill based on a preset encryption algorithm;
the first sending module:
and sending the encrypted target electronic bill to the bill user, so that the bill user decrypts the encrypted target electronic bill based on an encryption algorithm to obtain the target electronic bill, and executing service processing based on the target electronic bill.
17. The apparatus of claim 12, the generation module to:
determining a public key of the authorized party based on the identifier of the authorized party, and encrypting the authorization certificate based on the public key of the authorized party;
and sending the encrypted authorization certificate to the authorized party, so that the authorized party decrypts the encrypted authorization certificate based on the private key of the authorized party to obtain the authorization certificate.
18. The apparatus of claim 12, the determination module to:
determining whether the authorized party is a party related to the target electronic ticket based on the identification of the authorized party; wherein the related parties comprise an invoicing party, an invoicee party and a tax bureau;
and if the authorizer is the related party of the target electronic bill, determining that the authorizer has the authorization authority of the target electronic bill.
19. The apparatus of claim 17, the apparatus further comprising:
and the certificate storage module is used for issuing the encrypted authorization certificate to the block chain for certificate storage.
20. The apparatus of claim 17, the generation module to:
receiving an authorization certificate acquisition request which is sent by the authorized party and corresponds to the target electronic bill; wherein the authorization credential acquisition request includes an identification of the authorized party;
determining whether the authorized party has the acquisition right of the authorization credential based on the identification of the authorized party;
and if the authorized party has the acquisition right of the authorization certificate, sending the encrypted authorization certificate to the authorized party so that the authorized party decrypts the encrypted authorization certificate based on the private key of the authorized party to obtain the authorization certificate.
21. The apparatus of claim 20, the generation module to:
determining whether the identification of the authorized party in the authorization certificate acquisition request is matched with the identification of the authorized party in the electronic bill authorization request;
and if the identification of the authorized party in the authorization certificate acquisition request is matched with the identification of the authorized party in the electronic bill authorization request, determining that the authorized party has the acquisition authority of the authorization certificate.
22. The apparatus according to claim 20, the authorization credential retrieval request is sent by the authorized party upon receiving a notification message sent by the invoice service platform; the notification message is sent by the invoice service platform when the authorization credential is encrypted.
23. An electronic device, comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor implements the steps of the method of any one of claims 1 to 10 by executing the executable instructions.
24. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, carry out the steps of the method according to any one of claims 1 to 10.
CN201911207011.6A 2019-11-29 2019-11-29 Block chain-based electronic bill query method and device and electronic equipment Active CN111026789B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911207011.6A CN111026789B (en) 2019-11-29 2019-11-29 Block chain-based electronic bill query method and device and electronic equipment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911207011.6A CN111026789B (en) 2019-11-29 2019-11-29 Block chain-based electronic bill query method and device and electronic equipment

Publications (2)

Publication Number Publication Date
CN111026789A CN111026789A (en) 2020-04-17
CN111026789B true CN111026789B (en) 2020-12-15

Family

ID=70207273

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911207011.6A Active CN111026789B (en) 2019-11-29 2019-11-29 Block chain-based electronic bill query method and device and electronic equipment

Country Status (1)

Country Link
CN (1) CN111026789B (en)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111641631B (en) * 2020-05-28 2022-07-12 深圳壹账通智能科技有限公司 Bin bill verification method and system based on block chain bin bill platform
CN111985918A (en) * 2020-07-27 2020-11-24 王李琰 Block chain-based electronic certificate circulation management method and system and block chain platform
CN111932326B (en) * 2020-08-17 2024-03-19 腾讯科技（深圳）有限公司 Data processing method based on block chain network and related equipment
CN112084527A (en) * 2020-08-18 2020-12-15 中国银联股份有限公司 Data storage and acquisition method, device, equipment and medium
CN112149077B (en) * 2020-10-12 2022-03-25 杭州云链趣链数字科技有限公司 Supply chain billing method, system and computer equipment based on block chain technology
CN115048396B (en) * 2021-05-25 2024-04-16 支付宝(杭州)信息技术有限公司 Bill processing method and device
CN115205001A (en) * 2021-05-25 2022-10-18 支付宝(杭州)信息技术有限公司 Electronic certificate processing method, device and equipment
CN113221036B (en) * 2021-05-25 2022-05-10 支付宝(杭州)信息技术有限公司 Method and device for processing electronic bill mail
CN113301163B (en) * 2021-06-02 2022-12-16 网易（杭州）网络有限公司 Service processing method, system, electronic device and storage medium
CN113282671A (en) * 2021-06-10 2021-08-20 支付宝(杭州)信息技术有限公司 Claims settlement method and device based on block chain and electronic equipment
CN113282670A (en) * 2021-06-10 2021-08-20 支付宝(杭州)信息技术有限公司 Claims settlement method and device based on block chain and electronic equipment
CN117114787B (en) * 2023-10-23 2024-02-06 国能(北京)商务网络有限公司 Supply chain management method, system and terminal based on electronic invoice

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017021154A1 (en) * 2015-07-31 2017-02-09 British Telecommunications Public Limited Company Access control
CN109034924A (en) * 2018-08-16 2018-12-18 腾讯科技（深圳）有限公司 Electronic bill generation method, device, storage medium and computer equipment
CN109255084A (en) * 2018-08-28 2019-01-22 腾讯科技（深圳）有限公司 Electronic bill querying method, device, storage medium and computer equipment
CN110060111A (en) * 2018-12-12 2019-07-26 阿里巴巴集团控股有限公司 Based on the invoice access method and device of block chain, electronic equipment
CN110457875A (en) * 2019-07-31 2019-11-15 阿里巴巴集团控股有限公司 Data grant method and device based on block chain

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017021154A1 (en) * 2015-07-31 2017-02-09 British Telecommunications Public Limited Company Access control
CN109034924A (en) * 2018-08-16 2018-12-18 腾讯科技（深圳）有限公司 Electronic bill generation method, device, storage medium and computer equipment
CN109255084A (en) * 2018-08-28 2019-01-22 腾讯科技（深圳）有限公司 Electronic bill querying method, device, storage medium and computer equipment
CN110060111A (en) * 2018-12-12 2019-07-26 阿里巴巴集团控股有限公司 Based on the invoice access method and device of block chain, electronic equipment
CN110457875A (en) * 2019-07-31 2019-11-15 阿里巴巴集团控股有限公司 Data grant method and device based on block chain

Also Published As

Publication number Publication date
CN111026789A (en) 2020-04-17

Similar Documents

Publication Publication Date Title
CN111026789B (en) Block chain-based electronic bill query method and device and electronic equipment
CN110766550B (en) Asset query method and device based on block chain and electronic equipment
KR101987692B1 (en) Registry and Automation Management Methods for Smart Contracts in Blockchain Enforcement
CN110765200B (en) Asset procurement method and device based on block chain and electronic equipment
Guerar et al. A fraud-resilient blockchain-based solution for invoice financing
CN110471986B (en) Bill real name getting method and device based on block chain and electronic equipment
CN110458631B (en) Bill number distribution method and device based on block chain and electronic equipment
CN112101938B (en) Digital seal using method and device based on block chain and electronic equipment
US20170221053A1 (en) Digital asset conversion
WO2021017437A1 (en) Blockchain-based note verification method and apparatus, electronic device, and storage medium
CN111738725B (en) Cross-border resource transfer authenticity auditing method and device and electronic equipment
CN112767163B (en) Block chain-based digital commodity transaction method and device
CN111738724B (en) Cross-border resource transfer authenticity auditing method and device, and electronic equipment
CN111818095B (en) Tax refunding method and device based on block chain and electronic equipment
CN112766854B (en) Block chain-based digital commodity transaction method and device
CN111639125A (en) Resource circulation method and device based on block chain
CN112561407B (en) Asset management method, system and device based on block chain
CN112883109B (en) Block chain-based digital commodity transaction method and device
CN112200569A (en) Block chain-based digital seal using method and device and electronic equipment
CN110033367A (en) Based on the contract record method and device of block chain, electronic equipment
CN110009492A (en) Block chain method of commerce and device, electronic equipment, storage medium
CN116451280A (en) Asset management method and device based on blockchain
US20230360007A1 (en) System and method for secure and traceable fund transfer operation through a distributed ledger
Yang et al. DOPS: A Practical Dual Offline Payment Scheme of CBDC for Mobile Devices
CN113469657A (en) Block chain-based physical seal using method and device and electronic equipment

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right

Effective date of registration: 20200702

Address after: Unit 02, 20 / F, block a, building 4, Lane 838, Huangpi South Road, Huangpu District, Shanghai 200025

Applicant after: Ant blockchain Technology (Shanghai) Co., Ltd

Address before: 801-11, Section B, 8th floor, No. 556, Xixi Road, Xihu District, Hangzhou City, Zhejiang Province

Applicant before: Alipay (Hangzhou) Information Technology Co.,Ltd.

TA01 Transfer of patent application right
GR01 Patent grant
GR01 Patent grant