Computer-implemented system and method for managing transactions on blockchain network

Abstract

Computer-implemented methods and systems suitable for implementation in a transaction verification node of a blockchain network are provided. Modified blockchain node structures, network architectures, and protocols for processing large numbers of transactions and large transaction blocks are described. There is provided a computer-implemented method comprising: (i) receiving a transaction from the blockchain network; (ii) validating the transaction received from the blockchain network; (i) maintaining distributed and decentralized storage of verified transactions together with other transaction verification nodes in the block chain network; and (iv) distributing data corresponding to the verified transaction to the blockchain network.

Description

[0001] This application is a divisional application of a patent application with Chinese Application No. 201880038016.8 (PCT International Application No. PCT / IB2018 / 054006), a filing date of June 5, 2018, and a title of "Computer-Implemented Systems and Methods for Managing Transactions on a Blockchain Network". Technical Field

[0002] This specification mainly relates to computer-implemented methods and systems suitable for implementation in transaction verification nodes of a blockchain network. A modified blockchain node structure, network architecture, and protocol for handling large volumes of transactions and large transaction blocks are described. Background Art

[0003] In this document, we use the term "blockchain" to include all forms of electronic, computer-based distributed ledgers. They include, but are not limited to, blockchain and transaction chain technologies, permissioned ledgers and permissionless ledgers, shared ledgers and their variants. It should be noted that the present invention is not limited to use with a specific blockchain, and alternative blockchain implementations and protocols also fall within the scope of the present invention.

[0004] A blockchain is a consensus-based electronic ledger that is implemented as a computer-based decentralized, distributed system consisting of blocks, which in turn consist of transactions and other information. Each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and includes at least one input and at least one output. Each block contains the hash of the previous block, such that the blocks become linked together to create a permanent, immutable record of all transactions that have been written to the blockchain since its inception. Transactions contain small programs called scripts embedded in their inputs and outputs that specify how and by whom the outputs of the transaction can be accessed. These scripts are written using a stack-based scripting language.

[0005] In order to write a transaction to the blockchain, it must be "verified". Certain network nodes work to ensure that each transaction is valid, and invalid transactions are rejected from the network. For example, the software client installed on a node performs this verification work on transactions that reference unspent transaction outputs (UTXOs). Verification can be done by executing its locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to TRUE, and if certain other conditions are met, the transaction is valid and can be written to the blockchain. Thus, in order to write a transaction to the blockchain, the transaction must i) be verified by the node receiving the transaction - if the transaction is verified, the node relays it to other nodes in the network; ii) be added to a new block built by network nodes; iii) be added to the public ledger of past transactions. A transaction is considered confirmed when enough blocks have been added to the blockchain to make the transaction effectively irreversible.

[0006] Digital entrepreneurs have started exploring the use of both cryptographic security systems and the data that can be stored on the blockchain for new systems. It would be highly beneficial if the blockchain could be used for automated tasks and processes. Such a solution would be able to leverage the benefits of the blockchain (e.g., permanence of events, tamper-proof records, distributed processing, etc.) while being more versatile in its applications.

[0007] One area of research is the use of the blockchain to implement "smart contracts". These smart contracts are computer programs designed to automatically execute the terms of a machine-readable contract or agreement. Different from traditional contracts written in natural language, a smart contract is a machine-executable program that includes rules that can process inputs to produce results, and then actions can be made to be executed based on these results.

[0008] Another area related to the blockchain is the use of "Tokens" to represent and transfer real-world entities via the blockchain. Potentially sensitive or confidential items can be represented by tokens that have no obvious meaning or value. Thus, the token acts as an identifier that allows real-world items to be referenced from the blockchain.

[0009] 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 multiple authentication servers implementing a multi-signature authentication system, aggregates digital signatures, and propagates the authenticated financial transactions into the network. Once the financial transactions are propagated through the network, the financial transactions can be incorporated into the public shared ledger in a conventional manner by network node entities of the network. The Hot Wallet service system also includes an analysis system that monitors the network and can generate a credit rating or score, which can be used, for example, to prevent certain financial transactions from being processed by the multi-signature authentication system.

[0010] CN106548349 involves the problem that if each node in a blockchain network needs to verify the transaction information of each transaction, this process generates a considerable amount of workload and brings great pressure to the nodes. The solution described in CN106548349 is to propagate the transaction information from the first node to multiple selected second nodes for verifying the transaction information, rather than requiring all nodes to verify the transaction information. The second nodes are selected in a random and irregular manner to prevent the possibility of malicious fraud, and there is no need for each node to verify the transaction information.

[0011] WO2017 / 162904 is directed to a blockchain-based resource management system in which transaction latency is reduced and resource double-spending is mitigated by verifying transactions before creating a new block in the resource management system. At least one verification node is provided to verify the transaction and provide a verification acceptance message to the merchant to release the item to the customer. In this way, the sale can be reliably completed without waiting for the next block of the blockchain to be created. WO2017 / 162904 also discloses that the verification node can distribute the verification request to a group of verification nodes and receive responses from the group of verification nodes. Then, the verification node can send a verification acceptance message to the merchant if and only if none of the responses from the group of verification nodes reject the transaction. WO2017 / 162904 also discloses that when the time comes to create a block in the blockchain, the node creating the block can compile a set of transactions that have occurred since the most recently created block, and the next block includes the set of transactions.

[0012] US2016 / 0259937, WO2017 / 004527, and WO2017 / 011601 describe the configuration and functions of a blockchain network. In particular, individual transactions are propagated through the network and incorporated into the blockchain by joining a public ledger of past transactions, where network nodes select a set of transactions, group the transactions into a Prototype Block, and determine the value of a non-repeating random number (Number Used Once, abbreviated as Nonce) that is used only once in a traditional "proof-of-work" manner. Once a network node finds a valid nonce that is used only once, the block is verified by other nodes and incorporated into the blockchain.

[0013] US2015 / 0310424 discloses a system for generating user directory data through multi-mode key address mapping. The network includes cryptographic nodes for publicly verifying a set of transactions of a user. The nodes can participate in the network by relaying transactions and maintaining a verification ledger. Summary of the Invention

[0014] Obviously, in order to establish a competitive payment system, it is necessary to circumvent certain current limitations of the blockchain network. Since the 10-minute block time has been determined, it is necessary to consider changes in the block size and, consequently, changes in the blockchain itself. In this specification, a scalable solution is described that can, for example, process approximately 50,000 transactions per second. Importantly, a solution is provided that can support a high transaction rate while retaining a decentralized, distributed system architecture.

[0015] The transition from the current architecture to an architecture that can handle a large number of synchronous transactions places infrastructure stress on the entire network. A node system has been proposed that can more effectively and quickly verify and relay a large number of transactions. Due to the large volume of transactions, a distributed approach has been proposed in the design of the storage pool (transactions that have not yet been processed and are pending on the blockchain). The substantial increase in the volume of transactions places pressure on the block size, and when the block size exceeds a certain limit, the issue of the storage infrastructure becomes an important problem. In this specification, a solution to the problem of processing and storing large, gigabyte-sized blocks is described.

[0016] This specification describes a modified blockchain network architecture that includes a plurality of dedicated transaction verification nodes for verifying transactions and maintaining a distributed, decentralized storage of the verified transactions with other transaction verification nodes in the blockchain network. The transaction verification nodes are also used to prepare a list of verified transactions for network nodes and also create committed transactions for digital asset exchanges to provide the list of verified transactions to network nodes. In this way, the dedicated transaction verification nodes provide services to network nodes in terms of verifying transactions, constructing a list of verified transactions, and providing the list to network nodes. Once a transaction is added to the public ledger of past transactions, the transaction added to the public ledger of past transactions is provided to the transaction verification nodes, which construct a large block of the transactions added to the public ledger of past transactions and store the large block in dedicated storage nodes.

[0017] One aspect of the present invention is directed to a method for receiving, verifying, storing, and distributing transactions in a verification node to a blockchain network for addition to a public ledger of past transactions. A computer-implemented method for a transaction verification node of a blockchain network is provided, the computer-implemented method comprising:

[0018] (i) receiving a transaction from the blockchain network;

[0019] (ii) verifying the transaction received from the blockchain network;

[0020] (iii) Maintain a distributed and decentralized storage of the verified transactions together with other transaction verification nodes in the blockchain network; and

[0021] (iv) Distribute the data corresponding to the verified transactions to the blockchain network.

[0022] The data corresponding to the verified transactions distributed to the blockchain network may include a list of verified transactions. Each list may provide a complete list of verified transactions.

