System and method for quickly synchronizing block chain

Abstract

Embodiments include a node that receives one or more blocks of a blockchain. The node, including a data storage device, may store in the data storage device a plurality of key sets and data values associated with keys in the plurality of key sets, the data values being data associated with the blockchain. The node may perform a verification process on the one or more blocks. The verification process includes, for each of the one or more tiles, a) identifying a set of keys associated with the tile, b) retrieving data values associated with the identified keys from the data storage, c) storing the retrieved data values in a volatile memory, and d) validating the block using the data values in the volatile memory. The node may then complete the verification of the one or more blocks.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 392,079, filed on July 25, 2022, which is incorporated herein by reference in its entirety for all purposes. Background Art

[0003] The caching algorithm may utilize a cache of information stored on a computer. LRU (Least Recently Used) caching mechanism is widely used as a caching mechanism for loading data from NoSQL databases.

[0004] Current blockchains (such as Ethereum) use an LRU cache mechanism. For example, when the first transaction block of a blockchain is verified by a node, the node needs to first load information about the first block. The node can then use the key-value pairs and the usage count of the key-value pairs in the LRU cache to load the block information.

[0005] This LRU cache mechanism assumes that future data access is unknown. The LRU cache mechanism manages data in RAM by removing the oldest data value in RAM. The LRU cache mechanism works well when mining new blocks for the blockchain because the next data to be loaded is unknown. However, such a cache mechanism is inefficient when validating existing block data. This is because the next data to be loaded for verification is known because the block already exists.

[0006] Embodiments of the present disclosure individually and collectively address this and other problems. Summary of the invention

[0007] One embodiment includes a method, comprising: receiving one or more blocks of a blockchain by a node; storing, by the node, multiple key sets and data values ​​associated with keys in the multiple key sets in a data storage device, the data values ​​being data associated with the blockchain; performing, by the node, a verification process for the one or more blocks, wherein the verification process includes, for each of the one or more blocks: identifying, by the node, the key set associated with the block; retrieving, by the node, the data value associated with the identified key from the data storage device; storing, by the node, the retrieved data value in a volatile memory; and verifying, by the node, the block using the data value in the volatile memory; and completing, by the node, the verification of the one or more blocks.

[0008] Another embodiment relates to a node, comprising: a processor; and a computer-readable medium, the computer-readable medium coupled to the processor, the computer-readable medium comprising code executable by the processor to implement a method, the method comprising: storing a key set and a data value associated with a key in the key set in a data storage device, the data value being data from a block in a blockchain; performing a verification process of the blockchain, wherein the verification process comprises, for one or more blocks in the blockchain: identifying the key set associated with the block; retrieving the data value associated with the identified key from the data storage device; storing the retrieved data value in a volatile memory; and verifying the block using the data value in the volatile memory; and completing the verification of the blockchain.

[0009] Another embodiment is directed to a method comprising: receiving, by a provider computer, a blockchain data request message from a node; generating, by the provider computer, a blockchain data response message, the blockchain data response message comprising a plurality of hint headers, the plurality of hint headers comprising a key set; and providing, by the provider computer, the blockchain data response message to the node, wherein the node verifies a blockchain using the key set in the plurality of hint headers.

[0010] Additional details regarding embodiments of the present disclosure can be found in the detailed description and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 A block diagram of a blockchain caching system according to an embodiment is shown.

[0012] Figure 2 A block diagram of a node assembly according to an embodiment is shown.

[0013] Figure 3 A block diagram of provider computer components is shown according to an embodiment.

[0014] Figure 4 A block diagram showing a display block prompt according to an embodiment is shown.

[0015] Figure 5 A block diagram showing a caching method according to an embodiment is shown.

[0016] Figure 6 A flow chart showing a caching method according to an embodiment is shown.

[0017] Figure 7 A diagram showing a data structure according to an embodiment is shown.

[0018] Figure 8A diagram showing a portion of a block from a blockchain is shown according to an embodiment. DETAILED DESCRIPTION

[0019] Before discussing the embodiments of the present disclosure, some terms may be described in further detail.

[0020] "Interaction" may include interactive behavior or influence. Interaction may include communication, contact, or exchange between parties, devices, and / or entities. Example interactions include transactions between two parties and data exchanges between two devices. In other embodiments, interactions may include payment transactions in which two devices may interact to facilitate payment.

[0021] "Interaction data" may include data related to an interaction and / or data recorded during an interaction. In some embodiments, the interaction data may be transaction data of network data. The transaction data may include multiple data elements having data values.

[0022] "Quantity" can include the amount of something. Quantity can include the total number, size, value, or degree of one or more things.

[0023] "Digital assets" may refer to digital content associated with a value. In some cases, digital assets may also indicate a transfer of value. For example, a digital asset may include data indicating a transfer of monetary value (e.g., legal tender or cryptocurrency). In other embodiments, digital assets may correspond to other non-monetary values, such as access rights data (e.g., the number of authorized uses or time allotments for accessing information) and ownership data (e.g., digital rights data).

[0024] An "asset transfer network" may be a network for providing and / or receiving digital assets. An asset transfer network may include a plurality of nodes. In some embodiments, digital assets transferred in an asset transfer network may be recorded in a ledger of transactions. An example of an asset transfer network may be a blockchain network, where the ledger of transactions may take the form of a blockchain. In some embodiments, an asset transfer network may be a computer network.

[0025] The term "node" may include a connection point. In some embodiments, a node may be a physical electronic device capable of creating, receiving or transmitting data. In other embodiments, a node may be a software module on a computing device that is a connection point in a communication network. In some embodiments, a node may be a computing device within an asset transfer network. A node may place assets, transfer assets, receive assets, verify assets, maintain a ledger of transactions, and / or perform any other suitable function. In some embodiments, a node may be associated with and / or operated by a financial institution computer (e.g., a bank), a payment processor computer, a third-party computer, a user, or any other suitable entity.

