METHOD FOR TRANSACTION VERIFICATION NODE IN BLOCKCHAIN ​​NETWORK, STORAGE MEDIUM, ELECTRONIC DEVICE, TRANSACTION VERIFICATION NODE, SUPER NODE AND BLOCKCHAIN ​​NETWORK

Abstract

To provide a solution for supporting high transaction speed in implementation in a transaction verification node of a blockchain network.SOLUTION: A method includes the steps of: receiving transactions from a blockchain network; verifying the transactions received from the blockchain network; in conjunction with other transaction verification nodes in the blockchain network, maintaining a distributed non-centralized storage of the verified transactions; and distributing data corresponding to the verified transactions to the blockchain network for mining.SELECTED DRAWING: Figure 7

Description

[Technical field]

[0001] This specification relates generally to computer-implemented methods and systems suitable for implementation in transaction validating nodes of a blockchain network. Modified blockchain node structures, network architectures, and protocols for handling large numbers of transactions and large transaction blocks are described. The present invention is particularly suited, but not limited to, for use with the Bitcoin blockchain. [Background technology]

[0002] The term "blockchain" is used herein 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 application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. Although reference may be made herein to Bitcoin for convenience and illustrative purposes, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention.

[0003] A blockchain is a consensus-based electronic ledger implemented as a computer-based decentralized distributed system made up of blocks, which are made up of transactions and other information. In Bitcoin, each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system, and contains at least one input and at least one output. Each block contains a hash of the previous block that becomes chained together, creating a permanent, immutable record of all transactions that have been written to the blockchain since inception. Transactions contain small programs called scripts that are embedded in the transaction's inputs and outputs, and the scripts specify how the transaction's outputs can be accessed and by whom. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] For a transaction to be written to the blockchain, it must be "validated." Some network nodes, acting as miners, work to ensure that each transaction is valid, and invalid transactions are rejected from the network. For example, a software client installed on the node performs this validation for transactions that reference unspent transaction outputs (UTXOs). Validation may be performed by executing its lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to TRUE and certain other conditions are met, the transaction is valid and the transaction can be written to the blockchain. Thus, for a transaction to be written to the blockchain, it must i) be verified by the node that receives it, and if the transaction is valid, that node relays it to other nodes in the network; and ii) be added to a new block constructed by miners; and iii) be mined, i.e., added to the public ledger of past transactions. A transaction is considered agreed upon once a sufficient number of blocks have been added to the blockchain to make it effectively irreversible.

[0005] Although blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are beginning to explore using both the cryptographic security system that Bitcoin is based on, and the data that can be stored on the blockchain, to realize new systems. It would be highly advantageous if blockchain could be used for automating tasks and processes that are not purely limited to payments in cryptocurrencies. Such solutions could utilize the advantages of blockchain (e.g. permanent tamper-proof record of events, distributed processing, etc.) while becoming more diverse in their applications.

