A method and system for streaming block templates using cross-referencing.

Abstract

A method and device for compressing transaction identifiers by a first mining node in a blockchain network may include: constructing a first candidate block including a first ordered list of transaction identifiers; receiving data from a second mining node defining a second ordered list of transaction identifiers in a second candidate block to be mined by the second mining node; determining that at least one transaction identifier in the first ordered list is also in the second ordered list; generating an append message including data defining the first ordered list of transaction identifiers, the data specifying at least one transaction identifier in the first ordered list of transaction identifiers by including an index position of the at least one transaction identifier in the second ordered list of transaction identifiers; and transmitting the append message to the second mining node.

Description

Technical Field

[0001]

[0001] This disclosure relates to blockchain networks, and in particular to improving the propagation speed of blocks among miner nodes and / or reducing the bandwidth required to propagate blocks.

Background Art

[0002]

[0002] In a proof-of-work blockchain system, when a miner discovers a valid block, it attempts to quickly communicate its success to all other miners. This involves propagating information about the block to all mining nodes via the blockchain network. In some cases, this may involve sending the complete block data. In some cases, this may involve sending the block header and transaction list information. The receiving miner verifies the new block by hashing the header and confirming that it matches the hash value provided by the successful miner.

[0003]

[0003] As blocks increase in size and number of transactions, block propagation delays can exacerbate the problem of temporary forks and orphan blocks. These situations are costly for miners and for the system as a whole.

[0004]

[0004] Devising methods and systems for reducing the bandwidth consumed by block data and improving the propagation speed would be beneficial when propagating block data.

Brief Description of the Drawings

[0005]

[0005] Refer to the accompanying drawings, which illustrate exemplary embodiments of the present application, by way of example. [Figure 1]

[0006] Figure 1 shows an exemplary block structure of a blockchain network. [Figure 2]

[0007] Figure 2 schematically illustrates an example of a streaming block template network. [Figure 3]

[0008] Figure 3 shows an example configuration of a compressed identifier for a transaction. [Figure 4]

[0009] Figure 4 shows an example of a compressed transaction identifier storage system. [Figure 5]

[0010] Figure 5 shows an example method for generating a compressed transaction identifier in flowchart format. [Figure 6]

[0011] Figure 6 shows an exemplary method in flowchart format for updating the append-only list stored on the first mining node. [Figure 7]

[0012] Figure 7 shows another exemplary method for generating a compressed transaction identifier in flowchart format. [Figure 8]

[0013] Figure 8 shows a simplified exemplary system in block diagram form, including two mining nodes using an IDX reference. [Figure 9]

[0014] Figure 9 shows another simplified exemplary system in block diagram form, including three mining nodes using the EIDX reference. [Figure 10]

[0015] Figure 10 shows an exemplary mining node in block diagram format. [Figure 11]

[0016] Figure 11 shows the construction and distribution of candidate blocks in an exemplary mining node setup. [Figure 12]

[0017] Figure 12 schematically illustrates the parallel processes of candidate block updating and streaming block template communication for mining nodes. [Figure 13]

[0018] Figure 13 shows an exemplary operation of a transaction processor within a mining node in flowchart format. [Figure 14]

[0019] Figure 14 shows a flowchart illustrating one exemplary method of streaming block templates by mining nodes. [Figure 15]

[0020] Figure 15 shows a simplified example of a blockchain node in block diagram format.

[0021] In the figures, similar reference numbers are used to indicate similar elements and features. [Modes for carrying out the invention]

[0006]

[0022] In one embodiment, it is possible to provide a method for a computer to compress transaction identifiers by a first mining node in a blockchain network. The method may include: constructing a first candidate block containing a first ordered list of transaction identifiers; receiving data from a second mining node that defines a second ordered list of transaction identifiers in a second candidate block to be mined by the second mining node; determining that at least one transaction identifier in the first ordered list is also present in the second ordered list; generating an append message containing data that defines a first ordered list of transaction identifiers, wherein the data specifies at least one transaction identifier in the first ordered list of transaction identifiers by including the index position of at least one transaction identifier in the second ordered list of transaction identifiers; and transmitting the append message to the second mining node.

[0007]

[0023] In another implementation, the generation step includes determining that the index location is more compact than the compressed transaction identifier for at least one transaction identifier. In some cases, determining that the index location is more compact includes generating the compressed transaction identifier. In some cases, the first and second mining nodes have defined compressed transaction identifiers of at least two lengths, and the step of generating the compressed transaction identifier includes determining that at least one transaction identifier requires the longer of at least two lengths due to a collision, and based on that determination, determining that the index location is more compact.

[0008]

[0024] In some implementations, the method may further include: receiving data from a third mining node defining a third ordered list of transaction identifiers in a third candidate block actively mined by the third mining node; determining that one of the transaction identifiers in the first ordered list is also in the third ordered list; and specifying one of the transaction identifiers in an append message, including a reference to the third ordered list and the index position of one of the transaction identifiers in the third ordered list of transaction identifiers. In some cases, the specifying step may include first determining that a second mining node has a third ordered list. In some cases, the method may further include receiving data from a second mining node specifying a list stored in the second mining node, wherein the data specifying the list includes a reference to the third ordered list.

[0009]

[0025] In some implementations, the method may further include the steps of: receiving a second append message from a second mining node, the second append message containing data defining another ordered list of transaction identifiers; analyzing the data to obtain another ordered list of transaction identifiers; and storing the other ordered list of transaction identifiers appended to the second ordered list of transaction identifiers. In some cases, the data contains a reference to a transaction identifier in a first ordered list of transaction identifiers. In some cases, the reference contains an index position in the first ordered list, and the analysis contains obtaining the transaction identifier at that index position in the first ordered list.

[0010]

[0026] In some implementations, the method may further include receiving a second append message from a second mining node, where the second append message includes data defining another ordered list of transaction identifiers; analyzing the data to obtain another ordered list of transaction identifiers; and storing another ordered list of transaction identifiers appended to the second ordered list of transaction identifiers, where the data includes references to the transaction identifiers in a third ordered list of transaction identifiers. In some cases, the reference includes a reference to the third ordered list and an index position in the third ordered list, and analyzing includes obtaining the transaction identifier at the index position in the third ordered list. In some cases, the method further includes sending an initial message referencing the third ordered list of transaction identifiers to the second mining node.

[0011]

[0027] In another aspect, it is possible to provide a computing device for compressing transaction identifiers in a blockchain network. The computing device can include: one or more processors; a memory; and processor-executable instructions stored in the memory, where the processor-executable instructions, when executed by the one or more processors, cause the processor to execute one or more of the methods described herein.

[0012]

[0028] In yet another aspect, the present application provides a computer-readable storage medium storing processor-executable instructions for compressing transaction identifiers in a blockchain network, where the processor-executable instructions, when executed by one or more processors, cause the processor to execute one or more of the methods described herein.

[0013]

[0029] Other exemplary embodiments of the present disclosure will be apparent to those skilled in the art upon consideration of the following detailed description in connection with the drawings.

[0014]

[0030] In the present application, the term “and / or” is intended to cover all possible combinations and sub - combinations of the listed elements, including any one of the listed elements alone, any sub - combination, or all of the elements, and not necessarily excluding additional elements.

[0015]

[0031] In the present application, the phrase “at least one of... or...” is intended to cover any one or more of the listed elements, including any one of the listed elements alone, any sub - combination, or all of the elements, not necessarily excluding additional elements, and not necessarily requiring all of the elements.

[0016]

[0032] The present application refers to performing a hash operation or a hash function, which is intended to include any of a number of cryptographic hash functions and, when applied to any set of data or “message”, deterministically generates a unique fixed - length alphanumeric sequence. The result of a hash function may be referred to as a hash value, fingerprint, hash result, or the like. Specific examples include, but are not limited to, SHA - 2, SHA - 3, and BLAKE2. Any reference hereinafter to a miner hashing a block or candidate block is to be understood to mean applying a cryptographic hash function to the header portion of the candidate block. The hash function used may be any suitable hash function unless a specific hash function is specified.

[0017]

[0033] In this specification, the term “blockchain” is understood to include all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction chain technologies, as well as permitted and unauthorized ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have also been proposed and developed. Bitcoin, as exemplified by the Bitcoin SV protocol, may be referred to herein for convenience and illustrative purposes, but it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are also within the scope of the present invention.

[0018]

