Method and node for a network that improves verification speed by means of tamper-proof data

Abstract

Disclosed are a method and a node for a network that improves verification speed through tamper-proof data. The method includes: a) receiving a node identifier from a node among multiple nodes in a computer network; b) determining a plurality of node committees in a sampler graph including multiple nodes, wherein a node exists in one of the plurality of node committees; c) and i) generating a random string; ii) performing a proof-of-work process using the random string and a hash function; iii) if the proof-of-work process produces an acceptable solution, broadcasting the solution to all other nodes among the multiple nodes, wherein the other nodes verify the solution; and iv) if the other nodes verify the solution, selecting the node to a subcommittee of the node committee, wherein the subcommittee updates the sampler graph; and d) repeating steps b) and c) until a leadership committee is determined.

Description

[0001] This divisional application of the invention patent application has an international application number of PCT / US2018 / 033958, an international filing date of May 22, 2018, and a national phase entry application number in China of 201880041576.9, with the title "Method and Node for a Network that Improves Verification Speed through Tamper-Resistant Data".

[0002] Cross-reference to Related Applications

[0003] This application claims the benefit of U.S. Provisional Application No. 62 / 509,655, filed on May 22, 2017, and U.S. Provisional Application No. 62 / 668,122, filed on May 7, 2018, which are hereby incorporated by reference in their entirety for all purposes. Background Art

[0004] The global financial system is highly centralized, making it resistant to change, vulnerable to failures and attacks, and inaccessible to billions of people in need of basic financial tools. Cryptocurrencies aim to avoid these limitations by using large decentralized networks that allow for an "open membership" of participants. In this model, participants do not need a predefined identity to join the system and can join or leave the protocol at any time.

[0005] Decentralization poses new challenges in ensuring a consistent view among a group of mutually distrustful (i.e., Byzantine) participants. The permissionless mode of operation that allows for an open membership and requires continuous changes (i.e., joining and leaving) of participants will further complicate this task. Additionally, any agile financial system (including distributed ones) should be able to adequately handle the actual market load. This means that the system should be able to easily scale to a large number of participants and handle high transaction throughput at relatively low latency in order to provide output. The realization of these properties should also not use a large amount of resources from each participant, as this would run counter to the idea of building a tool that anyone can easily access.

[0006] Existing solutions currently fail to address the above challenges or make security and / or performance trade - offs, but unfortunately make them no longer truly decentralized solutions. Specifically, traditional Byzantine consensus mechanisms [Leslie Lamport, The Part - Time Parliament, ACM Transactions on Computer Systems, 16(2):133 to 169, May 1998; and Miguel Castro and Barbara Liskov, Practical Byzantine Fault Tolerance. In Proceedings of the Third Symposium on Operating Systems Design and Implementation, OSDI'99, pages 173 to 186, 1999; and Christian Cachin, Klaus Kursawe, and Victor Shoup, Random Oracles in Constantinople: Practical Asynchronous Byzantine Agreements Using Cryptography. In Proceedings of the 19 届 ACM Symposium on Principles of Distributed Computing (PODC), pages 123 to 132, 2000] can only work in a closed - membership setting where a fixed group of participants is known to all and their identities are known to all through a trusted third party. If used in an open - membership setting, these protocols may be vulnerable to compromise by Sybil attacks [John Douceur, The Sybil Attack. In Proceedings of the Second International Workshop on Peer - to - Peer Systems (IPTPS), 2002], where an adversary repeatedly rejoins the malicious parties with fresh identities to have a significant impact on the protocol outcome. Additionally, most traditional schemes assume a static adversary where a set of corrupt parties can be chosen only at the start of the protocol. Existing protocols against adaptive adversaries [Gabriel Bracha, Asynchronous [(n–1) / 3] - resilient consensus protocols. In Proceedings of the Third Annual ACM Symposium on Principles of Distributed Computing, PODC'84, pages 154 to 162, New York, NY, USA, 1984, ACM; and Run Canetti and Tal Rabin, Fast Asynchronous Byzantine Agreement with Optimal Resilience. In Proceedings of the 25th Annual ACM Symposium on Theory of Computing, STOC'93, pages 42 to 51, New York, NY, USA, 1993, ACM; and Valerie King and Jared Saia, Disconnecting o(n^2) - bit Barriers: Scalable Byzantine Agreements with Adaptive Adversaries. In Proceedings of the 29th ACM SIGACT - SIGOPS Symposium on Principles of Distributed Computing, PODC'10, pages 420 to 429, New York, NY, USA, 2010, ACM] scale poorly or are inefficient as the number of participants grows.

[0007] Most cryptocurrencies, such as Ethereum [Vitalik Buterin, Ethereum white paper. https: / / github.com / ethereum / wiki / wiki / white-paper, 2014] maintain a distributed transaction ledger called a blockchain within a large peer-to-peer (P2P) network, where each node maintains an up-to-date and complete copy of the entire ledger through a Byzantine consensus protocol known as Nakamoto consensus. Different from traditional consensus mechanisms, Nakamoto consensus allows new participants to join the protocol using the proof-of-work (PoW) process [Cynthia Dwork and Moni Naor, Pricing via processing or combatting junk mail. In Advances in Cryptology - CRYPTO'92: Proceedings of the 12th Annual International Cryptology Conference, Santa Barbara, California, USA, August 16-20, 1992, pages 139-147, Berlin Heidelberg, 1993, Springer-Verlag], where a node demonstrates that it has done a certain amount of work by providing a solution to a computational puzzle. The use of PoW not only allows the consensus protocol to deter Sybil attacks by restricting the rate at which malicious participants can join the system, but also provides a lottery mechanism through which a random leader is selected in each round to initiate the consensus process.

[0008] Unfortunately, it is now well-known that the PoW-based consensus of some cryptocurrencies has serious flaws at present, such as very low transaction throughput, high latency, poor energy efficiency [http: / / gizmodo.com / the-worlds-most-powerful-computer-network-is-being-was-504503726], and mining pool centralization [https: / / medium.com / @homakov / stop-calling-bitcoin-decentralized-cb703d69dc27, 2017, and Blockchain Chart: Hash Rate Distribution, March 2017, available at https: / / blockchain.info / pools]. In addition, the protocol cannot scale its transaction processing capacity in the case of a large number of participants joining the protocol [Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena, Secure Sharding Protocols for Open Blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pages 17 to 30, New York, NY, USA, 2016, ACM; and Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford, OmniLedger: Secure, Scalable, Decentralized Ledger via Sharding, Cryptology ePrint Archive, Report 2017 / 406, 2017. https: / / eprint.iacr.org / 2017 / 406]. Another major scalability issue of the above cryptocurrencies is that each party initially needs to download the entire blockchain from the network to independently verify all transactions. The size of the blockchain is currently about 165GB and has almost doubled in the past year [Blockchain Chart: Blockchain Size, March 2017, available at https: / / blockchain.info / charts / block-size]. A large increase in the size of the blockchain can be expected, and compared with the above cryptocurrencies, the blockchain is updated through a high-throughput consensus protocol.

[0009] Recently, several protocols have been proposed to alleviate the performance and scalability issues of the blockchains of the above cryptocurrencies [Andrew Miller, Yu Xia, Kyle Croman, Elaine Shi, and Dawn Song, HoneyBadger of BFT Protocols. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pages 31–42, New York, NY, USA, 2016, ACM; and Rafael Pass and Elaine Shi, Hybrid Consensus: Efficient Consensus in Permissionless Models, Cryptology ePrint Archive, Report 2016 / 917, 2016. http: / / eprint.iacr.org / 2016 / 917; and Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena, Secure Sharding Protocols for Open Blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pages 17–30, New York, NY, USA, 2016, ACM; and Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, and Nickolai Zeldovich, Algorand: Scaling Byzantine Agreements for Cryptocurrencies. In Proceedings of the 26th Symposium on Operating Systems Principles, SOSP'17, pages 51–68, New York, NY, USA, 2017, ACM; and Ittai Abraham, Dahlia Malkhi, Kartik Nayak, Ling Ren, and Alexander Spiegelman, Solida: A Blockchain Protocol Based on Reconfigurable Byzantine Consensus. In Proceedings of the 21st International Conference on Principles of Distributed Systems, OPODIS'17, Lisbon, Portugal, 2017; and Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford, OmniLedger: A Secure, Scalable, Decentralized Ledger via Sharding, Cryptology ePrint Archive, Report 2017 / 406, 2017.https: / / eprint.iacr.org / 2017 / 406], [M. Pease, R. Shostak, and L. Lamport, Reaching Agreement in the Presence of Faults, Journal of the ACM, 27(2):228–234, April 1980; and M. Castro and B. Liskov, Practical Byzantine Fault Tolerance and Proactive Recovery, ACM Transactions on Computer Systems (TOCS), 20(4):398–461, 2002]. Although most of these protocols are said to improve the throughput and latency of the above cryptocurrencies, all of these protocols still require the often overlooked assumption of a trusted setup: generating unpredictable initial common randomness in the form of a common origin block to bootstrap the blockchain. Similar to the above cryptocurrencies, these protocols basically describe how agreement on new blocks can be ensured given agreement on an origin block. This assumption plays a crucial role in reaching agreement among the nodes in these protocols and, if compromised, can easily affect the security of the entire consensus protocol, thus having a significant impact on the decentralized nature of the cryptocurrency.

[0010] Besides partial decentralization, most of these solutions have large per-node storage requirements [Andrew Miller, Yu Xia, Kyle Croman, Elaine Shi, and Dawn Song, HoneyBadger of BFT Protocols. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pages 31–42, New York, NY, USA, 2016, ACM; and Rafael Pass and Elaine Shi, Hybrid Consensus: Efficient Consensus in Permissionless Models, Cryptology ePrint Archive, Report 2016 / 917, 2016. http: / / eprint.iacr.org / 2016 / 917; and Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena, Secure Sharding Protocols for Open Blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pages 17–30, New York, NY, USA, 2016, ACM; and Ittai Abraham, Dahlia Malkhi, Kartik Nayak, Ling Ren, and Alexander Spiegelman, Solida: A Blockchain Protocol Based on Reconfigurable Byzantine Consensus. In Proceedings of the 21st International Conference on Principles of Distributed Systems, OPODIS'17, Lisbon, Portugal, 2017], incomplete specifications, or security issues [Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena, Secure Sharding Protocols for Open Blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pages 17–30, New York, NY, USA, 2016, ACM; and Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford, OmniLedger: A Secure, Scalable, Decentralized Ledger via Sharding, Cryptology ePrint Archive, Report 2017 / 406, 2017. https: / / eprint.iacr.org / 2017 / 406].In addition, all previous protocols require each participant in the consensus protocol to broadcast messages to the entire network to submit their consensus votes [Andrew Miller, Yu Xia, Kyle Croman, Elaine Shi, and Dawn Song, Honey Badger of BFT Protocols. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pages 31–42, New York, NY, USA, 2016, ACM], verify transactions [Andrew Miller, Yu Xia, Kyle Croman, Elaine Shi, and Dawn Song, Honey Badger of BFT Protocols. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pages 31–42, New York, NY, USA, 2016, ACM], and / or update each node's local blockchain copy [Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena, Secure Sharding for Open Blockchain. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pages 17–30, New York, NY, USA, 2016, ACM; and Rafael Pass and Elaine Shi, Hybrid Consensus: Efficient Consensus in Permissionless Models, Cryptology ePrint Archive, Report 2016 / 917, 2016. http: / / eprint.iacr.org / 2016 / 917; and Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, and Nickolai Zeldovich, Algorand: Scaling Byzantine Agreements for Cryptocurrencies. In Proceedings of the 26th Symposium on Operating Systems Principles, SOSP'17, pages 51–68, New York, NY, USA, 2017, ACM; and Ittai Abraham, Dahlia Malkhi, Kartik Nayak, Ling Ren, and Alexander Spiegelman, Solida: A Blockchain Protocol Based on Reconfigurable Byzantine Consensus. In Proceedings of the 21st International Conference on Principles of Distributed Systems, OPODIS'17, Lisbon, Portugal, 2017].Although the relatively large overhead of such broadcasts per participant is typically reduced from a linear number of messages (relative to the number of participants) to almost constant using a peer-to-peer gossip protocol [R. Karp, C. Schindelhauer, S. Shenker, and B. Vocking, Randomized rumor spreading. In Proceedings of the 41st Annual Symposium on Foundations of Computer Science, FOCS'00, pages 565–, Washington, DC, USA, 2000, IEEE Computer Society], the relatively high latency of such “broadcast to all objects” calls (e.g., 12.6 seconds per block on average) significantly increases the overall latency of the consensus protocol (the latency of broadcast to all objects almost quadruples the consensus time [Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford, OmniLedger: A Secure, Scalable, Decentralized Ledger via Sharding, Cryptology ePrint Archive, Report 2017 / 406, 2017. https: / / eprint.iacr.org / 2017 / 406]). Additionally, since the transaction throughput of most scalable blockchain protocols is very high (e.g., approximately 4,000 TPS [Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford, OmniLedger: A Secure, Scalable, Decentralized Ledger via Sharding, Cryptology ePrint Archive, Report 2017 / 406, 2017. https: / / eprint.iacr.org / 2017 / 406]), if transactions are broadcast to the entire network, the bandwidth usage per node is relatively large (e.g., higher than 6 MB / s).

[0011] Embodiments of the present invention, alone and in combination, solve these and other problems. SUMMARY OF THE INVENTION

[0012] Embodiments may implement selecting a leadership committee in a computer network. The leadership committee may be able to partition multiple nodes in the computer network into shard committees. Embodiments may allow new nodes to join the computer network. The shard committees may receive interaction data that can be verified and stored in a shard of a blockchain.

[0013] One embodiment of the present invention relates to a method performed by a node in a computer network comprising a plurality of nodes, each node having a node identifier, the method comprising: a) the node receiving node identifiers from other nodes among the plurality of nodes in the computer network; b) the node determining a plurality of node committees in a sampler graph comprising the plurality of nodes, wherein the node is present in one of the plurality of node committees; c) the node further i) generating a random string; ii) performing a proof-of-work process using the random string and a hash function; iii) if the proof-of-work process produces an acceptable solution, broadcasting the solution to all other nodes among the plurality of nodes, wherein the other nodes verify the solution; and iv) if the other nodes verify the solution, selecting the node to a sub-committee of the node committee, wherein the sub-committee updates the sampler graph; and d) repeating steps b) and c) until a leadership committee is determined.

[0014] Another embodiment of the present invention relates to a node comprising: a processor; a memory device; and a computer-readable medium coupled to the processor, the computer-readable medium comprising code executable by the processor for implementing a method performed by a node in a computer network comprising a plurality of nodes, each node having a node identifier, the method comprising: a) receiving node identifiers from other nodes among the plurality of nodes in the computer network; b) determining a plurality of node committees in a sampler graph comprising the plurality of nodes, wherein the node is present in one of the plurality of node committees; c) the node further i) generating a random string; ii) performing a proof-of-work process using the random string and a hash function; iii) if the proof-of-work process produces an acceptable solution, broadcasting the solution to all other nodes among the plurality of nodes, wherein the other nodes verify the solution; and iv) if the other nodes verify the solution, selecting the node to a sub-committee of the node committee, wherein the sub-committee updates the sampler graph; and d) repeating steps b) and c) until a leadership committee is determined.

[0015] Another embodiment of the present invention relates to a method, which includes: receiving, by a first node in a first committee in a computer network, a request including a node identifier to enable a second node to join the committee; providing, by the first node in the first committee, a proof-of-work process to the second node; receiving, by the first node in the first committee, a solution to the proof-of-work process from the second node, wherein a plurality of nodes in the first committee verify the solution; generating, by the first node in the first committee, a random string, which is used by the first node to determine a second committee for the second node; introducing, by the first node, the second node to the second committee, wherein the second committee shifts nodes to allow the second node to join the second committee; and communicating, by the first node, information that the second node is in the second committee to other nodes in the computer network.

[0016] Another embodiment of the present invention relates to a node, which includes: a processor; a memory device; and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor for implementing a method including the following operations: receiving, by a first node in a first committee in a computer network, a request including a node identifier to enable a second node to join the committee; providing, by the first node in the first committee, a proof-of-work process to the second node; receiving, by the first node in the first committee, a solution to the proof-of-work process from the second node, wherein a plurality of nodes in the first committee verify the solution; generating, by the first node in the first committee, a random string, which is used by the first node to determine a second committee for the second node; introducing, by the first node, the second node to the second committee, wherein the second committee shifts nodes to allow the second node to join the second committee; and communicating, by the first node, information that the second node is in the second committee to other nodes in the computer network.

[0017] Another embodiment of the present invention relates to a method, which includes: receiving, by a first node in a committee, an interaction request, the interaction request including interaction data from a client computer; incorporating, by the first node, the interaction data and other interaction data associated with other client computers into a block including the interaction data, wherein the block includes block parts; broadcasting, by the first node, the block to other nodes in the committee, wherein the other nodes in the committee verify the block; and incorporating the block into a blockchain managed by the committee.

[0018] Another embodiment of the present invention relates to a node, which includes: a processor; a memory device; and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor for implementing a method including the following operations: receiving, by a first node in a committee, an interaction request, the interaction request including interaction data from a client computer; incorporating, by the first node, the interaction data and other interaction data associated with other client computers into a block including interaction data, wherein the block includes block portions; broadcasting, by the first node, the block to other nodes in the committee, wherein the other nodes in the committee verify the block; and incorporating the block into a blockchain managed by the committee.

[0019] These and other embodiments of the present invention are described in further detail below. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 A block diagram showing a system of multiple nodes in a computer network according to an embodiment of the present invention is shown.

[0021] Figure 2 A block diagram showing a node according to an embodiment of the present invention is shown.

[0022] Figure 3 A flowchart showing stages in a method according to an embodiment of the present invention is shown.

[0023] Figure 4 A block diagram showing a selection chart according to an embodiment of the present invention is shown.

[0024] Figure 5 A flowchart showing a setup stage according to an embodiment of the present invention is shown.

[0025] Figure 6 A block diagram showing a system including a sharding committee according to an embodiment of the present invention is shown.

[0026] Figure 7 A flowchart showing a reconfiguration stage according to an embodiment of the present invention is shown.

[0027] Figure 8 A block diagram showing a transaction portion according to an embodiment of the present invention;

[0028] Figure 9 A flowchart showing a consensus stage according to an embodiment of the present invention is shown.

[0029] Figure 10 A flowchart showing a verification process according to an embodiment of the present invention is shown.

[0030] Figure 11A flowchart showing communication routing according to an embodiment of the present invention.

[0031] Figure 12 A flowchart showing communication response routing according to an embodiment of the present invention.

[0032] Figure 13 A diagram showing communication in the setup phase according to an embodiment of the present invention.

[0033] Figure 14 A diagram showing setup phase delay according to an embodiment of the present invention.

[0034] Figure 15 A diagram showing transaction costs according to an embodiment of the present invention.

[0035] Figure 16 A diagram showing transaction delay according to an embodiment of the present invention.

[0036] Figure 17 A diagram showing transaction delay with a variable committee size according to an embodiment of the present invention.

[0037] Figure 18 A diagram showing transaction costs with a variable committee size according to an embodiment of the present invention.

[0038] Figure 19 A diagram showing the number of messages per node count according to an embodiment of the present invention.

[0039] Figure 20 A diagram showing bandwidth versus the number of nodes according to an embodiment of the present invention.

[0040] Figure 21 A diagram showing delay versus the number of nodes according to an embodiment of the present invention.

[0041] Figure 22 A diagram showing the cost of handling changes according to an embodiment of the present invention.

[0042] Figure 23 A diagram showing change delay according to an embodiment of the present invention.

[0043] Figure 24 A diagram showing the probability of failure according to an embodiment of the present invention.

[0044] Figure 25 A diagram showing delay versus committee size according to an embodiment of the present invention.

[0045] Figure 26 A diagram showing user-perceived delay versus the number of nodes according to an embodiment of the present invention.

[0046] Figure 27 A graph showing transactions per second and committee size according to an embodiment of the present invention.

[0047] Figure 28 A graph showing transactions per second and block size according to an embodiment of the present invention. Detailed implementation

[0048] Before discussing embodiments of the present invention, some terms can be described in further detail.

[0049] "Digital asset" can refer to digital content associated with value. In some cases, a digital asset can also indicate a transfer of value. For example, a digital asset can include data indicating the transfer of a monetary value (e.g., fiat currency or cryptocurrency). In other embodiments, a digital asset can correspond to other non-monetary values, such as access permission data (e.g., the number of authorized uses or time allocation for accessing information) and ownership data (e.g., digital rights data). A digital asset can also include information about one or more digital asset attributes. For example, a digital asset can include useful information for transferring value from one entity or account to another entity or account. A digital asset can also include remittance information (e.g., information identifying the sending entity). In some embodiments, a digital asset can include one or more of the following: a digital asset identifier, a value (e.g., an amount, an original currency type, a destination currency type, etc.), transfer fee information, a currency exchange rate, an invoice number, a purchase order number, a timestamp, a sending entity identifier (e.g., a sender enterprise ID), a sending entity account number, a sending entity name, a sending entity contact information (e.g., an address, a phone number, an email address, etc.), a sending institution information (e.g., a financial institution name, an enterprise ID, and a BIN), a receiving entity identifier (e.g., a receiver enterprise ID), a receiving entity account number, a receiving entity name, a receiving entity contact information (e.g., an address, a phone number, an email address, etc.), and / or a receiving institution information (e.g., a financial institution name, an enterprise ID, and a BIN). When a digital asset is received, the recipient can have sufficient information to proceed with a settlement transaction for the indicated value.

[0050] "Asset transfer network" can be a network for providing and / or receiving digital assets. An asset transfer network can include multiple nodes. In some embodiments, digital assets transmitted in an asset transfer network can be recorded in a ledger of transactions. An example of an asset transfer network can be a blockchain network, where the ledger of transactions can take the form of a blockchain. In some embodiments, an asset transfer network can be a computer network.

[0051] The term "node" can refer to a connection point. In some embodiments, a node can be a physical electronic device that is capable of creating, receiving, or transmitting data. In other embodiments, a node can be a software module on a computing device that is a connection point in a communication network. In some embodiments, a node can be a computing device within an asset transfer network. A node is capable of minting assets, transferring assets, receiving assets, verifying assets, maintaining a ledger of transactions, and / or performing any other suitable function. In some embodiments, a node can be associated with and / or operated by a financial institution computer (such as a bank), a payment processor computer, a third-party computer, or any other suitable entity.

[0052] The term "transaction ledger" can refer to a compilation of data from previous transactions. A transaction ledger can be a database or other comparable file structure that can be configured to store data from all previous digital asset transfers, including the date and time of the transfer, the transfer amount, and the identity information of the transfer participants (e.g., the sender and recipient of the transfer amount). In some embodiments, a transaction ledger can be in the form of an electronic ledger (e.g., a blockchain), where the data already stored in the electronic ledger can be immutable. Portions (i.e., shards) of the transaction ledger can be stored at nodes.

[0053] A transaction ledger can include transaction records that are digitally signed (e.g., with a private key) to protect the transaction entries in the ledger from being tampered with by false transaction data. This can prevent double-spending and make all transactions immutable and irreversible, thus making the ledger trustworthy.

