Detailed Description
The technical solutions of the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is apparent that the described embodiments are only some embodiments of the present specification, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.
Please refer to fig. 1 and 2. The embodiment of the specification provides a data processing method based on a block chain.
In this embodiment, the blockchain (blockchain) may be a distributed ledger that organizes a plurality of blockdata in a chained structure according to a time sequence, and guarantees security, traceability, and non-falsifiability by using a cryptographic algorithm. The blockchains may include public blockchains, federated blockchains (also known as federated blockchains), private blockchains, and the like. The blockchain may be implemented based on a blockchain network. The blockchain network may include a P2P network (peer-to-peer network) or the like. The blockchain network may include a plurality of blockchain nodes. And the unified blockchain ledgers are commonly maintained among the blockchain nodes.
In this embodiment, the data processing method uses the sender server as an execution subject. The sender server may join the blockchain network as a blockchain node. An account of the sink may be logged into the sink server. The exporter account may be an account of an exporter in the blockchain. The sink server is capable of communicating with clients. The client may be, for example, a smart phone, a tablet electronic device, a portable computer, a Personal Digital Assistant (PDA), or a smart wearable device, etc. The data processing method may include the following steps.
Step S10: and calculating the commit time according to the reference time and the commit time interval.
In this embodiment, the reference time may include at least one of: the time of last submitting combined transaction information to the blockchain, the time of last submitting false transaction information to the blockchain. Details regarding the combined transaction information and the dummy transaction information will be presented in the following process.
In this embodiment, the value of the commit time interval may be flexibly set according to the service requirement. Specifically, the value of the submitting time interval may be a fixed value; or the method can be divided into time periods according to the actual service demand, and each time period is set to be a fixed value; or may be a random value. For example, the value of the commit time interval at the peak of the transaction may be set to 0.1 seconds (shorter or longer may also be set depending on the business requirements); the value of the commit time interval at the low valley period of the transaction may be set to 1 minute (shorter or longer may also be set depending on the business requirements). Of course, the value of the commit time interval may also be set according to a distribution function, so that the value of the commit time interval satisfies the distribution function. The distribution functions may include, for example, an exponential distribution function and an allangerhans distribution (Erlang Distribution) function. Wherein the expression of the exponential distribution function can beThe expression of the Allang distribution function can beWhere x represents the value of the commit time interval; lambda represents the arrival rate; k represents the order of the allran distribution function. Wherein the arrival rate may represent the number of event occurrences per unit time. In some examples of scenarios, the arrival rate may specifically represent the number of transactions per unit time. In actual business, for example, the expected transaction (including real and spurious transactions) arrival rate D for the commit time interval may be set; the actual arrival rate E of the actual transaction may be counted. Then λ=d-E in the exponential distribution function and the allron distribution function. Of course, it should be understood by those skilled in the art that the above manner of setting the values of the commit time intervals according to the distribution function and the alwnian distribution function is merely an example, and that the values of the commit time intervals may be set according to the distribution function and the alwnian distribution function in fact in any other suitable manner.
In this embodiment, the sender server may add the reference time and the commit time interval to obtain the commit time. Specifically, the sender server may add the time when the transaction information was last submitted to the blockchain to the commit time interval to obtain the commit time. The time at which the transaction information was last submitted to the blockchain may be the time at which the consolidated transaction information was submitted, or may also be the time at which the spurious transaction information was submitted.
Step S12: and after the submitting moment arrives, merging at least one piece of original transaction information received in the submitting time interval to obtain at least one piece of merged transaction information.
In this embodiment, the original transaction information may be transaction information from the client. Specifically, during the commit time interval, the client may send transaction information to the exporter server, which may receive the transaction information as original transaction information. Wherein the original transaction information may include a sink account identification and its corresponding original transaction amount. The sender account identification may be used to identify a sender account, such as a name or address of the sender account. In one implementation of this embodiment, the original transaction information may further include real business information. The real service information may include, for example, an order number, user information, and the like. The original transaction information may directly include the real service information, or may further include ciphertext of the real service information. Further, in this embodiment, the original transaction information may further include signature information of the real business information.
In this embodiment, the consolidated transaction information may include at least one sink account identification and its corresponding consolidated transaction amount. In the consolidated transaction information, a consolidated transaction amount corresponding to the sender account identifier may be calculated according to an original transaction amount corresponding to the sender account identifier, for example, a sum of the original transaction amounts corresponding to the sender account identifier may be calculated. In one implementation of this embodiment, the original transaction information may include real business information. Accordingly, the consolidated transaction information may include real business information corresponding to at least one sender account identification. The real business information corresponding to the sink account identifier in the merged transaction information can be determined according to the real business information corresponding to the sink account identifier in the original transaction information. The consolidated transaction information may directly include the real service information, or may further include ciphertext of the real service information. Further, in this embodiment, the combined transaction information may further include signature information of the real service information.
In this embodiment, the amount of original transaction information received by the sender server during the commit time interval may be one or more. When the number of received original transaction information is one, the sender server may directly use the original transaction information as the combined transaction information. When the number of received original transaction information is a plurality, the sender server may combine the plurality of original transaction information into at least one combined transaction information. In particular, the sender server may combine the plurality of original transaction information into at least one combined transaction information in any manner. For example, the sender server may combine the plurality of original transaction information into one combined transaction information. As another example, the sender server may combine the original transaction information having the same sender account identifier in the plurality of original transaction information into one combined transaction information.
In one example scenario, the original transaction information received by the sender server during the commit time interval may include 5 of A1, A2, A3, B1, B2, etc. The 5 pieces of original transaction information may be as shown in table 1 below.
TABLE 1
Name of original transaction information |
Inward account identification |
Transaction amount |
A1 |
A |
10 |
A2 |
A |
20 |
A3 |
A |
30 |
B1 |
B |
40 |
B2 |
B |
50 |
The sender server may combine the 5 original transaction information into one combined transaction information. The consolidated transaction information obtained by consolidation may be as shown in table 2 below.
TABLE 2
Inward account identification |
Transaction amount |
A |
60 |
B |
90 |
In another example scenario, the original transaction information received by the sender server during the commit time interval may include 5 of A4, A5, A6, B3, B4, etc. The 5 pieces of original transaction information may be as shown in table 3 below.
TABLE 3 Table 3
Name of original transaction information |
Inward account identification |
Transaction amount |
Service information |
Signature information |
A4 |
A |
10 |
A4_D |
A4_QM |
A5 |
A |
20 |
A5_D |
A5_QM |
A6 |
A |
30 |
A6_D |
A6_QM |
B3 |
B |
40 |
B3_D |
B3_QM |
B4 |
B |
50 |
B4_D |
B4_QM |
The sender server may combine the 5 original transaction information into one combined transaction information. The consolidated transaction information obtained by the consolidation may be as shown in table 4 below.
TABLE 4 Table 4
Of course, the sender server may also merge the 5 original transaction messages into two merged transaction messages. The combined transaction information obtained by the combination may be shown in the following tables 5 and 6, respectively.
TABLE 5
TABLE 6
Step S14: submitting the at least one consolidated transaction information to the blockchain.
In this embodiment, the sink device may submit the at least one consolidated transaction information to the blockchain; so that the common blockchain node in the blockchain can update the balance of the sink account and the balance of the sink account according to the combined transaction amount in the combined transaction information. For example, deducting the consolidated transaction amount from the balance of the sink account; the combined transaction amount is credited to the balance of the sender account. The sink device may submit the at least one merged transaction information to the blockchain at the same time, or may also submit the at least one merged transaction information to the blockchain separately.
In one implementation of this embodiment, before submitting the at least one consolidated transaction information to the blockchain, for each of the at least one consolidated transaction information, the sink server may further generate verification information from the consolidated transaction information; the verification information may be added to the consolidated transaction information. For example, the verification information may include signature information that incorporates transaction information.
In one implementation of this embodiment, the sender server may further encrypt the consolidated transaction amount in the at least one consolidated transaction information prior to submitting the at least one consolidated transaction information to the blockchain. This allows for hiding and confidentiality of the consolidated transaction amount.
In one implementation of this embodiment, the sender server may be provided with a set of false traffic information. The set of dummy service information may include at least one dummy service information. The dummy service information may include, for example, a dummy order number, dummy user information, and so on. The dummy service information may be preset. In this manner, the sender server may further select, for each sender account identifier in each merged transaction information, at least one piece of dummy service information from the set of dummy service information as the corresponding dummy service information in the merged transaction information before submitting the at least one merged transaction information to the blockchain. The number of the selected false service information can be flexibly set according to service requirements, for example, 1,2 or 5 false service information can be selected. Thus, by adding false business information into the combined transaction information, the quantity of the real business information in the combined transaction information can be hidden, and the transaction number is prevented from being leaked through the quantity of the real business information in the combined transaction information.
Further, in this embodiment, the dummy service information in the set of dummy service information may correspond to signature information. Accordingly, each consolidated transaction information may also include signature information corresponding to the dummy transaction information.
Further, in this embodiment, the false service information in the set of false service information may correspond to an account identifier of the sender. In this way, for each sender account identifier in each merged transaction information, the sender server may select, from the set of false service information, the false service information corresponding to the sender account identifier as the false service information in the merged transaction information.
For example, the set of dummy traffic information may include dummy traffic information AXJ _ D, AXJ2_ D, AXJ3_ D, BXJ1 _1_ D, BXJ2 _2_d. Wherein the dummy service information AXJ1_ D, AXJ2_ D, AXJ3_d may correspond to the sink account identification a; the dummy service information bxj1_ D, BXJ2_d may correspond to the sink account identification B. The signature information of the dummy traffic information AXJ1_ D, AXJ2_ D, AXJ3_ D, BXJ1 _1_ D, BXJ2_d may be AXJ1_qm, axj2_qm, axj3_qm, bxj1_qm, bxj2_qm, respectively.
The combined transaction information obtained by the combination may be as shown in the above table 4. Then, after adding the dummy transaction information, the consolidated transaction information may be as shown in table 7 below.
TABLE 7
In one implementation of this embodiment, the client may not send transaction information to the sender server during the commit time interval. Such that the sink server does not receive the original transaction information during the commit time interval. The sink server may thus generate spurious transaction information. The fraudulent transaction information may include a sink account identification and its corresponding zero value transaction amount. The sender server may obtain the sender account identification as the sender account identification in the fraudulent transaction information in any manner. For example, the sender server may randomly choose an account identification in a blockchain as the sender account identification in the spurious transaction information.
The remitter server can encrypt the transaction amount with the value of zero in the false transaction information; the spurious transaction information may be submitted to the blockchain. Thus, after the common block chain link point in the block chain updates the balance of the account of the sink and the balance of the account of the sink according to the transaction amount with the value of zero, the balance of the account of the sink and the balance of the account of the sink can be kept unchanged.
In this embodiment, the remitter server may perform merging processing on the original transaction information received in the submitting time interval, so that the third party cannot obtain the number of the original transaction information actually submitted to the blockchain, thereby hiding the transaction number of the remitter account on the blockchain. In addition, by combining the original transaction information received during the commit time interval, the amount of transaction information processed by the blockchain can also be reduced, and thus the burden on the blockchain throughput can be reduced.
Please refer to fig. 1 and 2. One example of a scenario for the embodiments of the present description is presented below.
In this scenario example, the sink device may have a set of spurious traffic information stored locally in advance. The set of dummy service information may include at least one dummy service information. The false business information in the false business information set may correspond to the sender account identification and signature information. The false service information in the false service information set can be agreed in advance by the sink and the sink. Specifically, for example, the sink may generate dummy service information in advance and transmit it to the sink. The importer can sign the false service information to obtain the signature information of the false service information; the signature information of the dummy service information can be fed back to the sink.
In this scenario example, the exporter server may add the time of the last submission of the transaction information to the blockchain to the commit time interval to obtain the commit time. The time of last submitting transaction information to the blockchain can be the time of submitting false transaction information or the time of submitting real transaction information. After the submitting time arrives, the remitter server can combine at least one original transaction information received in the submitting time interval to obtain at least one combined transaction information.
In this scenario example, the exporter's server may process the at least one consolidated transaction information as follows.
And selecting false business information corresponding to the account identifier of the importer from the false business information set as false business information in the combined transaction information aiming at the account identifier of the importer in each combined transaction information.
And encrypting the combined transaction amount in the at least one piece of combined transaction information.
Carrying out signature processing on each piece of combined transaction information to obtain signature information; the signature information is added to the consolidated transaction information.
In this scenario example, after the above-described processing, the exporter server may submit the at least one consolidated transaction information to the blockchain.
The blockchain may determine a consensus blockchain node based on a consensus mechanism. For each consolidated transaction information, the common blockchain node may verify whether the transaction has been executed using the anti-double or anti-replay mechanism of the related art; if already performed, the transaction may be rejected; if not, verifying whether the signature information in the combined transaction information is correct; if not, the transaction may be declined; if so, the balance of the sink account and the balance of the sender account may be updated based on the consolidated transaction amount in the consolidated transaction information.
Please refer to fig. 3. The embodiment of the specification provides a data processing device based on a block chain. The apparatus may comprise the following units.
A calculating unit 20 for calculating a commit time according to the reference time and the commit time interval;
A merging unit 22, configured to, after the commit time arrives, merge at least one piece of original transaction information received in the commit time interval, so as to obtain at least one piece of merged transaction information;
a submitting unit 24 for submitting the at least one merged transaction information to the blockchain.
Please refer to fig. 4. The embodiment of the specification also provides a server. The server may include a memory and a processor.
In this embodiment, the memory may be implemented in any suitable manner. For example, the memory may be a read-only memory, a mechanical hard disk, a solid state hard disk, or a usb disk. The memory may be used to store computer instructions.
In this embodiment, the processor may be implemented in any suitable manner. For example, a processor may take the form of, for example, a microprocessor or processor, and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, application SPECIFIC INTEGRATED Circuits (ASICs), programmable logic controllers, and embedded microcontrollers, among others. The processor may execute the computer instructions to implement the steps of: calculating the submitting time according to the reference time and the submitting time interval; after the submitting time arrives, merging at least one piece of original transaction information received in the submitting time interval to obtain at least one piece of merged transaction information; submitting the at least one consolidated transaction information to the blockchain.
It should be noted that, in the present specification, each embodiment is described in a progressive manner, and the same or similar parts of each embodiment are referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for the device embodiment and the server embodiment, since they are substantially similar to the method embodiment, the description is relatively simple, and reference is made to the partial description of the method embodiment for relevant points.
Those skilled in the art, after reading this specification, will recognize without undue burden that any and all of the embodiments set forth herein can be combined, and that such combinations are within the scope of the disclosure and protection of the present specification.
In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable GATE ARRAY, FPGA)) is an integrated circuit whose logic functions are determined by user programming of the device. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips 2. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented with "logic compiler (logic compiler)" software, which is similar to the software compiler used in program development and writing, and the original code before being compiled is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but HDL is not just one, but a plurality of kinds, such as ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language), and VHDL (Very-High-SPEED INTEGRATED Circuit Hardware Description Language) and Verilog2 are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.
The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
From the above description of embodiments, it will be apparent to those skilled in the art that the present description may be implemented in software plus a necessary general purpose hardware platform. Based on this understanding, the technical solution of the present specification may be embodied in essence or a part contributing to the prior art in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method described in the embodiments or some parts of the embodiments of the present specification.
The specification is operational with numerous general purpose or special purpose computer system environments or configurations. For example: personal computers, server computers, hand-held or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
Although the present specification has been described by way of example, it will be appreciated by those skilled in the art that there are many variations and modifications to the specification without departing from the spirit of the specification, and it is intended that the appended claims encompass such variations and modifications as do not depart from the spirit of the specification.