[0034] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based, decentralized system composed of blocks, each block consisting of a transaction. Each transaction is a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system, and includes at least one input and at least one output. Each block contains the hash of the block preceding it, and together they are chained to create a persistent and immutable record of all transactions that have been written to the blockchain since its inception. Transactions contain small programs known as scripts embedded in their inputs and outputs, and these programs specify who can access the transaction's output and how. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0019]

[0035] Blockchain is implemented on a network of nodes. Each node is a computing device that has network connectivity and runs software that executes the applicable blockchain protocol. Nodes verify transactions and propagate them to other nodes in the network. Special network nodes called "mining nodes" or "miners" attempt to collect unconfirmed transactions, i.e., sets of pending transactions, into a block and "mine" that block. In these examples, mining refers to solving Proof-of-Work (POW) before any other miner in the network succeeds in solving Proof-of-Work for their respective blocks. In the case of Bitcoin, POW involves hashing the block header, including the nonce, until the result falls below a threshold set by a difficulty parameter. The nonce is repeatedly incremented and the hash operation is repeated until the result falls below the threshold, or until one miner receives notification that another miner has succeeded. Variations of the mining process will be well known to those skilled in the art.

[0020]

[0036] A typical block contains two data structures: a block header and a transaction. Figure 1 schematically shows an exemplary block structure 100 from the Bitcoin protocol. Block structure 100 contains a block header 102 and a payload 104. In this example, the block header 102 contains fields for version number 106, previous block hash value 108, Merkle root 110, timestamp 112, target difficulty parameter 114, and nonce 116. The previous block hash value 108 chains this block to the previous block in the chain, thereby creating a "blockchain" structure, which links consecutive blocks to each other by cryptographic hashes. The Merkle root 110 refers to the Merkle tree structure based on all transactions contained in the block. The nonce 116 is an arbitrary value that, during mining, can be repeatedly incremented or decremented by a mining node to change the contents of the block header 102 in order to generate different hash results.

[0021]

[0037] The payload 104 includes a transaction count value 118 and a transaction list 120. In some implementations, the transaction list 120 may be a list of transaction ID numbers.

[0022]

[0038] If a mining node successfully finds a block header that produces a hash result below a threshold, it proceeds to notify other nodes using an updated inventory message containing the successful hash result value. The other nodes then request a copy of the new block and independently verify its validity.

[0023]

[0039] The blockchain ecosystem is maturing to offer improved utility through a significant increase in transaction volume and, consequently, block size. As blocks grow larger, sometimes exceeding 128 MB, it takes time for a successfully mined new block to propagate across the network to other nodes. These propagation delays incur costs. Firstly, miners unaware that a successfully mined block has been created will continue their attempts to mine their own candidate blocks, which will be futile if the new block proves to be valid. Secondly, delays in propagation and verification can lead to an increased possibility of (temporary) forks and orphan blocks.

[0024]

[0040] In many blockchain protocols, it will be understood that miners do not send a complete copy of a block, but instead send the hash result in an inventory message. The receiving mining node, determining that they have not seen the new block claimed, sends a GETBLOCK or GETDATA message to the successful miner. Instead of sending a complete copy of the block, the successful miner sends the block header, the transaction count field from the payload, and an ordered list of the transactions contained in the block. The ordered list may include a set of complete transaction ID numbers (TxIDs) for each transaction. In some embodiments, the TxID may be a fixed-length hash of the transaction. The TxID may be, for example, a 256-bit (32-byte) number obtained by hashing the transaction using SHA-256. The receiving node can reconstruct the complete block by retrieving the identified transactions from the mempool by their TxIDs.

[0025]

[0041] Nevertheless, with the current block size increasing to 128 MB, exceeding the size of the data to be transmitted, this could still become a serious issue if the number of transactions is large. For example, a block containing 500,000 transactions would have an ordered list of TxIDs that is 16 MB.

[0026]

[0042] Therefore, as described in PCT Patent Publications WO2020 / 208590 and WO2020 / 208596, it is proposed that mining nodes provide other miners with information about their respective candidate blocks while hashing them. In this way, each miner uses the time delay between successful block discoveries (approximately 10 minutes in the Bitcoin example) to provide other miners with details about the structure and content of the candidate block they are working on. By providing this information in advance, when a successful block is discovered, the successful miner only needs to send information from the block header and, if applicable, the coinbase transaction, ensuring that all other nodes can assemble and verify a complete new block. This data may be as small as a few hundred bytes. This increases the speed at which successful new blocks propagate throughout the entire network. The contents of PCT Patent Publications WO2020 / 208580 and WO2020 / 208596 are incorporated herein by reference.

[0027]

[0043] The pre-solution propagation of candidate block data between miners is sometimes called streaming block templates (SBTs). Each miner provides other miners with an ordered list of transaction identifiers in the candidate block they are currently working on. In some cases, to save bandwidth, transaction identifiers may be sent as terminated transaction identifiers. PCT Patent Publication WO2020 / 208596 details how to resolve conflicts in the case of terminated transaction identifiers.

[0028]

[0044] For illustrative purposes, Figure 2 illustrates a simplified system 200 for pre-distributing block data in a blockchain system. In this example, system 200 includes four mining nodes 202: miner A 202a, miner B 202b, miner C 202c, and miner D 202d. Mining nodes 202 are nodes within a blockchain network 204 that may contain other nodes (not shown). These other nodes may include full nodes, SPV nodes, mining nodes, or other types of blockchain nodes.

[0029]

[0045] Each mining node 202 may be implemented in a computing device which may include one or more processing units. As will be understood by those skilled in the art, the processing units may include specialized processing units with dedicated hardware designed to perform computational processing related to blockchain mining with remarkable speed and efficiency. However, it may also or alternatively include a general-purpose computing device. The computing device includes processor-executable software which, when executed, causes one or more processing units to perform the operations described. The computing device includes network connectivity and memory with associated hardware and software for obtaining network connectivity and sending and receiving messages in accordance with applicable network protocols.

[0030]

[0046] Each mining node 202 receives and verifies transactions from the blockchain network 204 and constructs candidate blocks for mining. For example, miner D 202d constructs a candidate block 208 containing an ordered set of transactions to be verified, and then attempts to find proof of work with respect to them.

[0031]

[0047] Meanwhile, miner D 202d sends information about the block template, i.e., the ordered list of transactions within its candidate block 208, to the other mining nodes 202. The miner also receives information from each of the other mining nodes 202 about the respective candidate blocks they are mining. Miner D 202d stores this information in an append-only list (AOL) 210 for each of the other mining nodes. For example, miner D 202d constructs an append-only list 210 for miner A 202a based on a message it receives from miner A 202a that specifies the ordered contents of that miner's candidate block. Simultaneously, miner D 202d can construct and maintain a record such as AOL-D, which records the ordered list of transaction information that the miner has sent to other nodes. This could be useful for synchronizing candidate block 208 with AOL-D data if a POW solution is found, as will be further explained below.

[0032]

[0048] Pre-distributing candidate block information so that each mining node 202 has its own ordered list of transactions (AOL) reflecting each candidate block ensures that only a minimal amount of information needs to be propagated after a Proof of Work (PoW) is discovered. This ensures that mining nodes 202 have the information they need to verify the new block as quickly as possible, thereby reducing the time wasted searching for a PoW if another mining node 202 has already succeeded. Mining nodes 202 have every incentive to propagate and verify the new block as quickly as possible so that they can move on to searching for the next block. Potential delays due to network latency are not a major issue if ordered lists of transactions are pre-distributed during the approximately 10-minute interval between consecutive blocks.

[0049] When one of the mining nodes 202 successfully discovers the Proof of Work (PoW) for a candidate block, that node sends a message to the other mining nodes 202, which contains at least some of the block header information required by those other mining nodes 202 to reconstruct the resolved block using the AOL 210 of that mining node. For example, the message may include a nonce and a timestamp, along with the hash value obtained when hashing the complete block header.

[0033]

[0050] In some implementations, messages between mining nodes 202 related to AOLs 210 may contain a template identifier relating to the current streaming block template. This may be referred to here as the SB template identifier. The SB template identifier may be specific to mining node 202 and the block level, and is intended to refer to a particular candidate block, i.e., a specific ordered list of transactions. Any messaging from mining node 202 related to an ordered list of transactions (AOL) may contain the SB template identifier, ensuring that the receiving mining node 202 associates its changes with the correct specific ordered list of transactions. In some implementations, the SB template identifier may be a hash of the prev_block field in the block header and the miner identifier (miner ID), i.e., a hash of the previous block.

[0034] TmID = H(prev block || miner ID)

[0051] This associates SB template identifiers with block levels and specific miners.

[0035]

