Computer-Implemented System and Method for Managing a Large-Scale Distributed Memory Pool in a Blockchain Network

Abstract

To provide a computer-implemented method implemented in a block chain network.SOLUTION: A verification node receives data about a newly mined block with a plurality of transactions, and transmits to a distributed memory pool a deletion request to delete the plurality of transactions from the distributed memory pool. A node that stores the distributed memory pool stores a plurality of transactions, and the plurality of transactions forms at least part of the distributed memory pool that waits to be mined into a block of the block chain. A method implemented in a computer further receives the deletion request from the verification node of a block chain network. The deletion request identifies one or more transactions contained in the newly mined block and the deletion request indicates that the one or more transactions should be deleted from the distributed memory pool.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] This specification generally relates to computer-implemented methods and systems suitable for implementation in nodes of a blockchain network. An improved blockchain node structure, network architecture, and protocol for handling a large number of transactions and large transaction blocks are described. The present invention is suitable for use with, but not limited to, in particular, the Bitcoin blockchain.

Background Art

[0002] In this document, we use the term 'blockchain' to include all forms of electronic, computer-based, distributed ledgers. These include, but are not limited to, blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. The most widely known use of blockchain technology is the Bitcoin ledger, but other blockchain implementations have also been proposed and developed. Here, for convenience and explanation, Bitcoin may be referred to, 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.

[0003] A blockchain is a consensus-based digital ledger implemented as a computer-based decentralized distributed system composed of a plurality of blocks consisting of transactions and other information. In the case of Bitcoin, each transaction is a data structure that encodes the transfer of management of digital assets among participants in the blockchain system and includes at least one input and at least one output. By each block including the hash of the previous block to which that block is chained together, a permanent and immutable record of all transactions written to that blockchain before its inception is created. Transactions include small programs known as scripts embedded in their inputs and outputs, which specify how the outputs of the transaction can be accessed by whom. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] For a transaction to be written to the blockchain, the transaction must be "verified". Some network nodes act as miners and perform work to ensure that each transaction is valid, and invalid transactions are rejected by the network. For example, the software client installed on the node performs this verification work on transactions that reference unspent transaction outputs (UTXOs). Verification can be performed by executing its locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to TRUE and certain other conditions are met, the transaction is valid and can be written to the blockchain. Therefore, for a transaction to be written to the blockchain, the transaction must be i) verified by the node receiving the transaction (if the transaction is verified, the node relays it to other nodes in the network), ii) added to a new block constructed by the miner, and iii) mined, i.e., added to the public ledger of past transactions. When a sufficient number of blocks have been added to the blockchain to make the transaction substantially irreversible, the transaction is considered approved.

[0005] Blockchain technology is best known in relation to the use of cryptocurrency implementations, but digital entrepreneurs are beginning to explore the use of both Bitcoin-based cryptographic security systems and data that can be stored on the blockchain in implementing new systems. It would be highly advantageous if the blockchain could be used for automated tasks and processes that are not at all limited to cryptocurrency-based payments. Such solutions could be more flexible in those applications while leveraging the advantages of the blockchain, such as a permanent tamper-proof record of events, distributed processing, etc.

[0006] One area of research is the use of blockchain for the implementation of "smart contracts". These are computer programs designed to automate the fulfillment of the terms of a machine-readable contract or agreement. Unlike traditional contracts written in natural language, smart contracts are machine-executable programs with rules that can process inputs to produce results, and can execute actions based on those results.

[0007] Another area of interest related to blockchain is the use of 'tokens' (or 'colored coins') to represent and transfer real-world entities via the blockchain. Potentially confidential or secret items can be represented by tokens that have no identifiable meaning or value. Tokens thus function as identifiers that enable real-world items to be referenced from the blockchain. SUMMARY OF THE INVENTION

[0008] The future of blockchain technology, such as Bitcoin for example, relies at least in part on proposals for new architectures that can increase the amount of transactions issued per second. One requirement for such new architectures is to remove the current limits on block size. In that scenario, one technical problem is how to manage the data of large blocks and how to manage the storage of very large blockchain. Another technical problem is how to manage the pool of transactions waiting to be mined into blocks and incorporated into the blockchain. A local memory pool cannot provide sufficient storage capacity, and therefore, it is necessary to design a new model for distributed memory pools (DMPs). After transactions are included in the blockchain, it is desirable to remove those transactions from such distributed memory pools. However, another technical problem is how to safely manage the removal of transactions from distributed memory pools without causing problematic data inconsistencies within the distributed memory pools. Yet another technical problem is how to mitigate the problem of data inconsistencies while also improving the security against attacks that attempt to fragment the data stored in distributed memory pools.

[0009] One aim of certain embodiments of the present invention is to address these technical problems by providing the technical solutions described herein. In particular, this specification describes a protocol for communication and data management between verification nodes and distributed memory pool nodes in a blockchain network that enables the distributed memory pool to be pruned while mitigating the problem of data inconsistencies within the distributed memory pool. Accordingly, the present invention makes a technical contribution by increasing the capacity of the blockchain network while maintaining its decentralization.

[0010] A computer-implemented method for a node of a blockchain network is described, the computer-implemented method comprising: storing a plurality of transactions, the plurality of transactions forming at least a portion of a distributed memory pool waiting to be mined into blocks of a blockchain; receiving a deletion request from a validation node of the blockchain network, the deletion request identifying one or more transactions included in a newly mined block, the deletion request indicating that the one or more transactions should be deleted from the distributed memory pool; and having.

[0011] The method described above is incorporated into the blockchain by the validation node communicating with the distributed memory pool, and thus enables the removal of transactions that can be removed from the distributed memory pool. The sending / receiving of an explicit deletion request indicating that one or more transactions should be deleted from the distributed memory pool is different from a mere notification that the transaction has been mined. In prior art configurations, mined transactions are not removed from the memory pool until a sufficient number of blocks have been mined above the transaction for it to be approved. Thus, the memory pool contains a large number of transactions that are not likely to be needed for a significant amount of time after they are mined into the blockchain. Further, if a miner automatically deletes a transaction after a certain period of time without following a specific deletion request protocol, it can lead to data inconsistencies in certain situations. The present invention recognizes and addresses these problems.

[0012] The method may further include marking a transaction as being removed from the distributed memory pool when a first threshold number of deletion requests for the transaction are received. The method may also include physically removing a transaction from the distributed memory pool when a second threshold number of deletion requests for the transaction are received. The second threshold is greater than the first threshold. Further, it is required that the first threshold number of deletion requests and the second threshold number of deletion requests come from different verification nodes of the threshold number within the blockchain network. These features require a level of consensus regarding the marking of a transaction as being removed within the distributed memory pool and a further level of consensus before the transaction is physically removed from the distributed memory pool. This mitigates the problem of data inconsistency and improves security against attacks attempting to fragment the data stored in the distributed memory pool. A transaction effectively has three states with respect to the distributed memory pool: available, marked for removal, and physically removed. A transaction marked for removal can be restored to be available again within the distributed memory pool if needed. A transaction physically deleted may not be restorable depending on the system configuration.

[0013] A transaction can be physically removed from the distributed memory pool only after a threshold time has elapsed since receiving the deletion request and without any further data requests for the transaction being received. For example, the threshold time can correspond to at least 1, 2, 3, 4, 5, 6, or more blocks being incorporated into the blockchain after the transaction for which deletion from the distributed memory pool is requested has been incorporated into the blockchain. Also, the transactions can be physically removed from the distributed memory pool in descending order of the time elapsed since receiving the deletion request and without any further data requests for the transaction being received. The computer-implemented method can also mark a transaction as being removed from the distributed memory pool when the transaction depends on a previously removed transaction. These features further help to mitigate the problem of data inconsistency and further improve the security against attacks that attempt to fragment the data stored in the distributed memory pool.

[0014] Deletion requests can be stored in a new deletion request database associated with the distributed memory pool. Deletion requests received from validators that did not validate the transaction can be discarded. The transaction can only be discarded if the check validator option is enabled. The number of data requests for a transaction that has already been marked for removal from the distributed memory pool can also be monitored. By using such a system, after a threshold number of data requests are received for a transaction marked for removal from the distributed memory pool, the transaction can be marked as a candidate for return to the distributed memory pool. A transaction can have its marking as being removed from the distributed memory pool removed when a return request is received for the transaction, or when a threshold number of return requests are received for the transaction. The threshold number of return requests can be required to come from a threshold number of different validation nodes within the blockchain network. In response to an inquiry about a transaction removed from the distributed memory pool, a message indicating that the transaction has been removed from the distributed memory pool can be sent. Also, such a message can indicate that the transaction has been removed from the distributed memory pool and can also indicate the number of deletion messages received for the removed message. Again, these features further help mitigate the problem of data inconsistencies and further improve the security against attacks that attempt to fragment the data stored in the distributed memory pool.

[0015] The above-described features of the protocol for distributed memory pool management are described from the perspective of the distributed memory pool storage nodes within the blockchain network. From the perspective of the validation nodes within the blockchain network, receive data regarding a newly mined block having a plurality of transactions, send a deletion request to the distributed memory pool to delete the plurality of transactions from the distributed memory pool A computer-implemented method is provided that has

[0016] The deletion request should preferably include a nonce and / or a timestamp in order to avoid the spread of unauthorized copies that could affect the consensus protocol. The deletion request should also preferably be signed with the private key of the validation node.

[0017] A node can store a record of the transactions it has verified and send a deletion request only for transactions it has previously verified. The deletion request can be sent only for transactions previously verified by the node when the check validator option is enabled. Also, a revert request can be sent to make the transaction reusable within the distributed memory pool, for example, after a blockchain reorg, to maintain data consistency within the system.

[0018] The deletion request is receipt of a mined block, blockchain reorg, and double spending or other forms of transaction conflict, and can be triggered by one or more of these.

[0019] Pruning of transactions from the distributed memory pool can be manual pruning, transaction expiration, and reaching the memory limit for the transactions within the distributed memory pool, and can be triggered by one or more of these.