[0054] As used herein, "blockchain" can include a series of blocks. Each block in a blockchain can include an electronic record of one or more historical transactions and metadata. In some embodiments, the blocks in a blockchain can be linked by including a reference to a previous block (e.g., the hash output of the previous block). Each new block in a blockchain can be determined algorithmically based on new transactions and previous blocks in the blockchain. As a result, any tampering with the data stored in these previous blocks can be detected. In some embodiments, a blockchain can be sharded into blockchain shards stored at committees. For example, a committee can store a shard of the blockchain, and different committees can store different shards of the blockchain.

[0055] A "committee" can be a group of nodes. In some embodiments, the nodes in a committee can communicate with each other. A committee may be able to communicate with other committees. In some embodiments, a committee can include nodes that can be committee leaders.

[0056] "Key pair" may include a pair of associated cryptographic keys. For example, a key pair may include a public key and a corresponding private key. In a key pair, the first key (e.g., the public key) can be used to encrypt a message, while the second key (e.g., the private key) can be used to decrypt the encrypted message. Additionally, the public key can verify a digital signature created with the corresponding private key. The public key can be distributed across the network so as to be able to authenticate messages signed with the corresponding private key. The public key and the private key can be in any suitable format, including formats based on RSA or elliptic curve cryptography (ECC). In some embodiments, an asymmetric key pair algorithm can be used to generate the key pair. However, as would be understood by one of ordinary skill in the art, other means can also be used to generate the key pair.

[0057] The term "digital signature" can refer to an electronic signature of a message. A digital signature can be a numerical value, an alphanumeric value, or any other type of data including a graphical representation. A digital signature can be a unique value generated from the message and a private key using a cryptographic algorithm. In some embodiments, a verification algorithm employing a public key can be used to verify the signature.

[0058] "Client computer" generally can refer to a computer that can submit interaction data to the committee. The client computer can include a computer (such as a desktop computer), a mobile device (such as a smart phone, a laptop computer, or a tablet computer), or a wearable device (such as a smart watch or an activity tracker). The client computer can include wireless communication capabilities (such as Wi-Fi, Bluetooth, or near field communication). In some embodiments, the client computer can communicate with a node in the committee.

[0059] "Interaction" can include communication, connection, or exchange between parties, devices, and / or entities. Example interactions include a transaction between two parties and a data exchange between two devices. An interaction can include the transfer of digital assets.

[0060] "Interaction data" can be data associated with an interaction. For example, the interaction might be the transfer of a digital asset from one party to another. For example, interaction data can include the transaction amount and unspent transaction outputs (UTXOs). In some embodiments, the interaction data can indicate different entities that are parties to the interaction and the value or information being exchanged. Interaction data can include value, information associated with the sender (such as token or account information, alias, device identifier, contact address, etc.), information associated with the receiver (such as token or account information, alias, device identifier, contact address, etc.), a one-time value (such as a random value, a nonce, a timestamp, a count, etc.), and / or any other suitable information. An example of interaction data can be transaction data.

[0061] A "block portion" can be each part of a block of a blockchain. The block portion can include unspent transaction outputs (UTXOs). Other block portions can include headers, interactive data, block identifiers, and Merkle trees. A block header can include the hash of the previous block, a timestamp, a difficulty target, a nonce, and / or a Merkle root.

[0062] A "sampler graph" can be a graph of data with nodes and edges, such as a random bipartite graph. The bipartite graph can include two sets L and R. Set L can include vertices that can represent nodes. Set R can include vertices that represent committees. Multiple sampler graphs linked together can be regarded as selection graphs. In some embodiments, a sampler graph can include nodes in a level of a selection graph that are connected by edges to a next-level committee of the selection graph.

[0063] A "processor" can refer to any suitable data computing device. The processor can include one or more microprocessors that work together to implement the desired function. The processor can include a CPU, and the CPU includes at least one high-speed data processor that is sufficient to execute program components for executing user- and / or system-generated requests. The CPU can be a microprocessor, such as the Athlon, Duron, and / or Opteron of AMD; the PowerPC of IBM and / or Motorola; the Cell processor of IBM and Sony; the Celeron, Itanium, Pentium, Xeon, and / or XScale of Intel; and / or similar processors.

[0064] A "memory" can be any suitable device that can store electronic data. Suitable memories can include non-transitory computer-readable media that store instructions executable by the processor to implement the desired method. Examples of memories can include one or more memory chips, disk drives, etc. Such memories can operate using any suitable electrical, optical, and / or magnetic operating modes.

[0065] Introduction

[0066] Figure 1 FIG. shows a block diagram of a system 100 including multiple components according to some embodiments of the present invention. System 100 includes multiple nodes, which include node A 101, node B 102, node C 103, node D 104, node E 105, node F 106, node G 107, and node H 108. In Figure 1In [the figure], node A 101 can operatively communicate with node B 102, node C 103, and node D 104. It should be understood that any suitable node arrangement can be used. For example, node A 101 can operatively communicate with node H 108. In some embodiments, any number of nodes may be present among the multiple nodes. In other embodiments, new nodes can join the computer network, and nodes can leave the computer network. The nodes in system 100 can represent the computer network before creating a node committee, as described below.

[0067] Figure 1 Messages between the nodes shown [in the figure] can be transmitted using a secure communication protocol, such as but not limited to: File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), Secure Hypertext Transfer Protocol (HTTPS), Secure Sockets Layer (SSL), ISO (e.g., ISO 8583), and so on. Messages can be transmitted and received via a communication network. The communication network can include any suitable communication medium. The communication network can be one and / or a combination of the following: direct interconnection; the Internet; local area network (LAN); metropolitan area network (MAN); Operations on Internet Nodes (OMNI); secure custom connection; wide area network (WAN); wireless network (e.g., using protocols such as but not limited to Wireless Application Protocol (WAP), i-mode, etc.).

[0068] Figure 2 A block diagram of a node according to some embodiments of the present invention is shown. Exemplary node 200 can include a processor 204. Processor 204 can be coupled to a memory 202, a network interface 206, and a computer-readable medium 208 including a selection module 208A, a reconfiguration module 208B, and a consensus module 208C.

[0069] Memory 202 can store shards of the blockchain, interaction data, routing tables, node identifiers, and any other relevant data. Memory 202 can be in the form of a secure element, a hardware security module, or any other suitable data storage form. The node identifier can be a public key associated with the node. For example, the first node can be associated with the first public key.

[0070] Interaction data may be data associated with an interaction. For example, the interaction may be the transfer of a digital asset from one party to another. For example, the interaction data may include a transaction amount and an unspent transaction output (UTXO). In some embodiments, the interaction data may indicate different entities that are parties to the interaction and the value or information being exchanged. The interaction data may include a value, information associated with the sender (e.g., token or account information, alias, device identifier, contact address, etc.), information associated with the recipient (e.g., token or account information, alias, device identifier, contact address, etc.), a one-time value (e.g., a random value, nonce, timestamp, count, etc.), and / or any other suitable information. An example of interaction data may be transaction data.

[0071] The network interface 206 may include an interface that may allow the node 200 to communicate with an external computer such as a client computer. The network interface 206 may enable the node 200 to convey data to another device (e.g., another node) and convey data from another device. Some examples of the network interface 206 may include a modem, a physical network interface (e.g., an Ethernet card or other network interface card (NIC)), a virtual network interface, a communication port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. The wireless protocols enabled by the network interface 206 may include Wi-Fi TM .

[0072] The computer-readable medium 208 may include a plurality of software modules, including a selection module 208A, a reconfiguration module 208B, and a consensus module 208C. The selection module 208A may include code that may cause the processor 204 to perform a selection process during the setup phase, as described below. The reconfiguration module 208B may include code that may cause the processor 204 to perform a reconfiguration process during the adjustment phase, as described below. The consensus module 208C may include code that may cause the processor 204 to perform a consensus process during the consensus phase, as described below.

[0073] The computer-readable medium 208 may include code executable by the processor 204 to implement a method performed by nodes in a computer network including a plurality of nodes, each node having a node identifier, the method including: a) receiving, by the node, node identifiers from other nodes among the plurality of nodes in the computer network; b) determining, by the node, a plurality of node committees in a sampler graph including the plurality of nodes, wherein the node is present in one of the plurality of node committees; c) the node further i) generating a random string; ii) performing a proof-of-work process using the random string and a hash function; iii) if the proof-of-work process produces an acceptable solution, broadcasting the solution to all other nodes among the plurality of nodes, wherein the other nodes verify the solution; and iv) if the other nodes verify the solution, selecting the node to a subcommittee of the node committee, wherein the subcommittee updates the sampler graph; and d) repeating steps b) and c) until a leadership committee is determined.

[0074] The computer-readable medium 208 may also include code executable by the processor 204 to implement a method including the following operations: receiving, by a first node in a first committee in a computer network, a request including a node identifier to cause a second node to join the committee; providing, by the first node in the first committee, a proof-of-work process to the second node; receiving, by the first node in the first committee, a solution to the proof-of-work process from the second node, wherein a plurality of nodes in the first committee verify the solution; generating, by the first node in the first committee, a random string, which is used by the first node to determine a second committee of the second node; introducing, by the first node, the second node to the second committee, wherein the second committee shifts nodes to allow the second node to join the second committee; and communicating, by the first node, information that the second node is in the second committee to other nodes in the computer network.

[0075] The computer-readable medium 208 may also include code executable by the processor 204 to implement a method including the following operations: receiving, by a first node in a committee, an interaction request including interaction data from a client computer; incorporating, by the first node, the interaction data and other interaction data associated with other client computers into a block including the interaction data, wherein the block includes block portions; broadcasting, by the first node, the block to other nodes in the committee, wherein the other nodes in the committee verify the block; and incorporating the block into a shard of a blockchain managed by the committee.

[0076] Overview

[0077] Most decentralized cryptocurrencies rely on consensus protocols: allowing a group of mutually untrusted participants to agree on a public ledger of transactions called the blockchain. Different from traditional consensus mechanisms, blockchain consensus often occurs in peer-to-peer networks with an open number of members, where new participants whose identities have not been established can join the system during the execution of the protocol. The said setting introduces new fundamental challenges, such as handling Sybil attacks and node churn while providing scalability, which have only recently been studied in the area of Byzantine consensus protocols. Unfortunately, the known techniques still cannot address these challenges because of poor trusted assumptions, scalability, and load balancing, as well as high latency, thus making them unimplementable and / or insecure for large-scale transaction processing.