[0023] This method effectively eliminates the requirement for network nodes to perform the verification function, while retaining the distributed and decentralized storage of the verified transactions together with other transaction verification nodes in the blockchain network. In addition, this method enables the transaction verification nodes to provide services to network nodes by preparing the data corresponding to the verified transactions and distributing it to the blockchain network for inclusion in the public ledger of past transactions. For example, this method enables the preparation and distribution of a list of verified transactions.

[0024] Optionally, the transaction verification node may be configured to verify transactions and maintain a distributed and decentralized storage of the verified transactions.

[0025] Optionally, the distributing the data corresponding to the verified transactions to the blockchain network may include: distributing the data corresponding to the verified transactions to the blockchain network for inclusion in the public ledger of past transactions; and further may include: distributing the data corresponding to the verified transactions from the transaction verification node to at least one network node in the blockchain network for inclusion in the public ledger of past transactions.

[0026] The computer-implemented method may further include:

[0027] (v) Receive data that has been included in the public ledger of past transactions from the blockchain network corresponding to the verified transactions, or, receive data corresponding to the verified transactions that has been included in the public ledger of past transactions from the blockchain network; optionally, at the transaction verification node, receive data corresponding to the verified transactions that has been included in the public ledger of past transactions from the blockchain network;

[0028] (vi) Assemble a block based on the data that has been included in the public ledger of past transactions; and

[0029] (vii) Send the assembled block to a storage entity for storage on the blockchain.

[0030] These further method steps enable the verification nodes to construct large blocks to be stored on the storage entity, without the need for network nodes to construct and store large blocks and transmit such blocks through the blockchain network. Additionally, the architecture allows for the use of large storage entities dedicated to storing large and growing blockchains.

[0031] The step of maintaining a distributed, decentralized storage of the verified transactions together with other transaction verification nodes in the blockchain network may include synchronizing the transaction verification nodes on the blockchain network to maintain an up-to-date list of the verified transactions in a decentralized and distributed manner. For example, the verification nodes may be synchronized by exchanging reversible Bloom filter lookup tables. The verified transactions are sorted in a defined order so as to use a common sorting system on the transaction verification nodes in the blockchain network to maintain the distributed, decentralized storage of the verified transactions. For example, a canonical sorting system may be used to maintain the distributed, decentralized storage of the verified transactions. This is known to be a particularly effective method for maintaining a decentralized, distributed storage while ensuring that the transaction data on the network is maintained in a consistent manner.

[0032] The step of distributing data corresponding to the verified transactions to the blockchain network for inclusion in the public ledger of past transactions may include: preparing data corresponding to the list of the verified transactions (such as a reversible Bloom lookup table and any accompanying data corresponding to the list of the verified transactions). Additionally, the step of distributing data corresponding to the verified transactions to the blockchain network for inclusion in the public ledger of past transactions includes: creating a commitment transaction for the digital asset in exchange for providing the network nodes with the data corresponding to the list of the verified transactions. For example, in the case where the commitment transaction is included, a hash tree, a Patricia tree, or another type of radix tree is calculated.

[0033] After distributing and including the data corresponding to the verified transactions in the public ledger of past transactions by solving an associated cryptographic puzzle (such as a hashing puzzle), the data included in the public ledger of past transactions is sent back to the transaction verification nodes, rather than being directly stored on the blockchain by the network nodes. The data included in the public ledger of past transactions may be assembled into (large) blocks and stored on a storage entity configured specifically for storing large amounts of data and / or in a distributed storage system. As previously mentioned, this enables the verification nodes to construct large blocks to be stored on the storage entity, without the need for network nodes to construct and store large blocks and transmit such blocks through the blockchain network. Additionally, the architecture allows for the use of large storage entities dedicated to storing large and growing blockchains.

[0034] Data of the public ledger of the joined past transactions received from the blockchain network may include block headers corresponding to the verified transactions. The data of the public ledger of the joined past transactions may further include transactions for digital assets in exchange for assembling and storing blocks based on the data of the public ledger of the joined past transactions. Additionally, the method may include a requirement 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 verification nodes. Requiring a minimum period of time before receiving digital assets incentivizes network nodes to propagate the skeleton blocks (including payments) to a series of nodes and incentivizes nodes to propagate the skeleton blocks to other nodes.

[0035] The step of assembling blocks based on the data of the public ledger of the joined past transactions may involve assembling large blocks, each block having a size of, for example, at least 2, 4, 6, 8, 10, 50, 100, 500, 1000, or 10000 megabytes. Although the upper limit may increase over time, a rated upper limit value of 1 PB can be specified. Each block may include, for example, at least 5000, 10000, 500000, 100000, 500000, or 1000000 transactions. Although the upper limit may increase over time, a rated upper limit value of 10 12 transactions per block can be specified. As previously mentioned, the methods, nodes, and blockchain network architectures described herein enable large blocks to be constructed and stored on storage entities without network nodes having to construct and store large amounts of transactions. This enables the system to handle significantly increased transaction rates.

[0036] In the methods described herein, a block can be modified to include a block header containing a nonce provided by a network node. That is, a transaction verification node can be used to process a block including a block header that contains a nonce provided by a network node when receiving a resolved transaction from the blockchain network. This constitutes a change to the block header, so the network node can select or randomly generate a number to insert into the block header. This helps ensure that even if many network nodes select the same list of transactions, the network nodes do not compete with each other to attempt to add transactions to the public ledger of past transactions for the same block.

[0037] The storage entity for storing the aforementioned large blocks of data can be shared among multiple transaction verification nodes on the blockchain network, and the multiple transaction verification nodes form super nodes on the blockchain network, where the shared storage entity is a public storage node, distributed storage, or a combination of both. This architecture enables the formation of a super node on the blockchain network and allows for the provision of a dedicated storage facility to store the blockchain and provide services to the blockchain network.

[0038] In view of the above, there is also provided a super node of a blockchain network, the super node comprising:

[0039] The multiple verification nodes as described above; and

[0040] A shared storage entity for storing the blockchain,

[0041] wherein the shared storage entity is a public storage node, a distributed storage, or a combination of both, and

[0042] wherein the blocks assembled by the multiple verification nodes are sent to and stored in the shared storage entity, whereby the shared storage entity maintains the blockchain.

[0043] This architecture is more suitable for handling large block sizes required to achieve the desired increase in transaction rate, which is the purpose of the methods and configurations described herein. For example, the shared storage entity can be configured to have a storage capacity of at least 100 GB, and more preferably at least 1, 10, 100, or 1000 TB. Although the upper limit will increase over time, a rated upper limit value of 10 6 TB or even 10 6 YB can be specified.

[0044] In terms of the overall network architecture, a blockchain network including multiple such supernodes can be provided. The supernodes can be connected (but not overlapping) on the blockchain network, and the shared storage entity of each supernode is used to store a copy of the blockchain. A supernode actually includes a group of nodes that form a pool serving as a supernode. To maintain the distributed nature of the blockchain, advantageously, there should be a certain number of such supernodes (e.g., at least 10, 50, 100, or 1000, and optionally less than 100000000).

[0045] Embodiments of the present invention can be provided in various forms. For example, a computer-readable storage medium including computer-executable instructions can be provided, and when the computer-executable instructions are executed, they cause a processor to execute the methods described herein. An electronic device can also be provided, the electronic device including: an interface device; one or more processors connected to the interface device; a memory connected to the one or more processors, and computer-executable instructions are stored on the memory, and when the computer-executable instructions are executed, they cause the one or more processors to execute the methods described herein. In addition, a verification transaction node of a blockchain network can be provided, and the verification transaction node is used to execute the methods described herein.

[0046] The present invention described herein is different from the prior art discussed in the background art section below.

[0047] The hot wallet service system of US2015 / 0287026 clearly discloses receiving transactions, authenticating transactions, and distributing the transactions to a blockchain network for inclusion in a public ledger of past transactions. However, the hot wallet service system of US2015 / 0287026 does not maintain a distributed, decentralized storage of the authenticated transactions together with other transaction verification nodes in the blockchain network. Instead, the hot wallet service system of US2015 / 0287026 utilizes multiple servers to initiate a multi-signature authentication system. Then, any transaction verified by aggregating authentication factors is propagated to the network, rather than being stored in a distributed, decentralized manner in the hot wallet service system. Additionally, in US2015 / 0287026, it is not proposed to prepare a list of the authenticated transactions and create a committed transaction for digital asset exchange to provide the list of the authenticated transactions to network nodes.