[0052] Each message related to an ordered list may further contain a sequence number. The sequence number may be an unsigned integer value used to indicate the order of messages from a particular minor associated with a specific template. Sequencing is useful for message recipients to uniquely determine the ordering of TXIDs for a particular minor when some messages are not received or are received out of order. Therefore, each append message may contain both an SB template identifier and a sequence number. The SB template identifier may remain constant for a block, while the sequence number is incremented with each message transmitted associated with that SB template identifier.

[0036]

[0053] The SB template identifier described herein is distinct from and different from a “template identifier” (template_id) or “candidate block identifier” (cb_id) that may be used by a transaction processor or block assembler within a miner, which represents the content of a candidate block at a specific point in time when that version of the candidate block is passed to a mining unit. As described below, the content of a candidate block may change over time as a candidate block to which transactions have been added and updated is passed to various mining units available to work on the candidate block. In some implementations... <base>.<sequence_number> The template_id (or cb_id), which may take the form of , tracks the state of its candidate block over time, and as a result, when a mining unit returns a solution, the block assembler or transaction processor can know which version of the candidate block the mining unit was working on. On the other hand, the streaming block template process runs somewhat asynchronously with the template construction process, and append messages sent to warn other miners about transactions contained in the current miner's candidate block may be detached from the state of the candidate block, particularly the version of the candidate block in which the solution has been found. Therefore, as will be further explained below, miners may engage in the synchronization process once a POW solution is found.

[0037]

[0054] As described above, the miner ID may be the IP address of the mining node or some other unique identifier for mining node 202. In some embodiments, an initial authentication operation may occur when a miner attaches to the network, resulting in the association of a unique miner ID with that miner node 202. The authentication operation may include a handshake operation in which each mining node 202 provides a public key and a digital signature. Authentication is linked to the verification of the digital signature. In some cases, the miner ID may be based on a public key, a digital signature, or some combination thereof. Thus, the mining nodes 202 may be interconnected by peer-to-peer authentication channels 206. Streaming block template messages may be exchanged over these authenticated channels 206.

[0038]

[0055] Compression identifier To reduce the amount of data transmitted between mining nodes in connection with streaming block templates, transaction identifiers specified in SBT messages may be compressed. One compression option is to truncate the transaction identifier so that only a portion of it is transmitted. This can result in collisions between truncated identifiers. Collisions can be exacerbated in the case of "manufactured TxIDs," i.e., there may be some case where the transaction is constructed in such a way that it ensures those TxIDs have certain features, such as a pattern within the TxID (e.g., multiple leading zeros). Such cases can lead to an increase in collisions and further increase the possibility of collision-inducing attacks. Therefore, it may be useful to provide a transaction identifier compression process other than simply truncating the TxID.

[0039]

[0056] In some cases, it may be useful to provide an extensible compressed identifier structure that offers increased collision resistance depending on the transaction volume or conditions. In some cases, it may be useful to compress the TxID in a way that attempts to retain as much randomness as reasonably possible. The coding method should be common across all peer nodes so that there is no need to maintain different coding processes to handle messages from different mining nodes. Furthermore, it would be advantageous in the implementation to have a process that enables fast storage and lookup of data structures operating under changing conditions.

[0040]

[0057] In one embodiment, the present application provides a method and system for compressing transaction identifiers and for identifying the complete transaction identifier from the compressed identifiers.

[0041]

[0058] Referring next to Figure 3, an exemplary compressed identifier structure according to the present application is schematically shown. By known methods, transaction identifier 302 is generated with respect to transaction 300. In the Bitcoin example, transaction identifier 302 is obtained by hashing transaction 300. In particular, Bitcoin specifies a double SHA 256 hash of transaction 300 to generate transaction identifier 302.

[0042]

[0059] The transaction identifier 302 is a fixed-length pseudorandom number. In the case of SHA256, the resulting number is 32 bytes long. The compressed transaction identifier (CID) 304 can be generated in two parts: creating a prefix 306 and concatenating it with the truncated portion 308 of the transaction identifier 302. The prefix 306 is a fixed-length number generated using a function applied to the complete transaction identifier 302. In some examples, it may be generated using a recursive hash function to produce a compact number. In some examples, the prefix 306 may be 2, 3, or 4 bytes long. The hash function used to generate the prefix 306 may be a non-cryptographic hash. The hash function may be selected based on ease of computational implementation and its randomness. Ideally, the hash function should produce a prefix value that is equally probable across the entire range of possible values, i.e., it should have an equally probable distribution. The function may be a Murmer hash function or one of its variations.

[0043]

[0060] In one example, the function includes XOR and folding operations. In some cases, the function may also or alternatively include rotate operations. In some cases, the function may further include XORing the transaction identifier with the salt value to improve the randomness of any non-randomized transaction identifiers (e.g., manufactured identifiers). The salt is a value known to all mining nodes and may also be a value recorded on the blockchain. In one example, the salt value may be a value that was not available before the previous block time. In one example, the salt value may be the Merkle root of the most recent block.

[0044]

[0061] An example process outline is as follows:

[0062] 1. Salt XOR TxID = CID32 Randomize any non-random pattern in TxID.

[0062] 2.CID32[0:15] XOR CID32[16:31] = CID16 {Fold CID 32 into 16 bytes}

[0064] 3.CID16[0:7] XOR CID16[8:15] = CID8 {Fold CID16 into 8 bytes}

[0065] 4.CID8[0:3] XOR CID8[4:7] = CID4 {Fold CDI8 into 4 bytes}

[0066] 5. CID4[0:2] = CID prefix {Truncate CID4 to the first 3 bytes}

[0067] In some cases, one or more cycles may be introduced at various steps of the process. The resulting CID prefixThis is a 3-byte randomized number that follows a statistically equal probability distribution.

[0045]

[0068] When using, CID prefix A prefix 306 like the one shown is concatenated with the truncated portion 308 of the transaction identifier. The truncated portion 308 may be a variable-length portion of the transaction identifier. The length of the truncated portion 308 may be set based on a predetermined CID length parameter cid_len, which may be set by individual mining nodes. The cid_len value may be specified by the mining node when it sends an initialization message regarding the establishment of a new block template. The cid_len value may be configured to specify the length of the truncated portion 308 in bytes, for example, in the range of 1 to 16. A typical length of the truncated portion 308 for a CID may be between 1 and 6 in many examples. In some other cases, the cid_len value may specify the overall CID length, including the 3-byte prefix 306. Experimental and modeling data suggest that a 4-byte CID may be optimal for blocks containing 10 million to 500 million transactions, while a 5-byte CID may be optimal for blocks containing 500 million to 10 billion transactions. These CID lengths correspond to 308 truncated portions of 1 or 2 bytes, respectively.

[0046]

[0069] Referring next to Figure 4, an example of a compressed transaction identifier storage system 400 is shown. System 400 is for storing transaction identifiers based on CIDs in mining nodes and for quick access. System 400 may be implemented using one memory device or multiple memory devices.

[0047]

[0070] System 400 may include a global TxID data structure 402, a TxID store index 404, and multiple buckets 406. The global TxID data structure 402 is a comprehensive list of transaction identifiers that are verified by mining nodes and available for inclusion in blocks, i.e., identifiers for pending unconfirmed transactions. This may be referred to in this case as the global transaction identifier list. Transaction identifiers are appended to the global TxID data structure 402 in the order of arrival. As described below, the order of arrival may be the order in which the transaction processors transmit them to the SBT module, which manages the CID generation and resolution process, and its management includes the management of the compressed transaction identifier storage system 400.

[0048]

[0071] The size of the TxID store index 404 depends on the length of the CID prefix. In this example, it is assumed that the prefix is ​​a 3-byte value. The TxID store index 404 assigns a pointer 408 to any CID prefix generated for a transaction identifier. Pointer 408 points to the location of the bucket 406 corresponding to that CID prefix. The TxID store index 404 can contain enough memory to store each pointer 408 for each address of the respective bucket 406 corresponding to each CID prefix.

[0049]

[0072] Each bucket 406 can be a flexible-sized data structure designed to contain one or more TxID indices 410 that point to a location (i.e., an index position) in a global TxID data structure 402 where the corresponding full TxID is stored.

[0050]

[0073] When a new transaction is received and validated by a mining node during use, the mining node generates a TxID (if it is not already known), appends the TxID to the global TxID data structure 402, and records the index of where the TxID is stored in the global TxID data structure 402. The mining node then generates a CID by generating a CID prefix using a compression process on the TxID, such as the recursive folding method described above. Once the prefix is ​​found, the prefix is ​​used to identify the corresponding bucket address using the TxID store index 404. The mining node then appends the TxID index 410 to its bucket 406, and the TxID index points to the location, i.e., position or index position, of the TxID stored in the global TxID data structure 402.