[0078] Embodiments of the present invention include a Byzantine consensus protocol for a public blockchain, which can improve scalability and security limitations in several ways compared to prior work. At a high level, a method according to an embodiment of the present invention can partition a set of nodes (e.g., all nodes in a computer network) into multiple smaller groups of nodes, which are referred to as committees, that can operate in parallel on disjoint blocks of transactions and maintain disjoint blockchains. A blockchain can include data regarding payment transactions. This partitioning of operations and / or data among multiple groups of nodes can be referred to as sharding [James C. Corbett, Jeffrey Dean, Michael Epstein, Andrew Fikes, Christopher Frost, J.J. Furman, Sanjay Ghemawat, Andrey Gubarev, Christopher Heiser, Peter Hochschild, Wilson Hsieh, Sebastian Kanthak, Eugene Kogan, Hongyi Li, Alexander Lloyd, Sergey Melnik, David Mwaura, David Nagle, Sean Quinlan, Rajesh Rao, Lindsay Rolig, Yasushi Saito, Michal Szymaniak, Christopher Taylor, Ruth Wang, and Dale Woodford, Spanner: Google's Globally Distributed Database, pages 251 to 264, 2012], and has recently been studied in the context of blockchain protocols [Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena, Secure Sharding Protocols for Open Blockchains. In the Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pages 17 to 30, New York, NY, USA, 2016, ACM; and Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford, OmniLedger: Secure, Scalable, Decentralized Ledger via Sharding, Cryptology ePrint Archive, Report 2017 / 406, 2017. https: / / eprint.iacr.org / 2017 / 406].By implementing parallelization of consensus work and storage, shard - based consensus can scale the throughput of the system proportionally to the number of committees, unlike the basic Nakamoto consensus.

[0079] The method according to an embodiment of the present invention can provide a scalable consensus protocol for a public blockchain, which can start adapting to Byzantine faults from a fraction close to 1 / 3 of the nodes and can allow each node to exchange a sub - linear amount of information (counting by the number of participants). Different from previous work, the method according to an embodiment of the present invention may not rely on public key infrastructure, trusted setup, or initial public randomness. In addition, these methods allow new participants to join or leave the protocol without delaying the execution of the protocol. The method according to an embodiment of the present invention can implement a blockchain protocol, which can shard the communication and storage overhead of the blockchain among a small committee of nodes without any trusted setup, such that each node can exchange a sub - linear amount of information. The method according to an embodiment of the present invention can be practical and, different from most cryptocurrencies, can scale the throughput by adding more resources (i.e., nodes) to the system.

[0080] The method according to an embodiment of the present invention can provide the following advantages: sub - linear consensus, decentralized bootstrapping, secure reconfiguration, efficient cross - shard transactions, storage scalability, and efficient atomic broadcast.

[0081] The method according to an embodiment of the present invention can provide a shard - based blockchain protocol, where each node can propagate messages to a sub - linear number of other nodes during a consensus round (i.e., sub - linear communication). In contrast, all previous work has required at least a constant fraction of the network (e.g., 90% [Kyle Croman, Christian Decker, Ittay Eyal, Adem Efe Gencer, Ari Juels, Ahmed Kosba, Andrew Miller, Prateek Saxena, Elaine Shi, Emin Gun Sirer, Dawn Song, and Roger Wattenhofer, On Scaling Decentralized Blockchains, pages 106 - 125, Springer Verlag, Berlin Heidelberg, 2016]) to receive each propagated message. This ultimately results in a super - linear number of messages in terms of the number of participants, which are exchanged in the network by those protocols (see Table 1 below).

[0082] Embodiments of the present invention may provide a shard - based blockchain protocol that has greater resilience than prior systems and methods, can tolerate up to one - third (instead of one - fourth) of its nodes being compromised, while exceeding the throughput and latency of the previous work [Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena, Secure Sharding Protocols for Open - Blockchain. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pages 17 - 30, New York, NY, USA, 2016, ACM; and Eleftherios Kokoris - Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford, OmniLedger: A Secure, Scalable, Decentralized Ledger via Sharding, Cryptology ePrint Archive, Report 2017 / 406, 2017. https: / / eprint.iacr.org / 2017 / 406].

[0083] Next, decentralized bootstrapping will be discussed. The method according to an embodiment of the present invention may operate in a permissionless setting allowing an open membership count, but different from the most prior work [Rafael Pass and Elaine Shi, Hybrid Consensus: Efficient Consensus in Permissionless Models, Cryptology ePrint Archive, Report 2016 / 917, 2016. http: / / eprint.iacr.org / 2016 / 917; Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena, Secure Sharding Protocols for Open Blockchains. In the proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pages 17 to 30, New York, NY, USA, 2016, ACM; and Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford, OmniLedger: A Secure, Scalable, Decentralized Ledger via Sharding, Cryptology ePrint Archive, Report 2017 / 406, 2017. https: / / eprint.iacr.org / 2017 / 406; and Ittai Abraham, Dahlia Malkhi, Kartik Nayak, Ling Ren, and Alexander Spiegelman, Solida: A Blockchain Protocol Based on Reconfigurable Byzantine Consensus. In the proceedings of the 21st International Conference on Principles of Distributed Systems, OPODIS'17, Lisbon, Portugal, 2017], embodiments may not assume the existence of an initial common randomness, typically in the form of a common genesis block. Creation of such a block is usually ignored or only assumed to be done using a distributed random generation protocol, such as [Christian Cachin, Klaus Kursawe, Frank Petzold, and Victor Shoup, Secure and Efficient Asynchronous Broadcast Protocols. In Advances in Cryptology - CRYPTO 2001 edited by Joe Kilian, pages 524 to 541, Berlin Heidelberg, 2001, Springer-Verlag; and E. Syta, P. Jovanovic, E. K. Kogias, N. Gailly, L. Gasser, I. Khoffi, M. J. Fischer, and B. Ford, Scalable Bias-Resistant Distributed Randomness. In the 2017 IEEE Symposium on Security and Privacy (SP), pages 444 to 460, May 2017].Unfortunately, all of these protocols require the exchange of Ω(n. 2 ) messages. In contrast, the method according to an embodiment of the present invention may employ a setup protocol, which may allow reaching an agreement on a set of mostly honest committees with only the exchange of O(m·n) messages without assuming any initial randomness (see Table 1 below). O may be a strict upper bound based on the growth of the algorithm. Ω may be a strict lower bound based on the growth of the algorithm.

[0084] Next, the fast committee consensus will be discussed. Compared with previous solutions, embodiments of the present invention can reduce the communication overhead and latency of the larger chunks of P2P consensus disseminated among the members of each committee by 3 to 10 times [Ittai Abraham, Dahlia Malkhi, Kartik Nayak, Ling Ren, and Alexander Spiegelman, 2017, Solida: A Blockchain Protocol Based on Reconfigurable Byzantine Consensus. In Proceedings of the 21st International Conference on Principles of Distributed Systems (OPODIS'17), Lisbon, Portugal; and Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, and Nickolai Zeldovich, 2017, Algorand: Scaling Byzantine Agreements for Cryptocurrencies. In Proceedings of the 26th Symposium on Operating System Principles (SOSP'17), ACM, New York, NY, USA, 51 to 68. https: / / doi.org / 10.1145 / 3132747.3132757; Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford, OmniLedger: A Secure, Scalable-out, Decentralized Ledger via Sharding, Cryptology ePrint Archive, Report 2017 / 406 (2017). https: / / eprint.iacr.org / 2017 / 406; and Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena, 2016, Secure Sharding Protocols for Open Blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security (CCS'16), ACM, New York, NY, USA, 17 to 30.https: / / doi.org / 10.1145 / 2976749.2978389; and Noga Alon, Haim Kaplan, Michael Krivelevich, Dahlia Malkhi, and J.P. Stern, 2004, Appendix for Scalable Secure Storage in the Presence of Half Failures of the System, Information and Computation (2004); and Ling Ren, Kartik Nayak, Ittai Abraham, and Srinivas Devadas, 2017, Practical Synchronous Byzantine Consensus, CoRR abs / 1704.02397 (2017). http: / / arxiv.org / abs / 1704.02397].

[0085] Next, secure reconfiguration can be discussed. The method according to an embodiment of the present invention can be extended based on the Cuckoo rule [Baruch Awerbuch and Christian Scheideler, Towards Scalable and Robust DHTs. In Proceedings of the 18th Annual ACM Symposium on Parallelism in Algorithms and Architectures, SPAA'06, pages 318 - 327, New York, NY, USA, 2006, ACM; and S. Sen and M.J. Freedman, Commensal Cuckoo: Secure Group Partitioning for Large Services, ACM SIGOPS Operating Systems Review, 46(1):33 - 39, 2012] to prevent join / leave attacks during node changes; a property missing in previous shard - based protocols [Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena, Secure Sharding Protocols for Open Blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pages 17 - 30, New York, NY, USA, 2016, ACM; and Eleftherios Kokoris - Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford, OmniLedger: Secure, Scalable, Decentralized Ledger via Sharding, Cryptology ePrint Archive, Report 2017 / 406, 2017. https: / / eprint.iacr.org / 2017 / 406]. The method according to an embodiment of the present invention can also allow new nodes to join the computer network in a seamless manner without any interruption or delay in the execution of the protocol.

[0086] Next, cross-shard verification can be discussed. To verify cross-committee transactions, the method according to an embodiment of the present invention may allow committees to discover each other through an efficient routing mechanism inspired by Kademlia [Petar Maymounkov and David Mazieres, Kademlia: A Peer-to-Peer Information System Based on the XOR Metric. In Revised Papers from the First International Workshop on Peer-to-Peer Systems, IPTPS'01, pages 53-65, London, UK, 2002, Springer-Verlag, Germany], which may incur logarithmic (in the number of committees) latency and storage. Unfortunately, committee discovery in existing solutions [Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena, Secure Sharding Protocols for Open Blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pages 17-30, New York, NY, USA, 2016, ACM; and Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford, OmniLedger: Secure, Scalable, Decentralized Ledger via Sharding, Cryptology ePrint Archive, Report 2017 / 406, 2017. https: / / eprint.iacr.org / 2017 / 406] requires several "broadcast to all" calls.

[0087] Embodiments of the present invention provide techniques for blockchain partitioning such that each node can store 1 / k fraction of the entire blockchain. Compared to a related method recently proposed by Kokoris-Kogias [Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford, OmniLedger: Secure, Scalable, Decentralized Ledger via Sharding, Cryptology ePrint Archive, Report 2017 / 406, 2017. https: / / eprint.iacr.org / 2017 / 406], the method according to an embodiment of the present invention allows one (instead of two) transactions, thus enabling cross-shard transactions to be committed atomically.

[0088] The method according to an embodiment of the present invention is based on the extension of the atomic broadcast protocol of Cachin and Tessaro [Christian Cachin and Stefano Tessaro, Asynchronous Verifiable Information Dissemination. In the Proceedings of the 19th International Conference on Distributed Computing, DISC'05, pages 503 - 504, Berlin Heidelberg, 2005, Springer-Verlag, Germany] to reduce the communication overhead of broadcasting large chunks of transactions within each committee. This can achieve higher throughput per committee as well as a larger committee size, resulting in a lower probability of failure compared to previous solutions [Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena, Secure Sharding Protocols for Open Blockchains. In the Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pages 17 - 30, New York, NY, USA, 2016, ACM; and Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, and Nickolai Zeldovich, Algorand: Scaling Byzantine Agreements for Cryptocurrencies. In the Proceedings of the 26th Symposium on Operating Systems Principles, SOSP'17, pages 51 - 68, New York, NY, USA, 2017, ACM; and Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford, OmniLedger: A Secure, Scalable, Decentralized Ledger via Sharding, Cryptology ePrint Archive, Report 2017 / 406, 2017. https: / / eprint.iacr.org / 2017 / 406].

[0089] Embodiments of the present invention can be empirically evaluated, showing that these methods scale well with the network size of approximately cryptocurrencies. The methods according to embodiments of the present invention can also seamlessly handle changes without delaying the consensus protocol, and nodes can take approximately 185 seconds (or less) to join the computer network.

[0090]

[0091]

[0092] Table 1

[0093] Table 1 above shows the complexity of known shard - based blockchain protocols. These columns indicate the total message complexity, except for the last column which shows a constant number of consensus on data blocks, where the consensus complexity is per data block of transactions. n can be the number of participants, m << n can be the size of each committee, and |B| can be the size of the blockchain. For the protocols described herein, a constant number of shards and messages of constant size can be assumed. "Bootstrapping" refers to the initial bootstrapping of the system to create initial common randomness.

[0094] Consider a peer - to - peer network with n nodes that have established identities (i.e., public / private keys) through a Sybil - resistant identity generation mechanism, e.g., [Marcin AndRychowicz and Stefan Dziembowski, PoW - based Distributed Cryptography without Trusted Setup, pp. 379 - 399, Springer - Verlag Berlin Heidelberg, Germany, 2015], where each node can solve a computational puzzle regarding the locally generated identity (i.e., public key) of the node, which can be verified by all other (honest) nodes without assuming a trusted randomization beacon. In a computer network comprising n nodes, a method according to an embodiment of the present invention can create k = n / m committees, each of size m = c log n nodes, where c can be a constant depending on the security parameter.

[0095]

[0096] Table 2

[0097] Table 2 above shows a high - level comparison between the results of the method according to an embodiment of the present invention and shard - based protocols.

[0098] In Table 2, there can be 500 B / tx (bytes per transaction), a one - day long period, a 100 - ms network latency for all links, and a 20 - Mbps bandwidth for all nodes in the three protocols. The selection of 1600 and 1800 nodes for [Elastico] and [OmniLedger] respectively is based on the maximum network sizes reported in these works. The failure time of the Elastico protocol decreases rapidly for larger network sizes. For OmniLedger, it can be expected that a larger network size will at most only slightly increase the throughput due to the need for a larger committee size. The latency numbers reported in Table 2 refer to the data block (or transaction) confirmation time, which is the latency from the time the data block creator proposes the data block to the network until the network confirms it as a valid transaction.

[0099] The method according to an embodiment of the present invention can be carried out within a fixed time period called an epoch. Figure 3 A flowchart showing the stages according to an embodiment of the present invention is shown. Figure 3It includes a setup phase 302, an adjustment phase 304, and a consensus phase 306. An epoch 308 can include the adjustment phase 304 and the consensus phase 306. Each epoch 308 can include at least one round 310.

[0100] The setup phase 302 can be a phase of setting up the system. Nodes can execute the setup phase 302 using the selection module 208A. The adjustment phase 304 can be a phase that allows new nodes to join the system. Nodes can execute the adjustment phase 304 using the reconfiguration module 208B. The consensus phase 306 can be a phase that allows a committee of a computer network to verify interactions and store the interactions into blocks in a blockchain. Nodes can execute the consensus phase using the consensus module 208C.

[0101] The epoch 308 can be repeated any suitable number of times. In some embodiments, the length of the epoch 308 can be the length of the adjustment phase 304 and the consensus phase 306. A round 310 can be a series of activities or functions within a period of time. For example, a round 310 can be a communication round during which nodes of a computer network can communicate. A round 310 can be associated with any suitable sequence of activities or functions. There can be any suitable number of rounds 310 in a given epoch 308. In some embodiments, the setup phase 302, the adjustment phase 304, and the consensus phase 306 can be sequentially executed by nodes in a computer network.

[0102] The first epoch can be started by a node running a probabilistic committee selection protocol, as described below, which can allow multiple nodes to agree on a committee with m = O(log n) nodes in a constant number of rounds and by exchanging at most a constant number of bits in total. Assuming that t < n / 3 nodes are controlled by a slowly adaptive Byzantine adversary, the committee selection protocol can sample committees from the set of all nodes in such a way that the fraction of malicious nodes in the sampled set is likely to be bounded by 1 / 2 with high probability. The committee, called the leading committee, can generate a new random value (called epoch randomness) at the start of each epoch, which can be used throughout the protocol to: (1) select a set of committees during the first epoch, (2) allow new nodes to join the system, and (3) reorganize the existing committee after one or more participants (e.g., nodes) join / leave to avoid adversarial reception.

[0103] Once the leading committee is formed (i.e., after the setup phase 302), each node in the leading committee can establish a P2P network with other nodes in the leading committee and can participate in the distributed random generation protocol described below to agree on the randomness r 0 of the first epoch, which can be distributed by the nodes in the leading committee to all nodes in the computer network. Next, the participants can use r 0Obtain a view of a new set of committees locally, where each new committee has m nodes, and at most 1 / 2 of the nodes in each committee are malicious with high probability. Nodes assigned to the same committee can discover each other through a peer discovery algorithm and can then participate together with other nodes in the same committee in multiple runs of a Byzantine consensus protocol to construct and generate a blockchain stored by multiple nodes associated with the committee. Based on a synchronous consensus algorithm recently proposed by Ren et al. [Ling Ren, Kartik Nayak, Ittai Abraham, and Srinivas Devadas, Practical Synchronous Byzantine Consensus, CoRR, abs / 1704.02397, 2017], driven by a list of leaders randomly selected using epoch randomness, embodiments of the present invention can allow for efficient in-committee consensus with an optimal resilience of t < n / 2.

[0104] In the method according to an embodiment of the present invention, consensus decisions can be made on transaction blocks submitted to a committee by an external user (i.e., a client computer) or on the periodic reconfiguration of the committee in adjustment phase 304. These events can be marked by a fixed time interval called an epoch and can respond to a slowly adapting adversary to allow the computer network to reorganize the committee [Rafael Pass and Elaine Shi, Hybrid Consensus: Efficient Consensus in Permissionless Models, Cryptology ePrint Archive, Report 2016 / 917, 2016. http: / / eprint.iacr.org / 2016 / 917]. Such an adversary may corrupt new nodes (i.e., take over the committee) at the end of an epoch (i.e., the set of committees can be fixed during each epoch). Unfortunately, repeating the entire committee selection protocol to reconfigure the committee in response to nodes joining and leaving the computer network less frequently may impose a huge overhead on the computer network. Therefore, at the end of each epoch, embodiments of the present invention can implement the lowest-cost reconfiguration protocol based on the Cuckoo rule [Baruch Awerbuch and Christian Scheideler, Towards Scalable and Robust DHTs. In Proceedings of the 18th Annual ACM Symposium on Parallelism in Algorithms and Architectures, SPAA'06, pages 318 - 327, New York, NY, USA, 2006, ACM; and S. Sen and M. J. Freedman, Commensal Cuckoo: Secure Group Partitioning for Large Services, ACM SIGOPS Operating Systems Review, 46(1):33 - 39, 2012], which can move a constant number of nodes between committees while provably guaranteeing security against join / leave attacks.

[0105] During the reconfiguration protocol, occurring at the end of the i-th epoch, each committee can generate a new randomness r i +1 for the next epoch. The new randomness can not only allow the protocol to move a certain number of nodes among committees in an unpredictable manner, thus hindering malicious reception, but also allow the creation of new computational puzzles (i.e., proof-of-work) for new nodes that request to join at the end of the next epoch (i.e., epoch i+1). If the new puzzles can be solved before the next reconfiguration event, such new nodes can be permitted to enter the system. Otherwise, it must solve another new puzzle, and the fastest of these puzzles can be revealed at the end of the next epoch.

[0106] Before a committee can add a block of transaction data to the blockchain, the committee can verify the validity of each transaction in the block. This may occur during consensus phase 306. In the cryptocurrency model, such verification typically depends on other transactions that record some previously unspent assets spent by the new transaction. Since embodiments of the present invention can shard the main blockchain into multiple unconnected blockchains, each stored by a different committee, the "verifying committee" can communicate with the "source committee" to ensure the existence of the relevant transaction in the blockchain of the source committee. Based on the idea from Kademlia [Petar Maymounkov and David Mazieres, Kademlia: A Peer-to-Peer Information System Based on the XOR Metric. In Revised Papers from the First International Workshop on Peer-to-Peer Systems, IPTPS'01, pages 53 to 65, London, UK, 2002, Springer-Verlag, Germany], the verifying committee can communicate with a logarithmic number of other committees to find the committee storing the relevant transaction.

[0107] Embodiments of the present invention can overcome the committee size limitations of the efficiency from the practical Byzantine Fault Tolerance (PBFT) protocol by adopting a more efficient consensus protocol, which was developed in [Andrew Miller, Yu Xia, Kyle Croman, Elaine Shi, and Dawn Song, Honey Badger of BFT Protocols. In the proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pages 31 to 42, New York, NY, USA, 2016, ACM]. This protocol can use the atomic broadcast protocol [Gabriel Bracha and Sam Toueg, Asynchronous consensus and broadcast protocols, Journal of the ACM (JACM), 32(4): 824 to 840, 1985] to improve embodiments of the present invention to reduce the communication cost of sending large messages in a synchronous communication model. Thus, embodiments of the present invention can handle a committee size of hundreds of nodes (e.g., 400 nodes). Since the committee can have a dynamic number of members, an efficient routing protocol based on the Kademlia algorithm [Petar Maymounkov and David Mazieres, Kademlia: A Peer-to-Peer Information System Based on the XOR Metric. In the revised papers of the First International Workshop on Peer-to-Peer Systems, IPTPS'01, pages 53 to 65, London, UK, 2002, Springer-Verlag, Germany], which enables fast committee discovery and communication, can be used in embodiments of the present invention. Embodiments of the present invention can avoid the requirement that each node must store the entire blockchain by introducing a new sharding protocol, which can allow the committee to partition transactions in the ledger and distribute them for storage in different committees.

[0108] Embodiments of the present invention may use the consensus protocol of Ren et al. [Ling Ren, Kartik Nayak, Ittai Abraham, and Srinivas Devadas, Practical Synchronous Byzantine Consensus, CoRR, abs / 1704.02397, 2017] to achieve optimal resilience of 1 / 2 in the committee, and thus allow for a smaller committee size with a higher overall resilience of 1 / 3 (compared to prior work [Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena, Secure Sharding Protocols for Open Blockchains. In the proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pp. 17–30, New York, NY, USA, 2016, ACM; and Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford, OmniLedger: A Secure, Scalable, Decentralized Ledger via Sharding, Cryptology ePrint Archive, Report 2017 / 406, 2017. https: / / eprint.iacr.org / 2017 / 406.]). Different from asynchronous protocols such as PBFT [Miguel Castro and Barbara Liskov, Practical Byzantine Fault Tolerance. In the proceedings of the Third Symposium on Operating Systems Design and Implementation, OSDI'99, pp. 173–186, 1999], the protocol of Ren et al., and most other synchronous protocols such as [Jonathan Katz and Chiu-Yuen Koo, An Expectant Constant-Round Protocol for Byzantine Agreement. In Advances in Cryptology - CRYPTO 2006, Lecture Notes in Computer Science Vol. 4117, pp. 445–462, Springer-Verlag, Berlin, Germany, 2006] do not respond to [Rafael Pass and Elaine Shi, Hybrid Consensus: Efficient Consensus in Permissionless Models, Cryptology ePrint Archive, Report 2016 / 917, 2016. http: / / eprint.iacr.org / 2016 / 917], which means that it propagates messages at a fixed rate, typically denoted by Δ, and thus its speed can be independent of the actual latency of the network.

[0109] While most committee-based protocols (e.g., [Ittai Abraham, Dahlia Malkhi, Kartik Nayak, Ling Ren, and Alexander Spiegelman, Solida: A Blockchain Protocol Based on Reconfigurable Byzantine Consensus. In Proceedings of the 21st International Conference on Principles of Distributed Systems, OPODIS'17, Lisbon, Portugal, 2017.]) select PBFT via a synchronous protocol for responsiveness, this typically results in a large cost, which usually leads to significantly worse throughput and latency, thus hindering responsiveness. Since asynchronous consensus requires t < n / 3, it is necessary to assume a total resilience of approximately 1 / 5 or less to achieve a similar committee size and failure probability when sampling committees at a 1 / 3 resilience. Unfortunately, increasing the total resilience (e.g., increasing to 1 / 4) can significantly increase the committee size (e.g., becoming 3 to 4 times larger), making the consensus within the committee very inefficient.

[0110] Embodiments of the present invention can run pre-scheduled consensus rounds among committee members weekly or any other suitable time length to reach an agreement on a new Δ, so that the computer network can adjust the consensus speed under the latest average latency of the computer network. Although this does not completely solve the responsiveness problem, it can make the protocol responsive to long-term and more stable network changes as technology advances.

[0111] Another challenge with using synchronous consensus protocols can occur in the cross-shard transaction scenario, where a malicious leader can deceive the source committee with a transaction that has been accepted by some but not all honest members in the verified committee. This can happen because, unlike asynchronous consensus protocols such as PBFT [Miguel Castro and Barbara Liskov, Practical Byzantine Fault Tolerance. In Proceedings of the Third Symposium on Operating System Design and Implementation, OSDI'99, pages 173 - 186, 1999], which proceed in an event-driven manner, synchronous consensus protocols proceed in the form of fixed rounds, and thus, some honest nodes can terminate before other nodes with a "safe value" that still need to be accepted by all honest nodes in future iterations before the transaction can be considered "committed" to the blockchain.

[0112] Consensus Technology

[0113] Due to the large amount of research on Byzantine consensus, two categories of such protocols are reviewed in this section: committee-based and shard-based consensus protocols. See also [Shehar Bano, Alberto Sonnino, Mustafa Al-Bassam, Sarah Azouvi, Patrick McCorry, Sarah Meiklejohn, and George Danezis, Consensus in the Blockchain Age, CoRR, abs / 1711.03936, 2017] for a complete survey of previous blockchain consensus protocols.

[0114] Commitment-based Consensus

[0115] Bracha [G Bracha, Byzantine Generals Protocol with o(log n) Expected Rounds of Randomness. In Proceedings of the 17th Annual ACM Symposium on Theory of Computing, STOC'85, pages 316–326, New York, NY, USA, 1985, ACM.] described a consensus protocol that reduces the round complexity of Byzantine protocols, which was later improved in [Rafail Ostrovsky, Sridhar Rajagopalan, and Umesh Vazirani, Simple and Efficient Leader Election in the Full Information Model, 1994; and Alexander Russell and David Zuckerman, Selecting a Perfect Information Leader in log*N + o(1) Rounds. In Proceedings of the 39th Annual Symposium on Foundations of Computer Science, FOCS'98, page 576–, Washington, DC, USA, 1998, IEEE Computer Society]. The idea of using committees to scale the communication and computational overhead of Byzantine protocols dates back to the work of King et al. [Valerie King, Jared Saia, Vishal Sanwalani, and Erik Vee, Scalable Leader Election. In Proceedings of the 17th Annual ACM-SIAM Symposium on Discrete Algorithms, SODA'06, pages 990–999, Philadelphia, PA, USA, 2006] and their subsequent work [Valerie King and Jared Saia, Breaking the o(n^2) Bit Barrier: Scalable Byzantine Protocols against Adaptive Adversaries. In Proceedings of the 29th ACM SIGACT-SIGOPS Symposium on Principles of Distributed Computing, PODC'10, pages 420–429, New York, NY, USA, 2010, ACM], which allows Byzantine protocols in fully connected networks with only sub-linear per-party overhead relative to the number of participants. Unfortunately, both protocols only provide theoretical results and cannot be directly used in the public blockchain setting (i.e., open membership peer-to-peer networks).

[0116] Decker et al. proposed a committee-based consensus protocol, called PeerCensus, in the public blockchain model (i.e., open membership peer-to-peer network). They proposed using PBFT [Miguel Castro and Barbara Liskov, Practical Byzantine Fault Tolerance. In Proceedings of the Third Symposium on Operating Systems Design and Implementation, OSDI'99, pages 173 to 186, 1999] within the committee to approve transactions. However, PeerCensus did not explicitly mention how to form and maintain the committee to ensure the honesty of the majority in the committee throughout the protocol. Hybrid consensus [Rafael Pass and Elaine Shi, Hybrid Consensus: Efficient Consensus in Permissionless Models, Cryptology ePrint Archive, Report 2016 / 917, 2016. http: / / eprint.iacr.org / 2016 / 917] proposed periodically selecting a committee that runs a Byzantine consensus protocol, which assumes a mildly adaptive adversary that may corrupt only honest nodes during certain time periods. ByzCoin proposed using a multi-signature protocol within the committee to improve transaction throughput. However, the specification of ByzCoin is incomplete, and the known protocol has serious vulnerabilities to Byzantine faults [Rafael Pass and Elaine Shi, Hybrid Consensus: Efficient Consensus in Permissionless Models, Cryptology ePrint Archive, Report 2016 / 917, 2016. http: / / eprint.iacr.org / 2016 / 917; and Ittai Abraham, Dahlia Malkhi, Kartik Nayak, Ling Ren, and Alexander Spiegelman, Solida: A Blockchain Protocol Based on Reconfigurable Byzantine Consensus. In Proceedings of the 21st International Conference on Principles of Distributed Systems, OPODIS'17, Lisbon, Portugal, 2017; and Shehar Bano, Alberto Sonnino, Mustafa Al-Bassam, Sarah Azouvi, Patrick McCorry, Sarah Meiklejohn, and George Danezis, Consensus in the Age of Blockchains, CoRR, abs / 1711.03936, 2017].

[0117] Algorand [Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, and Nickolai Zeldovich, Algorand: Scaling Byzantine Agreements for Cryptocurrencies. In Proceedings of the 26th Symposium on Operating Systems Principles, SOSP'17, pages 51–68, New York, NY, USA, 2017, ACM.] proposed a committee-based consensus protocol called BA*, which uses a Verifiable Random Function (VRF) [Silvio Micali, Salil Vadhan, and Michael Rabin, Verifiable Random Functions. In Proceedings of the 40th Annual Symposium on Foundations of Computer Science, FOCS'99, pages 120–, Washington, DC, USA, 1999, IEEE Computer Society] to randomly select committee members weighted by account balances in a private and non-interactive way. Thus, an adversary does not know which nodes are targeted until it participates in the BA* protocol with other committee members. Algorand replaces committee members with new members at each step of BA* to avoid targeted attacks on committee members by fully adaptive adversaries. However, the randomness used in each VRF call (i.e., the VRF seed) can be biased by an adversary; the protocol proposes a backtracking mechanism to ensure strongly synchronous and thus unbiased seeds, which leads to a problematic situation called the "nothing at stake" problem.

[0118] The trusted genesis block Solida [Ittai Abraham, Dahlia Malkhi, Kartik Nayak, Ling Ren, and Alexander Spiegelman, Solida: A Blockchain Protocol Based on Reconfigurable Byzantine Consensus. In Proceedings of the 21st International Conference on Principles of Distributed Systems, OPODIS'17, Lisbon, Portugal, 2017] uses its solution to the proof-of-work process to select nodes into the committee, which is revealed by 2t + 1 committee member signatures in each round to avoid precomputation and withholding attacks. To fill each slot in the ledger, a reconfigurable Byzantine consensus protocol is used, where consensus decisions are made on a batch of transactions or reconfiguration events. The latter records changes in the number of members in the committee and allows up to one member to be replaced in each event by ranking candidates by its proof-of-work solution. The protocol allows the winning candidate to lead the reconfiguration consensus, avoiding internal malicious leaders from deliberately delaying reconfiguration events to buy time for other malicious nodes in the proof-of-work process.

[0119] Sharding-based Consensus

[0120] Unlike the above cryptocurrencies, a shard - based blockchain consensus protocol can increase its transaction - processing power and the number of participants joining the network by allowing multiple node committees to process incoming transactions in parallel. Thus, the total number of transactions processed in each consensus round of the entire protocol is multiplied by the number of committees. Although there are multiple works on shard - based blockchain protocols, such as [Timo Hanke, Dfinity White Paper: Our Consensus Algorithm. https: / / medium.com / dfinity / dfinity - white - paper - our - consensus - algorithm - a11adc0a054c, 2018; and Zilliqa Team, Zilliqa Technical White Paper. https: / / docs.zilliqa.com / whitepaper.pdf, August 2017; and Hsiao - Wei Wang, Ethereum Sharding: Overview and Finality. https: / / medium.com / @icebearhww / ethereum - sharding - and - finality - 65248951F649, 2017], this review focuses on the results of handling shards in the cryptocurrency transaction model known as the UTXO model.

[0121] Elastico

[0122] Luu et al. [Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena, Secure Sharding Protocols for Open Blockchains. In the proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pages 17 - 30, New York, NY, USA, 2016, ACM.] proposed Elastico, a shard - based consensus protocol for public blockchains. In each consensus epoch, each participant solves a proof - of - work based on the epoch randomness obtained from the last state of the blockchain. The least - significant bit of the PoW is used to determine the committees that coordinate with each other to process transactions.

[0123] While Elastico can improve the throughput and latency of the above cryptocurrencies by several orders of magnitude, it still has several drawbacks: (1) Elastico requires all parties to re-establish their identities (i.e., solve PoW) and re-create all committees in "each" epoch. Besides the relatively large communication overhead, this also causes significant latency that scales linearly with the network size because the protocol takes more time to solve the sufficient proof-of-work processes to meet the needs of all committees. (2) In practice, Elastico requires a small committee size, around 100 parties, to limit the overhead of running PBFT in each committee. Unfortunately, this greatly increases the failure probability of the protocol, and using a simple analysis method (see [Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford, OmniLedger: A Secure, Scalable, Decentralized Ledger via Sharding, Cryptology ePrint Archive, Report 2017 / 406, 2017. https: / / eprint.iacr.org / 2017 / 406.]), this probability can be as high as 0.97 after only six epochs, making the protocol practically completely insecure.

[0124] The randomness used in each epoch of Elastico can be biased by adversaries and thus can harm the committee selection process and even allow malicious nodes to pre-compute the proof-of-work processes; Elastico requires a trusted setup to generate the initial common randomness that is revealed to all parties simultaneously. (5) While Elastico allows each party to verify only a subset of transactions, all data blocks still have to be broadcast to all parties and each party is required to store the entire ledger. (6) Finally, in the case of a high failure probability, Elastico can tolerate at most 1 / 4 fraction of faulty parties. Elastico needs to combine this low resilience in order to achieve a practical committee size.

[0125] OmniLedger

[0126] In recent work, Kokoris-Kogias et al. [Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford, OmniLedger: A Secure, Scalable-out, Decentralized Ledger via Sharding, Cryptology ePrint Archive, Report 2017 / 406, 2017. https: / / eprint.iacr.org / 2017 / 406] proposed OmniLedger, a sharding-based distributed ledger protocol that attempts to address some of the problems of Elastico. Assuming a slow-adaptive adversary can corrupt up to 1 / 4 fraction of the nodes at the start of each epoch, the OmniLedger protocol runs a global reconfiguration protocol at the start of each epoch, approximately once per day, to allow new participants to join the protocol. The protocol uses a slow identity blockchain protocol that assumes a synchronous channel to generate identities and assign participants to committees. In each epoch, for unpredictable leader selection, a bias-resistant random generation protocol that relies on a verifiable random function (VRF) [Silvio Micali, Salil Vadhan, and Michael Rabin, Verifiable Random Functions. In Proceedings of the 40th Annual Symposium on Foundations of Computer Science, FOCS'99, pages 120 -, Washington, DC, USA, 1999, IEEE Computer Society] is used to generate randomness in a way similar to the lottery algorithm of Algorand [Silvio Micali, ALGORAND: An Efficient and Democratic Ledger, CoRR, abs / 1607.01341, 2016]. The consensus protocol assumes a partially synchronous channel and uses a variant of ByzCoin to reach consensus, where randomness is further used to divide the committees into smaller groups. The design of ByzCoin is known to have several security / performance issues [Rafael Pass and Elaine Shi, Hybrid Consensus: Efficient Consensus in Permissionless Models, Cryptology ePrint Archive, Report 2016 / 917, 2016. http: / / eprint.iacr.org / 2016 / 917; Ittai Abraham, Dahlia Malkhi, Kartik Nayak, Ling Ren, and Alexander Spiegelman, Solida: A Blockchain Protocol Based on Reconfigurable Byzantine Consensus. In Proceedings of the 21st International Conference on Principles of Distributed Systems, OPODIS'17, Lisbon, Portugal, 2017], especially its return to all-to-all communication in the Byzantine setting.Unfortunately, due to the incomplete and constantly changing specifications of the new scheme, it is not clear how the new scheme used in OmniLedger addresses these issues.

[0127] In addition, several challenges that OmniLedger has not yet addressed are as follows: (1) Similar to Elastico, OmniLedger can only tolerate t < n / 4 corruptions. In fact, when t < n / 8, the protocol can only achieve low latency (e.g., less than 10 seconds); (2) Since each committee needs to propagate several messages to all n nodes for each transaction block, OmniLedger's consensus protocol requires O(n) communications per node; (3) OmniLedger requires a trusted setup to generate an initial unpredictable configuration to determine the VRF as a seed in the first epoch. The trivial algorithm for generating such a common seed requires Ω(n2) bits of communication.

[0128] (4) The OmniLedger network functionality is obvious for clients who should collect proofs of input UTXOs from input shards and provide them to output shards; (5) Due to the active role of clients, OmniLedger is not a good candidate for scaling to perform general computations on the chain. However, they provide some preliminary methods for delegating the client role to shards, which are not fully described in this version and not tested in the results; and (6) OmniLedger is vulnerable to denial-of-service (DoS) attacks by malicious block producers who can lock any transaction that exploits the atomic cross-shard protocol.

[0129] When t < n / 4, OmniLedger can achieve high throughput (e.g., more than 500 tx / second) only when the optimal trusted but verifiable method is used to trade off between throughput and transaction confirmation latency. In this method, a set of optimal verifiers process transactions to quickly provide temporary commitments, which are later verified by a set of core verifiers. Although this method seems useful for special scenarios, such as micropayments that quickly process low-risk small transactions, it can be considered a high-risk method for regular payments, especially due to the lack of a financial liability mechanism in today's decentralized systems. However, any blockchain protocol has a transaction confirmation latency that must be considered in practice to limit transaction risks.

[0130] Synchronous Consensus

[0131] The Byzantine consensus protocol by Castro and Liskov [Miguel Castro and Barbara Liskov, Practical Byzantine Fault Tolerance. In Proceedings of the Third Symposium on Operating Systems Design and Implementation, OSDI'99, pages 173–186, 1999], known as PBFT, can tolerate up to t < n / 3 faulty nodes over an asynchronous communication channel in an authenticated setting (i.e., using digital signatures). While asynchronous Byzantine consensus requires t < n / 3, even with digital signatures [Gabriel Bracha and Sam Toueg, Resilient consensus protocols. In Proceedings of the Second Annual ACM Symposium on Principles of Distributed Computing, PODC'83, pages 12–26, New York, NY, USA, 1983, ACM], synchronous consensus can be solved with digital signatures for t < n / 2. Recently, Ren et al. [Ling Ren, Kartik Nayak, Ittai Abraham, and Srinivas Devadas, Practical Synchronous Byzantine Consensus, CoRR, abs / 1704.02397, 2017] proposed an expected constant-round algorithm for Byzantine consensus in a synchronous, authenticated communication network where up to t < n / 2 nodes may be faulty. While the best previous result, due to Katz and Koo [Jonathan Katz and Chiu-Yuen Koo, An expected constant-round protocol for Byzantine agreement. In Advances in Cryptology - CRYPTO 2006, Lecture Notes in Computer Science Volume 4117, pages 445–462, Springer-Verlag, 2006], was expected to require 24 rounds of communication, the protocol by Ren et al. is expected to require only 8 rounds.

[0132] Ren et al. assume the existence of a random leader selection protocol and then iteratively run with a new unique leader in each iteration. If the leader is honest, consensus in the iteration is guaranteed. Otherwise, a Byzantine leader can prevent progress but cannot violate safety, meaning that some honest nodes may not terminate at the end of the iteration, but all honest nodes that terminate in the iteration can output the same value, called the safe value. If at least one node can show a new leader that decided on the safe value, the new leader proposes the same value in the next iteration. Otherwise, the new leader proposes a new value.

[0133] Information dispersion

[0134] Rabin [Valerie King, Jared Saia, Vishal Sanwalani, and Erik Vee, 2006, Scalable leader election. In Proceedings of the 17th Annual ACM-SIAM Symposium on Discrete Algorithms (SODA'06), Philadelphia, PA, USA, 990–999] introduced the concept of Information Dispersal Algorithms (IDA), which can split a message (or file) into multiple information chunks in such a way that a subset of the chunks will be sufficient to reconstruct the message. This is achieved using erasure codes [Richard E Blahut, 1983, Theory and Practice of Error Control Codes, Vol. 126, Addison-Wesley Reading (MA), et al.], since error-correcting codes (ECC) allow for the specific case where some of the information chunks are missing but unmodified. Krawczyk [Hugo Krawczyk, 1993, Distributed fingerprinting and secure information dispersal. In Proceedings of the 12th Annual ACM Symposium on Principles of Distributed Computing (PODC'93), ACM, New York, NY, USA, 207–218. https: / / doi.org / 10.1145 / 164051.164075] extended this to tolerate corrupted (i.e., changed) information chunks by computing the fingerprint of each information chunk and storing the vector of fingerprints using error-correcting codes. Alon et al. [Noga Alon, Haim Kaplan, Michael Krivelevich, Dahlia Malkhi, and Julien Stern, 2000, Scalable secure storage when half of the system fails. In Proceedings of the 27th International Colloquium on Automata, Languages, and Programming; and Noga Alon, Haim Kaplan, Michael Krivelevich, Dahlia Malkhi, and JP Stern, 2004, Appendix to Scalable Secure Storage When Half of the System Fails, Information and Computation (2004)] described a more efficient IDA mechanism [Ralph C. Merkle, 1988, Digital signatures based on conventional encryption functions. In Advances in Cryptology - CRYPTO '87, Springer-Verlag, London, UK, 369–378. http: / / dl.acm.org / citation.cfm?id=646752.704751] by computing Merkle hash trees over the encoded information chunks in order to verify whether each received information chunk is corrupted.

[0135] Embodiments of the present invention build upon and improve the IDA of Alon et al. [Noga Alon, Haim Kaplan, Michael Krivelevich, Dahlia Malkhi, and J.P. Stern, Appendix for Scalable Secure Storage with Half-Failures of the System, Information and Computation (2004)] and the consensus protocol of Ren et al. [Ling Ren, Kartik Nayak, Ittai Abraham, and Srinivas Devadas, Practical Synchronous Byzantine Consensus, CoRR abs / 1704.02397 (2017). http: / / arxiv.org / abs / 1704.02397] to perform efficient consensus on larger data chunks within each committee. Once the ECC-encoded messages are spread across the network by IDA, the honest nodes can use the protocol of Ren et al. to reach an agreement on the root of the Merkle tree to ensure consistency. The Merkle tree can be a data structure. In some embodiments, the Merkle tree can include leaf nodes and non-leaf nodes, where each leaf node can be labeled with the hash of a data chunk, and each non-leaf node can be labeled with the cryptographic hash of the labels of its children. Using the corresponding authentication path in the Merkle tree sent by the sender, the receiver can verify the integrity of the information chunk and use a decoding mechanism to recover the message, as described in further detail in Section IV.B below.

[0136] Model and Problem Definition

[0137] In this section, the network model and threat model used in embodiments of the present invention can be discussed.

[0138] Network Model

[0139] Consider n nodes in a peer-to-peer network, where there may be a known fixed upper bound Δ on the transmission time for each message. All messages sent in a round can be transmitted by the end of the round, and the order of these messages is not necessarily preserved. In some embodiments, messages can be propagated in the network by rumor [R. Karp, C. Schindelhauer, S. Shenker, and B. Vocking, Randomized rumor spreading. In Proceedings of the 41st Annual Symposium on Foundations of Computer Science, FOCS'00, pages 565–, Washington, DC, USA, 2000, IEEE Computer Society]. This can be a standard synchronous network model in distributed computing and can be adopted by blockchain consensus protocols [Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena, Secure sharding protocols for open blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pages 17–30, New York, NY, USA, 2016, ACM; and Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, and Nickolai Zeldovich, Algorand: Scaling byzantine agreements for cryptocurrencies. In Proceedings of the 26th Symposium on Operating Systems Principles, SOSP'17, pages 51–68, New York, NY, USA, 2017, ACM; and Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford, OmniLedger: A secure, sharded, outward scalable, decentralized ledger, Cryptology ePrint Archive, Report 2017 / 406, 2017. https: / / eprint.iacr.org / 2017 / 406; and Ittai Abraham, Dahlia Malkhi, Kartik Nayak, Ling Ren, and Alexander Spiegelman, Solida: A blockchain protocol based on reconfigurable byzantine consensus. In Proceedings of the 21st International Conference on Principles of Distributed Systems, OPODIS'17, Lisbon, Portugal, 2017], as a practical assumption for the Internet.This model is sometimes referred to as the asynchronous network model in the blockchain literature [Rafael Pass, Lior Seeman, and Abhi Shelat, Analyzing Blockchain Protocols in Asynchronous Networks. In Advances in Cryptology - EUROCRYPT 2017, edited by Jean-Sébastien Coron and Jesper Buus Nielsen, pp. 643 - 673, Cham, 2017, Springer International Publishing], which can be confusing since in traditional asynchronous networks, an adversary can arbitrarily delay messages in the network. This does not happen in synchronous networks. Also, as pointed out by Abraham et al. [Ittai Abraham, Dahlia Malkhi, Kartik Nayak, Ling Ren, and Alexander Spiegelman, Solida: A Blockchain Protocol Based on Reconfigurable Byzantine Consensus. In Proceedings of the 21st International Conference on Principles of Distributed Systems, OPODIS'17, Lisbon, Portugal, 2017], this difference in terminology is likely because the aforementioned cryptocurrency is neither synchronous nor asynchronous in the traditional sense.

[0140] For each Byzantine consensus protocol operating within a committee, embodiments of the present invention can create a local peer-to-peer network among multiple nodes of the committee. In practice, Δ can be conservatively set in seconds in a peer-to-peer network with more than 200 nodes. Thus, similar to [Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford, OmniLedger: Secure, Scalable, Decentralized Ledger via Sharding, Cryptology ePrint Archive, Report 2017 / 406, 2017. https: / / ePrint.iacr.org / 2017 / 406], embodiments of the present invention can use a partially synchronous channel [Miguel Castro and Barbara Liskov, Practical Byzantine Fault Tolerance. In Proceedings of the Third Symposium on Operating Systems Design and Implementation, OSDI'99, pages 173-186, 1999] among the members of each committee in the case of exponentially growing timeouts to minimize latency. Without loss of generality and similar to most hybrid blockchain protocols [Rafael Pass and Elaine Shi, Hybrid Consensus: Efficient Consensus in Permissionless Models, Cryptology ePrint Archive, Report 2016 / 917, 2016. http: / / eprint.iacr.org / 2016 / 917; Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena, Secure Sharding Protocols for Open Blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pages 17-30, New York, NY, USA, 2016, ACM; and Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford, OmniLedger: Secure, Scalable, Decentralized Ledger via Sharding, Cryptology ePrint Archive, Report 2017 / 406, 2017. https: / / ePrint.iacr.org / 2017 / 406], in some embodiments, all participants in the computer network can have equivalent computing resources. In some embodiments, a group of initial nodes can start the protocol simultaneously.

[0141] Threat Model

[0142] Embodiments of the present invention consider a probabilistically polynomial-time Byzantine adversary that can corrupt t < n / 3 nodes at any time. The corrupted nodes are in series with each other and can also deviate from the protocol in any arbitrary way (e.g., by sending invalid or inconsistent messages, remaining silent, etc.). Similar to most committee-based protocols [Rafael Pass and Elaine Shi, Hybrid Consensus: Efficient Consensus in Permissionless Models, Cryptology ePrint Archive, Report 2016 / 917, 2016. http: / / eprint.iacr.org / 2016 / 917; and Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford, OmniLedger: A Secure, Scalable, Decentralized Ledger via Sharding, Cryptology ePrint Archive, Report 2017 / 406, 2017. https: / / eprint.iacr.org / 2017 / 406; and Ittai Abraham, Dahlia Malkhi, Kartik Nayak, Ling Ren, and Alexander Spiegelman, Solida: A Blockchain Protocol Based on Reconfigurable Byzantine Consensus. In Proceedings of the 21st International Conference on Principles of Distributed Systems, OPODIS'17, Lisbon, Portugal, 2017], it is assumed that the adversary can adapt slowly, which means that the adversary can be allowed to choose a set of corrupted nodes at the start of the protocol and / or between each epoch, but cannot change this set of corrupted nodes within an epoch. In some embodiments, a node can be disconnected from the computer network during an epoch or between two epochs for any reason, such as an internal failure or network jitter. However, at any time, at least 2 / 3 fraction of the computing resources can belong to online uncorrupted participants (i.e., respond within the network time bound). Some embodiments of the present invention do not rely on any public key infrastructure or any secure broadcast channel, but can use a random oracle for a collision-resistant hash function. A random oracle can respond to random unique queries. A hash function can be collision-resistant if it is difficult for a malicious party to determine two inputs that hash to the same output.

[0143] Problem Definition

[0144] In some embodiments, the protocol may include a secure chained sharding protocol based on a modified version of the definition of the secure sharding protocol from [Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena, Secure Sharding Protocols for Open Blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pages 17–30, New York, NY, USA, 2016, ACM]. In some embodiments, a set of transactions may be sent to a computer network by a client computer located outside the computer network. This set of transactions may be divided into k non - overlapping blocks. x i，j represents the j - th transaction in the i - th block. In some embodiments, all nodes may have access to an external function f that outputs 0 or 1 given a transaction, indicating whether the transaction is invalid or valid, respectively. The protocol Π outputs a set X that contains k non - overlapping subsets or shards, such that for each j ∈ {1..|X i |}, X i = {x i，j}, such that the following holds:

[0145] Protocol: For each i ∈ {1..k}, at least Ω(log n) nodes can agree on X -λ with high probability of at least 1 - 2 i , where λ may be a security parameter.

[0146] Validity: For each i ∈ {1..k} and j ∈ {1..|X i |}, f(x i，j ) = 1.

[0147] Scalability: k can grow approximately linearly with n.

[0148] Efficiency: The communication and computational complexity of each party can be O(n) and the storage complexity of each party can be O(s).

[0149] Notation and Terminology

[0150] If an event occurs with high probability, the probability that the event may occur is 1 - O(1 / 2 λ ), where λ may be a security parameter. A set of nodes can be a committee. A subset of the committee can be a subcommittee. A node (a party) can become a member of committee C. Other nodes in C can be neighbors of node p in C. In some embodiments, when the committee runs a protocol, all members of the committee can participate in the execution of the protocol. If fewer than 1 / 3 of the nodes in the committee are malicious, the committee can be considered better. Let committee 1C 1 and committee 2C 2 become two good committees. In some embodiments, when committee 1C 1 sends message m to committee 2C 2 , each honest member of committee 1C 1 can send m to each member of committee 2C 2 . Since each member of committee 2C 2 may receive different messages due to malicious behavior, committee 2C 2 can select a message at least 1 / 3 + 1 times. In other embodiments, when committee 1C 1 sends a message to committee 2C 2 , the leader node of committee 1C 1 can receive a message including the digital signatures of each of multiple nodes in committee 1C 1 and can aggregate the messages, and then can transmit the aggregated message to the leader of committee 2C 2 . The leader of committee 2C 2 can transmit the aggregated message to each node in committee 2C 2 , where each node in committee 2C 2 can verify the digital signatures created by multiple nodes in committee 1C 1 .

[0151] Protocol according to an embodiment of the present invention

[0152] In this section, a scalable Byzantine consensus protocol is described. The method according to an embodiment of the present invention can run in three different phases: setup, consensus, and adjustment (see Figure 3 ). The main technical components of the protocol can enable the creation and maintenance of multiple committees, which can have at most 1 / 3 malicious nodes with high probability while allowing node changes. Each committee can store and add transactions to a partition of the blockchain (i.e., a shard of the blockchain).

[0153] Before detailing the different phases according to embodiments of the present invention, a construction for random number generation within a committee, known as Secure Random Generation (GenRand), can be presented. A computer network can include N nodes, where T nodes may be malicious. Nodes can generate l random bits using the following GenRand protocol. The protocol can have two steps: i) commitment and ii) revelation. During the commitment phase, each node p i can generate locally a random value r i and a commitment c i to r i . Each node can broadcast c i reliably to every other node. During the revelation phase, the nodes can broadcast the random value r i reliably to every other node. In some embodiments, the generated random value r i can be hidden from other nodes. The commitment c i can prove the generated node r i , but cannot disclose the value of r i to other nodes.

[0154] After receiving (c i , r i ) from all other nodes, each node can check the validity of the commitment and otherwise set r i to a default value (e.g., 0 of b bits). Then, the node can set its output to H(r 1 ||r 2 ||...||r N ), where H: {0, 1} * →{0, 1} l can be a hash function. H can be modeled as a random oracle, which may result in an output that can be an unbiased l-bit random value. In practice, all honest nodes can send better random values, so 2 / 3 of the inputs to the hash function are randomly selected. For example, malicious nodes may not generate random values and can then input any selected number into the hash function.

[0155] Setup Phase

[0156] The setup phase can start by running a setup protocol, where each node can establish its identity by solving a proof-of-work process to join the system. Then, the nodes can run a committee selection protocol, where the nodes can determine a good committee that can be referred to as the leadership committee. The leadership committee can then generate and distribute a series of random bits, which can be used to establish k good committees {C 1 ,..., C k}. In some embodiments, the setup phase can establish the computer network for the reconfiguration phase and the consensus phase.

[0157] The setup phase can include a method executed by nodes in a computer network including a plurality of nodes, each node having a node identifier. The method includes: a) the node receiving node identifiers from other nodes among the plurality of nodes in the computer network; b) the node determining a plurality of node committees in a sampler graph including the plurality of nodes, wherein the node exists in one of the plurality of node committees; c) the node further i) generating a random string; ii) performing a proof-of-work process using the random string and a hash function; iii) if the proof-of-work process produces an acceptable solution, broadcasting the solution to all other nodes among the plurality of nodes, wherein the other nodes verify the solution; and iv) if the other nodes verify the solution, selecting the node to a sub-committee of the node committee, wherein the sub-committee updates the sampler graph; and d) repeating steps b) and c) until a leadership committee is determined. The setup phase can be described with reference to Protocol 1 below.

[0158] In some embodiments, before running the setup phase, the computer network can run an identity generation protocol among the nodes, introduced by Andrychowicz and Dziembowski in [Marcin AndRychowicz and Stefan Dziembowski, PoW-based Distributed Cryptography without Trusted Setup, pp. 379-399, Springer-Verlag, Berlin Heidelberg, 2015]. This protocol can allow each node to establish a public / private key pair by solving a PoW computational challenge and then sending the public key of the node as its ID to other nodes in the computer network. Nodes in a computer network including a plurality of nodes can receive node identifiers from other nodes among the plurality of nodes in the computer network. In some embodiments, the node identifier can be a public key.

[0159] After each node receives the node identifiers from other nodes, the node can generate a deterministic random graph called a sampler graph. The sampler graph can be created locally by each node based on a predefined seed and the node identifiers known to all nodes in the computer network. The predefined seed can be a number or vector known to all nodes in the computer network. In some embodiments, the predefined seed can be used to initialize a pseudo-random number generator.

[0160] A sampler graph can allow nodes to sample multiple committees such that the distribution of malicious nodes within most committees can be within a δ fraction of the number of malicious nodes in the initial set that includes all nodes. For example, if there are 300 malicious nodes in a computer network of 1000 nodes, the fraction of malicious nodes is 3 / 10. Thus, a committee determined based on the sampler graph may have a fraction of malicious nodes δ other than 3 / 10 (i.e., δ is less than 3 / 10 or δ is greater than 3 / 10).

[0161] Thus, if multiple sampler graphs are associated together, the computer network can start with a set of nodes having a malicious fraction of 1 / 3 and will eventually gather committees having a malicious fraction of 1 / 2. Embodiments of the present invention can determine a selection network as a series of sampler graphs that are stacked on top of each other. By running the selection network, multiple nodes in the computer network can select a leadership committee, where at most 1 / 3 of the nodes in the leadership committee are malicious. In some embodiments, nodes in a computer network including multiple nodes can determine multiple node committees in a sampler graph including multiple nodes, where the nodes can be in a node committee of the multiple node committees.

[0162] Figure 4 A block diagram showing a selection graph (or network) according to an embodiment of the present invention is shown. Figure 4 It includes a selection graph 401. The selection graph 401 can include multiple levels such as level zero 400, level one 410, level two 420, and level three 430. In some embodiments, the selection graph 401 can include any suitable number of levels. The selection graph 401 can also include parties 402, committees 403, sub-committees 404, and a leadership committee 405 in any suitable manner.

[0163] The parties 402 can be nodes in the computer network. At level zero 400, the parties 402 may not yet be in a committee 403. After a selection round, the committee 403 can include multiple nodes (i.e., the parties 402). The sub-committee 404 can include parties 402 selected from the committee 403 at a previous level. For example, parties 402 in the committee 403 at level two 420 can select multiple parties 402 to form the sub-committee 404. Then, the sub-committee 404 can form the leadership committee 405 at level three 430. The leadership committee 405 can be a leadership committee. The selection process is described in further detail below.

[0164] The sampler graph can be represented as G(L,R) and can be a random bipartite graph, where the degree of each node in R (e.g., d R ) can be where n can be the number of nodes and c can be a scaling factor. The bipartite graph G can include two sets L and R. The set L can include vertices that can represent nodes. The set R can include vertices that represent committees. The sampler graph G(L, R) can be represented by Figure 4 two levels in

[0165] For example, the sampler graph G(L, R) can include parties 420 in level zero 400 and committees 430 in level one 410. For each node in R, the neighbors of the nodes in L can be randomly and independently and uniformly selected without replacement. None of the nodes in L have multiple edges to any of the nodes in R. The parties 420 in level zero 400 can each have an edge connecting to a committee 403 in level one 410. In some embodiments, the sampler graph can be randomly constructed using a predefined seed stored at each node of a computer network. In this way, the parties 402 in level zero 400 can be randomly connected to the committees 403 in level 410.

[0166] If the vertex members of a committee in G are connected, the node can be a committee member. The maximum coalition of malicious nodes T can be a subset of L (i.e., ). A subset of committee S can be any subset of the committee (i.e., ). ε(T, S) represents the event that each node in S has more than fraction of the edges associated with a node in T. Intuitively, ε can capture the following event: all committees in S are malicious, i.e., more than fraction of the nodes in the committee are malicious. The probability that a fixed node in S is also in T can be equal to

[0167] The selection network can be constructed by associating l sampler graphs together. Each sampler graph can correspond to a different level in the selection graph 401. For example, level one 410 can correspond to the first sampler graph G(L 1 , R 1 ), level two 420 can correspond to the second sampler graph G(L 2 , R 2 ), level three 430 can correspond to the third sampler graph G(L 3 , R 3 ). In some embodiments, there can be any suitable number of levels. The last level (i.e., the level at which the leadership committee 405 can be formed) can be level l and can correspond to the final sampler graph G(Ll , R l ).

[0168] Initially, n nodes can be assigned to the vertices in L 1 . Based on the edges in the sampler graph, each node can be assigned to a set of committees, each represented by the vertices in R 1 . Then, each committee can run the following subcommittee selection protocol to select a random subset of the committee nodes. Then, the selected nodes can be used as the L 2 , R 2 vertices of G(L 2 ). This process can continue until the last sampler graph G(L l , R l ), at which point a single committee (i.e., the leadership committee) can be formed.

[0169] To construct the selection network, the following can be set:

[0170]

[0171] where 0 < α i , β i , γ i < 1 and i = {2,..., l}. It can be shown that for some constant l, |R l | = 1.

[0172] From Equation 3, the error probability can be bounded for each level i of the selection network represented by p i , where

[0173]

[0174] Section VII below describes how to set the parameters α, β, and γ to instantiate this graph and presents an analysis that can achieve a good bound on its size.

[0175] After determining the committees of nodes in a sampler graph that includes multiple nodes, the nodes of each committee can run the GenRand protocol or potentially any other suitable random value generation algorithm. Each node can generate a random string s. The nodes within a committee can generate the same random string s. For example, the first multiple nodes in the first committee can generate a first random string, while the second multiple nodes in the second committee can generate a second random string. In some embodiments, the random string s can be of any suitable length.

[0176] Multiple nodes in the committee can use a random string s to select nodes that can be associated with the next-level committee. Each node with a node identifier ID can compute a hash function based on the random string s and the node's node identifier h = H(s||ID). After determining a solution to the hash function, if h <= 2 256-d , the node can announce itself as part of the next-level committee, where H may be a hash function modeled as a random Oracle. h <= 2 256-d can be a predetermined security value. d may be the difficulty level of computing the hash function and can be any suitable predetermined value. The difficulty level d can determine the computational difficulty of solving the hash function. 256 can represent a 256-bit number, but any suitable number, such as γ, can be used.

[0177] In other embodiments, the predetermined security value can be 2 γ-d . For example, if the first node determines that the hash value h can be less than or equal to 2 γ-d , the first node can broadcast the hash value h to other nodes. In some embodiments, the first node can broadcast the hash value h and the node identifier associated with the first node to other nodes. The predetermined security value 2 γ-d can be changed to change how many nodes are selected. In some embodiments, the predetermined security value can be predetermined by the leadership committee.

[0178] Each node can perform a proof-of-work process using the random string s and the hash function. If the proof-of-work process produces an acceptable solution, the node can broadcast the solution to all other nodes in the multiple nodes (i.e., in the same committee), where the other nodes can verify the solution. In some embodiments, each node in each committee can perform a proof-of-work process. If the result of the proof-of-work process is less than a predetermined security value (e.g., 2 γ-d ), then the solution of the proof-of-work process can be considered acceptable.

[0179] Other nodes in the committee can verify the solution broadcast by the node. Other nodes in the committee can verify the solution by determining whether the solution solves the hash function and whether it is less than a predetermined number. If other nodes verify the solution, the node can select a subcommittee for the node committee.

[0180] In some embodiments, all nodes can sign the data (ID, s) of e selected nodes with the minimum h, and then propagate the signatures in a set form as proof of the selection of the selected nodes. The signed data (ID, s) can prove that the e selected nodes are actually the selected nodes. Any given node can verify the signed data (ID, s) to determine whether the node is a selected node.

[0181] After each subcommittee selection (i.e., after each committee selects nodes into subcommittees), the selected nodes can learn the identities of other selected nodes belonging to the same subcommittee. In some embodiments, this can be done by diffusion within the G overlay network to announce the selection winners to all nodes.

[0182] In some embodiments, after each subcommittee selection, nodes can perform subcommittee peer discovery. Each node can learn the identities of the nodes selected from each committee. The e selected nodes can send the identity and proof (signed f + 1(ID, s)), where f can be the fraction of nodes that are malicious nodes. If more than e nodes of a committee correctly announce that they are selected, then the committee is dishonest, and all other nodes can decide not to accept any messages from any selected nodes of that committee.

[0183] After joining a subcommittee, each node in each subcommittee can update the sampler graph to represent the selected nodes and the next-level committees. Nodes can repeat the above steps to select nodes from new committees to form new subcommittees. Nodes can repeat this process until the leadership committee is determined. In some embodiments, nodes can determine the leadership committee based on the sampler graph, where the sampler graph indicates the number of nodes in the sampler graph, and where the number of nodes in the sampler graph is less than or equal to a predefined threshold. For example, the predefined threshold can be equal to the value 100. In this case, the maximum number of nodes that can join the leadership committee is 100. Thus, if the number of nodes in a subcommittee is less than or equal to 100 nodes, the nodes of the subcommittee can determine to form the leadership committee. In other embodiments, the predefined threshold can be equal to the value 300 or any other suitable value. In some embodiments, the predefined threshold can be predetermined by an entity associated with the computer network. In other embodiments, the predefined seed can include information about the predefined threshold.

[0184] The leadership committee selected from the above protocol can randomly partition all nodes in the computer network into shard committees, each shard committee can have at least 2 / 3 non-malicious nodes, and can store a partition of the distributed ledger, as described below. In some embodiments, the size of the shard committee can be much smaller than the leadership committee, which can improve transaction latency.

[0185] Figure 5 A flowchart showing the setup phase according to an embodiment of the present invention. It will be described in the context of selecting a leadership committee in a computer network Figure 5The method shown in []. However, it should be understood that embodiments of the present invention can be applied to other situations (e.g., determining a leader in a communication network or an asset transfer network). Although the above steps are shown in a specific order, it should be understood that embodiments of the present invention can include methods having steps in a different order. Additionally, steps can be omitted or added, and they can still be in embodiments of the present invention.

[0186] Before step S510, multiple nodes can join a computer network or otherwise connect to a computer network. The multiple nodes can include any suitable number of nodes. Each node among the multiple nodes can determine a node identifier. In some embodiments, the node identifier can be a public key. A node can establish the node identifier by solving a proof-of-work process. Each node among the multiple nodes can broadcast its own public key to every other node in the network. The computer network can include multiple nodes, each having a node identifier. The multiple nodes in the computer network can initialize communication between the nodes. For example, in some embodiments, each node can communicate operatively with every other node. In other embodiments, the multiple nodes in the computer network can create a routing table based on surrounding nodes.

[0187] At step S510, each node can receive node identifiers from other nodes. For example, if there are 200 nodes in the computer network, each node can receive 199 node identifiers. In some embodiments, each node can be associated with a unique node identifier. A node can transmit the node identifier associated with the node to every other node in the computer network.

[0188] At step S520, after receiving node identifiers from other nodes, each node can determine multiple node committees in a sampler graph. In some embodiments, each node can determine the sampler graph locally. In some embodiments, the sampler graph can be determined based on the node identifiers known to all nodes in the computer network and a predefined seed.

[0189] For example, a node can randomly determine the sampler graph based on a predefined seed. The predefined seed can be any suitable value previously stored by nodes in the computer network. The predefined seed can be used to randomly generate edges in the sampler graph connecting nodes in L and committees in R. The nodes in L can be generated from the node identifiers received from each node. The committees in R can be randomly generated based on the seed and the node identifiers. For example, each node can generate 7 committees or any other suitable number of committees in R based on the predefined seed.

[0190] Since each node can store the same predefined seed and all node identifiers of all nodes, each node can generate the same sampler graph. However, in some embodiments, a sampler graph of some honest nodes may include malicious nodes while a sampler graph of other honest nodes does not. This may occur because a malicious node can broadcast its node identifier to some honest nodes but not others.

[0191] A plurality of node committees can include any suitable number of committees. In some embodiments, the number of node committees can be less than the number of nodes in the plurality of nodes.

[0192] At step S530, after determining the plurality of node committees, the nodes in the node committees can each perform steps S531 to S537. Each node committee can independently perform steps S531 to S537.

[0193] At step S531, after determining the sampler graph, each node of the committee can generate a random string. For example, each node can generate a random string using the GenRand protocol described herein. Each node in the committee can generate the same random string. The random string can be used in the proof-of-work process at step S532 such that the hash function is new. This can prevent malicious nodes from pre-computing many hash functions in advance and then demanding that solutions to the pre-computed hash functions be acceptable. The random string can allow for the dynamic generation of hash functions during each selection phase.

[0194] At step S532, after generating the random string at each node, the node can perform a proof-of-work process. For example, the node can determine a solution to the hash function. A node with node identifier ID 1 can compute h = H(s||ID 1 ). The solution to the hash function can be an acceptable solution. If h ≤ 2 256-d , the acceptable solution can be considered acceptable. The difficulty value d can be a predefined value, which can be used to determine how many nodes are selected. For example, if only a few nodes can solve the proof-of-work process and are thus selected, the difficulty value can be considered difficult. If many nodes can solve the proof-of-work process and are thus selected, the difficulty value can be considered easy. In other embodiments, the difficulty value can change over several epochs. In some embodiments, each node in the committee can perform the proof-of-work process.

[0195] At step S533, the node can determine whether it can accept its own solution to the proof-of-work process. If the node determines that the solution is unacceptable, the node can determine that it is not a selected node. If other nodes of the committee are selected as the subcommittee, the node can terminate the process and, in some embodiments, wait until the leadership committee is determined. In other embodiments, the node can determine a solution to the proof-of-work process acceptable as described herein. If the node determines that the solution is acceptable, the node can proceed to step S534.

[0196] At step S534, after determining a solution to the acceptable proof-of-work process, the node can broadcast the solution to all other nodes in the committee. In some embodiments, the node can receive a second solution from a second node in the node committee. The node can receive any suitable number of solutions from other nodes determined by those nodes.

[0197] At step S535, other nodes can receive the solution to the proof-of-work process from the node. The other nodes can then determine whether the solution is acceptable. For example, the other nodes can determine whether the solution solves the proof-of-work process. In some embodiments, the node can verify whether the second solution from the second node is acceptable.

[0198] At step S536, if the other nodes determine that the solution to the proof-of-work process from the node is invalid, the other nodes can broadcast an invalid message. In some embodiments, the invalid message can include the ID of the node and the solution to the proof-of-work process determined by the other nodes to be unacceptable. The node can receive the invalid message from the other nodes. The node can determine whether the invalid message includes its own ID, i.e., whether the invalid message is associated with the node. The node can determine that it is not the selected node and wait until the leadership committee is determined by the selected nodes.

[0199] At step S537, if the other nodes determine that the solution is acceptable, the other nodes can select the node for the subcommittee of the committee. In some embodiments, if the second solution is acceptable, the node can select the second node for the subcommittee.

[0200] At step S540, the nodes of each subcommittee can determine whether the leadership committee has been determined. If the leadership committee has not been determined, the nodes can perform step S550. At step S550, if the leadership committee has not been determined, the nodes of each subcommittee can update the sampler graph and perform steps S520 to S540. After updating the sampler graph, the subcommittee can determine a new committee based on the sampler graph, thereby moving to the next level in the selection graph. As described herein, multiple sampler graphs can be associated together to form a selection graph, where each sampler graph can include nodes of a selection graph level connected to the next-level committee by edges. For example, the nodes selected in the first level of the selection graph can join the subcommittee that updates the sampler graph and then form the committee of the second level of the selection graph.

[0201] At step S560, the nodes of the subcommittee can determine the leadership committee. In some embodiments, the nodes can determine the leadership committee based on the sampler graph, where the sampler graph indicates the number of nodes in the sampler graph and where the number of nodes in the sampler graph is less than or equal to a predefined threshold. The predefined threshold can be the maximum number of nodes to join the leadership committee.

[0202] After determining the leadership committee, the nodes of the leadership committee C 0 can run GenRand as described herein to generate a random string r 0 . The nodes of the leadership committee C 0 can use the overlay network of G to send the random string r 0 to all nodes (i.e., multiple nodes of the computer network). The random string r 0 can be used to partition all nodes into non-malicious shard committees. In some embodiments, the leadership committee can create k = n / m shard committees, where each shard committee includes m = c * log(n) nodes, where n is the number of nodes in the computer network and c is a constant that can depend on the system security. The nodes in the leadership committee can partition the multiple nodes in the computer network.

[0203] After step S560, the nodes in the computer network can execute a neighbor discovery protocol (shown as Protocol 2 below). The neighbor discovery protocol can allow the nodes in the committee to determine which nodes are in neighboring committees. In some embodiments, the nodes in the committee can determine the IP addresses of the nodes in the neighboring committees, which can then be used when routing messages and / or data. Each node in the computer network can be based on the random string r 0The public key of the node and the node determines which committee to join. In some embodiments, each node can perform a proof-of-work process to determine which committee to join. For example, each node can determine the hash value generated by the hash function H(r 0 ||PK), where the random string r 0 and the public key of the node can be the input of the hash function. After determining the solution of the proof-of-work process, the node can determine the last m bits of the solution. The node can join committee C k , where k can be the last m bits of the solution.

[0204] After each node determines which committee to join, the nodes in committee C k / 2 can broadcast the addresses of the nodes in committee C k / 2 to the nodes in committee C k . Each node in C k can receive the addresses of the nodes in committee C k / 2 . The addresses can include Internet Protocol addresses (IP) and committee identifiers (e.g., C k , C k / 2 , etc.). After receiving the node addresses of committee C k / 2 , the nodes in committee C k can broadcast the addresses of the nodes in committee C k (e.g., IP and C k ) to the nodes in committee C k / 2 . If committee C k = C 6 , then C k / 2 = C 3 .

[0205] After the nodes in committee C k communicate with the nodes in committee C k / 2 , the nodes in committee C k can receive the addresses of the nodes in committee C 2k and can receive the addresses of the nodes in committee C 2k+1 . The nodes in committee C k can then broadcast the addresses of the nodes in committee C 2k and the addresses of the nodes in committee C 2k+1 to all nodes of the computer network.

[0206] As described herein, Protocol 1 and Protocol 2 below respectively illustrate examples of a committee selection and neighbor discovery protocol. Protocol 1 can allow multiple nodes to form a leadership committee and partition multiple nodes into shard committees in an efficient and secure manner. Protocol 2 can allow multiple nodes to determine which committee to assign the nodes and other nodes in the committee to.

[0207] Protocol 1: Committee Selection

[0208] {G(L 1 , R 1 ),..., G(L l , R l )} is the selection network graph.

[0209] 1. For each 1 ≤ i ≤ l of each committee C in G(L l , R l ):

[0210] (a) The nodes of C run GenRand to select a random string s.

[0211] (b) All nodes of C sign s and propagate their signatures within C.

[0212] (c) For each node of C with public key PK, if H(s||PK) ≤ 2 κ-e , then the node broadcasts a message to all members of C, declaring itself as a selected member, where c determines the number of parties to be selected. The leader can also propagate a proof (s that can be signed by f + 1 of the members of C).

[0213] (d) All members of C verify the announcement. The leader in C can learn about all other leaders of other committees. If a committee announces more than e leaders, the announcement is ignored and the committee is marked as dishonest and its leader is set to empty.

[0214] 2. C 0 is the leadership committee of G. C 0 runs GenRand to generate a random string r 0 and sends it to all parties using G's overlay network. This value can be used to partition all nodes into shard committees.

[0215] Protocol 2: Neighbor Discovery

[0216] 1. The parties consider C k as their committee, where k can be the last m bits of H(r 0 ||PK).

[0217] 2. It receives the addresses of the members of its receiving committee C k / 2 and sends them (IP, C k ) to the parties in C k / 2 .

[0218] 3. It receives the information (IP, C) of the parties in its receiving committees C 2k and C 2k+1 and sends it to everyone.

[0219] Internal consensus within the committee

[0220] Figure 6 A block diagram showing a sharding committee according to an embodiment of the present invention is shown. Figure 6 It includes a leadership committee 600 including a plurality of nodes, the nodes including selected node A 601, selected node B 602, selected node C 603, and selected node D 604. Figure 6 It further includes a plurality of sharding committees including a first sharding committee 610, a second sharding committee 620, and a third sharding committee 630. Each sharding committee may include a plurality of nodes. For example, the first sharding committee 610 may include three nodes 611 to 613. The second sharding committee may include three nodes 614 to 616. The third sharding committee 630 may include three nodes 617 to 619. Each committee may include any suitable number of nodes. The committee may include more than 5 nodes. In other embodiments, the committee may include 250 nodes.

[0221] The leadership committee 600 may communicate operatively with the first sharding committee 610, the second sharding committee 620, and the third sharding committee 630. In some embodiments, the sharding committees may communicate operatively with each other.

[0222] The leadership committee 600 may determine the sharding committees as described herein. For example, as shown in Protocol 2, the leadership committee 600 may generate a random string r 0 and transmit the random string r 0 to each node in the computer network. Each node may then use its own node identifier and the random string r 0 to perform a proof-of-work process. The last m bits of the solution to the proof-of-work may be the sharding committee assigned to the node. For example, a node may determine which sharding committee to join based on the random string r 0 and the node identifier. If the last m bits of the solution equal 001, the node may decide to join committee 001. The last m bits may be any suitable number of bits.

[0223] The first sharding committee 610 may store shards of the blockchain. For example, nodes 611 to 613 in the first sharding committee 610 may each store a shard of the blockchain in a memory or database associated with each of nodes 611 to 613. The first node 611, the second node 612, and the third node 613 may store the same shard of the blockchain, and in some embodiments, may reach a consensus on a new block before adding the new block to the shard of the blockchain. The first sharding committee 610, the second sharding committee 620, and the third sharding committee 630 may store different shards of the blockchain. In some embodiments, the shards of the blockchain stored in each sharding committee may constitute the total blockchain.

[0224] A client computer external to the computer network may submit an interaction to the computer network. The client computer may transmit the interaction to a validator committee. For example, the client computer may transmit the interaction to the first sharding committee 610, where the first sharding committee 610 may be a validator committee that can verify the interaction.

[0225] An advantage of an embodiment of the present invention may be that an interaction submitted by a client computer to the system can be processed by a single committee, which runs an intra-committee consensus to approve and add the interaction to the blockchain. When the client computer requests to add an interaction to the ledger using the routing protocol described below, the client computer may contact the validator committee designated for the interaction. Each node in the validator committee may check whether the proposed interaction is valid, and then may generate a data block of all valid interactions received by the committee during that period to add to the blockchain. In some embodiments, each node may maintain a copy of the shard of the blockchain designated for its committee and may independently decide whether to add certain interactions to the shard of the blockchain. Honest nodes in the committee may have the same local view of the shard of the blockchain, which may represent the current state of the shard of the blockchain of the committee.

[0226] In some embodiments, when the client computer wishes to submit an interaction to the computer network, the client computer may first obtain a list of multiple nodes (see Section VII below) and may send the interaction data to multiple (e.g., 8 or more) nodes, obtain the interaction data through the nodes in the committee, and submit the interaction data to those nodes. If the contacted node is malicious, the interaction cannot be processed. Then, the client computer may submit the interaction data to another party and may repeat until the client computer contacts an honest node. Within each committee, the node that receives the interaction data from the client computer may propose to add the interaction to the next data block. To this end, the node may reliably broadcast the proposed interaction to all other nodes in the committee.

[0227] The committee-internal consensus protocol can have two building blocks: (1) a rumor protocol that can be used to spread messages (e.g., transactions and data blocks) to all nodes of the committee; (2) a negotiation protocol that can be used to reach an agreement on block headers and finally finalize the transactions therein.

[0228] In some embodiments, the above consensus protocol can be an atomic broadcast protocol, and embodiments of the present invention can be used to send new transactions to all committee members (i.e., nodes in the shard committee). Embodiments of the present invention can be a modification of the reliable broadcast protocol proposed by Cachin and Tessaro [Christian Cachin and Stefano Tessaro, Asynchronous Verifiable Information Dispersal. In the Proceedings of the 19th International Conference on Distributed Computing, DISC'05, pages 503 - 504, Berlin Heidelberg, 2005, Springer-Verlag], which uses an erasure code to extend the broadcast protocol of Bracha and Toueg [Gabriel Bracha and Sam Toueg, Asynchronous Consensus and Broadcast Protocols, Journal of the ACM (JACM), 32(4): 824 - 840, 1985] to improve the performance for larger messages. The original protocol of [Gabriel Bracha and Sam Toueg, Asynchronous Consensus and Broadcast Protocols, Journal of the ACM (JACM), 32(4): 824 - 840, 1985] requires O(n 2 ) messages and O(mn 2 ) total communication cost to broadcast a message of size m to n parties. The construction in [Christian Cachin and Stefano Tessaro, Asynchronous Verifiable Information Dispersal. In the Proceedings of the 19th International Conference on Distributed Computing, DISC′05, pages 503 - 504, Berlin Heidelberg, 2005, Springer-Verlag] improves the communication to O(mn + hn 2 log(n)), where h is the hash size proportional to the security parameter. The method according to embodiments of the present invention can achieve better practical communication performance when the number of nodes is also large.

[0229] M can be a message propagated from a node (e.g., the sender) to d adjacent nodes, and a fraction f of the nodes may be corrupted. In addition, κ can be the number of information blocks into which the sender can break a larger message. First, the sender can divide M into (1 - f)κ equal-sized blocks M 1 , M 2 ,..., M(1 - f)κ and can perform an erasure code scheme (e.g., Reed - Solomon erasure code) to create another fκ parity blocks, which can be added to the original data blocks to obtain M 1 , M 2,..., M k . If the sender is honest, the original message can be reconstructed from any set of (1 - f)κ data blocks among those blocks.

[0230] Next, the sender can compute a Merkle tree with leaves M 1 ,..., M k . T(M i ) can be the hash of leaf block M i , and T(M i , M j ) is the hash stored in the first common parent of M i and M j . Sib(M i ) can be all the sibling nodes of the nodes on the path from the Merkle root to the leaf associated with M i . Thus, T(M i ), T(M i , M κ ) and Sib(M i ) are parts of the Merkle tree used to verify the validity of M i . The sender can propagate all M i for 1 ≤ i ≤ κ, T i (M i ) and Sib(M i ) by sending a unique set of κ / d information blocks to each adjacent node, and then those adjacent nodes can also send the information blocks to their neighbors. Each node can use the Merkle tree information and the root to verify the message it receives. Once a node receives (1 - f)κ valid information blocks, it can reconstruct the message M.

[0231] The above rumor protocol can also be optimized by making the following slight modifications. The modification of the above protocol is based on the observation of whether the sender sends Sib(M i ) to node P i for each i. The Merkle hashes near the root are almost sent to all parties. For example, half of the nodes receive T(M i , M κ / 2 ). In contrast, for any intermediate hash node T(M i , M j), which is sufficient to send it to a smaller subset of nodes. The sender selects a random subset of neighboring nodes of size d / (1 - f) and sends the hash to the nodes in the subset. This process may be referred to as thinning. Thus, a node may receive a message from the sender that does not contain all the hashes required to verify the validity of the data block that has been sent, and thus the party may not be able to immediately verify the data block. However, since at least one honest party receives each intermediate node, it can ensure that all nodes can have the correct intermediate nodes.

[0232] In each round r, each committee can have a leader node L randomly and unanimously selected r , which can be responsible for leading the consensus protocol. First, the leader node L r can collect all the interactions in the data block B that the leader node L r has received r . The leader node L r can use the rumor of the larger message protocol described herein, as well as the root of the Merkel tree of the rumor from the block, to propagate the body of the block. Next, the leader node L r can run the consensus protocol based on the headers of all the pending blocks (including the block created by the leader node L r in this round).

[0233] In some embodiments, the block can be a pending block. If the leader node L r proposed a data block in a previous round, the data block can be a pending block, but there are still honest nodes that have not terminated their consensus protocol. For all pending block headers H, the leader node L r can propose a secure value. The secure value can be a value that most nodes agree on. When most nodes agree on the secure value, the value can be regarded as the secure value. In contrast, an insecure value can be a value that not all nodes agree on. In some embodiments, the block header can include the hash of the previous block, a timestamp, a difficulty target, a nonce, and / or a Merkle root. For a new block, any value can be regarded as secure, but an honest leader node L r can propose the correct data block header, so that all other honest nodes in the computer network can accept the data block. If the data block header does not match the data block, all honest nodes can regard the data block as an empty data block and can only agree on the header and ignore the interactions within the data block body. If an honest node does not receive the secure value of the pending data block header from the leader node L r , they can regard the leader node L r as a dishonest node and set the value of the header to be empty.

[0234] For all the data block headers to be processed, from the leader node L r Upon receiving a proposed message, other nodes that propose <H, r> can verify whether the header H is valid. For example, a node can verify whether the header H matches the proposed data block. A node that receives a proposal message and proposes <H, r> can echo (i.e., broadcast without modification) the header as Echo <Proposal <H, r>>. The echoed proposal message can contain the same information as the proposal message. A node can receive a proposal message and then broadcast the echoed proposal message. At the end of this round, if an honest node receives a valid proposed header from the leader and f + 1 echoes, the node can accept the data block headers of all other nodes by propagating the node's accept message.

[0235] In some embodiments, a node can receive more than one valid "Proposal <H, r>" or "Echo <Proposal <H, r>>" from the leader node L for different values of H but with the same number of rounds r. The node can consider the leader node L r as dishonest and then propagate "Pending <H, r>", which can indicate that the header H is still pending. In other embodiments, a node can receive f + 1 valid messages (i.e., votes) for <H, r>, indicating that the header H is valid. f can be the fraction of malicious nodes. In some embodiments, f can be 1 / 3 or less. r Each echo "Echo <Proposal <H, r>>" message of the same proposed value from a single node in the current round can be considered a vote for the validity of the header H. Then, the node can accept the value H and propagate "Accept <Proposal <H, r>>, Proof", and remove it from the node's list of pending data blocks. The proof can be a data entry indicating that the header H is proven to be valid. In some embodiments, the proof can be an aggregation of node signatures. For example, a node can sign the proposed message if it is valid and then send the signed proposed message to the leader node L

[0236] If a node receives a valid "Accept <Proposal <H, r>>, Proof" message from another node, the node can change the vote of the other node to <H, r>. For example, in some embodiments, a node can store a list of votes from nodes in the committee. If a node receives a valid "Accept <Proposal <H, r>>, Proof" message from a second node, the node can edit the vote list to indicate that the second node voted for the header H. The node can decide to accept the Proposal <H, r> message if the vote list indicates that f + 1 other nodes have voted for the header H. r .

[0237]

[0238] ​The following Protocol 3 shows an example committee internal consensus protocol as described herein. The following committee internal consensus protocol may allow nodes to create interaction blocks and enable the committee to reach a consensus on the interaction data blocks.

[0239] Protocol 3: Committee Internal Consensus

[0240] 1. Create an interaction block and propagate it to the committee.

[0241] 2. For round r, reach a consensus on the pending block header H for each pending data block header.

[0242] (a) The leader may propagate "Propose <H, r>" and a "Proof" message showing that the value is secure for the security value H of round r, i.e., the proof contains f + 1 votes for <H, r>.

[0243] (b) A node that receives a valid "Propose <H, r>" may propagate an "Echo <Propose <H, r>>" message.

[0244] (c) If a node receives more than one valid "Propose <H, r>" or "Echo <Propose <H, r>>" from the leader for different values H but the same round number r, the node may consider the leader as dishonest and propagate "Pending <H, r>".

[0245] (d) Otherwise, if a node receives f + 1 valid votes for <H, r> (each "Echo <Propose <H, r>>" message for the same proposed value in the current round is also considered a vote in addition to the votes the party has received from accept messages before), the node accepts the value H and propagates "Accept <Propose <H, r>, Proof>" and deletes it from the node's pending data block list.

[0246] (e) If a node receives a valid "Accept <Propose <H, r>>, Proof" message from another party, the node changes the votes of other nodes for <H, r>.

[0247] Thus, a node may receive a message from a broadcaster that may not contain all the hashes required to verify the validity of the sent data block, so the node may not be able to immediately verify the block. However, if at least one honest node receives each intermediate node, it can forward its message, and this can allow all nodes to have the correct intermediate nodes. In Section VII.B, it can be shown that it is sufficient to send each intermediate node to a number of nodes that is sublinear in the tree depth to ensure the following: the probability that a node cannot verify a data block required for reconstruction is extremely low. A trade-off can be made between the tree and the number of nodes in the memory used at each node to receive the intermediate nodes.

[0248] Reconfiguration Phase

[0249] In an open access network, nodes can freely join and leave the network. Embodiments of the present invention can provide a mechanism to efficiently handle changes in a computer network. There are two major challenges when a new node joins a computer network. First, an adversary can use the change as a potential way to introduce new dishonest IDs into the network (e.g., Sybil attack). To prevent a Sybil attack, a new node joining the computer network can solve a proof-of-work process. Second, nodes joining and leaving the computer network can affect the committee distribution and may make the committee unreliable. The method according to an embodiment of the present invention can handle changes during an adjustment phase.

[0250] The adjustment phase (also referred to as a reconfiguration phase) can include a method comprising: receiving, by a first node in a first committee in a computer network, a request including a node identifier to cause a second node to join the committee; providing, by the first node in the first committee, a proof-of-work process to the second node; receiving, by the first node in the first committee, a solution to the proof-of-work process from the second node, wherein nodes in the first committee verify the solution; generating, by the first node in the first committee, a random string, which the first node uses to determine a second committee for the second node; introducing, by the first node, the second node to the second committee, wherein the second committee shifts nodes to allow the second node to join the second committee; and communicating, by the first node, information that the second node is in the second committee to other nodes in the computer network.

[0251] Figure 7 A flowchart showing a reconfiguration phase according to an embodiment of the present invention is shown. The method shown is described in the context of adding a new node (referred to as the second node) to a computer network. Figure 7 However, it should be understood that embodiments of the present invention can be applied to other situations. Although the above steps are shown in a particular order, it should be understood that embodiments of the present invention can include methods having steps in a different order. Additionally, steps can be omitted or added and they can still be within embodiments of the present invention.

[0252] Embodiments of the present invention can use a proof-of-work method to prevent Sybil attacks on a computer network. A new node (i.e., the second node) wishing to join a computer network including a leadership committee and a plurality of committees can solve a proof-of-work process, which can be generated based on new randomness in each period. This can be beneficial as it prevents malicious parties from solving many proof-of-work processes in advance and thus compromising the committee.

[0253] At step S710, any second node (i.e., new node) can contact one of the nodes in the committee and can request a new proof-of-work process at any time. The second node can transmit the request to one of the nodes in the committee. In some embodiments, the second node can transmit the request to a single node, referred to as the first node. The first node in the first committee in the computer network can receive the request including the node identifier to enable the second node to join the committee.

[0254] At step S720, after receiving the join request, the node in the first committee can generate a random value. In some embodiments, the node in the first committee can use GenRand as described herein to generate the random value. The GenRand algorithm can consist of two phases: commitment and revelation. The commitment phase may be the more expensive phase to practice of the two phases. In some embodiments, the commitment phase can be performed beforehand before the node in the first committee receives the request. Thus, each node in the first committee can run the commitment phase of random generation of many values in advance, and after the request, the node in the first committee can complete the revelation phase to obtain one of the random values that have been submitted.

[0255] Then, the node in the first committee can transmit the random value and the timestamp to the second node. In some embodiments, the first node in the first committee can provide the proof-of-work process to the second node. The second node can solve the proof-of-work process using the timestamp and the random value. If the second node determines an acceptable solution, the second node can transmit the solution to the node in the first committee. For example, the second node can determine the solution x such that the hash function H(timestamp||PK||x) is less than the security value 2 γ-d and send x to the first committee. The input to the hash function H can include the timestamp, the public key of the second node (i.e., the node identifier), and the random number x.

[0256] At step S730, the first node in the first committee can receive the solution to the proof-of-work process from the second node, where the node in the first committee verifies the solution. The nodes in the committee can verify that the second node has solved the proof-of-work process within a predefined time period and that the solution is acceptable. If the nodes in the committee determine that the second node has determined an acceptable solution within the predefined time period, the nodes in the committee can continue to assign the second node to the committee in the computer network. In some embodiments, if the solution solves the proof-of-work process, is less than a predetermined security value (e.g., 2 γ-d ) and is received within a predefined time period, multiple nodes in the first committee can verify the solution.

[0257] Embodiments of the present invention allow new nodes to solve the proof-of-work process without terminating the protocol and waiting for a solution to the proof-of-work process. In this way, the expensive proof-of-work sub-algorithm can be performed incidentally without affecting the latency of the consensus protocol, thereby increasing the overall throughput of the protocol. This improves the method used in Elastico [Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena, Secure sharding protocol for open blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pages 17–30, New York, NY, USA, 2016, ACM], which requires the protocol to wait for the PoW randomness of each epoch after a change and run the entire committee selection again. The Elastico protocol reduces throughput and incurs an additional Ω(n) communication cost.

[0258] After the nodes in the committee determine that the new node has solved the proof-of-work process, the computer network can perform committee reconfiguration. However, some challenges can be addressed. Partitioning nodes into scalability committees introduces new challenges when dealing with changes. Malicious nodes can strategically leave and rejoin the computer network so that eventually they can take over one of the committees and undermine the security guarantees of the protocol.

[0259] One way to prevent such an attack could be to recreate all committees regularly, faster than the adversary's ability to generate changes. However, this solution has two drawbacks. First, regenerating all committees can be very expensive. Second, maintaining blockchain partitions (one partition per committee) can be very challenging when all committee members may change after each epoch.

[0260] To handle the change problem, embodiments of the present invention can re-randomize committee members after nodes join and leave. In some embodiments, a small number of nodes can change committees, which can be more efficient than regenerating all committees. The method according to an embodiment of the present invention can use a modified version of the Cuckoo rule [Baruch Awerbuch and Christian Scheideler, Towards a Scalable and Robust DHT. In Proceedings of the 18th Annual ACM Symposium on Parallelism in Algorithms and Architectures, SPAA'06, pp. 318-327, New York, NY, USA, 2006, ACM; and S. Sen and MJ Freedman, Commensal Cuckoo: Secure Group Partitioning of Large Services, ACM SIGOPS Operating Systems Review, 46(1): 33-39, 2012], known as the bounded cuckoo rule, to achieve redistribution of committee nodes.

[0261] At step S740, after the nodes of the first committee verify the solution of the second node, the first node may generate a random string that may be used by the first node to determine the second committee of the second node. In some embodiments, the first node may generate the random string using the GenRand protocol described herein. In some embodiments, each node of the first committee may generate a random string. The first node may determine the second committee by determining the random committee in the sampler graph using the random string.

[0262] At any suitable point in time, the committee of the computer network may determine the set of the largest m / 2 committees as the active committee set A, where m may be the number of committees. The remaining m / 2 committees of smaller size may be part of the set of inactive committees I. In this way, half of the largest committees may be included in the active committee set A and half of the smallest committees may be included in the inactive committee set I.

[0263] In some embodiments, when a second node requests to join the computer network, the second node can discover the identities of the nodes in one of the committees (e.g., the first committee). In some embodiments, the first committee can be composed of C a When a second node requests to join the network, the second node can contact the access point committee C a All nodes.

[0264] At step S750, after the first node generates the random string, the first node may introduce the second node to the second committee, wherein the second committee may shift the nodes in the second committee to allow the second node to join the second committee.a A random committee C can be determined from the set A of active committees b , which is called the main assignment committee of the second node. The access point committee C a can notify the second node and the nodes of the main assignment committee C b about the new assignment. The main assignment committee C b can accept the joining, and at the same time can take back a constant number of nodes in the main assignment committee into other committees randomly selected from the inactive committees in the set of inactive committees I, which can be called secondary assignment committees.

[0265] In some embodiments, the second committee (i.e., the assignment committee) can shift a random number of nodes in the second committee based on a random value generated by the leadership committee. The shifted nodes can be the shifted nodes. The shifted nodes can determine which committee to join based on the random value. The shifted nodes can be assigned to a random inactive committee in the set of inactive committees I.

[0266] At step S760, after introducing the second node to the second committee, the first node can communicate the information that the second node is in the second committee to other nodes in the computer network.

[0267] The committees in the computer network can have many properties during the change. There can be invariant properties of two system committees maintained during the change protocol. At any point in time, the system committees can be balanced and they are honest. The first property means that there may not be too much deviation in the size of the committees in the system, and the size can be concentrated around 1 / 2c log n for a certain constant c. The second property can be that at least 2 / 3 of the nodes in each committee are non-malicious nodes. Therefore, the committees can successfully run the consensus protocol when processing blockchain interactions.

[0268] The following Protocol 4 describes an example of the adjustment phase as described herein. The adjustment protocol can allow the computer network to handle newly joined nodes while preventing Sybil attacks.

[0269] Protocol 4: Adjustment

[0270] 1. Puzzle Generation

[0271] (a) Each committee runs GenRand to generate a random string r i .

[0272] 2. Joining

[0273] (a) The new party P locally selects a public key PK and contacts the random committee C a to request a proof-of-work process.

[0274] (b) C sends r i and the timestamp to P.

[0275] (c) P finds a random number x such that the solution of the hash of the timestamp, public key, and random number is less than the security value (i.e., O = H(timestamp || PK || x) ≤ 2 γ-d ) and sends x to C.

[0276] (d) If C receives the solution within the valid time slot, it confirms the solution. The members of C run GenRand to generate a new random string s, which determines the committee C among the active committees in A where P will join b .

[0277] 3. Cuckoo Transaction

[0278] (a) C a contacts C b to introduce P.

[0279] (b) C k selects a constant number k of parties to be withdrawn to k committees randomly selected uniformly from the set of inactive committees I.

[0280] (c) Propagates the committees of the new state to the neighboring committees in the system.

[0281] In some embodiments, there may be a reference committee C R , which can check the proof of work solution of all nodes in the computer network. In this embodiment, the reference committee C R may be the only committee that generates the random string at step S720. At the beginning of each epoch, the reference committee C R may create a list of all currently active nodes for the data block and the assigned committees, and add the list to the first block of each epoch. The reference committee C R may also notify other committees by sending this block to all other committees so that they can also add the data to their first blocks.

[0282] In each epoch, the nodes of the reference committee C R can determine a random number (e.g., via GenRand). The nodes of the reference committee C R can transmit the random number and the timestamp to the second node when the second node requests to join the computer network. In this case, the reference committee C R can perform the reconfiguration method described herein.

[0283] If there is a reference committee C R, the reconfiguration phase can be performed as follows. Refer to Committee C R Random generation can be performed during epoch i-1 by first generating a random string r for the next epoch i Refer to Committee C R The nodes of can disclose r to other nodes of the computer network at the end of epoch i-1 i . During epoch i, all committees can receive the random string r from the reference Committee C R at the start of round i i . The second node can generate a public key PK locally. The second node can contact the random committee C to request a proof of work. Committee C can transmit the random string r of the current epoch i , the timestamp, and the addresses of multiple random nodes in the reference Committee C R (e.g., 16 IP addresses) to the second node. All nodes of the computer network can determine x such that O = H(timestamp || PK || r i || x) ≤ 2 γ-d , as described herein. The nodes can transmit x to the reference Committee C R . The reference Committee C R can confirm the solutions received from each node before the end of epoch i

[0284] After confirming the solutions, during round i+1, the nodes currently in the reference Committee C R (also in the reference Committee C during epoch i R ) can determine the value r i+1 . During epoch i, the nodes of the reference Committee C R receive all the confirmed interactions of the active nodes of round i+1. The nodes of the reference Committee C R can create a list of all the active nodes of round i+1 and also create A (i.e., the set of active committees) and I (i.e., the set of inactive committees). The reference Committee C R can assign committees in A to each new node using the random value r i+1 . For each committee C with new nodes, the reference Committee C R can randomly and consistently select a constant k nodes (e.g., using r i+1 as a seed) in committee C and withdraw the k nodes. For all the withdrawn nodes, the reference Committee C R can randomly and consistently determine the committees in I and assign the withdrawn nodes to different committees. The reference Committee C R can then add r iAnd a new list of all nodes and their assigned committees, and add it to the first block of the said period. Refer to Committee C R Propagate the first block of the said period to all committees in the computer network.

[0285] Consensus phase

[0286] In this section, a mechanism can be described whereby the method according to an embodiment of the present invention can reduce the storage usage of each node by dividing the blockchain into partitions, each partition being stored by a committee. Although partitioning the blockchain can reduce the storage overhead of the blockchain, it makes the verification of interactions challenging because the inputs and outputs of each interaction may reside in multiple committees.

[0287] In this part of the protocol, a client computer can submit an interaction to the computer network and can add the interaction to the blockchain. Embodiments of the present invention use a new blockchain sharding protocol that can split the blockchain among different committees. New interactions can be submitted to the committee handling the corresponding shard (i.e., the partition of the blockchain). Then, the committee can run an intra-committee consensus protocol to approve the interaction and add it to the shard of the said committee. This section presents the sharding protocol and also presents the optimized intra-committee consensus protocol from Section IV.C.

[0288] The consensus phase can include a method comprising: receiving, by a first node in a committee, an interaction request, the interaction request including interaction data from a client computer; incorporating, by the first node, the interaction data and other interaction data associated with other client computers into a block including interaction data, wherein the block includes block parts; broadcasting, by the first node, the block to other nodes in the committee, wherein the other nodes in the committee verify the block; and incorporating the block into a shard of the blockchain managed by the committee.

[0289] In some cryptocurrencies, each transaction has a unique identity and it has a list of inputs (depicted by their identities) and a list of outputs shown by transaction ID and line number. Figure 8 A block diagram showing the parties to a transaction according to an embodiment of the present invention. Figure 8 Includes an initial UTXO state 810, a transaction 820, and an output UTXO state 830. Figure 8 Described with reference to the ninth transaction (TX9). However, it should be understood that embodiments of the present invention can be applicable to other cases, such as other transactions and interactions such as file transfers.

[0290] The initial UTXO state 810 can be the initial unspent transaction output from a previous transaction. For example, the initial UTXO state 810 refers to the first transaction TX1 associated with the second row (row 2). The initial UTXO state 810 also refers to the fifth transaction TX5, the seventh transaction TX7, and the eighth transaction TX8. These previous transactions TX1, TX5, TX7, and TX8 can be associated with previous transactions stored in the blockchain. In some embodiments, each previous transaction can be stored in a different shard of the blockchain. For example, the first transaction TX1 can be stored in the first shard committee 610, while the fifth transaction TX5 can be stored in the second shard committee 620.

[0291] In the initial UTXO state 810, the inputs of a transaction can be unspent transaction outputs (UTXOs), which can be digital assets that were not used in previous transactions. In the output UTXO state 830, the outputs of a transaction can also be unused digital assets, such as new coins generated for the recipient in exchange for currency. After receiving a transaction, a node can verify whether the transaction is valid by checking (1) whether the inputs are unspent and (2) whether the sum of the outputs is less than the sum of the inputs. The node can add the valid transaction to the next data block that they accept.

[0292] Figure 9 A flowchart showing a consensus phase according to an embodiment of the present invention is shown. The method shown is described in the context of reaching a consensus on a transaction. Figure 9 However, it should be understood that embodiments of the present invention can be applied to other situations. Although the above steps are shown in a specific order, it should be understood that embodiments of the present invention can include methods having steps in a different order. Additionally, steps can be omitted or added, and they can still be within embodiments of the present invention.

[0293] The method according to an embodiment of the present invention can partition transactions based on their transaction IDs in a committee, and the committee can store the transaction outputs in a UTXO database at each node. In some embodiments, the transaction ID can be an interaction ID. Each committee can store transactions that have the committee ID as a prefix in the transaction ID. In some embodiments, different committees can be involved in verifying whether a transaction Tran is valid and then adding it to the shard of the committee.

[0294] There can be two types of committees. The first type of committee can be a source committee that can store the UTXOs related to the Tran input. The second type of committee can be a validator committee that can verify whether the transaction Tran is valid. The validator committee can also store the outputs (UTXOs) of the transaction. In some embodiments, these committees can be temporary roles, and each committee depends on whether the transaction can act as a source or as a validator in the protocol.

[0295] In some embodiments, the client computer may not attach a proof of its interactions submitted to the computer network. Instead, the client computer can communicate with any committee and send the interactions to a validator committee. In each round, the validator committee can merge the interactions that use UTXOs belonging to the same source committee into batches and can send a single UTXO request to the source committee. The source committee can check the validity of each UTXO. Then, the source committee can send the results of the batches to the validator committee. Since multiple UTXO requests are batched into the same request, results can be generated for multiple requests at the validator committee.

[0296] At step S900, a first node in the committee can receive an interaction request that includes interaction data from a client computer. In some embodiments, the interaction data associated with the interaction can be related to a transaction, such as transferring a digital asset from one party to another. For example, the interaction data can involve transferring twenty dollars from the client computer to another client computer.

[0297] At step S910, the first node can incorporate the interaction data, as well as other interaction data associated with other client computers, into an interaction data block. For example, the first node can receive interaction data from a number of client computers, where the interaction data is associated with a number of different interactions. For example, the interaction data can include the transaction volume and unspent transaction outputs (UTXOs) (i.e., block parts). In some embodiments, the first node can generate a list of all block parts to be verified. For example, the first node can generate a list of block parts that includes a first UTXO corresponding to the first interaction data, a second UTXO corresponding to the second interaction data, and a third UTXO corresponding to the third interaction data. The list of block parts can include the block parts to be verified.

[0298] At step S920, after incorporating the interaction data into the interaction data block, the first node can broadcast the interaction data block to other nodes in the committee, where the other nodes in the committee can verify the block. In some embodiments, the first node can receive other blocks from other nodes in the committee, where the other blocks include other interaction data.

[0299] At step S930, other nodes in the committee can verify the block. The other nodes can use any suitable method described herein to verify the block. For example, a node can verify the block by determining whether the input is valid. A node can determine whether the input (e.g., UTXO) corresponds to a previously verified interaction. A node can also determine whether the sum of the outputs is less than the sum of the inputs. If the sum of the outputs is less than the sum of the inputs, the node can verify the block. If other nodes in the committee verify the block, the process can proceed to step S940. However, if other nodes in the committee cannot verify the block, the process can proceed to step S950.

[0300] At step S940, if other nodes in the committee can verify the block, the other nodes and the first node can incorporate the block into the blockchain (i.e., shard) managed by the committee. The first node can incorporate the block into a shard of the blockchain. In some embodiments, the leader node of the committee can incorporate the block into a shard of the blockchain. Step S940 can correspond to the case where the source committee and the verifier committee can be the same committee, and each node in the committee can verify the interaction locally.

[0301] At step S950, if other nodes in the committee cannot verify the data block, the first node can contact another committee to verify the data block. In other embodiments, the leader node of the verifier committee can contact another committee, which can be the source committee, to verify the data block. The method according to an embodiment of the present invention can facilitate communication between the source committee and the verifier committee. The verifier committee can determine which committee is the source committee. In some embodiments, the verifier committee can determine the source committee based on the interaction ID. The first n bits of the interaction ID can correspond to the source committee. For example, the beginning of the interaction ID associated with the interaction to be verified can be 0x011, which can correspond to the third committee. As another example, each interaction including an interaction ID starting with 0x111 can be associated with the seventh source committee. The remaining bits of the interaction ID can include any suitable characters.

[0302] At step S960, the source committee can check the validity of each UTXO. The source committee can use any suitable method described herein to check the validity of each UTXO. After checking the validity of each UTXO, the source committee can send a verification message including the result to the verifier committee. Since multiple UTXO requests can be batched into the same request, the source committee can generate results for multiple requests (i.e., multiple interactions).

[0303] At step S970, if the nodes in the source committee cannot verify each UTXO, the validator committee may receive a verification message indicating that the block was not verified by the source committee. Then, the validator committee may decide not to store the block in the shard of the blockchain. In some embodiments, the client computer that submitted the interaction to the validator committee may resubmit the interaction at a future time.

[0304] At step S980, if the nodes in the source committee verify each UTXO, the validator committee may receive a verification message indicating that the block was verified by the source committee. At step S990, after receiving the verification message indicating that the block was verified, the nodes in the validator committee may incorporate the block into the blockchain managed by the validator committee. In some embodiments, the first node may incorporate the block into the shard of the blockchain.

[0305] In some embodiments, after step S980, the first node may transmit the output UTXO of the interaction to the client computer and may indicate that the interaction is stored in the shard of the blockchain.

[0306] The consensus phase may provide the following advantages: 1) there is one communication between committees for each transaction; 2) there is no locking, so the client computer may not lose interaction data even if it is offline; 3) there is no distributed denial of service (DDOS) attack; 4) the committees may batch process all submitted interactions and require one large interaction to make the process proceed faster.

[0307] Figure 10 A flowchart showing a verification process according to an embodiment of the present invention. Figure 10 Includes client computer 1010 and validator committee 1020 including nodes 1024 and blockchain shard 1022. Figure 10 Also includes source committees 1030 to 1050.

[0308] Client computer 1010 may submit a transaction including transaction data to validator committee 1020. After receiving the transaction, validator committee 1020 may include the transaction in a block including multiple transactions. Validator committee 1020 may determine whether the block is valid. If validator committee 1020 determines that the block is valid, validator committee 1020 may store the block in blockchain shard 1022.

[0309] If the validator committee 1020 cannot determine that the block is valid, the validator committee 1020 may determine the source committee 1030 among the multiple source committees 1030 to 1050 associated with the transactions in the data block (e.g., using a transaction identifier). In some embodiments, the validator committee 1020 may determine that the source committee 1030 is associated with a UTXO (which is an input of the transaction received from the client computer 1010). The validator committee 1020 may contact the source committee 1030 to request that the source committee 1030 verify the data block. After receiving the data block from the validator committee 1020, the source committee 1030 may determine whether the block is valid. If the source committee 1030 determines that the block is valid, the source committee 1030 may transmit a verification response to the validator committee 1020. If the verification response indicates that the block is valid, the validator committee 1020 may store the block in the blockchain shard 1022.

[0310] The following Protocol 5 describes an example consensus protocol as described herein. The consensus protocol may allow a computer network including committees of nodes to reach an agreement on an interaction block and store the interaction block in a shard of the blockchain.

[0311] Protocol 5: Consensus

[0312] 1. After receiving a message from the client computer, accept a new transaction from the client computer.

[0313] 2. Reach an agreement on the block

[0314] (a) Place all transactions on a proposed data block.

[0315] (b) Reliably broadcast the proposed data block to all nodes in the committee.

[0316] (c) Receive the proposed data block from all nodes in the committee and merge the proposed data blocks.

[0317] 3. Verify UTXO

[0318] (a) Create a list of all UTXOs that need to be verified.

[0319] (b) If the committee can verify the UTXO locally, verify the UTXO, otherwise contact the source committee for verification.

[0320] (c) If the committee receives a request for UTXO verification from another committee, answer "yes" if unspent, otherwise answer "no".

[0321] Routing Protocol

[0322] Currently in Ethereum, transaction broadcasting occurs in the global P2P network through a gossip protocol, where each node forwards the transactions it receives to its peer nodes (i.e., neighboring nodes). Thus, as long as the network is a connected graph, every sent transaction can eventually reach all nodes in the network. In a sharded blockchain, such global broadcasting is wasteful because transactions are only meaningful to a few committees. Nodes can only forward newly created transaction outputs to the committee responsible for the output. The method according to an embodiment of the present invention can provide a routing scheme that enables a user to quickly find out which committee a node should send its output to.

[0323] First, a strawman routing scheme can be discussed. One approach could be that each node can store information about all committees in the computer network (such as IP addresses, etc.). Thus, each node can quickly find the IP addresses of the committee members to which a user should send its transaction. The advantage of this solution is that it allows each user to determine the expected committee for a transaction in constant time. However, it requires O(n) storage at each node to store information about all committees. Additionally, each committee member would broadcast any changes in its committee membership to everyone in the network, which would result in a large overhead of message broadcasting in each period. This solution cannot scale to thousands of nodes in the network.

[0324] A different solution could be to have a dedicated committee C router that can track changes in committee membership and be responsible for transaction routing. Each user can obtain information from C router about the nodes currently in the committee that should process the transaction. This method provides efficient routing and only requires one communication round. However, C router becomes the central hub of the network that needs to handle a large amount of communication and is thus a possible bottleneck and potential target for DoS attacks.

[0325] Next, the routing overlay network can be discussed. In Kademlia, each node in the system is assigned an identifier, and there is a distance between the identifiers (e.g., the Hamming distance of the identifiers). A node stores information about all nodes within a logarithmic distance from itself. When a node wants to send a message to another node in the system, it identifies the node (closest to the destination node ID) among its neighboring nodes (stored locally) and asks it to recursively run the discovery mechanism. This enables node discovery and message routing in log n steps. See also [Petar Maymounkov and David Mazieres, Kademlia: A Peer-to-Peer Information System Based on the XOR Metric. In Revised Papers from the First International Workshop on Peer-to-Peer Systems, IPTPS'01, pages 53 to 65, London, UK, 2002, Springer-Verlag] for more details on the Kademlia routing protocol.

[0326] The method according to an embodiment of the present invention can employ a routing mechanism at two levels: First, at the level of communication between committees, which forms the basis of the protocol and prevents interference caused by malicious nodes, since each committee can have a vast majority of honest parties. The second conceptual layer in the routing protocol can be the communication between nodes, which can be used to implement message sending between committees. Specifically, each committee can maintain a routing table of log n records pointing to log n different committees, which are at a distance of 2 i (i.e., Hamming distance 1) for 0 ≤ i ≤ log n - 1.

[0327] Figure 11 A flowchart showing communication routing according to an embodiment of the present invention is shown. Figure 11 Includes a plurality of committees: C 0 1101, C 1 1102, C 2 1103, C 3 1104, C 4 1105, C 5 1106, C 6 1107 and C 7 1108. Each committee can be associated with a committee ID. For example, C 0 1101 can be associated with the committee ID 0x000. For example, C 1 1102 can be associated with the committee ID 0x001, C 2 1103 can be associated with the committee ID 0x010, C 3 1104 can be associated with the committee ID 0x011, C 41105 can be associated with committee ID 0x100, C 5 1106 can be associated with committee ID 0x101, C 6 1107 can be associated with committee ID 0x110, and C 7 1108 can be associated with committee ID 0x111. A committee can be associated with any suitable committee ID.

[0328] Each committee in a computer network can maintain a routing table containing log n other committees. Each committee can store a non - contiguous subset of transaction outputs, and the IDs of those outputs can have a fixed log n - bit prefix. This log n - common prefix in the transaction outputs can also be equal to the committee ID. In some embodiments, the first n bits of a transaction output can be the committee ID of the committee associated with those transaction outputs. Nodes in a committee can store a routing table containing information about log n other committees instead of storing a routing table including information about every other committee in the computer network. Each node does not have to store a larger routing table, thus reducing the memory used.

[0329] C 0 1101 can store the following routing table: including information about communication with C 1 1102, C 2 1103, and C 4 1105. Committee C 0 1101 can communicate with nodes having committee IDs that are 2 n committees away (i.e., 2 0 、2 1 and 2 2 ).

[0330] In some embodiments, C 0 1101 may need to communicate with C 7 1108 regarding an interaction. C 0 1101 can determine to transfer a data block including the interaction to C 4 1105 because it has the committee ID (0x100) that is closest to the committee ID (0x111) of C 0 1101 known to C 7 1108. After receiving the data block, C 4 1105 can determine the committee ID in its routing table that is closest to the final destination of the data block (i.e., C 7 1108). C 4 1105 can transfer the data block to C 61107, which can transfer data blocks to C 7 1108.

[0331] In addition, at the node-to-node level, the individual ID (i.e., node identifier) of each node can start with the committee ID. In some embodiments, each pair of nodes in a committee can be very close to each other (e.g., log(log(n)) distance), and can propagate messages within a committee without passing through another committee. More specifically, each node can store information about all nodes in its committee and about log(log(n)) nodes in each of the log n committees closest to the node's own committee. Messages between each committee can be implemented by all nodes in the sender committee sending the message to all nodes known to be in the receiver committee. Each node receiving the message can use reliable broadcast [Gabriel Bracha and Sam Toueg, Asynchronous Consensus and Broadcast Protocols, Journal of the ACM (JACM), 32(4): 824 - 840, 1985] to send the message to all other nodes in its committee.

[0332] When the client computer requests to add a transaction with a transaction identity ID tx the client computer can first find the committee C responsible for recording the transaction according to the sharding rules described herein tx . The client computer can use the discovery and routing mechanism to find C tx and send its message to committee C tx . Figure 12 A flowchart showing communication response routing according to an embodiment of the present invention. Figure 12 Includes an instance of a routing protocol initiated by committee C 0 to request information about committee C 7 . Figure 12 Includes multiple committees: C 0 1201, C 1 1202, C 2 1203, C 3 1204, C 4 1205, C 5 1206, C 6 1207 and C 7 1208.

[0333] Figure 12 Shows an example of a communication diagram when committee C 0 1201 locates committee C 7 1208, and the committee 1208 can be responsible for all transactions prefixed with 0x111, as aboveFigure 11 as described. C 0 1201 can first communicate with C 4 1205, which may be the closest to C 0 in the routing table of 1201 7 to the committee of 1208. C 4 1205 can communicate with C 6 1207, which may be the closest to C 4 in the routing table of 1205 7 to the committee of 1208 to seek communication information from C 7 1208, such as data block verification. Since C 6 1207 can communicate directly with C 7 1208, C 6 1207 can then relay back C 7 1208 to C 4 the membership list and addresses of 1205, since in some embodiments, a committee may store information about nodes in neighboring committees, such as addresses. Then, C 4 1205 can forward the communication information (e.g., data block verification results) to C 0 1201.

[0334] In some embodiments, nodes in a computer network may perform a setup phase, a reconfiguration phase, and then a consensus phase in any suitable manner as described herein. For example, a first node in a computer network may determine a leadership committee that includes a plurality of selected nodes including the first node. The leadership committee may be the first committee. The first node may receive a request from a second node to join a committee of the computer network. The request may include a node identifier. Then, the first node may determine that the second node may join a second committee based on a proof-of-work process computed by the second node. The first node may introduce the second node to the second committee, where the second committee shifts nodes to allow the second node to join the second committee, and information about the second node being in the second committee is communicated to other nodes in the computer network. Then, the first node may receive an interaction request that includes interaction data from a client computer. The first node may incorporate the interaction data and other interaction data associated with other client computers into a data block that includes the interaction data, where the block includes block portions. Then, the first node may broadcast the data block to other nodes in the committee, where the other nodes in the committee verify the block. The first node may incorporate the block into a shard of a blockchain managed by the first committee.

[0335] Evaluate

[0336] In this section, the scalability of the method according to embodiments of the present invention can be evaluated, as well as a comparison of the method with shard-based protocols, such as Elastico [Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena, Secure Sharding Protocols for Open Blockchains. In the Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pages 17 to 30, New York, NY, USA, 2016, ACM] and OmniLedger [Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford, OmniLedger: A Secure, Scalable, Decentralized Ledger via Sharding, Cryptology ePrint Archive, Report 2017 / 406, 2017. https: / / eprint.iacr.org / 2017 / 406]. In some embodiments, Bracha's reliable broadcast protocol [Gabriel Bracha, Asynchronous Byzantine Agreement Protocols, Information and Computation, 75(2): 130 to 143, November 1987] can be implemented using the Reed-Solomon erasure coding library [Ongoing Reed-Solomon erasure coding, May 2017, available at https: / / github.com / klauspost / reedsolomon].

[0337] By oversubscribing a set of 32 machines each running up to 125 instances, a network with up to 4,000 nodes is simulated. Each machine is equipped with an Intel Xeon Phi 7210 at 1.3 GHz with 64 cores and a 10 Gbps communication link. To simulate Internet latency, consider a 100 millisecond latency per message and a 20 Mbps bandwidth per node. This can geographically simulate distributed nodes around the world. Unless otherwise stated, the numbers reported in this section may apply to the case where all nodes act honestly. A period of the method according to an embodiment of the present invention can be executed, and the cost of each component of the protocol can be evaluated separately. These components can be independently used in other protocols. The consensus latency can be measured in seconds, the number of transactions committed per second, and the number of messages to the steering committee in the first exchange. Similar to the cryptocurrency core above, each node in the global P2P network can accept up to 8 outgoing connections and up to 125 incoming connections. However, any suitable number of outgoing and incoming connections can be used. The global P2P overlay can be used during the bootstrapping phase. During the consensus phase, nodes communicate through a much smaller P2P overlay created within each committee, where each node accepts up to 16 outgoing connections and up to 125 incoming connections.

[0338] During the evaluation, to obtain the number of synchronous rounds for consensus within the committee, Δ can be set to 600 ms based on the longest time to propagate an 80-byte digest to all nodes in a P2P network with 250 nodes, as Figure 28 shown. Remember that synchronous rounds are only required during Ren et al.'s consensus protocol to agree on the hash of a data block, resulting in a message of up to 80 bytes in size including signatures and control bits.

[0339] Each transaction data block can consist of 4,096 transactions, where each transaction consists of 512 bytes, resulting in a data block size of 2 MB. To implement this IDA-based rumor protocol within the committee to spread a 2 MB data block, each data block can be divided into 128 information blocks and the Jerasure library [Jerasure: Erasure Coding Library (May 2018), available at http: / / jerasure.org] can be used to encode the messages, using Reed-Solomon codes [Irving Reed and Gustave Solomon, 1960, Polynomial Codes Over Certain Finite Fields, Journal of the Society for Industrial and Applied Mathematics (SIAM) (1960), 300 to 304] and the decoding algorithm of Berlekamp and Welch [e Berlekamp and L Welch, Error Correction of Algebraic Block Codes, U.S. Patent 4,633,470 (December 30, 1986)].

[0340] Figure 13 A diagram showing the communication in the setup phase according to an embodiment of the present invention. Figure 13 A diagram including the improved message count 1302, the original message count 1304, the improved bandwidth 1306, and the original bandwidth 1308. When there are 5000 parties (i.e., nodes), the original message count 1304 is approximately 3.25*10 9 messages, while the improved message count 1302 is approximately 2.5*10 9 messages. In addition, with 5000 nodes, the original bandwidth 1308 is approximately 1900MB, while the improved bandwidth 1306 is approximately 1600MB.

[0341] Figure 14 A diagram showing the setup phase delay according to an embodiment of the present invention. Figure 13 and Figure 14 It also shows the improvement in setup runtime due to better analysis of the required size of the committee, which can save approximately 20% of the runtime and bandwidth, while the setup delay can be significant (e.g., approximately 20 hours for 5000 nodes). Nodes can run this protocol once, and the cost can be amortized during the adjustment and consensus periods. In contrast, the Elastico protocol assumes a trusted setup and does not present any corresponding measurements.

[0342] Next, the consensus overhead can be discussed. Figure 15 A diagram showing the transaction cost according to an embodiment of the present invention. Figure 16 A diagram showing the transaction delay according to an embodiment of the present invention. Figure 17 A diagram showing the transaction delay in the case of variable committee size according to an embodiment of the present invention. Figure 18 A diagram showing the transaction cost in the case of variable committee size according to an embodiment of the present invention.

[0343] Since there can be multiple shards, more than one transaction data block can be processed simultaneously. Specifically, one data block is processed for each committee. For experiments with different committee sizes n, the number of committees can be set to n / 100. For example, for a committee size of 100 and a network size of 5000, the computer network can process 50 transaction data blocks in parallel. For measurements with different committee sizes, the total number of nodes can be set to 1000. Both the latency and the message cost can be sub-linear with respect to the network size, indicating that embodiments of the present invention can scale to a large number of parties. Compared to Elastico [Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena, Secure Sharding Protocols for Open Blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, pages 17–30, New York, NY, USA, 2016, ACM], embodiments of the present invention can perform better with respect to latency. For example, embodiments of the present invention can improve the latency by about 0.7 times. As an example in a network with 2,000 nodes, Elastico takes about 460 seconds to propagate four data blocks, while the latency of embodiments of the present invention can be approximately 315 seconds in a network of a similar size.

[0344] Figure 19 A graph showing the number of messages per number of nodes according to an embodiment of the present invention. Figure 20 A graph showing the bandwidth versus the number of nodes according to an embodiment of the present invention. Figure 21 A graph showing the latency versus the number of nodes according to an embodiment of the present invention.

[0345] The bandwidth overhead during the OmniLedger epoch was estimated using the following numbers, reported in [Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford, OmniLedger: A Secure, Scalable, Decentralized Ledger via Sharding, Cryptology ePrint Archive, Report 2017 / 406, 2017. https: / / eprint.iacr.org / 2017 / 406]: a total of 1,800 nodes, a transaction size of 500B, a throughput of 3,500 tx / sec, and a probability of 3.7% of transactions within a shard. Since OmniLedger requires at least three calls to all parties for each cross-shard transaction, the bandwidth required per node is at least: 3,500 × 0.967 × 500B × 3 ≈ 45 Mbps. For n = 1600, m = 16, and 1MB data blocks, the reported transaction confirmation latency of 800 seconds can be used to estimate the throughput of Elastico. Assuming 500B / tx, the throughput of Elastico can be calculated as 16 * 2000 / 800 = 40 tx / sec.

[0346] Next, the reconfiguration overhead can be discussed. Figure 22 A graph showing the cost of handling changes according to an embodiment of the present invention. Figure 22 A graph of the number of messages versus the number of nodes when adding one new node 2202, five new nodes 2204, and ten new nodes 2206 during the reconfiguration phase. Figure 23 A graph showing the change latency according to an embodiment of the present invention. To measure the impact of changes in an embodiment of the present invention, the number of messages transmitted to add one party 2302, five parties 2304, or ten parties 2306 to each committee can be measured when the network size may change. As Figure 22 and 23 shown, the number of messages grows approximately linearly with the size of the network and the number of parties changing. Since changes to different parties and different committees occur in parallel, a higher change rate can also increase latency, but far less than previous systems and methods. Since the parties in the corresponding committee can handle the changes, the network size may not affect the latency of handling changes. In some embodiments, a new node may attempt to join the computer network, but if the new node attempts to join in the middle of an epoch, the join request may not be accepted, and then the new node can transmit another join request at the end of the epoch. This process may be affected by the randomness selected for the changes and may result in a small peak in latency for 300 nodes. The Elastico protocol cannot handle changes incrementally and requires re-initialization of all committees.

[0347] Since the embodiments of the present invention can shard the blockchain, the storage amount of each party can be equal to the (1 / # of the committee) fraction of the total ledger size. In a network with 5,000 nodes and 50 committees, each node can store approximately 6MB after proposing 1,000 data blocks of size 1MB to the network. In contrast, both Elastico and Byzcoin require each participating node to store approximately 270MB of data after 1,000 data blocks. Therefore, each node according to the embodiments of the present invention can store approximately 45 times less data. This can be an advantage of the embodiments of the present invention over existing blockchain protocols.

[0348] Figure 24 A graph showing the failure probability according to an embodiment of the present invention is shown. For a committee size of 20 to 220 nodes, the failure probability shown as 1 / 3 to 1 / 2 2402 in the embodiments of the present invention can be lower than previous work (i.e., 1 / 4 to 1 / 3).

[0349] Figure 25 A graph showing the latency and committee size according to an embodiment of the present invention is shown. Figure 25 Including maximum latency 2502, average latency 2504, and median latency 2506. Figure 26 A graph showing the user-perceived latency and the number of nodes according to an embodiment of the present invention is shown. Figure 26 Including user-perceived latency 2602 and confirmation latency 2604. The latency for processing a transaction can be measured using two metrics: confirmation latency and user-perceived latency. The former measures the latency between the time when a transaction is included in a data block of a transaction until the time when the data block is added to the ledger, such that the existence of the data block on the ledger can be confirmed by any (honest) node in the computer network. In contrast, the user-perceived latency measures the latency between the time when a user (i.e., a client computer) sends a transaction tx to the computer network until the time when tx can be confirmed by any (honest) node in the system.

[0350] Figure 26Shows the latency values measured for various network sizes. The user-perceived latency 2602 only increased by 2.8 seconds as the number of nodes in the computer network increased from 1000 nodes to 4000 nodes. The small increase in user-perceived latency 2602 allows users of client computers to receive confirmations in a similar amount of time as the computer network size grows. Although the client-perceived latency is approximately 8 times more than the confirmation latency, the two latencies are still approximately the same for networks larger than 1,000 nodes. In contrast, for networks of sizes 1,600 and 1,800 nodes respectively, Elastico and OmniLedger report confirmation latencies of approximately 800 seconds and 63 seconds. For network sizes between 1,500 and 2,000, the confirmation latency of embodiments of the present invention is from 8.64 to 8.72 seconds.

[0351] Next, throughput scalability can be discussed. Figure 27 Shows a graph of transactions per second versus committee size according to an embodiment of the present invention. For variable committee sizes, as the network size increases from 500 nodes to 4,000 nodes, the number of transactions processed per second by the method according to an embodiment of the present invention can be measured to evaluate the impact of sharding, such that the failure probability for each epoch remains less than 2*10 -6 (i.e., failure time of more than 1,300 years). For a network size of 4,000, a committee size of 250 can be considered, which results in a failure probability in one epoch of less than 6*10 -7 (i.e., failure time of more than 4,586 years). As Figure 27 shown, doubling the network size increases the capacity of embodiments of the present invention by 1.5 to 1.7 times. Unfortunately, none of the previous sharding-based protocols report throughput scalability with network size - an important measure of how well a system can scale its processing power using its main resource (the number of participants).

[0352] Next, block size can be discussed. Figure 28 Shows a graph of transactions per second versus data block size according to an embodiment of the present invention. Figure 28 Includes the throughput 2802 and latency 2804 of the computer network at data block sizes from 128 KB to 8192 KB. The throughput and latency of the method according to an embodiment of the present invention can be measured for a computer network including 4,000 nodes using various block sizes between 512 KB and 8,192 KB. As Figure 28As shown, a larger block size generally results in higher throughput and higher confirmation latency. To achieve a latency of less than 10 seconds, which is common in most mainstream payment systems, while achieving the highest possible throughput, embodiments of the present invention can use a block size of 2,048 KB, which results in a throughput of over 7,000 tx / second and a latency of approximately 8.7 seconds.

[0353] Conclusion

[0354] The new highly scalable consensus protocol can provide open membership and a distributed public ledger. Transaction latency can be improved by using a distributed ledger design that partitions the blockchain across multiple shard committees. Embodiments of the present invention can use an efficient setup protocol to establish honest shard committees and also employ new analytics for optimization. The method according to embodiments of the present invention can handle changes and cause minimal changes in the number of committee members without affecting transaction latency. Embodiments of the present invention are also characterized by some improved atomic broadcast and network routing protocols. Finally, empirical evaluations show that the method according to embodiments of the present invention can scale smoothly to a network size of 5,000 nodes and can exhibit better performance than existing systems such as Elastico.

[0355] Embodiments of the present invention have many advantages. For example, embodiments allow the blockchain to be sharded among multiple node committees. Each node committee can store a different partition of the blockchain, thus greatly reducing the amount of data stored on each node compared to previous systems and methods.

[0356] In addition, the committee can verify blocks including interactions and store the blocks in the committee partition of the blockchain. The committee does not need to broadcast data blocks to every node in the computer network and then have every node in the computer network verify the data blocks, as in previous systems and methods. Therefore, embodiments of the present invention can determine whether data blocks are valid with less communication compared to previous systems and methods.

[0357] In addition, embodiments of the present invention handle higher throughput, compared to previous systems such as Elastico and OmniLedger. Embodiments of the present invention also provide smaller latency, smaller storage at each node, and longer failure times (see Table 2 above) when the network size is larger than previous methods.

[0358] Embodiments of the present invention provide additional advantages. For example, embodiments of the present invention allow new nodes to join the computer network without reconfiguring every node in the computer network, as in previous systems and methods. Therefore, embodiments of the present invention provide a way to reconfigure several nodes among several committees while preventing malicious reception, such as a Sybil attack.

[0359] More details

[0360] Atomic broadcast

[0361] In this section, the sparsification process described in this paper can be discussed. Sparsification may not change the correctness and security of the atomic broadcast protocol. n may be the number of data blocks or leaf nodes in the Merkle tree and t may be the fraction of dishonest nodes. If there may exist nodes in the tree where the hash on the node is only assigned to the corrupted parties, the reconstruction phase may fail. If the hash T(M i , M j ) and all leaves that require the hash for data block verification are not sent, the tree nodes can be sparsified. All nodes up to a certain level i can be sparsified. s, which can be the size of the subset of parties that can be sent to each allowed sparse node, can be calculated using the probability that the node can be sent to at least one honest party of at least 2 -c . Let l(x) count the number of leaf nodes in the subtree rooted at node x, and u(x) count the number of corrupted nodes in the subtree rooted at node x.

[0362] The intermediate nodes can be assigned to the parties in two ways. The first method, which may have a simpler analysis, can randomly select s parties from the entire set of parties to send each leaf node to. The second method can be that the parties to which each intermediate node is sent can be a subset of the parties that have sent the node in the normal atomic broadcast protocol.

[0363] First, the case where the intermediate nodes can be assigned to any party can be discussed. If the nodes can be randomly assigned to s parties, the highest probability that only the corrupted parties receive the nodes can be ts. Therefore, taking a joint constraint on all 2 i+1 - 1 sent nodes,

[0364] (2 i+1 - 1)t s < 2 i+1 t s ≤ 2 -c

[0365] (i + 1)ln2 + slnt ≤ -cln2

[0366]

[0367] Consider the case where the intermediate nodes can be assigned to the parties that may have received the nodes in the normal broadcast. If the subtree has more than s leaves, a given node can be sparsified. The subtree rooted at level i can have at least leaves, so 。For node x, l(x) > s, without replacing all possible parties, the assignment of parties to the leaves in the subtree can be regarded as sampling. For any single randomly selected party, the highest probability that the party is corrupted can be t. Therefore, by Hoeffding's inequality, for δ ≥ 0,

[0368]

[0369] Next, the number of corrupted nodes in the subtree can be constrained at level i. Specifically, for j < i, x and y are siblings at level j + 1, and z is their parent at level j. The leaves of z can be the union of the leaves of x and the leaves of y. Given that u(x) / l(x) < α and u(y) / l(y) < α. Then, (u(x) + u(y)) / (l(x) + l(y)) ≤ α. If the proportion of corrupted nodes in all subtrees rooted at level i is constrained, then the constraint can be applied inductively to all subtrees rooted at levels i - 1,..., 1. There are 2 i subtrees rooted at level i, so

[0370]

[0371] Another failure cause can be whether all s nodes sampled from a single subtree are all corrupted nodes. Given that the highest proportion of corrupted nodes in any subtree can be t + δ, taking a joint constraint on all 2 i+1 -1 sparse nodes can give a given probability for any node that the highest probability that all parties sampled for the node are corrupted is (2 i+1 -1)(δ + t) s .

[0372] Therefore, in the case of taking a joint constraint on two failure causes, the highest probability that the honest sender broadcasts a failure can be

[0373] First, δ can be chosen as a function of t to minimize the above expression. 2 i can be independent of δ and t. Minimizing the expression can be equivalent to minimizing its logarithm. Therefore, it may be equivalent to minimizing -2sδ 2 + sln(2(δ + t)). Factoring out s, it can be to minimize -2δ 2 + ln(2(δ + t)). Since t can be a fixed parameter, taking the derivative with respect to δ and setting it to zero may result in and thus result in -4δ 2 - 4fδ + 1 = 0, which can have a solution at In some embodiments, δ < 0 can be removed. This case can be checked to determine whether it is a minimum, since Return to the overall expression and solve for the value of s:

[0374]

[0375] -2sδ 2 +ln2 + sln(δ + t) ≤ (-c - i)ln2

[0376] s(2δ 2 -ln(δ + t)) ≥ (c + i + 1)ln2

[0377]

[0378] Given t, i, and c, a solution for the value of s can be determined. This scenario may include values of s greater than in the case where any party can receive intermediate nodes. The advantage of restricting the intermediate nodes that can be sent by the parties (which may have sent intermediate nodes already) is that there may be fewer computations and a smaller memory cost. When any party can send any intermediate node, the corrupted parties can make hashes for any nodes that may be thinned. Although the hashes may not end up in the final Merkle tree, the reconstructor can still consider the hashes. If i is the maximum layer of thinning, the memory usage can be and the computational cost of reconstruction can be If the parties are restricted in the intermediate nodes they can send, the parties can send at most hashes that can be considered. The memory usage can be since each party can send one candidate for each layer. The computational cost can be

[0379]

[0380] By summing over the rows and considering the number of intermediate nodes in each row and the number of possible candidates, reconstruction can be performed. This can be simplified to

[0381]

[0382] So far, this may not be the optimal value of i for minimizing communication. The solution for optimizing i may not have a closed form, such as it can be

[0383] s(2 (i+1) -1) + (log 2 n - i)n

[0384] This can be the total number of hashes that the sender can send. The derivative of the previous expression with respect to i may be

[0385]

[0386] Since s may be a linear function of i, ds / di can be constant given a strategy for allocating intermediate hashes. However, the previous expression also tells us that sparsification may not provide a better asymptotic bound. If n is multiplied by 2 (thereby increasing the depth of the tree by one), then i can increase by less than 1 for the above expression to remain 0, since s2 i+1 = Θ(i2 i ). Thus, the optimal number of sparse layers can be sub-linear in the depth of the tree. Thus, the number of hashes sent at each level in the Merkle tree can be equal. Since the number of sparse layers can be sub-linear in the depth of the tree, the communication cost can be gradually dominated by the hashes in the non-sparse levels closer to the leaves in the tree.

[0387] Restricted Cuckoo Rule

[0388] In this section, an adjustment protocol according to an embodiment of the present invention that may maintain the balance and honesty properties of a committee in a computer network can be discussed.

[0389] This section may describe modifications to the proofs associated with the Cuckoo Rule and thus may use similar assumptions and terms. Parties can join and leave in turn in each round. At any time during the protocol, the fraction of dishonest parties relative to honest parties can be equal to ε. The protocol may start from a stable state where n parties partitioned into m committees can satisfy the balance and honesty conditions.

[0390] The system can first randomly map the parties to a point in [0, 1) using a hash function to map the parties to committees. Then, the range [0, 1) can be partitioned into k regions of size k / n and the committees can be groups of parties that can be assigned to clog n k-regions for c and k. When a new party joins the computer network, the party can be called the new party while the party is in a committee. At any time after that, even if the party changes committees, the party can be called the old party. The age of a k-region can be the amount of time that has passed since a new party has been placed in the k-region. The committee age can be the sum of the ages of the k-regions. Additionally, recall that a set of active committees can be m / 2 committees with the highest number of nodes among them.

[0391] For any fixed active committee C and at any time, the age of any active committee C can be with high probability within .

[0392] yi can be the age of the k-region called Ri and It can be the age of C. In some embodiments, at any point in time during the protocol, half of the committee can be active, so the area available for a new party can be determined by half of the k - regions. Thus, it can be distributed in a geometric form with probability . Thus, and Y can be concentrated around E[Y], meaning Y can be between (1 ± δ)E[Y].

[0393] Next, the maximum age of the k - regions in the active committee can be discussed. The age of any k - region in the active committee can be at most λ(n / 2k)logn. The k - region R i can be reclaimed with probability 2k / n in any round because, in a given round, there can be m / 2 active committees. Thus, half of the k - regions can accept new additions (i.e., new nodes). If the committee does not become inactive during this period, the probability can be independent of other rounds. Note that this situation can consider the worst - case scenario because the committee may become inactive during this period. Thus, R i has a probability of at least λ(n / 2k)logn of being at least (1 - 2k / n) λ(n / k)logn ≤e -2k / nλ(n / 2k)logn = n -λ .

[0394] In some embodiments, any fixed party v in the active committee can be shifted at most (1 + δ)λlogn times within λ(n / 2k)logn rounds. The party can be placed in the active committee with probability 1 / 2. After a new party joins the committee, half of the committee can be considered the active committee. This situation can be the worst - case scenario where half of the inactive committee can have nearly as many active parties in the next round. For example, if the active committee includes 50 nodes and the inactive committee includes 49 nodes, the inactive committee can have nearly as many active parties in the next round. If the party p can be replaced by t, the indicator random variable can be z t = 1, otherwise, the indicator random variable can be 0. Because at any time, the computer network can randomly select a region to reclaim from all active regions. Let where Using the Chernoff bound, with high probability Z < (1 + δ)E[Z].

[0395] t may be the number of parties that are dishonest at any time in the system. At any time, with high probability, the fixed committee can have within (1 - t / n)(1 ± δ)clognk / 2 old honest parties and old dishonest parties. In some embodiments, at any suitable time during the protocols described herein, all committees can satisfy the balance and honesty conditions. Next, the balance and honesty properties of a committee can be discussed, but the balance and honesty properties may apply to any number of committees.

[0396] The number of new parties in each committee can be at most clogn. The number of old parties is as shown above. In some embodiments, the maximum number of parties in each committee can be and the minimum load can be c / 2(1 - δ)logn.

[0397] For an honest committee, k can be determined such that any committee can have with high probability (1 - t / n)(1 - δ)clognk / 2 honest parties and dishonest parties. Note that these values can be for the worst - case scenario, where the adversary may target committees of size (clogn)k / n.

[0398] Expander

[0399] In this section, the analysis of the parameters in the setup protocols described herein can be discussed. Consider two fixed subsets of nodes and Each node in L can represent one of the n parties and each node in R can represent a committee that can be selected based on the edges associated with the nodes from L. And, T can represent the maximum coalition of faulty parties, and S can represent a subset of committees. ε(T, S) represents the following event: where each node in S can have more than a fraction of the edges associated with the nodes in T.

[0400] N can represent the number of edges between T and S. The number of edges associated with S can be equal to d R |S|. By the linearity of expectation, In some embodiments, the edges associated with S can be added sequentially. {X i} can represent a sequence of random variables such that X i = 1 if the i - th edge may be associated with T. The sequence {Z i = [N|X 0 ,..., X i} can define a Doob martingale, where Z 0= [N]. If any trial is changed, N can change by at most one. For a positive δ, a failure event ε can occur when the following occurs:

[0401]

[0402] By the Azuma inequality,

[0403]

[0404] By the joint constraints on the possible subsets T and S,

[0405]

[0406] pi can be subject to and and replace Equation 1 in Equation 2. For example, for n = 5000, α 1 = 0.912, β 1 = 0.766, γ 1 = 0.1 and δ = 1 / 6, it may result in p 1 ≤ 2 -90 . This choice of parameters can generate a sampler graph at the first level of a selection graph with l levels, and R 1 = 2363, and |S 1 | = 788. It should be noted that can also represent the size of the committee in the first level of the selection network.

[0407] In a sampler graph where honest parties are randomly assigned and dishonest parties are assigned adversarially, the probability that the committee in any subset of size |R'| is corrupted may be less than

[0408] In some embodiments, the sampler graph selection process can be regarded as a classical balls-and-bins process: |L|d L balls (parties) can be randomly, independently, and uniformly thrown into |R| containers (committees). Without loss of generality, first throw all the dishonest parties (bad balls), and then all the honest parties (good balls).

[0409] For a fixed committee C, X g can be a random variable that can represent the number of dishonest parties assigned to C. X b can be a random variable that can represent the minimum number of honest parties assigned to C. μ g and μ b can be the expected number of honest and dishonest parties per committee, respectively.

[0410] The distribution of the number of (good / bad) balls in the container can be approximately a Poisson distribution, where the mean value and μ g = 3d L |L| / 4. May be a Poisson random variable, close to X, that is The following are the Chernoff bounds for Poisson random variables:

[0411] When x > μ (4)

[0412] When x < μ (5)

[0413] x can be a threshold. If X g > 2x and X b < x, then the committee can be determined to be a good committee. In some embodiments, a good committee may have twice as many honest parties as a bad committee. The definition may be underestimated and may not account for some good committees. According to this definition, if X g ≤ 2x or X b ≥ x, then the committee can be determined to be a bad committee.

[0414] The probability that a fixed committee can be determined to be a bad committee may be:

[0415]

[0416] In some embodiments, the size of a set of committees can be |R'|, and the probability that all committees in the set of committees can be determined to be bad committees may be

[0417] In some embodiments, the adversary can select bad parties and bad committees. In this case, to find the probability that all committees in any subset of size |R'| are corrupted, a joint bound can be imposed on all possible adversarial selections:

[0418]

[0419] In other embodiments, the probability that the adversary successfully performs all actions may be different. Thus, a strategy that may be worse than another strategy can be considered and, in some embodiments, removed from the joint constraints because it may not be beneficial for the adversary to select such a strategy. In some embodiments, the following process may occur: 1) the good parties can be randomly assigned to the committees; 2) the adversary can assign an α fraction of the bad parties to the committees such that the assignment may corrupt the maximum number of committees; and 3) the adversary may assign the remaining 1 - α bad parties such that each party can be assigned to at least one good committee. Another strategy that does not follow the previous process may be that it may not be a good choice for the adversary to assign a bad party to all the bad committees in step (3) because assigning a bad node to a committee that may already be bad does not increase the adversary's chance of corrupting a new committee.

[0420] The probability that the set of size |R′| after throwing all the good parties and an α fraction of the bad parties contains only bad committees may be

[0421]

[0422] The fraction of strategies that the adversary can ignore due to the rule in step three above:

[0423]

[0424] Thus, in some embodiments, this fraction can be removed from the joint constraints.

[0425]

[0426] Any software component or functionality described in this application can be implemented as software code to be executed by a processor using any suitable computer language such as Java, C, C++, C#, Objective-C, Swift, etc. or a scripting language such as Perl or Python, using conventional or object-oriented techniques. The software code can be stored on a computer-readable medium as a series of instructions or commands for storage and / or transmission, and suitable media include random access memory (RAM), read-only memory (ROM), magnetic media such as a hard disk drive or a floppy disk, or optical media such as a compact disc (CD) or a digital versatile disc (DVD), flash memory, etc. The computer-readable medium can be any combination of such storage or transmission devices.

[0427] Such programs can also be encoded and transmitted using carrier signals adapted to be transmitted via wired, optical, and / or wireless networks compliant with various protocols including the Internet. Thus, a computer-readable medium according to an embodiment of the present invention can be created using data signals encoded with such programs. A computer-readable medium encoded with program code can be encapsulated with a compatible device or provided separately from other devices (e.g., downloaded via the Internet). Any such computer-readable medium can reside on or within a single computer product (e.g., a hard disk drive, a CD, or an entire computer system), and can exist on or within different computer products within a system or network. A computer system can include a monitor, a printer, or other suitable display for presenting any of the results mentioned herein to a user.

[0428] The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art after reading this disclosure. Therefore, the scope of the invention should not be determined by reference to the above description, but should be determined with reference to the pending claims and their full scope or equivalents.

[0429] Without departing from the scope of the invention, one or more features of any embodiment can be combined with one or more features of any other embodiment.

[0430] As used herein, unless expressly indicated to the contrary, the use of “a / an” or “the” is intended to mean “at least one.”

Claims

1. A method for managing a committee of computer nodes, the method comprises: receiving, by a first node in a first committee in a computer network, a request comprising a node identifier to cause a second node to join the committee; providing, by the first node in the first committee, a proof-of-work process to the second node; receiving, by the first node in the first committee, a solution to the proof-of-work process from the second node, wherein a plurality of nodes in the first committee verify the solution; generating, by the first node in the first committee, a random string, the random string being used by the first node to determine a second committee for the second node; allowing, by the first node, the second node to join the second committee, wherein the second committee shifts nodes to allow the second node to join the second committee; and communicating, by the first node, information that the second node is in the second committee to other nodes in the computer network.

2. The method according to claim 1, wherein the second committee shifts a random number of nodes based on a random value generated by a leadership committee.

3. The method according to claim 2, wherein the shifted nodes are assigned to a random inactive committee.

4. The method according to claim 1, wherein the first node is a leadership node of the first committee.

5. The method according to claim 1, wherein the plurality of nodes in the first committee verify the solution when a) the solution solves the proof-of-work process, b) the solution is less than a predetermined security value, and c) the solution is received within a predetermined time.