[0048] CN106548349 clearly discloses receiving transactions, verifying transactions, and distributing the verified transactions to a blockchain network for inclusion in a public ledger of past transactions. However, CN106548349 does not disclose maintaining a distributed, decentralized storage of the verified transactions together with other transaction verification nodes in the blockchain network. Moreover, in CN106548349, it is not proposed to prepare a list of the verified transactions and create a committed transaction for digital asset exchange to provide the list of the verified transactions to network nodes.

[0049] WO2017 / 162904 clearly discloses receiving transactions, verifying transactions, and distributing the authenticated transactions for incorporation into a blockchain. However, WO2017 / 162904 does not disclose maintaining a distributed, decentralized storage of the authenticated transactions together with other transaction verification nodes in the blockchain network. Moreover, in WO2017 / 162904, it is not proposed to prepare a list of the authenticated transactions and create a committed transaction for digital asset exchange to provide the list of the authenticated transactions to network nodes. In WO2017 / 162904, network nodes compile a set of transactions for inclusion in a public ledger of past transactions.

[0050] US2016 / 0259937, WO2017 / 004527, and WO2017 / 011601 disclose that a network node selects a set of transactions, groups the transactions into prototype blocks, and determines the value of a nonce in a conventional "proof of work" manner. Once the network node 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 the steps of maintaining a distributed, decentralized storage of verified transactions together with other transaction verification nodes in a blockchain network, which provides a distributed pool having a list of verified transactions provided to network nodes for joining a public ledger of past transactions. Similarly, US2015 / 0310424 also does not disclose a verification node that receives transactions, verifies the transactions, maintains a distributed, decentralized storage of verified transactions with other transaction verification nodes, prepares a list of verified transactions, and creates a commitment transaction for digital asset exchange to provide a list of verified transactions to network nodes.

[0051] In view of the above, it is believed that the present invention provides a unique architecture and method for more effectively processing and storing large blocks of gigabyte size in a blockchain network. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] With reference to the embodiments described herein, these and other aspects of the present invention will become apparent and be elucidated. The embodiments of the present invention are described below only by way of example and with reference to the drawings, in which:

[0053] Figure 1 shows the overall structure of a block;

[0054] Figure 2 shows, in the form of an operation diagram, the steps from a user submitting a transaction to the transaction ending in the blockchain;

[0055] Figure 3 shows a graph of an example of the total size of transactions waiting for confirmation in a storage pool;

[0056] Figure 4 shows multiple nodes linked to an internal decentralized storage facility.

[0057] Figure 5 shows a configuration where each node is part of a distributed storage pool and a distributed storage facility;

[0058] Figure 6 shows how a new node structure fits into the network, which shows a network configuration where verification nodes are members of storage pools that together form a decentralized distributed network;

[0059] Figure 7 Shows the functions of the new nodes;

[0060] Figure 8 Shows the new Merkle tree structure, which constitutes a modification to the current protocol.

[0061] Figure 9 Shows the workflow for creating a Bloom filter; and

[0062] Figure 10 Shows the workflow for illustrating how transactions are encoded in Invertible Bloom Filters (IBF) and Invertible Bloom Lookup Tables (IBLT). Detailed implementation

[0063] In this specification, solutions to the problems of processing and storing large, gigabyte-sized blocks are described.

[0064] Types of blockchain network nodes and verification nodes

[0065] A blockchain network can be described as a peer-to-peer open membership network where anyone can join the network without an invitation or the consent of other members. Distributed electronic devices running instances of the blockchain protocol (under which the blockchain network operates) can participate in the blockchain network. Such distributed electronic devices can be referred to as nodes.

[0066] The electronic devices of the nodes running the blockchain protocol and forming the blockchain network can be of various types, including, for example, computers (such as desktop computers, laptops, tablets, servers, computer clusters), mobile devices (such as smartphones), wearable computers (such as smartwatches), or other electronic devices.

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

[0068] Currently, nodes maintain a global ledger of all transactions on the blockchain. All transactions are grouped into multiple blocks, where each block contains the hash of the previous block on the blockchain. The global ledger is a distributed ledger, and each node can store a complete copy or a partial copy of the global ledger. Transactions of nodes that affect the global ledger are verified by other nodes, thus maintaining the validity of the global ledger. Those of ordinary skill in the art will understand the details of implementing and operating a blockchain network.

[0069] Each transaction typically has one or more inputs and one or more outputs. The scripts embedded in the inputs and outputs specify how and who can access the outputs of the said transaction. The output of a transaction can be the address to which the value as the result of the transaction is transferred. Then, the value is associated with the address of that output as an Unspent Transaction Output (UTXO). Subsequent transactions can reference that address as an input to spend or disperse the value.

[0070] Nodes can have different types or categories according to their functions. Four basic functions associated with nodes have been proposed: wallet, joining the public ledger of past transactions, full blockchain maintenance, and network routing. These functions may vary. A node can have multiple functions. For example, a "full node" provides all four functions. A lightweight node can be implemented, for example, in a digital wallet and may only have wallet and network routing functions. The digital wallet can keep track of the block headers (which are used as indexes when querying blocks) instead of storing the full blockchain. Nodes communicate with each other using connection-oriented protocols such as TCP / IP (Transmission Control Protocol).

[0071] Additional types or categories of nodes can be provided: Merchant Node (sometimes referred to as "M Node" in this article). The M Node is designed to focus on the rapid dissemination of transactions. The M Node may or may not store the full blockchain and does not perform the function of joining the public ledger of past transactions. In this sense, the M Node is similar to a lightweight node or a wallet. However, the M Node includes additional functions to achieve the rapid dissemination of transactions. The operation focus of the M Node is the rapid verification and dissemination of unconfirmed transactions, especially the dissemination to other M Nodes, from which the unconfirmed transactions are quickly pushed to other nodes in the blockchain network. To facilitate the implementation of this function, the M Node is allowed to have a larger number of incoming connections and especially outgoing connections, which might otherwise be allowed for nodes under the management protocol.

[0072] M Nodes can be collectively referred to as the Merchant Network (or "M Network"). The term "merchant" can be interpreted as "dedicated". M Nodes can be integrated into the blockchain network. Each M Node is a dedicated node on the blockchain network that meets specific hardware and performance capabilities to ensure its ability to perform the functions of an M Node. That is to say, the M Network can be regarded as a subnet within the blockchain network and is distributed through the blockchain network. M Nodes can be arranged and configured to perform one or more dedicated functions or services.

[0073] To enable the M network to operate reliably and provide services at a certain security level, the M nodes need to maintain a good overview of the entire M network, so an effective routing protocol needs to be established. Whenever an M node receives a start transaction, it needs to broadcast the transaction to several other M nodes and other nodes. In the M network environment, this is equivalent to finding a solution to the Multiple Traveling Salesman Problem (MTSP). There are many solutions to this problem, and any one of them can be applied to the M network. Each M node runs routing optimization in some up-to-date form.

[0074] In some embodiments, the M network is implemented as a decentralized IP multicast type of network. That is, in order to enable incoming transactions to spread quickly across the blockchain network, multicast can be used to ensure that transactions are quickly broadcast throughout the M network, so that all M nodes focus on forwarding transactions to other nodes in the blockchain network.

[0075] The multicast network architecture allows for the possibility of simultaneously distributing data to a group of destination nodes without replicating the data for each node interested in receiving the information. If a node wants to receive a multicast transmission, then the node joins the multicast group (registration phase), and thereafter the node will be able to receive all data sent through the multicast group. IP multicast does not require prior knowledge of how many receivers there are to scale to a larger group of receivers, and by only requiring the source to send the data packet once, the network infrastructure can be effectively utilized. Due to the nature of the multicast network, since it communicates with a large number of other nodes simultaneously, it is impractical to use a connection-oriented protocol such as TCP. Accordingly, a connectionless protocol is used.

[0076] Some blockchain networks use TCP for node-to-node communication. Packets sent using TCP have an associated sequence number, which is used for sorting. In addition, the TCP protocol involves a three-way handshake process both when establishing and terminating a connection. Packets sent via TCP have associated overhead, the packets have an associated sequence number and there is a three-way handshake protocol. When establishing a connection, 128–136 bytes are transmitted, while closing the connection takes 160 bytes. Thus, the handshake cost in packet transmission is as high as 296 bytes. In addition, when a node receives a new transaction, the node notifies other nodes via an inventory (INV) message containing the transaction hash. The node receiving the INV message checks whether the hash of the transaction has been seen before; if not, the node will request the transaction by sending a get data (GETDATA) message. The time required for a transaction to be transferred from node A to node B is T1 = verification + TCP(inv + getdata + tx), where TCP() represents the time overhead introduced by the TCP handshake procedure.