[0051]

[0074] To resolve the received CID, the mining node finds the corresponding bucket address in TxID store index 402 based on the prefix portion of the received CID. The mining node then reads TxID index 410 in that bucket 406 and places the corresponding TxID in the global TxID data structure 402 at the location indicated by TxID index 410. One of these TxIDs will fit the truncated portion of the CID.

[0052]

[0075] In particular, the data structure in this example scales well and allows for a high degree of concurrent access.

[0053]

[0076] Referring next to Figure 5, an exemplary method 500 for generating a compressed transaction identifier is provided in flowchart form. Method 500 may be implemented by a mining node in some examples. Method 500 may also be implemented by processor-executable instructions stored on a computer-readable medium, which, when executed by one or more processors, cause one or more processors to perform the function described. The instructions may be implemented as an application or a module such as an SBT module. An SBT module may be a standalone unit of software or may be incorporated as part of a larger system such as software routines, instructions, applications, or modules.

[0054]

[0077] In operation 502, the SBT module receives a transaction identifier. The transaction identifier may be provided by a transaction processor in a mining node configured to validate a new transaction. The transaction itself may be received via a peer-to-peer blockchain network in connection with the propagation of the transaction through the network. It may also be received via a merchant API from a merchant device connected to a mining node and / or blockchain network. The transaction identifier may also be determined by the transaction processor by hashing the transaction, which may be part of validating the transaction.

[0055]

[0078] To generate the CID, the SBT module, in this example, in operation 504, randomizes the TxID by performing an XOR operation with the salt. The salt may be some fixed number known to the mining node. In some examples, the salt may be the Merkle tree root of the most recently confirmed block in the blockchain. XORing a 32-byte Merkle root with a 32-byte TxID produces a 32-byte randomized TxID value.

[0056]

[0079] Next, in operations 506 and 508, the SBT module recursively folds the randomized TxID values ​​using XOR operations. Recursive folding involves XORing the first half of the number with the second half. For example, a 32-byte value is folded by XORing the first 16 bytes with the next 16 bytes. In some implementations, one or both halves of the halves may be cycled before the XOR operation. Recursive folding continues until the desired length is reached. In this example, folding continues until the value is 4 bytes long.

[0057]

[0080] Operation 510 indicates an optional circular operation. In some cases, the circularity may be applied to the final value obtained by recursive folding. Operation 512 indicates an optional truncation operation. In some cases, only a portion of the final value obtained by recursive folding is retained. In this example, only the first 3 bytes of the folded value are retained. Then, in operation 514, the result is output as a CID prefix.

[0058]

[0081] In this exemplary method 500, the CID generation process then further includes truncating the transaction identifier and concatenating the prefix with the truncated TxID, as shown by operation 516. The TxID may be truncated to a length determined based on a given CID length, as reflected by the cid_len parameter. Operation 516 results in the generation of a CID, which can then be used to signal to other mining nodes that the associated transaction is included in a candidate block by the current mining node.

[0059]

[0082] Method 500 further includes storing CID mappings, as shown by operations 518 to 522. In particular, in operation 518, the SBT module stores the TxID in global_list and records the location (e.g., index) where the TxID is stored. In operation 520, the SBT module then identifies the bucket associated with the CID prefix generated for the TxID. Then, in operation 522, an index against global_list is added to that bucket.

[0060]

[0083] It may be acknowledged that other actions may be performed in connection with the SBT module receiving a new TxID, such as adding the TxID to the append-only list (AOL) for the current mining node, reflecting the contents of the candidate block constructed by the current mining node, or including the CID in the append message sent to other mining nodes.

[0061]

[0084] Referring here to Figure 6, a flowchart is shown illustrating an exemplary method 600 for updating the AOL stored in the first mining node. In operation 602, the first mining node receives an append message from the second mining node. The append message contains an ordered set of CIDs. As will be further explained below, in some cases, the append message may even contain one or more extended CIDs or complete TxIDs if the sending mining node determines that a longer CID or complete TxID would be useful in avoiding collisions.

[0062]

[0085] In operation 604, the receiving mining node extracts the prefix portion of the received CID, which is used to identify the corresponding bucket in the TxID store. In one example, the prefix portion is the first three bytes. As mentioned above, a bucket contains one or more indices that point to locations in the global TxID data structure where the TxID corresponding to that prefix is ​​stored. In operation 606, the TxIDs pointed to by the index(s) are read to find a TxID that matches the remaining portion of the CID, i.e., the truncated portion. That is, the first part of the TxID will match the remaining portion of the CID. If no match is found, or if the bucket contains no index(s), in operation 608, the receiving mining node can send a message to the sending mining node to resolve the missing transaction data. For example, the message might request the complete TxID or the complete transaction corresponding to the CID.

[0063]

[0086] In operation 606, if a match is found, in operation 610, the checksum in the append message may be verified. In some exemplary implementations, the append message may include a checksum or another error detection mechanism to determine whether the resolved set of transaction identifiers obtained from the CID in the append message is correct. If it fails, it may indicate an undetected collision that requires resolution. As a result, the receiving mining node may send a message to the sending mining node requesting collision resolution regarding the failed checksum, as indicated by operation 608. If the checksum is verified, in operation 612, the receiving mining node appends the transaction identifier to the AOL stored in memory for the sending mining node. In some implementations, a single checksum value is provided for an ordered list of all transaction identifiers referenced in the append message. In other implementations, a checksum value is provided for each transaction identifier referenced in the append message. In yet another implementation, a checksum value is provided for each group of X sequential transaction identifiers in the order they are referenced in the append message. The group size X may be set by the blockchain protocol or by the mining node during initialization.

[0064]

[0087] As mentioned above, the CID length may be a fixed value. The fixed value may be defined in the network protocol and may, in some cases, be hardcoded. In some cases, it may be a predetermined network parameter selected by the consensus of the mining network. In some cases, it may be based on a length selected by a mining node when the mining node sends an SBT initialization message that signals that it is participating in the SBT network and has a candidate block that it will signal.

[0065]

[0088] The optimal length for balancing bandwidth utilization and collision probability may change with the volume of transactions. Providing an elegant mechanism for adjusting the CID length in response to conditional requirements may be advantageous. For example, the default CID length can be set by the CID length parameter cid_len, but the protocol may allow longer CIDs to signal transaction identifiers if collisions are detected by the sending node. Some implementations allow for two or more adjustments to the CID length to gradually adjust the length and avoid collisions on a case-by-case basis. In some cases, the complete TxID or even the complete transaction may be sent in an append message.

[0066]

[0089] Different opcodes may be defined for different types of references to signal the type of reference being sent. For example, the opcode OP_APPEND_CID may be defined to signal a compressed transaction identifier of length cid_len bytes. Another opcode, OP_APPEND_ECID, may be used to signal that an "Extended CID" is being appended, which has a length of (cid_len+1) bytes, i.e., one byte longer than the CID. That is, the truncated portion of the ECID is one byte longer than the truncated portion of the CID.

[0067]

[0090] In some cases, if the ECID cannot resolve a collision, another opcode, OP_APPEND_XCID, may be defined to signal a "further eXtended CID". The XCID can have a length of, for example, (cid_len+4) bytes, i.e., 3 bytes longer than the ECID and 4 bytes longer than the CID. In the very rare case where the ECID cannot resolve a collision, it may be possible to send the complete TxID using the opcode OP_APPEND_ID (which indicates that the subsequent data is a complete 32-byte TxID).

[0068]

[0091] In some cases, for example, when a miner receives a transaction submitted directly from a merchant API rather than via a peer-to-peer blockchain network, the receiving mining node may anticipate that it has not yet seen the message propagated over the peer-to-peer network and therefore choose to send the entire transaction in an append message (in addition to propagating it over the peer-to-peer network). For such situations, the opcode OP_APPEND_FULL can be defined, followed by a value indicating the length of the subsequent transaction data, and then possibly the complete transaction data.

[0069]

[0092] Referring here to Figure 7, a flowchart is shown illustrating one exemplary method 700 for generating a compressed transaction identifier. Method 700 may be carried out by a appropriately programmed computing device such as a mining node. It can be assumed here that the mining node has the TxID of the verified transaction and that the mining node is generating the prefix portion of the CID. The prefix portion may be generated using a recursive compression method, such as the recursive folding method described in relation to Figure 5, for example.