[0026] The term "ledger" may include a compilation of data. A ledger may be a database or other comparable file structure that may be configured to store data from all previous digital asset transfers, including the date and time of the transfer, the amount transferred, and the identity information of the transfer participants (e.g., the sender and recipient of the transfer amount). In some embodiments, the ledger may be in the form of an electronic ledger (e.g., a blockchain), wherein the data already stored in the electronic ledger may be immutable. Portions of the ledger (i.e., shards) may be stored at a node. The ledger may be an interactive ledger.

[0027] The ledger may include transaction records that are digitally signed (e.g., with a private key) to protect entries in the ledger from tampering with false data. This prevents duplicate costs and makes transfers immutable and irreversible, thus making the ledger trustworthy.

[0028] A "blockchain" may include a secure data structure. A blockchain may include a series of blocks. Each block in a blockchain may include an electronic record of one or more historical transactions as well as metadata. In some embodiments, blocks in a blockchain may be related by including a reference to a previous block (e.g., a hash output of a previous block). Each new block in a blockchain may be algorithmically determined based on new transactions and previous blocks in the blockchain. As a result, any tampering with the data stored in these previous blocks may be detected. In some embodiments, a blockchain may be fragmented into blockchain fragments stored at a committee. For example, a committee may store a slice of a blockchain, and different committees may store different slices of a blockchain.

[0029] A "key-value pair" may include a data representation in a computing system. A data storage system may use a key-value pair to retrieve and manage associative data arrays. A key-value pair may include two related data elements: a key and a value. A key-value pair may be a general form of mapping the relationship between a key as an array of an index and its value.

[0030] A "key" may include an identifier. A key may be a unique value that may identify another value. More specifically, a key may include the address of a value in a data structure. A key may be a constant that defines a data set, and a value may be a variable that belongs to the set. For example, a data set includes a blockchain data structure. A key may be a constant value, such as an identifier that identifies a location in a blockchain data structure.

[0031] A "value" may include data. In some embodiments, a value may include data from a block in a blockchain. A value may be identified by a unique key. While a key may be a constant defining a data set, a value may be a variable belonging to the set. For example, a data set includes a blockchain data structure. A value may be a value included in the blockchain data structure as identified by a key. A value may be a timestamp, a hash value, a name, an entity identifier, a nonce, a difficulty value, interaction data, and / or any other data that may be included in a blockchain data structure.

[0032] A "hint" may include an indication of something. A hint may include an indication of which values ​​may be used in the verification process. In some embodiments, a hint may be a key that references a value in a blockchain data structure.

[0033] A "hint header" may be a data object containing a hint. A hint header may include a hint set. A hint header may include a block identifier that identifies a block in the blockchain corresponding to the hint header. In some embodiments, a node may retrieve a hint set from a hint header.

[0034] A "processor" may include a device that processes something. In some embodiments, a processor may include any suitable one or more data computing devices. A processor may include one or more microprocessors that work together to achieve the desired functions. A processor may include a CPU that includes at least one high-speed data processor that is sufficient to execute program components for executing user and / or system generated requests. The CPU may be a microprocessor such as Athlon, Duron and / or Opteron from Advanced Micro Devices (AMD); PowerPC from IBM and / or Motorola; Cell processors from IBM and Sony; Celeron, Itanium, Pentium, Xeon and / or XScale from Intel; and / or similar processors.

[0035] "Memory" may be any suitable device or devices that can store electronic data. Suitable memory may include non-transitory computer-readable media that stores instructions that can be executed by a processor to implement the desired method. Examples of memory may include one or more memory chips, disk drives, etc. Such memory may operate using any suitable electrical, optical, and / or magnetic modes of operation.

[0036] A "server computer" may include a powerful computer or cluster of computers. For example, a server computer may be a large mainframe, a cluster of small computers, or a group of servers that function as a unit. In one example, a server computer may be a database server coupled to a Web server. A server computer may include one or more computing devices and may use any of a variety of computing structures, arrangements, and assemblies to service requests from one or more client computers.

[0037] Embodiments of the present disclosure allow for an efficient method of loading data objects into random access memory (RAM) using keys (e.g., hints) during validation of blocks of a blockchain. Embodiments allow a provider computer (e.g., a miner computer, a blockchain snapshot provider computer, etc.) to generate a hint header for a block by generating a key set necessary to process the block. During a synchronization process with the blockchain, a new node can use the hint header containing the key set to efficiently validate the blockchain while reducing the time spent on disk data loading.

[0038] A caching algorithm may be an optimization instruction or an algorithm that may utilize a cache of information stored on a computer. An LRU (Least Recently Used) caching mechanism is widely used as a caching mechanism for loading data from a NoSQL database.

[0039] Blockchains (such as Ethereum) utilize an LRU cache mechanism to verify block data. For example, when the first block of a blockchain is verified by a node, the node needs to first load information about the first block. The node can load the following key-value pairs and their usage counts in the LRU cache, as depicted in Table 1.

[0040] Table 1: First LRU cache display.

[0041] Key value use 0xa1f 0xaaf1.. 1 0x09f 0xff10.. 1 0x998 0xdaf1.. 1

[0042] After verifying the first block, the node can retrieve the data of the second block. The node can load the following key value pair, as depicted in Table 2. The values ​​of "0xaaf1.." and "0xff10.." have each been used again, so the used value increases to two.

[0043] Table 2: Second LRU cache representation.

[0044] Key value use 0xa1f 0xaaf1.. 2 0x09f 0xff10.. 2 0x998 0xdaf1.. 1

[0045] After verifying the second block, the node can retrieve the data for the third block. The node can determine that key 0xdf1a is needed to verify the third block. The node can search for key 0xdf1a in the LRU cache. Since the key for 0xdf1a is not included in the cache depicted in Table 2, the node can find and delete (e.g., remove from the LRU cache) the least recently used entry. The node can then load the key and the value of the key for 0xdf1a from disk into the LRU cache. In order to load the data from disk, the node needs to identify the location where the relevant data is stored and needs to search the data set for the data, which can add latency to the verification process.