[0077] The M node can be configured to communicate with other nodes using TCP when authorized by the existing protocol. However, the M node can use a connectionless protocol (such as the User Datagram Protocol (UDP)) for communication from M node to M node in a multicast scenario, and even more appropriately from an M node to multiple M nodes. Different from TCP, UDP does not involve a handshake protocol, so the M node can spread transactions faster. This can also prevent malicious nodes from not sending actual transactions but tying up other nodes by sending duplicate INV messages.

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

[0079] In an example scenario, regular nodes on a blockchain network generate transactions (such as merchant - based payments) that they wish to process through the M network. The regular node can send the transaction to an M node, and then that M node uses multicast to broadcast the transaction to other M nodes, or if the regular node knows the IP multicast address of the M nodes, it can send the transaction directly to multiple M nodes. In some examples, all M nodes of the M network are members of a single multicast address, so 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 network, and the receiving M node can evaluate from the routing information whether the transaction needs to be further broadcast to other multicast addresses to spread the transaction across the entire M network.

[0080] Multicast helps ensure the rapid initial spread of new transactions to all M nodes; however, the multicast solution does not necessarily solve the scalability problem of the blockchain network caused by increased transaction throughput. Each node in the network typically maintains a storage pool (Mempool) that contains unconfirmed transactions it has seen and that have not yet been merged into the blockchain by network nodes that have completed the proof - of - work. A significant increase in the number of transactions used in payment processing increases the number of transactions stored in each storage pool. Therefore, although the nodes in the M network can receive new transactions almost simultaneously, the nodes may have limitations in storage capacity for large and rapidly changing storage pools.

[0081] To solve this problem, the M node can use a shared storage pool implemented through a Distributed Hash Table (DHT) as an alternative to using multicast.

[0082] Assuming that the average size of a transaction (TX) is 500 bytes and the transaction rate is approximately 104 transactions per second, the M network can receive approximately 400 GB of incoming data per day. All of this data needs to be stored in the pool of unconfirmed transactions for different lengths of time. Therefore, the M network requires a large amount of storage space and the ability to store data quickly. To not place too many demands on each individual M node, the M nodes implement a shared storage pool that relies on a DHT. Instead of having each M node keep all incoming transactions in its own storage pool, each M node only stores a certain portion of the total, along with the hashes and associated key values of the remaining portion.

[0083] A DHT is a type of decentralized distributed system that allows for the partitioning of a set of keys among nodes and is able to send messages only to the owner of a given key in an efficient and optimized manner. Each node in the network can be thought of as a cell in an array of hash tables. The DHT is designed to manage a large number of nodes, allowing new nodes to join the network, old nodes to leave the network, or nodes to crash without compromising the integrity of the shared data. The DHT ensures decentralization (no central authority and no central coordination), scalability (efficient behavior of the system with millions of nodes), and fault tolerance (the system is reliable and able to manage nodes that join and leave the network or crash). Each node in the network can keep in touch with only a few other nodes, so the network does not become overloaded when there are changes or new data.

[0084] This concept can also be applied to the UTXO database, which contains the set of all unspent outputs on the blockchain. A DHT can be used to build the UTXO database so that the content can be shared among a group of nodes.

[0085] Many possible DHT structures and protocols can be used to implement the shared storage pool of the M network. One example is Pastry TM , and there are many other examples as well. Pastry TM is a protocol designed to maintain an overlay network that can store and transmit information on a distributed system. Each node in the Pastry TM network is assigned a 128-bit identifier that is used to indicate the node's position in a circular node identifier (ID) space (ranging from 0 to 2 128 -1). When a node joins the network, the ID is randomly assigned. Each node maintains a routing table, a neighborhood set, and a leaf set.

[0086] When determining the dimension of a robust DHT, one factor to consider is the number of replicas required to ensure the robustness and reliability of the entire network. As mentioned earlier, nodes can join and leave the network, which should not affect the availability of data. If the node storing transaction A leaves the network, it is necessary to find transaction A in another part of the network. In existing blockchain networks, the number of blockchain replicas of the network is equal to the number of all nodes in the network (an average of 5000 replicas), but this affects scalability.

[0087] In an M network configuration, the storage pool is not fully replicated on each M node, but is implemented through a DHT. To provide reliability, the DHT can be implemented with some overlap; that is, each transaction data item is replicated in more than one M node, although not in every M node. For example, the DHT can be implemented to specify a minimum number of 2 replicas. Also assume the complete independence between two nodes is This will likely result in two nodes going down simultaneously at any given time.

[0088] Therefore, the process for storing a new transaction in a distributed storage pool can include the following steps, where a DHT is used to implement the distributed storage pool. The process includes: a node sends a transaction to an M node. The M node hashes the transaction or the transaction ID according to the implementation to obtain a key value. The key value indicates the M node or multiple M nodes (in the case of replicated data) where the transaction is stored. Then, the M node stores the transaction in the distributed storage pool, which can include: routing the transaction to the correct M node to store the transaction based on the key value and the assigned ID of the M node in the M network. According to the DHT protocol involved, the M node may receive an acknowledgement. When the M node receives a new transaction from a regular node, the M node can perform certain verification operations to verify the authenticity of the transaction.

[0089] A transaction can be hashed to generate a key for the transaction. The key can indicate where the transaction should be stored in the DHT, which can be on other nodes than the current M node. Then, the M node evaluates whether the transaction is already in the running DHT. Based on the key space partitioning among the M nodes that make up the M network, each M node has a part of the stored transactions. In some configurations, the key space is partitioned among the participating M nodes. The partitioning may involve overlap to cause replication for network resilience. In some embodiments (such as using Pastry TM ), each M node is assigned a unique key or ID number, and the transaction can be stored in the M node or multiple M nodes (in the case of replication required) based on the proximity of the transaction key value. The M node can have a local storage part of the transaction and the hashes or key values of the rest. Therefore, the M node can evaluate whether a new transaction is in the DHT based on the local data in operation.

[0090] If the transaction is not in the DHT, then during operation, the M node stores the transaction in the DHT according to its key value. Generally, 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 and stored at the appropriate M node. Based on the selected implementation, the DHT can operate according to various protocols for distributed hash tables. Storing transactions in the M network using the DHT avoids using inventory / get data (INV / GETDATA) messages in the M network to route transactions to each M node.

[0091] In the operation of this example, the M node can send the transaction to a regular node in the blockchain network according to the normal transaction forwarding protocol of the blockchain network. For example, communication to a normal node can use TCP for node-to-node connections.

[0092] In one configuration, the M node includes a processor, a network interface, and a memory. Any suitable computing hardware can be used to implement the M node, which has network connectivity and sufficient processing and storage resources to perform the functions described herein. The M node may include processor-executable instructions to implement the functions described herein. In some cases, the processor-executable instructions may be referred to as a blockchain merchant node application, but it can be understood that based on the hardware and operating system, the instructions can be implemented in one or more modules, applications, scripts, or other programming constructs. The processor may include a multi-core processor and / or multiple processors.

[0093] The memory stores data partly based on its DHT key value (i.e., the M node ID), including an assigned part of the DHT-based storage pool. In this example implementation, the memory also stores a routing table, a neighborhood set, and a leaf set. The routing table contains a list of specific routing destinations within the M network. When a node receives a data packet, it refers to the routing table to know where to send the data. The routing table may also contain information about the distance between each destination and the M node. The neighborhood set (e.g., based on a proximity metric (ping latency)) contains information about nearby M nodes. The leaf set contains numerically close M nodes. If the key values (node IDs) of the M nodes are numerically close, then the nodes are numerically close. The memory also includes an M node reputation table, which will be further described below.

[0094] To provide scalability, in addition to using a DHT to implement a storage pool, the M network also allows nodes to join the M network. A new node needs to have the address of at least one M node that is already part of the M network so that the new node can direct its join request to one of the M nodes. The M node can perform certain verification actions, which may involve querying the new node. For example, the M network can have a set of minimum criteria assigned to M nodes that are associated with joining the M network. By way of example, the criteria can include a minimum amount of processing resources available, a minimum amount of free memory available, or connectivity requirements.

[0095] Assuming the M node completes any verification operations performed to vet the new node, the M node forwards the join request (Joinrequest()) to the DHT according to any DHT protocol that controls DHT operations. The DHT then communicates with the new node to provide the new node with a routing table, key values (node IDs), and any other data so that the new node can act as a new M node on the M network.

