How to become a node in a blockchain network

Abstract

To provide a modified blockchain node structure, network architecture, and protocol for managing large volumes of transactions and large transaction blocks.SOLUTION: A computer implemented method for a node of a blockchain network includes: receiving mined data corresponding to a plurality of verified transactions from the blockchain network; assembling blocks based on the mined data; and sending the assembled blocks to a storage entity for storage on a blockchain.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] This specification generally relates to computer-implemented methods and systems suitable for implementation in nodes of a blockchain network. 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 for, but not limited to, use with the Bitcoin blockchain. [Background technology]

[0002] The term "blockchain" is used herein to include all forms of electronic, computer-based, distributed ledgers, including, but 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. While reference may be made to Bitcoin herein 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 decentralized, distributed computer-based system composed of blocks, each of which consists 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 written to the blockchain since inception. Transactions contain small programs called scripts that are embedded in the transaction's inputs and outputs; 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 each transaction is valid; invalid transactions are rejected by the network. For example, a software client installed on a 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 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 valid, relayed by that node to other nodes in the network; 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 enough blocks have been added to the blockchain to make it effectively irreversible.

[0005] While blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are beginning to explore using both the cryptographic security system on which Bitcoin is based 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 automated tasks and processes that are not purely limited to cryptocurrency payments. Such solutions could utilize the benefits of blockchain (e.g., permanent, tamper-proof records of events, distributed processing, etc.) while further diversifying their applications.

[0006] One area of ​​research is the use of blockchain for the implementation of "smart contracts," which 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 containing rules that can process inputs to produce outcomes and then perform actions depending 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 that receives financial transactions from one or more user devices, authenticates the financial transactions using multiple authentication servers implementing a multi-signature authentication system, aggregates 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.

[0009] CN106548349 addresses the problem that if all nodes in a blockchain network were required to verify the transaction information of every transaction, this process would generate a significant workload and place a great deal of pressure on the nodes. The solution described in CN106548349 is to propagate transaction information from a first node to multiple selected second nodes to verify the transaction information, rather than requiring all nodes to 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 resource transfers 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, a sale can be reliably completed without waiting for the next block on the blockchain to be established. It also discloses that the validator node can distribute validation requests to a set of validator nodes and receive responses from the set of validator nodes. The validator node can 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 series of transactions that have taken place since the most recently established block, and the next block will include this series 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 through mining, where mining nodes select a set of transactions, group the transactions into prototype blocks, and determine the value of a nonce using the traditional "proof-of-work" method. Once a miner discovers a valid nonce, the block is validated by other nodes and incorporated into the blockchain.

[0012] US2015 / 0310424 discloses a system for generating user directory data through multimodal cryptographic key-address mapping. A cryptocurrency network includes cryptographic nodes that publicly validate a set of cryptocurrency user transactions. Nodes can 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 approximately 2,000 transactions, with blocks being mined approximately every 10 minutes (the 10-minute block time is set as a compromise between the time required for first confirmation and the time spent on chain splits). This provides a transaction processing speed of approximately 3.5 transactions per second. In contrast, the VISA system operates at a transaction processing speed of approximately 10,000 transactions per second, and can reach over 50,000 transactions per second.

[0014] It is clear that to build a competitive payment system, the current limitations of blockchain networks must somehow be circumvented. Since a 10-minute block time is well established, it is imperative to consider changes to the block size, and therefore the blockchain itself. A scalable solution capable of handling, for example, approximately 50,000 transactions per second, is described herein. Importantly, a solution is provided that can support high transaction speeds while maintaining a decentralized, distributed system architecture.

[0015] The transition from the Bitcoin network's current architecture to one capable of processing a large number of simultaneous transactions places infrastructure strain 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 decentralized approach has been 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 size, and if block size exceeds a predetermined limit, storage infrastructure issues will arise. This document describes a solution to the problem of processing and storing large gigabyte-sized blocks.

[0016] This specification describes a modified blockchain network architecture that includes multiple dedicated transaction validation nodes configured to validate transactions and, together with other transaction validation nodes in the blockchain network, maintain distributed, decentralized storage of the validated transactions. The transaction validation nodes are further configured to prepare lists of validated transactions for miners and, in exchange for providing the lists of validated transactions to miners, create commitment transactions for digital assets. Thus, the dedicated transaction validation 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 transactions are mined, the mined transactions are returned to the transaction validation nodes, which then build large blocks of the mined transactions and store the large blocks in dedicated storage nodes.