[0070]

[0093] In operation 702, the mining node identifies the bucket corresponding to the prefix generated for the TxID. This can include identifying a pointer to the address of the bucket stored in relation to the prefix in the txid_store data structure. The mining node then compares the TxID to TxIDs already referenced within the bucket, as shown by operation 704. That is, the bucket may already contain one or more TxID indices pointing to locations in the global TxID data structure where TxIDs with the same prefix are stored.

[0071]

[0094] In operation 706, the mining node evaluates whether one of the TxIDs referenced by the bucket matches at least the first N bytes of the current TxID. N may be a value set by the CID length parameter cid_len, such as N = cid_len + 1. That is, N may match the specified length of the XCID minus the 3-byte length of the prefix, i.e., N matches the length of the truncated portion of the XCID. If an existing stored TxID matches the first N bytes of the current TxID, in operation 708, the mining node determines that the complete ID should be sent. Therefore, the OP_APPEND_ID opcode is used to append the complete TxID to the append message.

[0072]

[0095] If no such match exists, at operation 710, the mining node evaluates whether at least M bytes of the current TxID match one of the TxIDs referenced in the bucket, where M < N. In some cases, M corresponds to the length of the truncated part of the ECID, e.g., cid_len - 2. In that case, at operation 712, the mining node determines that an XCID having a total length of, e.g., cid_len + 4, i.e., an XCID having a truncated part of a TxID having a length of cid_len + 1 bytes, should be transmitted. Thus, the XCID is assembled from the prefix and the first cid_len + 1 bytes of the TxID, and the OP_APPEND_XCID opcode is used to append the XCID to the append message.

[0073]

[0096] If no such match exists, at operation 714, the mining node evaluates whether at least P bytes of the current TxID match one of the TxIDs referenced in the bucket, where P < M < N. In some cases, P corresponds to the length of the truncated part of the CID, e.g., cid_len - 3. In that case, at operation 716, the mining node determines that an ECID having a total length of, e.g., cid_len + 1, where the truncated part is due to a length of cid_len - 2, should be transmitted. Thus, the ECID is assembled from the prefix and the first cid_len_2 bytes of the TxID, and the OP_APPEND_ECID opcode is used to append the ECID to the append message.

[0074]

[0097] If no match is found at operations 706, 710, or 716, or if there are still no TxIDs referenced within the bucket, at operation 718, the mining node generates a CID using the prefix and the first cid_len - 3 bytes of the TxID. Then, the OP_APPEND_CID opcode is used to append the CID to the append message.

[0075]

[0098] This exemplary process uses three possible compressed ID lengths (CID, ECID, XCID), but it will be acknowledged that other implementations may have more or fewer possible lengths. Furthermore, the lengths of the CID, ECID, and XCID values ​​in these examples are just an example of the set of lengths; other implementations may use different lengths. The process described above gradually adapts the length of the compressed identifier to address detected collisions and adapt to situations with high transaction volumes.

[0099] The methods and systems described above provide various options for streaming block template data between mining nodes, enabling pre-solution block template propagation. Using compressed transaction identifiers allows for reduced bandwidth usage. The exemplary process described for generating compressed transaction identifiers, through the elegant and adaptable extension of the compressed identifiers, helps detect and resolve collisions before they occur. The structure of the compressed identifiers, with prefixes configured to generally have an equal probability distribution, and the structure of the data model for storing data to decompress / resolve CIDs, provide resilience against attack vectors and enable fast, highly concurrent memory access for resolving CIDs.

[0076]

[0100] It would be advantageous to further utilize options for signaling transaction identifiers in a bandwidth-efficient manner. Therefore, in another aspect, the present application provides a method and system for signaling transaction identifiers that leverages the fact that mining nodes participating in the SBT network construct a common overall picture of the AOLs of other mining nodes. Most of these AOL lists are constructed from the same overall set of unconfirmed transactions. Thus, in one aspect, a mining node can refer to a transaction identifier in its own AOL using a pointer to the same transaction identifier in the AOL of another mining node.

[0077]

[0101] Figure 8 schematically illustrates a simplified exemplary system including two mining nodes: Miner A and Miner B. Miner A has an AOL-A list 802 that reflects an ordered list of transactions added to its current candidate block, and an AOL-B list 804 that reflects an ordered list of transactions that Miner B has notified it will be included in Miner B's candidate block. This constructs the AOL-B list based on append messages received from Miner B via an authenticated connection 806 between the two miners.

[0102] Minor B similarly maintains its own AOL-B list 808, which reflects an ordered list of transactions in its candidate block, and an AOL-A list 810, which reflects an ordered list of transactions that Minor A has notified it to be included in Minor A's candidate block.

[0078]

[0103] As mentioned above, the append message that miners use to signal each other their ordered lists of transactions within AOL is: OP_APPEND_CID, OP_APPEND_ECID, OP_APPEND_XCID, or It is possible to signal transaction identifiers in an ordered list using opcodes such as OP_APPEND_ID. However, if Miner A has signaled that it includes a particular transaction identifier 812 in AOL-A list 802, and has already entered that same particular transaction identifier 812 into AOL-B list 804 based on an append message from Miner B, Miner A has the option of specifying that particular transaction identifier to Miner B by pointing to Miner B's AOL-B list 804. Specifically, Miner A can indicate the index of that particular transaction within the ordered set of transactions that make up AOL-B list 804. In this example, the index could be 0x03.

[0079]

[0104] Therefore, when constructing an append message to be sent to Minor B, Minor A may choose to use OP_APPEND_IDX 0x03 instead of another opcode that references a compressed transaction identifier. When Minor B encounters the OP_APPEND_IDX opcode upon receiving the append message, Minor B understands that the specified index is an index on its AOL-B list 808. It can then copy the contents of that index from the AOL-B list, i.e., the TxID, to the AOL-A list 810. In this example, the TxID at index 0x03 on AOL-B list 808 is added to the AOL-A list 810.

[0080]

[0105] This method of signaling transaction identifiers can result in bandwidth savings when signaling AOL index values ​​is more efficient than signaling compressed transaction identifiers, especially when the compressed transaction identifiers are extended, further extended, or full transaction identifiers.

[0081]

[0106] The concept of specifying transaction identifiers by signaling an index to AOL can be extended to a multi-miner scenario in which one miner can signal a transaction identifier to a second miner by providing an index to the third miner's AOL. Figure 9 illustrates such a scenario involving miners A, B, and C. Miner A maintains its own AOL-A list 902, an AOL-B list 904 for miner B, and an AOL-C list 906 for miner C. The AOL-C list 906 is constructed by miner A based on append messages received from miner C. Similarly, miner B maintains its own AOL-B list 910, an AOL-A list 912 for miner A, and an AOL-C list 914 for miner C.

[0082]

[0107] If Minor A intends to send an append message to Minor B specifying TxID 920 in its AOL-A list 902, and knows that the same TxID 920 appears in AOL-C list 906 for Minor C, then Minor A can send an append message specifying AOL-C list 906 and its index, e.g., 0x05. Upon receiving the append message and encountering this reference, Minor B can then place the TxID in its copy of AOL-C list 914 at the specified index, e.g., 0x05. Minor B then copies the TxID and appends it to its AOL-A list 912.

[0083]

[0108] A third-party index reference opcode, OP_APPEND_EIDX, may be defined to specify an index to a third-party AOL list. OP_APPEND_EIDX includes both the index and a reference to the AOL list and / or related minor. In this sense, it is less efficient than OP_APPEND_IDX due to the inclusion of additional data, but nevertheless, in some cases, it may provide bandwidth savings that outweigh CID, ECID, XCID, and / or ID signaling.

[0084]

[0109] References to AOL lists included in append messages may, in some cases, be references to third-party miners, such as miner IDs, but these will not allow references to specific templates; rather, they will be interpreted as references to the then-current template for that third-party miner. Even within block time, if a new candidate block is started, the template may be reinitialized, so it may be advantageous to reference the template itself.

[0085]

[0110] Each template has a streaming block template identifier, sb_template_id, which is used when sending an initialization message. The sb_template_id is unique within the current template and, in combination with the sequence number applied to each append message, enables the receiving node to properly order and apply the append messages to update the correct template. Therefore, the OP_APPEND_EIDX operation can refer to the sb_template_id number, ensuring that the index is used to identify the TxID in the correct template.

[0086]