[0096] It should be understood that the ability of nodes to easily join the M network creates an opportunity for malicious nodes to also join the network. To identify and isolate potential malicious nodes, one configuration provides M nodes with an M node reputation table for tracking and updating node behavior rankings. When a new node joins the network, the node can be added to the M node reputation table as indicated by the node ID field. In some embodiments, the table can also include the join time. The table also includes a score or rating for the M node.

[0097] The score can 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 the M network with traffic determined to be non-transactional, or otherwise engages in negative behavior, then the ranking of the M node may be decreased or decremented. If a node's score drops below a preset minimum value, then the node can be excluded from the M network.

[0098] The M node reputation table maintained by a particular M node can be limited to tracking the scores of its neighbors, rather than the entire M network. Thus, when a new M node joins the network at time t, the M node reputation tables of its neighbors do not contain any information about the new node, but starting at time t, they begin to build the reputation of the new node, storing information in the node registry. For example, if the new node is a silent node, meaning the node does not transmit the information it receives over the network, then all neighbors begin to record this behavior in their respective M node reputation tables (e.g., assigning a negative value to the ID of the new node). After a certain time t + n, if the M node reputation tables of all nodes that know about the new node contain negative values, then the nodes can decide to isolate the new node and ban the new node from the network.

[0099] Transactions in the distributed storage pool of the M network may need to wait a fairly long time to be confirmed, i.e., before being incorporated into a block that is added to the blockchain and confirmed. A block is considered "confirmed" when a sufficient number of subsequent blocks are added to the blockchain above it, such that reversing the growth in the chain and deleting the block to change to a different branch or fork is computationally infeasible.

[0100] Due to the size and flexibility of the storage pool and the transaction volume, the time that a given transaction remains unconfirmed may be longer than in some blockchain implementations. In traditional implementations, once a transaction is incorporated into a block, the transaction is deleted from the storage pool. This means that if the block ultimately becomes an orphan block, then all the transactions in that block are retransmitted on the network. In the case of a fast transaction network, this may be impractical or may result in long delays in the confirmation of some transactions.

[0101] Thus, in some implementations, the storage pool can track the number of confirmations of the block into which a transaction has been incorporated, i.e., the number of blocks added to the blockchain after the block into which the transaction has been incorporated. A transaction is only deleted from the storage pool after a predetermined number of confirmations has occurred. The predetermined number can be 4, 5, 6, 7 or any suitable number for a given implementation. The storage pool data entry can be structured to include a transaction ID field, a transaction field, and a number of confirmations (NoC) field. In another implementation, the storage pool data entry can simply record the block number without tracking the NoC. Based on the current block number of the blockchain, the storage pool data entry can evaluate how many confirmations have occurred based on the block number.

[0102] Once the necessary number of confirmations has occurred, the transaction can be safely deleted from the storage pool. In this way, there is no loss of transactions in the case of an orphan block, and after the necessary number of confirmations, the transaction will be permanently deleted.

[0103] The solutions described in the following sections of this specification utilize a modified type of fast verification node as described above. A new full node configuration is described that is essentially an M node verification architecture enhanced with large-scale storage capabilities and a modified operating protocol. The M node and the storage node together form the core of the new full node. The new node structure is described in detail, including the necessary technical requirements and technical solutions, and a sustainable incentive model is provided.

[0104] Block Size and Storage Requirements

[0105] The current block size is 1Mb. Currently, a block consists of a field containing a so-called magic number (always the same value), a value indicating the actual size of the block, a so-called block header, the number of transactions contained in the block, and an actual list of transactions. The actual list of transactions always starts with the coinbase transaction. InFigure 1 shows the overall structure of the block.

[0106] The block header contains the following:

[0107] 1. Version number (4 bytes)

[0108] 2. Hash of the previous block header (32 bytes)

[0109] 3. Merkle root hash (32 bytes)

[0110] 4. Timestamp (4 bytes)

[0111] 5. Target threshold (encoded as nBits – 4 bytes)

[0112] 6. Nonce (a non-repeating random number used only once, 4 bytes)

[0113] Currently, a block contains approximately 2,000 transactions and is added to the public ledger of past transactions approximately once every 10 minutes (the 10-minute block time is set as a compromise between the first confirmation time and the time wasted 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 comparison, VISA operates at a rate of approximately 10,000 transactions per second and can reach over 50,000 transactions per second.

[0114] Obviously, in order to build a competitive payment system, it is necessary to somehow circumvent the current limitations. Since the 10-minute block time has been determined, it is necessary to consider changes in block size and thus changes in the blockchain itself. In this specification, a scalable solution is described that can handle approximately 50,000 transactions per second, for example.

[0115] Increasing the size of the current block, or even completely removing the limit, is a much-discussed and sometimes controversial topic. There seem to be strong arguments on both sides, as there are obvious benefits and trade-offs to both maintaining the existing size and increasing it.

[0116] Assuming a transaction rate of r, we can calculate the necessary block size. Assume the block time (average) is 10 minutes. Therefore, assume the number of transactions per block is T(r). We get

[0117] T(r) = r · 6 · 10 2 block -1

[0118] If s Tx is the average transaction size (in bytes), then the block size B(r, s Tx) can be expressed as

[0119] B(r,s Tx ) = s Tx ·T(r) = s Tx ·r·6·10 2

[0120] Therefore, considering the case of r = 50000 transactions per second and s Tx = 500 bytes, the quick backtracking calculation gives:

[0121]

[0122] This in turn leads to the storage requirements. Clearly, for blocks of this size, we need a slightly different method of block propagation and storage. Table 1 below shows the relationship between the transaction rate, average transaction size, block size, and the amount of storage space required per month and per year.

[0123]

[0124] Table 1: Relationship between transaction rate, average transaction size, block size, and the amount of storage space required per month and per year

[0125] Figure 2 shows a schematic diagram of the operations from the moment a user submits a transaction until the transaction ends in the blockchain.

[0126] A system is provided where special verification nodes (maintaining a shared storage pool among special verification nodes through a distributed hash table DHT) receive transactions, verify the transactions, and allocate the transactions in the storage pool. The verification nodes then provide services to network nodes, namely providing a list of valid transaction hashes. The network nodes assemble pre-blocks (block skeletons) based on these hashes and attempt to solve the hash puzzle. When a solution to the puzzle is found, the winning network node sends the block skeleton back to the verification node. The verification node verifies the block and ensures that the block is stored. Initially, it is possible and feasible for the verification node to store the block itself. When the block size finally exceeds a certain size threshold, the verification node will: a) expand its own storage capacity; or b) outsource the storage to dedicated storage nodes. These two architectures will be discussed later in this specification.

[0127] New full nodes

[0128] In order of block size, it no longer seems feasible to rely on PC-type nodes to provide the storage capacity for hosting the full image of the blockchain. Instead, it is necessary to provide or more storage devices (see Table 1). The challenge then becomes creating a system that can accommodate new blocks while maintaining the distributed, decentralized, and trustless nature of the network.

[0129] Two types of full-node architectures were envisioned, as well as combinations of these two types:

[0130] 1. Verification nodes with associated gigabyte storage racks

[0131] 2. Verification nodes with associated storage pool based on an internally decentralized distributed peer-to-peer (P2P) single-node network

[0132] 3. Combinations of 1 and 2

[0133] The proposed solution attempts to solve the problem of maintaining a distributed and decentralized record of the blockchain by introducing nodes that are similar to so-called full nodes but, in contrast, have the ability to scale as the size of the blocks and the number of transactions increase.

[0134] The differences are not limited to purely structural and hardware-related issues. Compared to the full nodes based on home computers that were running at the time of writing this article, the new nodes proposed in this article will be dedicated nodes. The new nodes require a significant investment, and therefore, the incentives will be very different. In a scalable paradigm, both M nodes (verification nodes) and the new full nodes (a combination of verification and storage nodes) will expect to be compensated for their services.

[0135] On the other hand of the spectrum, we have decentralized distributed storage solutions that mainly consist of single nodes. Storj (Wilkinson et al., 2016), Sia (NebulousLabs), and MaidSafe (maidsafe) are good examples.

[0136] As mentioned above, it is also possible to envision supernodes consisting of petabyte (Pb) racks and peer-to-peer (P2P) storage systems.

[0137] It is important to compensate all full nodes.

[0138] Nodes will form pools that act as supernodes. To maintain the distributed nature of the blockchain, there must be a certain number of such supernodes (≥100). The supernodes are connected but do not overlap.

[0139] Technical Requirements

[0140] As mentioned above, when discussing the new full nodes, two completely different architectures need to be considered (see Table 2).

[0141] The new full nodes need to maintain two types of storage devices:

[0142] 1) Distributed hash table (DHT) memory / storage device similar to random access memory (RAM) for a storage pool.

[0143] 2) Permanent tape / disk - type storage device for a blockchain.

[0144] As described above, for a transaction rate of r = 50000 transactions per second, the blocks are expected to be This implies an annual storage requirement of ~365×24×6×15 Gb = 7.9·10 5 Gb = 0.8 Pb / yr (see Table 1).

[0145] Table 2 shows a comparison between current full nodes and future full nodes:

[0146] Feature Current full node New full node Storage pool Yes Yes Storage pool size ~10 - 100 Mb ~0.1 - 1 Tb Storage pool type RAM with a charging floor DHT with "infinite" storage Disk space / year ~100 Gb ~1 Pb Transaction verification Yes Yes Block verification Yes Yes

[0147] Meanwhile, the rack / cluster needs to maintain the storage pool. This allows for quick recovery of blocks. The necessary size of the storage pool is more difficult to assess. Currently, the block size is approximately 1 megabyte There are approximately 4 transactions per second The total size of transactions waiting in the storage pool fluctuates between 2 megabytes and approximately 70 megabytes between. Figure 3 An example graph showing the total size of transactions waiting for confirmation in the storage pool is shown.

[0148] As described above, we envision two fundamentally different structures capable of storing large amounts of data, as well as a combination of the two structures. Figure 4 and Figure 5 These two structures are shown in Figure 4 shows a configuration including multiple nodes capable of accessing an internal decentralized storage facility. Figure 5 shows a configuration where each node is part of a distributed storage pool and a distributed storage facility. Figure 4 The described architecture seems suitable for larger entities that own and maintain multiple validation nodes, all of which can access the entity's own storage facility. In contrast, Figure 5 the architecture described in

[0149] Figure 6 is fully decentralized. This solution is suitable for individual nodes (such as a home PC with sufficient storage capacity) that wish to join a shared distributed storage pool. Underlying storage technologies (such as Storj, Sia, MaidSafe) already exist for this purpose.

[0150] Full Node Operations

[0151] In the large block scenario, we will face another situation, not just due to space requirements. The storage pool should be able to hold an amount equivalent to one block, which is approximately 15 gigabytes (~15Gb), preferably the same amount as the next block that will add transactions to the public ledger of past transactions. This will also be combined with the overhead that needs to be considered.

[0152] 1) The storage pool needs to synchronize with other validation nodes. This involves exchanging reversible Bloom filter lookup tables (Michael T. Goodrich, 2011)

[0153] 2) The IBLT needs to be carefully checked and missing transactions (Tx) retrieved

[0154] 3) The additionally retrieved transactions need to be verified

[0155] 4) Assemble the block based on the block skeleton received from network nodes or other full nodes

[0156] The new full node maintains an up-to-date storage pool. It is achieved through the IBLT and other validations exchanged with network nodes and the new full node.

[0157] Network nodes send the block skeleton (tuple) containing the following:

[0158] 1. A non-repeating random number, n, used only once

[0159] 2. IBLT

[0160] 3. Coinbase transaction

[0161] Based on this, the new full node sorts the transactions accordingly (according to a specific set of rules) and assembles a new block that adds the transactions to the public ledger of past transactions. The new full node continues to store the block in its own storage device and propagates the skeleton to other new full nodes. The protocol will be described in more detail later in this specification.

[0162] Incentives

[0163] An important feature of the specific configuration is to build incentives into the system to encourage the provision of new node structures and services. Since storing the blockchain requires a large amount of cost, incentives are needed. Figure 7 The functions of the new full node are shown. The new full node receives rewards for two types of services, mainly:

[0164] 1) Compile a list of verified transactions ready to be added to the public ledger of past transactions. Send the hash value (Merkle root) of the transactions to the network nodes, and the network nodes select the list and add the transactions to the public ledger of the block.

[0165] 2) The winning network node sends the skeleton of the block that has joined the public ledger of past transactions to several new full nodes. The skeleton includes the coinbase transaction, which contains:

[0166] a. A secret as part of a commitment scheme that serves as a payment mechanism for providing a verified list.

[0167] b. The fee for paying block verification and / or storing the block on the blockchain.

[0168] [Transaction] The verification node will compensate for transaction verification through the fee system. The receiving verification / new full nodes will be rewarded for one or more of the following:

[0169] 1) Providing a list of verified transaction (Tx) hashes to the network nodes (see b above)

[0170] 2) Reassembling the block from the block skeleton ("fixed" fee).

[0171] 3) The size of the block ("per megabyte storage" payment)

[0172] The incentive lies in the 100-block confirmation time T 100 .

[0173] 1) The network nodes need to wait for a time t approximately equal to T 100 .

[0174] 2) The verification node needs to wait for a time t approximately equal to T 100 , in order to receive the fee for the transactions in the verified block.

[0175] 3) The new full nodes need to wait for a time t approximately equal to T 100 , in order to receive the block assembly fee and the storage fee depending on the size.

[0176] Therefore, the 100-block confirmation time will provide the necessary incentive for network nodes to spread the skeleton blocks (including payments) to a series of new full nodes, and will incentivize the new full nodes to spread the skeleton blocks to other new full nodes.

[0177] It should also be noted that the network nodes can freely choose the list of (transactions) they wish to include in the block. Thus, we envision a market consisting of the following verification nodes, which compete by compiling a list of verified transactions that network nodes can select and purchase from by committing transactions.

[0178] A network node collects transactions (Tx) from a storage pool (or, as envisioned herein, from a dedicated verification node), organizes the transactions into blocks, and attempts to find a solution to a hashing puzzle (a non-repeating random number used only once). The block header contains the non-repeating random number used only once included by the network node, the hash of the previous block on the blockchain, and the root of the Merkle tree of the transactions. Solving the puzzle involves calculating the double SHA256 hash of the non-repeating random number used only once concatenated with the previous block hash and Merkle root (iteratively selected), and checking whether it is less than a so-called difficulty target. If it is less than the difficulty target, the puzzle is solved; if it is greater than the difficulty target, the iteration of the non-repeating random number used only once continues. This remains unchanged in the new paradigm. What poses a challenge is the greatly enlarged block size and the distribution of blocks that have incorporated past transactions across the entire network in the public ledger. Broadcasting an entire block of gigabyte size across the network is not necessarily feasible.

[0179] Instead, we propose a solution that includes the following steps:

[0180] 1. The network node receives a list of verified transactions from the verification / M node and / or new full nodes.

[0181] 2. The network node itself may or may not operate its own storage pool of transaction hash values, which follows a specific sorting convention.

[0182] 3. The network node solves the hashing puzzle by determining a non-repeating random number n used only once.

[0183] 4. Next, a hash tree (Merkle tree, hereinafter referred to as HT) is calculated, and the root of the Merkle tree is stored (see the next section).

[0184] 5. The transaction list is used to create an IBLT. The IBLT can be used to calculate the content differences between two sets (such as storage pools) and to reconcile the two sets.

[0185] 6. The tuple { n; IBLT; CoinBase Tx；HT root} is broadcast to the verification / M node.

[0186] 7. New full nodes operate a DHT for the storage pool and storage devices of the blockchain.

[0187] 8. The pool reassembles the block based on the tuple { n; IBLT; CoinBase Tx；HT root} and records the block on the blockchain by a) storing the block itself or b) storing it on a dedicated storage node.

[0188] Avoid competition between network nodes

[0189] Network nodes can select a list of verified transactions from a market consisting of several verification nodes. Unless otherwise stated, it is reasonable to assume that network nodes will select the list that maximizes their potential revenue. Careful readers may point out that this may lead to network nodes mainly selecting the same list from the same node. In turn, this will lead to some network nodes competing with each other to add transactions to the public ledger of past transactions for the same block. This benefits network nodes with the greatest hashing power.

[0190] We propose adding an additional field to the block header. This field contains a random number selected by each network node. This ensures that each network node starts from a different starting point, thus preventing the solution of the block from being reduced solely to hashing power. This will in turn simulate the current situation where network nodes tend to add transactions to the public ledger of past transactions for similar but independently selected and slightly different blocks.

[0191] Protocol

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

[0193] For the proposed system to function, the storage pools of the nodes involved (validators, network nodes, new full nodes...) should follow the sorting convention of transactions. Here, we propose using the canonical order proposed by Gavin Andresen. In this sorting, the sorting is related to the list of transactions in the block, but here we present an idea: all verification nodes and new full nodes use the same convention for their storage pools.

[0194] The convention can be summarized as follows:

[0195] 1) Sort the transactions in ascending order relative to the hash of the previous transaction.