[0017] One aspect of the present invention relates to post-mining functionality. A computer-implemented method for a node of a blockchain network is provided, the computer-implemented method comprising: receiving mined data from the blockchain network corresponding to the plurality of verified transactions; Assembling blocks based on the mined data; and The method includes sending the assembled blocks to a storage entity for storage in the blockchain.

[0018] Such an approach allows nodes to construct large blocks that are stored in storage entities, rather than requiring miners to construct and store large blocks and transmit such blocks over the blockchain network. Furthermore, this architecture allows for the use of large storage entities dedicated to storing large, ever-growing blockchains.

[0019] The computer-implemented method further comprises: Receiving transactions from the blockchain network; Validating transactions received from the blockchain network; maintaining a distributed, decentralized storage of validated transactions with other nodes in the blockchain network; and Distributing data corresponding to the validated transactions, the data including lists of the validated transactions, to a blockchain network for mining, each list capable of providing a complete list of the validated transactions for mining into blocks.

[0020] Such a method effectively eliminates the requirement for miners to perform validation functions while maintaining distributed, decentralized storage of validated transactions with other nodes in the blockchain network. Furthermore, the method allows transaction validating nodes to provide a service to miners by preparing and distributing data corresponding to validated transactions to the blockchain network for mining. For example, the method allows a list of validated transactions to be prepared and distributed.

[0021] Maintaining distributed, decentralized storage of 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. Validated transactions can also be sorted in a defined order such that a common ordering system is used across transaction validating nodes in the blockchain network to maintain the distributed, decentralized storage of verified transactions. For example, a canonical ordering system can be used to maintain the distributed, decentralized storage of 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 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). Further, distributing 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 another type of radix tree can be computed along with the included commitment transactions.

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

[0024] The mined data received from the blockchain network may include block headers corresponding to verified transactions. The mined data may also include digital asset transactions for assembling and / or storing blocks based on the mined data. The method may further include a condition to wait 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 so 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, which in turn 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 having a size of at least 2, 4, 6, 8, 10, 50, 100, 500, 1000, or 10,000 megabytes. A nominal upper limit of 1 petabyte may be specified, although the upper limit will increase over time. Each block may contain, for example, at least 5,000, 10,000, 50,000, 100,000, 500,000, or 1,000,000 transactions. The upper limit will increase over time, but a nominal upper limit of 10000 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 rates.

[0026] In the methods described herein, blocks can be modified to include a block header that includes a random number provided by the miner. That is, transaction validating nodes, when receiving resolved transactions from the blockchain network, can be configured to process blocks that include a block header that includes a random number provided by the miner. This constitutes a modification to the block header, whereby miners can choose or randomly generate the number inserted into the block header. This helps ensure that miners do not compete to mine the same block, even if the same transaction list is selected 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 multiple transaction validating nodes form a super node 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 allows for the formation of super nodes on the blockchain network and the provision of dedicated storage devices for storing the blockchain and providing services to the blockchain network.

[0028] In view of the above, super nodes of the blockchain network are also provided, which super nodes will: 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 then maintains the blockchain.

[0029] This architecture is better suited to handling the large 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 will increase over time, but is not limited to 10 6 Terabytes, possibly 10 6 A nominal upper limit of yottabytes may be specified.

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

[0031] 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 that includes: 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. Furthermore, 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] US 2015 / 0287026 discloses that once a financial transaction is propagated through a cryptocurrency network, it can be incorporated into a public shared ledger by miner entities of the cryptocurrency network in a standard manner. Accordingly, US 2015 / 0287026 does not disclose nodes that collect and assemble large blocks of mined transactions on behalf of miners for storage on the blockchain using specialized storage nodes. Furthermore, US 2015 / 0287026 does not disclose that the mined data includes digital asset transactions in exchange for assembling blocks based on the mined data and / or storing the assembled blocks.

[0034] Similarly, CN106548349, WO2017 / 162904, US2016 / 0259937, WO2017 / 004527, WO2017 / 011601, and US2015 / 0310424 do not disclose nodes that collect and construct large blocks of mined transactions on behalf of miners for storage on the blockchain using specialized storage nodes. Furthermore, these documents do not disclose that mined data includes digital asset transactions in exchange for assembling blocks based on the mined data and / or storing the assembled blocks. Rather, the documents disclose a standard mining procedure using current blockchain network architecture, in which a mining node selects a set of transactions, groups the transactions into a prototype block, determines the value of a nonce using traditional "proof-of-work" methods, and, once the miner finds a valid nonce, the block is validated by other nodes and incorporated into the blockchain.

