Blockchain data compression and storage

Abstract

The methods and systems described herein improve blockchain storage operations in various environments. A blockchain compression system can determine that a blockchain compression condition associated with a blockchain having a plurality of first blocks has been satisfied. In response, the system compresses the plurality of first blocks into a first root hash value using a first hash tree and stores the plurality of first blocks in a first database. The blockchain compression system generates a first new epoch genesis block that includes the first root hash value and a first database address of the first database in which the plurality of first blocks are stored. The blockchain compression system stores the blockchain at one or more nodes in a blockchain network. The blockchain includes the first new epoch genesis block and any previous new epoch genesis blocks. In various implementations, this can effectively reduce the storage requirements of the blockchain.

Description

Technical Field

[0001] This disclosure generally relates to blockchain technology, and the hardware and software associated with it. More specifically, this disclosure relates to systems and methods for compressing and storing blockchain data in various environments. Background Technology

[0002] Blockchain can be used for transactions involving Bitcoin, Ethereum, Litecoin, Monero, and / or various other distributed cryptocurrencies. Virtual currency systems can provide unregulated digital money, which can be issued and controlled by distributed software created by the virtual currency's developers, rather than by a central bank or public authority that issues and controls fiat currency. For example, Bitcoin is a decentralized virtual currency that provides peer-to-peer transactions without intermediaries, where these transactions are verified by Bitcoin network nodes and recorded in a public distributed ledger called a blockchain. Over time, as more transactions are verified by network nodes and added as blocks to the blockchain, the storage requirements of the blockchain continuously increase. Therefore, blockchains become storage-intensive and more difficult to maintain. Furthermore, distributing large blockchains across peer-to-peer networks utilizes network resources and increases transmission time compared to relatively smaller blockchains. The applicant recognizes an opportunity to improve the storage management of information on blockchains, particularly larger blockchains that may include a large number of historical transactions. Attached Figure Description

[0003] The accompanying drawings are included to provide a further understanding and are incorporated in and form part of this specification. These drawings illustrate the disclosed embodiments and, together with the description, serve to explain the principles of the disclosed embodiments. In the drawings:

[0004] Figure 1 This diagram illustrates a block diagram of a computational architecture for facilitating one or more blockchain-based transactions according to an embodiment of this disclosure.

[0005] Figure 2 The diagram shows Figure 1 A block diagram of an exemplary blockchain network based on a computer architecture.

[0006] Figure 3 This is a schematic diagram illustrating an exemplary blockchain according to an implementation of this disclosure.

[0007] Figure 4 The figure shows a diagram of an example transaction message.

[0008] Figure 5 An exemplary transaction broadcast on a blockchain network is shown.

[0009] Figure 6This is a flowchart illustrating the steps of an exemplary method for executing blockchain-based transactions.

[0010] Figure 7 This is a flowchart illustrating the steps of an exemplary method for performing blockchain compression.

[0011] Figure 8 It shows that according to Figure 7 An example of blockchain compression performed in the method.

[0012] Figure 9 It shows in Figure 7 The method generated during Figure 8 An example Merkle tree for a blockchain.

[0013] Figure 10 The diagram illustrates the use of in Figure 7 The method generated during Figure 8 An exemplary New Age genesis block of the blockchain.

[0014] Figure 11 The figure shows that it includes Figure 7 The method generated during Figure 10 An exemplary blockchain for the new era genesis block.

[0015] Figure 12 The diagram illustrates an exemplary blockchain comprising multiple New Age genesis blocks, each New Age genesis block representing... Figure 7 It is part of the blockchain generated during the process.

[0016] Figure 13 This is a flowchart illustrating the steps of an exemplary method for accessing data in a blockchain represented by the New Age genesis block.

[0017] Figure 14 The figure illustrates an exemplary system.

[0018] Figure 15 The figure illustrates an exemplary computing device. Detailed Implementation

[0019] According to some implementation methods Figures 1 to 6 and Figures 14 to 15 Certain aspects of blockchain operation will be described. According to some implementation methods, Figures 7 to 13 More specific aspects related to blockchain storage management will be described below.

[0020] In the following description of various embodiments, reference is made to the accompanying drawings, which form part of the various embodiments and illustrate by way of illustration the various embodiments in which the various aspects described herein can be practiced. It should be understood that other embodiments can be utilized, and structural and functional modifications can be made without departing from the scope of the description herein. The various aspects can have other embodiments and can be practiced or performed in a variety of different ways.

[0021] In a broad sense, blockchain refers to a framework that supports the distributed storage, maintenance, and updating of trusted ledgers across a peer-to-peer network. For example, in cryptocurrency applications such as Bitcoin or Ethereum, Ripple, Dash, Litecoin, Dogecoin, Zcash, Tether, Bitcoin Cash, Cardano, Stellar, EOS, NEO, NEM, BitShares, Desay, Augur, Komodo, PIVX, Waves, Slim, Monero, Golem, Stratis, Bytecoin, Ardor, or digital currency exchanges such as Bitcoinbase, Kraken, CEX.IO, Shapeshift, Poloniex, Bitstamp, Coinmama, Bisq, LocalBitcoins, Gemini, and other distributed ledgers, each transaction represents the transfer of cryptocurrency units between entities. For instance, using a digital currency exchange, a user can buy any value of cryptocurrency or exchange any held cryptocurrency for a global currency or other digital currencies. Each transaction can be verified through the distributed ledger, and only verified transactions are added to the ledger. The ledger, along with many aspects of blockchain, can be described as "decentralized" because there is typically no central authority. Therefore, the accuracy and integrity of the ledger cannot be compromised if it resides in a single, central location. To protect the integrity of the ledger, it becomes very difficult to modify the location where all or most of the ledger is stored. This is largely because the individuals associated with the nodes that make up the peer-to-peer network have a vested interest in the accuracy of the ledger.

[0022] While maintaining cryptocurrency transactions in a distributed ledger is perhaps the most widely accepted use of blockchain technology today, ledgers can be used in a wide variety of different fields. In fact, blockchain technology is suitable for any application that can access any type of data and ensure its accuracy. For example, supply chains can be maintained in a blockchain ledger, where the transfer of each component between parties and locations can be recorded for later retrieval. Doing so makes it easier to identify the origin of defective components and the delivery locations of other such defective components. Similarly, food items can be tracked in a similar way from farm to grocery store to buyer.

[0023] Embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0024] It should be understood that the wording and terminology used herein are for descriptive purposes and should not be considered limiting. Rather, the phrases and terms used herein will be given their broadest interpretation and meaning. The use of “including” and “contains” and their variations is intended to cover the items listed thereafter and their equivalents, as well as additional items and their equivalents.

[0025] In blockchain systems, the size of the blockchain can grow rapidly. Computational / storage capacity (i.e., faster processors, larger storage components) may be needed to support blockchain expansion. In some cases, blocks may be compressed before being added to the chain. In others, blocks may be eliminated when they become stale or irrelevant; for example, blocks at the beginning of the blockchain may be eliminated. However, in some cases, the elimination of blocks at the beginning of the blockchain might occur after the blockchain has reached an undesirable size. In still other cases, all data stored in the early blocks of the blockchain may be relevant, and therefore these blocks may never be able to be eliminated.

[0026] This disclosure describes a blockchain compression system that compresses a blockchain by calculating the hash root value of the blockchain's block set when the blockchain meets blockchain compression conditions. The blockchain's block set, or a portion of the blockchain, can be used as data for a Merkle tree. The blockchain portion, including the block on which the Merkle tree's root hash value is based, can be stored in a service provider's database. A service provider can be selected to store the blockchain portion based on whether the service provider meets the storage conditions. Nodes in the blockchain network can generate a NewGenesis block, which includes the database address storing the blockchain portion and the root hash value of these blocks. The NewGenesis block may be assigned to other nodes, and additional blocks can be added to the blockchain on top of it. Any query for information related to the stored portion of the blockchain may result in retrieving the database address and root hash value from the NewGenesis block and calling the database address and root hash value to complete the query. Therefore, the blockchain can be periodically compressed and distributed, and any previously compressed block can be accessed by referencing the root hash value stored in the NewGenesis genesis block and the database address in the NewGenesis genesis block. Thus, the system and method of this disclosure reduce the network costs of transmitting and distributing large blockchains. Furthermore, the blockchain of this disclosure reduces the storage requirements of nodes by distributing compressed versions of the blockchain.

[0027] Computing architecture

[0028] As mentioned above, in a blockchain framework, the distributed ledger is stored, maintained, and updated within a peer-to-peer network. In one example, the distributed ledger maintains numerous blockchain transactions. Figure 1 An exemplary blockchain compression system 100 for facilitating blockchain transactions is illustrated. The blockchain compression system 100 includes a first client device 120, a second client device 125, a first server 150, and an Internet of Things (IoT) device 155 interconnected via a network 140. The first client device 120, the second client device 125, and the first server 150 may be references. Figure 15 The computing device 1505 is described in more detail. The IoT device 155 can include any of a variety of devices, including vehicles, home appliances, embedded electronics, software, sensors, actuators, thermostats, light bulbs, door locks, refrigerators, RFID implants, RFID tags, pacemakers, wearable devices, smart home devices, cameras, trackers, pumps, POS devices, and fixed and mobile communication devices together with connectivity hardware configured to connect and exchange data. Network 140 can be any of a variety of available networks, such as the Internet, and represents a collection of global networks and gateways to support communication between devices connected to network 140. The blockchain compression system 100 may also include one or more distributed or peer-to-peer (P2P) networks, such as a first blockchain network 130a, a second blockchain network 130b, and a third blockchain network 130c (collectively referred to as blockchain network 130). Figure 1 As shown, network 140 may include a first blockchain network 130a and a second blockchain network 130b. A third blockchain network 130c may be referenced below. Figure 2 The described private blockchains are associated, and therefore, the third blockchain network 130c is shown separately from the first blockchain network 130a and the second blockchain network 103b. Each blockchain network 130 may include, as referenced... Figure 2 A more detailed description of multiple interconnected devices (or nodes). As mentioned above, a ledger or blockchain is a distributed database used to maintain a growing list of records that includes any type of information. (See reference...) Figure 3 A blockchain described in more detail can be stored at least on multiple nodes (or devices) of one or more blockchain networks 130.