[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, which are written in natural language, smart contracts are machine-executable programs that contain rules capable of processing inputs to produce outcomes and then performing actions dependent on those outcomes.

[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 sensitive or secret items can be represented by tokens that have no discernible meaning or value. The tokens thus act as identifiers that allow real-world items to be referenced from the blockchain.

[0008] US2015 / 0287026 discloses a hot wallet service system. The hot wallet service system receives financial transactions from one or more user devices, authenticates the financial transactions using a plurality of authentication servers implementing a multi-signature authentication system, aggregates the digital signatures, and propagates the authenticated financial transactions to a cryptocurrency network. Once the financial transactions are propagated by the cryptocurrency network, they can be incorporated into a public shared ledger by miner entities of the cryptocurrency network in the usual manner. The hot wallet service system further includes an analysis system capable of monitoring the cryptocurrency network and generating a credit rating and score, which can be used, for example, to prevent certain financial transactions from being processed by the multi-signature authentication system.

[0009] CN106548349 is related to the problem that if all nodes in a blockchain network are required to verify the transaction information of every transaction, this process generates a significant workload and puts a lot of pressure on the nodes. The solution described in CN106548349 is to propagate the transaction information from a first node to multiple selected second nodes to verify the transaction information, rather than requiring that all nodes must verify the transaction information. The second nodes are selected in a random and irregular manner, preventing the possibility of malicious fraud, and eliminating the need for all nodes to verify the transaction information.

[0010] WO2017 / 162904 relates to a blockchain-based resource management system in which transaction delays are reduced and duplicate transfers of resources are mitigated by validating transactions before a new block is established in the resource management system. At least one validator node is provided to validate the transaction, provide a validation acceptance message to the merchant, and release the item to the customer. Thus, it is possible to ensure that the sale is completed without waiting for the next block of the blockchain to be established. It is also disclosed that the validator node can distribute a validation request to a set of validator nodes and receive responses from the set of validator nodes. The validator node may then send a validation acceptance message to the merchant if and only if none of the responses from the set of validator nodes is a rejection of the transaction. It is further disclosed that when it is time to establish a block in the blockchain, the node establishing the block can compile a set of transactions that have taken place since the most recently established block, and the next block will include this set of transactions.

[0011] US2016 / 0259937, WO2017 / 004527, and WO2017 / 011601 describe how the current Bitcoin blockchain network is structured and functions. In particular, individual transactions are propagated through the network and incorporated into the blockchain by mining, where mining nodes select a set of transactions, group the transactions into prototype blocks, and determine the value of a nonce in a traditional "proof of work" manner. Once a miner finds a valid nonce, the block is verified by other nodes and incorporated into the blockchain.

[0012] US2015 / 0310424 discloses a system for generating user directory data by multi-modal cryptographic key-address mapping. A cryptocurrency network comprises crypto-nodes that publicly validate a set of cryptocurrency user transactions. Nodes may participate in the cryptocurrency network by relaying transactions, maintaining a validation ledger, and / or mining cryptocurrency. Summary of the Invention

[0013] At the time of writing, the Bitcoin blockchain network is based on a block size containing about 2000 transactions, with blocks being mined approximately every 10 minutes (the 10 minute block time is set as a compromise between the time spent on first confirmation and the time spent on chain splits). This provides a transaction processing speed of about 3.5 transactions per second. In contrast, the VISA system operates at a transaction processing speed of about 10,000 transactions per second, and can reach more than 50,000 transactions per second.

[0014] It is clear that in order to build a competitive payment system, the current constraints of blockchain networks must somehow be circumvented. Since 10 minute block times are well established, it is mandatory to consider changes in block sizes and thus the blockchain itself. A scalable solution is described herein that can handle, for example, around 50,000 transactions / second. Importantly, a solution is provided that can support high transaction speeds while maintaining a decentralized and distributed system architecture.

[0015] The transition of the Bitcoin network from its current architecture to one where a large number of simultaneous transactions can be processed places infrastructure strain pressures on the entire network. A system of nodes capable of validating and relaying a large number of transactions more efficiently and faster has been proposed. Due to the volume of transactions, a distributed approach is proposed in the design of a mempool (unprocessed transactions that have not yet been processed and stored in the blockchain). The large number of transactions puts pressure on block sizes, which will create storage infrastructure problems if the block size exceeds a given limit. A solution to the problem of processing and storing large gigabyte-sized blocks is described herein.

[0016] The present specification describes a modified blockchain network architecture, which includes a plurality of dedicated transaction validating nodes, which are configured to validate transactions and maintain a distributed, decentralized storage of the validated transactions together with other transaction validating nodes in the blockchain network. The transaction validating nodes are further configured to prepare a list of validated transactions for miners and to create commitment transactions for digital assets in exchange for providing the list of validated transactions to the miners. Thus, the dedicated transaction validating nodes provide services to miners in terms of validating transactions, building lists of validated transactions, and providing these lists to miners for a fee. Once a transaction is mined, the mined transaction is returned to the transaction validating nodes, which build large blocks of mined transactions and store the large blocks in the dedicated storage nodes.

[0017] One aspect of the present invention relates to a method in a validator node for receiving, validating, storing, and distributing transactions to a blockchain network for mining. A computer-implemented method for a transaction validator node of a blockchain network is provided, the computer-implemented method comprising:

[0018] (i) receiving a transaction from a blockchain network; (ii) validating the transactions received from the blockchain network; (iii) maintaining a distributed, decentralized storage of validated transactions together with other transaction validating nodes in the blockchain network; and (iv) distributing data corresponding to the verified transactions onto a blockchain network for mining.

[0019] Data corresponding to validated transactions distributed to a blockchain network for mining includes lists of validated transactions, each of which can provide a complete list of validated transactions for mining into a block.

[0020] Such a method effectively removes the requirement for miners to perform a validating function while maintaining distributed, decentralized storage of verified transactions with other transaction validating nodes in the blockchain network. Additionally, the method allows transaction validating nodes to provide a service to miners by preparing and distributing data corresponding to verified transactions to the blockchain network for mining. For example, the method allows a list of verified transactions to be prepared and distributed. The computer-implemented method further comprises: (v) receiving mined data from the blockchain network corresponding to the verified transaction; (vi) assembling blocks based on the mined data; and (vii) sending the assembled blocks to a storage entity for storage in the blockchain; It is possible to include: These further methods allow validating nodes to construct large blocks to be stored in storage entities without requiring miners to construct and store large blocks and transmit such blocks on the blockchain network. Furthermore, the architecture still allows the use of large scale storage entities specialized for storing large and still growing blockchains.

[0021] The step of maintaining a distributed, decentralized storage of the verified transactions with other transaction validating nodes in the blockchain network may include synchronizing the transaction validating nodes of the blockchain network to maintain an up-to-date list of verified transactions in a distributed, decentralized manner. For example, the validating nodes can be synchronized by exchanging invertible bloom filter lookup tables. The verified transactions can also be sorted in a defined order such that a common ordering system is used across the transaction validating nodes in the blockchain network to maintain the distributed, decentralized storage of the verified transactions. For example, a canonical ordering system can be used to maintain the distributed, decentralized storage of the verified transactions. This has been found to be a particularly efficient way of maintaining decentralized, distributed storage while ensuring that transaction data across the network is maintained in a consistent manner.

[0022] Distributing the data corresponding to the verified transactions to a blockchain network for mining can include preparing data corresponding to a list of verified transactions (including a reversible Bloom lookup table and any associated data corresponding to the list of verified transactions, where the verified transactions are included in a block). Additionally, distributing the data corresponding to the verified transactions to a blockchain network for mining can include creating commitment transactions for digital assets in exchange for providing miners with the data corresponding to the list of verified transactions. For example, a hash (Merkle) tree, a Patricia tree, or other type of radix tree can be computed with the included commitment transactions.

[0023] After the data corresponding to the validation transactions is distributed and mined by solving the associated cryptographic puzzle, e.g., a hash puzzle, the mined data is sent back to the transaction validation nodes, rather than being stored directly on the blockchain by the miners. This mined data can then be assembled into (large) blocks and stored either in storage entities specially configured for the storage of large amounts of data and / or in distributed storage systems. As mentioned above, this allows validation nodes to construct large blocks that are stored in storage entities without requiring miners to construct and store such blocks and transmit them on the blockchain network. Furthermore, the architecture allows the use of large storage entities dedicated to storing ever-growing large blockchains.

[0024] The mined data received from the blockchain network can include block headers corresponding to verified transactions. The mined data can also include digital asset transactions for assembling and / or storing blocks based on the mined data. Additionally, the method can include a condition to wait for a period of time t associated with a minimum number of blocks before receiving the digital assets. This provides an incentive scheme for providing validating nodes such that providers are rewarded for providing lists of verified transactions for mining (e.g., in the form of a reversible Bloom lookup table) and / or storing mined blocks on the blockchain. Requiring a minimum period of time before receiving the digital assets incentivizes miners to propagate skeleton blocks (including payments) to a range of nodes, and nodes are incentivized to propagate skeleton blocks to other nodes.

[0025] Assembling blocks based on the mined data may include, for example, assembling large blocks, each block having a size of at least 2, 4, 6, 8, 10, 50, 100, 500, 1000, or 10000 megabytes. A nominal upper limit of 1 petabyte may be specified, although the upper limit will increase over time. Each block may include, for example, at least 5000, 10000, 50000, 100000, 500000, or 1000000 transactions. The upper limit will increase over time, but a nominal upper limit of 10000 transactions per block may be specified. 12 A nominal upper limit of transactions may be specified. As noted above, the methods, nodes, and blockchain network architecture described herein allow large blocks to be constructed and stored in storage entities without requiring miners to construct and store large numbers of transactions. This allows the system to handle significantly increased transaction speeds.

[0026] In the methods described herein, a block may be modified to include a block header that includes a random number provided by the miner. That is, a transaction validating node may be configured to process a block that includes a block header that includes a random number provided by the miner when it receives a resolved transaction from the blockchain network. This constitutes a modification to the block header, whereby a miner may choose or randomly generate the number inserted in the block header. This helps ensure that miners do not compete to mine the same block, even if the same transaction list is chosen by multiple miners.

[0027] The storage device for storing the above-mentioned large blocks of data can be shared among multiple transaction validating nodes on the blockchain network, where the multiple transaction validating nodes form a supernode on the blockchain network, and the shared storage device can be either a common storage node, a distributed storage, or a combination of the two. This architecture leads to the formation of supernodes on the blockchain network and allows for the provision of dedicated storage devices for storing the blockchain and providing services to the blockchain network.

[0028] In view of the above, there is also provided for Supernodes of the blockchain network, which Supernodes shall: A plurality of validating nodes as described above; and A shared storage entity that stores the blockchain; wherein the shared storage entity is either a common storage node, a distributed storage, or a combination of both; and Blocks assembled by multiple validating nodes are sent to and stored in a shared storage entity, which maintains the blockchain.

[0029] This architecture is more suited to handling the larger block sizes required to achieve the desired increase in transaction rate that is the objective of the methods and configurations described herein. For example, a shared storage entity may be configured to have at least 100 gigabytes of storage capacity, and more preferably at least 1, 10, 100, or 1000 terabytes of storage capacity. The upper limit may be increased over time, but may be in the range of 10 to 100 terabytes. 6 Terabytes, possibly 10 6 A nominal upper limit of yottabytes may be specified.

[0030] Regarding the overall network architecture, a blockchain network may be provided that includes a plurality of such supernodes. The supernodes may be connected (but not overlapping) in the blockchain network, and the shared storage entity of each supernode is configured to store a copy of the blockchain. A supernode effectively includes a group of nodes that form a pool that functions as a supernode. To maintain the decentralized nature of the blockchain, there should advantageously be a certain number of such supernodes (e.g., at least 10, 50, 100, or 1000, and optionally less than 100,000,000).

[0031] The embodiments of the present invention may be provided in various forms. For example, a computer-readable storage medium may be provided that includes computer-executable instructions that, when executed, configure a processor to perform the methods described herein. An electronic device may also be provided having: an interface; one or more processors coupled to the interface; and a memory coupled to the one or more processors, the memory storing computer-executable instructions that, when executed, cause the one or more processors to perform the methods described herein. Further, a validating transaction node of a blockchain network may be provided, the validating transaction node configured to perform the methods described herein.

[0032] The invention described herein differs from the prior art discussed in the Background section as explained below.

[0033] The hot wallet service system of US2015 / 0287026 appears to disclose receiving transactions, authenticating transactions, and distributing transactions to the blockchain network for mining. However, the hot wallet service system of US2015 / 0287026 does not maintain a distributed, decentralized store of verified transactions with other transaction verification nodes in the blockchain network. Rather, the hot wallet service system of US2015 / 0287026 instigates a multi-signature authentication system using multiple services. Any transactions that are subsequently verified by aggregating authentication factors are merely propagated to the virtual currency network and are not stored in the hot wallet service system in a distributed, decentralized manner. Furthermore, there is no suggestion in US2015 / 0287026 of preparing a list of verified transactions and creating digital asset commitment transactions in return for providing the list of verified transactions to miners. CN106548349 appears to disclose receiving transactions, validating the transactions, and distributing the verified transactions to a blockchain network for mining. However, CN106548349 does not disclose maintaining a distributed, decentralized store of verified transactions with other transaction validating nodes in the blockchain network. Furthermore, there is no suggestion in CN106548349 about preparing a list of verified transactions and creating digital asset commitment transactions in return for providing the list of verified transactions to miners. WO2017 / 162904 appears to disclose receiving transactions, validating transactions, and distributing the validated transactions for inclusion in the blockchain. However, 2017 / 162904 does not disclose maintaining a distributed, decentralized store of validated transactions with other transaction validating nodes in the blockchain network. Furthermore, there is no suggestion in WO2017 / 162904 of preparing a list of validated transactions and creating digital asset commitment transactions in return for providing the list of validated transactions to miners.

[0034] US2016 / 0259937, WO2017 / 004527, and WO2017 / 011601 disclose that a mining node selects a set of transactions, groups the transactions into a prototype block, and determines the value of the nonce in a traditional "proof of work" manner. Once a miner finds a valid nonce, the block is verified by other nodes and incorporated into the blockchain. US2016 / 0259937, WO2017 / 004527, and WO2017 / 011601 do not disclose maintaining a distributed, decentralized store of verified transactions with other transaction verifying nodes in a blockchain network that provides a distributed pool, and the list of verified transactions is provided to miners for mining. Similarly, US2015 / 0310424 does not disclose validating nodes that receive transactions, validate the transactions, maintain a distributed, decentralized store of validated transactions with other transaction validating nodes, prepare a list of validated transactions, and create digital asset commitment transactions in return for providing the list of validated transactions to miners.

[0035] In view of the above, it is believed that the present invention provides a unique architecture and methodology for more efficiently processing and storing large gigabyte-sized blocks within a blockchain network. [Brief description of the drawings]

[0036] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter, which are described, by way of example only, with reference to the accompanying drawings, in which: [Figure 1] Figure 1 shows the overall structure of the block. [Diagram 2] Figure 2 shows the modified architecture of the Bitcoin network with a behavioral diagram showing the steps a transaction goes through from the time a user submits it to when it is finished on the blockchain. [Diagram 3] FIG. 3 shows a graph illustrating an example of the total size of transactions waiting in a memory pool for confirmation. [Figure 4] FIG. 4 shows multiple nodes linked to an internally centralized storage facility. [Diagram 5] FIG. 5 shows a configuration in which each node is part of both a distributed memory pool and a distributed storage facility. [Figure 6] Figure 6 illustrates how the new node structure fits into the Bitcoin network, showing a network configuration in which validating nodes are members of storage pools, and the pools together make up the decentralized and distributed Bitcoin network. [Figure 7] Figure 7 shows the functionality of the new node. [Figure 8] Figure 8 shows the new Merkle tree structure that constitutes the modification to the current protocol. [Figure 9] Figure 9 shows the workflow for creating a Bloom filter. [Figure 10]Figure 10 shows the workflow from how a transaction is encoded into a Reversible Bloom Filter (IBF) and a Reversible Bloom Lookup Table (IBLT). DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0037] Described herein is a solution to the problem of processing and storing large gigabyte-sized blocks.

[0038] Types of Blockchain Network Nodes and Validation Nodes A blockchain network may be described as a peer-to-peer open membership network in which anyone may join without invitation and without consent from other members. Distributed electronic devices running an instance of the blockchain protocol on which the blockchain network operates may participate in the blockchain network. Such distributed electronic devices may be referred to as nodes. The blockchain protocol may be, for example, the Bitcoin protocol or other cryptocurrencies.

[0039] The electronic devices that run the blockchain protocol and form the nodes of the blockchain network may be of various types, such as computers, such as desktop computers, laptop computers, tablet computers, servers, computer farms, mobile devices, such as smartphones, wearable computers, such as smart watches, or other electronic devices.

[0040] The nodes of a blockchain network are coupled to each other using suitable communication technologies, which may include wired and wireless communication technologies. Often, a blockchain network is implemented at least in part over the internet, and some of the nodes may be located in geographically distributed locations.

[0041] Currently, nodes maintain a global ledger of all transactions on the blockchain that are grouped into blocks, with each block containing a hash of the block that precedes it in the chain. The global ledger is a distributed ledger, and each node may store a full or partial copy of the global ledger. Transactions by nodes that affect the global ledger are verified by other nodes to maintain the validity of the global ledger. The details of the implementation and operation of blockchain networks, such as those that use the Bitcoin protocol, will be understood by those skilled in the art.

[0042] Each transaction typically has one or more inputs and one or more outputs. Scripts embedded in the inputs and outputs specify how the transaction's outputs can be accessed and by whom. A transaction's output may be an address to which a value is transferred as a result of the transaction. This value is associated with that output address as an unspent balance (UTXO). Subsequent transactions can then reference that address as an input to consume or distribute that value.

[0043] Nodes can be of different types or categories depending on their functions. It has been suggested that there are four basic functions associated with a node: wallet, mining, full blockchain maintenance, and network routing. Variations on this functionality can exist. A node may have more than one function. For example, a "full node" exhibits all four functions. A lightweight node may, for example, be implemented as a digital wallet or may only exhibit wallet and network routing functions. A digital wallet may not store the entire blockchain, but keep track of block headers that serve as an index when querying blocks. Nodes communicate with each other using a connection-oriented protocol such as TCP / IP (Transmission Control Protocol).

[0044] An additional type or category of node may be provided: a merchant node (often referred to herein as an "M-Node"). M-Nodes are designed to focus on rapid propagation of transactions. They may or may not store the complete blockchain, and do not perform mining functions. In that sense, they are similar to lightweight nodes or wallets; however, they include additional functionality that allows for rapid propagation of transactions. The operational focus of an M-Node is the rapid validation and propagation of unconfirmed transactions, particularly to other M-Nodes, from which unconfirmed transactions are rapidly pushed to other nodes in the blockchain network. To facilitate this function, M-Nodes are permitted a number of incoming and especially outgoing connections that may be permitted to nodes under the governance protocol.

[0045] M-Nodes may be collectively referred to as a merchant network (or "M-net"). The term "merchant" may be interpreted as meaning "specialised". M-Nodes may be integrated into a blockchain network. Each M-Node is a specialized node in the blockchain network and meets certain hardware and performance capabilities that ensure it can perform the functions of an M-Node. That is, an M-net may be considered a sub-network within and distributed throughout the blockchain network. M-Nodes may be arranged and configured to perform one or more dedicated functions or services.

[0046] For the M-net to work reliably and provide services at a given security level, the M-node needs to maintain a good view of the entire M-net, and therefore an efficient routing protocol needs to be in place. Whenever an M-node receives an initiation transaction, it needs to broadcast it to several other M-nodes in addition to other nodes. In the context of the M-net, this amounts to finding a solution to the Multiple Traveling Salesman Problem (MTSP). There are many solutions that address this problem, one of which may be used in the M-net. Each of the M-nodes performs some form of modern routing optimization.

[0047] In some implementations, M-net is implemented as a decentralized IP multicast type network, i.e., to allow for fast spreading of incoming transactions into the blockchain network, multicast may be used to ensure that transactions are quickly broadcast throughout the M-net, allowing all M-nodes to then focus on forwarding the transaction to other nodes in the blockchain network.

[0048] Multicast network architecture allows the possibility of simultaneous distribution of data to a group of destination nodes without duplication of data for each node interested in receiving the information. If a node wishes to receive a multicast transmission, it will join the multicast group (registration phase) and will then be able to receive all data transmitted on the multicast group. IP multicast is capable of scaling to a larger population of receivers without requiring prior knowledge of how many receivers exist, and the network infrastructure is used efficiently by requiring the source to send a packet only once. Due to the nature of multicast networks, the use of connection-oriented protocols (such as TCP) is impractical due to the simultaneous communication with a large number of other nodes. Therefore, connectionless protocols are used.

[0049] Some blockchain networks, such as Bitcoin, use TCP for node-to-node communication. Data packets sent using TCP have an associated sequence number that is used for ordering. In addition to this, the TCP protocol includes a three-way handshake procedure both when establishing and terminating a connection. Packets sent over TCP come with associated overhead, they have an associated sequence number, and there is a three-way handshake protocol. To establish a connection, 128-136 bytes are sent, and to close a connection costs 160 bytes. Thus, the handshake in packet transmission costs at most 296 bytes. Furthermore, when a node receives a new transaction, it notifies other nodes with an inventory (INV) message that contains the hash of the transaction. A node that receives an INV message checks if the hash of the transaction has been found before; if not, the node requests the transaction by sending a GETDATA message. The time required to send a transaction from node A to node B is T1=verification+TCP(inv+getdata+tx) where TCP() denotes the overhead introduced by the TCP handshake procedure in terms of time.

[0050] M-nodes may be configured to use TCP for communication with other nodes, as is forced by existing protocols, such as Bitcoin. However, they may use a connectionless protocol, such as User Datagram Protocol (UDP), for M-node to M-node communication, or, more appropriately, for M-node to multiple M-node communication in a multicast situation. Unlike TCP, UDP does not include a handshake protocol, so M-nodes can propagate transactions more quickly. This can also prevent malicious nodes from associating with other nodes by sending repeated INV messages without sending the actual transaction.

[0051] The lightweight nature of UDP comes with certain trade-offs: less error checking and no error recovery. In some implementations, these limitations of UDP can be overcome at the application level by implementing error recovery, ordering, and retransmission as application layer functions. Performing error checking at the application level removes overhead from the network.

[0052] In one example, a regular node on a blockchain network generates a transaction that it wants to be processed through the M-net, such as a merchant-based payment. It can send the transaction to an M-node, which may then broadcast it to other M-nodes using multicast, or it may send the transaction directly to multiple M-nodes if it knows the IP multicast addresses of the M-nodes. In some examples, all M-nodes in an M-net are members of a single multicast address, and therefore all transactions sent to that address are received by all M-nodes; however, in some cases, there may be more than one multicast address associated with the M-net, and the receiving M-node may evaluate from routing information whether further broadcasting of the transaction to other multicast addresses is necessary to propagate the transaction to the complete M-net.

[0053] Multicast helps ensure fast initial propagation of new transactions to all M-nodes; however, multicast solutions do not necessarily address the scalability issues of blockchain networks that arise from increased transaction throughput. Each node in the network typically maintains a memory pool that contains transactions that have been discovered and not yet confirmed, but have not yet been incorporated into the blockchain by miners completing proof-of-work. A significant increase in the number of transactions resulting from their use in payment processing increases the amount of transactions to store in each memory pool. Thus, although nodes in an M-net can receive new transactions almost simultaneously, they may have storage capacity limitations for large and rapidly changing memory pools.

[0054] To address this issue, M-nodes can use shared memory, implemented by a distributed hash table (DHT), as an alternative to using multicast.

[0055] Average transaction (TX) size of 500 bytes, ~10 4 Assuming a transmission rate of TX / s, M-net can receive about 400GB of input data every day. All this data needs to be stored for various periods of time in a memory pool of unconfirmed transactions. Therefore, M-net requires significant storage and capacity to store data quickly. In order not to place too many demands on each individual M-node, M-node implements a shared memory that relies on the DHT. Instead of each M-node keeping all incoming TX in its own memory pool, each M-node only keeps a certain part of the whole, plus the hash of the remaining part and the associated key value.

[0056] DHT is a class of decentralized distributed systems that allows for the partitioning of membership of a set of keys among nodes and allows messages to be sent only to the owners of a given key in an efficient and optimized manner. Each node in the network can be seen as a cell in an array of hash tables. DHTs are designed to manage a large number of nodes, allowing new nodes to join the network and old nodes to leave and crash without compromising the integrity of the shared data. DHTs guarantee decentralization (there is no central authority or central coordination), scalability (the system works efficiently with millions of nodes), and fault tolerance (the system is reliable and can manage nodes that join, leave, or crash). Each node in the network can only keep in contact with a small number of other nodes, so the network does not become overloaded when there is a change or in the presence of new data.

[0057] The same concept can be applied to a UTXO database, a database that contains the set of all unspent outputs on a blockchain. A UTXO database can be built using a DHT to share content among a group of nodes.

[0058] There are many possible DHT architectures and protocols that could be used to implement shared memory for M-net. One example is Pastry™, but there are many others. Pastry™ is a protocol designed to maintain an overlay network capable of storing and transferring information in a distributed system. Each node in a Pastry™ network is assigned a 128-bit identifier, and identifiers range from (0 to 2 128 The ID is used to indicate the node's location in a circular node ID space (ranging from 0 to 1). The ID is randomly assigned when a node joins the network. Each node maintains a routing table, a neighbourhood set, and a leaf set.

[0059] One factor to consider in dimensioning a robust DHT is the number of replicas needed to guarantee robustness and reliability of the entire network. As already mentioned, nodes can join and leave the network, and this should not affect the availability of data. If a node that stores transaction A leaves the network, it needs to find transaction A in another part of the network. In existing blockchain networks, for example Bitcoin, the network has a number of blockchain replicas equal to the total number of nodes in the network (average 5000 replicas), which affects scalability.

[0060] In one M-net configuration, the memory pool is not fully replicated on all M-nodes, but instead is realized by a DHT. To provide reliability, the DHT may be implemented to have some overlap; that is, each transaction data item is replicated on more than one M-node, but not on every M-node. As an example, the DHT may be implemented to specify a minimum number of replicas of two. This results in a probability of two nodes going down at once in any given hour, which assumes complete independence between nodes as follows:

number

[0061] Thus, a process for storing a new transaction in a distributed memory pool includes the following steps, where the distributed memory pool is implemented using a DHT. The process includes a node sending the transaction to an M-node. The M-node hashes the transaction or a transaction ID, depending on the implementation, to obtain a key value. The key value specifies the M-node or multiple M-nodes (in case of replicated data) where the transaction should be stored. The M-node then stores the transaction in the distributed memory pool, and the process may include routing the transaction to the correct M-node where the transaction should be stored based on the key value and the assigned ID of the M-node in the M-net. The M-node may receive an acknowledgement depending on the DHT protocol involved. When the M-node receives a new transaction from a legitimate node, the M-node may perform a predefined verification operation to verify the authenticity of the transaction.

[0062] The transaction may be hashed to generate a key for the transaction. The key may indicate where in the DHT the transaction should be stored, which may be in a node other than the current M-node. The M-node then evaluates whether the transaction is already in a running DHT. Each M-node has a portion of the transaction stored based on a partition of the key space among the M-nodes that make up the M-net. In some configurations, the key space is partitioned among the participating M-nodes. This partition may include overlaps to cause duplication for network resiliency. In some implementations, such as using Pastry™, each M-node is assigned a unique key or ID number, and the transaction may be stored in the M-node, or in multiple M-nodes (if duplication is desired), based on proximity to the transaction's key value. The M-node may have locally stored portions of the transaction and a hash or key value of the remaining portion. Thus, the M-node can evaluate whether the new transaction is in the DHT based on its local data in operation.

[0063] If the transaction is not in 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 and stored there. Depending on the implementation chosen, the DHT can work according to various protocols on a distributed hash table. The use of the DHT to store transactions in the M-net avoids the use of INV / GETDATA messages in the M-net to route the transaction to all M-nodes.

[0064] In operation, the M-node, in this example, may send transactions to regular nodes in the blockchain network according to the blockchain network's normal transaction forwarding protocol, e.g., communications to regular nodes may use TCP for node-to-node connections.

[0065] In one configuration, the M-node includes a processor, a network interface, and memory. The M-node may be implemented using any suitable computing hardware having network connectivity and sufficient processing and memory resources to perform 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, although it will be understood that the 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.

[0066] The memory stores data including an allocated portion of the DHT-based memory pool based in part on its DHT key value, i.e., M-node ID. In this implementation, the memory further stores a routing table, a neighbor set, and a leaf set. The routing table includes a list of specific routing destinations in the M-net, and when a node receives a packet of data, it consults the routing table to know where to send the data. The routing table may also include information about how far each destination is from the M-node. The neighbor set includes information about nearby M-nodes, for example, based on a proximity metric (e.g., ping latency). The leaf set includes M-nodes that are numerically close. Multiple M-nodes are numerically close if their key values ​​(node ​​IDs) are numerically close. The memory further includes an M-node reputation table, as described further below.

[0067] In addition to implementing a memory pool using DHT to provide scalability, M-net allows nodes to join the M-net. A new node must have the address of at least one M-node in an already existing part of the M-net so it can direct a join request to one of the M-nodes. The M-node can perform predefined validation actions that may include querying the new node. For example, M-net may have a set of minimum criteria associated with joining the M-net that it specifies for an M-node. By way of example, the criteria may include a minimum amount of processing resources available, a minimum amount of free memory available, or a connection requirement.

[0068] Whatever verification operation is performed to verify the new node, assuming the M-node is complete, it forwards a Joinrequest() to the DHT according to whatever DHT protocol governs the operation of the DHT. The DHT then communicates with the new node, providing it with its routing table, key values ​​(node ​​ID), and any other data that enables the new node to act as a new M-node on the M-net.

[0069] It will be appreciated that the ease with which nodes may join the M-net creates a vulnerability that malicious nodes may join the network. To identify and isolate potentially malicious nodes, one configuration provides an M-node that stores an M-node reputation table that is used to track and update the behavior rankings of nodes. When a new node joins the network, it may be added to the M-node reputation table, as indicated by the node ID field. The table may also include a join time in some implementations. The table includes a score and a rating for the M-node.

[0070] Scores may be adjusted up or down based on certain behavioral metrics. For example, if an M-node fails to forward a transaction, remains silent for a period of time, floods M-net with traffic that is determined to be non-transactional, or engages in negative behavior, its ranking may be dropped or reduced. If a node's score falls below a pre-set minimum, the node may be removed from M-net.

[0071] The M-node reputation table maintained by a particular M-node may be limited to tracking the scores of its neighbors, not the complete M-net. Thus, if a new M-node joins the network at time t, its neighbors' M-node reputation tables contain no information about the new node, and from that point in time t, they start building the reputation of the new node storing information in their node register tables. For example, if the new node is a silent node, meaning it does not forward any information it receives on the network, all neighbors start recording this behavior in their respective M-node reputation tables, for example by assigning a negative value to the new node's ID. After some time t+n, if the M-node reputation tables of all nodes aware of the new node contain negative values, the node may decide to isolate the new node and ban it from the network.

[0072] Transactions in M-net's distributed memory pool may wait a significant amount of time before being confirmed, i.e., incorporated into a block that is added to the blockchain and confirmed. A block is considered "confirmed" when a sufficient number of subsequent blocks have been added to the blockchain above it, such that it is computationally infeasible to reverse the chain's growth and remove the block to change into a different branch or fork.

[0073] Due to the size and flexibility of the memory pool and the volume of transactions, it is possible that a given transaction may not be confirmed for a longer period of time than in some blockchain implementations, such as Bitcoin. In traditional Bitcoin implementations, a transaction is removed from the memory pool as soon as it is incorporated into a block. This means that if a block becomes an orphan block (a block without a parent block), all transactions in the block are resent on the network. This may be impractical and, in the case of high-speed transaction networks, may result in long delays to confirm a particular transaction.

[0074] Thus, in some implementations, the memory pool may track the number of confirmations of the block in which the transaction is embedded, i.e., the number of blocks added to the blockchain following the block in which the transaction is embedded. The transaction is removed from the memory pool only after a predefined number of confirmations have occurred. The predefined number may be 4, 5, 6, 7, or any suitable number for a given implementation. The memory pool data entry may be configured 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 memory pool data entry may simply record the block number. From the block number, it is possible to evaluate how many confirmations have occurred based on the current block number of the blockchain.

[0075] Once the required number of confirmations have been made, the transaction can be safely removed from the memory pool. This way, no transaction is lost in case of an orphan block, and the transaction is permanently deleted after the required number of confirmations.

[0076] The solution as described in the following parts of this specification uses a modified type of fast validating node as described above. A new full node configuration is described, which is an enhanced M-node validating architecture with large storage capacity and improved operating protocols. The M-node and storage nodes together constitute the core of the new full node. A new node structure is detailed, including the necessary technical requirements and technical solutions, and a sustainable incentive model is provided.

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

[0078] The block header contains: 1. Version number (4 bytes) 2. Hash of previous block header (32 bytes) 3. Merkle root hash (32 bytes) 4. Time (4 bytes) 5. Target Threshold (encoded as n bits - 4 bytes) 5. Nonce (4 bytes)

[0079] Currently, a block contains about 2000 transactions, and blocks are mined approximately every 10 minutes (the 10 minute block time is set as a compromise between the time of first confirmation and the time spent on chain splitting). This gives a transaction rate of about 3.5 transactions / second, with a theoretical maximum of 7 transactions / second. In contrast, VISA operates at a rate of about 10000 transactions / second, and can reach over 50000 transactions / second.

[0080] It is clear that in order to build a competitive payment system, some workaround for the current constraints is necessary. Since 10 minute block times are well established, it is mandatory to consider changes in block size, i.e. the blockchain itself. A scalable solution is described herein that can handle, for example, around 50000 transactions per second.

[0081] Increasing the current block size, or even removing the limit altogether, has been the subject of much discussion and at times contentious debate. Both maintaining the current size and increasing it offer significant benefits and tradeoffs, and there appear to be strong arguments on both sides.

[0082] Assuming the transaction rate is r, we can calculate the required block size. In what follows, a block time of 10 minutes (on average) is assumed, so let T(r) be the number of transactions per block. T(r) = r 6 10 2 block -1 s Tx is the average transaction size in bytes, then the block size B(r,s Tx ) can be expressed as follows: B(r,s Tx )=s Tx T(r)=s Tx r 6 10 2 Therefore, r = 50000 Txs / s and s Tx Considering a scenario where metric = 500 bytes, a simple back-of-envelope calculation becomes:

number

[0083] This is O(10 6 This leads to a storage requirement of 100,000 Mbps, 100,000 Mbps, and 100,000 Mbps of data. Blocks of this size clearly require a slightly different approach to both block propagation and storage. Table 1 below shows the transaction rate, average transaction size, block size, and the amount of storage space required monthly and yearly.

[0084] [Table 1] Table 1: Relationship between transaction rate, average transaction size, block size, and monthly and yearly storage space required

[0085] The New Bitcoin Network The proposed architecture for the Bitcoin network is shown in Figure 2, which shows a behavioral diagram illustrating the steps from when a user submits a transaction until it is completed on the blockchain.

[0086] A system is provided where specialized validator nodes (which maintain a shared memory pool among themselves by a distributed hash table DHT) receive transactions, validate them, and allocate them to the memory pool. The validator nodes then offer their services to provide miners with a list of valid transaction hashes. Miners try to solve the hash puzzle by assembling pre-blocks (block skeletons) based on these hashes. Once a solution to the puzzle is found, the winning miners send their block skeletons back to the validator nodes. These validate the block and ensure that it is stored. Initially, it is possible and feasible for the validator nodes to store the blocks themselves. When the block size eventually exceeds a certain threshold of size, the validator nodes: a) extend their own storage capabilities; or b) outsource the storage to specialized storage nodes. Two architectures are discussed later in this paper.

[0087] New Full Node With block sizes on the order of O(10) GB, relying on PC-type nodes to provide the storage capacity to host a full image of the blockchain no longer seems feasible. Instead, facilities providing O(1) PB or more storage are required (see Table 1). The problem then is to build a system that can accommodate new blocks while keeping the network decentralized, decentralized, and trustless.

[0088] There are two possible complete node structures, and two possible combinations of these: 1. Validation nodes with associated petabyte storage racks 2. Validation nodes with associated storage pools based on an internally decentralized, distributed peer-to-peer (P2P) single-node network, very similar to the current Bitcoin network itself. 3. Combination of 1 and 2

[0089] The proposed solution attempts to solve the problem of constantly maintaining a distributed and decentralized record of the blockchain by introducing nodes similar to the so-called full nodes that operate in the current Bitcoin network, but which, in contrast to the current Bitcoin network, have the ability to scale with the increase in the size of blocks and the number of transactions.

[0090] This difference is not limited to purely architectural and hardware-related issues. In contrast to home PC-based full nodes that run at the time of writing, the new nodes proposed here are specialized nodes. They require significant investments and are therefore incentivized very differently. In the scalable paradigm, both M-nodes (validation nodes) and new full nodes (combination of validation and storage nodes) expect to be compensated for their services.

[0091] At the other end of the spectrum, there are decentralized and decentralized storage solutions, most of which consist of individual nodes. Good examples are Storj (Wilkinson et al., 2016), Sia (NebulousLabs) and Maidsafe. In the case of Storj, its functionality is based on participants being rewarded for providing storage space.

[0092] As mentioned above, it is possible to envision a supernode consisting of both a petabyte (Pb) rack and a peer-to-peer (P2P) storage system.

[0093] Since the Bitcoin ecosystem relies heavily on the existence of multiple replicas of the entire blockchain distributed in a decentralized manner, it is obviously important that all full nodes are compensated. This is very different from mining, which is essentially a winner-takes-all game. Since miners rely on blocks to make it to the public blockchain, it is in their interest to compensate all storing nodes.

[0094] Nodes are grouped into pools that act as supernodes. To maintain the decentralized nature of the blockchain, there must be a certain number of such supernodes (100 or more). Supernodes are connected but do not overlap.

[0095] technical requirements As mentioned above, there are two entirely different architectures that must be considered when discussing new full nodes (see Table 2).

[0096] A new full node will need to maintain two types of storage: 1) Random Access Memory (RAM) like Distributed Hash Table (DHT) memory / storage for memory pool 2) Persistent tape / disk like storage for blockchain As mentioned above, for a transaction rate of r=50000Tx / s, blocks are expected to be O(10)Gb, which means ~365×24×6×15Gb=7.9 10 5 Gb=0.8Pb / yr This means annual storage requirements (see Table 1).