[0035] In light of the above, it is believed that the present invention provides a unique architecture and method for more efficiently processing and storing large gigabyte-sized blocks within a blockchain network. [Brief explanation 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 will be 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. [Figure 2] Figure 2 shows the modified architecture of the Bitcoin network with a behavioral diagram showing the steps from when a user submits a transaction to when it finishes on the blockchain. [Figure 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. [Figure 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 a 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 in a Reversible Bloom Filter (IBF) and a Reversible Bloom Lookup Table (IBLT). DETAILED DESCRIPTION OF THE INVENTION

[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 an invitation and without consent from other members. Distributed electronic devices running an instance of the blockchain protocol on which the blockchain network operates can 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 one another 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 dispersed locations.

[0041] Currently, nodes maintain a global ledger of all transactions on the blockchain, which 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, maintaining the validity of the global ledger. Details of the implementation and operation of blockchain networks, such as those using 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 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 function. It has been suggested that there are four basic functions associated with nodes: wallet, mining, full blockchain maintenance, and network routing. Variations on these functions may 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 perform wallet and network routing functions. Rather than storing the entire blockchain, digital wallets can track block headers, which 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 the 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 enables the 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, an M-Node is permitted a number of incoming and especially outgoing connections, as may be permitted for nodes under the governing protocol.

[0045] M-Nodes may be collectively referred to as a merchant network (or "M-net"). The term "merchant" may be interpreted as meaning "specialized." M-Nodes may be integrated into a blockchain network. Each M-Node is a specialized node in the blockchain network and meets specific 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 specialized functions or services.

[0046] For the M-net to operate 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 to this problem, and one of them may be used in the M-net. Each M-node performs some form of modern routing optimization.

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

[0048] Multicast network architecture allows for the 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 joins the multicast group (the registration phase) and will then be able to receive all data transmitted on the multicast group. IP multicast does not require prior knowledge of how many receivers exist, making it possible to scale to a larger receiver population, and the network infrastructure is used efficiently by requiring the source to send packets 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 many 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 used for ordering. In addition, the TCP protocol includes a three-way handshake procedure both when establishing and terminating a connection. Packets sent over TCP arrive with associated overhead, they have associated sequence numbers, and there is a three-way handshake protocol. Establishing a connection costs 128–136 bytes, and closing 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 containing the transaction's hash. A node receiving the INV message checks whether the transaction's hash has been previously discovered; if not, it claims 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) and 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 mandated by existing protocols, such as Bitcoin. However, they may use connectionless protocols such as User Datagram Protocol (UDP) for M-node-to-M-node communication, or more appropriately, for communication from an M-node to multiple M-nodes in a multicast situation. Unlike TCP, UDP does not include a handshake protocol, allowing M-nodes to propagate transactions more quickly. This can also prevent malicious nodes from associating with other nodes by sending repeated INV messages without sending any actual transactions.

[0051] The lightweight nature of UDP comes with certain trade-offs: it has little 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. 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 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 M-nodes' IP multicast addresses. 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 full 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 containing discovered, unconfirmed transactions that 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 stored in each memory pool. Thus, although nodes in an M-net can receive new transactions nearly 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 approximately 400 GB of input data every day. All of 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. To avoid placing too many demands on each individual M-node, M-nodes implement a shared memory that relies on a DHT. Instead of each M-node keeping all incoming TX in its own memory pool, each M-node only keeps a specific portion of the whole, along with the hash of the remaining portion and the associated key value.

[0056] DHTs are a class of decentralized distributed systems that allow for the partitioning of key set membership among nodes and the efficient and optimized delivery of messages only to owners of given keys. Each node in the network can be viewed as a cell in a hash table array. 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 (no central authority or central coordination), scalability (the system can operate 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 maintain contact with only a small number of other nodes, so the network does not become overloaded when changes or new data are present.

[0057] The same concept can be applied to a UTXO database, a database containing the set of all unspent outputs on a blockchain. A UTXO database can be constructed using a DHT to share its contents among a group of nodes.

[0058] There are many possible DHT architectures and protocols that can 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 that can store and transfer information in a distributed system. Each node in a Pastry™ network is assigned a 128-bit identifier, and the identifiers range from 0 to 2 128 It is used to indicate the node's position in a circular node ID space (ranging from -1). The ID is assigned randomly when a node joins the network. Each node maintains a routing table, a neighborhood set, and a leaf set.

[0059] One factor to consider in sizing a robust DHT is the number of replicas needed to ensure the robustness and reliability of the entire network. As already mentioned, nodes can join and leave the network, and this should not affect data availability. If a node that stores transaction A leaves the network, it will need to find transaction A in another part of the network. In existing blockchain networks, such as Bitcoin, the network has a number of blockchain replicas equal to the total number of nodes in the network (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 with 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 two replicas. This results in a probability of two nodes going down at once in any given hour, which assumes complete independence between nodes:

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 the transaction ID, depending on the implementation, to obtain a key value. The key value specifies the M-node or multiple M-nodes (in the 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 it 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 predetermined validation operation to verify the authenticity of the transaction.

[0062] A transaction may be hashed to generate a transaction key. The key can indicate where the transaction should be stored within the DHT, 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 the partitioning of the key space among the M-nodes that make up the M-net. In some configurations, the key space is partitioned among participating M-nodes. This partitioning may include overlap, allowing for replication for network resiliency. In some implementations, such as those using Pastry™, each M-node is assigned a unique key or ID number, and transactions may be stored in the M-node or multiple M-nodes (if replication is desired) based on proximity to the transaction's key value. The M-node may locally store the stored portion of the transaction and the hash or key value of the remaining portion. Thus, the M-node can evaluate whether a new transaction is in the DHT based on its local data.

[0063] If a 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 function according to various protocols related to distributed hash tables. The use of a DHT to store transactions in the M-net avoids the use of INV / GETDATA messages within the M-net to route transactions 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 transfer protocol, e.g., communication to regular nodes may use TCP for node-to-node connections.

[0065] In one configuration, an M-node includes a processor, a network interface, and memory. The M-node can be implemented using any suitable computing hardware, including 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 allocated portions of the DHT-based memory pool, based in part on its DHT key value, i.e., M-node ID. In this implementation, the memory also stores a routing table, a neighbor set, and a leaf set. The routing table contains a list of specific routing destinations within the M-net; 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 contain information about how far each destination is from the M-node. The neighbor set contains information about nearby M-nodes, for example, based on a proximity metric (e.g., ping latency). The leaf set contains numerically close M-nodes. Multiple M-nodes are numerically close if their key values ​​(node ​​IDs) are numerically close. The memory also includes an M-node reputation table, as described further below.

[0067] In addition to implementing a memory pool using a 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 existing part of the M-net so that it can direct a join request to one of the M-nodes. The M-node can perform predetermined validation actions, which 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 M-nodes. Illustratively, the criteria may include minimum available processing resources, minimum available free memory, or connectivity requirements.

[0068] Assuming the M-node completes whatever verification operations are performed to verify the new node, 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 routing tables, key values ​​(node ​​IDs), and any other data that enables the new node to function as a new M-node on the M-net.

[0069] It will be appreciated that the ease with which nodes can join the M-net creates a vulnerability that allows malicious nodes to 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 node behavior rankings. When a new node joins the network, the node may be added to the M-node reputation table, as indicated by a 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; from that point on, they begin to build the new node's reputation by 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 begin to record 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 enough 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, changing it 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 than in some blockchain implementations, such as Bitcoin. In traditional Bitcoin implementations, transactions are removed from the memory pool as soon as they are 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 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 incorporated, i.e., the number of blocks added to the blockchain following the block in which the transaction was incorporated. A transaction is removed from the memory pool only after a predetermined number of confirmations have occurred. The predetermined 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 in 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 described in the remainder of this document uses a modified type of fast validating node as described above. A new full node configuration is described, which is an M-node validating architecture enhanced with large-scale storage capabilities and an improved operating protocol. The M-node and storage nodes together form 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 containing a so-called magic number (which is always the same), a value indicating 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. Figure 1 shows the overall structure of a block.

[0078] 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) 5. Nonce (4 bytes)

[0079] Currently, blocks contain about 2,000 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 splits). This provides a transaction rate of approximately 3.5 transactions per second, with a theoretical maximum of 7 transactions per second. In contrast, VISA operates at a rate of approximately 10,000 transactions per second, and can reach over 50,000 transactions per second.

[0080] It is clear that some workaround for the current limitations is necessary to build a competitive payment system. Since the 10-minute block time is well established, it is essential to consider changes to the block size, i.e., the blockchain itself. A scalable solution is described herein that can handle, for example, approximately 50,000 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 controversy. Both maintaining the current size and increasing it offer significant benefits and trade-offs, and there appear to be strong arguments on both sides.

[0082] Given a transaction rate of r, we can calculate the required block size. In the following, 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 ≡ 500 bytes, a simple back-of-envelope calculation would be:

number

[0083] This is O(10 6 This leads to a storage requirement of 100 Gb / year. It is clear that blocks of this size 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 in which specialized validator nodes (which maintain a shared memory pool among themselves via a distributed hash table (DHT)) receive transactions, validate them, and allocate them to the memory pool. The validator nodes then offer their services by providing a list of valid transaction hashes to miners. Miners then attempt 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 the block skeletons back to the validator nodes, which 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 size threshold, the validator nodes: a) expand their own storage capabilities; or b) outsource 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 offering O(1) PB or more storage are required (see Table 1). The problem then becomes how to build a system that accommodates new blocks while maintaining the distributed, decentralized, and trustless nature of the network.

[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, much like 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 block size and number of transactions.

[0090] This difference is not purely architectural and hardware-related. 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 a significant investment and are therefore incentivized very differently. In a scalable paradigm, both M-nodes (validation nodes) and new full nodes (combined validation and storage nodes) expect to be compensated for their services.

[0091] At the other end of the spectrum, there are decentralized and distributed 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 super node consisting of both a petabyte (Pb) rack and a peer-to-peer (P2P) storage system.

[0093] Because the Bitcoin ecosystem relies heavily on the existence of multiple replicas of the entire blockchain distributed in a decentralized manner, it is clearly 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 reach 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 should 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) as a distributed hash table (DHT) memory / storage for memory pools 2) Persistent tape / disk like storage for blockchain As mentioned above, for a transaction rate of r=50000 Tx / 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 a 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 is a graph showing the total size of transactions waiting in the memory pool for confirmation.

[0099] As mentioned above, we envision two fundamentally different architectures, and their combinations, capable of storing large amounts of data. The two architectures are illustrated in Figures 4 and 5. Figure 4 illustrates an architecture involving multiple nodes with access to an internally centralized storage device. Figure 5 illustrates an architecture in which each node is part of both a distributed memory pool and a distributed storage device. The architecture depicted in Figure 4 appears 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 suitable solution 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 simply due to space requirements: the memory pool should be able to accommodate the equivalent of a block, i.e., approximately 15 gigabytes (~15Gb), preferably the equivalent amount for the next block to be mined. This must be combined with overhead that must be considered. 1) The memory pool must be synchronized with other validating nodes, which involves exchanging invertible Bloom filter lookup tables (Michael T. Goodrich, 2011). 2) The IBLT is scanned and missing transactions (Tx's) are retrieved. 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 IBLT being exchanged with miners, other validating nodes, and the new full node.

[0102] Miners submit a block skeleton (tuple) consisting of: 1. Nonce, n 2.IBLT 3. Coinbase Transactions Based on this, the new full node orders transactions accordingly (according to a specific set of rules) and assembles a 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 functionality 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 roots) are sent to miners, who select from the list to mine a block. 2) The winning miner sends the skeleton of the mined block to several new full nodes. The skeleton contains the coinbase transaction and includes the following: 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] Validating nodes are compensated for validating transactions through a fee system. Recipient validators / new full nodes are rewarded for one or more of the following: 1) Providing a list of validated transaction (Tx) hashes to miners (see b. above). 2) Reassembling blocks from the block skeleton (for a "flat" fee). 3) Size of the block (paid per "MB storage").

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