[0111] To make OP_APPEND_EIDX more efficient, it may be advantageous to use a more compact form of the SB template identifier. If it is assumed that only a few dozen or a few hundred templates exist at some point, the compact form of the SB template identifier may be obtained by truncating it to a fixed number of shortened bytes (e.g., 2 bytes). The shortening may be by truncation, truncated hash, murmer hash, or any other such mechanism. In some implementations, a miner initializing a new template and selecting a new SB template identifier first checks whether the compact form of the SB template identifier conflicts with any current template it is aware of, and if so, selects the new SB template identifier and checks the compact form of the new SB template identifier for conflicts.

[0087]

[0112] In at least one model environment, when examining blocks containing approximately 1 billion transactions, IDX and CID can result in similar average message sizes. CID may be slightly more efficient. IDX may be chosen when ECID or XCID must be used in other ways. ECID may be more efficient than EIDX. If available, it may be advantageous to choose EIDX over XCID or ID.

[0088]

[0113] As described above, the SBT process may involve sending or broadcasting an initialization message over the SBT network that specifies the SB template identifier of the sending mining node. That mining node can receive initialization messages from other mining nodes, each indicating its own SB template identifier. Upon receiving these messages, the mining node prepares to construct a corresponding AOL list for each node. The initialization message can set several parameters related to the mining node's AOL list. For example, it may specify the miner ID, SB template identifier, and CID length (cid_len) used by the mining node. In some cases, it may also include miner public key information and miner signature. In some cases, when sending append messages, it may specify the checksum group size, which is the number of transactions in the group for which a checksum is performed and provided. This value may also be specified in individual append messages in some implementations. In some cases, the initialization message may also include a previous block hash, allowing the recipient to verify that the message relates to a candidate block associated with the current mining window.

[0089]

[0114] The initialization message may further specify other mining nodes, from which the current mining node receives SB template data such as initialization and append messages. In other words, the initialization message can signal which AOL lists the current mining node is tracking. This allows other mining nodes to know whether they can use EIDX signaling with the current mining node that references the AOL lists of specific third-party mining nodes. In some cases, a mining node updates its AOL tracking data in a subsequent append message to signal that it is tracking AOL information for additional mining nodes. For example, a mining node signals that it is tracking AOL information for specific other nodes by listing SB template identifiers for those other nodes in its initialization and / or append messages as third-party templates it is building.

[0090]

[0115] After sending an initialization message, a mining node may send one or more append messages specifying an ordered list of transactions in the then-current candidate block. Each subsequent append message sent by a mining node in relation to the same template includes a template identifier and a sequence number. In this way, a mining node receiving or processing non-orderly append messages can ensure they are processed in the correct order in order to build the AOL list and / or to identify any missing append messages in the correct order.

[0091]

[0116] Each append message may contain a template identifier, a sequence number, and a transaction count indicating the number of references in the message. Following references to blocks of AOL data, i.e., CIDs, IDXs, etc., the message may contain one or more checksum values. In some cases, a checksum group size parameter may be included, specifying how many resolved transaction identifiers are grouped together for the purpose of performing and evaluating the checksum. In some cases, there may be a single checksum for all resolved transaction identifiers. In some cases, they may be split into smaller groups of transaction identifiers, each with its own checksum value.

[0092]

[0117] When a POW solution is found, i.e., when a mining node has solved the POW for a candidate block version, the mining node sends a finalize message sbt_finalize over the SBT network to notify other mining nodes that it has found a solution and provides details of the solution. The sbt_finalize message can include, for example, the complete block header, coinbase (generation) transaction, etc. As will be further explained below, it can also include data that enables synchronization with the candidate block in the AOL list.

[0093]

[0118] To address synchronization issues, it would be beneficial to consider the operation of various parts of an exemplary mining node. Figure 10 shows a simplified example of a mining node 1000 in block diagram form. In this example, the mining node 1000 includes a transaction processor 1002 configured to receive and validate new transactions and store them in a transaction data store 1004. The transaction data store 1004 may be local or it may be located remotely and connected to the transaction processor 1002 via one or more network connections.

[0094]

[0119] Mining node 1000 further includes an SBT module 1006 configured to construct CIDs, ECIDs, XCIDs, and various messages, including append messages sent to other mining nodes via the SBT network. SBT module 1006 is further configured to receive append messages from other mining nodes and construct corresponding AOL 1008 stored in local memory. SBT module 1006 can be further configured to determine whether to replace CIDs, ECIDs, XCIDs, or IDs with IDX or EIDX references in certain situations where the use of IDX or EIDX references is advantageous.

[0095]

[0120] The SBT module 1006 sends and receives communications on the SBT network via authenticated connections 1010 with other mining nodes. The transaction processor 1002 may send and receive peer-to-peer messages with other nodes via a network connection 1012 with the blockchain network.

[0096]

[0121] Transaction data may be received by mining node 1000 from three sources. Transactions can be received via network connection 1012 to the blockchain network, according to transaction propagation such as that managed by the applicable blockchain protocol. Such transactions are verified by transaction processor 1002, stored in transaction data store 1004, and, where applicable, further propagated to other nodes in the blockchain network via network connection 1012.

[0097]

[0122] Transactions may be received via the SBT network through one of the authenticated connections 1010 to another mining node. Such transactions may also be received in their entirety from the other mining node, especially if the other mining node knows that the transaction has not yet propagated entirely across the blockchain network. The SBT module 1006 transfers the complete transaction data to the transaction processor 1002 for verification and storage in the transaction data store 1004.

[0098]

[0123] Alternatively, transactions may be received by the mining node 1000 via the merchant API 1020 through the merchant connection 1014. The merchant API 1020 may be associated with, for example, a point-of-sale (POS) device or a payment processing gateway, and may allow the direct input of newly generated transactions to the mining node 1000 for verification and propagation.

[0099]

[0124] The transaction processor 1002 may further include a journaling block assembler 1030 configured to construct candidate blocks. These candidate blocks contain an ordered set of verified transactions from the transaction data store 1004. Figure 11, hereby referenced, schematically illustrates the assembly and distribution of candidate blocks.

[0100]

[0125] A mining node 1000 may include a plurality of mining units 1050 configured to perform operations to search for a Proof of Work (POW) with respect to a given candidate block 1040. In some cases, these mining units 1050 are located within the mining node 1000. In some cases, some or all of these mining units 1050 may be located outside the mining node 1000, for example, if the mining node 1000 functions as a pool coordinator for a mining pool.

[0101]

[0126] The journaling block assembler 1030 may be configured to add transactions to the candidate block 1040 over time as the transactions are received and validated by the transaction processor 1002. In some implementations, this may result in the journaling block assembler 1030 periodically creating new or updated candidate blocks. In some examples, new candidate blocks are assembled approximately every 1 / 10th of a second.

[0102]

[0127] If a mining unit 1050 fails to find a solution for the candidate block it was working on, it may request a new candidate block. The journaling block assembler 1030 can then respond by providing them with the candidate block 1040 that it has assembled at that time. Thus, different mining units 1050 may be working against different "versions" of candidate block 1040, depending on when they obtained the candidate block 1040 from the journaling block assembler 1030. Each "version" may have an associated candidate_block identifier.

[0103]

[0128] Similarly, in a somewhat asynchronous manner, the transaction processor 1002, and possibly the journaling block assembler 1030, can provide updated candidate block information to the SBT module 1006. The SBT module 1006 then constructs appropriate append messages to update other mining nodes with respect to the candidate block being tested by the mining node 1000. In some cases, the SBT module 1006 can receive candidate block data from the journaling block assembler 1030 regarding transactions added on a free-running basis, and can construct append messages based on this incoming information until the incoming information is marked with a new candidate_block identifier. When the SBT module 1006 detects a new candidate_block identifier, it terminates, sends a draft append message, and starts a new one using the new transaction data associated with the new candidate_block identifier. In this way, each append message corresponds to a candidate_block identifier, which makes subsequent synchronization easier.

[0104]

[0129] When mining unit 1050 identifies a POW solution, it notifies transaction processor 1002, which then notifies SBT module 1006 that a POW solution has been found and provides the associated candidate_block identifier. Since mining unit 1050 does not necessarily operate in a synchronized manner with respect to the current candidate block, it will be acknowledged that SBT module 1006 may be operating ahead of some mining units 1050 with respect to the append messages that it generates and sends. Therefore, SBT module 1006 checks which append message matches the resolved candidate_block identifier. It should be recalled that each append message has a template identifier, sb_template_id (which is constant with respect to block time), and a sequence number. Once SBT module 1006 determines which sequence number is associated with the candidate_block identifier, it can determine whether synchronization is required. If synchronization is required, it will take action to update the AOL list of each of the 1000 mining nodes and instruct the other mining nodes to roll back one or more append operations.