[0020] Embodiments of the present invention can be provided in various forms. For example, a computer-readable storage medium having computer-executable instructions can be provided, and when the computer-executable instructions are executed, they configure one or more processors to execute the methods described herein. An electronic device having an interface device, one or more processors coupled to the interface device, and a memory coupled to the one or more processors, the memory storing computer-executable instructions that, when executed, configure the one or more processors to execute the methods described herein, can also be provided. Even further, a node of a blockchain network configured to execute the methods described herein can be provided.

Brief Description of the Drawings

[0021] These and other aspects of the present invention will become apparent and be elucidated with reference to the embodiments described herein. Hereinafter, embodiments of the present invention will be described by way of example only, with reference to the accompanying drawings, which include the following.

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Best Mode for Carrying Out the Invention

[0022] Types of Blockchain Network Nodes A blockchain network can be described as a peer-to-peer open membership network that anyone can join without invitation or the consent of other members. A decentralized electronics device running an instance of a blockchain protocol under which the blockchain network operates can participate in the blockchain network. Such a decentralized electronics device can be referred to as a node. The blockchain protocol can be, for example, the Bitcoin protocol or other cryptocurrencies.

[0023] Electronics devices that run a blockchain protocol and form nodes of a blockchain network can be of various types, including, for example, computers such as desktop computers, laptop computers, tablet computers, servers, computer farms, mobile devices such as smartphones, wearable computers such as smartwatches, or other electronics devices.

[0024] Nodes of a blockchain network are coupled to each other using suitable communication technologies that can include wired and wireless communication technologies. In many cases, the blockchain network is implemented at least partially on the Internet, and some of the nodes can be located in geographically dispersed locations.

[0025] Currently, nodes are grouped into multiple blocks, and each of the multiple blocks maintains a global ledger of all transactions on a blockchain that includes the hash of the preceding block in the chain. The global ledger is a distributed ledger, and each node can store a complete copy or a partial copy of the global ledger. The validity of the global ledger is maintained by having transactions by nodes that affect the global ledger verified by other nodes. Details of implementing and operating a blockchain network, such as those using the Bitcoin protocol, will be understood by those skilled in the art.

[0026] Each transaction typically has one or more inputs and one or more outputs. Scripts embedded in the inputs and outputs specify how the outputs of the transaction can be accessed by whom. The output of a transaction can be an address to which a value is transferred as a result of the transaction. And that value is associated with that output address as an unspent transaction output (UTXO). Subsequently, subsequent transactions can reference that address as an input to spend or distribute that value.

[0027] Nodes can be of different types or categories depending on their functions. There are four basic functions associated with nodes that have been proposed: wallet, mining, full blockchain maintenance, and network routing node. There may be variations of these functions. A node may have two or more of these functions. For example, a "full node" provides all four functions. Thus, a lightweight node can be implemented, for example, in a digital wallet and perform only the wallet and network routing functions. A digital wallet can track block headers that can serve as an index when querying blocks rather than storing the entire blockchain. Nodes communicate with each other using connection-oriented protocols such as TCP / IP (Transmission Control Protocol / Internet Protocol).

[0028] Additional types or categories of nodes may be provided, such as merchant nodes (herein sometimes referred to as "M-nodes" ("Mノード")). M-nodes are designed to focus on the fast propagation of transactions. They may or may not store the entire blockchain, and they do not perform the mining function. In that sense, they are similar to lightweight nodes or wallets, but they include the additional function of enabling the fast propagation of transactions. The operational focus of M-nodes is, in particular, the rapid verification and propagation of unapproved transactions to other M-nodes, from which those unapproved transactions are quickly pushed out to other nodes within the blockchain network. To facilitate this function, M-nodes are permitted a greater number of incoming connections and, in particular, outgoing connections than would otherwise be permitted to nodes under the management protocol.

[0029] These M-nodes may collectively be referred to as a merchant network (or "M-net" ("Mネット")). The term "merchant" may be interpreted to mean "specialized". M-nodes can be integrated into the blockchain network. Each M-node is a specialized node on the blockchain network that meets certain hardware capabilities and performance capabilities that will ensure that it can perform the functions of an M-node. That is, the M-net can be regarded as a sub-network dispersed throughout the blockchain network. One or more M-nodes can be configured and set up to perform one or more dedicated functions or services.

[0030] For the M - net to operate reliably and provide services at a certain security level, M - nodes need to maintain a good overview of the entire M - net. Therefore, an efficient routing protocol needs to be in place. Whenever an M - node receives a start transaction, its M - mode needs to broadcast that transaction to several other M - nodes and other nodes. In the context of the M - net, this amounts to finding a solution to the multiple traveling salesman problem (MTSP). There are far too many solutions to this problem, and any one of them could be adopted in the M - net. Each M - node runs some up - to - date form of routing optimization.

[0031] In some implementations, the M - net is implemented as a decentralized IP - multicast - type network. That is, in order to enable the fast dissemination of incoming transactions to the blockchain network, multicast can be used to ensure that transactions are quickly broadcast throughout the M - net, and then all M - nodes can focus on transferring the transactions to other nodes within the blockchain network.

[0032] A multicast network architecture enables the simultaneous distribution of data to a group of destination nodes without data duplication for each node interested in receiving the information. If a node wishes to receive multicast transmissions, the node joins (registration phase) the multicast group and will then be able to receive all data transmitted on the multicast group. IP multicast can scale to larger groups of receivers by not requiring prior knowledge of how many receivers there are, and by requiring the sender to transmit the packet only once, the network infrastructure is used efficiently. Due to the nature of the multicast network, the use of connection-oriented protocols (such as TCP) is not practical due to the simultaneous communication with a large number of other nodes. Therefore, connectionless protocols are used.

[0033] Some blockchain networks such as Bitcoin use TCP for node - to - node communication. Data packets sent using TCP have associated sequence numbers that are used for ordering purposes. In addition to this, the TCP protocol involves a three - way handshake procedure both when establishing a connection and when terminating a connection. Packets sent over TCP have associated overheads; they carry sequence numbers and there is also the three - way handshake protocol. When establishing a connection, 128 - 136 bytes are sent, while closing a connection takes 160 bytes. Thus, the handshake in packet transmission takes up to 296 bytes. Further, when a node receives a new transaction, that node notifies other nodes with an inventory message (INV) that includes the hash of the transaction. A node receiving an INV message checks whether the hash of that transaction has been seen before, and if not, that node will request that transaction by sending a GETDATA message. The time required to transmit a transaction from node A to node B is T1 = verification+TCP(inv+getdata+tx), where TCP() represents the overhead introduced by the TCP handshake procedure in terms of time.

[0034] The M nodes can be configured to use TCP for communication with other nodes, which is enforced by existing protocols such as Bitcoin. However, they may use a connectionless protocol such as the User Datagram Protocol (UDP) for communication from M node to M node or, more preferably, for communication from an M node to multiple M nodes in a multicast situation. Unlike TCP, UDP does not involve a handshake protocol, and thus, the M nodes can propagate transactions more quickly. This also allows malicious nodes to be prevented from connecting other nodes by sending repeated INV messages without ever sending an actual transaction.

[0035] The lightweight nature of UDP is associated with certain trade - offs. There is less error checking present and no error recovery. In some implementations, these limitations of UDP can be overcome at the application level by implementing error recovery, ordering, and re - transmission as application - layer functions. Placing error checking at the application level removes overhead from the network.

[0036] In one example scenario, a normal node on a blockchain network generates a transaction that is desired to be processed via an M network, such as a merchant-based payment. The node sends the transaction to an M node, and the M node may broadcast it to other M nodes using multicast, or, if the node knows the IP multicast address of the M nodes, it may send the transaction directly to multiple M nodes. In some examples, all M nodes of the M network are members of a single multicast address, and thus all transactions sent to that address are received by all M nodes, but in some cases, there may be two or more multicast addresses associated with the M network, and the receiving M nodes can evaluate from the routing information whether further broadcast of the transaction to other multicast addresses is necessary to propagate the transaction across the entire M network.

[0037] Multicast helps ensure fast initial propagation of new transactions to all M nodes, but multicast solutions do not necessarily address the scalability issues of the blockchain network resulting from increasing transaction throughput. Typically, each node in the network maintains a mempool that includes unapproved transactions that it has seen and that have not yet been incorporated into the blockchain by a miner completing proof-of-work. A large growth in the number of transactions resulting from payment processing increases the amount of transactions stored in each mempool. Thus, while nodes within the M network can receive new transactions almost simultaneously, they may have storage capacity limitations regarding the large and rapidly changing mempool.

[0038] To address this problem, instead of using multicast, the M node may use a shared memory pool implemented by a Distributed Hash Table (DHT).

[0039] Assuming an average transaction (TX) size of 500 bytes and a transaction rate of ~10 4 TX / s, the M network may receive ~400 GB of incoming data per day. All of this data needs to be stored in the memory pool of unapproved transactions for a variable amount of time. Therefore, the M network requires significant storage and the ability to store data quickly. To avoid placing excessive demands on each individual M node, the M node implements shared memory relying on DHT. Instead of having each M node hold all incoming TXs in its own memory pool, each M node stores only a specific percentage of the whole, as well as the hashes and associated key values of the remaining part.

[0040] DHT is a class of decentralized distributed systems that enables the partitioning of the membership of a key set among nodes and can send messages in an efficient and optimized way only to the owner of a given key. Each node in the network can be viewed as a cell in an array of hash tables. DHT is designed to manage a large number of nodes, allowing new nodes to join the network and old nodes to leave and fail without compromising the integrity of the shared data. DHT guarantees decentralization (no central authority or central coordination), scalability (the system behaves efficiently with millions of nodes), and fault tolerance (the system is reliable and can manage nodes that join, leave, and fail in the network). Each node in the network only needs to remain in contact with a few other nodes, so the network does not become overloaded in the presence of data changes or new pieces.