[0029] In one example, blockchain-based transactions can typically involve the transfer of data or values ​​between entities, such as... Figure 1The system includes a first user 110 on a first client device 120 and a second user 115 on a second client device 125. Server 150 may include one or more applications, such as transaction applications, configured to facilitate transactions between entities by utilizing a blockchain associated with one of the blockchain networks 130. As an example, the first user 110 may request or initiate a transaction with the second user 115 via a user application executed on the first client device 120. The transaction may relate to the transfer of value or data from the first user 110 to the second user 115. The first client device 120 may send a transaction request to server 150. Server 150 may send the requested transaction to one of the blockchain networks 130 for verification and approval, as discussed below.

[0030] Blockchain Network

[0031] Figure 2 An exemplary blockchain network 200 is shown, comprising multiple interconnected nodes or devices 205a to 205h (collectively referred to as nodes 205). Each node in node 205 may include reference... Figure 15 The computing device 1505 is described in more detail. Although Figure 2 A single node 205 is shown, but each node in 205 can include multiple devices (e.g., a pool). Blockchain network 200 can be associated with blockchain 220. Some or all of the nodes in 205 can replicate and maintain the same copy of blockchain 220. For example, Figure 2 The diagram shows that nodes 205b to 205e and 205g to 205h store copies of blockchain 220. Nodes 205b to 205e and 205g to 205h can independently update their respective copies of blockchain 220, as discussed below.

[0032] Blockchain node types

[0033] Blockchain nodes, such as node 205, can be full nodes or lightweight nodes. Full nodes, such as nodes 205b to 205e and 205g to 205h, can act as servers in the blockchain network 200 by storing a copy of the entire blockchain 220 and ensuring the validity of transactions mailed to blockchain 220. Full nodes 205b to 205e and 205g to 205h can publish new blocks on blockchain 220. Lightweight nodes, such as nodes 205a and 205f, may have fewer computing resources than full nodes. For example, IoT devices often act as lightweight nodes. Lightweight nodes can communicate with other nodes 205, provide information to full nodes 205b to 205e and 205g to 205h, and query the status of blocks in blockchain 220 stored by full nodes 205b to 205e and 205g to 205h. However, in this example, as... Figure 2 As shown, lightweight nodes 205a and 205f may not store a copy of blockchain 220, and therefore may not publish new blocks on blockchain 220.

[0034] In various embodiments of this disclosure, blockchain 220 may be a compressed version and may include a current distributed blockchain comprising the latest block and blockchain portions 220(1), 220(2), 220(3), 220(4), 220(5), 220(6), and / or up to 220(n), which may each be stored by one or more full nodes 205b to 205e and 205g to 205h. However, in other embodiments, blockchain portions 220(1) to 220(n) may additionally or alternatively be stored by server 150 and / or server 152. Furthermore, in some embodiments, each of nodes 205a to 205h may be associated with a service provider that owns that node.

[0035] Blockchain network types

[0036] Blockchain network 200 and its associated blockchain 220 can be public (permissionless), federated or consortium-based, or private. If blockchain network 200 is public, any entity can read and write to the associated blockchain 220. However, if blockchain network 200 and its associated blockchain 220 are controlled by a single entity or organization, then blockchain network 200 and its associated blockchain 220 can be federated or consortium-based. Furthermore, participation in transaction verification on blockchain 220 can be restricted to any node in node 205 that has internet access. If access to blockchain network 200 and blockchain 220 is limited to specific authorized entities, such as organizations or groups of individuals, then blockchain network 200 and its associated blockchain 220 can be private (permissioned). Furthermore, read permissions for blockchain 220 can be public or restricted, while write permissions can be limited to the controlling or authorized entity.

[0037] Blockchain

[0038] As discussed above, blockchain 220 can be associated with blockchain network 200. Figure 3 An exemplary blockchain 300 is illustrated. Blockchain 300 may include multiple blocks 305a, 305b, and 305c (collectively referred to as blocks 305). Blockchain 300 includes a first block (not shown), sometimes referred to as the genesis block. Each block in block 305 may include a record of one or more committed and verified transactions. Blocks 305 of blockchain 300 may be chained together and protected cryptographically. In some cases, post-quantum cryptography algorithms that dynamically change over time can be used to mitigate the ability of quantum computing to break current cryptographic schemes. Examples of various types of data fields stored in blockchain blocks are provided below. Copies of blockchain 300 may be stored, for example, as files locally by nodes 205b to 205e and 205g to 205h in the cloud, on a power grid, or in a database.

[0039] Block

[0040] Each block in block 305 may include one or more data fields. The organization of block 305 and its corresponding data fields within blockchain 300 may be implementation-specific. As an example, block 305 may include corresponding headers 320a, 320b, and 320c (collectively referred to as header 320) and block data 375a, 375b, and 375c (collectively referred to as block data 375). Headers 320 may include metadata associated with their respective blocks 305. For example, header 320 may include corresponding block numbers 325a, 325b, and 325c. Figure 3As shown, block number 325a of block 305a is N-1, block number 325b of block 305b is N, and block number 325c of block 305c is N+1. The header 320 of block 305 may include a data field containing the block size (not shown).

[0041] Blocks 305 can be chained together and cryptographically protected. For example, the header 320b of block N (block 305b) includes a data field containing a hash representation of the header 320a of the previous block N-1 (previous block hash 330b). The hash algorithm used to generate the hash representation can be, for example, a secure hash algorithm 256 (SHA-256) that produces a fixed-length output. In this example, the hash algorithm is a one-way hash function, where determining the input of the hash function based on its output is computationally difficult. Additionally, the header 320c of block N+1 (block 305c) includes a data field containing a hash representation of the header 320b of block N (block 305b) (previous block hash 330c).

[0042] The header 320 of block 305 may also include a data field containing a hash representation of the block data, such as block data hashes 370a to 370c. Block data hashes 370a to 370c may be generated, for example, through a Merkle tree and by storing hashes or by using hashes based on all block data. The header 320 of block 305 may include corresponding random numbers 360a, 360b, and 360c. In some implementations, the values ​​of random numbers 360a to 360c are arbitrary strings concatenated with (or appended to) the hash of the block. The header 320 may include other data, such as a difficulty target.

[0043] Block 305 may include corresponding block data 375a, 375b, and 375c (collectively referred to as block data 375). Block data 375 may include records of verified transactions that have also been integrated into blockchain 220 via a consensus model (described below). As discussed above, block data 375 may include various types of data in addition to verified transactions. Block data 375 may include any data, such as text, audio, video, images, or files, which may be digitally represented and electronically stored.

[0044] Blockchain transactions

[0045] In one example, blockchain-based transactions may typically involve the transfer of data or values ​​or interactions between entities, and are described in more detail below. Return to References Figure 1Server 150 may include one or more applications, such as transaction applications, configured to facilitate blockchain transactions between entities. Entities may include users, devices, etc. A first user 110 may request or initiate a transaction with a second user 115 via a user application executed on a first client device 120. The transaction may relate to the transfer of value or data from the first user 110 to the second user 115. The value or data may represent money, contracts, property, records, rights, states, supply, demand, alarms, triggers, or any other asset that can be represented digitally. The transaction may represent an interaction between the first user 110 and the second user 115.

[0046] Figure 4 This is a view of transaction 465 generated by the transaction application. Transaction 465 may include public key 415, blockchain address 430 associated with first user 110, digital signature 455, and transaction output information 460. The transaction application can obtain public key 415 from first user 110's private key 405 by applying cryptographic hash function 410 to private key 405. Cryptographic hash function 410 can be based on AES, SHA-2, SHA-3, RSA, ECDSA, ECDH (Elliptic Curve Cryptography), or DSA (Finite Field Cryptography), however, other cryptographic models can be used. More information on cryptographic algorithms can be found in the Federal Information Processing Standards Publication (FIPS PUB 180-3), Secure Hash Standard. The transaction application can obtain the address or identifier of first user 110, such as blockchain address 430, by applying hash function 420 to public key 415. In short, a hash function is a function that can be used to map data of arbitrary size to data of fixed size. This value can also be called a digest, hash value, hash code, or hash. To indicate that the first user 110 is the initiator of transaction 465, the transaction application can use the first user 110's private key 405 to generate a digital signature 455 for transaction data 435. Transaction data 435 may include information about the assets to be transferred and references to the source of the assets, such as previous transactions in which the assets were transferred to the first user 110 or identification of the event that initiated the asset transfer. Generating the digital signature 455 may include applying a hash function 440 to transaction data 435 to produce hashed transaction data 445. The hashed transaction data 445 and transaction data 435 may be encrypted using the first user 110's private key 405 (via encryption function 450) to generate the digital signature 455. Transaction output information 460 may include asset information 470 and the address or identifier of the second user, such as a blockchain address 475. Transaction 465 may be sent from the first client device 120 to the server 150.

[0047] The specific types of cryptographic algorithms being used may change dynamically based on various factors such as time horizon and privacy concerns. For example, the type of cryptographic algorithm being used may change annually, weekly, or daily. The type of algorithm may also change based on varying levels of privacy. For instance, content owners may be able to achieve higher levels of protection or privacy by utilizing more robust algorithms.

[0048] Blockchain address

[0049] Blockchain networks can use blockchain addresses to indicate the start and end points of entities or transactions using the blockchain. For example, the blockchain address of user 110, such as... Figure 4 The blockchain address 430 shown as the sender can include an alphanumeric string of characters obtained by applying a cryptographic hash function 420 to the public key 415 of the first user 110. The method used to obtain the address can vary and may be specific to the implementation of the blockchain network. In some examples, the blockchain address can be converted into a QR code representation, barcode, token, or other visual representation or graphic description so that the address can be optically scanned by mobile devices, wearable devices, sensors, cameras, etc. Besides addresses or QR codes, there are many methods for identifying individuals, objects, etc., represented in the blockchain. For example, individuals can be identified through biometric information (such as fingerprints, retinal scans, voice, facial recognition codes, temperature, heart rate, uniquely personal gestures / movements, etc.) and through other types of identity information (such as account numbers, home addresses, social security numbers, formal names, etc.).

[0050] Broadcast trading

[0051] Server 150 can receive transactions from users on blockchain network 130. Transactions can be submitted to server 150 via desktop applications, smartphone applications, digital wallet applications, web services, or other software applications. Server 150 can send or broadcast transactions to blockchain network 130. Figure 5 An exemplary transaction 502 is shown, broadcast by server 150 to blockchain network 130. Transaction 502 can be broadcast to multiple nodes 205 of blockchain network 130. Typically, once transaction 502 is broadcast or submitted to blockchain network 130, it can be received by one or more nodes 205. Once transaction 502 is received by one or more nodes 205 of blockchain network 130, it can be propagated by the receiving node 205 to other nodes 205 of blockchain network 130.