[0046] Embodiments of the present invention can improve the speed of the blockchain verification process. Blockchains can store data (such as data for payment transactions), data events, and other types of information. Nodes in a distributed network can be asked to verify that the blockchain is valid and accurate, and / or verify certain data (e.g., payment transactions) as recorded on a valid blockchain. Once the blockchain is verified, other tasks can be performed. For example, once the blockchain has been verified and past transactions are confirmed to be on a valid blockchain, a refund or other type of process can be initiated.

[0047] Embodiments provide a more efficient caching system and method than the LRU caching mechanism used by current blockchain networks. Current blockchain protocols use an LRU caching mechanism that assumes that future data to be accessed is unknown. The LRU mechanism manages data in RAM by removing the oldest data value in RAM. However, in some applications such as blockchain synchronization, all data required to verify a block is known in advance. Embodiments may utilize a hint for each block to prepare objects for processing in RAM. For example, a provider computer (e.g., a block miner, a snapshot provider computer, etc.) may generate a hint by generating a key set (e.g., a data object reference) required to process a block.

[0048] The hint may be a key, which may be an address or indicator of an object in a data set storing blockchain data (e.g., header data, block data, transaction data, etc.). For example, a key of 0xaa may be an address in a data set pointing to where an associated value (e.g., data object) is located in the data set. The associated object may be, for example, a date / time, a transaction amount, a transaction party, a digital signature, etc. For example, a key-value pair may include a key of "0xaa" and a value of "1 / 1 / 2023 11:30AM."

[0049] In some embodiments, the hints may be stored in a data container external to the block (e.g., a hint header). In other embodiments, the hints may be stored in the block itself. Hint generation and utilization are described in further detail below.

[0050] Figure 1 A system 100 according to an embodiment of the present disclosure is shown. The system 100 may be a distributed computer network, and in some embodiments may be characterized as a blockchain network. The system 100 may include a first node 101, a second node 102, an Nth node 103, and a provider computer 104.

[0051] The first node 101 may be in operative communication with the second node 102, the Nth node 103, and the provider computer 104. The second node 102 may be in operative communication with the first node 101, the Nth node 103, and the provider computer 104. The Nth node 103 may be in operative communication with the first node 101, the second node 102, and the provider computer 104. The provider computer 104 may be in operative communication with the first node 101, the second node 102, and the Nth node 103.

[0052] For simplicity of explanation, Figure 1 A specific number of components are shown in the drawings. However, it should be understood that embodiments of the present invention may include more than one of each component. In addition, some embodiments of the present invention may include more than one of each component. Figure 1 All components shown in the drawings may be fewer or more components. For example, there may be any number of nodes in the system 100.

[0053] Figure 1 Messages between devices in the system 100 may be transmitted using a secure communication protocol, such as, but not limited to, File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS); SSL; ISO (e.g., ISO 8583) and / or the like. The communication network may include any one and / or combination of the following: direct interconnection; the Internet; a local area network (LAN); a metropolitan area network (MAN); an operating mission as a node on the Internet (OMNI); a secure custom connection; a wide area network (WAN); a wireless network (e.g., using protocols such as, but not limited to, Wireless Application Protocol (WAP), I-mode and / or the like); and / or the like. The communication network may use any suitable communication protocol to generate one or more secure communication channels. In some cases, the communication channel may include a secure communication channel, which may be established in any known manner, such as by using mutual authentication and session keys, and establishing a secure socket layer (SSL) session.

[0054] Nodes (such as the first node 101, the second node 102, and the Nth node 103) can be nodes in a blockchain network. The nodes can interact and add the interactions to the blockchain. The nodes can store the blockchain and the blockchain data of the blockchain, which can include the data of each previous block in the blockchain. The nodes can verify one or more blocks. The nodes can also create new blocks for the blockchain.

[0055] Provider computer 104 may include a computer that creates a tip in a blockchain network. In some embodiments, provider computer 104 may be a miner computer that creates a new block for a blockchain. Provider computer 104 may be a snapshot provider computer that provides the current blockchain to other computers upon request. Provider computer 104 may be a full node.

[0056] The provider computer 104 may generate a set of hints for each block added to the blockchain. The hint set may include one or more hints. A hint may be a key in a value-key pair data structure. Thus, the provider computer 104 may generate a key set including one or more keys. The provider computer 104 may provide multiple key sets upon request. The provider computer 104 may generate a key set based on which values ​​associated with the key are needed to verify a particular block.

[0057] Figure 2 A block diagram of a node 200 according to an embodiment is shown. The exemplary node 200 may include a processor 204. The processor 204 may be coupled to a memory 202, a network interface 206, and a computer-readable medium 208. The computer-readable medium 208 may include one or more software modules. For example, the computer-readable medium 208 may include a key identification module 208A, a storage module 208B, and a block verification module 208C.

[0058] The memory 202 may be used to store data and code. For example, the memory 202 may store block data. The memory may include a data storage device 202A and a volatile memory 202B. The data storage device 202A may be a non-volatile or semi-volatile memory. The memory 202 may be coupled to the processor 204 internally or externally (e.g., a cloud-based data storage device) and may include any combination of volatile and / or non-volatile memory (e.g., RAM, DRAM, ROM, flash memory, or any other suitable memory device).

[0059] The computer-readable medium 208 may include code executable by the processor 204 for performing a method comprising: storing a key set and a data value associated with a key in the key set in a data storage device, the data value being data from a block in a blockchain; performing a verification process of the blockchain, wherein the verification process includes, for one or more blocks in the blockchain: identifying a key set associated with the block; retrieving a data value associated with the identified key from the data storage device; storing the retrieved data value in a volatile memory; and verifying the block using the data value in the volatile memory; and completing the verification of the blockchain.