[0097] Table 2 shows the comparison between current and future full nodes: [Table 2]

[0098] At the same time, the rack / cluster needs to maintain a memory pool, which allows for fast block recovery. Evaluating the required size of the memory pool is more difficult. Currently, with a block size of about one megabyte (~1Mb) and about four transactions per second (~4Tx / s), the total size of transactions waiting in the memory pool fluctuates between 2 and about seventy megabytes (~70Mb). Figure 3 shows a graph showing the total size of transactions waiting in the memory pool for confirmation.

[0099] As mentioned above, we envisage two fundamentally different structures and their combinations that can store large amounts of data. The two structures are shown in Figures 4 and 5. Figure 4 shows a structure that includes multiple nodes with access to an internally centralized storage device. Figure 5 shows a structure where each node is part of both a distributed memory pool and a distributed storage device. The architecture depicted in Figure 4 seems suitable for larger entities that own and maintain several validating nodes, all of which have access to the entity's own storage device. In contrast, the architecture shown in Figure 5 is completely decentralized. It is a solution that is suitable for individual nodes that wish to participate in a shared distributed storage pool, such as a home-owned PC with ample storage capacity. The basic storage technology used for this already exists (e.g., Storj, Sia, MaidSafe).

[0100] One way to visualize how new full nodes fit into the Bitcoin network is shown in Figure 6, which shows a network configuration in which validating nodes are members of a storage pool. Together, the pools comprise the decentralized, distributed Bitcoin network.