[0106] Therefore, a confirmation time of 100 blocks will provide miners with the necessary incentive to propagate skeleton blocks (including payments) to a range of new full nodes, which will in turn 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 include in a block. Thus, we can envision a market with competing validating nodes 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 mempool (or, as we envision here, specialized validating nodes), organize them into blocks, and attempt 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 a nonce (chosen iteratively) concatenated with the Merkle root and checking whether it is less than the so-called difficulty target. If it is less than the nonce, the puzzle is solved; if it is greater, iterations continue on the nonce. This remains the case in the new paradigm. What poses a challenge is the greatly expanded block size and the distribution of mined blocks across the network. With gigabyte-sized blocks, broadcasting the entire block in the network is not necessarily required.

[0109] Rather, we propose a solution that follows these steps: 1. Miners receive a list of validated transactions from validating / M-nodes and / or new full nodes. 2. Miners themselves may or may not operate their own memory pool of Tx hash values ​​that follow a predetermined 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., 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 will be able to select a list of validated transactions from a marketplace consisting of several validating nodes. Unless otherwise specified, it is reasonable to assume that miners will select the list that maximizes their potential profits. An observant reader may point out that this may lead to miners primarily selecting the same list from the same nodes. This would lead to a situation where several miners compete with each other to mine the same block. This would favor miners with the greatest hashing power.