[0060] The key identification module 208A may include code or software executable by the processor 204 to identify a key. The key identification module 208A in combination with the processor 204 may receive a plurality of key sets. The plurality of key sets may be stored in the data storage device 202A. Each key set may be included in a hint header in a plurality of hint headers. The hint header may include a block identifier, wherein the block identifier identifies the block to which the hint header corresponds. The key identification module 208A in combination with the processor 204 may identify a key set in a plurality of key sets associated with a current block evaluated by the node 200. The key identification module 208A in combination with the processor 204 may identify a hint header in a plurality of hint headers, wherein the plurality of hint headers include a block identifier corresponding to the current block. For example, the block identifier may identify block number 5. If the current block is block number 5, the key identification module 208A in combination with the processor 204 may identify the key set included in the hint header with the block identifier 5.

[0061] The storage module 208B may include code or software that can be executed by the processor 204 to maintain and utilize memory. The storage module 208B in conjunction with the processor 204 may retrieve data from the data storage device 202A and the volatile memory 202B, and store the data in the data storage device and the volatile memory. The storage module 208B in conjunction with the processor 204 may receive a key identifying a value in a blockchain data structure stored in the data storage device 202A. The storage module 208B in conjunction with the processor 204 may identify the value in the data storage device 202A using the key, and then retrieve the value from the data storage device 202A. The storage module 208B in conjunction with the processor 204 may then store the value in the volatile memory 202B for use by the block verification module 208C.

[0062] The block verification module 208C may include code or software that can be executed by the processor 204 to verify the block. The block verification module 208C in combination with the processor 204 can verify the block of the blockchain. The block verification module 208C in combination with the processor 204 can verify the block in any suitable manner using the blockchain data. For example, the block verification module 208C in combination with the processor 204 can verify the block by verifying the proof of work of the block. As another example, the block verification module 208C in combination with the processor 204 can verify that the hash of the block and its data (e.g., determined by hashing the block data) is equal to a given output value with x leading zeros or other requirements. As another example, the block verification module 208C in combination with the processor 204 can verify that the hash of the previous block is equal to the stored hash value of the previous block.

[0063] The network interface 206 may include an interface that may allow the node 200 to communicate with an external computer. The network interface 206 may enable the node 200 to communicate data to another device (e.g., other nodes, provider computer 104, etc.), and to communicate data from the other device. Some examples of the network interface 206 may include a modem, a physical network interface (such as an Ethernet card or other network interface card (NIC)), a virtual network interface, a communication port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. The wireless protocols enabled by the network interface 206 may include Wi-Fi, Wi-Fi 3, Wi-Fi 4, Wi-Fi 5, Wi-Fi 6, Wi-Fi 7, Wi-Fi 8, Wi-Fi 9, Wi-Fi 10, Wi-Fi 11, Wi-Fi 12, Wi-Fi 13, Wi-Fi 14, Wi-Fi 15, Wi-Fi 16, Wi-Fi 17, Wi-Fi 18, Wi-Fi 19, Wi-Fi 20 TM The data transferred through the network interface 206 may be in the form of signals, which may be electrical signals, electromagnetic signals, optical signals, or any other signals capable of being received by an external communication interface (collectively referred to as "electronic signals" or "electronic messages"). These electronic messages, which may contain data or instructions, may be provided between the network interface 206 and other devices via a communication path or channel. As described above, any suitable communication path or channel may be used, such as wire or cable, optical fiber, telephone line, cellular link, radio frequency (RF) link, WAN or LAN network, the Internet, or any other suitable medium.

[0064] Figure 3 A block diagram of a provider computer 104 according to an embodiment is shown. An exemplary provider computer 104 may include a processor 304. The processor 304 may be coupled to a memory 302, a network interface 306, and a computer-readable medium 308. The computer-readable medium 308 may include one or more modules. For example, the computer-readable medium 308 may include a hint header creation module 308A.

[0065] Memory 302 may be used to store data and code. For example, memory 302 may store block data. Memory 302 may be coupled to processor 304 internally or externally (e.g., a cloud-based data storage device) and may include any combination of volatile and / or non-volatile memory (such as RAM, DRAM, ROM, flash memory, or any other suitable memory device).

[0066] The computer-readable medium 308 may include code executable by the processor 304 for performing a method comprising: receiving, by a provider computer, a blockchain data request message from a node; generating, by the provider computer, a blockchain data response message, the blockchain data response message including a plurality of hint headers, the plurality of hint headers including a key set; and providing, by the provider computer, the blockchain data response message to the node, wherein the node verifies a blockchain using the key set in the plurality of hint headers.

[0067] The hint header creation module 308A may include code or software executable by the processor 304 to create a hint header. The hint header may include a key set corresponding to a value that may be used to verify the block corresponding to the hint header. The hint header creation module 308A is combined with the processor 304. When a value is utilized during block creation or during block verification, the hint header creation module 308A, in combination with the processor 304, may store a key set associated with the utilized value. A key may be an address that identifies a value in a blockchain data structure. The hint header creation module 308A, in combination with the processor 304, may generate a hint header for a block. The hint header may include a key set, and optionally a value set associated with the key set.

[0068] Network interface 306 may be similar to network interface 206 and will not be repeated here.

[0069] Figure 4 A block diagram showing block hints is shown. Each block in blockchain 402 can be associated with a hint set. Each hint set can include one or more hints. Each hint can be the address of a data object required to process the associated block.

[0070] The first block B0 is associated with a first hint set 404. The first hint set 404 includes three hints of 0xaa, 0x1a, and 0x2f. When processing the first block B0, the node can use these three hints to preemptively load data objects referenced by the hints from a data storage device (e.g., disk) into a volatile memory (e.g., RAM). Then, when processing the first block B0, the node can quickly access the relevant data objects (e.g., transactions, dates, times, etc.) stored in the block from the volatile memory.

[0071] The second block B1 is associated with the second hint set 406, which includes 0xbb, 0x2b, and 0x30. For each block of the blockchain, the third block B2 is associated with the third hint set 408, the fourth block B3 is associated with the fourth hint set 410, the fifth block B4 is associated with the fifth hint set 412, the sixth block B5 is associated with the sixth hint set 414, and so on.