[0101] Full Node Operation In the large block scenario, we face a different situation that is not just due to space requirements: the memory pool should be able to accommodate the equivalent of a block, i.e. about 15 gigabytes (~15Gb), preferably the equivalent amount for the next block to be excavated. This must be combined with overhead that must be considered. 1) The memory pool needs to be synchronized with other validating nodes. This involves exchanging Invertible Bloom filter Lookup Tables (Michael T. Goodrich, 2011) 2) The IBLT is scanned to retrieve any missing transactions (Tx's). 3) Any additional Tx acquired must be verified 4) Assemble blocks based on block skeletons received from miners and other full nodes. The new full node will have an up-to-date memory pool, which is achieved by the IBLT being exchanged with miners, other validating nodes, and the new full node.

[0102] Miners send block skeletons (tuples) that consist of: 1. Nonce, n 2.IBLT 3. Coinbase Transactions Based on this, the new full node orders the transactions accordingly (following a certain set of rules) and assembles the newly mined block. The new full node then proceeds to store the block in its own storage as well as propagate the skeleton to other new full nodes. The protocol is described in more detail later in this specification.

[0103] Incentives One important feature of this particular configuration is to build incentives into the system to encourage the provision of new node structures and services. Incentives are needed due to the significant costs associated with storing the blockchain. Figure 7 shows the functioning of new full nodes. New full nodes are primarily rewarded for two types of services: 1) A list of verified transactions is compiled and prepared for mining: the transaction hashes (Merkle root) are sent to miners who select from the list and mine a block. 2) The winning miner sends the skeleton of the mined block to some new full nodes. The skeleton contains the coinbase transaction and includes the following a-c: a.Mining rewards b. A secret that is part of a commitment scheme used as a payment mechanism to provide a verified list c. Payment for block validation and / or storage of blocks in the blockchain.