[0111] We propose adding an additional field to the block header. This field 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 operate the new full nodes. For the proposed system to function, the mempools 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 is related to the list of transactions in a block, but here we present the idea that all validators and new full nodes use the same rule for their mempools.

[0113] The rules can be summarized as follows: 1) Order 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 the Merkle root hash is reached. It is clear that, were it not for the fact that miners are producing coinbase transactions, validating nodes could calculate the entire Merkle tree, and therefore the Merkle root and its corresponding hash.

[0115] Here we propose a Merkle tree that is computed using the following method 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) Coinbase transactions are omitted. 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 containing a random number chosen by the miner, so solving the hash puzzle would change as follows:

number

[0118] Therefore, we 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 preceding 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] Verification → Minor Validation nodes: 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 all transactions 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 wishes 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 node 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 as 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 whether the coinbase transaction has the appropriate reward. o Nodes verify that received data is consistent by calculating a checksum (hash). ○ Nodes use IBLT1 to ensure that transactions in a block are present in the memory pool. ○ The node assembles the block by querying the 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 choose lists that maximize their chances, and validating M-nodes will pick accordingly.

[0124] There may be cases where a miner wants to customize his or her block by combining transactions from two or more lists. By calculating the difference between the two IBLTs, it is possible to perform set reconciliation between the two sets. The miner then sends the IBLT containing the difference back to one of the contributing nodes, thus obtaining the information necessary to create a list that 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 discuss 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 mempools will overlap significantly, so combining lists will result in adding a small number of transactions (relatively speaking) from different lists. However, to combine lists, miners would have to "purchase" the entire list (via a commitment transaction) from each validator node. Whether this will be a profitable approach for miners remains to be seen.