[0041] The same concept can be applied to the UTXO database, which is a database containing the set of all unspent outputs on the blockchain. The UTXO database can be constructed using a DHT to share content among a set of nodes.

[0042] There are numerous possible DHT architectures and protocols that can be used to implement a shared mempool for the M network. One example is Pastry(TM), but there are many others. Pastry(TM) is a protocol designed to maintain an overlay network that can store and transfer information on a distributed system. Each node in the Pastry(TM) network is assigned a 128-bit identifier, which is used to indicate the node's position within a circular node ID space (ranging from 0 to 2 128 -1). The ID is randomly assigned when the node joins the network. Each node maintains a routing table, a set of neighbors (neighborhood), and a leaf set.

[0043] One factor to consider when sizing a robust DHT is the number of replicas required to ensure the overall robustness and reliability of the network. As already mentioned, multiple nodes can join and leave the network, and this should not affect the availability of data. If the node storing transaction A leaves the network, another part of the network needs to be able to find transaction A. In existing blockchain networks such as Bitcoin, the network has a number of blockchain replicas equal to the total number of nodes in the network (on average 5000 replicas), but this affects scalability.

[0044] In one configuration of the M network, the mempool is not completely replicated at all M nodes. Instead, it is implemented by a DHT. To provide reliability, the DHT can be implemented to have some redundancy, i.e., each transaction data item is replicated at two or more M nodes, but not all M nodes. As an example, the DHT can be implemented to specify a minimum of two replicas. This results in a probability that two nodes will go down simultaneously within any given hour, which, assuming complete independence between nodes, is (1 / (24×365)) 2 =130×10 -8 which is

[0045] The process of storing a new transaction in the distributed mempool can, therefore, have the following steps in which the distributed mempool is implemented using the DHT. The process includes a node sending a transaction to an M node. The M node hashes the transaction or transaction ID, depending on the implementation, to obtain a key value. The key value indicates the M node or nodes (in the case of replicated data) where the transaction should be stored. The M node then stores the transaction in the distributed mempool, which includes routing the transaction to the correct M node or nodes where the transaction should be stored based on the key value and the assigned ID of the M nodes within the M network. The M node may receive an acknowledgement depending on the DHT protocol involved. When an M node receives a new transaction from a normal node, the M node may perform certain verification operations to verify the authenticity of the transaction.

[0046] By hashing the transaction, a key for the transaction can be generated. The key can indicate where in the DHT the transaction should be stored, which can be a node other than the current M node. The M node then evaluates whether the transaction already exists within the operating DHT. Each M node has a portion of the stored transactions based on the division of the key space among the M nodes that make up the M net. In some configurations, the key space is divided among the participating M nodes. The division can involve duplication to create replication for network resiliency. For example, in some implementations such as using Pastry(TM), each M node is assigned a unique key or ID number, and the transaction can be stored at the M node or multiple M nodes (if replication is desired) based on proximity to the key value of the transaction. The M node can have the stored portion of the transaction locally and have the hash or key value of the remaining portion. Thus, the M node can evaluate during operation, based on local data, whether a new transaction exists within the DHT.

[0047] If the transaction does not exist within the DHT, the M node stores the transaction in the DHT during operation based on its key value. In a general sense, this can take the form of a put(k,tx) operation, where k is the key value and tx is the transaction. The applicable DHT routing protocol ensures that the transaction is sent to the appropriate M node(s) and stored there. The DHT can operate according to various protocols regarding the distributed hash table depending on the selected implementation. The use of the DHT for storing transactions in the M net avoids the use of INV / GETDATA messages within the M net for routing transactions to all M nodes.

[0048] In operation, the M node can send transactions to normal nodes within the blockchain network according to the normal transaction transfer protocol of the blockchain network in this example. For example, communication with normal nodes can use TCP for node - to - node connections.

[0049] In one configuration, the M node includes a processor, a network interface, and a memory. The M node can be implemented using any suitable computing hardware having network connectivity and sufficient processing resources and memory resources to execute the functions described herein. The M node may include processor - executable instructions for implementing the functions described herein. In some cases, the processor - executable instructions may be referred to as a blockchain merchant node application, but it should be understood that these instructions may be implemented in one or more modules, applications, scripts, or other programming structures depending on the hardware and operating system. The processor may include a multi - core processor and / or multiple processors.

[0050] The memory stores data including an assigned portion of a DHT - based mempool that is partially based on its DHT key value, i.e., the M node ID. In this implementation example, the memory further stores a routing table, a neighbor set, and a leaf set. The routing table includes a list of specific routing destinations within the M network. When a node receives a packet of data, the node refers to the routing table to know where to send the data. The routing table may also include information about how far each destination is from that M node. The neighbor set includes information about nearby M nodes, for example, based on a proximity metric (ping latency). The leaf set includes numerically close M nodes. Two M nodes are numerically close if their key values (node IDs) are numerically close. The memory further includes an M node reputation table, as further described below.

[0051] To provide scalability, in addition to implementing the mempool using DHT, M-net enables nodes to join the M-net. A new node needs to have the addresses of at least one M-node that is already part of the M-net so that it can direct its participation request to one of the M-nodes. The M-node can perform certain verification actions that may involve querying the new node. For example, the M-net may have a set of minimum criteria related to joining the M-net that are defined for the M-node. By way of illustration, the criteria may include the minimum available processing resources, or the minimum available free memory, or the connectivity requirements.

[0052] Assuming that the M-node has completed any verification operations performed to verify the new node, the M-node then transfers the joinrequest() to the DHT according to some DHT protocol that governs the operation of the DHT. The DHT then communicates with the new node and provides it with a routing table, a key value (node ID), and other data that enables the new node to function as a new M-node on the M-net.

[0053] It is understood that the ease with which a node can join the M-net creates the vulnerability that malicious nodes may be able to join the network. To identify and isolate potential malicious nodes, one configuration provides for the M-node to store an M-node reputation table that is used to track and update node behavior rankings. When a new node joins the network, it can be added to the M-node reputation table as indicated by the node ID field. This table may further include the join time in some implementations. This table further includes a score or evaluation regarding that M-node.

[0054] The score can be adjusted up or down based on specific behavior metrics. For example, if an M node fails to transfer a transaction, remains silent for a certain period, floods the M network with traffic determined not to be a transaction, or otherwise engages in negative behavior, its ranking can be decreased or reduced. If a node's score falls below a preset minimum value, that node can be excluded from the M network.

[0055] The M node reputation table maintained by a specific M node may be limited to tracking the scores of its neighbors rather than the entire M network. Thus, when a new M node joins the network at time t, the M node reputation tables of its neighbors do not contain any information about the new node, but from time t, they start building the reputation of the new node by storing information in the node registration table. For example, if the new node is a silent node, i.e., it does not transfer the information it receives on the network, all its neighbors start recording this behavior in their respective M node reputation tables, for example, assigning a negative value to the ID of the new node. After a certain time t + n, if the M node reputation tables of all the nodes aware of the new node contain negative values, those nodes may decide to isolate the new node and expel it from the network.

[0056] Transactions within the distributed memory pool of the M network may have to wait for a significant period before being approved, i.e., before being incorporated into a block added to the blockchain and approved. A block is considered "approved" when a sufficient number of subsequent blocks have been added to the blockchain above it, such that it becomes computationally infeasible to reverse the growth of the chain and remove that block to change to a different branch, i.e., a fork.

[0057] Due to the size and flexibility of the mempool and the volume of transactions, a given transaction may not be approved for a longer period of time in some blockchain implementations such as Bitcoin. In traditional Bitcoin implementations, a transaction is removed from the mempool as soon as it is incorporated into a block. This means that if the block ultimately becomes an orphan block, all the transactions within the block are resent on the network. This can be difficult to achieve or can cause long delays in approving specific transactions in the case of a high-speed transaction network.

[0058] Accordingly, in some implementations, the mempool may track the number of approvals of the block in which the transaction was incorporated, i.e., the number of blocks added to the blockchain following the block in which the transaction was incorporated. The transaction is only removed from the mempool after a predetermined number of approvals have occurred. This predetermined number can be 4, 5, 6, 7, or any suitable number in a given implementation. The data entry in the mempool can be structured to include a transaction ID field, a transaction field, and a number of confirmations (NoC) field. In another implementation, rather than tracking the NoC, the mempool data entry may simply record the block number. From the block number, the number of approvals that have occurred can be calculated based on the current block number of the blockchain.

[0059] Once the required number of approvals has occurred, the transaction can be safely removed from the mempool. Thus, there is no transaction loss in the case of an orphan block, and the transaction will be permanently removed after the required number of approvals.

[0060] The solution described in the following part of this specification utilizes an improved type of high-speed verification node as described above. A new full-node configuration is described, which is effectively an M-node verification architecture enhanced with large-scale storage capabilities and an improved operating protocol. The M-node and the storage node together form the core of the new full-node. The new node structure is described in detail, including the necessary technical requirements and technical solutions, and a sustainable incentive model is provided.

[0061] Block Size and Storage Requirements The current block size is 1 Mb. Currently, a block consists of fields including a so-called magic number (always the same value), a value indicating the actual block size, a so-called block header, the number of transactions included in the block, and finally a list of actual transactions. The latter always starts with a coinbase transaction, which is a transaction containing the reward for mining the block. The overall structure of the block is shown in Figure 1.

[0062] The block header consists of: 1. Version number (4 bytes) 2. Hash of the previous block header (32 bytes) 3. Merkle root hash (32 bytes) 4. Timestamp (4 bytes) 5. Target threshold (encoded as nBits - 4 bytes) 6. Nonce (4 bytes) and includes.

[0063] Currently, a block contains approximately 2000 transactions, and blocks are being mined approximately every 10 minutes (the 10 - minute block time was set as a compromise between the initial approval time and the time wasted in chain splits). This provides a transaction rate of approximately 3.5 transactions per second, as opposed to a theoretical maximum of 7 transactions per second. In contrast, VISA operates at a rate of approximately 10000 transactions per second and can reach over 50000 transactions per second.