[0105]

[0130] For example, a synchronous rollback may be implemented by sending the sequence number corresponding to the candidate_block in the finalization message to other mining nodes. The other mining nodes can then unwind any appends caused by subsequent append messages with the sequence number in order to reach an AOL that matches the resolved candidate block.

[0106]

[0131] In another example, a synchronous rollback may be performed by inserting an OP_DELETE operation into the finalize message that specifies the deletion of all transactions added after a given index indicated in the OP_DELETE message.

[0107]

[0132] Referring here to Figure 12, the parallel processes of candidate block updating and SBT communication for a mining node are schematically illustrated. On the left side of the figure is the first version of the candidate block formed by the journaling block assembler. The first version is formed when the assembler adds verified transactions to the candidate block in order. These transactions, and possibly their indices (e.g., location / order) within the candidate block, are relayed to the SBT module. This passing of transaction data to the SBT module is done in a message tagged with a candidate block identifier, e.g., candidate_block_id. In one example, the identifier cb_id is specified for ease of reference. In this simplified example, cb_id is initially set to 0, and as a result, each transaction in the first version relayed to the SBT module is in a message specifying cb_id=0.

[0108]

[0133] The SBT module appends the received transaction data to the draft append message as soon as it is received, thereby constructing the append message for transmission. It will be acknowledged that the append message may contain CIDs, ECIDs, or XCIDs rather than the complete TxID. In some cases, it may contain IDX or EIDX references; however, in some implementations, the SBT module may leave it to decide later whether to replace the CID, ECID, XCID, or ID reference with an IDX or EIDX reference before sending the message to a particular miner.

[0109]

[0134] At some point, the journaling block assembler completes the assembly of the current candidate block. This may be triggered periodically, for example, every 1 / 10th of a second, or in response to a request from a mining unit for a new block. In some cases, an initial version of a candidate block is assembled and sent as soon as the journaling block assembler completes it using currently available transactions, and then, if they are validated and stored in the transaction process, additional validated transactions are added, and a new "version" of the candidate block is marked each time an evolving candidate block is sent to a mining unit in response to a request from the mining unit to mine the candidate block.

[0110]

[0135] Regardless of how the journaling block assembler determines when the candidate block version changes, each time it changes, subsequent transactions relayed to the SBT module are marked with the updated candidate block identifier. In the illustrated example, when a transaction at index position 0x05 is relayed to the SBT module, it is contained in a message that includes cb_id=1. Therefore, upon receiving that message, the SBT module determines that the candidate block version has changed (from 0x00 to 0x01). As a result, it terminates and sends the draft append message without adding any further new transactions. It then opens a new draft append message with the next sequence number and adds the transaction at index 0x05 in the candidate block to the new draft append message. It is also possible to update the local AOL stored in the memory of this mining node to track the current state of the candidate block.

[0111]

[0136] This process, as illustrated, involves the SBT module closing and sending an append message each time it discovers from the relayed transaction from the journaling block assembler that the candidate block identifier has been incremented. If one of the mining units finds a solution, it returns the solution to the transaction processor along with the candidate block identifier of the candidate block for which it found the solution. This is not necessarily the current candidate block identifier, as the candidate block version being worked on may have been updated one or more times since the mining unit was provided with it. Thus, the journaling block assembler can use the candidate block identifier to determine which version of the candidate block has been resolved.

[0112]

[0137] The solution and its associated candidate block identifier are also relayed to the SBT module. The SBT module then determines which append messages were associated with the resolved candidate block, i.e., which append messages were sent when the candidate block identifier was incremented. For example, using the illustrated process, if the candidate block identifier of the resolved block was cb_id=1, then the candidate block contains an ordered set of transactions spanning indices 0x00 to 0x10. The SBT module then identifies that append messages with sequence numbers 0 and 1 match the candidate block, but append message sequence number 2 and draft (but unsent) append message sequence number 3 are not part of the resolved candidate block.

[0113]

[0138] Therefore, the SBT module prepares and sends an SBT finalize message, e.g., sbt_finalize, to notify other mining nodes that a solution has been found, provides solution data (e.g., block header data, coinbase transaction, etc.), and provides synchronization data. For example, the synchronization data may be the sequence number of the last append message corresponding to the resolved candidate block. The receiving mining nodes then check whether they have updated the corresponding AOL list using append messages with later sequence numbers, and roll back those appends to ensure that the AOL list matches the contents of the resolved candidate block. They can then use the solution data from the SBT finalize message to assemble the completed block and verify the block solution.

[0114]

[0139] Alternatively, the synchronization data may be one or more explicit delete opcodes specifying the transactions to be removed from the AOL list in order to roll back the previous append operation. The delete opcode may be a single opcode for the oldest append that needs to be deleted, with the understanding that all subsequent appends must also be deleted, or the delete opcode may be included for all transaction identifiers that need to be removed from the AOL list.

[0115]

[0140] Referring again to the example above, if the SBT module determines that append message 2 and draft append message 3 should be removed, the SBT module simply discards draft append message 3 and specifies sequence number 1 in the SBT finalize message. The receiving mining node then determines which transactions were added based on append message sequence number 2 and removes those transaction identifiers from the AOL list. Alternatively, the SBT finalize message contains the delete operation to be applied to remove those transaction identifiers.

[0116]

[0141] Thus, the journaling block assembler operates independently of the SBT module, and is partially synchronized with candidate block versions with respect to blocking transaction identifiers in separate append messages, which then enables rapid and sophisticated synchronization of AOL lists on remote mining nodes upon solution discovery.

[0117]

[0142] Referring here to Figure 13, one exemplary method 1300 of the operation of a transaction processor within a mining node is shown in flowchart form. It will be acknowledged that not all operations or functions of the transaction processor are shown in the flowchart. Some of the operations shown in the flowchart may be performed by the journaling block assembler. Some of the operations shown in the flowchart may be performed by other parts of the transaction processor other than the journaling block assembler. In some cases, some of the operations shown in the flowchart may be performed by components of the mining node outside of the transaction processor itself.

[0118]

[0143] In operation 1302, the transaction is received. The transaction may be received via a peer-to-peer blockchain network, a merchant API connection, or otherwise. The transaction processor verifies the transaction and stores it in a memory pool of unverified transactions. In operation 1304, the transaction processor determines that the transaction should be included in the current candidate block. The basis for this determination may differ in different implementations. In this case, the determination is made and the transaction is appended to the current candidate block having the candidate block identifier i. The transaction may also be appended to the candidate block at index n in an ordered list of transactions in the candidate block, as represented by its transaction identifier. The transaction identifier in the candidate block and its index n are sent to the SBT module in operation 1306, along with the associated candidate block identifier i.

[0119]

[0144] In operation 1308, the transaction processor evaluates whether a solution has been discovered by any of its mining units. Notification of a solution from any mining unit will be accompanied by the candidate block identifier associated with the solved candidate block and details of the solution (e.g., nonce, Merkle root, etc.). If such a solution is discovered, the transaction processor can begin verifying the solution and notify the SBT module of the solution and associated candidate block identifier, as shown in operation 1312, which in turn can notify other miners and begin the process of synchronizing their AOL lists. If no such solution is discovered, the transaction processor also evaluates whether a notification of a solution from an external miner has been received, as shown in operation 1310. This notification may arrive via a peer-to-peer blockchain network or via the SBT network. It will be understood that the transaction processor can construct the newly discovered block from the corresponding AOL list maintained by the SBT module and will also perform the task of verifying the new block to confirm its legitimacy. Additionally, a legitimate block may result in flushing the memory pool of the confirmed transaction.

[0120]

[0145] If a solution is found either externally or internally, in operation 1314, the block identifier and index are reset, and in operation 1316, the transaction processor initializes a new candidate block. The process then returns to operation 1302 and begins filling the new candidate block with unconfirmed transactions.

[0121]

[0146] If no solution is found, in operation 1318, the transaction processor may decide whether to increment the candidate block identifier. As described above, the transaction processor may be configured to update the candidate block version and identifier on a fixed period basis, for example, every 1 / 10 second. In some cases, the transaction processor may be configured to update the candidate block version and identifier in response to candidate block requests from one or more mining units. If no update is scheduled, in operation 1319, index n is incremented, and the process returns to operation 1302, continuing to add unconfirmed transactions to the current candidate block.

[0122]