[0128] Combining lists from several validating nodes requires a commitment between the miner and each contributing validating node. It is possible to imagine miners abusing this system. Currently, there is no rule / protocol that forces all commitment transactions to 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 highly 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 various tasks to correspondingly specialized nodes, leading miners to become even more specialized themselves. Compiling lists of validated transactions, reconstructing blocks based on block skeletons, and storing them are all functions that require significant resources. Therefore, we expect the structure of the Bitcoin network to change, and with it, its incentives. We have addressed these issues in detail herein.

[0130] Among the new elements introduced in this specification, the following can be mentioned: o New types of node structures, referred to herein as new full nodes or super nodes, which may or may not be extensions to validating M-nodes. ○ Nodes operate on a protocol that efficiently allows 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 containing a random number, chosen by miners to avoid mining activity becoming a race based solely 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. If we want to maintain an index of the items to be filtered, it quickly becomes clear that we need to extend the filter's functionality. 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 transactions are encoded in the IBF / IBLT.

[0136] application Suppose we have two nodes N1 and N2, each maintaining a memory pool m1 and m2. Each memory pool contains the entire hexadecimal string S 16 Furthermore, we assume that the memory pool follows an ordering convention, as proposed by Andresen and outlined herein above. N1 sends m1 to N2, and now N2 can 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 exist 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] While 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 confers 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 illustrate the present invention rather than limit it, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present invention as defined by the appended claims. In the claims, any reference signs placed between 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 several 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 node of a blockchain network, comprising: receiving mined data corresponding to a plurality of verified transactions from the blockchain network; Assembling a plurality of blocks based on the mined data; and sending the assembled block to a storage entity for storage in the blockchain; A method comprising: (Appendix 2) 10. The computer-implemented method of claim 1, wherein the mined data received from the blockchain network includes a block header corresponding to the verified transaction. (Appendix 3) 3. The computer-implemented method of claim 1 or 2, wherein the mined data includes transactions of digital assets in exchange for assembling blocks based on the mined data. (Appendix 4) 4. The computer-implemented method of any one of claims 1-3, wherein the mined data includes transactions of digital assets in exchange for storing assembled blocks. (Appendix 5) 5. The computer-implemented method of claim 3 or 4, further comprising a condition to wait a period of time t associated with a minimum number of blocks before accepting the digital asset. (Appendix 6) 6. The computer-implemented method of any one of claims 1-5, 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. (Appendix 7) 7. The computer-implemented method of any one of Clauses 1-6, wherein the block includes a block header including a random number provided by a miner. (Appendix 8) 8. The computer-implemented method of any one of claims 1-7, further comprising storing the block in the blockchain. (Appendix 9) 9. The computer-implemented method of any one of claims 1-8, wherein the storage entity is shared among multiple nodes in the blockchain network, the multiple 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 10) receiving a transaction from the blockchain network; validating the transaction received from the blockchain network; maintaining, with other nodes in the blockchain network, a distributed, decentralized storage of validated transactions; and distributing data corresponding to the verified transactions, the data including a list of verified transactions, to the blockchain network for mining; 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 maintaining distributed, decentralized storage of validated transactions with other nodes in the blockchain network includes synchronizing nodes in the blockchain network to maintain an up-to-date list of validated transactions in a decentralized, distributed manner. (Appendix 12) 12. The computer-implemented method of claim 11, wherein the nodes are synchronized by exchanging reversible Bloom filter lookup tables. (Appendix 13) 13. The computer-implemented method of any one of Clauses 10-12, wherein the verified transactions are sorted in a predetermined order such that a common ordering scheme is used across nodes in the blockchain network to maintain distributed, decentralized storage of the verified transactions. (Appendix 14) 14. The computer-implemented method of claim 13, wherein the validated transactions are sorted into an order determined using a canonical ordering scheme to maintain distributed, decentralized storage of the validated transactions. (Appendix 15) The step of distributing data corresponding to the verified transactions to the blockchain network for mining comprises: A step for preparing data corresponding to the list of verified transactions 15. The computer-implemented method of any one of Clauses 10-14, comprising: (Appendix 16) The step of distributing data corresponding to the verified transactions to the blockchain network for mining comprises: creating a digital asset commitment transaction in exchange for providing the miner with the data corresponding to the list of verified transactions; 16. The computer-implemented method of any one of clauses 10-15, including: (Appendix 17) 17. The computer-implemented method of claim 16, wherein a hash tree, Patricia tree, or other type of radix tree is computed along with the included commitment transaction. (Appendix 18) 18. The computer-implemented method of any one of Clauses 10-17, 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 accompanying data, and the verified transactions are included in blocks. (Appendix 19) 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-18. (Appendix 20) 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-18. (Appendix 21) A node of a blockchain configured to perform the method described in any one of Supplements 1-18. (Appendix 22) a plurality of nodes according to claim 21; and a shared storage entity that stores said blockchain; a blockchain super node, wherein the shared storage entity is either a common storage node, a distributed storage, or a combination of both; Blocks assembled by the plurality of nodes are sent to and stored in the shared storage entity, which maintains the blockchain, a super node. (Appendix 23) 23. The super node of claim 22, wherein the shared storage entity has a storage capacity of at least 100 gigabytes. (Appendix 24) A blockchain network including a plurality of super nodes according to Supplementary Note 22 or 23, A blockchain network, wherein the super nodes are connected by the blockchain network, the shared storage entity of each super node is configured to store a copy of the blockchain, and the blockchain network includes at least 10 super nodes. [Prior art documents] [Patent documents]