[0196] 2) Add the first transaction from the sorted list that does not depend on subsequent transactions.

[0197] As mentioned before, the block contains the so-called Merkle root hash. It is generated by hashing all transactions (including coinbase transactions), and then hashing the concatenated hashes until the Merkle root hash is reached. Obviously, if it were not for the fact that network nodes are creating coinbase transactions, verification nodes could calculate the entire Merkle tree, and thus calculate the Merkle root and the corresponding hash.

[0198] Here, we propose a procedure to calculate the Merkle tree in the following way:

[0199] The verifier nodes calculate the Little Merkle Root. The procedure is the same as when calculating the standard Merkle Root, but with a few exceptions:

[0200] 1) Exclude coinbase transactions.

[0201] 2) Include so-called commitment transactions.

[0202] 3) The network nodes generate coinbase transactions and concatenate them with the Little Merkle Root hash to produce the Merkle Root hash.

[0203] Figure 8 The new Merkle tree structure is shown. Note that the structure constitutes a modification to the current protocol.

[0204] Modify the block header

[0205] As mentioned above, we propose to add an extra field to the block header that contains a random number selected by the network nodes. Thus, the solution to the hash puzzle changes as follows:

[0206] SHA256[SHA256[Prev.Block Hash ∥ Merkle Root ∥ nonce]]

[0207] SHA256[SHA256[RND ∥ Prev.Block Hash ∥ Merkle Root ∥ nonce]]

[0208] Therefore, we propose to enhance the block header of the new block that has incorporated past transactions with an extra field containing a random number. The block header will contain the following:

[0209] 1. Version number (4 bytes)

[0210] 2. Hash of the previous block header (32 bytes)

[0211] 3. Merkle Root Hash (32 bytes)

[0212] 4. Timestamp (4 bytes)

[0213] 5. Target threshold (encoded as nBits – 4 bytes)

[0214] 6. Nonce (4 bytes) that is used only once and is non-repeating

[0215] 7. Random number (4 bytes)

[0216] Verification → Network nodes

[0217] Verifying nodes:

[0218] o Upon request, the verifying node (which may or may not be a new full node) prepares a list of verified transactions to be added to the public ledger of past transactions.

[0219] o The verifier node creates a commitment transaction.

[0220] o Calculate the so-called Little Merkle Root (see previous section), which includes the commitment transaction.

[0221] o The verifier node prepares two IBLTs for the following:

[0222] 1) For all transactions in the block (IBLT1); and

[0223] 2) For all corresponding transaction identifiers TxID in the block (IBLT2)

[0224] o The verifier node sends to the network nodes:

[0225] 1) The Little Merkle Root.

[0226] 2) IBLT1.

[0227] 3) IBLT2 (optional - only if the network nodes are running with their own TxID- / storage pool).

[0228] 4) The previous block hash.

[0229] 5) The above hash checksum.

[0230] Network nodes:

[0231] o After receiving data from the verifier node, the network nodes continue to create the coinbase transaction. Additionally, the coinbase transaction contains an output field with a secret that matches the secret in the commitment transaction.

[0232] o The network nodes use the Little Merkle Root received from the verifier node and combine it with the coinbase transaction to create the Merkle root hash.

[0233] o The network nodes now have all the information needed to start solving the hash puzzle.

[0234] o Join the public ledger of past transactions according to the foregoing lines.

[0235] Network nodes → New full nodes

[0236] Network nodes:

[0237] o After adding transactions to the public ledger of past transactions for a block, the network nodes send the following to the list of new full nodes:

[0238] o Non-repeating random numbers (solutions to puzzles) that are used only once, n

[0239] o Coinbase transactions

[0240] o Block headers

[0241] o Merkle roots

[0242] o Small Merkle roots

[0243] o IBLT1

[0244] o IBLT2 (optional)

[0245] o Hash checksums.

[0246] New full nodes:

[0247] o Check whether the coinbase transaction contains appropriate rewards.

[0248] o Nodes check the consistency of the received data by calculating checksums (hashes).

[0249] o Nodes use IBLT1 to ensure that the transactions in the block exist in the storage pool.

[0250] o By querying the storage pool using IBLT1, nodes assemble the block. Then store the block (see the section on new full nodes and storage).

[0251] o The data received from network nodes will be broadcast to other new full nodes.

[0252] Customized transaction lists

[0253] We envision a scenario where the market for verified transactions will adapt to the needs of network nodes. Network nodes tend to select lists that maximize their potential, and verification M nodes will conform to such trends.

[0254] In some cases, network nodes may wish to customize their blocks by combining transactions from two or more lists. By calculating the differences between two IBLTs, set reconciliation can be performed between the two sets. Then, the network node sends the IBLT containing the differences back to one of the providing nodes, in this way retrieving the information required to create a list that contains all the transactions from the two lists.

[0255] Obviously, if network nodes want to compile their own lists based on several lists, it will pose additional challenges. This article briefly introduces the key points.

[0256] If a network node wants to merge the lists from various validation nodes, it is not clear how to merge the Merkle roots. Here, we propose the following suggestions:

[0257] Construct a Big Little Merkle Root of multiple single small Merkle roots; and

[0258] Combine the Big Little Merkle Root with the coinbase transaction.

[0259] The additional cost is not proportional to the amount of additional transactions added to the list / block. Since it can be reasonably assumed that various storage pools overlap significantly, merging the lists is equivalent to adding a small (relatively speaking) number of transactions from another list. However, to merge the lists, the network node must "purchase" the full list from each validation node (through committed transactions). Whether this is a profitable method for the network node remains to be seen.

[0260] Merging the lists from multiple validation nodes requires a commitment between the network node and each providing validation node. It is conceivable that the network node may abuse the system. Currently, there are no rules / protocols that enforce that all committed transactions will end up in a block. One possibility is that the validation node can check each block and veto those blocks that contain its transactions.

[0261] Summary

[0262] In terms of computational work, today's network mainly focuses on adding transactions to the public ledger of past transactions. With a significant increase in the volume of transactions, focusing on this aspect may not necessarily be feasible. The solutions described in this specification delegate various tasks to corresponding dedicated nodes, and the network nodes themselves become more specialized. Compiling a list of verified transactions, reconstructing blocks based on the block skeleton, and storage are all resource-intensive functions. Therefore, it is expected that the structure of the network will change, and the incentive mechanism will also change accordingly. We have described these issues in detail in this specification.

[0263] Among the new elements introduced in this specification, we can mention:

[0264] o A new type of node structure, referred to herein as the new full node or super node, may or may not be an extension of the validation M node.

[0265] o The nodes operate according to a protocol that effectively allows the broadcast of gigabyte-sized blocks from validation nodes to network nodes and from network nodes to new full nodes.

[0266] o Two overall storage structures for storing the blockchain, which may or may not be part of the proposed new full node.

[0267] o An incentive model that allows the creation of a market for pre-block lists of verified transactions for block assembly and storage after joining a public ledger of past transactions.

[0268] o A new Merkle tree structure that enables network nodes to dispense with maintaining their own storage pools.

[0269] o Adding an extra field with a nonce selected by network nodes to the block header to prevent the act of adding transactions to the public ledger of past transactions from becoming a competition based purely on hashing power.

[0270] o Rewarding verification through special commitment transactions.

[0271] Bloom filters and Invertible Bloom Lookup Tables (IBLTs)

[0272] In this section, we summarize the properties of the so-called Bloom filters and an extension of these filters called Invertible Bloom Lookup Tables.

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

[0274]

[0275] where S 16 is the space of hexadecimal strings on which the hash functions act. To determine whether a transaction Tx 0 belongs to the set targeted by the Bloom filter, we need to compute H 1 (Tx 0 )…H k (Tx 0 ) and then check whether the corresponding bits in the array are set to 1. Figure 9 Illustrates the workflow for creating a Bloom filter.

[0276] If one or more are false, then Tx 0 is definitely not in the queried set. However, Bloom filters do allow false positives. This is because the probability that a hash function changes a bit to 1 is p = 1 / |size of array| = 1 / M, where "sizeof array" is the size of the array. Thus, the bits are not set to 1 by the so-called given hash functions as follows:

[0277]

[0278] Therefore, if there are k hash functions, the probability that a given bit is not set to 1 is

[0279]

[0280] If n elements need to be inserted, the probability becomes

[0281]

[0282] An obvious drawback of the Bloom filter is that it neither tracks nor maintains any particular order. Clearly, if we wish to maintain an index of the items to be filtered, we need to extend the functionality of the filter. This is where the Invertible Bloom Filter (IBF) and the Invertible Bloom Lookup Table (IBLT) come into play.