[0052] Blockchain networks can operate according to a set of rules. Rules can specify the conditions under which nodes can accept transactions, the types of transactions nodes can accept, and the types of compensation nodes receive for accepting and processing transactions. For example, nodes can accept transactions based on transaction history, reputation, computing resources, and relationships with service providers. Rules can specify the conditions for broadcasting transactions to nodes. For example, transactions can be broadcast to one or more specific nodes based on criteria related to a node's geography, history, reputation, market conditions, log / latency, and technology platform. Rules can be dynamically modified or updated (e.g., turned on or off) to address issues such as latency, scalability, and security conditions. Transactions can be broadcast to a subset of nodes as a form of compensation to entities associated with these nodes (e.g., by receiving compensation for adding blocks of one or more transactions to the blockchain).

[0053] Transaction verification – user authentication and transaction data integrity

[0054] Due to issues such as latency, not all full nodes 205 can simultaneously receive the broadcast transaction 502. Furthermore, not all full nodes 205 that receive the broadcast transaction 502 can choose to verify it. Node 205 can choose to verify a specific transaction, for example, based on the transaction fees associated with transaction 502. Transaction 502 may include the sender's blockchain address 505, public key 510, digital signature 515, and transaction output information 520. Node 205 can verify whether transaction 502 is legitimate or conforms to a predefined set of rules. Node 205 can also verify transaction 502 based on establishing user authenticity and transaction data integrity. User authenticity can be established by determining whether the sender indicated by transaction 502 is actually the actual initiator of transaction 502. User authenticity can be proven via cryptography (e.g., asymmetric key cryptography using pairwise keys such as public and private keys). When establishing user authenticity, additional factors such as user reputation, market conditions, history, and transaction speed can be considered. Data integrity of transaction 502 can be established by determining whether the data associated with transaction 502 has been modified in any way. (Return to Reference) Figure 4 When a transaction application creates a transaction 465, it can indicate that the first user 110 is the initiator of the transaction 465 by including a digital signature 455.

[0055] Node 205 can decrypt digital signature 515 using public key 510. The decryption result may include hashed transaction data 540 and transaction data 530. Node 205 can generate hashed transaction data 550 by applying hash function 545 to transaction data 530. Node 205 can perform a comparison 565 between the first hashed transaction data 540 and the second hashed transaction data 550. If the result 570 of comparison 565 indicates a match, the data integrity of transaction 502 can be established, and node 205 can indicate that transaction 502 has been successfully verified. Otherwise, the data of transaction 502 may have been modified in some way, and node 205 can indicate that transaction 502 has not been successfully verified.

[0056] Each full node 205 can build its own block and add verified transactions to that block. Therefore, blocks from different full nodes 205 can include different verified transactions. As an example, full node 205a can create a first block containing transactions "A", "B", and "C". Another full node 205b can create a second block containing transactions "C", "D", and "E". Both blocks can contain valid transactions. However, only one block can be added to the blockchain; otherwise, transactions that the two blocks could share (such as transaction "C") might be recorded twice, leading to problems such as double-spending when transactions are executed twice. One potential problem in the above example is that transactions "C", "D", and "E" might be excessively delayed when added to the blockchain. This can be addressed in several different ways discussed below.

[0057] Protection Key

[0058] Software such as digital wallets can be used to manage and protect private keys, public keys, and addresses. Private keys can also be stored and protected using hardware. Digital wallets also enable users to conduct transactions and manage their balances. Digital wallets can be stored or maintained online or offline, and in software or hardware, or both. Without public / private keys, users cannot prove ownership of their assets. Furthermore, anyone with access to a user's public / private keys can access the user's assets. Although assets can be recorded on the blockchain, users may not be able to access them without the private key.

[0059] Tokens

[0060] A token can refer to an entry belonging to a blockchain address within a blockchain. This entry can include information indicating ownership of an asset. Tokens can represent money, contracts, property, records, access rights, states, supply, demand, alarms, triggers, reputation, tickets, or any other asset that can be represented digitally. For example, a token can refer to an entry associated with cryptocurrency used for a specific purpose, or it can represent ownership of a real-world asset such as fiat currency or real estate. A token contract refers to a cryptographic token representing a set of rules encoded in a smart contract. The person possessing the private key corresponding to a blockchain address can access the tokens at that address. Therefore, a blockchain address can represent the identity of the person who owns the tokens. Only the owner of the blockchain address can send the tokens to another person. The owner can access the tokens through the owner's wallet. The token owner can send or transfer the tokens to users via blockchain transactions. For example, the owner can sign a transaction corresponding to a token transfer using their private key. When a user receives the tokens, the tokens can be recorded in the blockchain at the user's blockchain address.

[0061] Establish user identity

[0062] While digital signatures can provide a link between a transaction and the owner of the transferred assets, they may not provide a link to the owner's true identity. In some cases, it may be necessary to establish the true identity of the owner of the public key corresponding to the digital signature. For example, the true identity of the public key owner can be verified based on biometric data, passwords, personal information, etc. Biometric data can include any physically identifying information, such as fingerprints, facial and eye images, voice samples, DNA, body movement, gestures, gait, facial expressions, heart rate characteristics, temperature, etc.

[0063] Publish and verify blocks

[0064] As discussed above, full nodes 205 can each build their own blocks containing different transactions. Nodes can build blocks by adding verified transactions until the blocks reach a specific size that can be specified by the blockchain rules. However, only one block can be added to the blockchain at a time. The blocks to be added to the blockchain and their order can be determined based on a consensus model. In a proof-of-work model, two nodes can compete to add their respective blocks to the blockchain by solving a complex mathematical problem. For example, such a problem could include determining a random number, as discussed above, such that the hash value (using a predefined hashing algorithm) of the block to be added to the blockchain (including the random number) has a value that satisfies a range constraint. If both nodes solve the problem simultaneously, a "fork" may be created. When full node 205 solves the problem, it can publish its block for verification by any validating node of node 205 in the blockchain network 130.

[0065] In a proof-of-work consensus model, for example, a node verifies transactions by running checks or searching the current ledger stored in the blockchain. The node will then create a new block for the blockchain, which will include data on one or more verified transactions (see, for example, ...). Figure 3 (Block 305). In blockchain implementations such as Bitcoin, block size is limited. (Return to reference) Figure 3In this example, block 305 will include the hash 330 of the previous block, representing the hash of the current last block in the blockchain. The block may also include the hash 370 of its own transaction data (e.g., a so-called Merkle hash). Depending on the specific algorithm, all or selected data from the block can be hashed to create a final hash value. In implementations of the Proof-of-Work model, nodes will seek to modify the block's data such that the final hash value is less than a preset value. This is achieved by adding a data value called a random number 360. Because the final hash value cannot be predicted based on its inputs, it is impossible to estimate an appropriate value for the random number 360 that would cause the final hash value to be less than the preset value. Therefore, in this implementation, computationally intensive operations are required at the nodes to determine the appropriate random value through a "brute-force" trial-and-error process. Once a successful random value is determined, the complete block is published to the blockchain network for verification. If verified by a majority of nodes in the blockchain network, the complete block is added to the blockchain at each participating node. When a node's block is not added to the blockchain, the block is discarded, and the node continues building new blocks. Transactions in a discarded block may be returned to the queue and await addition to the next block. When a transaction is discarded or returned to the queue, the assets associated with the discarded transaction are not lost because the asset's record exists on the blockchain. However, when a transaction returns to the queue, it causes a delay in completing the transaction. Reducing transaction completion time can be important. The blockchain rule set, or re-enumeration / compensation for nodes processing returned transactions, can determine how returned transactions should be handled in the future. When a transaction is placed in the pool, it can have a priority, but rules may instruct that a transaction priority must exceed a threshold level. The priority of returned or discarded transactions can be increased. Another way to reduce transaction completion time is to have the system, service provider, transaction participant, or merchant pay additional rewards for nodes processing returned transactions. For example, service providers can identify preferred miner networks based on geographic location or batch discounts. Transaction completion time can be optimized by routing returned transactions to specific preferred nodes. A transaction may be associated with an address that restricts which of the preferred nodes will process the transaction if it is returned because it was included in a discarded block. Values ​​can be associated with transactions to direct them to a preferred miner in a specific geographic location. Furthermore, returned transactions can be processed based on preset rules. For example, rules could instruct a commitment to process a specific number of returned transactions in exchange for additional rewards or compensation.

[0066] Blockchain confirmation

[0067] After a block containing a transaction is added to the blockchain, blockchain confirmations can be generated for that transaction. Blockchain confirmations can be added to the blockchain after the block containing the transaction. For example, when a transaction is broadcast to the blockchain, there will be no blockchain confirmations associated with that transaction. If the transaction fails verification, the block containing the transaction will not be added to the blockchain, and the transaction will continue to have no blockchain confirmations associated with it. However, if the block containing the transaction is verified, each transaction in the block will have a blockchain confirmation associated with it. Therefore, when a block is verified, the transactions in the block will have one blockchain confirmation associated with it. When a block is added to the blockchain, each transaction in the block will have two blockchain confirmations associated with it. As additional verified blocks are added to the blockchain, the number of blockchain confirmations associated with that block will increase. Therefore, the number of blockchain confirmations associated with a transaction can indicate the difficulty of rewriting or reversing a transaction. Higher-value transactions may require a larger number of blockchain confirmations before execution.

[0068] consensus model

[0069] As discussed above, a blockchain network can determine which of the full nodes 205 will publish the next block to the blockchain. In a permissionless blockchain network, nodes 205 can compete to determine which node will publish the next block. Based on a consensus model, node 205 can be selected to publish its block as the next block in the blockchain. For example, the selected or winning node 205 can receive rewards such as transaction fees for, for example, publishing its block. Various consensus models can be used, such as proof-of-work, proof-of-stake, delegated proof-of-stake, circular, proof-of-authority or proof-of-identity, and proof-of-time models.