6. The method according to claim 5, wherein the first node is a leadership node of the first committee.

7. The method according to claim 1, wherein at least two-thirds of the nodes in each committee in the computer network are non-malicious nodes.

8. A computer node, which comprises: a processor; a memory device; and a computer-readable medium coupled to the processor, the computer-readable medium comprising code executable by the processor for implementing a method comprising the following operations: receiving, by a first node in a first committee in a computer network, a request comprising a node identifier to cause a second node to join the committee; providing, by the first node in the first committee, a proof-of-work process to the second node; receiving, by the first node in the first committee, a solution to the proof-of-work process from the second node, wherein a plurality of nodes in the first committee verify the solution; generating, by the first node in the first committee, a random string, the random string being used by the first node to determine a second committee for the second node; allowing, by the first node, the second node to join the second committee, wherein the second committee shifts nodes to allow the second node to join the second committee; and The first node communicates information about the second node being in the second committee to other nodes in the computer network.

9. The node according to claim 8, wherein the second committee shifts a random number of nodes in the second committee based on a random value generated by a leadership committee.

10. The node according to claim 9, wherein the shifted nodes are assigned to a random inactive committee.

11. The node according to claim 8, wherein the first node is the leadership node of the first committee.

12. The node according to claim 8, wherein the multiple nodes in the first committee verify the solution when a) the solution solves the proof-of-work process, b) the solution is less than a predetermined security value, and c) the solution is received within a predetermined time.