[0104] [Transactions] Verifier nodes are compensated for validating transactions via a pay-to-play system. Recipient validators / new full nodes are rewarded for one or more of the following: 1) Providing miners with a list of validated transaction (Tx) hashes (see b. above). 2) Reassembling blocks from the block skeleton (for a "flat rate" fee). 3) Size of the blocks (paid per "MB storage").

[0105] The incentive is 100 block confirmation time T 100 It is between. 1) Miners wait until t~T to claim their rewards 100 You need to wait for a period of time. 2) Validation nodes must wait t~T before they receive their fees for validating a block Tx. 100 You need to wait for a period of time. 3) A new full node can receive block construction fees and size-dependent storage payments within t~T 100 You need to wait for a period of time.

[0106] Therefore, the 100 block confirmation time provides miners with the necessary incentive to propagate skeleton blocks (including payments) to a range of new full nodes, which will be stimulated to propagate skeleton blocks to other new full nodes.

[0107] It should also be pointed out that miners are free to choose the list of transactions they wish to be included in a block. Thus, we can envision a market with competing validating nodes by compiling a list of validated transactions that miners can select and purchase through commitment transactions.

[0108] Revised Mining The Bitcoin ecosystem relies on the mining process. Miners collect transactions (Txs) from a memory pool (or from special validating nodes, as we assume here), organize them into blocks, and try to find a solution (nonce) to solve a hash puzzle. The block header contains the hash of the previous block in the blockchain, the root of the Merkle tree of transactions, and the nonce included by the miner. Solving the puzzle consists of computing the double SHA256 hash of the previous block hash and the nonce (chosen iteratively) concatenated with the Merkle root, and checking if it is less than the so-called difficulty target. If it is less than the nonce, the puzzle is solved, if it is more than it, the iterations on the nonce continue. This remains the same in the new paradigm. What poses the problem is the very enlarged block size and the distribution of mined blocks across the network. With Gb-sized blocks, it is not necessarily mandatory to broadcast the entire block in the network.