[0064] Clearly, in order to create a competitive payment system, it is necessary to bypass the current constraints in some way. Since the 10 - minute block time is well - established, it is essential to consider changes to the block size and, by extension, the blockchain itself. In this document, for example, a scalable solution that could handle approximately 50000 transactions per second will be described.

[0065] Incrementing the current block size, or even completely removing the limit, has been much debated and has sometimes been a controversial topic. There seem to be strong arguments on both sides, as both maintaining the current size and increasing it have significant benefits and trade - offs.

[0066] Assuming a transaction rate r, the required block size can be calculated. Here, assume a (mean) block time of 10 minutes. Thus, if T(r) is the number of transactions per block,

Equation

Equation

Number

[0067] This leads to storage requirements of O(10 6 ) Gb / year instead. It is quite obvious that for blocks of this size, slightly different approaches are required for both block propagation and storage. Table 1 below shows the relationship between the transaction rate, average transaction size, block size, and the amount of monthly and annual storage space required.

Table 1

[0068] New Bitcoin Network We show the architecture we propose for the Bitcoin network in Figure 2. This shows an operation diagram that depicts the steps from when a user initiates a transaction until it is completed on the blockchain.

[0069] A system is provided where a special plurality of verification nodes (which maintain and manage shared memory among themselves via a distributed hash table DHT) receive transactions, verify them, and assign them to a mempool. And these verification nodes provide their services to miners by providing a list of valid transaction hashes. Miners attempt to assemble a pre-block (block skeleton) based on those hashes and solve a hash puzzle. When a solution to the puzzle is found, the winning miner sends the block skeleton back to the verification nodes. These verify the block and ensure its storage. Initially, it would be possible and appropriate for the verification nodes to store the blocks themselves. When the block size finally exceeds a certain threshold in size, the verification nodes will either a) expand their own storage capacity or b) outsource the storage to specialized storage nodes. These two architectures are described later in this specification.

[0070] New full node At a block size on the order of O(10)GB, it no longer seems feasible to rely on a PC - type node to provide the storage capacity to host the entire picture of the blockchain. Instead, a facility that provides O(1)PB or more storage is required (see Table 1). In that case, it becomes a challenge to create a system that accommodates new blocks while maintaining the distributed, decentralized, and trustless nature of the network.

[0071] Two types of full - node structures and combinations of those two types are conceivable.

[0072] 1. Verification nodes with an attached petabyte - scale storage rack 2. Verification nodes with an attached storage pool based on an internal decentralized distributed peer - to - peer (P2P) single - node network, similar to the current Bitcoin network itself. 3. The combination of 1 and 2.

[0073] The proposed solution attempts to solve the problem of constantly maintaining a decentralized and non - centralized record of the blockchain by introducing nodes similar to the so - called full nodes operating on today's Bitcoin network. In contrast, it has the ability to scale as the size of the blocks and the number of transactions grow.

[0074] This difference is not limited purely to structurally related hardware problems. In contrast to home - PC - based full nodes that operate during writing, the new nodes proposed here are specialized nodes. They will require a significant amount of investment, and thus, the incentives will be very different. In a scalable paradigm, both M nodes (verification nodes) and new full nodes (a combination of verification and storage nodes) will expect compensation for their services.

[0075] At the opposite extreme within the range, we have a decentralized distributed storage solution mostly composed of individual nodes. Good examples are Storj (Wilkinson et al., 2016), Sia (NebulousLabs), and MaidSafe (maidsafe). In the case of Storj, its functionality is based on participants receiving rewards for providing storage space.

[0076] As described, it is also possible to envision supernodes that consist of both petabyte (Pb) racks and peer - to - peer (P2P) storage systems.

[0077] Since the Bitcoin ecosystem heavily relies on the existence of multiple replicas of the entire blockchain distributed in a decentralized manner, it becomes clear that it is important for all full nodes to be compensated. This is significantly different from mining, which is basically a game where the winner takes all the prize money. Miners will aim to hit their (winning) blocks to reach the public blockchain, so it is in the miners' interest to be rewarded for storing full nodes.

[0078] Nodes group into pools that function as supernodes. To maintain the decentralization of the blockchain, a certain number (≧100) of such supernodes must exist. Supernodes are connected to each other but do not overlap.

[0079] Technical Requirements As described, there are two overall different architectures to consider when discussing new full nodes (see Table 2).

[0080] New full nodes need to maintain and manage two types of storage: 1) Distributed Hash Table (DHT) memory / storage like Random Access Memory (RAM) for the mempool, 2) Storage like a persistent tape / disk for the blockchain.

[0081] As described, at a transaction rate r = 50000 Tx / s, a block is expected to be O(10) Gb, which means an annual storage requirement of ~365×24×6×15 Gb = 7.9·10 5 Gb = 0.8 Pb / year (see Table 1).

[0082] Table 2 shows a comparison between current full nodes and future full nodes.

Table 2

[0083] At the same time, the rack / cluster needs to maintain and manage the mempool. This will enable fast block restoration. The required size of the mempool is more difficult to calculate. Currently, with a block size of approximately 1 megabyte (~1 Mb) and approximately 4 transactions per second (~4 Tx / s), the total size of the transactions waiting in the mempool fluctuates between 2 and approximately 70 megabytes (~70 Mb). Figure 3 is a graph showing the total size of the transactions waiting in the mempool for approval.

[0084] As shown, we assume two fundamentally different structures capable of storing large amounts of data, and combinations thereof. These two structures are shown in Figures 4 and 5. Figure 4 shows a configuration having multiple nodes with access to an internal centralized storage institution. Figure 5 illustrates a configuration where each node is part of both a distributed mempool and a distributed storage institution. The architecture shown in Figure 4 seems suitable for a relatively large entity that owns and maintains several verification nodes, and all of these verification nodes have access to the entity's own storage institution. In contrast, the architecture shown in Figure 5 is completely decentralized. This is a suitable solution for individual nodes, such as a home-owned PC with sufficient storage capacity, that wish to participate in a shared distributed storage pool. The underlying storage technology used for this already exists (e.g., Storj, Sia, MaidSafe).

[0085] One way to visualize how a new full node fits into the Bitcoin network is shown in Figure 6, which shows a network configuration where the verification nodes are members of a storage pool. These pools together form a decentralized distributed Bitcoin network.

[0086] Full Node Operation In the large block scenario, one faces another situation, not just for space requirements. The mempool should be able to accept an equivalent amount of blocks, i.e., approximately 15 gigabytes (~15 Gb), preferably the equivalent amount of the next mined block. This is also combined with the overhead that needs to be addressed.

[0087] 1) The mempool needs to synchronize with other verification nodes. This involves exchanging an Invertible Bloom filter Lookup Table (IBLT) (Michael T. Goodrich, 2011) 2) The IBLT needs to be audited and missing transactions (Tx) are searched for 3) Additional searched Tx need to be verified 4) Assembly of blocks based on the block skeleton received from miners or other full nodes.

[0088] New full nodes keep the latest mempool. They do this by means of IBLTs exchanged with miners, other verification nodes, and new full nodes.

[0089] A miner sends a block skeleton (tuple) composed of 1. Nonce n 2. IBLT 3. Coinbase transaction Based on this, new full nodes sort the transactions appropriately (according to a specific rule set) and assemble newly mined blocks. The new full nodes then proceed to store the blocks in their own storage and propagate the skeletons to other new full nodes. The protocol will be described in more detail later in this specification.

[0090] Incentive

[0091] Incentive One important feature of the specific configuration is to incorporate into the system incentives that encourage the provision of new node structures and services. Incentives are necessary due to the significant costs associated with storing the blockchain. Figure 7 shows the functions of the new full nodes. The new full nodes receive rewards mainly for the following two types of services: 1) Edit the list of verified transactions and prepare for mining. Then, the hash value (Merkle root) of the transactions is sent to the miner who selects the list to mine the block; 2) The winning miner sends the skeleton of the mined block to several new full nodes. The skeleton includes the coinbase transaction, which includes: a. Mining reward b. A secret that is part of the commitment scheme used as a payment mechanism for providing the verified list c. Payment for block verification and / or storage of blocks on the blockchain.

[0092] [Transaction] The verification node will be paid for verifying the transaction by the fee system. The receiving verification node / new full node will receive rewards for one or more of the following: 1) Providing the miner with a list of verified transaction (Tx) hashes (see b. above) 2) Reassembling the block from the block skeleton ("flat rate" fee) 3) The size of the block (payment in "1MB storage" units).

[0093] The incentive is at the 100-block approval time T 100 as follows: 1) The miner needs to wait for t~T 100 to claim the reward 2) The verification node needs to wait for t~T 100need to wait over 3) The new full node needs to wait from t to T before receiving the block assembly fee and size-dependent storage payment. 100 need to wait over

[0094] Therefore, the 100-block approval time will provide the incentive for the miner to propagate the skeleton block (including payment) to a range of new full nodes, and the new full nodes will receive the incentive to propagate the skeleton block to other new full nodes.

[0095] Also, it should be noted that the miner can freely choose the list (of transactions) that it wishes to include in the block. Therefore, we assume a market composed of competing verification nodes by editing the list of verified transactions that the miner can select from the commitment transactions and purchase with them.

[0096] Mining Revisited The Bitcoin ecosystem relies on the process of mining. Miners collect transactions (Tx) from the mempool (or, as assumed here, specialized verification nodes), compile them into blocks, and attempt to find a solution (nonce) to solve the hash puzzle. The block header contains the hash of the previous block on the blockchain, the root of the Merkle tree of the transactions, and the nonce included by the miner. Solving the puzzle consists of calculating the double SHA256 hash of the nonce (repeatedly selected) concatenated with the previous block hash and Merkle root, and checking if it is less than the so-called difficulty target. If it is below, the puzzle is solved; if it is above, iterations continue over multiple nonces. This remains unchanged even in the new paradigm. The challenges are the increased block size and the distribution across the network of the mined blocks. With blocks of Gb size, it may not always be possible to broadcast the entire block on the network.