[0072] Figure 5 A block diagram showing a caching method according to an embodiment is shown. Figure 5 The method presented in will be described in the context of node 200 verifying blocks in a blockchain network. Node 200 may include a data storage device 502 and a volatile storage device 504 (e.g., RAM).

[0073] Prior to step 1, node 200 may obtain data in a data storage device 502 (e.g., a non-volatile data storage device, such as a disk) from one or more nodes in the blockchain network. Data storage device 502 may include blockchain data representing the current state of the blockchain. Node 200 may attempt to verify a block in the received data stored in data storage device 502. For example, node 200 may verify a block by verifying proof of work for the block. For example, node 200 may verify that a hash of a block and its data is equal to a given output value with x leading zeros or other requirements. As another example, node 200 may verify that a hash of a previous block is equal to a stored hash value of a previous block.

[0074] At step 1, the node 200 may evaluate a first hint set 404 for a first block B0. The node 200 may access data values ​​in the data storage device 502 as indicated by the hints. For example, each hint in the first hint set 404 may be a key indicating an address in a block data structure (as further described in detail in FIG. 1 ). Figure 7 4. The first hint set 404 includes keys (e.g., data addresses) of 0x11, 0xaa, and 0x33. The node 200 may identify the key in the data storage device 502 and access the value stored in association with the key in the data storage device 502. The node 200 may load the value associated with the key into the volatile memory 504.

[0075] For example, node 200 may identify a key of "0x11" in data storage 502 and retrieve a value of "0x11ff..." stored in association with the key. Additionally, node 200 may identify a key of "0xaa" in data storage 502 and retrieve a value of "0xaaff..." stored in association with the key. Node 200 may identify a key of "0x33" in data storage 502 and retrieve a value of "0x33ff...." stored in association with the key. Node 200 may load the values ​​of "0x11ff...", "0xaaff...", and "0x33ff..." from data storage 502 into volatile memory 504. Loading values ​​into volatile memory may be referred to as caching values.

[0076] As illustrative examples, a key (e.g., a data structure address) of 0x11 may be associated with a value of a first transaction amount of $5, a key of 0xaa may be associated with a sender identifier of the first transaction of "Jane123", and a key of 0x33 may be associated with a value of a recipient identifier of the first transaction of "John123".

[0077] After evaluating the first hint set 404 and loading the relevant values ​​into the volatile memory 504, the node 200 can proceed to steps 2A and 2B. Steps 2A and 2B can occur simultaneously or in any order. During step 2A, the node 200 can begin loading the second hint set 406 into RAM. During step 2B, the node 200 can begin verifying the first block B0 with the data loaded into RAM during step 1. The verification of the block can be performed asynchronously with the loading of the data into RAM. Therefore, after loading the data values ​​into the volatile memory 504, as indicated by the first key set of the first block B0, the node 200 can load the data values ​​indicated by the second key set of the second block B1, while verifying the data in the first block B0 using the values ​​in the volatile memory 504.

[0078] For example, at step 2A, the node 200 may evaluate the second hint set 406 for the second block B1. The node 200 may access the data value in the data storage device 502 as indicated by the hint. The second hint set 406 includes keys (e.g., data addresses) of 0xbb, 0x22, and 0xcc. The node 200 may identify the key in the data storage device 502 and access the value stored in association with the key in the data storage device 502. The node 200 may load the value associated with the key into the volatile memory 504.

[0079] For example, node 200 may identify a key of “0xbb” in data storage device 502 and retrieve a value of “0xbbff...” stored in association with the key. Additionally, node 200 may identify a key of “0x22” in data storage device 502 and retrieve a value of “0x22ff...” stored in association with the key. Node 200 may identify a key of “0xcc” in data storage device 502 and retrieve a value of “0xccff....” stored in association with the key. Node 200 may load the values ​​of “0xbbff...”, “0x22ff...” and “0xccff...” from data storage device 502 into volatile memory 504.

[0080] For example, at step 2B, the node 200 may verify the first block B0 using the value loaded into the volatile memory 504. The node 200 may verify the block of the blockchain using any suitable verification process using the value loaded into the volatile memory 504. For example, the node 200 may verify that the hash of the block and its data is equal to a given output value with x leading zeros. The value loaded into the volatile memory 504 may include data that can be used for verification. For example, the value loaded into the volatile memory 504 may include block data (e.g., root hash, previous hash, random number, timestamp, difficulty value, etc.) of the first block B0. The node 200 may calculate the hash of the block using the block data. The node 200 may compare the calculated block hash value with the difficulty value to verify whether the block is created correctly relative to the difficulty value.

[0081] Node 200 may verify any portion of a block using values ​​loaded in volatile memory 504. If node 200 needs to utilize a value that is not loaded into volatile memory 504, node 200 may load the required value from data store 502. This may occur if the hint set does not include all required keys or is otherwise incorrectly created. In the worst case scenario, if the hint set is created completely incorrectly, node 200 may load the required value from data store 502, which is computationally approximately equivalent to the current LRU cache mechanism minus a longer constant load time (e.g., by loading the value indicated by the hint). Since node 200 is required to load the correct value from data store 503, malicious entities cannot generate false hints, which, in addition to causing a smaller constant time delay length, also have a negative impact on the system.

[0082] After step 2A, in which the node 200 loads the values ​​of the second block B1 into the volatile memory 504, the node 200 may continue to load values ​​based on the hints until the volatile memory 504 is full or there are no more values ​​to load. For example, at step 3, the node 200 may begin loading the values ​​indicated by the hints in the third hint set 408 into the volatile memory 504. At step 4, the node 200 may load the values ​​indicated by the hints in the fourth hint set 410 into the volatile memory 504.

