LIGHTWEIGHT DATA STORAGE APPARATUS FOR GRAPHIC BLOCKCHAIN AND METHOD THEREOF
20230015556 · 2023-01-19
Inventors
- Jiang XIAO (Wuhan City, CN)
- Xiaohai DAI (Wuhan City, CN)
- Shijie ZHANG (Wuhan City, CN)
- Hai JIN (Wuhan City, CN)
Cpc classification
G06F16/27
PHYSICS
H04L2209/56
ELECTRICITY
G06F16/2379
PHYSICS
International classification
H04L9/00
ELECTRICITY
Abstract
The present invention relates to a lightweight data storage apparatus for graphic blockchains, at least comprising a common transaction construction module for a user to initiate new transactions and a network broadcast module for broadcasting the transactions, wherein the apparatus further comprises a combined-transaction constructing module and a transaction deleting module, wherein the combined-transaction constructing module serves to determine whether number of transactions initiated by an account satisfies a first predetermined condition, and if yes, execute a first lightening procedure on the transactions, and the transaction deleting module serves to execute a second lightening procedure on the transactions that have been processed by the first lightening procedure and now have validation references satisfying a second predetermined condition, after which the network broadcast module broadcasts the transactions obtained after the second lightening procedure. With the disclosed transaction-combining and reference-transaction-deleting scheme, data storage overheads of a graphic blockchain can be reduced.
Claims
1. A lightweight data storage apparatus for graphic blockchains, the apparatus at least comprising a common transaction construction module for a user to initiate new transactions and a network broadcast module for broadcasting the transactions, wherein the lightweight data storage apparatus further comprises a combined-transaction constructing module and a transaction deleting module, wherein the combined-transaction constructing module serves to determine whether number of transactions initiated by an account satisfies a first predetermined condition, and if yes, execute a first lightening procedure on the transactions, and the transaction deleting module serves to execute a second lightening procedure on the transactions that have been processed in the first lightening procedure and now have validation references satisfying a second predetermined condition, after which the network broadcast module broadcasts the transactions obtained after the second lightening procedure.
2. The lightweight data storage apparatus of claim 1, wherein the combined-transaction constructing module is configured to periodically determine whether the number of the transactions initiated by the account satisfies the first predetermined condition for combination.
3. The lightweight data storage apparatus of claim 2 further comprising a common transaction construction module that serves to construct data of new transaction initiated by the user.
4. The lightweight data storage apparatus of claim 3, wherein the combined-transaction constructing module is for collecting at least one previous transaction prior to the construction of the new transaction and combining the collected at least one previous transaction with the recently constructed new transaction.
5. The lightweight data storage apparatus of claim 4, wherein the combined-transaction constructing module is configured to generate at least one of the followings for the combined transaction through the first lightening procedure: content site, header site, validation site, and signature site.
6. The lightweight data storage apparatus of claim 5, further comprising a content site compressing module, which serves to uniformly store the content sites in the different combined transactions associated with the same account.
7. The lightweight data storage apparatus of claim 6, wherein the apparatus is configured to combine validation references of individual transactions so as to construct a validation site in a combined transaction.
8. The lightweight data storage apparatus of claim 7, wherein the second predetermined condition includes: at least one transaction in the combined transaction has reached a reference override state.
9. The lightweight data storage apparatus of claim 8, wherein the apparatus is configured to delete validation reference data of transactions that have reached the reference override state.
10. The lightweight data storage apparatus of claim 9, wherein the apparatus is configured to have the account construct a common transaction, and broadcast the common transaction if the number of transactions initiated by an account does not satisfy the first predetermined condition.
11. A lightweight data storage method for graphic blockchains, the method at least comprising: determining whether number of transactions initiated by an account satisfies a first predetermined condition; executing a combining procedure on the transactions, when the number of transactions satisfies the first predetermined condition; determining whether validation references of the transactions satisfy a second predetermined condition; executing a deleting procedure on the transactions, when the validation references satisfy the second predetermined condition; and broadcasting the combined transactions.
12. The lightweight data storage method of claim 11, wherein further comprising periodically determining whether the number of the transactions initiated by the account satisfies the first predetermined condition for combination.
13. The lightweight data storage method of claim 12, wherein the first predetermined condition includes: the current number of the transactions initiated by the account is an integer multiple of a predetermined threshold for the number of transactions.
14. The lightweight data storage method of claim 13, wherein further comprising combining at least two of the transactions initiated by the account corresponding to the predetermined threshold for the number of transactions and obtaining a combined transaction.
15. The lightweight data storage method of claim 14, wherein the step of combining transactions at least comprises: combining validation references of individual transactions so as to construct a validation site in a combined transaction.
16. The lightweight data storage method of claim 15, wherein the second predetermined condition includes: at least one transaction in the combined transaction has reached a reference override state.
17. The lightweight data storage method of claim 16, wherein the step of deleting transactions at least comprises: deleting validation reference data of transactions that have reached the reference override state.
18. The lightweight data storage method of claim 17, wherein if the number of transactions initiated by an account does not satisfy the first predetermined condition, the account constructs a common transaction, and broadcasts the common transaction.
19. A lightweight data storage apparatus applicable to graphic blockchains, which at least comprises a common transaction construction module for users to initiate new transactions, the apparatus further comprising: a combined-transaction constructing module, being configured to collect at least one transaction initiated by the account previously, and combine relevant fields in the at least one transaction initiated by the account previously with relevant fields in a new transaction; a reference override computing module, for computing override relationship of validation references contained in the new transaction; and a transaction deleting module, for deleting transactions that have reached the reference override state.
20. The lightweight data storage apparatus applicable to graphic blockchains of claim 19, wherein the combined-transaction constructing module is configured to periodically determine whether the number of the transactions initiated by the account satisfies the first predetermined condition for combination.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
[0032]
DETAILED DESCRIPTION OF THE INVENTION
[0033] The present invention will be further detailed below with reference to accompanying drawings and particular embodiments for further explaining its objectives, technical schemes and advantages. It is to be understood that these embodiments are only illustrative but not limiting. Moreover, the technical features referred to in the embodiments of the present invention may be combined with each other in any manner as long as no conflicts are caused therebetween.
[0034] For ease of understanding, technical terms of the present invention are explained as follows.
[0035] A DAG, or a directed acyclic graph is mathematically defined as a directed finite graph that does not have any directed loop. It is composed of a finite number of apexes and directed edges. Every directed edge is pointed at an apex from another apex. A travel started from any apex through these directed edges will never go back to the departure apex. In the field of computer science, a directed acyclic graph is a data structure, or a way how data are organized.
[0036] A graphic blockchain mainly refers to a DAG-based blockchain, also known as a DAG ledger. It uses a DAG data structure to organize and store ledger data. Every apex in a DAG ledger represents a storage unit, which may be a single transaction, or a block composed of multiple transactions happening in a period of time. A normal single-chain blockchain is a special case of a DAG ledger, which means that, in every period of time, the whole system can only generate one block. What is different is, a DAG ledger allows different peers to create storage units at their own paces, as long as every storage unit selects one or more units as its sub-units. A DAG ledger has obvious advantages over the traditional link-type blockchains, mainly in terms of scalability and transaction throughput. By organizing a ledger using the DAG data structure, a peer can process new transactions without having data consistency of all peers. This prevents time waste caused by network latency and data synchronization. Therefore, the number of peers participating in DAG accounting can significantly increase. Additionally, the DAG ledger may be tailed with any amount of new data in a parallel manner, so it naturally has high concurrency to provide excellent transaction throughput. This makes it beat link-type blockchains. A link-type blockchain only allows one-block-sized data to be added, so its transaction throughput is limited and hard to be significantly improved.
[0037] Herein, flexibility, or scalability, means the ability to process an increased number of transactions in a given period of time by means of some technology or protocol. For example, a traditional payment network, like Visa, can process thousands of transactions every second, but most blockchains can only process a few transactions in the same duration.
[0038] A blockchain is maintained by a group of peers having consensus protocols (Proof of Work, Proof of Stake, and Delegated Proof of Stake). Every peer keeps a local copy of the whole blockchain. Thus, every peer can access the historical information, search the transactions and calculate the balance. However, as the amount of data contained in a blockchain increase, the required storage space also increases. For example, some complete digital credential block is composed of a block header and a block body, wherein the block header takes up 80 bytes and contains the basic information about the block, such as the version, the block header Hash value of the previous block, the Merkle root Hash, the timestamp, the target value, and a random number. The block body contains transaction data. The transaction data contained in the block body are used to construct a Merkle tree, whose root is stored in the block head. Every transaction is signed by its sender using a digital signature, so as to ensure that the transaction cannot be counterfeited. A transaction includes several transaction inputs and several transaction outputs. Every input in a transaction corresponds to the output of some prior transaction, and is expressed as a Hash pointer, which takes up 32 bytes, and called the previous tx hash. Since every transaction has at least one input, and the size of the Hash field is usually greater than any other field (such as requiring 32 bytes for the Hash field, and 8 bytes or 4 bytes for the random number), the Hash pointers occupy a large space in a block.
[0039] In order to reduce data storage overheads of a graphic blockchain system, the present invention provides a lightweight data storage method applicable to graphic blockchains. The method at least comprises steps S1 to S10. While the steps of the lightweight data storage method are herein described in a specific sequence, this shall not be construed as that the exact operations have to be performed in the described sequence or performed successively to obtain the expected results. In some cases, multi-tasking or parallel processing may be advantageous. Similarly, the detailed implementation included in the discussion given above shall not be interpreted as limitations to the scope of the present invention or of the claims. Instead, they are only description for some particular embodiments of the discussed invention. In the disclosure, some features separately described with respect to the context of different embodiments may be integrally implemented in a single embodiment. On the contrary, features described with respect to the context of a single embodiment may be alternatively implemented in multiple embodiments or any suitable sub-combination of these embodiments separately.
[0040] At the step S1, for N.sup.th transactions initiated by an account, it is determined whether N is an integer multiple of K. The determination corresponds to the first predetermined condition. As shown in
[0041] At S2, the account constructs a common transaction T.sub.N, and broadcasts the common transaction.
[0042] Preferably, the common transaction T.sub.N includes a parent reference field, two validation reference fields, a sending-party account field, a receiving-party account field, a transfer amount field, a timestamp field, a random number field, and a signature field. Therein, the parent reference field is pointed at the previous transaction Hash sent by the account, and the validation reference field is randomly pointed at two end-point peer transaction Hashes in the network.
[0043] Preferably, in order to ensure the common transactions can be combined in a later stage, the step S2 may further comprises: if a transaction has not been used referred by any other transaction by means of the validation reference field, determining that the transaction is an end-point peer transaction. Generally speaking, end-point peer transactions are some newly generated transactions. In addition, since different accounts have different network views, and a network has a certain latency, it is possible that different accounts refer the same end-point peer transaction at the same time.
[0044] At S3, the N.sup.th transaction that meets the combination cycle, combining the K−1 transactions prior to it. That is, the K−1 transactions: T.sub.N−K+1, T.sub.N−K+2, . . . , T.sub.N−1 initiated by the account previously are acquired and combined into TU.sub.N.
[0045] Preferably, for reducing data storage overheads for the combined transactions, the step S3 may further comprises at least one of S31 to S34.
[0046] At S31, according to the significance of transaction contents, the contents of every transaction can be divided into two types, namely core contents and auxiliary contents. Therein, the core contents include fields related to the transaction, such as the receiving party account, the transfer amount, the timestamp, and the random number. The auxiliary contents include fields of the parent reference and the validation reference. For every transaction of T.sub.N−K+1, T.sub.N−K+2, . . . , T.sub.N−1, T.sub.N, its core contents are preserved in the combined transaction, so as to form a core content site of the combined transaction.
[0047] At S32, the parent reference in the auxiliary contents is such processed that the parent references of the T.sub.N−K+1 transactions and the current account forms a header site of the combined transaction.
[0048] At S33, the validation reference in the auxiliary contents is such processed that the validation references of the T.sub.N−K+1, T.sub.N−K+2, . . . , T.sub.N−1, T.sub.N are combined into a validation site of the combined transaction.
[0049] To multiple combined transactions published by the same account, data in the content sites and different combined transactions are likely to be duplicate. At S34, the data in the core content site of the combined transaction are uniformly stored in a common content site (CCS), and for every combined transaction, pointers pointed at different parts of the CCS are generated to indicate the number of the content sites of the combined transaction.
[0050] At S34, the whole combined transaction is signed by tailing the combined transaction with a signature.
[0051] At S4, it is set that i=N−K+1. At this time, i corresponds to the (N−K+1).sup.th transaction T.sub.N−K+1.
[0052] S5 is about determining whether i<N according to the second predetermined condition. If i<N is true, the method turns to the step S6. Otherwise, the method turns to the step S10.
[0053] At S6, the reference count of the i.sup.th transaction is updated. Specifically, if a new transaction refers some prior transaction, 1 is added to the reference count of the referred transaction. Updating the reference count of the i.sup.th transaction is to ensure that the referred object exists. This does not affect the accumulated consensus confirmation algorithm adopted by the graphic blockchain system.
[0054] At S7, it is to determine whether the validation reference of the prior i.sup.th transaction has reached the state of “reference override”, and to further cut the data in the validation site of the combined transaction accordingly. If yes, the method turns to the step S8. If not, the method turns to the step S9.
[0055] Preferably, to any two validation references, if their header peers and tail peers of a reference belong to the same accounts, respectively, this is the case that the validation reference having the later timestamp overrides the validation reference having the earlier timestamp. If all validation references in a transaction are overridden, it is the case that the transaction reaches a state of “reference override”.
[0056] At S8, the i.sup.th transaction is deleted to reduce the storage space occupied by the data.
[0057] At S9, the value of i is increased progressively. The method then turns to the step S5 for processing the next transaction. By increasing the value of i progressively, the K transactions in the current transaction cycle can be traversed. As shown in
[0058] At S10, TU.sub.N is broadcasted. The method ends.
[0059] Preferably, to lower the network transmission overheads for broadcasting a TU, the current user just needs to broadcast the respective fields such as the receiving-party account, the transfer amount, the timestamp, the random number, and the validation reference in the new transaction, as well as the signature field of the new TU. When other users receive the foregoing field information, they can construct the full contents of the TU (combined transaction) based on the existing transaction data.
[0060] The disclosed lightweight data storage apparatus for graphic blockchains at least comprises at least one of the following modules: a common transaction construction module, a combined-transaction constructing module, a reference count updating module, a reference override computing module, a transaction deleting module, a content site compressing module, and a network broadcast module. Preferably, the lightweight data storage apparatus of the present invention may be, for example, a computer, a server, or another device or system using the lightweight data storage apparatus. According to embodiments of the present invention, besides the common transaction construction module, the combined-transaction constructing module, the reference count updating module, the reference override computing module, the transaction deleting module, the content site compressing module, and the network broadcast module, the shard-type storage apparatus may further comprise other components, such as a central processor, a communication unit, a storage unit or an I/O unit. For example, the common transaction construction module, the combined-transaction constructing module, the reference count updating module, the reference override computing module, the transaction deleting module, the content site compressing module, and the network broadcast module are connected with the central processing unit, respectively, and all perform information exchange with it. Alternatively, the common transaction construction module, the combined-transaction constructing module, the reference count updating module, the reference override computing module, the transaction deleting module, the content site compressing module, and the network broadcast module are successively connected with each other to perform information exchange.
[0061] As examples, a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or another programmable logic device, a discrete gate or transistor logic, a discrete hardware component and/or any combination for executing the disclosed functions may be used to realize or implement the various exemplary logic blocks, modules, and circuits as described herein. The general-purpose processor may be a micro-processor. Alternatively, the processor may be any ordinary processor, controller, micro-controller or state machine. The processor may alternatively be realized as a combination of computing equipment, such as a combination of DSP and a micro-processor, a combination of plural micro-processors, a combination of one or plural micro-processors and a DSP kernel, or any other similar structure. As examples, the disclosed embodiment may be described in the context of a machine-executable instruction. The machine-executable instruction may be incorporated in a program module operating in a device on the actual or virtual target processor. Generally speaking, the program module may include a routine, a program, a library, an object, a class, a component, a data structure, etc., and is for executing particular tasks or realizing particular abstract data structures. In individual embodiments, functions of the program module may be merged or divided among the described program modules. The machine-executable instruction used in the program module may be executed locally or in distributed equipment. In the distributed equipment, the program module may be located both locally and in a remote storage medium.
[0062] The common transaction construction module is used when a user initiates a new transaction. The common transaction construction module constructs transaction data when there is no need to combine transactions. Constructing the transaction data includes signing the generated new transaction.
[0063] The combined-transaction constructing module is used to collect the K−1 transactions initiated by the account before. The combined-transaction constructing module combines related fields in the K−1 transactions and in the new transaction. The combined-transaction constructing module generates the content site, the header site, the validation site, and the signature site in the combined transaction.
[0064] A reference count updating module is used to update the reference count with respect to the other peers pointed by the new transaction.
[0065] A reference override computing module is used to compute the override relationship of the validation reference contained in the new transaction. The reference override computing module can mark the overridden validation references.
[0066] The transaction deleting module serves to delete a transaction whose all validation references have all been overridden, thereby reducing data storage overheads in the system.
[0067] The content site compressing module is for uniformly storing the content sites of the different combined transactions of the same account. The data redundancy in the combined transactions are compressed so as to effectively reduce data storage overheads.
[0068] The network broadcast module is used to collect the respective fields such as receiving-party account, the transfer amount, the timestamp, the random number, the validation reference in the new transaction, and the signature field in the new TU. The network broadcast module then uses these fields to construct a TU augmentation, thereby realizing lightweight network broadcast.
[0069] It should be noted that the above-mentioned specific embodiments are exemplary, and those skilled in the art can come up with various solutions inspired by the disclosure of the present invention, and those solutions also fall within the disclosure scope as well as the protection scope of the present invention. It should be understood by those skilled in the art that the description of the present invention and the accompanying drawings are illustrative rather than limiting to the claims. The protection scope of the present invention is defined by the claims and their equivalents. The description of the present invention contains a number of inventive concepts, such as “preferably”, “according to a preferred embodiment” or “optionally” all indicate that the corresponding paragraph discloses an independent idea, and the applicant reserves the right to file a divisional application based on each of the inventive concepts.