[0109] Rather we propose a solution that follows these steps: 1. The miner receives a list of validated transactions from the validating / M-nodes and / or new full nodes. 2. Miners themselves may or may not operate their own memory pools of Tx hash values ​​that follow a given ordering convention, an example of such ordering is shown below. [https: / / www.cryptocoinsnews.com / bitcoin-in-bloom-how-iblts-allow-bitcoin-scale / ] 3. The miner solves the hash puzzle by determining a nonce, n. 4. Next, a hash tree (Merkle tree, referred to here as HT) is computed and the root of the tree is stored (see next section). 5. This list of Txs is used to create an IBLT, which can be used to calculate the content difference between two sets (e.g., of memory pools) and reconcile the two sets. 6. The tuple {n;IBLT;CoinbaseTx:HTRoot} is broadcast to the validating / M-nodes. 7. The new full nodes will operate the DHT for storage and memory pools related to the blockchain. 8. The pool reassembles the block based on the tuple {n;IBLT;CoinbaseTx:HTroot} and records the block on the blockchain by a) storing it itself or b) storing it in a specialized storage node.

[0110] Avoiding competition between miners Miners could select a list of validated transactions from a marketplace consisting of several validating nodes. Unless otherwise stated, it is reasonable to assume that miners will select the list that maximizes their potential profits. The careful reader may point out that this may lead to miners selecting the same list primarily from the same nodes. This would lead to a situation where several miners would compete with each other to mine the same block. This would favor the miners with the greatest hashing power.

[0111] We propose to add an additional field to the block header, which contains a random number chosen by each miner. This will ensure that each miner starts from a different starting point, and therefore prevent the search for a solution to the block from simply being reduced to a matter of hashing power. This is similar to the current situation, where miners tend to mine similar, but slightly different, blocks chosen individually.

[0112] protocol Here we describe the protocol required to run the new full nodes. For the proposed system to work, the memory pools of the participating nodes (validators, miners, new full nodes, etc.) should follow a transaction ordering rule. Here we propose to use the canonical ordering proposed by Gavin Andersen, where the ordering concerns the list of transactions in a block, but here we present the idea that all validators and new full nodes use the same rules for their memory pools.

[0113] The rules can be summarised as follows: 1) Sort the transactions in ascending order with respect to the hash of the previous transaction. 2) Add the first transaction from the ordered list that does not depend on any subsequent transactions.

[0114] As mentioned before, a block contains the so-called Merkle root hash, which is generated by hashing all transactions, including the coinbase transaction, and then hashing the concatenation of hashes until we arrive at the Merkle root hash. It is clear that, were it not for the fact that miners produce coinbase transactions, a validating node could calculate the entire Merkle tree, and thus the Merkle root and its corresponding hash.

[0115] Here we propose a Merkle tree that is computed using the following procedure: Validating nodes compute a Little Merkle Root. The procedure is the same as for computing a standard Merkle Root, with a few exceptions: 1) The coinbase transaction is eliminated. 2) So-called communication transactions are included. 3) The miner generates a coinbase transaction and concatenates it with the little Merkle root hash to generate the Merkle root hash.

[0116] This is illustrated in Figure 8, which shows the new Merkle tree structure. Note that this is a modification to the current protocol.

[0117] Modifications to block headers As mentioned above, we propose to add an extra field to the block header that contains a random number chosen by the miner, so solving the hash puzzle would change as follows:

number

[0118] We therefore propose that the block header of new blocks mined be enhanced with an additional field containing a random number. The block header contains: 1. Version number (4 bytes) 2. Hash of the previous block header (32 bytes) 3. Merkle root hash (32 bytes) 4. Time (4 bytes) 5. Target Threshold (encoded as n bits - 4 bytes) 6. Nonce (4 bytes) 7. Random number (4 bytes)