13. The node according to claim 12, wherein the first node is the leadership node of the first committee.

14. The node according to claim 8, wherein at least two-thirds of the nodes in each committee in the computer network are non-malicious nodes.

15. A method for merging blocks into a blockchain shard, the method comprises: receiving, by a first node in a committee, an interaction request that includes interaction data from a client computer; incorporating, by the first node, the interaction data and other interaction data associated with other client computers into a block that includes interaction data, wherein the block includes a block portion; broadcasting, by the first node, the block to other nodes in the committee, wherein the other nodes in the committee verify the block; and incorporating the block into a shard of a blockchain managed by the committee.

16. The method according to claim 15, wherein the committee is a verification committee, and if the block portion having the interaction data or the other interaction data cannot be verified by the other nodes in the committee, the method further comprises: associating, by the first node, a source committee with a node to verify the block portion.

17. The method according to claim 16, wherein the source committee verifies the block portion and transmits a verification message to the verification committee.

18. The method according to claim 16, which further comprises: determining, by the first node, the source committee based on the block portion.

19. The method according to claim 15, which further comprises: receiving, by the first node, multiple blocks from the other nodes in the committee; and merging, by the first node, the multiple blocks with the block.

20. The method according to claim 15, which further comprises: generating, by the first node, a list of all block portions to be verified.