[0070] In the Proof-of-Work (PoW) model, a node can publish the next block by becoming the first node to solve a computationally intensive mathematical problem (e.g., the mathematical puzzle mentioned above). This solution serves as "proof" that the node expended appropriate effort to publish the block. The solution can be verified by all nodes before the block is accepted. However, the PoW model can be vulnerable to the 51% attack described below. The Proof-of-Stake (PoS) model is generally less computationally intensive than the PoW model. Unlike the PoW model, which is open to any node with the computational resources to solve the mathematical problem, the PoS model is open to any node that owns stake in the system. Stake can be a certain amount of cryptocurrency that a blockchain network node (user) may have invested in the system. The probability of a node publishing the next block can be proportional to its stake. Because this model uses fewer resources, the blockchain may forgo rewards as an incentive to publish the next block. The circular model is commonly used by permissioned blockchain networks. Using this model, nodes can take turns publishing new blocks. In the Proof-of-Ever model, each publishing node requests a waiting time from the secure hardware within its computer system. A publishing node may become idle for the duration of the waiting period, and then create a block and publish it to the blockchain network. As an example, in situations requiring speed and / or scalability (e.g., in an enterprise environment), a hybrid blockchain network may switch between fully or partially permissioned and permissionless modes. The network may switch based on various factors such as latency, security, and market conditions.

[0071] Forked

[0072] As discussed above, consensus models can be used to determine the order of events on a blockchain, such as which node can add the next block and which node's transaction is verified first. When conflicts related to the ordering of events exist, the result can be a fork in the blockchain. A fork can lead to two versions of the blockchain existing simultaneously. Consensus methods typically resolve conflicts related to the ordering of events, thus preventing forks from occurring. In some cases, a fork may be unavoidable. For example, using a proof-of-work consensus model, only one node among the competing nodes to solve a puzzle may win by solving its puzzle first. The winning node's block is then verified by the network. If the winning node's block is successfully verified by the network, it will be added to the next block of the blockchain. However, it is possible that two nodes may solve their respective puzzles simultaneously. In this case, both winning nodes' blocks can be broadcast to the network. Since different nodes may receive notifications from different winning nodes, the node that receives notification from the first node as the winning node may add the first node's block to its copy of the blockchain. The node that receives notification from the second node as the winning node may add the second node's block to its copy of the blockchain. This results in two versions of the blockchain, or a fork. This type of fork can be resolved using the longest chain rule of the Proof-of-Work consensus model. According to the longest chain rule, if two versions of the blockchain exist, the chain with the larger number of blocks in the network can be considered the valid blockchain. The other version of the blockchain may be considered invalid and discarded or orphaned. Since blocks created by different nodes may contain different transactions, a fork may result in transactions being included in one version of the blockchain instead of the other. Transactions in blocks on the discarded blockchain may be returned to the queue and await addition to the next block.

[0073] In some cases, forks may stem from changes associated with the blockchain implementation, such as changes to the blockchain protocol and / or software. Due to their impact on a large number of users, forks can be more disruptive to permissionless and globally distributed blockchain networks than to private blockchain networks. Changes or updates to backward-compatible blockchain implementations may result in soft forks. When a soft fork occurs, some nodes may implement the updated blockchain implementation, while others may not. However, nodes that have not updated to the new implementation may continue to transact with nodes that have updated.

[0074] Changes to a non-backward-compatible blockchain implementation can lead to a hard fork. While hard forks are usually intentional, they can also be caused by unintentional software defects / bugs. In this case, all publishing nodes in the network may need to update to the new blockchain implementation. While publishing nodes that haven't updated to the new implementation might continue publishing blocks based on the previous implementation, these nodes might reject blocks created based on the new implementation and continue accepting blocks created based on the previous implementation. Therefore, nodes on different hard-forked versions of the blockchain may be unable to interact with each other. If all nodes move to the new implementation, the previous version may be discarded or obsolete. However, updating all nodes in the network to the new implementation may be impractical or infeasible, for example, if the update disables specialized hardware used by some nodes.

[0075] Blockchain-based applications: Cryptocurrencies

[0076] Cryptocurrencies are a medium of exchange that can be created electronically and stored in a blockchain, such as... Figure 1 The blockchain in blockchain network 130a. Bitcoin is one example of cryptocurrency; however, several other cryptocurrencies exist. Various cryptographic techniques can be used to create units of cryptocurrency and to verify transactions. As an example, a first user 110 may possess 10 units of cryptocurrency. The blockchain in blockchain network 130a may include a record indicating that the first user 110 possesses 10 units of cryptocurrency. The first user 110 may initiate a transfer of 10 units of cryptocurrency to a second user 115 via a wallet application running on a first client device 120. The wallet application may store and manage the first user 110's private key. Examples of wallet devices include personal computers, laptops, smartphones, personal digital assistants (PDAs), etc.

[0077] Figure 6 It is shown that it is used in, for example Figure 1 The flowchart illustrates the steps of an example method 600 for executing a blockchain transaction between entities such as a first user 110 on a first client device 120 and a second user 115 on a second client device 125. The steps of method 600 can be derived from... Figure 1 The steps of method 600 may be performed by any computing device shown. Alternatively or additionally, some or all of the steps of method 600 may be performed by one or more other computing devices. The steps of method 600 may be modified, omitted, and / or performed in a different order, and / or additional steps may be added.

[0078] At step 605, the wallet application can generate transaction data for transferring 10 units of cryptocurrency from first user 110 to second user 115. The wallet application can generate a public key for the transaction using the private key of first user 110. To indicate that first user 110 is the initiator of the transaction, a digital signature for the transaction can also be generated using the private key of first user 110. (See reference...) Figure 4 The transaction data discussed may include information such as the sender's blockchain address 430, digital signature 455, transaction output information 460, and the sender's public key 415. The transaction data can be sent from the first client device 120 to the server 150.

[0079] Server 150 can receive transaction data from first client device 120. At step 610, server 150 can broadcast the transaction to blockchain network 130a. The transaction can be received by one or more nodes 205 of blockchain network 130a. At step 615, upon receiving the transaction, node 205 can select to verify the transaction, for example, based on the transaction fee associated with it. If the transaction is not selected for verification by any node 205, it can be placed in a queue and await selection by node 205.

[0080] At step 620, each of the selected nodes 205 can verify the transaction. Verifying a transaction may include determining whether the transaction is legal or conforms to a predefined set of rules, establishing user authenticity, and establishing transaction data integrity. At step 625, if the transaction is successfully verified by node 205, the verified transaction is added to the block constructed by that node 205. As discussed above, because different nodes 205 can choose to verify different transactions, different nodes 205 can construct or assemble blocks containing different verified transactions. Therefore, the transaction associated with the transfer of 10 units of cryptocurrency from first user 110 to second user 115 can be included in some blocks but not others.

[0081] At step 635, blockchain network 130a may wait for a block to be published. Verified transactions can be added to the block assembled by node 205 until it reaches the minimum size specified by the blockchain. If blockchain network 130a uses a proof-of-work consensus model, nodes 205 can compete for the right to add their respective blocks to the blockchain by solving complex mathematical puzzles. The node 205 that solves its puzzle first wins the right to publish its block. As compensation, the winning node can be rewarded with transaction fees associated with the transaction (e.g., from the wallet of the first user 110). Alternatively or additionally, the winning node can be rewarded with compensation as an amount of cryptocurrency added from the blockchain network to the account associated with the winning node (e.g., a “new” unit of cryptocurrency entering circulation). This latter method of compensation and releasing a new unit of cryptocurrency into circulation is sometimes referred to as “mining.” At step 640, if the block has not yet been published, method 600 returns to step 635 and waits for the block to be published. However, at step 640, if the block has already been published, method 600 proceeds to step 645.

[0082] At step 645, the published block is broadcast to blockchain network 130a for verification. At step 650, if the block is verified by a majority of nodes 205, the verified block is added to blockchain 220. However, if the block is not verified by a majority of nodes 205 at step 650, method 600 proceeds to step 675. At step 675, the block is discarded, and the transactions in the discarded block are returned to a queue. Transactions in the queue can be selected by one or more nodes 205 for the next block. The node 205 that constructed the discarded block can construct the new next block.

[0083] At step 660, if the transaction is added to blockchain 220, server 150 may wait to receive a minimum number of blockchain confirmations for the transaction. At step 665, if the minimum number of confirmations for the transaction has not yet been received, the process may return to step 660. However, if the minimum number of confirmations has been received at step 665, the process proceeds to step 670. At step 670, the transaction can be executed and assets from first user 110 can be transferred to second user 115. For example, after the transaction receives at least three confirmations, 10 units of cryptocurrency owned by first user 110 can be transferred from first user 110's financial account to second user 115's financial account.

[0084] Anonymity and Privacy

[0085] As discussed above, using private / public key pairs to establish user authenticity during blockchain transaction verification offers some privacy because it does not reveal user identity. However, transactions stored on the blockchain may be publicly visible. It has been shown that user identity can derive from publicly available transaction information.

[0086] Blockchain size

[0087] Depending on the frequency of events recorded in the blockchain, its size can grow rapidly. Computational / storage capacity (i.e., faster processors, larger storage components) may be required to support this expansion. In some cases, blocks may be compressed before being added to the chain. In others, blocks may be eliminated when they become stale or irrelevant; for example, blocks at the beginning of the blockchain may be eliminated. As an example, a method of "replacing" the first 1000 transactions with a new block that effectively simulates the hash of 1000 transactions might help manage the blockchain size. However, in some cases, the elimination of blocks at the beginning of the blockchain might occur after the blockchain has reached an undesirable size. In other cases, all data stored in the early blocks of the blockchain may be relevant, and therefore eliminating these blocks may never be practical. The systems and methods disclosed in this disclosure address these problems with blockchain systems.

[0088] Referring now to Figure 7, a method 700 for blockchain compression is illustrated according to various embodiments. In various embodiments, it can be achieved by... Figure 1 The blockchain compression system 100 includes any suitable computer system and / or combination of computer systems to perform operations related to... Figure 7 The operations described. However, for convenience and ease of explanation, the operations described below will be simply about... Figure 2 The discussion will focus on nodes 205b to 205e, 205g, and / or 205h of the blockchain network 200, which can be... Figure 1 Any of the blockchain networks 130a, 130b, and / or 130c. Furthermore, the various operational elements discussed below may be modified, omitted, and / or used in a different manner or order than indicated. Thus, in some implementations, one or more full nodes 205b to 205e, 205g, and / or 205h may perform one or more aspects described below, while another system may perform one or more other aspects.