[0097] Instead, we propose a solution that follows these steps: 1. Miners receive a list of verified transactions from verification / M nodes and / or new full nodes 2. The miner may or may not use its own mempool of Tx hash values, which follows specific ordering rules. Examples of such ordering are given at [https: / / www.cryptocoinsnews.com / bitcoin-in-bloom-how-iblts-allow-bitcoin-scale / ] 3. Miners solve the hash puzzle by determining the nonce n 4. Next, a hash tree (Merkle tree, referred to here as HT) is calculated and the root of the stored tree is computed (see the next section) 5. Using this list of Tx, an IBLT is created. The IBLT can be used to calculate the difference in content between two sets (e.g., the mempool) and to reconcile the two sets. 6. The tuple {n; IBLT; coinbase Tx; HT root} is broadcast to the verification / M nodes. 7. New full nodes operate the DHT of the mempool and the storage of the blockchain. 8. The pool reassembles the blocks based on the tuple {n; IBLT; coinbase Tx; HT root} and records the blocks on the blockchain either by a) storing them itself or b) storing them on a specialized storage node.

[0098] Avoidance of Race among Miners Miners will be able to select a list of verified transactions from a market composed of several verification nodes. In the absence of specific instructions, it is fair to assume that miners will select the list that maximizes their potential revenue. Attentive readers may note that this could lead miners to mainly select the same list from the same nodes. This would, in turn, result in a situation where several miners try to mine the same block and race against each other. This would work to the advantage of the miner(s) with the most hash power.

[0099] We propose adding an additional field to the block header. This field contains a random number selected by each miner. This ensures that each miner starts from a different starting point and thus prevents the solution of that block from simply boiling down to hash power. This will, in turn, mimic the current situation where miners tend to mine slightly different but similar blocks that they have selected individually.

[0100] Protocol Here, we describe the protocol necessary to operate new full nodes.

[0101] For the proposed system to function, the mempools of the participating nodes (validators, miners, new full nodes) should follow the ordering rules regarding transactions. Here, we propose to use the canonical ordering proposed by Gavin Andresen. There, the ordering was related to the list of transactions within a block, but here, we present the idea that all validation nodes and new full nodes use the same rules in their mempools.

[0102] The rules can be summarized as follows: 1) Sort the transactions in ascending order with respect to the previous transaction hash 2) Add the first transaction from the sorted list that does not depend on later transactions.

[0103] As seen before, a block contains the so-called Merkle root hash. It is generated by hashing all the transactions including the coinbase transaction and then hashing the concatenation of the hashes until the Merkle root hash is reached. It becomes clear that without the fact that the miner is generating the coinbase transaction, the validation nodes can calculate the entire Merkle tree and thus the Merkle root and its corresponding hash.

[0104] Here, we propose a Merkle tree calculated as follows by a certain procedure: The validation node calculates the Little Merkle Root. This procedure has several exceptions: 1) The coinbase transaction is omitted 2) The so-called commitment transactions are included 3) The minor generates a coinbase transaction, concatenates it with the little Merkle root hash, and it produces the Merkle root hash Except for , it is the same as when calculating a standard Merkle root.

[0105] This is shown in Figure 8, which illustrates the new Merkle tree structure. Note that this constitutes a change to the current protocol.

[0106] Changes to the block header As described, we propose to add an additional field containing a nonce selected by the miner to the block header. Therefore, solving the hash puzzle changes as follows:

Number

[0107] Verification → Miner Verification node: · Upon request, the verification node (which may or may not be a new full node) prepares a list of verified transactions to be mined; · The verification node creates a commitment transaction; · A so-called little Merkle root (see the previous subsection) is calculated including the commitment transaction; · The verification node has two IBLTs: 1) For all transactions within the block (IBLT1), and 2) For all corresponding TxIDs within the block (IBLT2) Prepare them; · The verification node sends to the miner: 1) The little Merkle root 2) IBLT1 3) IBLT2 (optional - only if the miner is operating on its own TxID / mempool) 4) The previous block hash 5) The hash checksum of the above Send them.

[0108] Miner: · Upon receiving the data from the verification node, the miner proceeds to create the coinbase transaction. The coinbase transaction includes the reward for mining and the reward for the new full node's block verification / storage that wants to send the mined block. Additionally, the coinbase transaction includes an output field having a secret that matches the secret within the commitment transaction; · The miner uses the little Merkle root received from the verification node and combines it with the coinbase transaction to create the Merkle root hash; · The miner now has all the information necessary to start solving the hash puzzle; · Mining proceeds along the lines described above.

[0109] Miner → New full node Miner: · Once the block is mined, the miner sends to the new full node on the list the following: · The nonce (solution to the puzzle) n · The coinbase transaction · The block header · The Merkle root · The little Merkle root · IBLT1 · IBLT2 (Optional) · Hash checksum is sent.

[0110] New full node: · Check if appropriate rewards are within the coinbase transaction; · The node checks the consistency of the received data by calculating a checksum (hash); · The node approves the existence of transactions in the block in the mempool using IBLT1; · Query the mempool using IBLT1 and the node assembles the block. Then the block is stored (see sections on new full nodes and storage); · Data received from the miner is broadcast to other new full nodes.

[0111] Customized transaction list We assume a situation where the market of verified transactions will adapt to the needs of the miner. The miner tends to choose a list that maximizes its own possibilities, and the M nodes being verified capture such a tendency.

[0112] There may be cases where the miner may want to customize its own block by combining transactions from two or more lists. By calculating the difference between two IBLTs, it is possible to make setting adjustments between the two sets. The miner then sends back the IBLT containing the difference to one of the source nodes, thus extracting the information necessary to create a list containing all the transactions of both lists.

[0113] If the miner wants to edit its own list based on several lists, additional difficulties seem to be introduced. Here, we will briefly mention various points.

[0114] If a minor combines lists from various verification nodes, it is unclear how to combine the Merkle root. Here, we propose the following: Construct a big-endian Merkle root from the individual little-endian Merkle roots, and Combine the big-endian Merkle root with the coinbase transaction.

[0115] The additional costs are not proportional to the amount of transactions added to the list / block. Since it is fair to assume that those various mempools are quite overlapping, combining the lists will result in adding (relatively speaking) a small number of transactions from different lists. However, in order to combine the lists, the minor will have to "purchase" the entire list from each verification node (by means of a commitment transaction). Whether this will be a beneficial approach for the minor is unclear at this point.

[0116] Combining lists from several verification nodes requires a commitment between each of the minor and the providing verification nodes. One can imagine abuse of this system by the minor. Currently, there is no rule / protocol that all commitment transactions become blocks. One possibility is that the verification node checks each block and can reject the block containing its own transaction.

[0117] Overview of the structure and operation of the node Today's Bitcoin network is heavily centered around mining in terms of computational effort. As the transaction volume significantly increases, this may not necessarily be achievable. The solutions described in this specification lead to delegating various tasks to appropriately specialized nodes, making the miners themselves even more specialized. Editing the list of verified transactions, reconstructing and storing blocks based on the block skeleton are all functions that require a significant amount of resources. Therefore, it is expected that the structure of the Bitcoin network will change, and along with it, the incentives will also change. We describe these issues in detail in this specification.

[0118] The elements introduced in this specification include the following: · A new type of node structure, here called a new full node or super node, which may or may not be an extension of the verification M node: · The node operates with a protocol that effectively enables the broadcast of Gb-sized blocks both from verification nodes to miners and from miners to new full nodes; · Two overall storage structures for storing the blockchain, which may or may not be part of the proposed new full node; · An incentive model that enables the creation of a market for the pre-block list of verified transactions and the assembly and storage of blocks after mining; · A new Merkle tree structure that liberates miners from the need to maintain their own mempool; · The addition of an extra field in the block header with a random number selected by the miner to avoid the mining act becoming a pure hash-power-based race; · Verification receives rewards using special commitment transactions.

[0119] According to one implementation, a computer-implemented method for a node of a blockchain network is provided, the computer-implemented method comprising: Receiving mined data corresponding to a plurality of verified transactions from the blockchain network; Assembling a block based on the mined data; and Transmitting the assembled block to a storage entity for storage on the blockchain. The method includes the steps of:

[0120] Such a method enables a node to construct large blocks to be stored on a storage entity without requiring a miner to construct and store large blocks and transmit such blocks onto the blockchain network. Further, this architecture enables the use of a large-scale storage entity dedicated to storing a large and growing blockchain.

[0121] The computer-implemented method further comprises: Receiving a transaction from the blockchain network; Verifying the transaction received from the blockchain network; Maintaining a decentralized, non-centralized storage of the verified transactions with other nodes in the blockchain network; and Distributing data corresponding to the verified transactions to the blockchain network for mining data having a list of verified transactions. Each list can provide a complete list of verified transactions to be mined into blocks.

[0122] Such a method effectively removes the need for miners to perform the verification function while maintaining a distributed and decentralized storage of verified transactions with other nodes within the blockchain network. Further, this method enables transaction verification nodes to provide services to miners by preparing data corresponding to the verified transactions and distributing it to the blockchain network for mining. For example, this method enables a list of verified transactions to be prepared and distributed.

[0123] The step of maintaining a distributed and decentralized storage of verified transactions with other transaction verification nodes within the blockchain network may involve synchronizing transaction verification nodes on the blockchain network in order to maintain an up-to-date list of verified transactions in a decentralized and distributed manner. For example, verification nodes can be synchronized by exchanging reversible Bloom filter lookup tables. Verified transactions can also be sorted in a defined order such that a common ordering system is used across transaction verification nodes within the blockchain network in order to maintain a distributed and decentralized storage of verified transactions. For example, a canonical ordering system can be used to maintain a distributed and decentralized storage of verified transactions. It is understood that this is a particularly efficient way of maintaining a decentralized distributed storage while ensuring that transaction data across the network is maintained in a consistent manner.