[0142] [Patent Document 1] International Publication No. 2017 / 038507 [Non-patent literature]

[0143] [Non-Patent Document 1] Kazuyuki Nagata et al., "Considerations on identity verification methods in blockchain," Research Report Computer Security (CSEC), Information Processing Society of Japan, February 23, 2017, vol. 2017-CSEC-76, no. 19, pp. 1-6

Claims

1. 1. A computer-implemented method for a node of a blockchain network, comprising: receiving mined data corresponding to a plurality of verified transactions from the blockchain network, the mined data including a block header including a random number selected by a miner; An assembly step of assembling a plurality of blocks based on the mined data, Prepare a list of verified transactions to be mined; Generate a commitment transaction and calculate a little Merkle root that includes the commitment transaction; and generating an invertible Bloom lookup table (IBLT) based on the plurality of verified transactions; and sending the assembled blocks to a storage entity for storage in the blockchain; A method comprising:

2. 2. The method of claim 1, wherein transmitting the assembled block to a storage entity for storage in the blockchain further comprises transmitting the IBLT and the little Merkle root.

3. 10. The method of claim 1, wherein the block header comprises: Version number; The hash of the previous block header; Merkle root hash; time value; target threshold; and Nonce; The method further comprises:

4. 4. The method of claim 1, wherein generating the IBLT further comprises generating a second IBLT, the second IBLT including a list of transaction IDs for each of the plurality of verified transactions.