[0089] Method 700 begins at step 702, where a determination is made regarding whether a blockchain compression condition associated with a blockchain having multiple first blocks has been met. In one embodiment, at step 702, a compression application on one or more nodes 205a to 205h can determine whether a compression condition exists (in various embodiments, a compression condition may indicate that the storage of certain older blocks in the blockchain should be managed according to the techniques described herein). Thus, when blockchain 220 comprises a predetermined number of blocks, one or more nodes 205a to 205h can determine that a compression condition exists. In other embodiments, one or more nodes 205a to 205h can determine that a compression condition exists when blockchain 220 reaches a predetermined size (e.g., 1GB, 10GB, 100GB, or any other blockchain size that would benefit from the teachings of this disclosure). In yet another embodiment, one or more nodes 205a to 205h can determine that a compression condition exists when a predetermined time period (e.g., 1 day, 1 week, 1 month, 6 months, 1 year, or any other duration) has elapsed. In another embodiment, one or more nodes 205a to 205h can determine that a compression condition exists when a predetermined delay time is detected on the blockchain network 200. In yet another embodiment, one or more nodes 205a to 205h can determine that a compression condition exists when a compression notification is received from any of client devices 120 and / or 125 and / or servers 150 and / or 152. While specific examples of compression conditions have been described, those skilled in the art will recognize that other compression conditions may also fall within the scope of this disclosure. Furthermore, a compression condition can be satisfied when one or more of the above-described compression conditions are met.

[0090] If no compression condition exists at step 702, method 700 may continue monitoring the blockchain compression system 100 until a compression condition exists. If a compression condition exists at step 702, method 700 then proceeds to step 704, in various embodiments, where a hash tree is used to compress multiple first blocks of the blockchain into a root hash value. In embodiments, at step 704, compression applications on one or more nodes 205b to 205e, 205g, and / or 205h may compress multiple first blocks in blockchain 220 in response to the blockchain compression condition being met in step 702. For example, nodes 205b to 205e, 205g, and / or 205h may compress their respective blockchain replicas 220. However, in other examples, one of nodes 205b to 205e, 205g, and / or 205h can be selected by nodes 205b to 205e, 205g, and / or 205h to perform the compression operation on blockchain 220. In various implementations, the number of nodes performing the compression operation depends on the compression technique. For example, for interleaved hashing, one node will be responsible for the compression operation and will communicate which node is responsible for which type of compressed block. However, for Merkle hashing, no designated coordinator node is required, so each individual node can perform the compression operation itself.

[0091] refer to Figure 8 and Figure 9 The illustration shows an example of steps 702 and 704. Figure 8 The diagram illustrates blockchain 220, which may include blocks 805, 810, 815, and 820. Block 805 may be the genesis block or the epoch genesis block, as discussed in further detail below. Blocks 810, 815, and 820 may be respectively... Figure 3 Blocks 305a, 305b, and 305c. One or more nodes from 205b to 205e, 205g, and / or 205h can monitor blockchain 220 until the blockchain compression condition is met. In a simplified example, the blockchain compression condition can be met in step 702 when blockchain 220 has four blocks (e.g., blocks 805, 810, 815, and 820) or three blocks after genesis block 805 (e.g., blocks 805, 810, and 815). In various implementations, at least one node from 205b to 205e, 205g, and 205h can generate... Figure 9The root hash value of the Merkle tree 900 (also referred to herein as the hash tree) is a tree structure in which each leaf node 905a, 905b, 905c, and 905d of the Merkle tree 900 is a hash of each data block (e.g., each block 805 to 820 of blockchain 220 could be a corresponding data block). Each non-leaf node 910a and 910b can be a hash of its child nodes, which can be leaf nodes or other non-leaf nodes depending on the size of the Merkle tree 900. This results in a single hash called the Merkle root, which is referred to herein as the root hash value 915. In a specific example, node 205b can generate leaf node 905a by hashing block 805 using one of the hashing algorithms described above. Similarly, node 205b can generate leaf node 905b by hashing block 810, leaf node 905c by hashing block 815, and leaf node 905d by hashing block 820. Node 205b can then generate non-leaf node 910a by hashing leaf nodes 905a and 905b using a hash algorithm. Likewise, node 205b can generate non-leaf node 910b by hashing leaf nodes 905c and 905d. Node 205b can then generate the root hash value 915 (e.g., the root node) by hashing non-leaf nodes 910a and 910b. In the illustrated example, Merkle tree 900 is a binary hash tree because each non-leaf node 910a and 910b, as well as the root node 915, has two child nodes. However, those skilled in the art will recognize that each non-leaf node can be a hash of any number of child nodes. Furthermore, those skilled in the art will recognize that a Merkle tree 900 can have more than one level of non-leaf nodes, depending on the number of leaf nodes.