[0119] Validation → Minor Validation node: Upon request, a validating node (which may or may not be a new full node) prepares a list of validated transactions to be mined. A validator node creates a commitment transaction. A so-called Little Merkle Root (see previous section) is calculated with the included commitment transactions. ○ IBLT with two validator nodes: 1) for every transaction in the block (IBLT1); and 2) For all corresponding TRxIDs in the block (IBLT2) Prepare the following. ○ Verifier nodes to miners: 1) Little Merkle Route 2) IBLT1 3) IBLT2 (optional - only if miner works with its own TxID- / memory pool) 4) Predecessor block hash 5) The hash checksum of the above Send.

[0120] minor: Upon receiving the data from the validator node, the miner proceeds to create a coinbase transaction, which contains the reward for mining and the reward for block validation / storage in the new full node (where the miner wants to send the mined block). Additionally, the coinbase transaction contains an output field with a secret that matches the secret in the commitment transaction. Miners use the Little Merkle Root received from the validator nodes and combine it with the coinbase transaction to create the Merkle Root hash. ○ Miners now have all the information they need to start solving the hash puzzle. Mining proceeds in the manner described above.

[0121] Miner → New full node minor: Once a block is mined, the miner sends the following to a new list of full nodes: ○ Nonce (solution to the puzzle), n ○ Coinbase Transactions ○ Block Header ○ Merkle Root ○ Little Merkle Route ○ IBLT1 ○ IBLT2 (optional) ○ Hash checksum

[0122] New Full Node: ○ Check if the coinbase transaction has the appropriate reward. o A node verifies that received data is consistent by calculating a checksum (hash). ○ A node uses IBLT1 to ensure that a blocked transaction exists in the memory pool. ○ The node assembles the block by querying its memory pool using IBLT1, which is then stored (see the section on new full nodes and storage). Data received from miners is broadcast to other new full nodes.

[0123] Customized Transaction List We envision a situation where the market for transactions to be validated matches the needs of miners: miners will tend to pick lists that maximize their chances, and validating M-nodes will pick up on those trends.

[0124] There may be cases where a miner wants to customize his block by combining transactions from two or more lists. It is possible to perform set reconciliation between the two sets by computing the difference between the two IBLTs. The miner then sends the IBLT containing the difference back to one of the contributing nodes, thus obtaining the necessary information to create a list, which contains all transactions that are in both lists.

[0125] Further challenges seem to arise if miners want to create their own lists based on several lists. We will briefly mention the various points here.

[0126] If miners combine lists from various validating nodes, it is unclear how the Merkle root should be combined. Here we propose the following: Constructing a Big Little Merkle root for each Little Merkle root; and Combining Big and Little Merkle Root with Coinbase transactions.

[0127] The additional cost is not proportional to the amount of additional transactions added to the list / block. It is reasonable to assume that the various memory pools will overlap significantly, so combining lists would result in adding a small number of transactions (relatively speaking) from different lists. However, to combine lists, miners would have to "buy" full lists (by commitment transactions) from each validator node. It remains to be seen whether this will be a profitable approach for miners.

[0128] Combining lists from several validating nodes requires a commitment between the miner and each of the contributing validating nodes. It is possible to imagine an abuse of this system by miners. Currently there is no rule / protocol that enforces that all commitment transactions end up in a block. One possibility is that validating nodes can check each block and reject blocks that contain transactions.

[0129] Summary Today's Bitcoin network is very miner-centric in terms of computational effort. With the massive increase in transaction volume, this is not always feasible. The solution described herein leads to delegating different tasks to correspondingly specialized nodes, leading miners to specialize themselves even more. Compiling a list of verified transactions, reconstructing blocks based on the block skeleton, and storing them are all functions that require significant resources. It is therefore expected that the structure of the Bitcoin network will change, and with it the incentives. These issues have been discussed in detail herein.

[0130] Among the new elements introduced in this specification, the following can be mentioned: o A new type of node structure, referred to herein as a new full node or super node, which may or may not be an extension to validating M-nodes. ○ Nodes operate on a protocol that efficiently enables the broadcast of Gb-sized blocks both from validating 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 nodes. ○ An incentive model that allows for the creation of a market for pre-block lists of transactions to be validated, and for the assembly and storage of blocks. ○ A new Merkle tree structure that relieves miners from the need to maintain their own memory pools. Addition of an extra field in the block header with a random number, chosen by the miners, to avoid the mining activity becoming merely a race based on hashing power. ○ Verification is rewarded using special commitment transactions.

[0131] Bloom Filters and IBLTs In this section we summarize the properties of so-called "Bloom filters" and their extension to what we call "reversible Bloom lookup tables".

[0132] In its simplest form, a Bloom filter is an array. The array has two parameters associated with it: M and k. M is the number of bits in the array, and k is the number of different hash functions H, such as k is the number of

number

[0133] If one or more are not, then Tx0 is definitely not in the target set. However, Bloom filters allow for false positives. This is because the probability of a hash function changing a bit to 1 is p=1 / |size of array|=1 / M Therefore, the so-called

number

number

number

[0134] One obvious drawback of Bloom filters is that they do not track or maintain any particular order. It quickly becomes apparent that if we want to maintain an index of the items being filtered, we need to extend the functionality of the filter. Here we enter the world of Reversible Bloom Filters (IBFs) and Reversible Bloom Lookup Tables (IBLTs).

[0135] In addition to activating bits in the array, the XOR sum of the key, the hash value (as described above), and an overall counter are stored in each field of the IBF. This procedure is illustrated in Figure 10, which shows the workflow of how a transaction is encoded in the IBF / IBLT.

[0136] application Suppose we have two nodes N1 and N2, each of which maintains a memory pool m1 and m2. Each memory pool contains the entire hexadecimal string S 16 We further assume that the memory pool follows an ordering convention, as proposed by Andresen and outlined herein above. N1 sends m1 to N2, which can now approach set reconciliation in two ways: 1) Calculate the set difference by Δm = m2 - m1 (see (David Eppstein, 2011), (Michael T. Goodrich, 2011)). 2) Iterate over the transactions in m2 and check if they are in N1's memory pool.

[0137] It turns out that IBLT can be used for at least two purposes: 1) Allowing nodes to assemble mined blocks based on the transactions they already have in their memory pool, and helping them identify and acquire blocks they do not have. 2) Maintaining a certain level of synchronization between memory pools belonging to different nodes.

[0138] Although transactions can transfer bitcoin, it should be understood that users can exchange other resources using the methods and systems described herein, such as information, contracts, and tokens. A token represents an asset or resource according to a smart contract associated with the token, such that control of the token results in control of the asset or resource. The smart contract itself may be stored outside the blockchain or may be stored within one or more transactions.

[0139] References An Integrated World.(nd).Retrieved from https: / / www.anintegratedworld.com / whats-in-a-block / David Eppstein,MT(2011).What's the Difference? Efficient Set Reconciliation without Prior Context.ACM. maidsafe.(nd).Retrieved from github.com: https: / / github.com / maidsafe / Whitepapers Michael T.Goodrich,MM(2011).Invertible Bloom Lookup Tables.Communication, Control, and Computing(Allerton),2011 49th Annual Allerton Conference on. NebulousLabs.(nd).Retrieved from github.com: https: / / github.com / NebulousLabs / Sia O(1) Block Propagation. (nd).Retrieved from github.com:https: / / gist.github.com / gavinandresen / e20c3b5a1d4b97f79ac2 Wikipedia.(nd).Retrieved from https: / / en.wikipedia.org / wiki / Distributed_hash_table Wilkinson et al. (2016, December 15). Retrieved from https: / / storj.io / storj.pdf

[0140] It should be noted that the above-described embodiments are illustrative of the invention rather than limiting it, and that those skilled in the art can design many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the scope of the claims. The words "comprising" and "comprises" and the like do not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "comprising" means "comprising or consisting of" and "comprising" means "comprising or consisting of". The singular reference of an element does not exclude the reference of a plurality of such elements and vice versa. The invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that several items are recited in mutually different dependent claims does not indicate that a combination of these items cannot be used to advantage.