[0083] At step 5, after the first block B0 has been verified, the node 200 may begin verifying the second block B1 using the preloaded values ​​in the volatile memory 504 loaded during step 2A. The second block B1 may be verified in any suitable manner using the values ​​in the volatile memory 504. The second block B1 may be verified in a similar manner as the first block B0.

[0084] The node 200 may continue to preemptively load data values ​​into the volatile memory 504 (e.g., RAM) and validate blocks until each block is validated (and the blockchain is validated) or the node 200 otherwise determines that the process should stop (e.g., an incorrect node is found).

[0085] The node 200 may also remove data values ​​from the volatile memory 504 periodically or upon the occurrence of certain events. In some embodiments, the node 200 may remove data values ​​from the volatile memory 504 once the volatile memory 504 has been filled with data. The node 200 may remove the oldest value stored in the volatile memory 504 before the newest value in the volatile memory 504. For example, the node 200 may remove values ​​in the volatile memory 504 based on a first-in-first-out (FIFO) removal process. The point at which the node 200 fills the volatile memory 504 with values ​​(e.g., uses up all available empty space in RAM) may depend on the memory capacity of the volatile memory 504. Thus, the ... Figure 5 Values ​​are removed at different times during the presented method, depending on the volatile memory 504 available to the node 200 .

[0086] In other embodiments, the node 200 may remove the value from the volatile memory 504 after the block associated with the value has been verified. For example, a first set of values ​​as identified by a first hint header of a first block of the blockchain may be stored in the volatile memory 504. Once the node 200 has verified the first block in the blockchain, the node 200 may remove (e.g., delete) the first set of values ​​from the volatile memory 504. The node 200 may remove the set of values ​​corresponding to the block after the corresponding block has been verified. In some embodiments, the node 200 may remove the set of values ​​corresponding to the block after a predetermined (e.g., 2, 3, 5, 10, etc.) number of blocks have been verified. Thus, the node 200 removes the value after the value has been in the volatile memory 504 during the predetermined number of block verifications.

[0087] Figure 6 A flow chart of a caching method according to an embodiment is shown. Figure 6 The method presented in will be described in the context of the node 200 requesting blockchain data from the provider computer 104. The node 200 may continue to analyze the received blockchain data to verify that the received blockchain data is correct and valid.

[0088] Prior to step 602, the node 200 may generate a blockchain data request message. The blockchain data request message may include a request for blockchain data of the current blockchain. The blockchain data request message may include a request for one or more blocks of the blockchain. The node 200 may send the blockchain data request message to the provider computer 104, or may propagate the blockchain data request message to the blockchain network.

[0089] The provider computer 104 may receive a blockchain data request message from the node 200. The provider computer 104 may generate a blockchain data response message including blockchain data. In some embodiments, the blockchain data may include data for each block in the blockchain. In other embodiments, the blockchain data may include data for one or more blocks. The provider computer 104 may also include multiple key sets (e.g., multiple prompt sets). Each key set may include a key corresponding to a value in the blockchain data. Each key set may correspond to a different block of the blockchain. Each key set in the multiple key sets may be included in a prompt header associated with a block of the blockchain (e.g., by a block identifier).

[0090] After generating the blockchain data response message, the provider computer 104 may provide the blockchain data response message to the node 200 .

[0091] At step 602, the node 200 may receive a blockchain data response message containing blockchain data. For example, the node 200 may receive one or more blocks of a blockchain, the one or more blocks being associated with a key value pair indicating data (value) and a location where the data is located in a blockchain data structure. The node 200 may also receive a plurality of key sets, each of which is included in a hint header.

[0092] Node 200 may store the received data in a data storage device of node 200. The data storage device may be a non-volatile memory (e.g., a computer disk). In some embodiments, the data storage device may be a semi-volatile memory. For example, node 200 may store a key set and a data value associated with the key set in the data storage device.

[0093] After receiving the blockchain data, node 200 may begin verifying the blockchain data.

[0094] At step 604, the node 200 may identify a key set in a plurality of key sets corresponding to a current block. The current block may be an initial block verified by the node 200. The current block may be a first block in the blockchain. The key set corresponding to the first block may be a first key set in the plurality of key sets.

[0095] As an example, node 200 may use a block identifier to identify a hint header associated with a block. For example, a first block may have a block identifier of 1. The corresponding hint header may include the block identifier 1. The hint header includes a key set associated with verification of the block.

[0096] After identifying the key set, the node 200 may retrieve data values ​​associated with the keys in the key set from the data storage device at step 606. Each key may be an address that identifies a value (e.g., a data value) in the received blockchain data structure.

[0097] As an illustrative example, a key set may include keys of the following key-value pairs: "K1" - "previousHash", "K2" - "random number", "K3" - "rootHash", "K8" - "hash0", "K9" - "difficultyValue", "K12" - "interaction1Amount", "K13" - "interaction1Sender", and "K14" - "interaction1Receiver".

[0098] After retrieving the data values ​​associated with the keys in the key set from the data storage device, the node 200 may store the data values ​​in a volatile memory (e.g., RAM) at step 608. For example, the previous hash, random number, root hash, hash 0, difficulty value, interaction 1 amount, interaction 1 sender, and interaction 1 receiver values ​​may be stored in the volatile memory.

[0099] At step 610, after storing the data value in volatile memory, node 200 may determine whether there is a next block in the blockchain to be verified. If there is a next block in the blockchain, node 200 may proceed to steps 612A and 612B, which may be performed asynchronously. If there is no next block 610, node 200 may proceed to step 620.

[0100] Steps 612A and 612B may be performed concurrently with each other. However, it should be understood that in some embodiments, node 200 may cache one or more next block data in volatile memory before the current block is verified. Thus, step 612B for future blocks may be performed before step 612A for the current block (e.g., as described in reference to FIG. 1 ). Figure 5 described).

[0101] At step 612A, the node 200 may verify the current block using the data values ​​stored in the volatile memory. The node 200 may verify any data in the current block.

