WO2020134615A1 - 跨链存证方法及访问方法、装置、电子设备 - Google Patents
跨链存证方法及访问方法、装置、电子设备 Download PDFInfo
- Publication number
- WO2020134615A1 WO2020134615A1 PCT/CN2019/115851 CN2019115851W WO2020134615A1 WO 2020134615 A1 WO2020134615 A1 WO 2020134615A1 CN 2019115851 W CN2019115851 W CN 2019115851W WO 2020134615 A1 WO2020134615 A1 WO 2020134615A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- invoice
- target
- blockchain
- node device
- cross
- 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.)
- Ceased
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; 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/22—Indexing; Data structures therefor; Storage structures
- G06F16/2228—Indexing structures
- G06F16/2255—Hash tables
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; 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/23—Updating
- G06F16/2365—Ensuring data consistency and integrity
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/16—Multipoint routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/302—Route determination based on requested QoS
- H04L45/306—Route determination based on the nature of the carried application
Definitions
- One or more embodiments of this specification relate to the field of blockchain technology, and in particular to a cross-chain certificate storage method and access method, device, and electronic equipment.
- Blockchain technology also known as distributed ledger technology, is an emerging technology in which several computing devices jointly participate in "bookkeeping" and jointly maintain a complete distributed database.
- Blockchain technology has the characteristics of decentralization, openness and transparency, each computing device can participate in database records, and data synchronization can be quickly performed between computing devices, making blockchain technology widely used in many fields. To apply.
- one or more embodiments of this specification provide a blockchain-based invoice creation method and device, and electronic equipment.
- a cross-chain certificate storage method is proposed, which is applied to a cross-link slave device that maintains communication with multiple blockchain node devices Connection; the method includes:
- Optional also includes:
- the correspondence between the identification information of the target invoice and the target blockchain is saved locally.
- the identification information of the target invoice includes:
- the invoice certificate storage request further includes an invoice code of the target invoice; the multiple blockchains respectively correspond to different invoice code value ranges;
- the determining a corresponding target blockchain for the target invoice from the plurality of blockchains based on preset rules includes:
- forwarding the invoice deposit request to the node device of the target blockchain includes:
- the target blockchain Based on the transaction format supported by the target blockchain, construct an invoice deposit transaction corresponding to the invoice deposit request; wherein, the invoice deposit transaction includes the target invoice;
- Optional also includes:
- forwarding the invoice access request to the node device of the target blockchain includes:
- the multiple blockchains respectively correspond to different administrative regions.
- a cross-chain access method is proposed, which is applied to a cross-link device that maintains a communication connection with multiple blockchain node devices ,
- the cross-link device stores the correspondence between the invoice identification information and the blockchain locally; the method includes:
- forwarding the invoice access request to the node device of the target blockchain includes:
- a cross-chain certificate storage device which is applied to a cross-link slave device that maintains communication with multiple blockchain node devices Connection; the device includes:
- the certificate storage receiving unit receives the invoice certificate storage request initiated by the client; wherein the invoice certificate storage request includes the target invoice;
- the first determining unit in response to the invoice certificate request, determines a corresponding target blockchain for the target invoice from the plurality of blockchains based on a preset rule;
- the first forwarding unit forwards the invoice deposit request to the target blockchain node device, so that the target blockchain node device performs consensus processing on the target invoice, and after the consensus is passed The target invoice is deposited in the target blockchain.
- Optional also includes:
- the message receiving unit receives the notification message that the target invoice has been successfully stored returned by the node device in the target blockchain
- the saving unit in response to the notification message, locally stores the correspondence between the identification information of the target invoice and the target blockchain.
- the identification information of the target invoice includes:
- the invoice certificate storage request further includes an invoice code of the target invoice; the multiple blockchains respectively correspond to different invoice code value ranges;
- the first determining unit is specifically used to:
- the first forwarding unit is specifically used to:
- the target blockchain Based on the transaction format supported by the target blockchain, construct an invoice deposit transaction corresponding to the invoice deposit request; wherein, the invoice deposit transaction includes the target invoice;
- Optional also includes:
- the access receiving unit receives the invoice access request initiated by the client; wherein the invoice access request includes identification information of the target invoice to be accessed;
- a second determining unit in response to the invoice access request, querying the corresponding relationship, and determining a target blockchain corresponding to the identification information of the target invoice;
- the second forwarding unit forwards the invoice access request to the target blockchain node device, and forwards the target invoice to be accessed returned by the target blockchain node device to the client.
- the second forwarding unit is specifically used to:
- the multiple blockchains respectively correspond to different administrative regions.
- a cross-chain access device which is applied to a cross-link device that maintains a communication connection with a plurality of blockchain node devices ,
- the cross-link device stores the correspondence between the invoice identification information and the blockchain locally; the device includes:
- the receiving unit receives the invoice access request initiated by the client; wherein the invoice access request includes identification information of the target invoice to be accessed;
- the determining unit in response to the invoice access request, queries the corresponding relationship to determine the target blockchain corresponding to the identification information of the target invoice;
- the forwarding unit forwards the invoice access request to the node device of the target blockchain, and forwards the target invoice to be accessed returned by the node device of the target blockchain to the client.
- the forwarding unit is specifically used to:
- an electronic device including:
- Memory for storing processor executable instructions
- the processor executes the executable instruction to implement the cross-chain certificate storage method as described in any of the above embodiments.
- an electronic device including:
- Memory for storing processor executable instructions
- the processor executes the executable instruction to implement the cross-chain access method as described in any of the above embodiments.
- the invoice deposit request and the invoice access request are forwarded to the corresponding block chain node device by the device across the link, which can realize cross-chain certificate deposit and cross-chain access to the invoice.
- the cross-link by the device located in the middle layer shields the differences in the implementation of the underlying technology, and the client does not need to interface with the node device of the blockchain; in other words For the external client, there is only one logical block chain, and the physical block chain is not exposed to the outside, and the client cannot perceive the difference between the underlying block chains. It is sufficient to store certificates and access invoices on the blockchain without directly accessing a particular blockchain.
- FIG. 1 is a flowchart of a cross-chain certification method provided by an exemplary embodiment.
- FIG. 2 is a flowchart of a cross-chain access method provided by an exemplary embodiment.
- FIG. 3 is a schematic diagram of an overall architecture of a cross-chain certificate storage scheme and a cross-chain access scheme provided by an exemplary embodiment.
- FIG. 4 is an interactive schematic diagram of a cross-chain certificate storage method provided by an exemplary embodiment.
- FIG. 5 is an interaction schematic diagram of a cross-chain access method provided by an exemplary embodiment.
- FIG. 6 is a schematic structural diagram of an apparatus provided by an exemplary embodiment.
- FIG. 7 is a block diagram of a cross-chain certificate storage device provided by an exemplary embodiment.
- FIG. 8 is a schematic structural diagram of another device provided by an exemplary embodiment.
- FIG. 9 is a block diagram of a cross-chain access device provided by an exemplary embodiment.
- the steps of the corresponding method are not necessarily performed in the order shown and described in this specification.
- the method may include more or fewer steps than described in this specification.
- the single step described in this specification may be decomposed into multiple steps for description in other embodiments; and the multiple steps described in this specification may also be combined into a single step in other embodiments. description.
- FIG. 1 is a flowchart of a cross-chain certification method provided by an exemplary embodiment. As shown in Figure 1, this method is applied to cross-link routers and may include the following steps:
- Step 102 Receive an invoice certificate request initiated by a client; wherein the invoice certificate request includes a target invoice.
- the client may be any type of electronic device such as a mobile phone, tablet computer, smart watch, etc. used by the certificate requesting party, which is not limited in this specification.
- the certificate requesting party can access the cross-link slave device to interact with the cross-link slave device by logging in the registered account on the electronic device.
- the cross-link device maintains a communication connection with multiple blockchain node devices.
- the certificate requesting party can send the invoice certificate request (including the invoice) to the cross-link device through the client, so that the cross-link device forwards the invoice certificate request to the applicable
- the node device performs consensus processing on the invoice after receiving the invoice storage request, and deposits the invoice in the blockchain after the consensus is passed.
- Step 104 in response to the invoice certificate request, determine a corresponding target blockchain for the target invoice from the multiple blockchains based on a preset rule.
- different blockchains can be built according to different value ranges of invoice codes; in other words, each blockchain is used to store invoices with invoice codes within the corresponding value ranges (which can be multiple (Blockchain corresponds to the value range of the same invoice code, and it can also correspond to the value range of the invoice code.) Therefore, the cross-link slave device can use the invoice code of the target invoice as the basis for determining the target blockchain.
- the client can add the invoice code of the target invoice in the invoice deposit request; then the device can use the cross-link
- the invoice code of the target invoice matches the value range of the invoice codes corresponding to the multiple blockchains; if the value of the invoice code of the target invoice is located in any of the multiple blockchains
- the value range of the corresponding invoice code determines the blockchain as the target blockchain corresponding to the target invoice.
- multiple blockchains can correspond to different administrative regions; in other words, the value range of the invoice code corresponds to the administrative region.
- each province can build a blockchain for depositing invoices belonging to its own administrative region.
- the cross-link device can determine the administrative area to which the target invoice belongs based on the invoice code of the target invoice, so that the blockchain corresponding to the administrative area is the target blockchain.
- Step 106 Forward the invoice deposit request to the node device of the target blockchain, so that the node device of the target blockchain performs consensus processing on the target invoice, and after the consensus is passed The target invoice is deposited in the target blockchain.
- multiple blockchains may be constructed by different blockchain technologies. Therefore, the transaction format of each blockchain may be different. Based on the difference in transaction format, the cross-link device needs to convert the transaction format when forwarding the invoice deposit request to the node device of the target blockchain. As an exemplary embodiment, the cross-link device can construct an invoice deposit transaction corresponding to the invoice deposit request based on the transaction format supported by the target blockchain (the invoice deposit transaction includes the target invoice), and then save the invoice The certificate transaction is sent to the node device of the target blockchain.
- the node device of the blockchain after receiving the invoice deposit request forwarded by the device across the link, performs consensus processing on the target invoice included in it, and deposits the target invoice to the district after the consensus is passed In the blockchain. Further, after the certificate is successfully deposited, the node device may return a notification message that the target invoice is successfully registered to the cross-link device. Then, the cross-link device can receive the notification message that the target invoice is successfully returned by the node device in the target blockchain, and in response to the notification message, locally save the identification information of the target invoice corresponding to the target blockchain relationship.
- the identification information of the target invoice may include: the invoice content for the target invoice; or, the hash value calculated by hashing the unique information in the invoice content.
- the unique information may include information such as invoice number, invoice code, invoice date, and tax-free amount. Of course, this manual does not limit the invoice content and the specific form of unique information in the invoice content.
- the client can access each blockchain by sending an invoice access request to the device across the link Certificated invoice.
- the device receives the invoice access request initiated by the client across the link (the invoice access request includes the identification information of the target invoice to be accessed), and in response to the invoice access request, the corresponding relationship is queried to determine the The target blockchain corresponding to the identification information of the target invoice, and forwarding the invoice access request to the node device of the target blockchain, and returning the to-be-accessed node device of the target blockchain
- the target invoice is forwarded to the client.
- the device across the link may construct the corresponding invoice access based on the transaction format supported by the target blockchain
- the requested invoice access transaction (the invoice access transaction includes identification information of the target invoice), and then the invoice access transaction is sent to the target blockchain node device.
- FIG. 2 is a flowchart of a cross-chain access method according to an exemplary embodiment. As shown in Figure 2, this method is applied to cross-link routers and may include the following steps:
- Step 202 Receive an invoice access request initiated by a client; wherein the invoice access request includes identification information of the target invoice to be accessed.
- the cross-link device maintains a communication connection with multiple blockchain node devices.
- the cross-link device locally stores the correspondence between the identification information of the invoice and the blockchain, and for the preservation process of this correspondence, reference may be made to the embodiments in the cross-chain certificate storage scheme, which will not be repeated here.
- Step 204 In response to the invoice access request, query the corresponding relationship to determine a target blockchain corresponding to the identification information of the target invoice.
- Step 206 Forward the invoice access request to the node device of the target blockchain, and forward the target invoice to be accessed returned by the node device of the target blockchain to the client.
- multiple blockchains may be constructed by different blockchain technologies. Therefore, the transaction format of each blockchain may be different. Based on the difference in transaction format, the cross-link device needs to convert the transaction format when forwarding the invoice access request to the node device of the target blockchain. As an exemplary embodiment, the cross-link device can construct an invoice access transaction corresponding to the invoice access request based on the transaction format supported by the target blockchain (the invoice access transaction includes the identification information of the target invoice), and then the invoice The access transaction is sent to the node device of the target blockchain.
- the invoice deposit request and the invoice access request are forwarded to the corresponding block chain node device by the device across the link, which can realize cross-chain certificate deposit and cross-chain access to the invoice.
- the cross-link by the device located in the middle layer shields the differences in the implementation of the underlying technology, and the client does not need to interface with the node device of the blockchain; in other words For the external client, there is only one logical block chain, and the physical block chain is not exposed to the outside, and the client cannot perceive the difference between the underlying block chains. It is sufficient to store certificates and access invoices on the blockchain without directly accessing a particular blockchain.
- FIG. 3 is a schematic diagram of an overall architecture of a cross-chain certificate storage scheme and a cross-chain access scheme provided by an exemplary embodiment.
- the user after completing the issuance of the invoice (hereinafter referred to as the target invoice), the user (the invoice certificate requesting party) can input the invoice content of the target invoice through the client 31, so that the client 31 cross-links
- the device 32 sends an invoice certificate request (including the target invoice).
- the cross-link device 32 selects from multiple blockchains (Blockchain A, Blockchain B, Blockchain C, etc. as shown in FIG. 3) based on preset rules.
- the target invoice determines the corresponding target blockchain, and forwards the invoice deposit request to the node device of the target blockchain (for example, assuming that the target blockchain is Block B, the cross-link device 32 can deposit the invoice
- the request is forwarded to the node device 33B), and the node device of the target blockchain (hereinafter referred to as the target node device) performs consensus processing on the target invoice, and deposits the target invoice in the target blockchain after the consensus is passed.
- the cross-link device 32 may locally store the correspondence between the identification information of the invoice and the blockchain (the blockchain that holds the invoice). Then, the subsequent user (access requesting party of the invoice) can input the identification information of the target invoice to be accessed through the client 31, so that the client 31 sends an invoice access request (including the identification information of the target invoice) to the device 32 across the link. After receiving the invoice access request, the cross-link device 32 determines the target blockchain corresponding to the identification information of the target invoice by querying the corresponding relationship, and forwards the invoice access request to the node device of the target blockchain.
- the cross-link routing device 32 may be a third-party trusted service device that is different from the node devices of multiple blockchains (as shown in FIG. 3).
- the cross-link device 32 may be a physical server containing an independent host, or the cross-link device 32 may be a virtual server carried by the host cluster.
- the cross-link slave device 32 may also be a common node device of multiple blockchains (for example, the cross-link slave device 32 may be blockchain A, blockchain B, and blockchain C Common node device).
- the cross-link slave device 32 may be blockchain A, blockchain B, and blockchain C Common node device.
- FIG. 4 is an interactive schematic diagram of a cross-chain certificate storage method provided by an exemplary embodiment. As shown in FIG. 4, the interaction process may include the following steps:
- step 402 a binding relationship is established between the client 31 and the cross-link slave device 32.
- the binding relationship to be established is a binding relationship between the identity information of the user (including the certificate requesting party and the access requesting party) and the device information of the client 31. Based on the binding relationship, the cross-link device 32 can confirm that these requests correspond to the user when receiving the invoice deposit request and the invoice access request sent by the client 31 subsequently.
- the user may register an account with the device 32 in advance across the link to obtain a registered account uniquely corresponding to himself. Then, the user can log in to the registered account on the client 31, and the cross-link device 32 determines the registered account (corresponding to the user) and the client based on the login information of the registered account on the client 31 A binding relationship is established between the terminals 31.
- step 404 the client 31 obtains the target invoice of the certificate to be stored.
- the certificate requesting party may enter the target invoice in the client (for example, enter the invoice content of the target invoice), and the client 31 may then generate an invoice certificate based on the input target invoice request.
- step 406 the client 31 sends an invoice certificate request to the device 32 across the link.
- step 408 the cross-link device 32 determines the target blockchain according to the invoice code of the target invoice.
- multiple blockchains can correspond to different administrative regions.
- each city-level region can build a blockchain for depositing invoices belonging to its own administrative region.
- the cross-link device can determine the municipal administrative area to which the target invoice belongs based on the invoice code of the target invoice (the invoice code is included in the invoice content), so that the blockchain corresponding to the municipal administrative area is the target area Blockchain.
- the target blockchain is Blockchain A.
- Step 410 The device 32 constructs an invoice certificate transaction across the link.
- the blockchains of each administrative region may be constructed by different blockchain technologies. Therefore, the transaction format of each blockchain may be different. Based on the difference in the transaction format, after the cross-link device 32 determines the target blockchain, it needs to convert the transaction format.
- the cross-link device 32 can build an invoice deposit transaction corresponding to the invoice deposit request based on the transaction format supported by Blockchain A (ie
- the transaction format of the invoice storage transaction is the transaction format supported by Blockchain A, and the invoice storage transaction includes the target invoice).
- step 412 the device 32 sends the constructed invoice certificate transaction to the target node device across the link.
- the node device 33A among the node devices of the blockchain A and the cross-link is accessed by the device 32 is the node device 33A (that is, the node device 33A is the target node device). Then, after the cross-link device 32 constructs the invoice storage transaction, it can send the invoice storage transaction to the node device 33A.
- step 414 the target node device deposits the target invoice in the target blockchain.
- the target node device after receiving the invoice deposit transaction sent by the device across the link, performs consensus processing on the target invoice included therein, and deposits the target invoice to the target blockchain after the consensus is passed in.
- step 416 the target node device returns to the cross-link device 32 a notification message that the target invoice has been successfully registered after the certificate is successfully deposited.
- the cross-link device 32 locally stores the correspondence between the identification information of the target invoice and the target blockchain.
- the cross-link device 32 may hash the unique information in the invoice content of the target invoice, and use the obtained hash value as the identification information of the target invoice.
- the unique information may include: invoice number, invoice code, invoice date, tax-free amount and other information.
- this manual does not limit the invoice content and the specific form of unique information in the invoice content.
- the cross-link routing device 32 may locally store the cross-link routing table shown in Table 2:
- Blockchain hash value 1 Blockchain A hash value 2
- Blockchain B hash value 3
- Blockchain C ... ...
- step 420 the cross-link device 32 returns a notification message of successful certificate storage to the client 31.
- the client 31 may display the notification message to remind the user (certification requester) that the target invoice has been successfully certified.
- FIG. 5 is an interaction schematic diagram of the cross-chain access method provided by an exemplary embodiment. As shown in FIG. 5, this method is applied to cross-link routers, and may include the following steps:
- step 502 the client 31 generates an invoice access request.
- the invoice content of the target invoice can be entered in the client 31
- the unique information (invoice number, invoice code, invoice date, tax-excluded amount, etc.).
- the client 31 may generate an invoice access request based on the unique information. For example, the client 31 can directly add the unique information to the invoice access request; or, the client 31 can hash the unique information to add the calculated hash value as the Ford information to the invoice access request.
- step 504 the client 31 sends an invoice access request to the device 32 across the link.
- step 506 the cross-link device 32 determines the target blockchain based on the identification information.
- the target blockchain corresponding to the target invoice is queried according to the correspondence relationship obtained in the embodiment shown in FIG. 4 above. Following the example in Table 2 above, it is assumed that the obtained identification information is a hash value of 1, and the target blockchain can be determined as the blockchain A according to the correspondence recorded in Table 2.
- step 508 the invoice access transaction is constructed by the device 32 across the link.
- the device 32 across the link needs to convert the transaction format after determining the target blockchain.
- the cross-link device 32 determines that the target blockchain is Blockchain A, it can construct an invoice access transaction corresponding to the invoice access request based on the transaction format supported by Blockchain A (ie, the invoice The transaction format of the access transaction is the transaction format supported by Blockchain A, and the invoice access transaction includes the identification information of the target invoice).
- step 510 the device 32 sends the constructed invoice access transaction to the target node device across the link.
- the node device 33A among the node devices of the blockchain A and the cross-link is accessed by the device 32 is the node device 33A (that is, the node device 33A is the target node device). Then, after the cross-link device 32 constructs the invoice access transaction, it may send the invoice access transaction to the node device 33A.
- the target node device obtains the target invoice in the target blockchain according to the identification information of the target invoice.
- step 514 the target node device returns the obtained target invoice to the cross-link router 32.
- Step 516 The device 32 returns the target invoice to the client 31 across the link.
- the invoice deposit request and the invoice access request are forwarded to the corresponding block chain node device by the device across the link, which can realize cross-chain certificate deposit and cross-chain access to the invoice.
- the cross-link by the device located in the middle layer shields the differences in the implementation of the underlying technology, and the client does not need to interface with the node device of the blockchain; in other words For external clients, there is only one logical block chain, and the physical block chain is not exposed to the outside, and the client does not perceive the differences between the underlying block chains (for example, the client does not need to build a correspondence In the transaction format of each blockchain), the device can deposit certificates and access invoices on the blockchain through the cross-link, without directly accessing a specific blockchain.
- FIG. 6 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to FIG. 6.
- the device includes a processor 602, an internal bus 604, a network interface 606, a memory 608, and a non-volatile memory 610. Of course, it may include hardware required for other services.
- the processor 602 reads the corresponding computer program from the non-volatile memory 610 into the memory 608 and then runs it to form a cross-chain certificate storage device at a logical level.
- one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of hardware and software, etc., that is to say, the execution body of the following processing flow is not limited to each
- the logic unit may also be a hardware or logic device.
- the cross-chain certificate storage device is applied to a cross-link slave device that maintains a communication connection with multiple blockchain node devices; the device may include:
- the certificate receiving unit 71 receives the invoice certificate request initiated by the client; wherein the invoice certificate request includes the target invoice;
- the first determining unit 72 in response to the invoice certificate request, determines a corresponding target blockchain for the target invoice from the plurality of blockchains based on a preset rule;
- the first forwarding unit 73 forwards the invoice deposit request to the node device of the target blockchain, so that the node device of the target blockchain performs consensus processing on the target invoice, and after the consensus is passed Deposit the target invoice in the target blockchain.
- Optional also includes:
- the message receiving unit 74 receives the notification message that the target invoice has been successfully stored returned by the node device in the target blockchain;
- the saving unit 75 in response to the notification message, locally stores the correspondence between the identification information of the target invoice and the target blockchain.
- the identification information of the target invoice includes:
- the invoice certificate storage request further includes an invoice code of the target invoice; the multiple blockchains respectively correspond to different invoice code value ranges;
- the first determining unit 72 is specifically used to:
- the first forwarding unit 73 is specifically used to:
- the target blockchain Based on the transaction format supported by the target blockchain, construct an invoice deposit transaction corresponding to the invoice deposit request; wherein, the invoice deposit transaction includes the target invoice;
- Optional also includes:
- the access receiving unit 76 receives the invoice access request initiated by the client; wherein the invoice access request includes identification information of the target invoice to be accessed;
- the second determining unit 77 in response to the invoice access request, queries the corresponding relationship, and determines a target blockchain corresponding to the identification information of the target invoice;
- the second forwarding unit 78 forwards the invoice access request to the target blockchain node device, and forwards the target invoice to be accessed returned by the target blockchain node device to the client .
- the second forwarding unit 78 is specifically configured to:
- the multiple blockchains respectively correspond to different administrative regions.
- the device includes a processor 802, an internal bus 804, a network interface 806, a memory 808, and a non-volatile memory 810. Of course, it may include hardware required for other services.
- the processor 802 reads the corresponding computer program from the non-volatile memory 810 into the memory 808 and then runs it to form a cross-chain access device at a logical level.
- one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of hardware and software, etc., that is to say, the execution body of the following processing flow is not limited to each
- the logic unit may also be a hardware or logic device.
- the cross-chain access device is applied to a cross-link slave device, and the cross-link slave device maintains a communication connection with multiple blockchain node devices.
- the cross-link slave device The device locally stores the correspondence between the invoice identification information and the blockchain; the device may include:
- the receiving unit 91 receives an invoice access request initiated by a client; wherein the invoice access request includes identification information of a target invoice to be accessed;
- the determining unit 92 in response to the invoice access request, queries the corresponding relationship and determines a target blockchain corresponding to the identification information of the target invoice;
- the forwarding unit 93 forwards the invoice access request to the node device of the target blockchain, and forwards the target invoice to be accessed returned by the node device of the target blockchain to the client.
- the forwarding unit 93 is specifically used to:
- the system, device, module or unit explained in the above embodiments may be specifically implemented by a computer chip or entity, or implemented by a product having a certain function.
- a typical implementation device is a computer, and the specific form of the computer may be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email sending and receiving device, and a game control Desk, tablet computer, wearable device, or any combination of these devices.
- the computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
- processors CPUs
- input/output interfaces network interfaces
- memory volatile and non-volatile memory
- the memory may include non-permanent memory, random access memory (RAM) and/or non-volatile memory in a computer-readable medium, such as read only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
- RAM random access memory
- ROM read only memory
- flash RAM flash memory
- Computer readable media including permanent and non-permanent, removable and non-removable media, can store information by any method or technology.
- the information may be computer readable instructions, data structures, modules of programs, 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 technologies, read-only compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, Magnetic tape cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices.
- computer-readable media does not include temporary computer-readable media (transitory media), such as modulated data signals and carrier waves.
- first, second, third, etc. may use the terms first, second, third, etc. to describe various information, the information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other.
- first information may also be referred to as second information, and similarly, the second information may also be referred to as first information.
- word "if” as used herein may be interpreted as "when” or “when” or “in response to a determination”.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Business, Economics & Management (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Development Economics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Accounting & Taxation (AREA)
- Economics (AREA)
- Finance (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Telephonic Communication Services (AREA)
Abstract
一种跨链存证方法及访问方法、装置、电子设备，该跨链存证方法应用于跨链路由设备，所述跨链路由设备与多个区块链的节点设备保持通讯连接；该方法可以包括：接收客户端发起的发票存证请求；其中，所述发票存证请求包括目标发票（102）；响应于所述发票存证请求，基于预设规则从所述多个区块链中为所述目标发票确定对应的目标区块链（104）；将所述发票存证请求转发至所述目标区块链的节点设备，以由所述目标区块链的节点设备对所述目标发票进行共识处理，并在共识通过后将所述目标发票在所述目标区块链中进行存证（106）。
Description
本说明书一个或多个实施例涉及区块链技术领域，尤其涉及一种跨链存证方法及访问方法、装置、电子设备。
区块链技术，也被称之为分布式账本技术，是一种由若干台计算设备共同参与“记账”，共同维护一份完整的分布式数据库的新兴技术。由于区块链技术具有去中心化、公开透明、每台计算设备可以参与数据库记录、并且各计算设备之间可以快速的进行数据同步的特性，使得区块链技术已在众多的领域中广泛的进行应用。
发明内容
有鉴于此，本说明书一个或多个实施例提供一种基于区块链的发票创建方法及装置、电子设备。
为实现上述目的，本说明书一个或多个实施例提供技术方案如下：
根据本说明书一个或多个实施例的第一方面，提出了一种跨链存证方法，应用于跨链路由设备，所述跨链路由设备与多个区块链的节点设备保持通讯连接；所述方法包括：
接收客户端发起的发票存证请求；其中，所述发票存证请求包括目标发票；
响应于所述发票存证请求，基于预设规则从所述多个区块链中为所述目标发票确定对应的目标区块链；
将所述发票存证请求转发至所述目标区块链的节点设备，以由所述目标区块链的节点设备对所述目标发票进行共识处理，并在共识通过后将所述目标发票在所述目标区块链中进行存证。
可选的，还包括：
接收所述目标区块链中的节点设备返回的所述目标发票存证成功的通知消息；
响应于所述通知消息，在本地保存所述目标发票的标识信息与所述目标区块链的对应关系。
可选的，所述目标发票的标识信息，包括：
针对所述目标发票的发票内容；或者，所述发票内容中的唯一性信息进行hash计算得到的hash值。
可选的，所述发票存证请求中还包括所述目标发票的发票代码；所述多个区块链分别对应不同的发票代码取值范围；
所述基于预设规则从所述多个区块链中为所述目标发票确定对应的目标区块链，包括：
将所述目标发票的发票代码与所述多个区块链对应的发票代码取值范围分别进行匹配；如果所述目标发票的发票代码的取值位于所述多个区块链中的任一区块链对应的发票代码取值范围，则将该区块链确定为与所述目标发票对应的目标区块链。
可选的，将所述发票存证请求转发至所述目标区块链的节点设备，包括：
基于所述目标区块链支持的交易格式，构建对应于所述发票存证请求的发票存证交易；其中，所述发票存证交易包括所述目标发票；
将所述发票存证交易发送至所述目标区块链的节点设备。
可选的，还包括：
接收客户端发起的发票访问请求；其中，所述发票访问请求包括待访问的目标发票的标识信息；
响应于所述发票访问请求，查询所述对应关系，确定与所述目标发票的标识信息对应的目标区块链；
将所述发票访问请求转发至所述目标区块链的节点设备，并将所述目标区块链的节点设备返回的所述待访问的目标发票转发给所述客户端。
可选的，将所述发票访问请求转发至所述目标区块链的节点设备，包括：
基于所述目标区块链支持的交易格式，构建对应于所述发票访问请求的发票访问交易；其中，所述发票访问交易包括所述目标发票的标识信息；
将所述发票访问交易发送至所述目标区块链的节点设备。
可选的，所述多个区块链分别对应不同的行政区域。
根据本说明书一个或多个实施例的第二方面，提出了一种跨链访问方法，应用于跨 链路由设备，所述跨链路由设备与多个区块链的节点设备保持通讯连接，所述跨链路由设备本地保存有发票的标识信息与区块链的对应关系；所述方法包括：
接收客户端发起的发票访问请求；其中，所述发票访问请求包括待访问的目标发票的标识信息；
响应于所述发票访问请求，查询所述对应关系，确定与所述目标发票的标识信息对应的目标区块链；
将所述发票访问请求转发至所述目标区块链的节点设备，并将所述目标区块链的节点设备返回的所述待访问的目标发票转发给所述客户端。
可选的，将所述发票访问请求转发至所述目标区块链的节点设备，包括：
基于所述目标区块链支持的交易格式，构建对应于所述发票访问请求的发票访问交易；其中，所述发票访问交易包括所述目标发票的标识信息；
将所述发票访问交易发送至所述目标区块链的节点设备。
根据本说明书一个或多个实施例的第三方面，提出了一种跨链存证装置，应用于跨链路由设备，所述跨链路由设备与多个区块链的节点设备保持通讯连接；所述装置包括：
存证接收单元，接收客户端发起的发票存证请求；其中，所述发票存证请求包括目标发票；
第一确定单元，响应于所述发票存证请求，基于预设规则从所述多个区块链中为所述目标发票确定对应的目标区块链；
第一转发单元，将所述发票存证请求转发至所述目标区块链的节点设备，以由所述目标区块链的节点设备对所述目标发票进行共识处理，并在共识通过后将所述目标发票在所述目标区块链中进行存证。
可选的，还包括：
消息接收单元，接收所述目标区块链中的节点设备返回的所述目标发票存证成功的通知消息；
保存单元，响应于所述通知消息，在本地保存所述目标发票的标识信息与所述目标区块链的对应关系。
可选的，所述目标发票的标识信息，包括：
针对所述目标发票的发票内容；或者，所述发票内容中的唯一性信息进行hash计算得到的hash值。
可选的，所述发票存证请求中还包括所述目标发票的发票代码；所述多个区块链分别对应不同的发票代码取值范围；
所述第一确定单元具体用于：
将所述目标发票的发票代码与所述多个区块链对应的发票代码取值范围分别进行匹配；如果所述目标发票的发票代码的取值位于所述多个区块链中的任一区块链对应的发票代码取值范围，则将该区块链确定为与所述目标发票对应的目标区块链。
可选的，所述第一转发单元具体用于：
基于所述目标区块链支持的交易格式，构建对应于所述发票存证请求的发票存证交易；其中，所述发票存证交易包括所述目标发票；
将所述发票存证交易发送至所述目标区块链的节点设备。
可选的，还包括：
访问接收单元，接收客户端发起的发票访问请求；其中，所述发票访问请求包括待访问的目标发票的标识信息；
第二确定单元，响应于所述发票访问请求，查询所述对应关系，确定与所述目标发票的标识信息对应的目标区块链；
第二转发单元，将所述发票访问请求转发至所述目标区块链的节点设备，并将所述目标区块链的节点设备返回的所述待访问的目标发票转发给所述客户端。
可选的，所述第二转发单元具体用于：
基于所述目标区块链支持的交易格式，构建对应于所述发票访问请求的发票访问交易；其中，所述发票访问交易包括所述目标发票的标识信息；
将所述发票访问交易发送至所述目标区块链的节点设备。
可选的，所述多个区块链分别对应不同的行政区域。
根据本说明书一个或多个实施例的第四方面，提出了一种跨链访问装置，应用于跨链路由设备，所述跨链路由设备与多个区块链的节点设备保持通讯连接，所述跨链路由设备本地保存有发票的标识信息与区块链的对应关系；所述装置包括：
接收单元，接收客户端发起的发票访问请求；其中，所述发票访问请求包括待访问的目标发票的标识信息；
确定单元，响应于所述发票访问请求，查询所述对应关系，确定与所述目标发票的标识信息对应的目标区块链；
转发单元，将所述发票访问请求转发至所述目标区块链的节点设备，并将所述目标区块链的节点设备返回的所述待访问的目标发票转发给所述客户端。
可选的，所述转发单元具体用于：
基于所述目标区块链支持的交易格式，构建对应于所述发票访问请求的发票访问交易；其中，所述发票访问交易包括所述目标发票的标识信息；
将所述发票访问交易发送至所述目标区块链的节点设备。
根据本说明书一个或多个实施例的第五方面，提出了一种电子设备，包括：
处理器；
用于存储处理器可执行指令的存储器；
其中，所述处理器通过运行所述可执行指令以实现如上述任一实施例中所述的跨链存证方法。
根据本说明书一个或多个实施例的第六方面，提出了一种电子设备，包括：
处理器；
用于存储处理器可执行指令的存储器；
其中，所述处理器通过运行所述可执行指令以实现如上述任一实施例中所述的跨链访问方法。
由以上技术方案可见，一方面，通过跨链路由设备将发票存证请求和发票访问请求转发至相应区块链的节点设备，可实现针对发票的跨链存证和跨链访问。另一方面，即使各区块链采用不同的区块链技术搭建，由位于中间层的跨链路由设备屏蔽了底层技术实现上的差异，客户端也无需与区块链的节点设备对接；换言之，对于外部的客户端来说，在逻辑上只有一个区块链，而物理上的区块链对外不露出，客户端感知不到底层区块链之间的差异，通过跨链路由设备在区块链上存证和访问发票即可，而无需直接访问某个特定的区块链。
图1是一示例性实施例提供的一种跨链存证方法的流程图。
图2是一示例性实施例提供的一种跨链访问方法的流程图。
图3是一示例性实施例提供的一种跨链存证方案以及跨链访问方案的整体架构示意图。
图4是一示例性实施例提供的跨链存证方法的交互示意图。
图5是一示例性实施例提供的跨链访问方法的交互示意图。
图6是一示例性实施例提供的一种设备的结构示意图。
图7是一示例性实施例提供的一种跨链存证装置的框图。
图8是一示例性实施例提供的另一种设备的结构示意图。
图9是一示例性实施例提供的一种跨链访问装置的框图。
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。
需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。
图1是一示例性实施例提供的一种跨链存证方法的流程图。如图1所示，该方法应用于跨链路由设备，可以包括以下步骤：
步骤102，接收客户端发起的发票存证请求；其中，所述发票存证请求包括目标发票。
在一实施例中，客户端可以为存证请求方使用的手机、平板电脑、智能手表等任意类型的电子设备，本说明书并不对此进行限制。存证请求方通过在电子设备上登录已注册账号，可接入跨链路由设备以与跨链路由设备进行交互。
在一实施例中，跨链路由设备与多个区块链的节点设备保持通讯连接。发票的存证请求方在完成对发票的开具后，可通过客户端向跨链路由设备发送发票存证请求(包括该发票)，以使得跨链路由设备将发票存证请求转发至适用于存证该发票的区块链的节点设备，那么该节点设备在接收到发票存证请求后对发票进行共识处理，并在共识通过后将发票在区块链中进行存证。
步骤104，响应于所述发票存证请求，基于预设规则从所述多个区块链中为所述目标发票确定对应的目标区块链。
在一实施例中，可按照发票代码的取值范围的不同来相应地搭建不同的区块链；换言之，各个区块链用于存证发票代码在相应取值范围内的发票(可以多个区块链与同一发票代码的取值范围对应，也可以区块链与发票代码的取值范围一一对应)。因此，跨链路由设备可将目标发票的发票代码作为确定目标区块链的依据。基于上述存证发票的机制(多个区块链分别对应不同的发票代码取值范围)，客户端可在发票存证请求中添加目标发票的发票代码；那么跨链路由设备可将所述目标发票的发票代码与所述多个区块链对应的发票代码取值范围分别进行匹配；如果所述目标发票的发票代码的取值位于所述多个区块链中的任一区块链对应的发票代码取值范围，则将该区块链确定为与所述目标发票对应的目标区块链。
在一实施例中，多个区块链可分别对应不同的行政区域；换言之，发票代码的取值范围与行政区域相对应。以省级行政区域为例，各个省份可搭建用于存证归属于自身行政区域范围内的发票的区块链。那么，跨链路由设备可根据目标发票的发票代码确定出目标发票所归属的行政区域，从而与该行政区域对应的区块链便是目标区块链。
步骤106，将所述发票存证请求转发至所述目标区块链的节点设备，以由所述目标区块链的节点设备对所述目标发票进行共识处理，并在共识通过后将所述目标发票在所述目标区块链中进行存证。
在一实施例中，多个区块链之间可能由不同的区块链技术来搭建。因此，各个区块链的交易格式可能存在差异。基于交易格式上的差异，跨链路由设备在将发票存证请求转发至目标区块链的节点设备时，需要进行交易格式的转换。作为一示例性实施例，跨 链路由设备可基于目标区块链支持的交易格式，构建对应于发票存证请求的发票存证交易(该发票存证交易包括目标发票)，再将发票存证交易发送至目标区块链的节点设备。
在一实施例中，区块链的节点设备在接收到跨链路由设备转发的发票存证请求后，对其中包括的目标发票进行共识处理，并在共识通过后将目标发票存证至区块链中。进一步的，在存证成功后，节点设备可向跨链路由设备返回目标发票存证成功的通知消息。那么，跨链路由设备可接收目标区块链中的节点设备返回的目标发票存证成功的通知消息，以及响应于该通知消息，在本地保存目标发票的标识信息与目标区块链的对应关系。其中，目标发票的标识信息可以包括：针对目标发票的发票内容；或者，该发票内容中的唯一性信息进行hash计算得到的hash值。例如，唯一性信息可以包括：发票号码、发票代码、发票日期、不含税金额等信息。当然，本说明书并不对发票内容以及发票内容中唯一性信息的具体形式进行限制。
在一实施例中，基于跨链路由设备本地保存有发票的标识信息与区块链之间的对应关系，客户端可通过向跨链路由设备发送发票访问请求来访问各个区块链中存证的发票。以上述目标发票为例，跨链路由设备接收客户端发起的发票访问请求(发票访问请求包括待访问的目标发票的标识信息)，响应于该发票访问请求，查询所述对应关系，确定与所述目标发票的标识信息对应的目标区块链，以及将所述发票访问请求转发至所述目标区块链的节点设备，并将所述目标区块链的节点设备返回的所述待访问的目标发票转发给所述客户端。
在一实施例中，同样的，由于各个区块链的交易格式可能存在差异，跨链路由设备在接收到发票访问请求后，可基于目标区块链支持的交易格式，构建对应于发票访问请求的发票访问交易(所述发票访问交易包括所述目标发票的标识信息)，再将所述发票访问交易发送至所述目标区块链的节点设备。
相应的，本说明书还提供一种跨链访问方案。请参见图2，图2是一示例性实施例提供的一种跨链访问方法的流程图。如图2所示，该方法应用于跨链路由设备，可以包括以下步骤：
步骤202，接收客户端发起的发票访问请求；其中，所述发票访问请求包括待访问的目标发票的标识信息。
在一实施例中，跨链路由设备与多个区块链的节点设备保持通讯连接。同时，跨链路由设备本地保存有发票的标识信息与区块链的对应关系，而针对该对应关系的保存过 程，可参考上述跨链存证方案中的实施例，在此不再赘述。
步骤204，响应于所述发票访问请求，查询所述对应关系，确定与所述目标发票的标识信息对应的目标区块链。
步骤206，将所述发票访问请求转发至所述目标区块链的节点设备，并将所述目标区块链的节点设备返回的所述待访问的目标发票转发给所述客户端。
在一实施例中，多个区块链之间可能由不同的区块链技术来搭建。因此，各个区块链的交易格式可能存在差异。基于交易格式上的差异，跨链路由设备在将发票访问请求转发至目标区块链的节点设备时，需要进行交易格式的转换。作为一示例性实施例，跨链路由设备可基于目标区块链支持的交易格式，构建对应于发票访问请求的发票访问交易(发票访问交易包括所述目标发票的标识信息)，再将发票访问交易发送至目标区块链的节点设备。
由以上技术方案可见，一方面，通过跨链路由设备将发票存证请求和发票访问请求转发至相应区块链的节点设备，可实现针对发票的跨链存证和跨链访问。另一方面，即使各区块链采用不同的区块链技术搭建，由位于中间层的跨链路由设备屏蔽了底层技术实现上的差异，客户端也无需与区块链的节点设备对接；换言之，对于外部的客户端来说，在逻辑上只有一个区块链，而物理上的区块链对外不露出，客户端感知不到底层区块链之间的差异，通过跨链路由设备在区块链上存证和访问发票即可，而无需直接访问某个特定的区块链。
图3是一示例性实施例提供的一种跨链存证方案以及跨链访问方案的整体架构示意图。如图3所示，用户(发票的存证请求方)在完成对发票(以下称为目标发票)的开具后，可通过客户端31输入目标发票的发票内容，使得客户端31向跨链路由设备32发送发票存证请求(包括目标发票)。跨链路由设备32在接收到发票存证请求后，基于预设规则从多个区块链(如图3所示的区块链A、区块链B、区块链C等)中为目标发票确定对应的目标区块链，并将发票存证请求转发至目标区块链的节点设备(例如，假定目标区块链为区块链B，跨链路由设备32可将发票存证请求转发至节点设备33B)，以由目标区块链的节点设备(以下简称为目标节点设备)对目标发票进行共识处理，并在共识通过后将目标发票在目标区块链中进行存证。
进一步的，跨链路由设备32可在本地保存发票的标识信息与区块链(存证该发票的区块链)的对应关系。那么，后续用户(发票的访问请求方)可通过客户端31输 入待访问的目标发票的标识信息，使得客户端31向跨链路由设备32发送发票访问请求(包括目标发票的标识信息)。跨链路由设备32在接收到发票访问请求后，通过查询对应关系确定与目标发票的标识信息对应的目标区块链，以及将发票访问请求转发至目标区块链的节点设备。
需要说明的是，在一种情况下，跨链路由设备32可以是区别于多个区块链的节点设备的第三方可信服务设备(如图3所示)。其中，跨链路由设备32可以为包含一独立主机的物理服务器，或者跨链路由设备32可以为主机集群承载的虚拟服务器。在另一种情况下，跨链路由设备32也可以是多个区块链的共同节点设备(例如，跨链路由设备32可以是区块链A、区块链B、区块链C共同的节点设备)。当然，本说明书一个或多个实施例并不对此进行限制。
为了便于理解，下面针对客户端31、跨链路由设备32和目标节点设备分别在跨链存证和跨链访问过程中实现的操作和功能，结合图4-5对本说明书的技术方案进行详细说明。图4是一示例性实施例提供的跨链存证方法的交互示意图。如图4所示，该交互过程可以包括以下步骤：
步骤402，客户端31与跨链路由设备32之间实现对绑定关系的建立。
在一实施例中，所需建立的绑定关系为用户(包括存证请求方和访问请求方)的身份信息与客户端31的设备信息之间的绑定关系。基于该绑定关系，使得跨链路由设备32在接收到客户端31后续发送的发票存证请求和发票访问请求时，可以确认这些请求对应于该用户。
举例而言，用户可以预先在跨链路由设备32处进行账号注册，得到与自身唯一对应的已注册账号。然后，用户可以通过在客户端31上登录该已注册账号，而跨链路由设备32基于该已注册账号在客户端31上的登录信息，确定该已注册账号(对应于该用户)与客户端31之间建立了绑定关系。
步骤404，客户端31获取待存证的目标发票。
在一实施例中，存证请求方在目标发票被开具后，可在客户端中输入目标发票(例如，输入目标发票的发票内容)，客户端31进而可根据输入的目标发票生成发票存证请求。
步骤406，客户端31向跨链路由设备32发送发票存证请求。
步骤408，跨链路由设备32根据目标发票的发票代码确定目标区块链。
在一实施例中，多个区块链可分别对应不同的行政区域。以市级区域划分区块链为例，各个市级地区可搭建用于存证归属于自身行政区域范围内的发票的区块链。那么，跨链路由设备可根据目标发票的发票代码(发票内容中包含发票代码)确定出目标发票所归属的市级行政区域，从而与该市级行政区域对应的区块链便是目标区块链。
举例而言，假定发票代码(仅示出发票代码中发票批印税务机关的地区代码)与市级行政区域以及区块链之间的对应关系如表1所示：
| 发票代码 | 市级行政区域 | 区块链 |
| 3301 | 杭州 | 区块链A |
| 3302 | 宁波 | 区块链B |
| 3303 | 温州 | 区块链C |
| 3304 | 嘉兴 | 区块链D |
| …… | …… | …… |
表1
假定目标发票的发票代码(其中的地区代码)为3301，则可以确定出目标区块链为区块链A。
步骤410，跨链路由设备32构建发票存证交易。
在一实施例中，各个行政区域的区块链可能由不同的区块链技术搭建。因此，各个区块链的交易格式可能存在差异。基于交易格式上的差异，跨链路由设备32在确定出目标区块链之后，需要进行交易格式的转换。
承接于上述举例，跨链路由设备32在确定出目标区块链为区块链A后，可基于区块链A支持的交易格式，构建对应于发票存证请求的发票存证交易(即该发票存证交易的交易格式为区块链A支持的交易格式，并且该发票存证交易包括目标发票)。
步骤412，跨链路由设备32向目标节点设备发送构建的发票存证交易。
承接于上述举例，如图3所示，区块链A的节点设备中与跨链路由设备32接入的为节点设备33A(即节点设备33A为目标节点设备)。那么，跨链路由设备32在构建出发票存证交易后，可向节点设备33A发送该发票存证交易。
步骤414，目标节点设备在目标区块链中存证目标发票。
在一实施例中，目标节点设备在接收到跨链路由设备发送的发票存证交易后，对其中包括的目标发票进行共识处理，并在共识通过后将目标发票存证至目标区块链中。
步骤416，目标节点设备在存证成功后向跨链路由设备32返回目标发票存证成 功的通知消息。
步骤418，跨链路由设备32在本地保存目标发票的标识信息与目标区块链的对应关系。
在一实施例中，跨链路由设备32可对目标发票的发票内容中的唯一性信息进行hash计算，并将得到的hash值作为目标发票的标识信息。其中，唯一性信息可以包括：发票号码、发票代码、发票日期、不含税金额等信息。当然，本说明书并不对发票内容以及发票内容中唯一性信息的具体形式进行限制。
举例而言，跨链路由设备32在接收到各节点设备返回的通知消息后，可在本地保存如表2所示的跨链路由表：
| 发票的标识信息 | 区块链 |
| hash值1 | 区块链A |
| hash值2 | 区块链B |
| hash值3 | 区块链C |
| …… | …… |
表2
步骤420，跨链路由设备32向客户端31返回存证成功的通知消息。
在一实施例中，客户端31在接收到该通知消息后，可展示该通知消息以提示用户(存证请求方)目标发票已存证成功。
基于跨链路由设备32本地保存了发票的标识信息与区块链之间的对应关系，用户在存在访问区块链上存证的某一发票的需求时，可通过客户端31向跨链路由设备32发送发票访问请求来访问该发票。请参见图5，图5是一示例性实施例提供的跨链访问方法的交互示意图。如图5所示，该方法应用于跨链路由设备，可以包括以下步骤：
步骤502，客户端31生成发票访问请求。
在一实施例中，当用户存在访问区块链上存证的某一发票的需求时，可在客户端31中输入目标发票(以用户需访问的发票为上述目标发票为例)的发票内容中的唯一性信息(发票号码、发票代码、发票日期、不含税金额等信息)。那么客户端31可根据该唯一性信息生成发票访问请求。例如，客户端31可直接在发票访问请求中添加该唯一性信息；或者，客户端31可对该唯一性信息进行hash计算，以将计算得到的hash值作为标致信息添加至发票访问请求中。
步骤504，客户端31向跨链路由设备32发送发票访问请求。
步骤506，跨链路由设备32根据标识信息确定目标区块链。
在一实施例中，当发票访问请求中记录的是目标发票的唯一性信息时，读对该唯一性信息进行hash计算以得到目标发票的标识信息；当发票访问请求中记录有目标发票的标识信息(客户端31根据用户输入的发票内容中的唯一性信息进行hash计算得到的hash值)时，直接读取该标识信息即可。在获取到标识信息后，根据上述图4所示实施例得到的对应关系查询与目标发票对应的目标区块链。承接于上述表2的举例，假定获取到的标识信息为hash值1，根据表2记录的对应关系可确定出目标区块链为区块链A。
步骤508，跨链路由设备32构建发票访问交易。
在一实施例中，由于各个行政区域的交易格式可能存在差异，跨链路由设备32在确定出目标区块链之后，需要进行交易格式的转换。承接于上述举例，跨链路由设备32在确定出目标区块链为区块链A后，可基于区块链A支持的交易格式，构建对应于发票访问请求的发票访问交易(即该发票访问交易的交易格式为区块链A支持的交易格式，并且该发票访问交易包括目标发票的标识信息)。
步骤510，跨链路由设备32向目标节点设备发送构建的发票访问交易。
承接于上述举例，如图3所示，区块链A的节点设备中与跨链路由设备32接入的为节点设备33A(即节点设备33A为目标节点设备)。那么，跨链路由设备32在构建出发票访问交易后，可向节点设备33A发送该发票访问交易。
步骤512，目标节点设备根据目标发票的标识信息在目标区块链中获取目标发票。
步骤514，目标节点设备将获取到的目标发票返回至跨链路由设备32。
步骤516，跨链路由设备32将目标发票返回至客户端31。
由以上技术方案可见，一方面，通过跨链路由设备将发票存证请求和发票访问请求转发至相应区块链的节点设备，可实现针对发票的跨链存证和跨链访问。另一方面，即使各区块链采用不同的区块链技术搭建，由位于中间层的跨链路由设备屏蔽了底层技术实现上的差异，客户端也无需与区块链的节点设备对接；换言之，对于外部的客户端来说，在逻辑上只有一个区块链，而物理上的区块链对外不露出，客户端感知不到底层区块链之间的差异(比如，客户端无需构建对应于各个区块链的交易格式)，通过跨链路由设备在区块链上存证和访问发票即可，而无需直接访问某个特定的区块链。
图6是一示例性实施例提供的一种设备的示意结构图。请参考图6，在硬件层面，该设备包括处理器602、内部总线604、网络接口606、内存608以及非易失性存储器610，当然还可能包括其他业务所需要的硬件。处理器602从非易失性存储器610中读取对应的计算机程序到内存608中然后运行，在逻辑层面上形成跨链存证装置。当然，除了软件实现方式之外，本说明书一个或多个实施例并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
请参考图7，在软件实施方式中，该跨链存证装置应用于跨链路由设备，所述跨链路由设备与多个区块链的节点设备保持通讯连接；该装置可以包括：
存证接收单元71，接收客户端发起的发票存证请求；其中，所述发票存证请求包括目标发票；
第一确定单元72，响应于所述发票存证请求，基于预设规则从所述多个区块链中为所述目标发票确定对应的目标区块链；
第一转发单元73，将所述发票存证请求转发至所述目标区块链的节点设备，以由所述目标区块链的节点设备对所述目标发票进行共识处理，并在共识通过后将所述目标发票在所述目标区块链中进行存证。
可选的，还包括：
消息接收单元74，接收所述目标区块链中的节点设备返回的所述目标发票存证成功的通知消息；
保存单元75，响应于所述通知消息，在本地保存所述目标发票的标识信息与所述目标区块链的对应关系。
可选的，所述目标发票的标识信息，包括：
针对所述目标发票的发票内容；或者，所述发票内容中的唯一性信息进行hash计算得到的hash值。
可选的，所述发票存证请求中还包括所述目标发票的发票代码；所述多个区块链分别对应不同的发票代码取值范围；
所述第一确定单元72具体用于：
将所述目标发票的发票代码与所述多个区块链对应的发票代码取值范围分别进 行匹配；如果所述目标发票的发票代码的取值位于所述多个区块链中的任一区块链对应的发票代码取值范围，则将该区块链确定为与所述目标发票对应的目标区块链。
可选的，所述第一转发单元73具体用于：
基于所述目标区块链支持的交易格式，构建对应于所述发票存证请求的发票存证交易；其中，所述发票存证交易包括所述目标发票；
将所述发票存证交易发送至所述目标区块链的节点设备。
可选的，还包括：
访问接收单元76，接收客户端发起的发票访问请求；其中，所述发票访问请求包括待访问的目标发票的标识信息；
第二确定单元77，响应于所述发票访问请求，查询所述对应关系，确定与所述目标发票的标识信息对应的目标区块链；
第二转发单元78，将所述发票访问请求转发至所述目标区块链的节点设备，并将所述目标区块链的节点设备返回的所述待访问的目标发票转发给所述客户端。
可选的，所述第二转发单元78具体用于：
基于所述目标区块链支持的交易格式，构建对应于所述发票访问请求的发票访问交易；其中，所述发票访问交易包括所述目标发票的标识信息；
将所述发票访问交易发送至所述目标区块链的节点设备。
可选的，所述多个区块链分别对应不同的行政区域。
图8是一示例性实施例提供的另一种设备的示意结构图。请参考图8，在硬件层面，该设备包括处理器802、内部总线804、网络接口806、内存808以及非易失性存储器810，当然还可能包括其他业务所需要的硬件。处理器802从非易失性存储器810中读取对应的计算机程序到内存808中然后运行，在逻辑层面上形成跨链访问装置。当然，除了软件实现方式之外，本说明书一个或多个实施例并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
请参考图9，在软件实施方式中，该跨链访问装置应用于跨链路由设备，所述跨链路由设备与多个区块链的节点设备保持通讯连接，所述跨链路由设备本地保存有发票的标识信息与区块链的对应关系；该装置可以包括：
接收单元91，接收客户端发起的发票访问请求；其中，所述发票访问请求包括待访问的目标发票的标识信息；
确定单元92，响应于所述发票访问请求，查询所述对应关系，确定与所述目标发票的标识信息对应的目标区块链；
转发单元93，将所述发票访问请求转发至所述目标区块链的节点设备，并将所述目标区块链的节点设备返回的所述待访问的目标发票转发给所述客户端。
可选的，所述转发单元93具体用于：
基于所述目标区块链支持的交易格式，构建对应于所述发票访问请求的发票访问交易；其中，所述发票访问交易包括所述目标发票的标识信息；
将所述发票访问交易发送至所述目标区块链的节点设备。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
在一个典型的配置中，计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。
Claims (22)
- 一种跨链存证方法，应用于跨链路由设备，所述跨链路由设备与多个区块链的节点设备保持通讯连接；所述方法包括：接收客户端发起的发票存证请求；其中，所述发票存证请求包括目标发票；响应于所述发票存证请求，基于预设规则从所述多个区块链中为所述目标发票确定对应的目标区块链；将所述发票存证请求转发至所述目标区块链的节点设备，以由所述目标区块链的节点设备对所述目标发票进行共识处理，并在共识通过后将所述目标发票在所述目标区块链中进行存证。
- 根据权利要求1所述的方法，还包括：接收所述目标区块链中的节点设备返回的所述目标发票存证成功的通知消息；响应于所述通知消息，在本地保存所述目标发票的标识信息与所述目标区块链的对应关系。
- 根据权利要求2所述的方法，所述目标发票的标识信息，包括：针对所述目标发票的发票内容；或者，所述发票内容中的唯一性信息进行hash计算得到的hash值。
- 根据权利要求1所述的方法，所述发票存证请求中还包括所述目标发票的发票代码；所述多个区块链分别对应不同的发票代码取值范围；所述基于预设规则从所述多个区块链中为所述目标发票确定对应的目标区块链，包括：将所述目标发票的发票代码与所述多个区块链对应的发票代码取值范围分别进行匹配；如果所述目标发票的发票代码的取值位于所述多个区块链中的任一区块链对应的发票代码取值范围，则将该区块链确定为与所述目标发票对应的目标区块链。
- 根据权利要求1所述的方法，将所述发票存证请求转发至所述目标区块链的节点设备，包括：基于所述目标区块链支持的交易格式，构建对应于所述发票存证请求的发票存证交易；其中，所述发票存证交易包括所述目标发票；将所述发票存证交易发送至所述目标区块链的节点设备。
- 根据权利要求2所述的方法，还包括：接收客户端发起的发票访问请求；其中，所述发票访问请求包括待访问的目标发票的标识信息；响应于所述发票访问请求，查询所述对应关系，确定与所述目标发票的标识信息对应的目标区块链；将所述发票访问请求转发至所述目标区块链的节点设备，并将所述目标区块链的节点设备返回的所述待访问的目标发票转发给所述客户端。
- 根据权利要求6所述的方法，将所述发票访问请求转发至所述目标区块链的节点设备，包括：基于所述目标区块链支持的交易格式，构建对应于所述发票访问请求的发票访问交易；其中，所述发票访问交易包括所述目标发票的标识信息；将所述发票访问交易发送至所述目标区块链的节点设备。
- 根据权利要求1所述的方法，所述多个区块链分别对应不同的行政区域。
- 一种跨链访问方法，应用于跨链路由设备，所述跨链路由设备与多个区块链的节点设备保持通讯连接，所述跨链路由设备本地保存有发票的标识信息与区块链的对应关系；所述方法包括：接收客户端发起的发票访问请求；其中，所述发票访问请求包括待访问的目标发票的标识信息；响应于所述发票访问请求，查询所述对应关系，确定与所述目标发票的标识信息对应的目标区块链；将所述发票访问请求转发至所述目标区块链的节点设备，并将所述目标区块链的节点设备返回的所述待访问的目标发票转发给所述客户端。
- 根据权利要求9所述的方法，将所述发票访问请求转发至所述目标区块链的节点设备，包括：基于所述目标区块链支持的交易格式，构建对应于所述发票访问请求的发票访问交易；其中，所述发票访问交易包括所述目标发票的标识信息；将所述发票访问交易发送至所述目标区块链的节点设备。
- 一种跨链存证装置，应用于跨链路由设备，所述跨链路由设备与多个区块链的节点设备保持通讯连接；所述装置包括：存证接收单元，接收客户端发起的发票存证请求；其中，所述发票存证请求包括目标发票；第一确定单元，响应于所述发票存证请求，基于预设规则从所述多个区块链中为所述目标发票确定对应的目标区块链；第一转发单元，将所述发票存证请求转发至所述目标区块链的节点设备，以由所述 目标区块链的节点设备对所述目标发票进行共识处理，并在共识通过后将所述目标发票在所述目标区块链中进行存证。
- 根据权利要求11所述的装置，还包括：消息接收单元，接收所述目标区块链中的节点设备返回的所述目标发票存证成功的通知消息；保存单元，响应于所述通知消息，在本地保存所述目标发票的标识信息与所述目标区块链的对应关系。
- 根据权利要求12所述的装置，所述目标发票的标识信息，包括：针对所述目标发票的发票内容；或者，所述发票内容中的唯一性信息进行hash计算得到的hash值。
- 根据权利要求11所述的装置，所述发票存证请求中还包括所述目标发票的发票代码；所述多个区块链分别对应不同的发票代码取值范围；所述第一确定单元具体用于：将所述目标发票的发票代码与所述多个区块链对应的发票代码取值范围分别进行匹配；如果所述目标发票的发票代码的取值位于所述多个区块链中的任一区块链对应的发票代码取值范围，则将该区块链确定为与所述目标发票对应的目标区块链。
- 根据权利要求11所述的装置，所述第一转发单元具体用于：基于所述目标区块链支持的交易格式，构建对应于所述发票存证请求的发票存证交易；其中，所述发票存证交易包括所述目标发票；将所述发票存证交易发送至所述目标区块链的节点设备。
- 根据权利要求12所述的装置，还包括：访问接收单元，接收客户端发起的发票访问请求；其中，所述发票访问请求包括待访问的目标发票的标识信息；第二确定单元，响应于所述发票访问请求，查询所述对应关系，确定与所述目标发票的标识信息对应的目标区块链；第二转发单元，将所述发票访问请求转发至所述目标区块链的节点设备，并将所述目标区块链的节点设备返回的所述待访问的目标发票转发给所述客户端。
- 根据权利要求16所述的装置，所述第二转发单元具体用于：基于所述目标区块链支持的交易格式，构建对应于所述发票访问请求的发票访问交易；其中，所述发票访问交易包括所述目标发票的标识信息；将所述发票访问交易发送至所述目标区块链的节点设备。
- 根据权利要求11所述的装置，所述多个区块链分别对应不同的行政区域。
- 一种跨链访问装置，应用于跨链路由设备，所述跨链路由设备与多个区块链的节点设备保持通讯连接，所述跨链路由设备本地保存有发票的标识信息与区块链的对应关系；所述装置包括：接收单元，接收客户端发起的发票访问请求；其中，所述发票访问请求包括待访问的目标发票的标识信息；确定单元，响应于所述发票访问请求，查询所述对应关系，确定与所述目标发票的标识信息对应的目标区块链；转发单元，将所述发票访问请求转发至所述目标区块链的节点设备，并将所述目标区块链的节点设备返回的所述待访问的目标发票转发给所述客户端。
- 根据权利要求19所述的装置，所述转发单元具体用于：基于所述目标区块链支持的交易格式，构建对应于所述发票访问请求的发票访问交易；其中，所述发票访问交易包括所述目标发票的标识信息；将所述发票访问交易发送至所述目标区块链的节点设备。
- 一种电子设备，包括：处理器；用于存储处理器可执行指令的存储器；其中，所述处理器通过运行所述可执行指令以实现如权利要求1-8中任一项所述的方法。
- 一种电子设备，包括：处理器；用于存储处理器可执行指令的存储器；其中，所述处理器通过运行所述可执行指令以实现如权利要求9-10中任一项所述的方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811607409.4 | 2018-12-27 | ||
| CN201811607409.4A CN110020902B (zh) | 2018-12-27 | 2018-12-27 | 跨链存证方法及访问方法、装置、电子设备 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2020134615A1 true WO2020134615A1 (zh) | 2020-07-02 |
Family
ID=67188682
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2019/115851 Ceased WO2020134615A1 (zh) | 2018-12-27 | 2019-11-06 | 跨链存证方法及访问方法、装置、电子设备 |
Country Status (3)
| Country | Link |
|---|---|
| CN (1) | CN110020902B (zh) |
| TW (1) | TWI717866B (zh) |
| WO (1) | WO2020134615A1 (zh) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111797169A (zh) * | 2020-07-09 | 2020-10-20 | 杭州复杂美科技有限公司 | 数据存证方法、设备和存储介质 |
| CN112632619A (zh) * | 2020-12-30 | 2021-04-09 | 杭州趣链科技有限公司 | 跨链存证方法、装置、终端设备及存储介质 |
| CN112926033A (zh) * | 2021-03-18 | 2021-06-08 | 南京星链高科技发展有限公司 | 一种基于区块链跨链协作的任务过程追溯系统 |
| CN118283046A (zh) * | 2024-03-29 | 2024-07-02 | 中国工商银行股份有限公司 | 一种基于开放联盟链的跨区块链的交易方法及装置 |
Families Citing this family (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110020902B (zh) * | 2018-12-27 | 2021-01-08 | 创新先进技术有限公司 | 跨链存证方法及访问方法、装置、电子设备 |
| CN110647559B (zh) * | 2019-09-24 | 2024-08-23 | 腾讯科技（深圳）有限公司 | 数据处理方法、相关节点及系统 |
| CN113129144A (zh) * | 2019-12-31 | 2021-07-16 | 航天信息股份有限公司 | 一种交易信息处理的方法、装置和系统 |
| CN111311342B (zh) * | 2020-03-20 | 2025-06-24 | 腾讯科技（深圳）有限公司 | 基于区块链的数据处理方法、装置、设备及可读存储介质 |
| CN111160998B (zh) * | 2020-04-02 | 2021-04-30 | 支付宝(杭州)信息技术有限公司 | 基于区块链的点评数据处理方法、装置及点评系统 |
| CN111737361B (zh) * | 2020-07-22 | 2021-01-15 | 百度在线网络技术（北京）有限公司 | 区块链处理方法、装置、设备和存储介质 |
| CN112699136B (zh) * | 2020-12-29 | 2023-04-14 | 杭州趣链科技有限公司 | 一种跨链存证方法及相关装置 |
| CN112712367A (zh) * | 2021-01-14 | 2021-04-27 | 上海边界智能科技有限公司 | 一种基于区块链的跨链存证方法 |
| CN112435030B (zh) * | 2021-01-27 | 2021-05-07 | 支付宝(杭州)信息技术有限公司 | 一种基于区块链的数据处理方法、装置及电子设备 |
| CN113220453B (zh) * | 2021-05-11 | 2024-05-31 | 支付宝(杭州)信息技术有限公司 | 区块链系统中发起交易的方法及装置 |
| CN113259476B (zh) * | 2021-06-10 | 2022-09-30 | 深圳市腾讯信息技术有限公司 | 消息推送方法及系统 |
| CN113537745A (zh) * | 2021-07-06 | 2021-10-22 | 招商银行股份有限公司 | 业务处理方法、设备、介质及计算机程序产品 |
| CN116566710B (zh) * | 2023-05-28 | 2024-04-26 | 深圳市远东数智采技术服务有限公司 | 一种区块链数据管理方法及系统 |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106850538A (zh) * | 2016-12-06 | 2017-06-13 | 中金云金融（北京）大数据科技股份有限公司 | 区块链路由接入系统及方法 |
| US20170346639A1 (en) * | 2016-05-24 | 2017-11-30 | Business Information Exchange System Corp. | Public Key Infrastructure based on the Public Certificates Ledger |
| CN108399572A (zh) * | 2018-03-22 | 2018-08-14 | 深圳市网心科技有限公司 | 区块链交易处理方法、装置及存储介质 |
| CN108492108A (zh) * | 2018-03-29 | 2018-09-04 | 深圳前海微众银行股份有限公司 | 区块链跨链通信方法、系统和计算机可读存储介质 |
| US20180343120A1 (en) * | 2016-10-26 | 2018-11-29 | Black Gold Coin, Inc. | Systems and methods for providing a universal decentralized solution for verification of users with cross-verification features |
| CN110020902A (zh) * | 2018-12-27 | 2019-07-16 | 阿里巴巴集团控股有限公司 | 跨链存证方法及访问方法、装置、电子设备 |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9892460B1 (en) * | 2013-06-28 | 2018-02-13 | Winklevoss Ip, Llc | Systems, methods, and program products for operating exchange traded products holding digital math-based assets |
| JP6565360B2 (ja) * | 2015-06-17 | 2019-08-28 | 富士通株式会社 | 接続装置およびストレージ装置 |
| CN106952124A (zh) * | 2017-03-16 | 2017-07-14 | 北京牛链科技有限公司 | 基于分布式记账的电子发票管理系统和方法 |
| CN108805704A (zh) * | 2018-05-16 | 2018-11-13 | 深圳市网心科技有限公司 | 区块链业务实现方法、监听设备、存储介质及系统 |
| CN108830600B (zh) * | 2018-06-19 | 2022-02-18 | 方欣科技有限公司 | 一种基于区块链的电子发票系统及实现方法 |
| CN108922012B (zh) * | 2018-07-11 | 2020-05-19 | 北京大账房网络科技股份有限公司 | 基于区块链技术不泄露原始信息的发票查验方法 |
-
2018
- 2018-12-27 CN CN201811607409.4A patent/CN110020902B/zh active Active
-
2019
- 2019-10-17 TW TW108137450A patent/TWI717866B/zh active
- 2019-11-06 WO PCT/CN2019/115851 patent/WO2020134615A1/zh not_active Ceased
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20170346639A1 (en) * | 2016-05-24 | 2017-11-30 | Business Information Exchange System Corp. | Public Key Infrastructure based on the Public Certificates Ledger |
| US20180343120A1 (en) * | 2016-10-26 | 2018-11-29 | Black Gold Coin, Inc. | Systems and methods for providing a universal decentralized solution for verification of users with cross-verification features |
| CN106850538A (zh) * | 2016-12-06 | 2017-06-13 | 中金云金融（北京）大数据科技股份有限公司 | 区块链路由接入系统及方法 |
| CN108399572A (zh) * | 2018-03-22 | 2018-08-14 | 深圳市网心科技有限公司 | 区块链交易处理方法、装置及存储介质 |
| CN108492108A (zh) * | 2018-03-29 | 2018-09-04 | 深圳前海微众银行股份有限公司 | 区块链跨链通信方法、系统和计算机可读存储介质 |
| CN110020902A (zh) * | 2018-12-27 | 2019-07-16 | 阿里巴巴集团控股有限公司 | 跨链存证方法及访问方法、装置、电子设备 |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111797169A (zh) * | 2020-07-09 | 2020-10-20 | 杭州复杂美科技有限公司 | 数据存证方法、设备和存储介质 |
| CN112632619A (zh) * | 2020-12-30 | 2021-04-09 | 杭州趣链科技有限公司 | 跨链存证方法、装置、终端设备及存储介质 |
| CN112926033A (zh) * | 2021-03-18 | 2021-06-08 | 南京星链高科技发展有限公司 | 一种基于区块链跨链协作的任务过程追溯系统 |
| CN118283046A (zh) * | 2024-03-29 | 2024-07-02 | 中国工商银行股份有限公司 | 一种基于开放联盟链的跨区块链的交易方法及装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110020902A (zh) | 2019-07-16 |
| TW202025685A (zh) | 2020-07-01 |
| TWI717866B (zh) | 2021-02-01 |
| CN110020902B (zh) | 2021-01-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2020134615A1 (zh) | 跨链存证方法及访问方法、装置、电子设备 | |
| JP7721797B2 (ja) | 非代替性トークンのための保管システム | |
| US10733176B2 (en) | Detecting phantom items in distributed replicated database | |
| CN109145205B (zh) | 一种基于区块链的跨链数据操作方法和装置 | |
| US11030217B2 (en) | Blockchain implementing cross-chain transactions | |
| US20240037267A1 (en) | Authenticating Accesses to a Shared Datastore of a Multi-Tenant Computer System | |
| TWI706280B (zh) | 資料讀寫方法及裝置、電子設備 | |
| WO2020134699A1 (zh) | 基于区块链的发票报销方法、装置及电子设备 | |
| TW201937436A (zh) | 基於區塊鏈的交易執行方法及裝置、電子設備 | |
| CN110019540B (zh) | 企业图谱的实现方法、展示方法及装置、设备 | |
| TW202022857A (zh) | 基於區塊鏈的發票創建方法及裝置、電子設備 | |
| TW202022754A (zh) | 基於區塊鏈的發票創建方法及裝置、電子設備 | |
| KR20200099602A (ko) | 계층화된 그래프 데이터 구조 | |
| WO2020125233A1 (zh) | 字段更新方法及装置、电子设备 | |
| CN113220717B (zh) | 基于区块链的数据核验方法及装置、电子设备 | |
| CN106933891A (zh) | 访问分布式数据库的方法和分布式数据服务的装置 | |
| US20200169402A1 (en) | Data storage on tree nodes | |
| TW202105197A (zh) | 區塊鏈資料的分次獲取方法和裝置 | |
| CN103973810A (zh) | 基于互联网协议ip盘的数据处理方法和装置 | |
| WO2020125224A1 (zh) | 数据结构的读取及更新方法、装置、电子设备 | |
| CN110837499B (zh) | 数据访问处理方法、装置、电子设备和存储介质 | |
| WO2016101759A1 (zh) | 一种数据路由方法、数据管理装置和分布式存储系统 | |
| WO2020108052A1 (zh) | 一种基于多个区块链网络的数据读取方法及系统 | |
| TWI812366B (zh) | 一種資料共用方法、裝置、設備及存儲介質 | |
| CN111966731A (zh) | 一种在区块链系统中查询数据的方法和装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 19902563 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 19902563 Country of ref document: EP Kind code of ref document: A1 |