[0283] Instead of just activating the bits in the array, the XOR sum of the keys, the hash values (as before), and the total counter are stored in each field of the IBF. The process is as Figure 10 shown Figure 10 shows the workflow illustrating how transactions are encoded in the IBF / IBLT.

[0284] Application

[0285] We assume that there are two nodes N 1 and N 2 , which respectively maintain storage pools m 1 and m 2 . Each storage pool contains elements from the entire hexadecimal string S 16 . We further assume that the storage pools follow the sorting convention proposed by Andresen and outlined earlier in this specification.

[0286] Now, N 1 sends m 1 to N 2. , N 2. Now the set reconciliation can be processed in two ways:

[0287] (1) Calculate the set difference by △m = m 2 - m 1 (see (David Eppstein, 2011), (Michael T. Goodrich, 2011))

[0288] (2) Iterate through the transactions in m 2 and check whether the said transaction exists in the storage pool of N 1 We can see that the IBLT can be used for at least two purposes:

[0289] 1) Let the nodes assemble the blocks of the common ledger that have joined the past transactions according to the transactions already existing in their storage pools, and help identify and retrieve the blocks they do not have.

[0290] 2) Maintain a certain level of synchronization between storage pools belonging to different nodes.

[0291] It should be understood that the user can instead use the methods and systems described herein to exchange other resources (such as information, contracts, and tokens). Tokens represent assets or resources according to the smart contracts associated with them, such that control of the tokens has the ability to control the assets or resources. The smart contracts themselves can be stored outside the blockchain or in one or more transactions.

[0292] References

[0293] An Integrated World.(n.d.).Retrieved from https: / / www.anintegratedworld.com / whats-in-a-block /

[0294] David Eppstein,M.T.(2011).What's the Difference?Efficient SetReconciliation without Prior Context.ACM.

[0295] maidsafe.(n.d.).Retrieved from github.com:https: / / github.com / maidsafe / Whitepapers

[0296] Michael T.Goodrich,M.M.(2011).Invertible Bloom LookupTables.Communication,Control,and Computing(Allerton),2011 49th AnnualAllerton Conference on.

[0297] NebulousLabs.(n.d.).Retrieved from github.com:https: / / github.com / NebulousLabs / Sia

[0298] O(1)Block Propagation.(n.d.).Retrieved from github.com:https: / / gist.github.com / gavinandresen / e20c3b5a1d4b97f79ac2

[0299] Wikipedia.(n.d.).Retrieved from https: / / en.wikipedia.org / wiki / Distributed_hash_table

[0300] Wilkinson et al.(2016,December 15).Retrieved from https: / / storj.io / storj.pdf

[0301] It should be noted that the above embodiments illustrate rather than limit the present invention. Without departing from the scope of the present invention as defined by the appended claims, those skilled in the art will be able to design many alternative embodiments. In the claims, any reference signs in parentheses shall not be construed as limiting the claims. The word "comprising" etc. does not exclude the presence of other elements and steps as a whole, although these elements and steps are not listed in any claim or the specification. In this specification, "comprising" means "comprising or consisting of". The singular reference to an element does not mean the exclusion of a plural reference to such elements, and vice versa. The present invention can be implemented by means of hardware including several different elements, as well as by means of a suitably programmed computer. In a device claim listing several devices, several of these devices can be embodied by the same component of the hardware. It is an established fact that the listing of certain methods in mutually different dependent claims does not mean that the combination of these methods cannot achieve beneficial effects.

Claims

1. A computer-implemented method for a transaction verification node in a blockchain network, the computer-implemented method comprises: (i) receiving a transaction from the blockchain network; (ii) verifying the transaction received from the blockchain network; (i) maintaining a distributed and decentralized storage of verified transactions together with other transaction verification nodes in the blockchain network; and (iv) distributing data corresponding to the verified transaction to the blockchain network.

2. The computer-implemented method according to claim 1, wherein, the step of maintaining a distributed and decentralized storage of verified transactions together with other transaction verification nodes in the blockchain network includes: synchronizing the transaction verification nodes on the blockchain network to maintain an up-to-date list of the verified transactions in a decentralized and distributed manner.

3. The computer-implemented method according to claim 2, wherein, the verification nodes are synchronized by exchanging reversible Bloom filter lookup tables.

4. The computer-implemented method according to any one of the preceding claims, wherein, the verified transactions are sorted in a defined order for using a common sorting system on the transaction verification nodes in the blockchain network to maintain the distributed and decentralized storage of the verified transactions.

5. The computer-implemented method according to claim 4, wherein, the verified transactions are sorted in the defined order using a canonical sorting system to maintain the distributed and decentralized storage of the verified transactions.

6. The computer-implemented method according to any one of the preceding claims, wherein, the step of distributing data corresponding to the verified transaction to the blockchain network includes: preparing data corresponding to the list of the verified transactions.

7. The computer-implemented method according to any one of the preceding claims, wherein, the step of distributing data corresponding to the verified transaction to the blockchain network includes: creating a commitment transaction for digital asset exchange to provide the data corresponding to the list of the verified transactions to network nodes.

8. The computer-implemented method according to claim 7, wherein, in the case where the commitment transaction is included, calculating a hash tree, a Patricia tree, or another type of radix tree.

9. The computer-implemented method according to any one of the preceding claims, wherein, the data corresponding to the verified transaction is distributed to the blockchain network in the form of a reversible Bloom lookup table and any accompanying data.

10. The computer-implemented method according to any one of the preceding claims, wherein, the transaction verification node is configured to verify transactions and maintain a distributed and decentralized storage of verified transactions; the distributing data corresponding to the verified transaction to the blockchain network includes: distributing the data corresponding to the verified transaction from the transaction verification node to at least one network node in the blockchain network for joining a public ledger of past transactions; the method further includes: (v) At the transaction verification node, receive data of the public ledger of the joined past transactions corresponding to the verified transaction from the blockchain network; (vi) Assemble a block based on the data of the public ledger of the joined past transactions; and (vii) Send the assembled block to a storage entity for storage on the blockchain.

11. The computer-implemented method according to claim 10, wherein, the data of the public ledger of the joined past transactions received from the blockchain network includes a block header corresponding to the verified transaction.

12. The computer-implemented method according to claim 10 or 11, wherein, the data of the public ledger of the joined past transactions includes a transaction for exchanging digital assets for assembling the block based on the data of the public ledger of the joined past transactions.

13. The computer-implemented method according to any one of claims 10 to 12, wherein, the data of the public ledger of the joined past transactions includes a transaction for exchanging digital assets for storage of the assembled block.

14. The computer-implemented method according to claim 12 or 13, further comprising: Before receiving the digital assets, require waiting for a period of time t associated with a minimum number of blocks.

15. The computer-implemented method according to any one of claims 10 to 14, wherein, the step of assembling the block based on the data of the public ledger of the joined past transactions includes assembling large blocks, wherein the size of each such block is at least 2 megabytes.

16. The computer-implemented method according to any one of claims 10 to 15, wherein, the block includes a block header containing a random number provided by a network node.

17. The computer-implemented method according to any one of claims 10 to 16, wherein, the storage entity is shared among multiple nodes on the blockchain network, and the multiple nodes form super nodes on the blockchain network, wherein the shared storage entity is a public storage node, a distributed storage device, or a combination of both.

18. A computer-readable storage medium including computer-executable instructions that, when executed, cause a processor to perform the method according to any one of claims 1 to 17.

19. An electronic device, comprising: an interface device; one or more processors coupled to the interface device; a memory connected to the one or more processors, and computer-executable instructions are stored on the memory, and when the computer-executable instructions are executed, the one or more processors perform the method according to any one of claims 1 to 17.

20. A transaction verification node of a blockchain network, the transaction verification node being configured to perform the method according to any one of claims 1 to 17.

21. A super node of a blockchain network, the super node comprising: a plurality of verification nodes according to claim 20; and a shared storage entity for storing the blockchain, wherein the shared storage entity is a public storage node, a distributed storage device, or a combination of both, and Among them, the block assembled by the multiple verification nodes is sent to and stored on the shared storage entity, whereby the shared storage entity maintains the blockchain.

22. The super node according to claim 21, wherein, the shared storage entity includes a storage capacity of at least 100 gigabytes.

23. A blockchain network, comprising a plurality of super nodes according to claim 21 or 22, wherein, the super nodes are connected to the blockchain network, wherein the shared storage entity of each super node is used to store a copy of the blockchain, and wherein the blockchain network includes at least 10 such super nodes.

Images