21. The method according to claim 15, wherein the committee includes more than 5 nodes.

22. A computer node, which comprises: a processor; a memory device; and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor for implementing a method including the following operations: Receive an interaction request by a first node in a committee, the interaction request including interaction data from a client computer; Incorporate, by the first node, the interaction data and other interaction data associated with other client computers into a block including interaction data, wherein the block includes block portions; Broadcast, by the first node, the block to other nodes in the committee, wherein the other nodes in the committee verify the block; and Incorporate the block into a shard of a blockchain managed by the committee.

23. The node according to claim 22, wherein the committee is a verification committee, and if the block portion having the interaction data or the other interaction data cannot be verified by the other nodes in the committee, the method further includes: Contact a source committee with the node to verify the block portion.

24. The node according to claim 23, wherein the source committee verifies the block portion and transmits a verification message to the verification committee.

25. The node according to claim 23, wherein the method further includes: Determine, by the first node, the source committee based on the block portion.

26. The node according to claim 22, wherein the method further includes: Receive, by the first node, a plurality of blocks from the other nodes in the committee; and Merge, by the first node, the plurality of blocks with the block.

27. The node according to claim 22, wherein the method further includes: Generate, by the first node, a list of all block portions to be verified.

28. The node according to claim 27, wherein the blockchain includes data on payment transactions.