[0141] (Appendix 1) 1. A computer-implemented method for a transaction validating node of a blockchain network, comprising: (i) receiving a transaction from the blockchain network; (ii) validating the transactions received from the blockchain network; (iii) maintaining, together with other transaction validating nodes in the blockchain network, a distributed, decentralized storage of validated transactions; and (iv) distributing data corresponding to the verified transactions onto the blockchain network for mining; The method includes: (Appendix 2) 2. The computer-implemented method of claim 1, wherein maintaining distributed, decentralized storage of verified transactions with other transaction validation nodes in the blockchain network includes synchronizing transaction validation nodes in the blockchain network to maintain an up-to-date list of verified transactions in a decentralized, distributed manner. (Appendix 3) 3. The computer-implemented method of claim 2, wherein the validator nodes are synchronized by exchanging reversible Bloom filter lookup tables. (Appendix 4) 4. The computer-implemented method of claim 1, wherein the verified transactions are sorted in a pre-defined order such that a common ordering scheme is used across transaction verification nodes in the blockchain network to maintain distributed, decentralized storage of the verified transactions. (Appendix 5) 5. The computer-implemented method of claim 4, wherein the validated transactions are sorted into an order determined utilizing a canonical ordering scheme to maintain a distributed, decentralized storage of the validated transactions. (Appendix 6) The step of distributing data corresponding to the verified transactions to the blockchain network for mining comprises: Preparing data corresponding to the list of verified transactions 6. The computer-implemented method of any one of claims 1-5, comprising: (Appendix 7) The step of distributing data corresponding to the verified transactions to the blockchain network for mining comprises: creating a digital asset commitment transaction in return for providing the miner with the data corresponding to the list of verified transactions; 7. The computer-implemented method of any one of claims 1-6, comprising: (Appendix 8) 8. The computer-implemented method of claim 7, wherein a hash tree, Patricia tree, or other type of radix tree is computed along with the included commitment transactions. (Appendix 9) 9. The computer-implemented method of any one of claims 1-8, wherein the data corresponding to the verified transactions is distributed to the blockchain network in the form of a reversible Bloom lookup table and any associated data. (Appendix 10) (v) receiving mined data from the blockchain network corresponding to the verified transaction; (vi) assembling a plurality of blocks based on the mined data; and (vii) sending the assembled blocks to a storage entity for storage in the blockchain; 10. The computer-implemented method of any one of claims 1-9, further comprising: (Appendix 11) 11. The computer-implemented method of claim 10, wherein the mined data received from the blockchain network includes a block header corresponding to the verified transaction. (Appendix 12) 12. The computer-implemented method of claim 10 or 11, wherein the mined data includes transactions of digital assets in return for assembling blocks based on the mined data. (Appendix 13) 13. The computer-implemented method of any one of claims 10-12, wherein the mined data includes transactions of digital assets in return for storing assembled blocks. (Appendix 14) 14. The computer-implemented method of claim 12 or 13, further comprising a condition to wait a period of time t associated with a minimum number of blocks before accepting the digital asset. (Appendix 15) 15. The computer-implemented method of any one of claims 10-14, wherein the step of assembling a plurality of blocks based on the mined data includes assembling large blocks, each block having a size of at least 2 megabytes. (Appendix 16) 16. The computer-implemented method of any one of Clauses 10-15, wherein the block includes a block header including a random number provided by a miner. (Appendix 17) 17. The computer-implemented method of any one of claims 10-16, wherein the storage entity is shared among a plurality of transaction verification nodes in the blockchain network, the plurality of transaction verification nodes forming a supernode in the blockchain network, and the shared storage entity is either a common storage node, a distributed storage, or a combination of both. (Appendix 18) A computer-readable storage medium comprising computer-executable instructions that, when executed, configure a processor to perform the method of any one of claims 1-17. (Appendix 19) Interface devices; one or more processors coupled to the interface device; a memory coupled to said one or more processors; wherein the memory stores computer readable instructions that, when executed, configure the one or more processors to perform a method according to any one of claims 1-17. (Appendix 20) A transaction validation node of a blockchain configured to perform a method according to any one of appendixes 1-17. (Appendix 21) A plurality of validating nodes according to claim 20; and a shared storage entity that stores said blockchain; a blockchain supernode, the shared storage entity being either a common storage node, a distributed storage, or a combination of both; Blocks assembled by the multiple validating nodes are sent to and stored in the shared storage entity, which maintains the blockchain; and a supernode. (Appendix 22) 22. The super node of claim 21, wherein the shared storage entity has a storage capacity of at least 100 gigabytes. (Appendix 23) A blockchain network including a plurality of supernodes according to claim 22 or 23, A blockchain network, wherein the supernodes are connected in the blockchain network, and the shared storage entity of each supernode is configured to store a copy of the blockchain, and the blockchain network includes at least 10 supernodes.

Claims

1. 1. A computer-implemented method for a transaction validating node of a blockchain network, comprising: (i) receiving a transaction from the blockchain network; (ii) validating the transaction received from the blockchain network; (iii) maintaining distributed, decentralized storage of verified transactions with other transaction validating nodes in the blockchain network; and maintaining a distributed, decentralized storage of verified transactions with other transaction verification nodes in the blockchain network includes synchronizing transaction verification nodes in the blockchain network to maintain an up-to-date list of verified transactions in a decentralized, decentralized manner; The method of claim 1, wherein the validating nodes are synchronized by exchanging reversible Bloom filter lookup tables.

2. 2. The method of claim 1, wherein the verified transactions are sorted in a predetermined order such that a common ordering scheme is used across transaction verification nodes in the blockchain network to maintain distributed, decentralized storage of the verified transactions.

3. 3. The method of claim 2, wherein to maintain a distributed, decentralized storage of the validated transactions, the validated transactions are sorted into a predetermined order utilizing a regular ordering scheme.

4. 4. The method of claim 3, wherein sorting the verified transactions into a predetermined order utilizing a regular ordering scheme comprises: Order the transactions in ascending order with respect to the hash of the previous transaction; and Adding a transaction that is independent of subsequent transactions A method carried out by.

5. 5. The method according to claim 1, wherein the step of distributing data corresponding to verified transactions to the blockchain network for mining comprises: preparing data corresponding to a list of verified transactions; A method comprising:

6. 6. The method of claim 5, wherein distributing data corresponding to the verified transactions to the blockchain network for mining comprises: creating a digital asset commitment transaction in return for providing the data corresponding to the list of verified transactions to a miner; A method comprising:

7. 7. The method of claim 6, wherein a hash tree, a Patricia tree, or another type of radix tree is computed along with the included commitment transactions.

8. 8. The method of claim 1, wherein data corresponding to the verified transactions is distributed to the blockchain network in the form of a reversible Bloom lookup table and any associated data.

9. The method according to any one of claims 1 to 8, (v) receiving mined data from the blockchain network corresponding to the verified transaction; (vi) constructing blocks based on the mined data; and (vii) sending the assembled blocks to a storage entity for storage on the blockchain; The method includes:

10. 10. The method of claim 9, wherein the mined data received from the blockchain network includes a block header corresponding to the verified transaction.

11. 11. The method of claim 9 or 10, wherein the mined data includes transactions of digital assets in return for assembling blocks based on the mined data.

12. 12. The method of any one of claims 9-11, wherein the mined data includes transactions of digital assets in return for storing assembled blocks.

13. 13. The method of claim 11 or 12, further comprising a condition to wait a period of time t associated with a minimum number of blocks before accepting the digital asset.

14. 14. The method of any one of claims 9-13, wherein assembling a plurality of blocks based on the mined data includes assembling large blocks, each block having a size of at least 2 megabytes.

15. 15. The method of any one of claims 9-14, wherein the block includes a block header that includes a random number provided by a miner.

16. 16. The method of any one of claims 9-15, wherein the storage entity is shared among a plurality of transaction validation nodes in the blockchain network, the plurality of transaction validation nodes forming a supernode in the blockchain network, and the shared storage entity is either a common storage node, a distributed storage, or a combination of both.

17. A computer readable storage medium comprising computer executable instructions which, when executed, configure a processor to perform the method of any one of claims 1-16.

18. interface devices; one or more processors coupled to the interface device; a memory coupled to the one or more processors; 17. An electronic device comprising: said memory storing computer executable instructions which, when executed, configure said processor to perform a method according to any one of claims 1 to 16.

19. A transaction validation node of a blockchain network configured to perform the method of any one of claims 1-16.

20. A plurality of verification nodes according to claim 19; and a shared storage entity that stores the blockchain; A super node of a blockchain network, comprising: A super node, wherein blocks assembled by the plurality of validating nodes are sent to and stored in the shared storage entity, which maintains the blockchain.

21. 21. The super node of claim 20, wherein the shared storage entity has a storage capacity of at least 100 gigabytes.

22. A blockchain network including a plurality of super nodes according to claim 20 or 21, A blockchain network, wherein the supernodes are connected in the blockchain network, and the shared storage entity of each supernode is configured to store a copy of the blockchain, and the blockchain network includes at least 10 supernodes.

Images