[0124] The step of distributing data corresponding to verified transactions to a blockchain network for mining may include preparing data corresponding to a list of verified transactions (e.g., a reversible Bloom lookup table and associated data corresponding to the list of verified transactions, where the verified transactions are included in a block). Further, the step of distributing data corresponding to verified transactions to a blockchain network for mining may include creating a commitment transaction regarding a digital asset instead of providing data corresponding to a list of verified transactions to a miner. For example, a hash (Merkle) tree, a Patricia tree, or another type of radix tree can be calculated, including the commitment transaction.

[0125] After the data corresponding to the verified transactions is distributed and mined by solving a related cryptographic puzzle such as a hash puzzle, the mined data is sent back to the transaction verification node instead of being directly stored on the blockchain by the miner. This mined data can then be assembled into (large) blocks and stored on a storage entity specifically configured for storing large amounts of data and / or on a distributed storage system. As described above, this enables the verification node to construct large blocks stored on a storage entity without requiring the miner to build, store, and send such blocks onto the blockchain network. Furthermore, this architecture enables the use of large-scale storage entities dedicated to storing large and increasingly growing blockchains.

[0126] The mined data received from the blockchain network can include a block header corresponding to the verified transactions. The mined data can also include transactions regarding digital assets instead of assembling and / or storing blocks based on the mined data. Further, this method can include a requirement to wait for a period t associated with a minimum number of blocks prior to receiving the digital assets. This provides an incentive scheme for providing verification nodes. Because the provider will receive a reward for providing a list of verified transactions (e.g., in the form of a reversible Bloom lookup table) for mining and / or storing the mined blocks on the blockchain. Requiring a minimum period before receiving the digital assets gives miners an incentive to propagate the skeleton blocks (including payments) to a range of nodes, and the nodes will be given an incentive to propagate the skeleton blocks to other nodes.

[0127] The step of assembling blocks based on the mined data can involve, for example, assembling larger blocks using each block having a size of at least 2, 4, 6, 8, 10, 50, 100, 500, 1000, or 10000 megabytes. The upper limit will increase over time, but a nominal upper limit value of 1 petabyte may be specified. Each block can have, for example, at least 5000, 10000, 5000000, 1000000, 5000000, or 1000000 transactions. The upper limit will increase over time, but 10 per block 12A nominal upper limit value called a transaction may be specified. As shown above, the methods, nodes, and blockchain network architectures described herein enable large blocks to be constructed and stored on storage entities without requiring miners to construct and store a large number of transactions. This enables the system to handle a significantly increased transaction rate.

[0128] In the method described herein, a block can be modified to include a block header containing a random number provided by a miner. That is, when a transaction verification node receives a solved transaction from the blockchain network, it can be configured to process a block that includes a block header containing a random number provided by a miner. This constitutes a change to the block header, whereby the miner can either select or randomly generate the number inserted into the block header. This helps ensure that miners do not compete to mine the same block even when the same transaction list is selected by multiple miners.

[0129] The storage entity that stores the data of the large block described above can be shared among multiple transaction verification nodes on the blockchain network, and these multiple transaction verification nodes form supernodes on the blockchain network. The shared storage entity can be either a common storage node, distributed storage, or a combination of the two. This architecture leads to the formation of supernodes on the blockchain network and enables the provision of a dedicated storage institution that stores the blockchain and provides services to the blockchain network.

[0130] In view of the above, supernodes of the blockchain network are also provided, and the supernodes are: a plurality of verification nodes as described above, and A shared storage entity for storing a blockchain, and having the shared storage entity is either a common storage node, distributed storage, or a combination of the two, blocks assembled by a plurality of verification nodes are sent to and stored on the shared storage entity, whereby the shared storage entity maintains and manages the blockchain.

[0131] This architecture is better suited to handle the large block sizes required to achieve the desired increase in transaction rate that is the aim of the methods and configurations described herein. For example, the shared storage entity can be configured to have a storage capacity of at least 100 gigabytes, more preferably at least 1, 10, 100, or 1000 terabytes. The upper limit will increase over time, but a nominal upper limit value of 10 6 terabytes or even 10 6 yottabytes may be specified.

[0132] With respect to the overall network architecture, a blockchain network having a plurality of such supernodes can be provided. The supernodes can be connected (but not duplicated) on the blockchain network, and the shared storage entity of each supernode is configured to store a copy of the blockchain. The supernodes effectively have a group of nodes that form a pool functioning as supernodes. To maintain the decentralization of the blockchain, advantageously, a certain number (e.g., at least 10, 50, 100, or 1000 and optionally less than 100,000,000) of such supernodes should exist.

[0133] Bloom filters and IBLTs In this section, we summarize the properties of so-called Bloom filters and their extensions called reversible Bloom lookup tables.

[0134] In its simplest form, a Bloom filter is an array. The array has two associated parameters, M and k. M is the number of bits in the array, and k is the number of different hash functions H k . [Number] , where S 16 is the space of hexadecimal strings on which the hash function operates. To determine whether a transaction T X0 belongs to the set for which the Bloom filter was created, we need to calculate H 1 (T X0 )...H k (T X0 ) and then check whether the corresponding bits are set to 1 in the array. Figure 9 shows the workflow for creating a Bloom filter.

[0135] If one or more are not, then T X0 is definitely not in the queried set. However, Bloom filters allow false positives. This is because the probability that a hash function changes a bit to 1 is p = 1 / [array size] = 1 / M. Therefore, so-called [Number] means that for a given hash function, the bit may not be set to 1.

[0136] Therefore, if there are k hash functions, the probability that a given bit is not set to 1 is [Number] . If we need to insert n such elements, this is

Number

[0137] One obvious drawback of Bloom filters is that they do not track or maintain a specific order. It becomes immediately apparent that if one wishes to maintain an indexing of the items to be filtered, it is necessary to extend the functionality of the filter. This is where Invertible Bloom Filters (IBFs) and Invertible Bloom filter Lookup Tables (IBLTs) come in.

[0138] Instead of just activating the bits of the array, the XOR sum of the key, the hash value (as before), and the global counter are stored in each field of the IBF. This procedure is illustrated in FIG. 10, which shows a workflow that illustrates how transactions are encoded in the IBF / IBLT.

[0139] Application Each maintaining the memory pool m 1 and m 2 Assume there are two nodes N 1 and N 2 Each memory pool contains elements from the population of the hexadecimal string S 16 Furthermore, assume that the memory pools follow the ordering rules proposed by Andresen and previously outlined herein.

[0140] Here, N 1 sends m 1 to N 2 and N 2 can now approach set adjustment in two ways.

[0141] 1) Δm = m 2 - m 1Calculate the set difference (see (David Eppstein, 2011), (Michael T. Goodrich, 2011)); 2) m 2 Iterate over the transactions in m and check if they are present in N 2 's mempool.

[0142] We understand that IBLT can be used for at least two purposes: 1) Assist nodes in assembling mined blocks based on the transactions they already have in their own mempools and identify and retrieve those they do not have; 2) Maintain a certain level of synchronization between mempools belonging to different nodes.

[0143] Pruning of the distributed mempool As described above, the future of blockchain technology such as Bitcoin, for example, depends at least in part on the proposal of new architectures that can increase the amount of transactions issued per second. One requirement for such new architectures is to remove the current limitations on block size. In this scenario, local memory pools cannot provide sufficient storage capacity, and therefore, it is necessary to design new models for distributed memory pools (DMPs). The improved architecture for the management of distributed memory pools provides the following features: Global consensus on the validity of transactions stored in the distributed mempool; Consistency and completeness of the stored information; Fast read and write processing; and Security mechanisms against routing and storage attacks in the distributed mempool.

[0144] Once a transaction is included in a newly mined block, the corresponding copy in the DMP may no longer need to be stored. In this section, we extend the previous architecture by providing a protocol for the secure removal of transactions from the DMP.

[0145] We present an overview of the provided DMP architecture and distributed hash table (DHT) operations. We also introduce a new mechanism for reaching a distributed consensus regarding the pruning of transactions within the DMP. Additionally, multiple different policies for resolving data inconsistencies within the DMP are presented, and those policies are: Transactions can be marked as being deleted but can still be locally stored at the mempool nodes; The same transaction can be marked as being deleted at one mempool node but can still be available at another mempool node; Blockchain reorganisation may require the preservation of transactions that were previously removed from the mempool.

[0146] Individual nodes in the current Bitcoin network can be viewed as a cluster of nodes that provide a distributed memory pool (DMP). The proposed DMP relies on a distributed hash table (DHT) structure deployed over a network composed of individual trust relationships between honest nodes. The set of node connections is built on top of both a set of routing information and application-level information. There is no involvement of a central authority in the issuance or preservation of trust certificates, and each node maintains and manages a record of its own trustworthy peers.

[0147] In order to carry out some form of attack, a malicious entity needs to participate in the network. For example, the Sybil attack focuses on the creation of a large number of fake identifiers to damage the system [John R. Douceur, The Sybil Attack, First International Workshop on Peer-to-Peer Systems, Springer-Verlag, London, 2002]. Sybil nodes connected to the network can block or delay legitimate routing queries and spread incorrect routing information. The DHT routing protocol described here has approximately linear (sub-linear) time and space complexity and is based on the following assumptions: Nodes cannot distinguish between honest nodes and malicious nodes; The majority of honest nodes have more connections to other honest nodes; and Each node is responsible for storing information about the partitioning of the key space.

[0148] The DHT protocol provides two main functions: UPDATE() is used to build a routing table and insert keys at each DHT node; and GET(x,k) is used by DHT node x to find the target key value record represented by key k.