[0092] Then, method 700 proceeds to step 706, in various embodiments, where in step 706, a database for storing multiple first blocks is determined (e.g., an entity that controls one or more databases may be selected to archive the multiple first blocks). In embodiments, at step 706, compression applications on one or more nodes 205b to 205e, 205g, and / or 205h may determine which nodes 205a to 205h and / or service providers associated with one or more nodes 205a to 205h (e.g., Figure 1The service provider of server 150 or server 152 will store uncompressed copies of a plurality of first blocks of blockchain 220 that have been compressed in response to the satisfaction of compression conditions. In various embodiments of this disclosure, the original data or original blocks 805 to 820 of blockchain 220 may be stored by one or more nodes 205a to 205h and / or by servers 150 and / or 152. The nodes 205a to 205h and / or servers 150 and / or 152 on which blocks 805 to 820 of blockchain 220 are to be stored may be determined according to various mechanisms. For example, blocks 805 to 820 of blockchain 220 may be stored in a circular manner, such that each time a compression condition is satisfied, the compressed blocks of blockchain 220 may be stored by nodes 205a to 205h and / or servers 150 and / or 152 in a predefined order.

[0093] In other examples, the selection of nodes 205a to 205h and / or servers 150 and / or 152 to store blocks 805 to 820 can be based on the transactions stored in those blocks 805 to 820. For example, if a service provider associated with nodes 205a to 205h and / or servers 150 and / or 152 (e.g., via wallet addresses) is identified as the service provider that has performed the most transactions and / or a predetermined threshold of transactions in block data 375a to 375c stored in blocks 805 to 820, then the nodes associated with that service provider, or the server devices of nodes 205a to 205h, or servers 150 and 152, can be selected to store blocks 805 to 820. Accordingly, if a particular block on the blockchain has 100 transactions, 90 of which correspond to PayPal... TM Transactions may then be archived in a database controlled by PayPal. This can provide additional storage savings, as certain institutional entities (such as PayPal) may also need to retain copies of such transactions for other reasons.

[0094] In other implementations, blocks 805 to 820 may be auctioned to the service provider with the highest bid for blocks 805 to 820. The blockchain compression system 100 can incentivize various service providers included in the blockchain compression system 100 and operating one or more blockchain networks 130a to 130c to store and manage blocks 805 to 820. Service providers may wish to store blocks they frequently access or blocks frequently accessed by others, because there may be costs associated with verifying the data stored in these blocks or costs for other entities to access these blocks in other ways, as discussed further below. While one of nodes 205a to 205h, a dedicated database among multiple dedicated storage databases, or one of servers 150 and 152 may store blocks 805 to 820, those skilled in the art with this disclosure will recognize that more than one node among nodes 205a to 205h, more than one dedicated database among multiple dedicated storage databases, and / or more than one server among servers 150 and 152 may store blocks 805 to 820 for redundancy purposes. For example, if an attack or alteration occurs on blocks 805 to 820 or on one of the copies of blocks 805 to 820, redundant copies can be used to recover the stored blocks and correct the alteration. After determining one or more databases in which multiple blocks of the blockchain are stored, method 700 then proceeds to step 708, in which multiple first blocks are stored in the database. In a particular example, the database may use key values ​​having keys that serve as hashes for blocks or transactions for storage.

[0095] Then method 700 proceeds to step 710, where, according to various embodiments, a first epoch genesis block is generated in step 710. This first epoch genesis block includes a first root hash value and a database identifier for a first entity controlling the first database. In embodiments, at step 710 and referring to… Figure 10 The compression application of one or more nodes from nodes 205b to 205e, 205g, and 205h can generate a new epoch genesis block 1000 for blockchain 220. Typically, new epoch genesis block 1000 represents the previous portion of the blockchain (e.g., multiple blocks linked from previous new epoch genesis blocks and compression conditions) as the root hash value of that portion of the blockchain, or the new epoch genesis block can represent a single block of the entire blockchain in which the blockchain is identified as the root hash value. The new epoch genesis block may also include location information for one or more databases storing previous blocks of the blockchain represented by new epoch genesis block 1000.

[0096] For example, NewGenesis Block 1000 may include one or more data fields. NewGenesis Block 1000 may include a header 1020a and block data 1075a. The header 1020 may include metadata associated with NewGenesis Block 1000. For example, header 1020a may include block number 1025a. In some implementations and continuing the example above, blocks 810 to 820 may be... Figure 3 Blocks 305a to 305c. Block number 1025a can be N+2. The header 1020a of block 1000 may include a data field (not shown) containing the block size.

[0097] Blocks 1000 can be chained together and cryptographically protected along with the data blocks they represent. For example, the header 1020a of block 1000 includes a data field containing a hash representation of the header 320c of the previous block N+1 (previous block hash 1030a). The hash algorithm used to generate the hash representation can be, for example, a secure hash algorithm 256 (SHA-256) that produces a fixed-length output. In this example, the hash algorithm is a one-way hash function, where determining the input of the hash function based on its output is computationally difficult.

[0098] The header 1020a of the Newgem genesis block 1000 may also include data fields such as block data hash 1070a, which contains a hash representation of the block data 1075a. Block data hash 1070a may be generated, for example, via a Merkle tree and by storing hashes or by using hashes based on all block data. The header 1020a of block 1000 may include a random number 1060a. In some implementations, the value of random number 1060a is an arbitrary string concatenated with (or appended to) the hash of the block. The header 1020a may include other data, such as a difficulty target.

[0099] The header 1020a of block 1000 may also include data fields such as the root hash value 1080 of the compressed block containing blockchain 220, etc. Figure 8 Blocks 805 to 820 shown Figure 9 The root hash value shown is 915. As discussed above, for example, a root hash value 1080 can be generated based on previous blocks 805 to 820 using a Merkle tree. The header 1020a of block 1000 may include a database address 1090 that identifies the address where blocks 805 to 820 are stored.

[0100] The Genesis Block 1000 of the New Era may include Block Data 1075a. Block Data 1075a may include records of verified transactions that have also been integrated into Blockchain 220 via the consensus model (as described above). As discussed above, Block Data 1075a may include various types of data in addition to verified transactions. Block Data 1075a may include any data, such as text, audio, video, images, or files, which may be digitally represented and electronically stored.

[0101] According to various implementations, method 700 then proceeds to step 712, in which the blockchain, including the first epoch genesis block and any previous epoch genesis blocks, is stored. In implementations, at step 712, one or more nodes from nodes 205b to 205e, 205g, and / or 205h may store a copy of the epoch genesis block 1000. The copy of the epoch genesis block 1000 may be distributed to any node from nodes 205b to 205e, 205g, and / or 205h on the blockchain network 200. For example, if node 205b generates the epoch genesis block 1000, node 205b may distribute the epoch genesis block 1000 to any node from nodes 205a to 205h in the blockchain network 200. Nodes 205a and / or up to 205h that receive the epoch genesis block 1000 may then store the epoch genesis block 1000. Previous distributed copies of blockchain 220, including blocks 805 through 820, can be deleted or removed from various nodes that have copies of that blockchain. This can reduce the storage required for functional copies of the blockchain (especially since copies of many different blockchains may be distributed to thousands or even millions of different devices). Therefore, nodes in blockchain network 200 can store the blockchain (e.g., the NewGenesis genesis block as described herein and / or any previous NewGenesis genesis block) on other nodes in the blockchain network. Thus, NewGenesis genesis block 1000 is distributed to all nodes 205b through 205e, 205g, and / or 205h on blockchain network 200, allowing them to build upon that node. The system will create a fork of the blockchain with the NewGenesis genesis block and build upon it. Once a large number of blocks (e.g., 10 or any other number of blocks) have been built onto the new copy of the blockchain, nodes will begin referencing the blockchain with the new genesis block.

[0102] Then method 700 can proceed to step 714, in which, in various embodiments, the first epoch block is added to the first epoch genesis block. In embodiments, at step 714, the blockchain compression system 100 can perform... Figure 6Method 600, in which the transaction is completed and added to block 220 of the blockchain. Nodes 205b to 205e and / or 205g to 205h can execute this. Figure 6 Step 655 adds the first epoch block to the first epoch genesis block 1000. For example... Figure 11 As shown in the diagram, block 1105 with block number n+3 can be added to the New Age genesis block 1000. Figure 6 Method 600 may repeat the process of adding blocks 1110 with block number n+4, blocks 1115 with block number n+5, blocks 1120 with block number n+6, etc., from nodes 205b to 205e and / or 205g to 205h until another compression condition is detected at step 702 of method 700.

[0103] In various embodiments of method 700, at step 704, the data used to determine the root hash value 915 of the Merkle tree 900 may include the first genesis block or any new epoch genesis block (e.g., new epoch genesis block 1000). Thus, after the creation of the new epoch genesis block 1000, blockchain 220 effectively has only one block distributed among nodes 205b to 205e, 205g, and / or 205h. As discussed below, to access data from any previous block set, the node storing the blockchain portion of blockchain 220 used to generate the root hash value 1080 will be accessed based on the new epoch genesis block 1000. This node will determine, based on the last new epoch genesis block 1000, the nodes among nodes 205b to 205e, 205g, and / or 205h that store previous blockchain portions of blockchain 220, and so on, until the data is found. For example and refer to Figure 2 If blockchain portion 220(n) is the latest compression of blockchain 220 including the epoch genesis block (n) 1000, then the epoch genesis block (n-1) included in blockchain portion 220(n) may include the root hash value 1080 and database address 1090 of blockchain portion 220(6) stored at node 205g. The epoch genesis block (n-2) included in blockchain portion 220(6) stored at node 205g may include the root hash value of blockchain portion 220(5) stored at node 220e and the address of node 220e. The various blockchain portions 220(1) to 220(n) may be linked together via the root hash values ​​of the epoch genesis blocks included in those portions.

[0104] However, in other examples, the data used to determine the root hash value 915 of the Merkle tree 900 may not include the first genesis block or any epoch genesis block (e.g., epoch genesis block 1000 or when block 805 is a genesis block or epoch genesis block), and may only include blocks following the genesis block or epoch genesis block, or portions of those subsequent blocks. The header 1020a in epoch genesis block 1000 may include a hash data field (not shown) of the previous genesis block. Thus, after creating the new epoch genesis block 1000, blockchain 220 provides a compressed blockchain of epoch genesis blocks, where each epoch genesis block has the root hash value of the blocks included in the blockchain portion represented by each epoch genesis block and the database address of the database storing those blocks represented by the epoch genesis block. Reference Figure 12 In the example blockchain 220, after each execution of method 700, new epoch genesis blocks 1205 and 1210 can be added to new epoch genesis block 1000. Thus, blockchain 220 distributed to nodes 205b to 205e, 205g and / or 205h can include new epoch genesis blocks for each blockchain portion 220(1) to 220(n).

[0105] In other implementations, each block following the NewGenesis genesis block 1000 may be compressed or pruned before being used as data to determine the root hash value of subsequent NewGenesis genesis blocks. Data compression or pruning can be performed to further reduce the storage required to store the blocks of blockchain 220 in various databases. Figure 8 and Figure 9 In the example illustrated, one or more blocks 805, 810, 815, and / or 820 can be compressed by a compression application on nodes 205b to 205e, 205g, and / or 205h. In various implementations, incremental encoding can be used to encode block data 375a, 375b, and / or 375c. For example, block data 375a in block 305a can be encoded such that references and differences of block data 375a are stored in block 305a. Furthermore, modification operations can be performed (e.g., changes to the data that result in a change in the length or quantity of the data (e.g., increases or decreases)). Additionally, modification operations can be performed (e.g., changes to the data that do not result in a change in the length or quantity of the data (e.g., increases or decreases)). Other data pruning techniques, such as deleting or moving data, can also be considered.

[0106] In other implementations, data compression techniques can be performed on block data 375a, 375b, and / or 375c. For example, part or all of the block data 375b in block 305b can be compressed using a compression algorithm such as the Lempel-Ziv-Markov Chain Algorithm (LZMA) and optionally hashed using SHA3-512. However, SHA3-512 may be optional since block 305b is hashed. Furthermore, those skilled in the art, possessing this disclosure, will recognize that other compression algorithms can be conceived.

[0107] In various implementations, interleaving techniques for fault tolerance and performance scalability can be used to trim block data 375a, 375b, and / or 375c. For example, an erasure coding mechanism can be used to perform interleaving. Shared segment allocation can also reduce redundancy in storage because of the presence of references / pointers to lookup tables. Erasure coding mechanisms can provide high data availability and remove data redundancy. Pointers to shared segment lookups may only remove data redundancy. While specific compression and trimming techniques for individual blocks of blockchain 220 have been described, those skilled in the art with this disclosure will recognize that other compression and trimming techniques can be conceived and fall within the scope of this disclosure.

[0108] Now for reference Figure 13 The diagram illustrates a method 1300 for accessing data on a blockchain, according to various implementations. In these various implementations, it can be... Figure 1 The blockchain compression system 100 includes any suitable computer system and / or combination of computer systems to perform operations related to... Figure 13 The operations described. However, for convenience and ease of explanation, the operations described below will be simply about... Figure 2 The discussion will focus on nodes 205b to 205e, 205g, and / or 205h of the blockchain network 200, which can be... Figure 1 Any of the blockchain networks 130a, 130b, and / or 130c. Furthermore, the various operational elements discussed below may be modified, omitted, and / or used in a different manner or order than indicated. Thus, in some implementations, one or more nodes 205a to 205h may perform one or more aspects described below, while another system may perform one or more other aspects.

[0109] Method 1300 may begin at step 1302, in which a request to perform a data action on data included in a first block of a plurality of first blocks in the blockchain is received. In embodiments, at step 1302, nodes 205a to 205h may receive a request to perform a data action on data stored in a database managed by one or more nodes 205a to 205h in blockchain portion 220(1) or up to 220(n). In some embodiments, the requested data action may be associated with data not provided in the current distributed version of blockchain 220 (e.g., the current genesis node and subsequent blocks linked to the current genesis node). For example, prior to step 1302, user 110 may query blockchain data to verify transactions via, for example, a blockchain query application executed on a first client device 120. The query may include identification information associated with the transaction (e.g., transaction identifier, public key, keyword, sequence number, and / or any other identification information that is obvious to a person skilled in the art possessing this disclosure). The first client device 120 can provide requests to a query application executed on one or more nodes 205a to 205h via an application programming interface (API).

[0110] Method 1300 can then proceed to step 1304, where a determination is made regarding whether any current epoch genesis block or any subsequent epoch blocks linked to the epoch genesis blockchain include the requested information. In an implementation, at step 1304, a query application executed on, for example, node 205b can search for transactions in the current distributed version of blockchain 220, which includes epoch genesis block 1000 and any subsequent epoch blocks subsequently linked to epoch genesis block 1000, such as, for example... Figure 11 Blocks 1105, 1110, 1115, and / or 1120 are illustrated in the diagram. In an implementation, the query application can use identification information for the requested data / transaction to query blocks 1000, 1105, 1110, 1115, and 1120. If any block contains the requested data, method 1300 can proceed to step 1306, in which the query application performs an action based on the query request. For example, the query application can return the requested data to user 110 via first client device 120. In other examples, the block containing the data can be provided to user 110 via first client device 120. In other examples, various hash levels of the nodes in the hash tree that provide the root hash of the block containing the data can be returned, allowing client device 120 to reconstruct the hash of the block containing the data to verify that the hash of that block matches the hash of the block in blockchain 220.

[0111] If it is determined at step 1304 of method 1300 that the current epoch genesis block or any subsequent epoch block connected to the epoch genesis blockchain does not include the requested data, then method 1300 may proceed to step 1308, in which multiple first blocks are accessed from the database, wherein the multiple first blocks are not set in the current distributed version of the blockchain and are stored in a database associated with the entity. In an implementation, at step 1308, the query application on the node that received the query request from client device 120 may query the root hash value 1080 of the epoch genesis block 1000 and the database address 1090 in which the previous blockchain portion of blockchain 220 is stored. A query application on a node (e.g., node 205b) can use database address 1090 to forward query requests to or generate a node identified in database address 1090 (e.g., node 205h), which stores a previous portion (e.g., blockchain 220(n)) of blockchain 220 used to generate the new epoch genesis block 1000. Query requests can be made between nodes via an API through the query application. A node receiving a query request (e.g., node 205h, which stores blockchain portion 220(n)) can query, via its query application, the blockchain portion 220(n) identified by root hash value 1080, and / or any block data for identification information that may be stored in blockchain portion 220(n) and / or any other blockchain portion at node 205h.

[0112] If the queried data is not in blockchain section 220(n), node 205h can forward the query to a node with the previous blockchain section 220(n-1) or 220(6) as shown in the example. Node 205h can identify the previous blockchain section 220(6) in the header 1020a of the new epoch genesis block 1000 in blockchain section 220(n). For example, the header 1020a of the new epoch genesis block 1000 in blockchain section 220(n) may include the root hash value of blockchain section 220(6) and the database address 1090 of node 205g that stores blockchain section 220(6).

[0113] Upon receiving a query request, node 205g can use its query application to query blockchain section 220(6) identified by the root hash value 1080 in the New Age genesis block 1000, and / or query any block data in blockchain section 220(6) and / or any other blockchain section containing identification information that may be stored at node 205g. If the data in the query request is not located in blockchain section 220(6), node 205g's query application can further query other blockchain sections using the root hash value 1080 and database address 1090 located in the New Age genesis block of blockchain section 220(6). Nodes 220a through 220h can continue searching previous sections of blockchain 220 until identification information is found.

[0114] The above example illustrates when the genesis block or epoch genesis block is included as data for the Merkle tree, which is used to create the root hash value of the block set of blockchain 220. However, if the genesis block and / or epoch genesis block is not provided as data for the Merkle tree, then at step 1308, the following is presented: Figure 12 The example shown links the NewGenesis genesis block to a previous NewGenesis genesis block. A node's query application receiving a query request can query the database address 1090 of the blockchain portion used to generate the root hash value 1080 found in that NewGenesis genesis block, as well as each node identified in the root hash value 1080. For example, node 205a can query the portion of blockchain 220 used to generate the root hash value included in NewGenesis genesis block 1210, targeting nodes identified in NewGenesis genesis block 1205. If that blockchain portion does not include identification information, node 205a can query the nodes identified in NewGenesis genesis block 1205. If the blockchain portion associated with the root hash value identified in NewGenesis block 1205 does not include identification information, node 205a can query the nodes identified in NewGenesis block 1000, and so on, until identification information is found.

[0115] Method 1300 then proceeds to step 1310, in which an action is performed on the data based on the query request. In an implementation, at step 1310, the query application may perform one or more actions based on a data action request included in the query request. For example, a data action may include a query application that returns the requested data to user 110 via first client device 120. In other examples, a data action may include returning the block containing the data to user 110 via first client device 120. In other examples, various hash levels of the nodes in the hash tree that provide the root hash of the block containing the data may be returned, allowing client device 120 to reconstruct the hash of the block containing the data to verify that the hash of that block matches the hash of the block in blockchain 220. In other examples, any one of the non-leaf nodes 910a or 910b and any one of the leaf nodes 905a to 905d can be returned, requiring the reconstruction of the root hash node to verify blockchain portions 220(1) and / or up to 220(n). This allows client device 120 to reconstruct the root hash node of blockchain portions 220(1) and / or up to 220(n) where the data resides, to verify the data whose returned root hash value is represented by the root hash value 1080 in the Epoch Genesis Block 1000. For example, if user 110 has block data in block 805, and user 110 also has the value of leaf node 905b and the value of non-leaf node 910b, then user 110 can reconstruct the root hash value 915. In this way, the node's query application can respond to the data action request from the client device 120 by providing the first block where the identified data is located in the identification information and other hash values ​​required in the Merkle tree 900 to obtain the root hash value, so that the root hash value 915 in the New Age genesis block 1000 can be verified by the user 110 who issued the data action request.

[0116] In various embodiments of method 1300, when a node among nodes 205b to 205e, 205g, and / or 205h receives a query request, locates the data identified in the query request in its database, and performs an action associated with the query request, the node among nodes 205b to 205e, 205g, and / or 205h may receive an escrow fee for storing and providing information about the query / data action request. Payments can be made through various node accounts associated with each node or against each entity associated with a node. In some embodiments, payments can be made using cryptocurrency for blockchain 220, and transactions can be recorded in blockchain 220. However, in other examples, in the absence of any transaction records in blockchain 220, payments can be made via a query application through the transfer of funds between the accounts of one entity or another entity. The escrow fee can be used to incentivize one or more entities or nodes 205a to 205h to escrow various blockchain portions that are compressed by hashing blocks to obtain the root hash value of a Merkle tree representing that blockchain portion.

[0117] Therefore, the systems and methods of this disclosure describe blockchain compression, which can be achieved by calculating the hash root value of the blockchain's block set when the blockchain meets the blockchain compression conditions. A block set or a portion of the blockchain can be used as data for a Merkle tree. The portion of the blockchain including the block on which the root hash value of the Merkle tree is based can be stored in an entity database. Nodes in the blockchain network can generate a NewGenesis block, which includes the database address storing the blocks and the root hash value representing those blocks. The NewGenesis block may be assigned to other nodes, and additional blocks can be added to the blockchain on top of it. Therefore, the blockchain can be periodically compressed and distributed, and any previously compressed block can be accessed by referencing the root hash value and the database address in the NewGenesis block. Thus, the systems and methods of this disclosure reduce the network costs of transmitting and distributing large blockchains. Furthermore, the blockchain of this disclosure reduces the storage requirements of nodes by distributing compressed versions of the blockchain.

[0118] computing devices

[0119] Figure 14System 1400 is illustrated. System 1400 may include at least one client device 1410, at least one database system 1420, and / or at least one server system 1430 communicating via network 1440. It should be understood that the network connections shown are illustrative and any method used to establish a communication link between computers may be used. It is assumed that any of the following network protocols exist: TCP / IP, Ethernet, FTP, HTTP, etc., and various wireless communication technologies exist: GSM, CDMA, WiFi, and LTE, and the various computing devices described herein can be configured to communicate using any of these network protocols or technologies. Any device and system described herein may use, in whole or in part, information regarding… Figure 14 The description refers to one or more computing systems that implement this.

[0120] Client device 1410 may use one or more client applications (not shown) as described herein to access server applications and / or resources. Client device 1410 may be a mobile device, such as a laptop, smartphone, mobile phone, or tablet, or a computing device, such as a desktop computer or server, wearable device, or embedded device. Alternatively, client device 1410 may include other types of devices, such as game consoles, cameras / video recorders, video players (e.g., combining DVD, Blu-ray, red laser, optical, and / or streaming technologies), smart TVs, and other networked devices (where applicable).

[0121] Database system 1420 can be configured to maintain, store, retrieve, and update information from server system 1430. Furthermore, the database system can provide information to server system 1430 periodically or on request. In this respect, database system 1420 can be a distributed database capable of storing, maintaining, and updating large amounts of data across a cluster of nodes. Database system 1420 can provide various types of databases, including, but not limited to, relational databases, hierarchical databases, distributed databases, in-memory databases, flat file databases, XML databases, NoSQL databases, graph databases, and / or combinations thereof.

[0122] Server system 1430 may be configured with server applications (not shown) capable of interfaceing with client applications and database system 1420 as described herein. In this regard, server system 1430 may be a standalone server, a corporate server, or a server located in a server farm or cloud computing environment. According to some examples, server system 1430 may be a virtual server hosted on hardware capable of supporting multiple virtual servers.

[0123] Network 1440 may include any type of network. For example, network 1440 may include a local area network (LAN), a wide area network (WAN), a wireless telecommunications network and / or any other communication network, or a combination thereof. It should be understood that the network connections shown are illustrative and can be established using any means necessary to establish a communication link between computers. It is assumed that any of the following network protocols exist: TCP / IP, Ethernet, FTP, HTTP, etc., and various wireless communication technologies exist: GSM, CDMA, WiFi, and LTE, and the various computing devices described herein can be configured to communicate using any of these network protocols or technologies.

[0124] Data transferred to and from various computing devices in System 1400 may include secure and sensitive data, such as confidential documents, personally identifiable customer information, and account data. Therefore, secure network protocols and encryption may be required to protect the transmission of such data and / or the integrity of the data while it is stored on various computing devices. For example, file-based or service-based integration schemes can be used to transfer data between various computing devices. Various network communication protocols can be used to transfer data. Secure data transfer protocols and / or encryption can be used to protect the integrity of data during file transfers, such as File Transfer Protocol (FTP), Secure File Transfer Protocol (SFTP), and / or Privacy Good Protocol (PGP) encryption. In many implementations, one or more network services can be implemented within various computing devices. Web services can be accessed by authorized external devices and users to support the input, retrieval, and manipulation of data between various computing devices in System 1400. Network services built to support personalized display systems can be cross-domain and / or cross-platform and can be built for enterprise use. Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocols can be used to transfer data to provide secure connections between computing devices. Network services can be implemented using WS security standards, providing secure SOAP messages with XML encryption. Dedicated hardware can be used to provide secure network services. For example, secure network devices may include built-in features such as hardware-accelerated SSL and HTTPS, WS security, and / or firewalls. Such dedicated hardware can be installed and configured in front of one or more computing devices in system 1400, allowing any external device to communicate directly with the dedicated hardware.

[0125] Now go to Figure 15The present invention describes a computing device 1505 that can be used with one or more computing systems. The computing device 1505 may include a processor 1503 for controlling the overall operation of the computing device 1505 and its associated components, including RAM 1506, ROM 1507, input / output devices 15011, communication interfaces 1511, and / or memory 1515. A data bus may interconnect with (one or more) processors 1503, RAM 1506, ROM 1507, memory 1515, I / O devices 1509, and / or communication interfaces 1511. In some embodiments, the computing device 1506 may represent, incorporate, and / or include various devices such as desktop computers, computer servers, mobile devices (such as laptops, tablets, smartphones), any other type of mobile computing device, and / or any other type of data processing device.

[0126] Input / output (I / O) devices 1509 may include a microphone, keypad, touchscreen, and / or stylus movements and gestures, through which users of computing device 1500 can provide input. I / O devices 1509 may also include one or more speakers for providing audio output and video display devices for providing text, audiovisual, and / or graphical output. Software may be stored in memory 1515 to provide instructions to processor 1503, thereby allowing computing device 1500 to perform various actions. For example, memory 1515 may store software used by computing device 1500, such as operating system 1517, application programs 1519, and / or associated internal database 1521. Various hardware memory cells in memory 1515 may include volatile and non-volatile, removable, and non-removable media implemented in any way or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Memory 1515 may include one or more physically persistent memory devices and / or one or more non-persistent memory devices. The memory 1515 may include, but is not limited to, random access memory (RAM) 1506, read-only memory (ROM) 1507, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, optical disc storage devices, magnetic tape cassettes, magnetic tapes, disk storage devices or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by the processor 1503.

[0127] The communication interface 1511 may include one or more transceivers, digital signal processors and / or additional circuitry and software for communicating via any wired or wireless network using any of the protocols described herein.

[0128] Processor 1503 may include a single central processing unit (CPU), which may be a single-core or multi-core processor, or processor 1503 may include multiple CPUs. One or more processors 1503 and associated components may allow computing device 1500 to execute a series of computer-readable instructions to perform some or all of the processes described herein. Although in Figure 15 As not shown, various elements within memory 1515 or other components in computing device 1500 may include one or more caches, such as a CPU cache used by processor 1503, a page cache used by operating system 1517, a disk cache of hard disk drive, and / or a database cache for caching content from database 1521. In embodiments including a CPU cache, the CPU cache may be used by one or more processors 1503 to reduce memory latency and access time. Processors 1503 may retrieve data from or write data to the CPU cache instead of reading / writing to memory 1515, which can improve the speed of these operations. In some examples, a database cache may be created where some data from database 1521 is cached in a separate, smaller database in memory separate from the database (such as in RAM 1506 or on a separate computing device). For example, in a multi-tiered application, a database cache on an application server can reduce data retrieval and manipulation time because communication with a backend database server over a network is not required. These types of caches and other types of caches can be included in various implementations and can provide potential advantages in some implementations of the devices, systems and methods described herein, such as faster response times and less dependence on network conditions when transmitting and receiving data.

[0129] Although various components of the computing device 1505 have been described individually, the functions of the various components may be performed in combination with and / or by a combination of a single component and / or multiple computing devices in communication without departing from the present invention.

[0130] Although the subject matter has been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are described as exemplary implementations of the appended claims.

Claims

1. A blockchain data compression system, the blockchain data compression system comprising: Non-transitory memory; as well as One or more hardware processors are coupled to the non-transitory memory, and the one or more hardware processors are configured to execute instructions from the non-transitory memory to cause the system to perform the following operations: The blockchain compression conditions associated with a blockchain having multiple first blocks are determined, wherein the blockchain compression conditions include at least one of a block count threshold associated with the multiple first blocks, a size threshold associated with the multiple first blocks, or a time threshold since the last compression event. In response to the determination that the blockchain compression conditions have been met, the blockchain is compressed as follows: Based on multiple hash operations performed on the plurality of first blocks using the first hash tree, a first root hash value is generated for the plurality of first blocks; The plurality of first blocks are stored in the first database; Generate a first new epoch genesis block, the first new epoch genesis block including the first root hash value and the first database address storing the plurality of first blocks; and The compressed blockchain is stored at one or more nodes in the blockchain network, wherein the compressed blockchain includes the first epoch genesis block and any previous epoch genesis blocks.

2. The system according to claim 1, wherein, The operation also includes: The first database for storing the plurality of first blocks is selected based on the satisfaction of the database storage conditions.

3. The system according to claim 1, wherein, The operation also includes: Before storing the plurality of first blocks in the first database or when storing the plurality of first blocks in the first database, at least a portion of the data stored in the plurality of first blocks is compressed.

4. The system according to claim 1, wherein, The operation also includes: Generate multiple second blocks that are connected to the first New Era Genesis Blockchain.

5. The system according to claim 4, wherein, The operation also includes: A second root hash value is generated for the plurality of second blocks based on multiple hash operations performed on the plurality of second blocks using a second hash tree; The plurality of second blocks are stored in a second database; Genesis block of the second epoch is generated, comprising the second root hash value and the second database address; and The compressed blockchain, including the second epoch genesis block, is stored.

6. The system according to claim 5, wherein, The operation also includes: Replace the compressed blockchain comprising the first New Age genesis block with the compressed blockchain comprising the second New Age genesis block.

7. The system according to claim 1, wherein, The operation also includes: After storing the plurality of first blocks in the first database, a request is received to verify the data included in the first block among the plurality of first blocks; Access the plurality of first blocks; Generate a hash value associated with the first block and other hash values ​​in the first hash tree used to obtain the first root hash value; and In response to the request, a hash value associated with the first block and other hash values ​​in the first hash tree are provided, such that the first root hash value in the first epoch genesis block can be verified by the entity that issued the request.

8. The system according to claim 1, wherein, The operation also includes: Receive a request to perform a data action on the data, wherein the data action is included in a query request, and the query request includes identification information of the data; The identification information is not determined in the first epoch genesis block of the compressed blockchain or in any subsequent epoch blocks; Access the first root hash value and the first database address of the first database included in the first new epoch genesis block; Using the first hash value, the first database address, and the identification information, a query is performed on the first database used for the plurality of first blocks; and The data action is performed in response to the plurality of first blocks including the identification information.

9. A method for verifying compressed blockchain data, the method comprising: The computing device determines that the blockchain compression conditions associated with a blockchain having a plurality of first blocks have been met, wherein the blockchain compression conditions include at least one of the following: a block count threshold associated with the plurality of first blocks, a size threshold associated with the plurality of first blocks, or a time threshold since the last compression event. In response to determining that the blockchain compression conditions have been met, the computing device compresses the blockchain; After the blockchain is compressed, the computing device receives a request to verify the data included in the first block of the plurality of first blocks of the compressed blockchain, wherein the first block of the plurality of first blocks is not set in the current distributed version of the compressed blockchain, and wherein the first block is stored in a database associated with the computing device. The computing device accesses the plurality of first blocks from the database; When the plurality of first blocks are stored in the database, a first hash value and a second hash value associated with the first blocks are generated based on the plurality of first blocks, wherein the first hash value and the second hash value are used to verify a first root hash value, the first root hash value being stored in a first new epoch genesis block included in the current distributed version of the compressed blockchain; and In response to the request, a first hash value associated with the first block and a second hash value in the first hash tree necessary to obtain the first root hash value are provided, such that the first root hash value in the first epoch genesis block can be verified by the electronic entity that issued the request.

10. The method according to claim 9, further comprising: The computing device generates a second hash value based on the plurality of first blocks in the compressed blockchain stored in the database; The computing device compares the second hash value with the first hash value stored in the first epoch genesis block; When the first hash value matches the second hash value, the computing device notifies the client device that issued the request that the plurality of first blocks and the first epoch genesis block are valid; and When the first hash value does not match the second hash value, the computing device notifies the client device that issued the request that the plurality of first blocks and the first epoch genesis block are not valid.

11. The method according to claim 9, wherein, Compression of the blockchain includes: The computing device generates a first hash value for the plurality of first blocks based on a plurality of hash operations performed on the plurality of first blocks using the first hash tree; and The method further includes: The computing device stores the plurality of first blocks in the database; The computing device generates the first epoch genesis block, which includes the first root hash value and the database address of the database storing the plurality of first blocks; and The computing device stores the compressed blockchain at one or more nodes in the blockchain network, wherein the compressed blockchain includes the first epoch genesis block and any previous epoch genesis blocks.

12. The method according to claim 11, further comprising: The computing device selects a first database for storing the plurality of first blocks based on whether the database storage conditions are met.

13. The method according to claim 11, further comprising: Before storing the plurality of first blocks in the database or while storing the plurality of first blocks in the database, the computing device compresses at least a portion of the data stored in the plurality of first blocks.

14. A method for performing blockchain data actions, the method comprising: A computing device receives a request to perform a data action associated with data stored on a blockchain, wherein the data action includes a query request that includes identification information of the data stored in the blockchain; The identification information is not determined by the computing device in the first epoch genesis block and any subsequent epoch blocks of the blockchain, which is distributed to one or more computing nodes in the blockchain network; The computing device accesses the first epoch genesis block to obtain a first hash value and a first database address of a first database, wherein the first database stores multiple first blocks of the blockchain represented by the first hash value in the first epoch genesis block. The computing device uses the first hash value, the first database address, and the identification information to query the plurality of first blocks in the first database; and The computing device performs the data action in response to the plurality of first blocks including the identification information.

15. The method according to claim 14, further comprising: Before receiving the request, the computing device determines whether the blockchain compression conditions associated with the blockchain having the plurality of first blocks have been met; In response to the blockchain compression condition being met, the computing device compresses the plurality of first blocks into the first hash value using a first hash tree; The computing device stores the plurality of first blocks in the first database; The computing device generates the first epoch genesis block, which includes the first root hash value and the first database address of the first database storing the plurality of first blocks; as well as The blockchain is stored at one or more computing nodes in the blockchain network, wherein the blockchain includes the first epoch genesis block and any previous epoch genesis blocks.

16. The method according to claim 15, further comprising: The computing device selects the first database for storing the plurality of first blocks based on whether the database storage conditions are met.

17. The method of claim 15, further comprising: Before adding a portion of the data to the blockchain, the computing device compresses at least a portion of the data stored in the plurality of first blocks.

18. The method according to claim 14, further comprising: The computing device generates a plurality of second blocks that are connected to the first New Era Genesis Blockchain.

19. The method according to claim 18, further comprising: The computing device determines the blockchain compression conditions that have been met in relation to the blockchain having the plurality of second blocks; In response to the blockchain compression condition being met, the computing device compresses the plurality of second blocks into a second hash value using a second hash tree; The computing device stores the plurality of second blocks in a second database; The computing device generates a second epoch genesis block, which includes a second root hash value and a second database address. as well as The computing device stores the blockchain including the second epoch genesis block.

20. The method according to claim 19, further comprising: The computing device replaces the blockchain containing the first epoch genesis block with a blockchain containing the second epoch genesis block.

Images