[0102] For example, node 200 may verify hash 0. Hash 0 may be a hash of data of interaction 1 included in the block. Node 200 may hash data related to interaction 1, including interaction 1 amount, interaction 1 sender, and interaction 1 recipient, to form a determined hash value. Node 200 may compare the determined hash value to hash 0. If the determined hash value matches hash 0, node 200 may determine that hash 0 in the block is valid.

[0103] As another example, node 200 may verify that a block was created during a valid proof-of-work process. For example, node 200 may generate a hash of a previous hash, a random number, and a root hash together to obtain a determined hash value. Node 200 may compare the determined hash value to a difficulty value. If the determined hash value satisfies the difficulty value, the block is valid. For example, if the determined hash value is lower than the difficulty value, the block may be deemed valid.

[0104] At step 612B, the node 200 may begin caching the next block data into the volatile memory. Step 612B may include steps 614, 616, and 618.

[0105] At step 614, node 200 may identify a next key set in the plurality of key sets that corresponds to the next block. For example, the next block may be a second block of the blockchain. Node 200 may identify that a second key set in the plurality of key sets corresponds to the second block. Step 614 may be similar to step 604.

[0106] After identifying the key set, at step 616, node 200 may retrieve from the data storage device a next data value associated with a key in the next key set. Step 616 may be similar to step 606.

[0107] At step 618, node 200 may store the data value in volatile memory (e.g., RAM). Step 618 may be similar to step 608. For example, node 200 may store the next data value retrieved in volatile memory.

[0108] In some embodiments, the node 200 may remove the previous value used to verify the previous block from the volatile memory. In other embodiments, once the volatile memory is full, the node 200 may begin removing the values ​​in the volatile memory. The values ​​removed from the volatile memory may be removed based on a first-in, first-out data removal process.

[0109] After node 200 has asynchronously performed steps 612A and 612B, node 200 may proceed to step 610 to determine whether there is a next block to verify.

[0110] At step 620, if there is no next block to verify, the node 200 may verify the current block (eg, the last block) using the data value stored in the volatile memory. Step 620 may be similar to step 612A.

[0111] At step 622, node 200 may complete verification of the blockchain after verifying each block that requires verification.

[0112] After validating the blockchain, the node 200 may perform additional processing. For example, the node 200 may initiate an interaction with another node to start mining a new block, etc. For example, after completing the validation, the node may submit a new interaction to be included in the blockchain. The new interaction may include interaction details such as the amount, the recipient address, and the sender address. The blockchain network may perform a validation and consensus process to determine whether to include the new interaction in a new block.

[0113] Figure 7 A block diagram illustrating a data structure according to an embodiment is shown. Figure 7 The data structure 700 shown in FIG. 7 may be Figure 57. The data structure 700 is an illustrative data structure, and it should be understood that the data structure utilized by an embodiment may differ from the data structure 700.

[0114] Each data object (e.g., an entry in data structure 700) may have a key that identifies the data object. Data structure 700 includes a root with a key of 0x111. The root data object may include block data objects for block 1 and block 2. The root data object may include any suitable number of blocks.

[0115] Each block object may include an interaction data object. For example, a block 1 data object includes an interaction 1 data object. In addition, each interaction data object may include details about the interaction. For example, an interaction 1 data object includes an amount, a sender identifier, and a recipient identifier.

[0116] Figure 8 A block diagram showing a block 802 from a blockchain is shown according to an embodiment. The block 802 may include a block header 804 (which may be hashed into a block hash in some embodiments).

[0117] The block header 804 includes a previous hash (e.g., a hash value of a previous block in the blockchain), a random number 808, and a root hash 810.

[0118] The root hash 810 may be a hash value determined from the interactions included in the block 802. The root hash 810 may be determined based on a first combined hash value Hash01 812 and a second combined hash value Hash23 814. Each combined hash value may be created from two hash values.

[0119] A first combined hash value Hash01 812 may be created by hashing together a first hash value Hash0 816 and a second hash value Hash1 818. Each hash value is created by hashing data from an interaction included in block 802. The first hash value Hash0 816 is created by hashing first interaction data Tx0 820. The second hash value Hash1 818 is created by hashing second interaction data Tx1 822.

[0120] A second combined hash value Hash23 814 may be created by hashing together a third hash value Hash2 824 and a fourth hash value Hash3 826. The third hash value Hash2 824 is created by hashing the third interaction data Tx2 828. The fourth hash value Hash3 826 is created by hashing the fourth interaction data Tx3 830.

[0121] The following table 3 shows the Figure 6 The process is consistent with the sample protocol.

[0122] Table 3: FastSync algorithm.

[0123]

[0124] Embodiments may be used for L1 cache and L2 cache, L2 cache and L3 cache, L3 cache and RAM, RAM and Optane memory, Optane and disk memory, and / or memory between disk and RAID. In addition, embodiments may be used for caching transactions, contract logic, contract status, block headers, etc.

[0125] Embodiments of the present disclosure have several advantages. For example, a new node can utilize hints regardless of its RAM capacity. Since the data needed to verify a block is pulled into RAM before block verification begins, delays in pulling such data from non-volatile storage such as disk are avoided. This can be significant, then there are many blocks and many data values ​​associated with those blocks. In some cases, the pipeline will never stop, and block synchronization and verification will only be limited by computation.

[0126] Furthermore, the hint set does not affect the security of the system. For example, even if the hint set is wrong or maliciously generated, the node using the hint to verify the block will determine that the data preemptively loaded in RAM is wrong data, and will instead determine that the hint is wrong and retrieve the appropriate data from the dataset.

[0127] Although the steps in the above flow charts and process flows are shown or described in a particular order, it should be understood that embodiments of the present invention may include methods with steps in different orders. In addition, steps may be omitted or added and may still be in embodiments of the present invention.