[0149] Each DHT node x is usually identified by the public key P x and the current IP address addr x . This information is securely linked to the record sign x (P x ,addr x ), where sign x () represents a signature with the corresponding private key. And the node ID is stored in the DHT using the signed record. When a node changes location or receives a new IP address, a new record [P x ,addr xIt must be stored in the DHT. A malicious node may insert an incorrect key - value pair. The GET method has the responsibility of verifying the signature within the returned key - value record.

[0150] The data routing network can be represented by an undirected graph. Malicious edges connect malicious nodes to honest nodes, and honest edges connect two honest nodes. Creating any number of Sybil identifiers can be computationally affordable for malicious entities, but creating a malicious edge requires convincing an honest node to establish a trustworthy link to one of the Sybil - managed identifiers. Without the existence of a sparse cut that divides the honest region into two, a short random walk starting from an honest node is likely to end at an honest node.

[0151] The routing table of a node can be constructed by starting independent random walks within the network. The node collects one or more random key - value records from the receiving nodes of each walk. This routing information is used during lookups, and when the local table does not contain the key, a lookup message is multicast to a set of nodes. It is likely that one or more receiving nodes locally store the key - value record queried. No direct requests are sent to the tables of other nodes. Thus, a malicious node cannot arbitrarily increase the number of incorrect entries in the remote tables.

[0152] To prevent malicious nodes from forcefully finding the desired output and inserting a wrong key between two honest keys, keys are not stored in the shared space using a deterministic function such as a hash. Therefore, a function for measuring the distance between two keys is not defined. Each node x constructs a long-distance routing table that contains pointers to other nodes with IDs uniformly distributed across the entire key space. The pointers are stored by starting a random walk and collecting random IDs from the end nodes. The short-distance routing table contains key-value records. These keys are the ones closest to the node's ID according to a predefined ordering.

[0153] This routing structure can (a) manage node failures, i.e., the redundancy in the routing table provides an alternative path for retrieving key values; (b) manage key changes, i.e., the addition or deletion of keys leads to inconsistencies between the key distribution and the distribution of long-distance pointers in the DHT space; and (c) manage changes in network connections, i.e., the addition or deletion of trusted connections does not affect routing performance as long as the sparse cuts do not divide the honest network and the endpoints are not malicious. The synchronization and availability of new keys are provided by periodic UPDATE calls.

[0154] The concept of trusted connections is fundamental for providing security and integrity in the DHT infrastructure. Two different mechanisms can be involved in creating new edges in the network.

[0155] Subjective connections are built on social or professional relationships between peers, such as friendship, contracts, and trust regarding well-known global or local entities. For example, non-profit organizations, research institutions, government agencies, and private companies that have signed specific agreements can be trusted connections.

[0156] The transient connection is based on logical characteristics and reliability to increase the number of random paths on the network. The increased randomness in the hop-by-hop walk makes it even more difficult for malicious nodes to exploit the vulnerability of malicious edges. To recognize trusted connections between other nodes, signed messages can be exchanged between peers. Nodes can decide to assign different weights to their trusted connections to adjust the probability of selecting individual hops in a random walk or to initialize a new transient connection. All nodes bear their own weights. Honest nodes will adjust the weights of their connections according to the routing behavior of their peers, and a node may not be able to provide a valid key-value record if a key falls into its short-distance routing table. Thus, new random walks are prevented from passing through weak edges, and the influence of malicious nodes will decrease over time.

[0157] The DMP function is provided by a cluster of specialized Bitcoin nodes. Within the cluster, verification nodes are responsible for collecting and verifying new incoming transactions, while mempool nodes are responsible for permanently storing the verified transactions. Figure 11 shows the design of a mempool cluster with multiple verification nodes v and multiple mempool nodes s. The functions of these two types of nodes may be provided by the same physical entity or embedded in different entities.

[0158] DMP provides two basic operations: storage and retrieval of verified transactions. Given a transaction t i and an identifier id(t i ) is set to id i = H(t i) can be assigned, where H represents a hash function. This identifier will be used as a key in the DMP. Using a specific multicast address, transactions can be received from multiple validators within a cluster. Then, each validator independently verifies the transaction. However, the underlying DHT structure does not embed the transaction ID into the key space to prevent key clustering attacks. Therefore, transactions can be stored in random nodes within the DMP. For a given transaction or a given group of transactions, the validator node can send an R STORE message request to a random mempool node, where R is the data replication factor.

[0159] Assume that N validators independently verify transaction t i . Each validator v maintains and manages a local database called V DB . Each entry in this database contains the identifier of the transaction id i and the binary decision regarding verification. Each validator sends a STORE(t i , id i ) or REJECT(idi) message to the DMP according to the local decision.

[0160] Each mempool node s stores t i only when it receives N / 2 + 1 STORE messages. Alternatively, the node starts a timer for receiving the N / 2 additional STORE messages required to reach the quorum as soon as it receives the first STORE message. If the timeout is exceeded without receiving sufficient confirmation, the transaction is discarded. Each mempool node s m also maintains the number N i of confirmations received for t i,m > N / 2 + 1.

[0161] Verified transaction ti The search requires a broadcast of the message QUERY(id i ). The mempool node responsible for storing t i will send the message DATA(t i ) to the query node. If M mempool nodes are required to store t i , at least M / 2 + 1 DATA messages should be received by the query node to consider the stored transactions to be consistent. Further, the query node can interrogate N / 2 + 1 random validators using the VALIDITY_REQ(t DB ) message to evaluate the validity of t i according to the information stored in V i .

[0162] A scalable architecture for managing increasingly growing transaction activity requires a storage infrastructure that operates with large amounts of data. For example, a 1KB average transaction size at a transaction rate of 10K txn / s requires ~27TB of storage per month of blocks.

[0163] Within the M network cluster, two different storage architectures (or combinations thereof) are proposed. The first architecture is suitable for large entities that own and maintain several verification nodes that all have access to a centralized storage institution. In contrast, a fully decentralized architecture is suitable for individual nodes with sufficient storage capacity that wish to participate in a shared distributed storage pool.

[0164] Below, we use the following terms to represent transaction dependencies: A transaction can use the output of a preceding transaction called the parent; A transaction can create an output for a subsequent transaction called a child.

[0165] Transaction dependencies, or a chain of transactions, can represent a complex transaction workflow that requires a child to be added before its parent [Bitcoin Core source code URL: https: / / github.com / bitcoin / bitcoin]. When a chain of transactions is transmitted across the network, the order of data arrival may not match the order of data transmission. In that case, an orphan transaction pool is used by the receiving node to store transactions that reference an unknown parent transaction. Once the parent is known, any orphans that reference UTXOs created by the parent are freed from the orphan pool and re-validated recursively. And the entire chain of transactions is reconstructed in the correct order and included in the transaction pool. Therefore, when a new transaction is added to the mempool, there are no children in the mempool. Because such children would become orphans.

[0166] To prevent a denial-of-service attack, there is a limit on the number of orphan transactions stored in memory. If the number of orphan transactions in the pool exceeds the allowed maximum, randomly selected orphan transactions are removed from the pool until the pool size is back within limits.

[0167] The local memory pool contains a set of transactions that match the node's view of the blockchain. A transaction can be removed from the local mempool for one of the following reasons: Transaction disclosure in a mined block. When a new block is verified, the transaction is removed from the mempool; Blockchain reorg. If a block is disconnected from the blockchain, its transactions are moved back; Collision with in-block transactions (double spending). When a new block is verified, all transactions that collide with the transactions in that block, along with those that depend on them, are removed from the mempool.

[0168] Also, depending on the local mempool configuration, the following additional cases can be considered: Manual pruning; Expiration; and Local memory size limit.

[0169] When deleting a transaction and its children, a complete set of transactions must be calculated before actually performing the deletion. Otherwise, the mempool can become an inconsistent state where it is impossible to find the parent. All ancestors of a given transaction marked for removal need to be updated. Thus, intermediate transactions in the chain cannot be removed until all states of all related transactions are updated.

[0170] In the case of a reorg, new transactions may have children within the mempool, which can cause an inconsistent state. This is because there may be descendant transactions of transactions from the disconnected block. In this case, the out-of-block descendants of in-block transactions within the mempool must be checked. In Bitcoin Core, the function UpdateForDescendants is used to update the descendants of individual transactions added to the mempool, and it can have child transactions within the mempool [Bitcoin Core source code URL: https: / / github.com / bitcoin / bitcoin].

[0171] As described above, the winning minor returns the block skeleton to the verification node. The block skeleton consists of a nonce, a reversible Bloom filter lookup table (IBLT), and a coinbase transaction. Based on this, the verification node can: 1. Order the transactions according to a specific rule set; 2. Assemble the newly mined block; 3. Proceed to store the block in its own storage; 4. Propagate the skeleton to other new full nodes, which is possible.

[0172] Therefore, the verification node becomes aware of newly published transactions. Each validator node independently sends a deletion message containing a list of transaction IDs to the DMP. A validator can send a deletion request only for transactions that have been previously verified (check_validator_send is enabled). This information is stored in the database V DB (Validator database). According to this model, the mempool node can discard deletion requests received from validators that did not verify the transaction (check_validator_rcv is enabled). This information is stored in the database S DB (Storage database). These two check_validator_send options and check_validator_rcv options may be hardcoded or may be set independently. The deletion message is signed with the validator's private key. The message must include a nonce or a timestamp to avoid the spread of unauthorized duplicates that could affect the consensus protocol.

[0173] Figure 12 shows validator node v receiving an update regarding the newly mined block n(0 ≦ n < N) is shown. After verifying the block, the validator sends a DELETE request regarding the published transaction to the DMP. Each mempool node s m (0 ≦ m < M) is, for S DB tracking the storage requests on the table and R DB removal requests on the table. As shown in FIG. 12, in order to track the deletion requests for each of the stored transactions, a new table R DB (Removal database) is used by each mempool node. When given a deletion request for a transaction t i from validator n < N for mempool node m < M, the local R DB (m) table will contain a boolean r mn value. For example, if N = 100 and each mempool node can store 10M transactions every 10 minutes for 3 days, the size of R DB (m) is bounded by 100 · 10 7 · 3 · 24 · 6 = 432GB. Note that this number represents a highly unlikely worst - case scenario where all the transactions stored locally in the past 3 days have not been approved and 1 byte is required for each table entry. A table size that is at least one or two orders of magnitude smaller (e.g., ~4GB) is more likely to represent a realistic scenario. However, due to the high storage capacity required of the mempool nodes, we do not impose a limit on the maximum size of the local table.

[0174] Let N MAX > N be the maximum number of validators that can send STORE or DELETE messages to the cluster. Depending on the selected distributed architecture, N MAX may be equal to the total number of validators in the network or may be proportional to the size of a particular DMP cluster. The size of the DMP cluster is given by the number of mempool nodes and / or the total amount of transactions that can be stored locally.

[0175] We introduce some criteria for determining whether the transaction ti stored in the local memory pool node s within the cluster should be removed: m At least N <N * <N MAX validators send DELETE requests. The validators can actually contribute to N according to the settings of check_validator_send and check_validator_rcv. When one or both options are set, we can impose N * ≒N (approximate). If neither option is set, in order to achieve the highest possible consensus, we recommend N * >N. *

[0176] t i depends on the previously removed transaction t j If both transactions are stored in s m and t j has been safely removed, then t i can also be safely removed (when consensus is reached on the removal of the transaction, the dependent transaction must be considered invalid and marked for removal). No signaling to other memory pool nodes is required.

[0177] We do not force the DMP to store the transaction chain in a single memory pool node to prevent specific service disruption attacks. Therefore, the memory pool node may be in an inconsistent state for the state of individual transactions in the chain. This is not a problem as long as the Bitcoin node that requests data related to the transaction chain learns about the inconsistency from a specific query request to the DMP. For example, the Bitcoin node queries the DMP about the transaction t i . This transaction depends on a second transaction t j . After querying the DMP about the second transaction, the node will​j It is discovered that it is no longer stored. Therefore, even if it is still stored in some memory nodes within the DMP, it is the responsibility of the node to consider it as unavailable. The long-term inconsistency will be resolved by permanent pruning. i Once consensus is reached, the transaction t

[0178] is locally marked as being removed. However, for security reasons, the transaction may not be physically removed. We introduce two criteria to determine when a transaction should be physically deleted from s i : m At least N validators send a DELETE request. The value of N ** ≧ N * should be high enough to consider the pruning consensus to be completely secure; ** After the last DELETE request is received, a time of length ΔT has elapsed and no further data requests for t i > ΔT * have been transferred. The value of ΔT i should be high enough to consider the probability of a reorg event to be negligible. According to the 6-block approval rule, a transaction can be safely considered to have been accepted by the network approximately 1 hour after its publication in a newly mined block. * However, depending on the memory constraints of s

[0179] even if the above criteria are not met, t m may be removed. Transactions can be sorted in descending order of ΔT i and selected for permanent deletion. Belonging to the chain and s i m ​Multiple transactions stored therein must be deleted simultaneously. No notification to validators regarding pruning of the transaction chain is required. Bitcoin nodes that require data regarding the transaction chain learn of the discrepancy through specific query requests to the DMP.

[0180] The mempool node may collect data requests for transactions that are already marked as being removed. Receiving multiple data requests for an individual transaction may have different meanings: A service disruption attack that retains useless data; A blockchain reorg and the need to transfer transactions back to the DMP.

[0181] Since the requests may not be legitimate, the mempool node takes no action as a result of these data requests. The data request counter can be used to mark removed transactions as candidates for reversion. These candidates can still be considered for physical pruning. If a priority policy is implemented for physical pruning, lower priority can be assigned to candidate transactions for reversion.

[0182] Transactions that are marked as being removed but are still locally stored can only be reverted if a REVERT (reversion) message is received from the validator. The validator is responsible for signaling the DMP when a chain reorg occurs. The mempool node needs to collect a certain number of its own REVERT messages to make the transaction reusable again. We recommend the number of messages as a function of the N, N * and / or N ** parameters. For example, the minimum number of REVERT messages can be equal to the average value between N and N *

[0183] ​Table 3 summarizes the configurable parameters used by the pruning protocol.

Table 3

[0184] The protocol for managing transactions includes the following messages: RECEIVED(t i ) A callback for the validator triggered when a new unvalidated transaction t i is received; STORE(t i ,id i ) A request for the validator to store a valid transaction t i and key id i ; STORE(id i ) An optimized request for the validator to store a valid transaction key id i ; QUERY(id i ) A request from a general node regarding the transaction with key id i ; DATA(t i ) A response from the mempool node to a query request for transaction t i ; VALIDITY_REQ(t i ) A request from a general node to double-check the validity of transaction t i ; VALIDITY_ACK(t i ) A response from the validator to a validity request regarding transaction t i .

[0185] The extensions presented here require the following additional messages: REMOVE(id i ) A request from the validator to remove the transaction specified by id i ; REVERT(id i) After chain reorg, a validator's request to revert the transaction identified by id i ; REMOVED(id i ) id i The response of the mempool node to a query request regarding the removed transaction identified by id. If the information is still available, this message may include the number of REMOVE messages received by the mempool node regarding the transaction identified by id i .

[0186] Figure 13 shows the complete state diagram of the transaction identified by idi in response to the validator's request. Depending on the type (i.e., STORE, REMOVE, REVERT) and number (e.g., N, N * , N ** ) of the messages received from the validator, the transaction can change its state to Available, Removed, or Physically Removed. The transaction state "Physically Removed" cannot be reverted. However, depending on the functions provided by the local file system and the operating system, the data may still be recoverable.

[0187] Note that the above-described embodiments are not intended to limit the present invention, but are illustrative, and those skilled in the art can design numerous alternative embodiments without departing from the scope of the present invention defined by the appended claims. For example, it should be understood that a transaction can transfer Bitcoin, but instead, a user can exchange other resources such as information, contracts, and tokens using the methods and systems described herein. A token represents an asset or resource according to a smart contract associated with the token, and the management of the token enables the management of the asset or resource. The smart contract itself may be stored outside the blockchain or may be stored inside one or more transactions.

[0188] In the claims, any reference signs placed in parentheses shall not be construed as limiting the claim. The terms "comprising" and "comprises" and the like do not exclude the presence of elements or steps other than those listed in any claim or the entire specification. In this specification, "comprises" means "includes or consists of", and "comprising" means "including or consisting of". References to elements in the singular do not exclude references to those elements in the plural, and vice versa. The present invention can be implemented by means of hardware having several distinct elements and also by a suitably programmed computer. In device claims enumerating several means, several of those means may be embodied by the same hardware item. The mere fact that certain means are recited in mutually different dependent claims does not indicate that a combination of those means cannot be used advantageously.

[0189] References - An Integrated World. (n.d.) Retrieved from https: / / www.anintegratedworld.com / whats-in-a-block / - David Eppstein, M. T. (2011). What's the Difference? Efficient Set Reconciliation without Prior Context. ACM. - maidsafe. (n.d.). Retrieved from github.com:https: / / github.com / maidsafe / Whitepapers - Michael T. Goodrich, M. M. (2011). Invertible Bloom Lookup Tables. Communication, Control, and Computing (Allerton), 2011 49th Annual Allerton Conference on. - NebulousLabs. (n.d.). Retrieved from github.com:https: / / github.com / NebulousLabs / Sia - O(1) Block Propagation. (n.d.). Retrieved from github.com:https: / / gist.github.com / gavinandresen / e20c3b5a1d4b97f79ac2 - Wikipedia. (n.d.). Retrieved from https: / / en.wikipedia.org / wiki / Distributed_hash_table - Wilkinson et al. (December 15, 2016). Retrieved from https: / / storj.io / storj.pdf - John R. Douceur. The Sybil Attack. First International Workshop on Peer-to-Peer Systems. Springer-Verlag, London, UK, 2002 - Bitcoin Core source code. URL: https: / / github.com / bitcoin / bitcoin

Claims

1. A computer-implemented method for a node in a blockchain network, comprising: Receiving data regarding a newly mined block having a plurality of transactions; Sending a revert request to the decentralized memory pool to change the state of the transaction to be available within the decentralized memory pool; A computer-implemented method having the above.

2. The revert request is sent after a blockchain re-organization, The computer-implemented method according to claim 1.

3. The state of the transaction is changed to be available after a specified number of unique revert requests are provided to the decentralized memory pool, the computer-implemented method according to claim 1 or 2.

4. The specified number of unique revert requests is a function of the number of validators responsible for verifying the transaction, the minimum number of validators required to trigger a reversible pruning of the transaction, and the minimum number of validators required to trigger a physical pruning of the transaction, the computer-implemented method according to claim 3.

5. Removing the marking of a transaction as being removed from the decentralized memory pool when a revert request is received for the transaction; The computer-implemented method according to any one of claims 1 to 4, further comprising the above.

6. Removing the marking of a transaction as being removed from the decentralized memory pool when a threshold number of revert requests are received for the transaction; The computer-implemented method according to any one of claims 1 to 5, further comprising the above.

7. The threshold number of revert requests is required to come from a threshold number of different validation nodes within the blockchain network, The computer-implemented method according to claim 6.

8. The pruning of a transaction from the decentralized memory pool is Manually pruned, The transaction has expired, and A memory limit has been reached for the transaction within the decentralized memory pool, Triggered by one or more of the above, The computer-implemented method according to any one of claims 1 to 7.

9. A computer-readable storage medium having computer-executable instructions that, when executed, configure one or more processors to perform the method according to any one of claims 1 to 8.

10. An interface device, One or more processors coupled to the interface device, A memory coupled to the one or more processors, the memory storing computer-executable instructions that, when executed, configure the one or more processors to perform the method according to any one of claims 1 to 8, An electronics device having the above.

11. A node of a blockchain network, the node being configured to perform the method according to any one of claims 1 to 8.

Images