29. A method for incorporating a block into a shard of a blockchain, the method includes: Determine, by a first node in a computer network, a leadership committee including a plurality of selected nodes, the plurality of selected nodes including the first node, the leadership committee being a first committee; Receive, by the first node, a request from a second node to join a committee of the computer network, the request including a node identifier; Determine, by the first node based on a proof-of-work process computed by the second node, that the second node can join a second committee; Allow, by the first node, the second node to join the second committee, wherein the second committee shifts nodes to allow the second node to join the second committee, wherein information that the second node is in the second committee is communicated to other nodes in the computer network; Receive, by the first node, an interaction request, the interaction request including interaction data from a client computer; Incorporate, by the first node, the interaction data and other interaction data associated with other client computers into a block including interaction data, wherein the block includes block portions; Broadcast, by the first node, the block to other nodes in the first committee, wherein the other nodes in the first committee verify the block; and Incorporate the block into a shard of a blockchain managed by the first committee.

30. A computer node, which includes: a processor; Memory device; and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor for implementing a method including the following operations: Determining, by a first node in a computer network, a leadership committee including a plurality of selected nodes, the plurality of selected nodes including the first node, the leadership committee being a first committee; Receiving, from a second node, a request to join a committee of the computer network, the request including a node identifier; Determining, based on a proof-of-work process computed by the second node, that the second node is able to join a second committee; Allowing the second node to join the second committee, wherein the second committee shifts nodes to allow the second node to join the second committee, and wherein information that the second node is in the second committee is communicated to other nodes in the computer network; Receiving an interaction request, the interaction request including interaction data from a client computer; Incorporating the interaction data and other interaction data associated with other client computers into a block including interaction data, wherein the block includes block portions; Broadcasting the block to other nodes in the first committee, wherein the other nodes in the first committee verify the block; and Incorporating the block into a shard of a blockchain managed by the first committee.

Images