[0128] Any of the software components or functions described in this application can be implemented as software code executed by a processor using any suitable computer language (e.g., Java, C, C++, C#, Objective-C, Swift, or a scripting language such as Perl or Python) using, for example, conventional or object-oriented techniques. The software code can be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission, suitable media including random access memory (RAM), read-only memory (ROM), magnetic media such as a hard drive or floppy disk, or optical media such as a compact disk (CD) or DVD (digital versatile disk), flash memory, etc. The computer-readable medium can be any combination of such storage or transmission devices.

[0129] Such programs can also be encoded and transmitted using carrier signals suitable for transmission by wired, optical and / or wireless networks (including the Internet) that meet various protocols. Therefore, a data signal encoded with such a program can be used to create a computer-readable medium according to an embodiment of the present invention. The computer-readable medium encoded with program code can be packaged together with a compatible device, or provided separately from other devices (for example, downloaded via the Internet). Any such computer-readable medium can reside on or within a single computer product (for example, a hard drive, a CD or an entire computer system), and can be present on or within different computer products in a system or network. A computer system can include a monitor, a printer or other suitable displays for providing any result in the result mentioned herein to the user.

[0130] The above description is illustrative and not restrictive. After reading this disclosure, many changes of the present invention will become apparent to those skilled in the art. Therefore, the scope of the present invention should not be determined with reference to the above description, but should be determined with reference to pending claims and their full scope or equivalent.

[0131] One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the present invention.

[0132] As used herein, the use of "a," "an," or "the" is intended to mean "at least one" unless clearly indicated to the contrary.

Claims

1. A method comprising: Receiving one or more blocks of the blockchain by the node; storing, by the node, a plurality of key sets and data values ​​associated with keys in the plurality of key sets in a data storage device, the data values ​​being data associated with the blockchain; The node performs a verification process on the one or more blocks, wherein the verification process comprises, for each of the one or more blocks: identifying, by the node, a key set associated with the block; retrieving, by the node, from the data storage device, a data value associated with the identified key; storing, by the node, the retrieved data value in a volatile memory; as well as verifying, by the node, the block using the data value in the volatile memory; as well as The verification of the one or more blocks is completed by the node. 2 . The method of claim 1 , wherein the data storage device is a non-volatile memory or a semi-volatile memory.

3. The method of claim 2, wherein the non-volatile memory is a computer disk. The method of claim 1 , wherein the volatile memory is a random access memory.

5. The method of claim 1, wherein the one or more blocks include the key and the data value associated with the blockchain, wherein the method further comprises: The plurality of key sets are received by the node from a provider computer.

6. The method of claim 1 , wherein identifying the key set associated with the block further comprises: A hint header associated with the block is evaluated by the node, wherein the hint header includes the set of keys associated with authentication of the block.

7. The method according to claim 6, further comprising: receiving, by the node from a provider computer, a plurality of hint headers; and The plurality of hint headers are stored, by the node, in the data storage device.

8. The method of claim 1 , wherein the data values ​​in the volatile memory include a previous hash value, a random number, and a root hash, and wherein verifying the block further comprises: The block performs a hash operation on the data in the block to obtain a determined hash value; and It is verified by the node whether the determined hash value matches the hash value included in the next block.

9. The method of claim 1 , wherein the key comprises an address identifying a location of a corresponding data value in a blockchain data structure.

10. The method of claim 1, wherein the block is a current block, and wherein when verifying the current block using the data value in the volatile memory: identifying, by the node, a next key set associated with a next block; retrieving, by the node, from the data storage device, a next data value associated with the identified next key; as well as The next data value retrieved is stored by the node in the volatile memory.

11. The method according to claim 10, further comprising: After retrieving the next data value, the retrieved data value is removed by the node from the volatile memory.

12. The method according to claim 10, further comprising: The retrieved data value is removed, by the node, from the volatile memory, the volatile memory being full, wherein older data values ​​in the volatile memory are removed before newer data values.

13. A node comprising: processor; as well as A computer readable medium coupled to the processor, the computer readable medium comprising code executable by the processor to implement a method comprising: storing a key set and data values ​​associated with keys in the key set in a data storage device, the data values ​​being data from a block in a blockchain; Performing a verification process on the blockchain, wherein the verification process includes, for one or more blocks in the blockchain: identifying a key set associated with the block; retrieving from the data storage device a data value associated with the identified key; storing the retrieved data value in volatile memory; as well as verifying the block using the data value in the volatile memory; as well as The verification of the blockchain is completed.

14. The node of claim 13, wherein the data storage device is a non-volatile or semi-volatile memory, and wherein the volatile memory is a random access memory.

15. The node of claim 13, wherein the method further comprises: receiving a plurality of hint headers from a provider computer; and Storing the plurality of hint headers in the data storage device, wherein identifying the set of keys associated with the block further comprises: A hint header associated with the block is evaluated, wherein the hint header includes the set of keys associated with authentication of the block.

16. The node of claim 13, wherein the key secret comprises an address identifying a location of a corresponding data value in a blockchain data structure.

17. The node of claim 13, wherein the block is a current block, and wherein when verifying the current block using the data value in the volatile memory: Identify the next key set associated with the next block; retrieving from the data storage device a next data value associated with the identified next key; and The next data value retrieved is stored in volatile memory.

18. A method comprising: Receiving, by the provider computer, a blockchain data request message from a node; generating, by the provider computer, a blockchain data response message, the blockchain data response message comprising a plurality of hint headers, the plurality of hint headers comprising a key set; and The blockchain data response message is provided, by the provider computer, to the node, wherein the node verifies a blockchain using the set of keys in the plurality of hint headers.

19. The method of claim 18, wherein each hint header includes a block identifier identifying a block in the blockchain.

20. The method of claim 18, wherein the node: storing the key set in a data storage device; Performing a verification process on the blockchain, wherein the verification process includes, for one or more blocks in the blockchain: identifying a key set associated with a hint header of the plurality of hint headers for the block; retrieving from the data storage device a data value associated with the identified key; storing the retrieved data value in volatile memory; as well as verifying the block using the data value in the volatile memory; as well as The verification of the blockchain is completed.

Images