5. 5. The method of claim 4, wherein sending assembled blocks to a storage entity for storage in the blockchain includes the second IBLT including the list of transaction IDs.

6. 6. The method of any one of claims 1-5, wherein the mined data includes transactions of digital assets in exchange for assembling blocks based on the mined data.

7. 7. The method of any one of claims 1-6, wherein the mined data includes transactions of digital assets in exchange for storing assembled blocks.

8. 8. The method of claim 6 or 7, further comprising a condition to wait a period t associated with a minimum number of blocks before accepting the digital asset.

9. 9. The method of claim 1, wherein assembling a plurality of blocks based on the mined data comprises assembling large blocks, each block having a size of at least 2 megabytes.

10. The method of any one of claims 1 to 9, further comprising storing the block in the blockchain.

11. 11. The method of claim 1, wherein the storage entity is shared among a plurality of nodes in the blockchain network, the plurality of nodes forming a super node in the blockchain network, and the shared storage entity is either a common storage node, a distributed storage, or a combination of both.

12. 12. The method according to any one of claims 1 to 11, receiving a transaction from the blockchain network; validating the transaction received from the blockchain network; maintaining, with other nodes in the blockchain network, distributed, decentralized storage of verified transactions; and distributing data corresponding to the verified transactions, the data including a list of verified transactions, to the blockchain network for mining; The method further comprises:

13. 13. The method of claim 12, wherein maintaining distributed, decentralized storage of validated transactions with other nodes in the blockchain network comprises synchronizing nodes in the blockchain network to maintain an up-to-date list of validated transactions in a decentralized, distributed manner.

14. 14. The method of claim 13, wherein the nodes are synchronized by exchanging reversible Bloom filter lookup tables.

15. 15. The method of any one of claims 12-14, wherein the validated transactions are sorted in a predetermined order such that a common ordering scheme is used across nodes in the blockchain network to maintain a distributed, decentralized storage of the validated transactions.

16. 16. The method of claim 15, wherein to maintain distributed, decentralized storage of the validated transactions, the validated transactions are sorted into an order determined using a regular ordering scheme.

17. 17. The method of any one of claims 12-16, wherein distributing data corresponding to the verified transactions to the blockchain network for mining comprises: A step for preparing data corresponding to the list of verified transactions A method comprising:

18. 18. The method of any one of claims 12-17, wherein distributing data corresponding to the verified transactions to the blockchain network for mining comprises: creating a digital asset commitment transaction in exchange for providing the data corresponding to the list of verified transactions to a miner; A method comprising:

19. 20. The method of claim 18, wherein a hash tree, Patricia tree, or other type of radix tree is computed along with the included commitment transactions.

20. 20. The method of any one of claims 12-19, 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 accompanying data, and the verified transactions are included in blocks.

21. 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-20.

22. interface devices; one or more processors coupled to the interface device; said one or more processor-associated memories; 21. An electronic device comprising: said memory storing computer readable instructions that, when executed, configure said one or more processors to perform a method according to any one of claims 1 to 20.

23. A node of a blockchain network configured to perform the method of any one of claims 1 to 20.

24. a plurality of nodes according to claim 23; and a shared storage entity that stores the blockchain; a super node of a blockchain network, wherein the shared storage entity is either a common storage node, a distributed storage, or a combination of both; A super node, wherein blocks assembled by the plurality of nodes are sent to and stored in the shared storage entity, which maintains the blockchain.

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

26. 25. A blockchain network including a plurality of super nodes according to claim 24, A blockchain network, wherein the super nodes are connected in the blockchain network, the shared storage entity of each super node is configured to store a copy of the blockchain, and the blockchain network includes at least 10 super nodes.

Images