[0147] If the candidate block version and index are scheduled to be updated, in operation 1320, the transaction processor may send the current candidate block to one or more mining units to be mined, and may also increment the candidate block identifier i before returning to operation 1302 to continue adding unconfirmed transactions to the current candidate block.

[0123]

[0148] One exemplary method of operation of the SBT module within a mining node is illustrated by the flowchart in Figure 14. It will be understood that not all operations or functions of the SBT module are necessarily shown in the flowchart. For example, this flowchart does not show the handling of incoming append messages and the construction of the corresponding AOL list, or the generation or resolution process of TxID compressed identifiers. Some of the operations described in the flowchart may be performed by the SBT module. Some of the operations described in the flowchart may be performed by other components of the mining node outside of the SBT module itself.

[0124]

[0149] In operation 1402, the SBT module may perform initialization such as clearing the data structure, zeroing out the index, and allocating memory. Operation 1402 may further include sending an initialization message to other mining nodes indicating the SB template identifier and other parameters to be used by the mining node for the current block. In operation 1404, the SBT module initiates a draft append message for the current candidate block. The append message may include an SB template identifier sb_template_id, which can be selected so as not to conflict with any existing SB template identifiers received from other mining nodes, or their compressed versions, if any. The append message may further include a sequence number, which may be initially set to 0.

[0125]

[0150] In operation 1404, the SBT module receives transaction data from the transaction processor, such as a transaction identifier, a candidate block identifier (e.g., cb_id) indicating the candidate block version to which the transaction is attached, and an index indicating the transaction's position in an ordered list of transactions within the candidate block.

[0126]

[0151] In operation 1408, the SBT module determines whether the received candidate block identifier has been incremented since the last received identifier. If not, the SBT module learns that the received transaction identifier has been appended to the current candidate block version and, if applicable, proceeds to generate the corresponding CID, ECID, XCID, etc., and appends a reference to the transaction (e.g., CID, ECID, XCID, ID, IDX, EIDX, etc.) to the draft append message, as indicated by operation 1410.

[0127]

[0152] If no block solution is found, as indicated by operation 1416, method 1400 returns to operation 1406 to process the next transaction data received from the transaction processor. This can continue until, in operation 1408, the SBT module determines that the transaction identifier received from the transaction processor is associated with an incremented candidate block identifier, e.g., cb_id. In such a case, the SBT module then closes the draft append message without adding a new transaction identifier, as indicated by operation 1412, and sends it to the other mining nodes. Then, in operation 1414, a new draft append message with an incremented sequence number is opened, and then the process proceeds to operation 1410, where the received transaction identifier (or its compressed form) is added to the new draft append message.

[0128]

[0153] If a block solution is detected in operation 1416 and it is discovered by an external mining node, the SBT module returns to initialization operation 1402. The AOL list and data structures are reinitialized, and the process of building a new candidate block begins anew.

[0129]

[0154] As shown in operation 1418, if the SBT module receives notification of a solution from a transaction processor indicating that the solution has been found by this mining node, the SBT module prepares an SBT finalize message to be sent to other mining nodes. In particular, the notification from the transaction processor regarding the found solution includes a reference to the candidate block identifier associated with the solution. In operation 1420, the SBT module determines which append message corresponds to the last group of transactions added in the candidate block associated with the candidate block identifier. Then, in operation 1422, it sends an SBT finalize message containing block solution information and synchronization data to other mining nodes. As described above, in some implementations, the synchronization data may include the sequence number of the last valid append message associated with the resolved candidate block. In some implementations, the synchronization data may include a delete instruction that identifies a transaction identifier to be removed from the associated AOL list in order to synchronize it with the resolved candidate block.

[0130]

[0155] Referring here to Figure 15, a simplified mining node 1500 according to an example of the present application is shown in block diagram form. The mining node 1500 includes a processor 1502 which may include one or more microprocessors, application-specific integrated circuits (ASICs), microcontrollers, or similar computer processing devices. The mining node 1500 may further include memory 1504 which may include persistent and non-persistent memory for storing values, variables, and, in some cases, processor-executable program instructions, and one or more network interfaces 1506.

[0131]

[0156] The mining node 1500 may include a processor-executable blockchain application 1508 which, when executed, causes the processor 1502 to perform one or more of the functions or operations described herein.

[0132]

[0157] The various embodiments presented above are merely examples and are not intended to limit the scope of this application. Modifications of the technological innovation described herein will be obvious to those skilled in the art, and such modifications fall within the intended scope of this application. In particular, it is possible to select features from one or more of the above-described exemplary embodiments to create alternative exemplary embodiments that include sub-combinations of features not explicitly described above. Furthermore, it is possible to select and combine features from one or more of the above-described exemplary embodiments to create alternative exemplary embodiments that include combinations of features not explicitly described above. Features suitable for such combinations and sub-combinations will be readily apparent to those skilled in the art when considering this application as a whole. The subject matter described in the specification and claims is intended to cover and encompass all appropriate modifications of the technology.

Claims

1. A method performed by a computer for compressing a transaction identifier by a first mining node in a blockchain network, the method being: Steps include constructing a first candidate block containing a first ordered list of transaction identifiers; The second mining node receives data from the second mining node specifying a second ordered list of transaction identifiers in a second candidate block to be mined by the second mining node; The step of determining that at least one transaction identifier in the first ordered list is also present in the second ordered list; A step of generating an append message which includes data specifying a first ordered list of transaction identifiers, wherein the data specifies the at least one transaction identifier in the first ordered list of transaction identifiers by including the index position of the at least one transaction identifier in a second ordered list of transaction identifiers; and The step of transmitting the append message to the second mining node; A method that includes this.

2. A method according to claim 1, wherein the generating step includes determining that the index location is more compact than the compressed transaction identifier for the at least one transaction identifier.

3. A method according to claim 2, wherein the step of determining that the index location is more compact includes the step of generating the compressed transaction identifier.

4. The method according to claim 3, wherein the first mining node and the second mining node specify compressed transaction identifiers of at least two lengths, and the step of generating the compressed transaction identifiers includes determining that at least one transaction identifier requires the longer of the at least two lengths due to a collision, and determining, based on the determination, that the index position is more compact.

5. The method according to any one of claims 1-4, further: The third mining node receives data from the third mining node specifying a third ordered list of transaction identifiers in a third candidate block that is actively mined by the third mining node; The step of determining that one of the transaction identifiers in the first ordered list is also present in the third ordered list; and The step of specifying one of the transaction identifiers in the append message by including the index position of one of the transaction identifiers in a third ordered list of the transaction identifiers, and a reference to the third ordered list; A method that includes this.

6. The method according to claim 5, wherein the designated step includes first determining that the second mining node stores the third ordered list.

7. The method according to claim 6, further comprising the step of receiving data from the second mining node specifying a list stored in the second mining node, wherein the data specifying the list includes a reference to the third ordered list.

8. A method according to any one of claims 1 to 7, further comprising the steps of: receiving a second append message from the second mining node, wherein the second append message includes data specifying another ordered list of transaction identifiers; analyzing the data to obtain the other ordered list of transaction identifiers; and storing the other ordered list of transaction identifiers appended to the second ordered list of transaction identifiers.

9. The method according to claim 8, wherein the data includes references to transaction identifiers in a first ordered list of transaction identifiers.

10. A method according to claim 9, wherein the reference includes an index position in the first ordered list, and the analysis includes obtaining a transaction identifier at the index position in the first ordered list.

11. A method according to any one of claims 5-7, further comprising: receiving a second append message from the second mining node, wherein the second append message includes data specifying another ordered list of transaction identifiers; analyzing the data to obtain another ordered list of transaction identifiers; and storing the other ordered list of transaction identifiers appended to the second ordered list of transaction identifiers, wherein the data includes references to transaction identifiers in a third ordered list of transaction identifiers.

12. The method according to claim 11, wherein the reference includes a reference to the third ordered list and an index position in the third ordered list, and the analysis includes obtaining a transaction identifier at the index position in the third ordered list.

13. A method according to claim 12, further comprising the step of sending an initial message to the second mining node that references a third ordered list of transaction identifiers.

14. A computing device for compressing transaction identifiers in a blockchain network, wherein the computing device is: One or more processors; memory; and Processor-executable instructions stored in the aforementioned memory; An arithmetic device comprising, wherein the processor-executable instruction, when executed by one or more processors, causes the processors to perform the method according to any one of claims 1 to 13.

15. A computer-readable storage medium for storing processor-executable instructions for compressing transaction identifiers in a blockchain network, wherein, when executed by one or more processors, the processor-executable instructions cause the processors to perform the method according to any one of claims 1 to 13.

Images