Multi-party computation in a computer sharded environment

Abstract

Methods and systems are presented that provide a framework for facilitating multi-party computation within a sharded environment. After a blockchain is divided into a plurality of shard chains, a multi-party computation system obtains attributes associated with a first shard chain. The attributes can represent characteristics of the first shard chain, characteristics of transactions recorded in the first shard chain, and characteristics of computer nodes configured to manage the first shard chain. Based on the attributes, the multi-party computation system determines a multi-party computation scheme that specifies a minimum threshold number of nodes required to participate in a transaction validation process and at least one required node required to participate in the transaction validation process of the first shard chain. The multi-party computation system configures computer nodes configured to manage the first shard chain to perform the transaction validation process in accordance with the multi-party computation scheme.

Description

Technical Field

[0001] This specification relates generally to distributed computing, and more specifically to providing a framework for secure multi-party computation in a computer-sharded environment according to various embodiments of this disclosure. Background Technology

[0002] Due to its inherent peer-to-peer and immutable characteristics, blockchain has become a popular computer data structure for storing transaction data. For example, blockchain has been used as a decentralized ledger to record transaction data related to various cryptocurrencies, smart contracts, and other types of transaction data. Copies and / or portions of the blockchain can be stored on different computer nodes, each of which can be configured to verify transactions and add new transaction data to the blockchain. When a new transaction is made, one or more computer nodes can be configured to verify the new transaction (e.g., through proof-of-work or proof-of-stake mechanisms). Once the new transaction is verified, its transaction data can be packaged into a block by one or more computer nodes and appended to a copy of the blockchain.

[0003] As more and more transaction data is added to the blockchain, the speed and efficiency of managing the blockchain can be impacted by its continued growth in scale. One solution to improve blockchain scalability is to divide the blockchain into multiple shards, each corresponding to a different part of the blockchain. The computer nodes configured to manage the blockchain can also be divided into different groups, each group configured to manage its corresponding shard. While such a sharding solution can improve blockchain scalability, it also makes the blockchain (or each shard associated with it) more vulnerable to attack. For example, because the computer nodes configured to store and manage the blockchain are divided into multiple smaller groups to manage the various shards, a 51% attack on a shard can be accomplished by controlling (e.g., takeover, virus infection, etc.) a much smaller number of computer nodes than the same attack on the entire blockchain. Therefore, a framework is needed to improve the security of electronic transactions in sharded blockchain environments. Attached Figure Description

[0004] Figure 1 An example computational architecture for facilitating one or more blockchain-based transactions according to an embodiment of this disclosure is shown;

[0005] Figure 2 An example blockchain network according to an embodiment of this disclosure is shown;

[0006] Figure 3 An example blockchain according to an embodiment of this disclosure is shown;

[0007] Figure 4This is a diagram of an example transaction message according to an embodiment of this disclosure;

[0008] Figure 5 An example of a transaction broadcast in a blockchain network according to an embodiment of this disclosure is shown;

[0009] Figure 6A This is a flowchart illustrating an example process for executing a blockchain-based transaction according to an embodiment of this disclosure;

[0010] Figure 6B This is a flowchart illustrating another example process for executing a blockchain-based transaction according to an embodiment of this disclosure;

[0011] Figure 7A An example of a blockchain for secret broadcasting according to an embodiment of this disclosure is shown;

[0012] Figure 7B Examples of blockchain abuse according to embodiments of this disclosure are shown;

[0013] Figure 8 An example of a blockchain-enabled in-store purchasing system according to an embodiment of this disclosure is shown;

[0014] Figure 9 An example of communication of a device system supporting IoT blockchain according to an embodiment of this disclosure is shown;

[0015] Figure 10 An example system according to an embodiment of the present disclosure is shown;

[0016] Figure 11 An example computing device according to an embodiment of the present disclosure is shown;

[0017] Figure 12 This is a block diagram illustrating a networked system including an electronic transaction system according to an embodiment of the present disclosure;

[0018] Figure 13 An example sharding environment of a blockchain according to an embodiment of this disclosure is shown;

[0019] Figure 14 This is a block diagram illustrating a multi-party computation module according to an embodiment of the present disclosure;

[0020] Figure 15 The secret distribution and secret share among a group of computer nodes according to an embodiment of the present disclosure are shown;

[0021] Figure 16 The interaction between a set of computer nodes for performing a verification process according to an embodiment of the present disclosure is illustrated;

[0022] Figure 17 This is a flowchart illustrating the process of implementing a multi-party computation scheme for a fragment chain according to an embodiment of the present disclosure;

[0023] Figure 18 This is a flowchart illustrating the process of modifying the multi-party computation scheme of the fragment chain according to an embodiment of the present disclosure;

[0024] Figure 19 This is a flowchart illustrating the process of performing a verification procedure according to an embodiment of the present disclosure; and

[0025] Figure 20 This is a block diagram of a system for implementing an apparatus according to an embodiment of the present disclosure.

[0026] The embodiments and advantages of this disclosure can be best understood by referring to the following detailed description. It should be understood that similar reference numerals are used to identify similar elements shown in one or more figures, wherein the illustrations are for illustrative purposes and not for limiting the purpose of this disclosure. Detailed Implementation

[0027] This disclosure includes methods and systems for providing a framework to facilitate multi-party computation within a sharded environment. As discussed herein, the speed and efficiency of adding transaction data to a blockchain can decrease as the size of the blockchain, managed by multiple computer nodes (in a blockchain network), grows. One solution is to divide the blockchain into multiple parts (also known as “shard chains”), such that each computer node can be configured to store and manage only its corresponding shard chain (e.g., a corresponding part of the blockchain) rather than the entire blockchain. Transactions added to each shard chain can then be merged into the blockchain subsequently (e.g., offline). Since the processing resources required to process transaction data in a shard chain of the blockchain are significantly less than those required to process transaction data in the entire blockchain, speed and efficiency can be improved.

[0028] However, such sharding solutions also introduce new security risks to blockchains. The integrity of a blockchain can depend on many factors, including the total number of computer nodes configured to store and manage copies of the blockchain within the blockchain network. This is because when a blockchain operates in a decentralized manner, the true version of the blockchain can be determined based on consensus (e.g., a majority) from the various computer nodes configured to store and manage copies of the blockchain. Therefore, one way to compromise the integrity of a blockchain (e.g., adding fraudulent data to the blockchain and / or deleting legitimate data from it) is to control at least half of the computer nodes within the blockchain network, which are configured to store and manage the blockchain (also known as the 51% attack discussed above). The more computer nodes configured to store and manage copies of the blockchain, the more difficult it is to perform such an attack on the blockchain.

[0029] By dividing the computer nodes configured to manage the blockchain into different node groups (e.g., different shard networks) to store and manage the corresponding shard chains, the number of nodes configured to manage each shard chain is significantly less than the total number of nodes configured to manage the entire blockchain before sharding. This significantly reduced number of nodes used to store and manage each shard chain may, in turn, lead to higher security risks for the blockchain, because it is easier to launch an attack on any one shard chain (e.g., a 51% attack) than to attack the entire blockchain before sharding.

[0030] Thus, according to various embodiments of this disclosure, a multi-party computation system can be configured to use multi-party computation techniques to improve the security and integrity of individual shards of a blockchain. In some embodiments, the multi-party computation system can access the shards associated with the blockchain and computer nodes configured to store and manage the shards. The multi-party computation system can determine one or more metrics for each shard. For example, the multi-party computation system can determine a chain metric for each shard, representing a characteristic of the blockchain portion corresponding to the shard. The chain metric can indicate the size of the shard, the age of blocks in the shard (e.g., average age), the rate or frequency of blocks being added to the shard, and other information associated with the shard. In some embodiments, the chain metric can also represent the size of the entire blockchain, the age of the blockchain, the rate or frequency of blocks being added to the blockchain as a whole, and other information associated with the blockchain.

[0031] The multi-party computing system can also determine transaction metrics representing the characteristics of transactions recorded in each shard chain. For example, transaction metrics may represent the amount of transactions recorded in the shard chain (e.g., average, minimum, maximum, etc.), the number of transactions recorded in the shard chain, the rate or frequency of transactions recorded in the shard chain, the volatility of transactions recorded in the shard chain, the characteristics of the users and / or user devices used to perform the transactions recorded in the shard chain, and other information associated with the transactions recorded in the shard chain. The multi-party computing system can also determine node metrics representing the characteristics of computer nodes within a group configured to store and manage shard chains. For example, node metrics may represent the security level of each computer node within the group, the hardware and / or software configuration of each computer node within the group, network attributes associated with connections between computer nodes within the group, and other attributes associated with computer nodes in the group.

[0032] Based on metrics associated with the sharded chains, the multi-party computation system can determine the multi-party computation scheme for each sharded chain. The multi-party computation scheme can specify the minimum number (t) of participating nodes (out of n computer nodes) in a group (within the sharded network) corresponding to the sharded chain to verify transactions to be recorded in the sharded chain. By specifying a minimum number of participating nodes to verify transactions to be recorded in the sharded chain (e.g., more than half of the nodes in the node group), the security of sharding can be improved.

[0033] In some implementations, to further enhance sharding security, the multi-party computation system can also identify the computer nodes required (also referred to as "must-haves") to participate in verifying transactions to be recorded in the shard chains. For example, the multi-party computation system can select specific computer nodes for each particular shard chain as the ("must-haves") computer nodes required to participate in verifying transactions through that particular shard. For instance, the multi-party computation system can select specific computer nodes configured to store and manage a particular shard chain as well as one or more other shard chains of the blockchain. The reason for selecting such computer nodes is that computer nodes configured (e.g., by the blockchain administrator) to store and manage multiple shard chains are generally more trustworthy and have a higher level of security than other nodes. Therefore, selecting specific computer nodes as the nodes required to participate in the verification process further enhances the security of sharding.

[0034] To implement such a multi-party computation process, multiple secrets can be generated for a digital signature in a manner that requires a combination of multiple secrets to generate the digital signature. The number of secrets generated can correspond to one plus the number of computer nodes required (“essential”) to verify transactions made through sharding. For example, if the verification process requires only one required (“essential”) computer node, two secrets can be generated to generate the digital signature. If the verification process requires two required computer nodes, three secrets can be generated to generate the digital signature. Generating a digital signature requires a combination of all secrets. The multiple secrets can include one or more non-shared secrets corresponding to one or more required computer nodes, as well as shared secrets to be shared among other nodes within a group configured to manage shards.

[0035] A multi-party computation system can distribute one or more non-shared secrets among one or more desired computer nodes (if there is only one desired computer node, then a non-shared secret is provided to that desired computer node). The multi-party computation system can then generate shares from the remaining secret (shared secret) using the techniques disclosed herein, and distribute the shares associated with the shared secret to the other remaining computer nodes in the group (multiple computer nodes other than the desired node). In some embodiments, the multi-party computation system can generate shares based on the shared secret and distribute the shares to the remaining multiple computer nodes such that the shares from any combination of the multiple computer nodes are equal to t minus the number of desired nodes, requiring the generation of an output simulating computation based on the shared secret. In some embodiments, the output can be the shared secret. In some embodiments, the output can simulate a product generated based on the shared secret.

[0036] Therefore, during the verification process used to verify transactions to be recorded in a shard of the blockchain, a group of computer nodes, excluding the required node, can collaborate using their respective shares to perform a set of computations to generate a shared secret or a product based on the shared secret. If a sufficient number of computer nodes (t minus the number of required nodes) participate in the verification process, the group of computer nodes will successfully generate an output corresponding to the shared secret (e.g., the shared secret or a product mimicking the shared secret) using their respective shares. The required node can then perform additional computations on the output using the corresponding secret to generate a digital signature. The transaction is only recorded in the shard when a correct digital signature is generated. Therefore, when the number of computer nodes is less than the minimum threshold number (t) of computer nodes participating in verification, or when any required node does not participate in the verification of the transaction, the transaction will not be recorded in the corresponding shard chain (e.g., discarded by computer nodes in the shard network). In some implementations, when a correct digital signature is generated, the generated digital signature can also be recorded in the shard chain (e.g., within the same block as the transaction data associated with the transaction).

[0037] Blockchain

[0038] In its broadest sense, blockchain refers to a framework that enables the distributed storage, maintenance, and updating of a trusted ledger across a peer-to-peer network. For example, in cryptocurrency applications (such as Bitcoin or Ethereum, Ripple, Dash, Litecoin, Dogecoin, zCash, Tether, Bitcoin Cash, Cardano, Stellar, EOS, NEO, NEM, Bitshares, Decred, Augur, Komodo, PIVX, Waves, Steem, Monero, Golem, Stratis, Bytecoin, Ardor), or in digital currency exchanges (such as Coinbase, Kraken, CEX.IO, Shapeshift, Poloniex, Bitstamp, Coinmama, Bisq, LocalBitcoins, Gemini, etc.), the distributed ledger represents every transaction in which cryptocurrency units are transferred between entities. For instance, using digital currency exchanges, users can buy any value of digital currency or exchange any held digital currency for a global currency or other digital currencies. Each transaction can be verified through the distributed ledger, and only verified transactions are added to the ledger. Ledgers and many aspects of blockchain can be described as “decentralized” because there is typically no central authority. Therefore, the accuracy and integrity of the ledger cannot be attacked from a single central location. To protect the integrity of the ledger, it becomes difficult to modify all or most of its storage location. This is largely because the individuals associated with the nodes that make up the peer-to-peer network have a vested interest in the accuracy of the ledger.

[0039] While maintaining cryptocurrency transactions in a distributed ledger is perhaps the most well-known use of blockchain technology today, ledgers can be used in a wide variety of different fields. In fact, blockchain technology is suitable for any application that can access any type of data and guarantee its accuracy. For example, supply chains can be maintained in a blockchain ledger, where the transfer of each component from one party to another and from one location to another can be recorded for later retrieval. Doing so makes it easier to identify the origin of defective parts and the delivery locations of other such defective parts. Similarly, food can be tracked in a similar way from farm to grocery store to buyer.

[0040] The implementation of this disclosure will now be described in detail with reference to the accompanying drawings.

[0041] It should be understood that the wording and terminology used herein are for descriptive purposes and should not be considered restrictive. Rather, the phrases and terms used herein should be given their broadest interpretation and meaning. The use of “including” and “contains” and their variations means to cover the items listed thereafter and their equivalents, as well as additional items and their equivalents.

[0042] Computing architecture

[0043] As mentioned above, the distributed ledger in the blockchain framework is stored, maintained, and updated in a peer-to-peer network. In one example, the distributed ledger maintains many blockchain transactions. Figure 1 An example system 100 for facilitating blockchain transactions is illustrated. System 100 includes a first client device 120, a second client device 125, a first server 150, a second server 152, and an Internet of Things (IoT) device 155 interconnected via a network 140. The first client device 120, the second client device 125, the first server 150, and / or the second server 152 may be references. Figure 11 The computing device 1105 is described in more detail. The IoT device 155 can include any of a variety of devices, including vehicles, home appliances, embedded electronics, software, sensors, actuators, thermostats, light bulbs, door locks, refrigerators, RFID implants, RFID tags, pacemakers, wearable devices, smart home devices, cameras, trackers, pumps, POS devices, fixed and mobile communication devices, and connectivity hardware configured to connect and exchange data. Network 140 can be any of a variety of available networks, such as the Internet, and represents a global collection of networks and gateways that support communication between devices connected to network 140. System 100 may also include one or more distributed or peer-to-peer (P2P) networks, such as first, second, and third blockchain networks 130a-c (commonly referred to as blockchain network 130). Figure 1 As shown, network 140 may include a first blockchain network 130a and a second blockchain network 130b. A third blockchain network 130c may be associated with the following references. Figure 2 The described private blockchains are associated with and connected to one or more servers, such as server 152, and are therefore shown separately from the first blockchain network 130a and the second blockchain network 103b. Each blockchain network 130 may include multiple interconnected devices (or nodes), as referenced. Figure 2 A more detailed description follows. As mentioned above, a ledger or blockchain is a distributed database used to maintain a constantly growing list of records containing any type of information. (See reference...) Figure 3 In more detail, a blockchain can be stored at least on multiple nodes (or devices) of one or more blockchain networks 130.

[0044] In one example, blockchain-based transactions can typically involve entities (such as...) Figure 1 The transfer of data or value between a first user 110 on a first client device 120 and a second user 115 on a second client device 125. Each of servers 150 and 152 may include one or more applications, such as transaction applications configured to facilitate transactions between entities by utilizing a blockchain associated with one of the blockchain networks 130. As an example, the first user 110 may request or initiate a transaction with the second user 115 via a user application executed on the first client device 120. The transaction may involve the transfer of value or data from the first user 110 to the second user 115. The first client device 120 may send a transaction request to server 150. The first server 150 and / or the second server 152 may send the requested transaction to one of the blockchain networks 130 for verification and approval, as described below.

[0045] Blockchain Network

[0046] Figure 2 An example blockchain network 200 is shown, comprising multiple interconnected nodes or devices 205a-h (typically referred to as node 205). Each node 205 may include references Figure 11 The computing device 1105 is described in more detail. Although Figure 2 A single device 205 is shown, but each node 205 can include multiple devices (e.g., a pool). The blockchain network 200 can be associated with one or more blockchains 220a-h (commonly referred to as blockchain 220). Some or all nodes 205 can replicate and maintain the same copy of blockchain 220. For example, Figure 3 The diagram shows that nodes 205b-e and 205g-h store copies of blockchain 220. Nodes 205b-e and 205g-h can independently update their respective copies of blockchain 220, as described below.

[0047] Blockchain node types

[0048] Blockchain nodes, such as node 205, can be full nodes or lightweight nodes. Full nodes (such as nodes 205b-e and 205g-h) act as servers in the blockchain network 200 by storing a copy of the entire blockchain 220 and ensuring the validity of transactions published to blockchain 220. Full nodes 205b-e and 205g-h can publish new blocks on blockchain 220. Lightweight nodes, such as nodes 205a and 205f, can have fewer computational resources than full nodes. For example, IoT devices often act as lightweight nodes. Lightweight nodes can communicate with other nodes 205, provide information to full nodes 205b-e and 205g-h, and query the status of blocks in blockchain 220 stored by full nodes 205b-e and 205g-h. However, in this example, as... Figure 2 As shown, lightweight nodes 205a and 205f do not need to store a copy of blockchain 220, and therefore do not need to publish new blocks on blockchain 220.

[0049] Blockchain network types

[0050] Blockchain network 200 and its associated blockchain 220 can be public (permissionless), federated or consortium-based, or private. If blockchain network 200 is public, any entity can read and write to the associated blockchain 220. However, if controlled by a single entity or organization, blockchain network 200 and its associated blockchain 220 can be federated or consortium-based. Furthermore, participation in the verification of transactions on blockchain 220 can be restricted to any node 205 with internet access. If access to blockchain network 200 and blockchain 220 is limited to specific authorized entities, such as organizations or groups of individuals, blockchain network 200 and its associated blockchain 220 can be private (permissioned). Furthermore, read permissions for blockchain 220 can be public or restricted, while write permissions can be limited to the controlling or authorized entity.

[0051] Blockchain

[0052] As mentioned above, blockchain 220 can be associated with blockchain network 200. Figure 3An example blockchain 300 is shown. Blockchain 300 may include multiple blocks 305a, 305b, and 305c (commonly referred to as block 305). Blockchain 300 includes a first block (not shown), sometimes called the genesis block. Each block 305 may include a record of one or more committed and verified transactions. Blocks 305 of blockchain 300 may be chained together and cryptographically protected. In some cases, post-quantum cryptography algorithms that dynamically change over time can be used to mitigate the ability of quantum computing to break existing cryptographic schemes. Examples of various types of data fields stored in blockchain blocks are provided below. Replicas of blockchain 300 may be stored locally, for example, by nodes 205b-e and 205g-h, in the cloud, on a grid as files, or stored in a database.

[0053] Block

[0054] Each block in block 305 may include one or more data fields. The organization of block 305 and its corresponding data fields within blockchain 300 can be implementation-specific. As an example, block 305 may include corresponding headers 320a, 320b, and 320c (generally referred to as header 320) and block data 375a, 375b, and 375c (generally referred to as block data 375). Header 320 may include metadata associated with its corresponding block 305. For example, header 320 may include corresponding block numbers 325a, 325b, and 325c. Figure 3 As shown, block number 325a of block 305a is N-1, block number 325b of block 305b is N, and block number 325c of block 305c is N+1. The header 320 of block 305 may include a data field that includes the block size (not shown).

[0055] Blocks 305 can be chained together and cryptographically protected. For example, the header 320b of block N (block 305b) includes a data field (the hash of the previous block 330b), which contains a hash representation of the header 320a of the previous block N-1. The hash algorithm used to generate the hash representation can be, for example, a secure hash algorithm 256 (SHA-256) that results in a fixed-length output. In this example, the hash algorithm is a one-way hash function, where determining the input of the hash function based on its output is computationally difficult. Additionally, the header 320c of block N+1 (block 305c) includes a data field (the hash of the previous block 330c), which contains a hash representation of the header 320b of block N (block 305b).

[0056] The header 320 of block 305 may also include data fields, such as a hash representation of the block data, like block number 375375 and hashes 370a-c. The block data hashes 370a-c may be generated, for example, via a Merkle tree and by storing the hashes or by using hashes based on all block data. The header 320 of block 305 may include corresponding random numbers 360a, 360b, and 360c. In some implementations, the values ​​of the random numbers 360a-c are arbitrary strings concatenated with (or appended to) the block's hash. The header 320 may include other data, such as a difficulty target.

[0057] Block 305 may include corresponding block data 375a, 375b, and 375c (commonly referred to as block data 375). Block data 375 may include records of verified transactions that have also been integrated into blockchain 200 via a consensus model (described below). As mentioned above, in addition to verified transactions, block data 375 may also include various other types of data. Block data 375 may include any data that can be digitally represented and electronically stored, such as text, audio, video, images, or files.

[0058] Blockchain transactions

[0059] In one example, blockchain-based transactions can typically involve the transfer of data or value, or interactions between entities, and are described in more detail below. Return to reference Figure 1 The first server 150 and / or the second server 152 may include one or more applications, such as transaction applications configured to facilitate blockchain transactions between entities. These entities may include users, devices, etc. The first user 110 may request or initiate a transaction with the second user 115 via a user application executed on the first client device 120. The transaction may involve the transfer of value or data from the first user 110 to the second user 115. The value or data may represent money, contracts, property, records, rights, states, supply, demand, alarms, triggers, or any other asset that can be represented digitally. The transaction may represent an interaction between the first user 110 and the second user 115.

[0060] Figure 4This is a graph of transaction 465 generated by the transaction application. Transaction 465 may include public key 415, blockchain address 430 associated with first user 110, digital signature 455, and transaction output information 460. The transaction application can derive public key 415 from first user 110's private key 405 by applying cryptographic hash function 410 to private key 405. Cryptographic hash function 410 may be based on SHA-2 or SHA-3, but may utilize other cryptographic models. For more information on cryptographic algorithms, see the Secure Hash Standards in Federal Information Processing Standards Publication (FIPS PUB 180-3). The transaction application can derive the address or identifier of first user 110, such as blockchain address 430, by applying hash function 420 to public key 415. In short, a hash function is a function that can be used to map data of arbitrary size to data of fixed size. This value may also be called a digest, hash value, hash code, or hash. To indicate that the first user 110 is the initiator of transaction 465, the transaction application can use the first user 110's private key 405 to generate a digital signature 455 for transaction data 435. Transaction data 435 may include information about the asset to be transferred and references to the asset's source, such as a previous transaction in which the asset was transferred to the first user 110 or an identifier of the event that initiated the asset. Generating the digital signature 455 may include applying a hash function 440 to transaction data 435, thereby producing hashed transaction data 445. The hashed transaction data 445 and transaction data 435 can be encrypted (via encryption function 450) using the first user 110's private key 405, thereby generating the digital signature 455. Transaction output information 460 may include asset information 470 and the address or identifier of the second user 115, such as a blockchain address 475. Transaction 465 can be sent from the first client device 125 to the first server 150.

[0061] The specific type of encryption algorithm used can change dynamically based on various factors, such as the duration of use and privacy concerns. For example, the type of encryption algorithm used can change annually, weekly, or daily. The algorithm type may also vary depending on different levels of privacy. For instance, content owners can achieve a higher level of protection or privacy by utilizing stronger algorithms.

[0062] Blockchain address

[0063] Blockchain networks can use blockchain addresses to indicate the start and end points of entities or transactions using the blockchain. For example, in Figure 4The blockchain address of the first user 110, shown as the sender 430, may include an alphanumeric string derived from the first user 110's public key 415 by applying a cryptographic hash function 420 to the public key 415. The methods used to derive the address may vary and may be specific to the implementation of the blockchain network. In some examples, the blockchain address may be converted into a QR code representation, barcode, token, or other visual representation or graphic description to enable the address to be optically scanned by mobile devices, wearable devices, sensors, cameras, etc. Besides addresses or QR codes, there are many other QR codes that identify individuals, objects, etc., represented in the blockchain. For example, individuals can be identified through biometric information such as fingerprints, retinal scans, voice, facial ID, temperature, heart rate, and personally unique gestures / movements, as well as other types of identification information such as account numbers, home addresses, Social Security numbers, and formal names.

[0064] Broadcast trading

[0065] The first server 150 can receive transactions from users of the blockchain network 130. Transactions can be submitted to the first server 150 via desktop applications, smartphone applications, digital wallet applications, web services, or other software applications. The first server 150 can send or broadcast transactions to the blockchain network 130. Figure 5 Example transaction 502 is shown, broadcast from server 150 to blockchain network 130. Transaction 502 can be broadcast to multiple nodes 205 of blockchain network 130. Typically, once transaction 502 is broadcast or submitted to blockchain network 130, it can be received by one or more nodes 205. Once transaction 502 is received by one or more nodes 205 of blockchain network 130, it can be propagated by the receiving node 205 to other nodes 205 of blockchain network 130.

[0066] A blockchain network can operate according to a set of rules. These rules can specify the conditions under which a node can accept a transaction, the types of transactions a node can accept, and the types of compensation a node receives for accepting and processing transactions. For example, a node might accept a transaction based on its transaction history, reputation, computing resources, and relationship with a service provider. Rules can also specify the conditions for broadcasting transactions to nodes. For example, a transaction might be broadcast to one or more specific nodes based on criteria related to a node's geographic location, history, reputation, market conditions, case files / delays, and technology platform. Rules can be dynamically modified or updated (e.g., enabled or disabled) to address issues such as latency, scalability, and security conditions. Transactions can be broadcast to a subset of nodes as a form of compensation to entities associated with those nodes (e.g., compensation for receiving a block of one or more transactions added to the blockchain).

[0067] Transaction verification – user authentication and transaction data integrity

[0068] Due to issues such as wait times, not all full nodes 205 can simultaneously receive broadcast transaction 502. Furthermore, not all full nodes 205 that receive broadcast transaction 502 can choose to verify transaction 502. Node 205 can choose to verify a specific transaction, for example, based on the transaction fee associated with transaction 502. Transaction 502 may include the sender's blockchain address 505, public key 510, digital signature 515, and transaction output information 520. Node 205 can verify whether transaction 502 is legitimate or conforms to a set of predefined rules. Node 205 can also verify transaction 502 based on establishing user authenticity and transaction data integrity. User authenticity can be established by determining whether the sender indicated by transaction 502 is actually the actual initiator of transaction 502. User authenticity can be proven cryptographically, for example, using asymmetric key cryptography with a pair of keys (e.g., public and private keys). Additional factors such as user reputation, market conditions, history, and transaction speed can be considered when establishing user authenticity. Data integrity of transaction 502 can be established by determining whether the data associated with transaction 502 has been modified in any way. (Return to reference) Figure 4 When a transaction application creates a transaction 465, it can indicate that the first user 110 is the initiator of the transaction 465 by including a digital signature 455.

[0069] Node 205 can use public key 510 to decrypt digital signature 515. The decryption result can include hash transaction data 540 and transaction data 530. Node 205 can generate hash transaction data 550 by applying hash function 545 to transaction data 530. Node 205 can perform a comparison 565 between the first hash transaction data 540 and the second hash transaction data 550. If the result 570 of comparison 565 indicates a match, the data integrity of transaction 502 can be established and node 205 can indicate that transaction 502 has been successfully verified. Otherwise, the data of transaction 502 may have been modified in some way, and node 205 can indicate that transaction 502 has not been successfully verified.

[0070] Each full node 205 can build its own block and add verified transactions to that block. Therefore, blocks from different full nodes 205 can include different verified transactions. As an example, full node 205a can create a first block containing transactions "A", "B", and "C". Another full node 205b can create a second block containing transactions "C", "D", and "E". Both blocks may contain valid transactions. However, only one block can be added to the blockchain; otherwise, transactions that might be shared by the blocks, such as transaction "C", might be recorded twice, leading to problems like double-spending when the transaction is executed twice. One potential problem in the above example is that transactions "C", "D", and "E" might be excessively delayed when added to the blockchain. This can be addressed in several different ways, as discussed below.

[0071] Protect key

[0072] Private keys, public keys, and addresses can be managed and protected using software such as digital wallets. Private keys can also be stored and protected using hardware. Digital wallets also enable users to conduct transactions and manage their balances. Digital wallets can be online or offline and can be stored or maintained in software, hardware, or both. Without a public / private key, a user cannot prove ownership of assets. Furthermore, anyone with access to a user's public / private key can access the user's assets. While assets may be recorded on a blockchain, users may not be able to access them without a private key.

[0073] Token

[0074] A token can refer to an entry in a blockchain that belongs to a blockchain address. This entry can include information indicating ownership of an asset. A token can represent money, contracts, property, records, access rights, states, supply, demand, alarms, triggers, reputation, bills, or any other asset that can be represented digitally. For example, a token can refer to an entry associated with cryptocurrency used for a specific purpose, or it can represent ownership of a real-world asset such as fiat currency or real estate. A token contract is a cryptographic token representing a set of rules encoded in a smart contract. The person who owns the private key corresponding to the blockchain address can access the token at that address. Therefore, a blockchain address can represent the identity of the person who owns the token. Only the owner of the blockchain address can send the token to another person. The owner can access the token through the owner's wallet. The owner of the token can send or transfer the token to a user through blockchain transactions. For example, the owner can sign a transaction corresponding to a token transfer using their private key. When a user receives the token, the token can be recorded at the user's blockchain address in the blockchain.

[0075] Establish user identity

[0076] While digital signatures can provide a link between a transaction and the owner of the transferred assets, they may not provide a link to the owner's true identity. In some cases, it may be necessary to establish the true identity of the public key owner corresponding to the digital signature. For example, the true identity of the public key owner can be verified based on biometric data, passwords, personal information, etc. Biometric data can include any physically identifying information, such as fingerprints, facial and eye images, voice samples, DNA, human movement, gestures, gait, facial expressions, heart rate characteristics, temperature, etc.

[0077] Publish and verify blocks

[0078] As described above, full nodes 205 can each build their own blocks containing different transactions. Nodes build blocks by adding verified transactions until the blocks reach a specific size that can be specified by the blockchain rules. However, only one block can be added to the blockchain at a time. The blocks to be added to the blockchain and their order can be determined based on a consensus model. In a proof-of-work model, two nodes might compete to add their respective blocks to the blockchain by solving a complex mathematical puzzle. For example, such a puzzle could include determining a random number, as described above, such that the hash (using a predefined hash algorithm) of the block to be added to the blockchain (including the random number) has a value that satisfies a range constraint. If both nodes solve the puzzle simultaneously, a "fork" might be created. When full node 205 solves the puzzle, it can publish its block for verification by validator nodes 205 of the blockchain network 130.

[0079] In the Proof-of-Work consensus model, nodes verify transactions, for example, by inspecting or searching the current ledger stored in the blockchain. The node will then create a new block for the blockchain, which will include data on one or more verified transactions (see example...). Figure 3 (Block 375). In blockchain implementations such as Bitcoin, block size is limited. (Return to reference) Figure 3In this example, the block will include the hash 330 of the previous block, representing the hash of the current last block in the blockchain. The block may also include the hash 370 of its own transaction data (e.g., a so-called Merkle hash). Depending on the specific algorithm, all or selected data from the block can be hashed to create the final hash. In the implementation of the proof-of-work model, nodes will seek to modify the block's data such that the final hash is less than a preset value. This is achieved by adding a data value called a random number 360. Because the final hash cannot be predicted based on its input, it is impossible to estimate the appropriate value of the random number 360 that will result in a final hash less than the preset value. Therefore, in this implementation, computationally intensive operations are required at the node to determine the appropriate random value through a "brute-force" trial and error process. Once a successful random value is determined, the complete block is published to the blockchain network for verification. If verified by a majority of nodes in the blockchain network, the complete block is added to the blockchain of each participating node. When a node's block is not added to the blockchain, the block is discarded, and the node will continue building new blocks. Transactions in discarded blocks can be returned to the queue and await addition to the next block. When a transaction is discarded or returned to the queue, the assets associated with the discarded transaction are not lost, as the asset's record will remain on the blockchain. However, returning a transaction to the queue causes a delay in transaction completion. Reducing transaction completion time can be important. A set of blockchain rules or a re-enumeration / compensation of nodes processing returned transactions can determine how returned transactions should be handled in the future. When a transaction is placed in the pool, it can have a priority, but rules can instruct that a transaction's priority must exceed a threshold level. The priority of returned or discarded transactions can be increased. Another way to reduce transaction completion time is to have the system, service providers, transaction participants, or merchants pay additional rewards for nodes processing returned transactions. As an example, service providers can identify preferred miners' networks based on geographic location or based on bulk discount angles. Transaction completion time can be optimized by routing returned transactions to specific preferred nodes. Transactions may be associated with addresses that restrict which preferred nodes will process the transaction if it is returned due to being included in a discarded block. Values ​​can be associated with transactions so that they flow to preferred miners in a specific geographic location. Furthermore, returned transactions can be processed according to preset rules. For example, the rules could instruct the processing of a specific number of returned transactions in exchange for a promise of additional incentives or compensation.

[0080] Blockchain confirmation

[0081] After a block containing a transaction is added to the blockchain, blockchain confirmations can be generated for that transaction. Blockchain confirmations can be added to the blockchain multiple times after the block containing the transaction. For example, when a transaction is broadcast to the blockchain, there will be no blockchain confirmation associated with that transaction. If a transaction is not verified, the block containing it will not be added to the blockchain, and the transaction will continue to have no associated blockchain confirmation. However, if the block containing the transaction is verified, each transaction in that block will have a blockchain confirmation associated with it. Therefore, when a block is verified, the transactions in the block will have one associated blockchain confirmation. When a block is added to the blockchain, each transaction in the block will have two associated blockchain confirmations. As additional verified blocks are added to the blockchain, the number of blockchain confirmations associated with that block will increase. Therefore, the number of blockchain confirmations associated with a transaction may indicate the difficulty of overwriting or reversing a transaction. Higher-value transactions may require a greater number of blockchain confirmations before execution.

[0082] consensus model

[0083] As described above, a blockchain network can determine which full node 205 will publish the next block to the blockchain. In a permissionless blockchain network, nodes 205 can compete to determine which node will publish the next block. Node 205 can be selected to publish its block as the next block in the blockchain based on a consensus model. For example, the selected or winning node 205 can receive a reward, such as a transaction fee for publishing its block. Various consensus models can be used, such as proof-of-work, proof-of-stake, delegated proof-of-stake, circular, proof-of-authority or proof-of-identity, and proof-of-time models.

[0084] In the Proof-of-Work (PoW) model, a node can publish the next block by being the first to solve a computationally intensive mathematical problem (e.g., the mathematical puzzle mentioned above). The solution serves as "proof" that the node has expended appropriate effort to publish the block. The solution can be verified by all nodes before the block is accepted. However, the PoW model can be vulnerable to the 51% attack described below. The computational intensity of the Proof-of-Stake (PoS) model is generally lower than that of the PoW model. Unlike the PoW model, which is open to any node with the computational resources to solve the mathematical problem, the PoS model is open to any node that holds stake in the system. Stake can be a certain amount of cryptocurrency that a blockchain network node (user) may have invested in the system. The probability of a node publishing the next block may be proportional to its stake. Because this model uses fewer resources, the blockchain may forgo rewards as an incentive to publish the next block. The circular model is commonly used by permissioned blockchain networks. Using this model, nodes can take turns publishing new blocks. In the Proof-of-Ever-Time (PoE) model, each publishing node requests a waiting time from the secure hardware within its computer system. The publishing node may be idle during the waiting time, then create a block and publish it to the blockchain network. As an example, in situations requiring speed and / or scalability (such as in enterprise environments), hybrid blockchain networks can switch between fully or partially permissioned and permissionless modes. The network may switch based on various factors such as latency, security, market conditions, etc.

[0085] fork

[0086] As mentioned above, consensus models can be used to determine the order of events on a blockchain, such as which node adds the next block and which node's transaction is verified first. When conflicts related to the order of events exist, the result can be a fork in the blockchain. A fork can lead to two versions of the blockchain existing simultaneously. Consensus methods typically resolve conflicts related to event ordering to prevent forks from occurring. In some cases, a fork may be unavoidable. For example, in a Proof-of-Work consensus model, only one node competing to solve a puzzle might win by solving its puzzle first. The winning node's block will then be verified by the network. If the winning node's block is successfully verified by the network, it will be the next block added to the blockchain. However, it is possible that two nodes will eventually solve their respective puzzles simultaneously. In this case, the blocks of the two winning nodes can be broadcast to the network. Since different nodes can receive notifications from different winning nodes, the node that receives notification from the first node as the winning node can add the first node's block to its blockchain copy. The node that receives notification from the second node as the winning node can add the second node's block to its blockchain copy. This results in two versions of the blockchain, or a fork. This type of fork can be resolved using the longest chain rule of the Proof-of-Work consensus model. According to the longest chain rule, if two versions of a blockchain exist, the chain with the more blocks is considered the valid blockchain. Other versions of the blockchain may be considered invalid and discarded or orphaned. Because blocks created by different nodes may contain different transactions, a fork may result in transactions being included in one version of the blockchain instead of the other. Transactions in discarded blockchain blocks can be returned to the queue and await addition to the next block.

[0087] In some cases, a fork may be caused by changes related to the blockchain implementation, such as changes to the blockchain protocol and / or software. Due to the impact on a large number of users, a fork can be more disruptive to permissionless, globally distributed blockchain networks than to private blockchain networks. Changes or updates to backward-compatible blockchain implementations may result in a soft fork. When a soft fork occurs, some nodes may implement the updated blockchain implementation, while others may not. However, nodes that have not updated to the new blockchain implementation may continue to transact with nodes that have updated.

[0088] Changes to a blockchain implementation that is not backward compatible can result in a hard fork. While hard forks are usually intentional, they can also be caused by unintentional software bugs / errors. In this case, all publishing nodes in the network may need to update to the new blockchain implementation. While publishing nodes that have not updated to the new implementation can continue to publish blocks based on the previous implementation, these nodes may reject blocks created based on the new implementation and continue to accept blocks created based on the previous implementation. Therefore, nodes on different hard fork versions of the blockchain may be unable to interact with each other. If all nodes migrate to the new implementation, the previous version may be discarded or abandoned. However, updating all nodes in the network to the new implementation may be impractical or infeasible, for example, if the update disables the specialized hardware used by some nodes.

[0089] Blockchain-based applications: Cryptocurrencies

[0090] Cryptocurrencies are mediums of exchange that can be created electronically and stored on a blockchain, such as... Figure 1 Blockchain 130a is an example of cryptocurrency. Bitcoin is one example of cryptocurrency, but several other cryptocurrencies exist. Various cryptographic techniques can be used to create cryptocurrency units and verify transactions. As an example, a first user 110 may possess 10 units of cryptocurrency. Blockchain 130a may include a record indicating that the first user 110 possesses 10 units of cryptocurrency. The first user 110 may initiate a transfer of 10 units of cryptocurrency to a second user 115 via a wallet application running on a first client device 120. The wallet application may store and manage the first user 110's private key. Examples of wallet devices include personal computers, laptops, smartphones, personal data assistants (PDAs), etc.

[0091] Figure 6A It is shown that it is used in, for example Figure 1 The flowchart illustrates the steps of an example method 600 for executing a blockchain transaction between entities such as a first user 110 on a first client device 120 and a second user 115 on a second client device 125. The steps of method 600 can be derived from... Figure 1 The method may be performed by any computing device shown. Alternatively or additionally, some or all of the steps of method 600 may be performed by one or more other computing devices. The steps of method 600 may be modified, omitted, and / or performed in a different order, and / or additional steps may be added.

[0092] In step 605, the wallet application can generate transaction data for transferring 10 units of cryptocurrency from first user 110 to second user 120. The wallet application can use the private key of first user 110 to generate a public key for the transaction. To demonstrate that first user 110 is the initiator of the transaction, a digital signature can also be generated for the transaction using the private key of first user 110. See reference... Figure 4 The transaction data discussed may include information such as the blockchain address of sender 430, digital signature 455, transaction output information 460, and the public key of sender 415. The transaction data can be sent from the first client device 125 to the first server 150.

[0093] The first server 150 may receive transaction data from the first client device 125. In step 610, the first server 150 may broadcast the transaction to the blockchain network 130a. The transaction may be received by one or more nodes 205 of the blockchain network 130a. In step 615, upon receiving a transaction, a node 205 may choose to verify the transaction, for example, based on the transaction fee associated with the transaction. If the transaction is not selected for verification by any node 205, it may be placed in a queue and await selection by a node 205.

[0094] In step 620, each node 205 selected for the transaction can verify the transaction. Verifying a transaction may include determining whether the transaction is legal or conforms to a predefined set of rules, establishing user authenticity, and establishing transaction data integrity. In step 625, if the transaction is successfully verified by node 205, the verified transaction is added to the block constructed by that node 205 (step 630). As described above, since different nodes 205 can choose to verify different transactions, different nodes 205 can construct or assemble blocks containing different verified transactions. Therefore, the transaction associated with the transfer of 10 units of cryptocurrency from the first user 110 to the second user 115 can be included in some blocks but not others.

[0095] In step 635, blockchain network 130a may wait for a block to be published. Verified transactions can be added to the block assembled by node 205 until it reaches the minimum size specified by the blockchain. If blockchain network 130a utilizes a proof-of-work consensus model, node 205 can compete for the right to add its respective block to the blockchain by solving a complex mathematical puzzle. The node 205 that solves its puzzle first wins the right to publish its block. As compensation, the winning node can be rewarded with the transaction fee associated with the transaction (e.g., from the wallet of the first user 110). Alternatively or additionally, the winning node can be rewarded as compensation for the amount of cryptocurrency added from the blockchain network to the account associated with the winning node (e.g., "new" cryptocurrency units entering circulation). This latter method of compensation and releasing new cryptocurrency units into circulation is sometimes referred to as "mining". In step 640, if the block has not yet been published, process 600 returns to step 635 and waits for the block to be published. However, in step 640, if the block has already been published, process 600 proceeds to step 645.

[0096] In step 645, the published block is broadcast to blockchain network 130a for verification. In step 650, if the block is verified by a majority of nodes 205, the verified block is added to blockchain 220. However, if the block is not verified by a majority of nodes 205 in step 650, process 600 proceeds to step 675. In step 675, the block is discarded, and the transactions in the discarded block are returned to a queue. Transactions in the queue can be selected by one or more nodes 205 for the next block. The node 205 that constructed the discarded block can construct the new next block.

[0097] In step 660, if the transaction is added to blockchain 220, server 150 may wait to receive a minimum number of blockchain confirmations for the transaction. In step 665, if the minimum number of confirmations for the transaction has not yet been received, the process may return to step 660. However, if the minimum number of confirmations has been received in step 665, the process proceeds to step 670. In step 670, the transaction can be executed and assets from first user 110 can be transferred to second user 115. For example, after the transaction receives at least three confirmations, 10 units of cryptocurrency owned by first user 110 can be transferred from first user 110's financial account to second user 115's financial account.

[0098] Smart Contracts

[0099] A smart contract is a protocol stored on a blockchain that executes automatically when its predetermined terms and conditions are met. These terms and conditions may be visible to other users on the blockchain. When predefined rules are satisfied, the relevant code executes automatically. This protocol can be written as a script using programming languages ​​such as Java, C++, JavaScript, VBScript, PHP, Perl, Python, Ruby, ASP, and Tcl. This script can then be uploaded to the blockchain as a transaction.

[0100] As an example, a first user 110 (also known as tenant 110) can rent an apartment from a second user 115 (also known as landlord 115). A smart contract can be used between tenant 110 and landlord 115 to handle rent payments. The smart contract can indicate that tenant 110 agrees to pay the next month's rent of $1000 by the 28th of the current month. The agreement can also instruct that if tenant 110 pays the rent, landlord 115 will provide tenant 110 with an electronic receipt and a digital access key to the apartment. The agreement can also indicate that if tenant 110 pays the rent before the 28th of the current month, the access key and rent will be released to tenant 110 and landlord 115 respectively on the last day of the month.

[0101] Figure 6B This is a flowchart illustrating the steps of an example method 601 for executing a smart contract transaction between entities such as tenant 110 and landlord 115. The steps of method 601 can be... Figure 1 The method may be performed by any computing device shown. Alternatively or additionally, some or all of the steps of method 601 may be performed by one or more other computing devices. The steps of method 601 may be modified, omitted, and / or performed in a different order, and / or additional steps may be added.

[0102] In step 676, an agreement or smart contract can be created between tenant 110 and landlord 115, and then submitted as a transaction to blockchain network 130a. The transaction can be added to a block mined by node 205 of blockchain network 130a, and the block containing the transaction can be verified by blockchain network 130a and then recorded in blockchain 220 (as shown in...). Figure 6A (As shown in steps 610-655). The protocol associated with the transaction can be assigned a unique address for identification.

[0103] In step 678, process 601 waits to receive information regarding the conditions related to the agreement. For example, process 601 might wait to receive a notification that $1000 was sent from the blockchain address associated with tenant 110 and received on the 28th of the month at the blockchain address associated with landlord 115. In step 680, if no such notification is received, process 601 returns to step 678. However, if a notification is received in step 680, process 601 proceeds to step 682.

[0104] In step 682, based on the determination that the received notification meets the conditions required to trigger the execution of the various terms of the smart contract, process 601 proceeds to step 684. However, in step 682, if it is determined that the received notification does not meet the conditions required to trigger the execution of the smart contract, process 601 returns to step 678. In step 684, process 601 creates and records a transaction associated with the execution of the smart contract. For example, the transaction may include information about received payments, the date the payments were received, the identifier of tenant 110, and the identifier of landlord 115. The transaction may be broadcast to blockchain network 130a and recorded in blockchain 220 (e.g., ...). Figure 6A The process 600 is illustrated in steps 610-655. If the transaction is successfully recorded in blockchain 220, the transaction can be executed. For example, if payment is received on the 28th, an electronic receipt can be generated and sent to tenant 110. However, on the last day of the month, the digital input key and rent are released to tenant 110 and landlord 115 respectively.

[0105] Smart contracts can execute based on data received from entities not on the blockchain or off-chain resources. For example, a smart contract can be programmed to execute when a temperature reading from a smart sensor or IoT sensor is below 10 degrees Celsius. Smart contracts cannot extract data from off-chain resources. Instead, this data needs to be pushed to the smart contract. Furthermore, because smart contracts are replicated across multiple nodes in the network, even minor changes in the data can cause problems. For example, one node might receive a temperature reading of 9.8 degrees Celsius, while another node might receive a reading of 10 degrees Celsius. Since transaction verification is based on consensus among nodes, even a small change in the received data could cause the smart contract's conditions to be evaluated as unmet. Third-party services can be used to retrieve off-chain resource information and push it to the blockchain. These third-party services may be called oracles. Oracles can be software applications, such as big data applications, or hardware, such as IoT or smart devices. For example, an oracle service could pre-evaluate a received temperature reading to determine if it is below 10 degrees Celsius and then push this information to the smart contract. However, using oracles can introduce another potential point of failure in the process. Oracles may encounter errors, push incorrect information, or even fail.

[0106] Because blockchains are immutable, modifying or updating smart contracts residing on the blockchain can be challenging, making them more expensive and / or more restrictive than text-based contracts.

[0107] Internet of Things (IoT)

[0108] An IoT network may consist of devices and sensors that collect data and forward it to each other via gateways. Gateways can translate between different protocols used by devices and sensors and manage and process the data. For example, IoT devices can collect information from their environment, such as motion, gestures, sound, voice, biometric data, temperature, air quality, humidity, and light. The collected information is sent over the internet for further processing. Typically, IoT devices connect to the internet or the "cloud" using low-power networks, Bluetooth, Wi-Fi, or satellite. Some IoT-related issues that blockchain may be able to detect include a lack of compliance during the manufacturing phase of IoT devices. For example, blockchain can track whether IoT devices have been adequately tested.

[0109] As described above, information from off-chain resources (including IoT devices) can be pushed to smart contracts by a third-party entity called an oracle. As an example, a smart refrigerator can monitor the usage of items stored inside, such as milk. Various sensors within the refrigerator can be used to periodically determine the amount of milk stored. A smart contract stored on the blockchain might indicate that if the stored milk weighs less than 10 ounces, a new carton of milk will be automatically purchased and delivered. The refrigerator sensors can periodically send their readings to a third-party service or oracle. The oracle can evaluate the sensor readings to determine if the condition for purchasing a new carton of milk has been met. When it is determined that the stored milk weighs less than 10 ounces, the oracle can push a message to the smart contract indicating that the execution condition of the smart contract has been met. The smart contract can then be executed, and a new carton of milk can be purchased automatically. Both the execution of the smart contract and the purchase of the new carton can be recorded on the blockchain. In some cases, the condition can be the occurrence of an event, such as a need or anticipated need, or a convenience factor, such as a delivery date, cost, promotion, or incentive.

[0110] Some of the challenges associated with integrating blockchain into the Internet of Things (IoT) include transaction speed and computational complexity. When an IoT network with hundreds or thousands of connected devices is operating and transacting simultaneously, the speed of transaction execution on the blockchain can be critical. IoT devices are often designed for connectivity rather than computation and may therefore lack the processing power to support blockchain consensus algorithms such as Proof-of-Work. IoT devices are also often vulnerable to internet hacking and / or physical tampering. For example, IoT devices may be more susceptible to DDoS and malware attacks. Hackers might target a specific network and begin sending spam to it within a short period. Due to the surge in traffic, bandwidth could quickly become overloaded, potentially causing the entire system to crash.

[0111] Supply chain monitoring and logistics

[0112] A product's supply chain may include a network of entities and activities involved in product creation and its eventual sale to customers. For example, blockchain-based product supply chain records can be used to track the origin of parts and materials and prevent counterfeit parts from entering the supply chain. Integrating blockchain into the product supply chain can leverage IoT devices and data, oracles, and smart contracts. For instance, RFID tags can be attached to products to physically track them and record their location within the supply chain. Furthermore, smart contracts can be used to record various activities and interactions between entities involved in the product supply chain. (See above reference...) Figure 6A and 6B Any data or information that can be digitally represented and electronically stored can be recorded in the blockchain by submitting data as part of a blockchain transaction. When a transaction is included in a verified block added to the blockchain, the transaction and its associated data are recorded in the blockchain.

[0113] For example, permissioned blockchains can be used to record and monitor entities and activities involved in food distribution, such as fruits or vegetables. The blockchain can be accessed by entities such as seed and pesticide suppliers, farmers, distributors, grocery stores, customers, and regulatory bodies. It can record activities such as the sale of pesticides and / or seeds to farmers, the harvesting and packaging of fruit, its transport to distributors' warehouses, its arrival at various stores, and the final purchase by consumers. Sensors and RFID devices can be used to track fruit throughout the supply chain. For example, fruit can be packaged in crates with unique RFID tags. When the tagged crates are loaded onto trucks and transported from the farm to the distributor, the crates may be scanned, and their transport record may be uploaded to the blockchain. When the crates arrive at the warehouse, they may be scanned again, and their arrival record may be uploaded to the blockchain. Furthermore, smart contracts can be executed throughout the supply chain. For example, when a crate is scanned at the warehouse, a smart contract between the farmer and the warehouse can be executed, indicating that the crate has been successfully transported from the farmer to the warehouse and received by the warehouse.

[0114] As another example, a permissioned blockchain for automobiles can store records of entities and activities related to components used in automobile manufacturing. The blockchain is accessible to various entities, such as original equipment manufacturers (OEMs), distributors and suppliers of materials and components, dealerships, mechanics, insurance providers, etc. When assessing an accident involving a policyholder's vehicle, a first user 110 (in this example, insurance provider 110) can determine that the accident may have been caused by a defective component used in the vehicle's wheels. Insurance provider 110 may wish to trace the component's origin based on information recorded in the permissioned blockchain. Insurance provider 110 can query the blockchain data for information related to the component via, for example, a blockchain query application executed on a first client device 120. This query can include identification information associated with the component. For example, the component can be tagged with a unique identifier for that component or a set of components. The query results may include records in the blockchain of entities and activities involved in the creation of the component and its eventual sale to the automobile manufacturer.

[0115] Blockchain supports in-store purchases

[0116] refer to Figure 8 The system 800 shown Figure 6A The process 600 shown is Figure 6B The process 601 shown is used to describe an example of in-store purchasing that supports blockchain. Figure 8 An example of an in-store purchasing system 800 supporting blockchain is shown. System 800 includes a mobile device 805, a merchant system 810, and a server 850 connected via a network 840. The merchant system 810 can connect to various IoT devices within the store, such as in-store smart shelves 815 and in-store smart checkout detectors 830, via a local wireless network.

[0117] A store may include one or more smart shelves, such as in-store smart shelf 815. Smart shelf 815 may include RFID tags, RFID readers, and antennas. One or more products may be stored on in-store smart shelf 815. Each product may include an RFID tag, such as a first product tag 820a attached to a first product 816a and a second product tag 820b attached to a second product 816b. In-store smart shelf 815 can send information about products 816a and 816b to merchant system 810 throughout the day based on reading product tags 820a and 820b. Merchant system 810 can then update the inventory of products currently in the store.

[0118] Shoppers can use mobile device 805 to navigate through the store. A digital shopping list on mobile device 805 can include a list of items the shopper might need to purchase. For example, the shopping list could include items matching the first product 816a. When a shopper approaches an in-store smart shelf 815, mobile device 805 can notify the shopper that the first product 816a is currently available on the in-store smart shelf 815. The shopper can remove the first product 816a from the in-store smart shelf 815 and place it in a smart shopping cart 835. The smart shopping cart 835 can read the first product label 820a and product labels attached to other products that may already be in the smart shopping cart 835. When the shopper is ready to check out, they can push the shopping cart 835 out of the store. As the shopper leaves the store, an in-store smart checkout detector 830 can detect the smart shopping cart 835. The smart shopping cart 835 can communicate with the in-store smart checkout detector 830 and transmit information about the products in the smart shopping cart. The in-store smart checkout detector 830 can send information about the product (e.g., the first product 816a) and payment information from the mobile device 805 to the merchant system 810. The merchant system 810 can receive the information and payment information from the in-store smart checkout detector 830 and proceed with the purchase of the first product 816a.

[0119] refer to Figure 6A In step 605 of process 600 shown, a wallet application on mobile device 805 can generate transaction data for transferring a quantity of cryptocurrency matching the sales price of the first product 816a from the shopper to the merchant. The wallet application can generate a public key for the transaction using the shopper's private key. To demonstrate that the shopper is the initiator of the transaction, a digital signature can also be generated for the transaction using the shopper's private key. The transaction data can then be sent from mobile device 805 to server 850.

[0120] Server 850 can receive transaction data from mobile device 805. In step 610, server 850 can broadcast the transaction to blockchain network 130a. The transaction can be received by one or more nodes 205 of blockchain network 130a. In step 615, upon receiving a transaction, node 205 can choose to verify the transaction, for example, based on the transaction fee associated with the transaction. If the transaction is not selected for verification by any node 205, it can be placed in a queue and wait to be selected by a node 205.

[0121] In step 620, each node 205 selected for the transaction can verify the transaction. In step 625, if the transaction is successfully verified by node 205, then in step 630, the verified transaction is added to the block constructed by node 205. In step 635, the blockchain network 130a can wait for the block to be published. In step 640, if the block has not yet been published, process 600 returns to step 635 and waits for the block to be published. However, in step 640, if the block has already been published, process 600 proceeds to step 645.

[0122] In step 645, the published block is broadcast to blockchain network 130a for verification. In step 650, if the block is verified by a majority of nodes 205, the verified block is added to blockchain 220. In step 660, if the transaction is added to blockchain 220, server 850 may wait to receive a minimum number of blockchain confirmations for the transaction. In step 665, if the minimum number of confirmations for the transaction has not yet been received, the process may return to step 660. However, if the minimum number of confirmations has been received in step 665, the process proceeds to step 670. In step 670, the transaction can be executed and the sales price of the first product 816a can be transferred from the shopper to the merchant.

[0123] When the in-store smart checkout detector 830 sends product information (e.g., the first product 816a) and payment information from the mobile device 805 to the merchant system 810, it can then... Figure 6B The illustrated process 601 creates and executes a smart contract between the shopper and the merchant. For example, in step 676, a smart contract between the shopper and the merchant can be created and then submitted as a transaction to blockchain network 130a. For example, in step 678, process 601 can wait for a notification received at the blockchain address associated with the merchant when the first product 816a is removed from the smart cart 835, after a cryptocurrency amount equal to the sale price of the first product 816a is sent from the blockchain address associated with the shopper. If payment for the first product 816a is successfully transferred from the shopper to the merchant when the shopper removes it from the smart cart 835, an electronic receipt can be generated and sent to the shopper. Otherwise, the merchant system 815 can be alerted that the shopper is attempting to leave the premises without paying for the first product 816a.

[0124] Blockchain supports in-car shopping

[0125] refer to Figure 9 The system 900 shown Figure 6A The process 600 shown is Figure 6B The process 601 shown here is used to describe an example of in-vehicle purchases that support blockchain. Figure 9 An example system 900 for in-vehicle purchases supporting blockchain is shown. System 900 includes an IoT-enabled smart vehicle 908. Vehicle 908 may include one or more computing devices implementing a vehicle system 910, a vehicle navigation system 930, a payment system 960, and a fuel management system 935. Vehicle 908 may include RFID tags, such as vehicle identification tags 912. System 900 may also include various merchant systems, such as a fuel merchant system 915 and a tollbooth system 916. System 900 may also include a mobile device 905 belonging to the driver of vehicle 908.

[0126] When a driver enters vehicle 908, payment information can be loaded from the driver's mobile device 905 into the vehicle payment system 910, allowing for secure payments to other devices to complete in-vehicle purchases, such as fuel purchases and toll payments. Drivers of smart vehicles can use the IoT-enabled smart vehicle 908 to pay for parking and fast food. Furthermore, the IoT-enabled smart vehicle 908 can facilitate in-vehicle purchases of smartphone apps, music, audiobooks, and other goods and services.

[0127] The fuel management system 935 can perform various functions related to fuel usage and communicate with the vehicle system 916. For example, the fuel management system 935 can monitor fuel usage and notify the vehicle system 910 based on the detection that fuel levels are below a threshold. The vehicle system 910 can communicate with the vehicle navigation system 930 to determine nearby gas stations. The selection of a gas station can be based on various factors, such as fuel availability at nearby gas stations, the vehicle's current route and location, and incentives offered by nearby gas stations. The vehicle system 910 can notify the driver about the selected gas station, and the vehicle 908 can be rerouted to the selected gas station. Upon arrival at the selected gas station, the driver can park the vehicle at the fuel pump. The fuel pump may include a fuel pump system 965, which is configured to detect the vehicle's RFID tag, such as a vehicle identification tag 912, to obtain the vehicle's identification. The fuel pump system 965 and the payment system 960 can be configured to communicate with each other. The fuel payment system 960 can send payment information to the fuel pump system 965. After refueling, the driver can simply drive away. The fuel pump system 965 can send information about the vehicle 908's identification, the amount of fuel purchased, and payment information to the fuel merchant system 915. The fuel merchant system 915 can use this information to complete the fuel purchase transaction with the driver. For example, the fuel merchant system 915 can communicate with the server 950 to... Figure 6AThe process shown, 600, collects fuel fees from the driver. Additionally, the fuel merchant system 915 can communicate with the server 950 to create a smart contract between the driver and the fuel merchant. This can be based on... Figure 6B The process shown in step 601 is for creating and executing smart contracts.

[0128] Augmented Reality (AR), Mixed Reality, and Blockchain-Based E-commerce

[0129] AR or mixed reality devices, such as wearable smart glasses, head-mounted displays, holographic devices, or smartphone apps, overlay digital content onto a real-world view, enhancing the user's experience of the real world. The overlay content can be a 3D model generated based on a 3D scan of a real-world object. AR allows users to experience online shopping in a virtual environment. For example, using AR to browse a virtual store and view 3D models of goods for sale. Just like in the real world, customers can handle and examine various physical details of the products. Blockchain smart contracts can be used to provide e-commerce platforms where customers can purchase goods from online merchants using cryptocurrencies and digital wallets. Information about products, such as country of origin, materials, ingredients, price, description, measurements, terms and conditions, and 3D models of physical products, can be hashed and recorded in the blockchain. This provides proof of ownership of virtual goods and products and allows for accurate tracking of any changes made to this information. Artificial intelligence (AI) can be used to generate 3D models of products based on 2D images. Smart contracts can be used to facilitate transactions between merchants and customers.

[0130] For example, customers can browse different stores in a virtual shopping mall to purchase clothing using wearable AR devices (such as smart glasses). Customers can examine 3D models of shirts just like in the real world. Furthermore, customers can virtually try on shirts using a 3D model of their own body. If a customer decides to buy the shirt, they can initiate a transaction with the store's merchant. The transaction can be submitted to the blockchain via the customer's digital wallet to transfer money (cryptocurrency) from the customer to the merchant. Various smart contracts can be used to implement various aspects of the e-commerce process. For example, based on the detection that the sale price of the shirt has been successfully transferred from the customer to the merchant, a smart contract can be executed to initiate the shipment of the shirt from the merchant's warehouse to the customer. As described above in the section on supply chain monitoring and tracking, RFID tags and other IoT devices can be used to track the process of the shirt's transport from the merchant's warehouse to its delivery to the customer's residence.

[0131] Quantum computing

[0132] One concern with quantum computing is that it may increase the likelihood of breaking cryptographic algorithms, thereby weakening the overall security of the blockchain. This can be addressed by requiring certain cryptographic algorithms to use larger key sizes or switching to quantum proof algorithms. In some cases, if there are concerns that blocks may be decrypted in the future, dynamically changing cryptographic hashes can be used. Different cryptographic hashes can be dynamically selected for specific blocks or the entire blockchain based on various factors, such as whether there is a concern that the block may be decrypted in the future, increasing the hash strength, or using a hash more suitable for protecting privacy. In some cases, different cryptographic hashes can be selected for different blocks.

[0133] Anonymity and Privacy

[0134] As mentioned above, using private / public key pairs to establish user authenticity during blockchain transaction verification can provide a degree of privacy because it does not reveal user identity. However, transactions stored on the blockchain may be publicly visible. It has been shown that user identity can be obtained from publicly available transaction information.

[0135] Blockchain size

[0136] The size of a blockchain can grow rapidly depending on the frequency of events recorded within it. Increased computing / storage capacity (i.e., faster processors, larger storage components) may be required to support this expansion. In some cases, blocks can be compressed before being added to the chain. In other cases, blocks may be eliminated, for example, at the beginning of the blockchain when they become stale or irrelevant. For instance, replacing the first 1000 transactions with a new block that effectively mimics the hashes of 1000 transactions could be useful for managing blockchain size.

[0137] Blockchain immutability

[0138] In some cases, it may be necessary to delete content from the blockchain. For example, if a security vulnerability exists or the content is no longer relevant, deletion may be required. The level of immutability of a blockchain can vary depending on its type. For instance, changing content in a public blockchain can be difficult because it could affect a large number of users. According to some technologies, data stored on a private blockchain or a public blockchain controlled by a few entities can be altered by recording a flag indicating a change (the current block) and adding the current block (referenced by the flag) to the blockchain. The added block can then indicate the changes made to the previous block.

[0139] As another example, changes to the blockchain may be necessary to resolve broken links. For instance, the hash of a modified block might no longer match the hash stored in block +1. In some cases, changes to the blockchain may be needed to reverse the consequences of illicit transactions. In other cases, changes may be required to resolve software errors, erroneous transactions, or to remove confidential or legally mandated information. If the blockchain is immutable, these errors and information could be permanently embedded within it. Furthermore, blockchains may need to be modified to comply with regulatory issues such as the EU's upcoming General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA) concerning consumer data privacy and ownership, the Fair Credit Reporting Act requiring editable user-identifiable personal financial data, and the SEC's Regulations SP.

[0140] Certain technologies may allow modification of the blockchain to address software bugs, legal and regulatory requirements, etc., by allowing designated entities to edit, rewrite, or delete previous blocks without breaking the blockchain. Such technologies can achieve blockchain editing by using variants of the "chameleon" hash function and secure private keys. This editing may allow for updating problematic smart contracts so that changes are carried over to subsequent smart contracts in the blockchain. Using these technologies, altered blocks may contain "scars" or marks that cannot be removed even by trusted parties.

[0141] According to some technologies, when a block is hashed, any confidential information (such as personally identifiable information and IP addresses) is not included in that block because it is not part of the hashed data value. However, since confidential information is not hashed, it can be altered. According to some technologies, confidential information may not be placed or recorded in the blockchain. More precisely, the information may reside in a file outside the blockchain. However, the hash of that file may be recorded in the blockchain. For example, a user's confidential information can be deleted locally without affecting the blockchain.

[0142] As another example, assuming that everything contained in a block within the blockchain cannot be changed after it is added, it is possible to determine whether some or all of that data needs to be deleted later before it is added to the blockchain. For example, confidential information (i.e., data to be deleted later) could be stored as a file outside the block and the blockchain. For the purpose of creating a block, a link to the file containing the confidential information and the hash of the file containing the confidential information could be added to the block. An HTTP link is an example of such a link. During the confirmation of a block to be added to the blockchain, network nodes are able to access the confidential information and verify it based on the hash of the file within the block. Since the hash of the file is part of the block, the file containing the confidential information may not be easily altered. However, the confidential information file could be changed by altering the data within it and adding a random number. This might involve changing the random number until the resulting hash equals the hash stored in the blockchain. However, this would be very difficult (possibly almost impossible), and an inspection of the modified confidential information file would reveal the added random number, potentially raising suspicion that the information has been altered since it was first added to the blockchain.

[0143] Files containing confidential information can be encrypted before hashing (e.g., using asymmetric key encryption). When confidential information is "deleted," the file containing it may be deleted or removed, rendering links stored in the blockchain unretrievable. The file's hash and link remain in the blockchain, so blockchain connections via hash functions are unaffected. However, due to this change, transactions that are part of that block or a different special block can be added to the blockchain to indicate that the link is no longer valid and the confidential information file is no longer part of the blockchain. This effectively excludes confidential information from the blockchain while providing the confidential information to blockchain users and proving its authenticity before it is deleted from the blockchain. This can have drawbacks because access to the data implies the ability to store such data. Therefore, those with access to the confidential information file, even though it is part of the blockchain, may have already stored that information in another location that may no longer be accessible during the aforementioned "deletion" operation.

[0144] 51% attack

[0145] A "51% attack" refers to a situation where a single mining node or a group of mining nodes controls more than 50% of the mining power of a blockchain network, also known as hash rate or hash power. Hash rate is a measure of the rate at which hashes are computed on a blockchain network. As mentioned above, hashing can involve taking an input string of a given length and running it through a cryptographic hash function to produce a fixed-length output. The hash rate of a blockchain network can be expressed as 1 kilohashes per second (1,000 hashes per second), 1 megahashes per second (1,000,000 hashes per second), 1 thahashes per second (1,000,000,000,000 hashes per second), or 1 petahashes per second (1,000,000,000,000,000 hashes per second). For example, mining nodes in a blockchain using the Proof-of-Work (PoW) consensus model can perform hashing to find solutions to difficult mathematical problems. The hash rate of a mining node may depend on the computing resources available to that node. A mining node that successfully solves a mathematical problem may be able to add a block to the blockchain. Therefore, by ensuring that invalid transactions are not included in blocks, mining nodes improve the reliability of the network. A transaction might be considered invalid if it attempts to spend more money than currently possessed or engages in double-spending. If a mining node intentionally or unintentionally includes invalid transactions in a block, that block will not be validated by the network. Furthermore, nodes that accept invalid blocks as valid blocks and continue adding blocks on top of them ultimately waste computational resources. Therefore, mining nodes do not cheat by intentionally adding invalid transactions to blocks and accepting invalid blocks as valid blocks.

[0146] An entity could potentially disrupt the network by controlling 50% of its hash rate. In a 51% attack, blockchain nodes could intentionally reverse or overwrite transactions and double-spend. When a node generates a valid block of transactions, it broadcasts the block to the network for verification. In some cases, a node controlling more than 50% of the network hash rate might mine blocks privately without broadcasting them to the network. In this scenario, the rest of the network might follow the public version of the blockchain, while the controlling node might follow its private version. Figure 7A The diagram shows the fraudulent and valid versions of blockchain 700. The valid blockchain at the top includes valid blocks 705, 710a, 715a, and 720. The fraudulent blockchain at the bottom is not broadcast to the network and includes blocks 705, 710b, 715b, and the invalid block 720.

[0147] Figure 7BThis illustrates another fraudulent and valid version of the blockchain. The valid version of the blockchain includes nodes 740, 745a, 750a, and 755a. The fraudulent version of the blockchain includes nodes 740, 745b, 750b, 755b, and 775. However, following the longest chain rule, the network can choose and utilize a private or fraudulent blockchain that includes nodes 740, 745b, 750b, 755b, and 775. Because it is the longest chain, previous transactions may be updated based on this chain. A cheating node might include spending transactions on the public or fraudulent version of the blockchain, such as block 750b containing a 150 BTC transaction, without including these transactions in the private version of the blockchain. Therefore, in the private version of the blockchain, the cheating node might continue to possess the spent 150 BTC. When a cheating node controls more than 50% of the network's hash resources, it may be able to broadcast its private version of the blockchain and continue to create blocks on the private blockchain faster than other nodes in the network, resulting in an even longer blockchain. Because there are two versions of the blockchain, the network might choose the longest or a fraudulent private blockchain as the valid blockchain. Therefore, the rest of the network might be forced to use the longer blockchain. The public or valid version of the blockchain can then be discarded or abandoned, and all transactions in that blockchain that are not included in the private or fraudulent version can be reversed. Controlling or cheating nodes might continue to possess the spent money because the spending transaction is not included in the fraudulent version of the blockchain, allowing the cheating node to spend that money in future transactions.

[0148] A successful 51% attack is often difficult to achieve due to the financial resources required to obtain more hash power than the rest of the network combined. However, it is less expensive to carry out a 51% attack on a network with a lower hash rate than on a network with a higher hash rate. Furthermore, the probability of a successful 51% attack increases with the use of mining pools that combine the computational resources of multiple nodes, for example, when mining is performed from the same pool.

[0149] computing devices

[0150] Figure 10System 1000 is illustrated. System 1000 may include at least one client device 1010 (also referred to as a "control processing device"), at least one database system 1020, and / or at least one server system 1030 communicating via network 1040. It should be understood that the network connections shown are illustrative and any means of establishing a communication link between computers may be used. It is assumed that various network protocols such as TCP / IP, Ethernet, FTP, HTTP, etc., and various wireless communication technologies such as GSM, CDMA, WiFi, and LTE are present, and the various computing devices described herein can be configured to communicate using any of these network protocols or technologies. Any device and system described herein may use, in whole or in part, the technologies described herein. Figure 10 The description refers to one or more computing systems that implement this.

[0151] Client device 1010 may use one or more client applications (not shown) as described herein to access server applications and / or resources. Client device 1010 may be a mobile device, such as a laptop computer, smartphone, mobile phone, or tablet computer, or a computing device, such as a desktop computer or server, wearable device, or embedded device. Alternatively, client device 1010 may include other types of devices, such as game consoles, cameras / video recorders, video players (e.g., combining DVD, Blu-ray, red laser, optical, and / or streaming technologies), smart TVs, and other network-connected devices (if applicable).

[0152] Database system 1020 can be configured to maintain, store, retrieve, and update information of server system 1030. Furthermore, database system 1020 can periodically or on request provide information to server system 1030. In this respect, database system 1020 can be a distributed database capable of storing, maintaining, and updating large amounts of data across a cluster of nodes. Database system 1020 can provide various types of databases, including but not limited to relational databases, hierarchical databases, distributed databases, in-memory databases, flat file databases, XML databases, NoSQL databases, graph databases, and / or combinations thereof.

[0153] Server system 1030 may be configured with server applications (not shown) capable of interfaceing with client applications and database system 1020 as described herein. In this respect, server system 1030 may be a standalone server, an enterprise server, or a server located in a server farm or cloud computing environment. According to some examples, server system 1030 may be a virtual server hosted on hardware capable of supporting multiple virtual servers.

[0154] Network 1040 may include any type of network. For example, network 1040 may include a local area network (LAN), a wide area network (WAN), a wireless telecommunications network, and / or any other communication network or combination thereof. It should be understood that the network connections shown are illustrative and any means of establishing a communication link between computers may be used. It is assumed that various network protocols such as TCP / IP, Ethernet, FTP, HTTP, etc., and various wireless communication technologies such as GSM, CDMA, WiFi, and LTE are present, and the various computing devices described herein can be configured to communicate using any of these network protocols or technologies.

[0155] Data transmitted to and from various computing devices within System 1000 may include secure and sensitive data, such as confidential documents, customer personally identifiable information, and account data. Therefore, it may be desirable to use secure network protocols and encryption to protect the transmission of such data and / or to protect its integrity when stored on various computing devices. For example, file-based or service-based integration schemes may be used to transfer data between various computing devices. Various network communication protocols can be used to transmit data. Secure data transmission protocols and / or encryption can be used in file transfers to protect data integrity, such as File Transfer Protocol (FTP), Secure File Transfer Protocol (SFTP), and / or Privacy Good Protocol (PGP) encryption. In many implementations, one or more network services may be implemented within various computing devices. Web services may be accessible by authorized external devices and users to support the input, retrieval, and manipulation of data between various computing devices within System 1000. Web services built to support personalized display systems may be cross-domain and / or cross-platform and may be built for enterprise use. Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocols can be used to transmit data to provide secure connections between computing devices. Web services can be implemented using the WS-Security standard, thereby providing secure SOAP messages using XML encryption. Dedicated hardware can be used to provide secure network services. For example, secure network devices may include built-in features such as hardware-accelerated SSL and HTTPS, WS-Security, and / or firewalls. Such dedicated hardware can be installed and configured in front of one or more computing devices in System 1000, allowing any external device to communicate directly with the dedicated hardware.

[0156] Turn now Figure 11This describes a computing device 1105 that can be used with one or more computing systems. The computing device 1105 may include a processor 1103 and associated components for controlling the overall operation of the computing device 1105, including RAM 1105, ROM 1107, input / output devices 11011, communication interfaces 1111, and / or memory 1115. A data bus may interconnect the processor 1103, RAM 1106, ROM 1107, memory 1115, I / O devices 1109, and / or communication interfaces 1111. In some embodiments, the computing device 1105 may represent, incorporate, and / or include various devices, such as desktop computers, computer servers, mobile devices (e.g., laptop computers, tablet computers, smartphones), any other type of mobile computing device, and / or any other type of data processing device.

[0157] Input / output (I / O) devices 1109 may include input microphones, keypads, touchscreens and / or stylus movements and gestures that can be provided by the user of computing device 1105, and may also include one or more speakers for providing audio output and video display devices for providing text, audiovisual and / or graphical output. Software may be stored in memory 1115 to provide instructions to processor 1103, thereby allowing computing device 1105 to perform various actions. For example, memory 1115 may store software used by computing device 1105, such as operating system 1117, application programs 1119 and / or associated internal database 1121. Various hardware memory units in memory 1115 may include volatile and non-volatile, removable and non-removable media implemented for any method or technology for storing information such as computer-readable instructions, data structures, program modules or other data. Memory 1115 may include one or more physically persistent memory devices and / or one or more non-persistent memory devices. The memory 1115 may include, but is not limited to, random access memory (RAM) 1106, read-only memory (ROM) 1107, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, optical disc storage, magnetic tape cassette, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by the processor 1103.

[0158] The communication interface 1111 may include one or more transceivers, digital signal processors and / or additional circuitry and software for communicating via any wired or wireless network using any protocol described herein.

[0159] Processor 1103 may include a single central processing unit (CPU), which may be a single-core or multi-core processor, or may include multiple CPUs. Processor 1103 and associated components may allow computing device 1100 to execute a series of computer-readable instructions to perform some or all of the processes described herein. Although Figure 11 Not shown, but various elements within memory 1115 or other components in computing device 1105 may include one or more caches, such as a CPU cache used by processor 1103, a page cache used by operating system 1117, a hard disk drive, and / or a database cache for caching content from database 1121. In embodiments including a CPU cache, the CPU cache may be used by one or more processors 1103 to reduce memory latency and access time. Instead of reading / writing data from / to memory 1115, processor 1103 may retrieve or write data from the CPU cache, which can improve the speed of these operations. In some examples, a database cache may be created where some data from database 1121 is cached in a separate, smaller database in memory separate from the database, such as RAM 1106 or a separate computing device. For example, in a multi-tiered application, a database cache on an application server can reduce data retrieval and data manipulation time by eliminating the need to communicate with a backend database server over a network. These types of caches and other types of caches can be included in various implementations and can provide potential advantages in some implementations of the devices, systems and methods described herein, such as faster response times when sending and receiving data and less dependence on network conditions.

[0160] Although the individual components of computing device 1105 are described separately, the functions of the individual components may be combined and / or performed by a single component and / or multiple computing devices communicating with each other without departing from the present invention.

[0161] Invention Description

[0162] Figure 12A networking system 1200 is illustrated, within which a multi-party computing system according to one embodiment of the present disclosure can be implemented. Note, however, that the technology can be applied to many different computing and technical environments and is not limited to those shown in the figures. The networking system 1200 includes a network of service provider servers 1230, merchant servers 1220, user equipment 1210, and computer nodes 1270, 1280, and 1290 that can be communicatively coupled to each other via a network 1260. In one embodiment, the network 1260 can be implemented as a single network or a combination of multiple networks. For example, in various embodiments, the network 1260 may include the Internet and / or one or more intranets, terrestrial networks, wireless networks, and / or other suitable types of communication networks. In another example, the network 1260 may include a wireless telecommunications network (e.g., a cellular telephone network) adapted to communicate with other communication networks such as the Internet.

[0163] In one implementation, user 1240 may use user equipment 1210 to interact with merchant server 1220 and / or service provider server 1230 via network 1260. User 1240 may be a natural person or entity (e.g., a company, partnership, organization, etc.). For example, user 1240 may use user equipment 110 to conduct online transactions with merchant server 120 via a website hosted by merchant server 1220 or a mobile application associated with merchant server 1220. User 1240 may also log in to a user account to access account services or conduct electronic transactions with service provider server 1230 (e.g., account transfers or payments, cryptocurrency transactions, etc.). In various implementations, user equipment 1210 may be implemented using any suitable combination of hardware and / or software configured for wired and / or wireless communication via network 1260. In various implementations, user equipment 1210 may include at least one of wireless cellular phones, wearable computing devices, PCs, laptops, etc.

[0164] In one implementation, user device 1210 includes a user interface (UI) application 1212 (e.g., a web browser, mobile payment application, etc.) that user 1240 can use to interact with merchant server 1220 and / or service provider server 1230 via network 1260. In one implementation, the UI application 1212 includes software programs (e.g., mobile applications) that provide user 1240 with a graphical user interface (GUI) for interface connection and communication with service provider server 1230 and / or merchant server 1220 via network 1260. In another implementation, the UI application 1212 includes a browser module that provides a network interface for browsing available information via network 1260. For example, the UI application 1212 may be partially implemented as a web browser to view available information via network 1260.

[0165] User device 1210 may include a digital wallet application 1216 for facilitating payment transactions with merchant server 1220 and / or service provider server 1230. In some embodiments, digital wallet application 1216 may include data associated with one or more funding sources (e.g., credit cards, debit cards, bank accounts, etc.) that can be used for payments in one or more payment transactions with merchant server 1220 and / or service provider server 1230. In some embodiments, digital wallet application 1216 may include data associated with cryptocurrency accounts (e.g., private keys associated with cryptocurrency accounts) that can be used to execute cryptocurrency transactions with merchant server 1220, service provider server 1230, or any other cryptocurrency digital wallet.

[0166] In one implementation, user equipment 1210 may include at least one identifier 1214, which may be implemented as, for example, an operating system registry entry, a cookie associated with user interface application 1212 and / or authentication application 1216, an identifier associated with the hardware of user equipment 1210 (e.g., a media control access (MAC) address), or various other suitable identifiers. In various implementations, identifier 1214 may be transmitted via network 1260 to service provider server 1230 along with a user login request, and identifier 1214 may be used by service provider server 1230 to associate user 1240 with a specific user account (e.g., and a specific profile) maintained by service provider server 1230.

[0167] In various implementations, user 1240 is able to input data and information into the input component (e.g., keyboard) of user device 1210. For example, user 1240 can use the input component to interact with UI application 1212 (e.g., to retrieve content from a third-party server such as merchant server 1220, to provide target-related input to service provider server 1230, etc.).

[0168] Although Figure 12 Only one user device 1210 is shown, but it is envisioned that multiple user devices, each associated with a different user account of the service provider server 1230, can be connected to user device 1210, merchant server 1220 and service provider server 1230 via network 1260.

[0169] In various implementations, the merchant server 1220 may be maintained by a business entity (or, in some cases, by a partner of the business entity that processes transactions on its behalf). Examples of business entities include merchants, resource information providers, utility providers, real estate management providers, social networking platforms, etc., which provide access to and / or purchase of various items and process payments for purchases. As shown, the merchant server 1220 may include a merchant database 1224 for identifying available items, which may be items that can be obtained by the user device 1210 for the user to view and purchase.

[0170] In one implementation, merchant server 1220 may include a marketplace application or server 1222, which may be configured to provide information (e.g., display content) to user interface application 1212 of user device 1210 via network 1260. In one implementation, marketplace application 1222 may include a web server hosting a merchant's website. For example, user 1240 of user device 1210 may interact with marketplace application 1222 via user interface application 1212 through network 1260 to search and view various items in merchant database 1224 that can be accessed and / or purchased. In one implementation, merchant server 1220 may include at least one merchant identifier 1226, which may be included as part of one or more items available for purchase, such that, for example, a specific item is associated with a specific merchant. In one implementation, merchant identifier 1226 may include one or more attributes and / or parameters associated with the merchant, such as business and banking information. Merchant identifier 1226 may include attributes associated with merchant server 1220, such as identification information (e.g., serial number, location address, GPS coordinates, network identifier, etc.).

[0171] Although Figure 12Only one merchant server 1220 is shown, but it is envisioned that multiple merchant servers, each associated with a different merchant, can be connected to the user equipment 1210 and the service provider server 1230 via network 1260.

[0172] Each of the network of computer nodes 1270, 1280, and 1290 (e.g., a sharding network) can correspond to a shard chain of the blockchain. The blockchain can be associated with a specific trading platform, such as a specific cryptocurrency, a specific platform for recording and managing smart contracts, etc. In the example where the blockchain is associated with a specific cryptocurrency (e.g., Bitcoin, Ethereum, etc.), the blockchain can be associated with a specific trading platform, and the blockchain can record all transactions made using that specific cryptocurrency. When a new transaction using that specific cryptocurrency is initiated, the new transaction can be recorded within the blockchain when the computer nodes associated with the blockchain verify the new transaction (e.g., using proof-of-work or proof-of-stake mechanisms, etc.). In another example, the blockchain can be associated with a specific trading platform for executing smart contracts. The blockchain can record all smart contracts executed through that specific trading platform. When a new smart contract is executed, the smart contract can be recorded in the blockchain after it has been verified by the computer nodes associated with the blockchain. These records can include digital signatures representing the legitimacy of the corresponding block (and the corresponding transaction). Once a block is inserted into the blockchain, that block is no longer immutable. Therefore, as more transactions are recorded, the size of the blockchain will continue to grow.

[0173] As discussed in this article, the speed and efficiency of adding additional transactions to the blockchain can be impacted as the blockchain size increases. One solution to improve blockchain-related performance is to divide the blockchain into separate shard chains, each corresponding to a different part of the blockchain. In some implementations, computer nodes configured to store and manage the blockchain are divided into various groups (e.g., various shard networks), and shard chains are used for storing and managing the blockchain individually. In this way, each group of computer nodes (e.g., each shard network) can be responsible for storing and managing its corresponding shard chain. Since each shard chain contains only a small portion of the entire blockchain, the processing resources required to operate a shard chain are significantly less than those required to operate the entire blockchain, thereby greatly improving the overall speed and efficiency of operating the blockchain.

[0174] In one example, the blockchain may be divided into three independent shard chains. However, in another example, the shard chains can be created individually and together form a new blockchain. In either case, each shard chain can be managed by different networks of computer nodes (e.g., shard network 1270, shard network 1280, and shard network 1290). Thus, computer nodes in each shard network can store copies of their corresponding shard chains and can be configured to manage their respective shards (e.g., generate blocks and append blocks to their corresponding shards). For example, computer nodes in shard network 1270 can store various copies of the first shard chain of the blockchain and can be configured to record transactions to the first shard chain. Computer nodes in shard network 1280 can store various copies of the second shard chain of the blockchain and can be configured to record transactions to the second shard chain. Computer nodes in shard network 1290 can store various copies of the third shard chain of the blockchain and can be configured to record transactions to the third shard chain. In some implementations, each group of computer nodes can be configured to verify transactions using a verification mechanism (as discussed herein) before adding them to the corresponding shard chain. In some implementations, transactions involving wallets processed in separate shards (i.e., inter-shard transactions) can be managed individually via the collaboration of designated nodes in each shard.

[0175] In one implementation, the service provider server 1230 may be maintained by a transaction processing entity or online service provider that can process electronic transactions between a user of user device 1210 and one or more merchants or other types of payees. Thus, the service provider server 1230 may include a service application 1238, which may be adapted to interact with user device 1210 and / or merchant server 1220 via network 1260 to facilitate item search, selection, purchase, payment, transaction authentication, and / or other services provided by the service provider server 1230. In one example, the service provider server 1230 may be located in San Jose, California, USA. nc. and / or one or more service entities or corresponding intermediaries may provide multiple point-of-sale devices in different locations to facilitate transaction routing between merchants and, for example, service entities.

[0176] In some implementations, service application 1238 may include a payment processing application (not shown) for processing the purchase and / or payment of electronic transactions between users and merchants or between any two entities (e.g., between two users, etc.). In one implementation, the payment processing application assists in resolving electronic transactions through verification, delivery, and settlement. Thus, the payment processing application resolves debts between users and merchants, where accounts can be directly and / or automatically debited and / or credited with monetary funds. In some implementations, to process fiat payment transactions, service application 1238 may communicate via a payment network with various servers associated with issuing and / or acquiring banks (e.g., through a series of commands). In some implementations, to process cryptocurrency payment transactions, service application 1238 may communicate with various computer nodes associated with a blockchain (e.g., computer nodes in sharded networks 1270, 1280, or 1290).

[0177] Service provider server 1230 may also include interface server 1234 configured to provide content (e.g., web page content) to users and interact with them. For example, interface server 1234 may include a web server configured to provide web page content in response to HTTP requests. In another example, interface server 1234 may include an application server configured to interact with a corresponding application (e.g., a service provider mobile application) installed on user device 1210 via one or more protocols (e.g., REST API, SOAP, etc.). Thus, interface server 1234 may include pre-generated electronic content ready to be provided to users. For example, interface server 1234 may store login pages and be configured to provide login pages to users for logging into their user accounts to access various services provided by service provider server 1230. Interface server 1234 may also include other electronic pages associated with different services (e.g., electronic transaction services, etc.) provided by service provider server 1230. As a result, a user (e.g., user 1240) or a merchant associated with merchant server 1220 can access the user account associated with that user and access various services provided by service provider server 1230 (e.g., various transactions such as payment transactions and data access transactions through the user's user account) by generating an HTTP request to service provider server 1230.

[0178] In one implementation, the service provider server 1230 can be configured to maintain one or more user accounts and merchant accounts (e.g., digital wallet accounts, etc.) in an account database 1236, wherein each user account and merchant account can be associated with a profile and can include account information associated with one or more individual users (e.g., user 1240 associated with user device 1210, etc.) and merchants (e.g., funding sources linked to digital wallet application 1216, keys associated with cryptocurrency wallet accounts, etc.). In one implementation, a user can have credentials to authenticate or verify their identity with the service provider server 1230. Therefore, the service provider server can store the user's credentials in a corresponding record in the account database 1236 associated with the user account.

[0179] In various implementations, the service provider server 1230 includes a multi-party computation (MPC) module 1232 that implements at least a portion of the multi-party computation system discussed herein. The MPC module 1232 can configure computer nodes in various sharded networks to perform a verification process using the multi-party computation techniques disclosed herein to verify electronic transactions conducted through one or more shard chains. Thus, the MPC module 1232 can access each shard chain of the blockchain and shard networks 1270, 1280, and 1290. The MPC module 1232 can determine various metrics characterizing the computer nodes within the shard chains and / or shard networks. These metrics may include chain metrics representing characteristics of the entire blockchain, shard metrics representing characteristics of the shard chains, transaction metrics representing characteristics of transactions recorded in the shard chains, and node metrics representing characteristics of the computer nodes within the shard networks. Based on these metrics, the MPC module 1232 can determine a multi-party computation scheme for each shard chain. The multi-party computation scheme can specify a threshold number of computer nodes required to participate in the verification process for verifying transactions on the corresponding shard chain. In some implementations, the multi-party computation scheme may also specify one or more required ("mandatory") computer nodes to participate in the verification process in order to verify transactions on the corresponding shard chain. The MPC module 1232 may also implement the multi-party computation scheme in the computer nodes of the corresponding shard network, enabling the computer nodes to use the multi-party computation scheme to verify transactions to be recorded on the corresponding shard chain.

[0180] Figure 13A sharded environment 1300 associated with blockchain 1310 is illustrated. In this example, blockchain 1310 may be associated with a specific cryptocurrency or a specific trading platform. Blockchain 1310 is managed by a network of computer nodes (blockchain network) 1320. Thus, each computer node in blockchain network 1320 can store a copy of blockchain 1310 and can be configured to manage blockchain 1310 (e.g., perform transaction verification and record transactions in the blockchain, etc.). As discussed herein, as the size of blockchain 1310 grows (e.g., transactions continue to be recorded to blockchain 1310), the computational resources required for each computer node in the blockchain network of computer nodes 1320 to perform transaction verification and recording also increase. As a result, the speed and efficiency performance of operating blockchain 1310 may be affected.

[0181] In some implementations, to improve the performance of operating blockchain 1310, the blockchain may undergo a sharding process, wherein the blockchain can be divided into multiple shard chains 1312, 1314, and 1316. Each of shard chains 1312, 1314, and 1316 may correspond to a different portion of blockchain 1310, and the combination of shard chains 1312, 1314, and 1316 constitutes blockchain 1310. The sharding of blockchain 1310 can be performed in different ways. For example, blockchain 1310 may be sharded based on user accounts (e.g., cryptocurrency wallet accounts), such that transactions associated with a first one or more user accounts are recorded in shard chain 1312, transactions associated with a second one or more user accounts are recorded in shard chain 1314, and transactions associated with a third one or more user accounts are recorded in shard chain 1316. In another example, blockchain 1310 can be divided based on the geographical regions where transactions take place, such that transactions in the first one or more regions are recorded in shard chain 1312, transactions in the second one or more regions are recorded in shard chain 1314, and transactions in the third one or more regions are recorded in shard chain 1316.

[0182] As discussed herein, in some implementations, instead of dividing an existing blockchain into multiple shard chains, shard chains 1312, 1314, and 1316 can be created separately, and these shard chains 1312, 1314, and 1316 together form a new blockchain. Therefore, the sharding process can involve the initial creation of shard chains 1312, 1314, and 1316 of the new blockchain.

[0183] In some implementations, the sharding process can further divide the blockchain network of computer node 1320 into multiple shard networks, each responsible for storing and managing its corresponding shard chain. In this example, blockchain network 1320 can be divided into shard networks 1322, 1324, and 1326. Alternatively, when shard chains 1312, 1314, and 1316 are created separately, shard networks 1322, 1324, and 1326 can be independently assigned to each shard chain. Shard network 1322 can be configured to store and manage shard chain 1312, shard network 1324 can be configured to store and manage shard chain 1314, and shard network 1326 can be configured to store and manage shard chain 1316. Although shard chain 1310 and blockchain network 1320 are divided into three shard chains and three shard networks respectively, it should be noted that blockchain 1310 and blockchain network 1320 can be divided into any number of shard chains and shard networks as needed (e.g., 5, 10, 100, etc.). Alternatively, any number of shard chains can be created to form a new blockchain. In some implementations, to facilitate the synchronization of transactions added to shard chains 1312, 1314, and 1316, a central chain (also called a “beacon chain”) 1350 can be generated. The central chain 1350 is configured to track all changes occurring to shard chains 1312, 1314, and 1316, making a trusted version of the entire blockchain 1310 easily accessible via the central chain 1350. Furthermore, the central chain 1350 can be used during the verification of new transactions to be added to any of shard chains 1312, 1314, and 1316. For example, when verifying a new transaction on a shard chain, computer nodes within the corresponding shard network can verify the new transaction based on previous transactions recorded in the central chain 1350 (e.g., to ensure that the funds used in the new transaction were not spent in a previous transaction on another shard chain, etc.).

[0184] In one implementation, each block in central chain 1350 may include a crosslink connecting the blockchain of central chain 1350 to a corresponding block in shard chains 1312, 1314, and 1316. Since there are three shard chains in this example, each block in central chain 1350 may include three crosslinks, each connecting the blockchain of central chain 1350 to a block in a corresponding shard chain. These crosslinks enable synchronization between each of shard chains 1312, 1314, and 1316 and central chain 1350, and also enable communication between shard chains 1312, 1314, and 1316 (e.g., for transactions involving digital wallets associated with different shard chains). More details on the operation of the central chain and shard chains can be found in the article: The Beacon Chain Ethereum 2.0 (https: / / ethos.dev / beacon-chain / ).

[0185] Because each shard network is configured to store and manage only much smaller shard chains (in this example, each shard chain could be approximately one-third the size of blockchain 1310), the computing resources required to validate and record new transactions in each of shard chains 1312, 1314, and 1316 are likely significantly less than those required to validate and record new transactions in blockchain 1310. However, while the sharding environment 1300 improves the speed and efficiency of operating blockchain 1310, it also introduces (or increases) security risks to shard chains 1312, 1314, and 1316. For example, to launch a 51% attack on blockchain 1310 before sharding, a malicious user would need to control (e.g., take over) more than half of the computer nodes in blockchain network 1320 before the sharding process. Therefore, if blockchain network 1320 comprises 90 computer nodes, a malicious user might need to control more than 45 computer nodes. After blockchain 1310 is divided into shard chains 1312, 1314, and 1316, and since blockchain network 1320 is also divided into three shard networks, each of which can include 30 computer nodes, a malicious user may only need to control 15 computer nodes to compromise the integrity of each shard chain, which is much easier than controlling more than 45 computer nodes. Therefore, according to various embodiments of this disclosure, MPC module 1232 can be configured to implement a multi-party computation process in each of the shard networks 1322, 1324, and 1316 to verify the transactions to be recorded in each shard chain 1312, 1314, and 1316, thereby improving the security of shard chains 1312, 1314, and 1316.

[0186] Figure 14A block diagram of an MPC module 1232 according to an embodiment of the present disclosure is shown. The MPC module 1232 includes an MPC manager 1402, a sharding interface 1404, a sharding analysis module 1406, a configuration module 1408, and a verification module 1410. In some embodiments, the MPC module 1232 may be communicatively coupled to a central chain 1350 and sharding networks 1322, 1324, and 1326 configured to manage shards 1312, 1314, and 1316, respectively. The MPC module 1232 may collaborate with computer nodes in sharding networks 1322, 1324, and 1326 to configure and implement multi-party computation schemes for sharding chains 1312, 1314, and 1316, respectively. In some embodiments, the MPC module 1232 may be configured to facilitate the synchronization of blockchain 1310 by managing the central chain 1350. For example, MPC module 1232 can be configured to add any new transaction that will be verified to be added to any of the shard chains 1312, 1314 and 1316 to the central chain 1350.

[0187] In some implementations, the sharding analysis module 1406 can access each of the sharding networks 1322, 1324, and 1326 via the sharding interface 1404 to analyze the computer nodes and copies of the shard chains stored in those nodes. For example, the sharding analysis module 1406 can access copies of shard chains 1312, 1314, and 1316 stored in the sharding networks 1322, 1324, and 1306. The sharding analysis module 1406 can analyze the copies of shard chains 1312, 1314, and 1316 to determine chain metrics. Since the combination of shard chains 1312, 1314, and 1316 corresponds to the entire blockchain 1310, the sharding analysis module 1406 can determine chain metrics representing various characteristics of the blockchain 1310 based on the analysis of shard chains 1312, 1314, and 1316. Chain metrics can represent various characteristics of blockchain 1310, such as the size of blockchain 1310 (e.g., the number of transactions or blocks recorded in blockchain 1310, the total or average value of transactions, the memory size of blockchain 1310, etc.), the age of blockchain 1310 (e.g., the average age of transactions recorded in blockchain 1310, etc.), the rate or frequency at which blockchain 1310 is added (e.g., added to any of shard chains 1312, 1314, and 1316), and other information associated with blockchain 1310.

[0188] Sharding analysis module 1406 can also determine sharding metrics for each individual shard chain (e.g., shard chain 1312). Sharding metrics can represent various characteristics of the shard chain, such as the size of the shard chain (e.g., the number of transactions or blocks recorded in shard chain 1312), the age of blocks in the shard chain (e.g., average age), the rate or frequency at which blocks are added to the shard chain, and other information related to the shard chain.

[0189] The sharding analysis module 1406 can also determine transaction metrics for each shard chain (e.g., shard chain 1312) that represent the characteristics of transactions recorded in each shard chain. For example, transaction metrics may represent the amount or value of transactions recorded in shard chain 1312 (e.g., average, minimum, maximum, etc.), the number of transactions recorded in shard chain 1312, the rate or frequency of transactions recorded in shard chain 1312, the volatility of transactions recorded in shard chain 1312, the characteristics of the user and / or user device used to conduct transactions recorded in shard chain 1312, the geographical region where transactions are conducted in shard chain 1312, and other information associated with transactions recorded in shard chain 1312.

[0190] The sharding analysis module 1406 can also determine node metrics for each shard chain (e.g., shard chain 1312) that represent the characteristics of computer nodes within a sharding network (e.g., sharding network 1322) configured to store and manage shard chain 1312. For example, node metrics may represent the security level of each computer node within sharding network 1322, the hardware and / or software configuration of each computer node within sharding network 1322, network attributes associated with connections between computer nodes within sharding network 1322, and other attributes associated with computer nodes within sharding network 1322.

[0191] Shard analysis module 1406 can determine various metrics for each of shard chains 1312, 1314, and 1316. Based on the various metrics determined for blockchain 1310 and shard chains 1312, 1314, and 1316, configuration module 1408 can determine a multi-party computation scheme for each of shard chains 1312, 1314, and 1316. For a specific shard chain, the minimum number (t) of participating nodes (out of n computer nodes) in the shard network corresponding to that specific shard chain can be specified for verifying transactions to be recorded in the shard chain. By specifying a minimum number of participating nodes (e.g., more than half of the nodes in the shard network) to verify transactions recorded in the shard chain, the security of the shard chain can be improved.

[0192] In some implementations, to further enhance sharding security while reducing the number of required nodes, configuration module 1408 may also determine a multi-party computation scheme to specify the ("required") computer nodes needed to participate in verifying transactions to be recorded in the shard chains. For example, configuration module 1408 may select specific computer nodes for each specific shard chain as the ("required") computer nodes needed to participate in verifying transactions through that specific shard chain. In some implementations, configuration module 1408 may select specific computer nodes configured to store and manage a specific shard and one or more other shard chains of the blockchain. For example, for shard chain 1312, the configuration module may select a computer node that is part of shard network 1322 and at least one of shard networks 1324 and 1326. The reason for selecting computer nodes configured to manage multiple shard chains as required computer nodes is that (e.g., by a blockchain administrator) computer nodes configured to store and manage multiple shard chains are typically hardened, more trustworthy, and have a higher level of security than other nodes. Furthermore, a specific computer node configured to manage multiple shard chains may possess insights that other computer nodes may not have, which enhances the security of the transaction verification process. For example, a specific computer node can determine that a transaction was made by a user account that has been linked to one or more fraudulent transactions associated with one or more other shard chains. This information, which other computer nodes associated with the shard chains do not possess, can allow the specific computer node to determine not to verify transactions to be recorded in the shard chain. Therefore, selecting specific computer nodes as those required to participate in the verification process further enhances the security of the shard chains.

[0193] In some implementations, configuration module 1408 can adjust the minimum number (t) of participating nodes and the required number of computer nodes based on various metrics. The ratio between the number of computer nodes (t) required to perform the verification process and the total number of computer nodes (n) in the set of computer nodes determines the security and resilience of the sharded chain verification process. For a given set of computer nodes (n), a larger t will improve the security of the verification process but reduce its resilience. Conversely, a smaller t will improve the resilience of the verification process but reduce security. In some implementations, configuration module 1408 can determine a minimum number (t) of more than half of the computer nodes in the group, such that more than half of the computer nodes in the sharded network need to collaborate in verifying transactions. Therefore, a typical 51% attack will not succeed on a sharded network implemented using this multi-party computation scheme.

[0194] In some implementations, configuration module 308 may further increase (or decrease) the minimum number (t) required to perform the verification process and / or increase (or decrease) the number of nodes required to perform the verification process based on various metrics. For example, when various metrics indicate that transaction amounts are generally high (e.g., exceeding a threshold), computer nodes in the sharded network do not have the latest version of software or no security software installed on the computer nodes, connections between nodes in the sharded network lack security, transaction frequency is higher than a threshold, and / or other factors, configuration module 1408 may increase the minimum number (t) in the multi-party computation scheme of the sharded chain and / or increase the number of computer nodes required to verify transactions.

[0195] Once a multi-party computation scheme has been determined for the sharded chains, the MPC manager 1402 can implement the scheme among the computer nodes associated with the sharded chains via the sharding interface 1404. For example, the MPC manager 1402 can generate (or otherwise obtain) a corresponding public-private key pair for each of the sharded chains 1312, 1314, and 1316. In some implementations, the MPC manager 1402 can generate a corresponding key pair, such as a public-private key, for each of the sharded chains 1312, 1314, and 1316 using an asymmetric encryption algorithm. The public and private key pairs correspond to each other; data encrypted with the private key can only be decrypted with the public key, and vice versa. The private key can be kept secret by the administrator or the computer server associated with blockchain 1310 and is not shared with anyone. The authenticity of a digital signature generated by a verification process involving one or more computer nodes within a group (e.g., data encrypted with the private key associated with the corresponding sharded chain) can be verified by decrypting the digital signature using the corresponding public key to recover the unencrypted data.

[0196] In this example, MPC manager 1402 can generate private key 1422 for shard chain 1312, private key 1424 for shard chain 1314, and private key 1426 for shard chain 1316. MPC manager 1402 can temporarily store private keys 1422, 1424, and 1426 in data storage 1460. A digital signature for each shard chain can be generated using the corresponding private key (e.g., by encrypting a piece of data using the corresponding private key). Therefore, a digital signature for shard chain 1312 can be generated using private key 1422. Similarly, a digital signature for shard chain 1314 can be generated using private key 1424, and a digital signature for shard chain 1316 can be generated using private key 1426. However, using a multi-party computation scheme instead of the actual private keys, different shareable values ​​can be used to generate outputs that mimic the digital signatures of the shard chains, as will be explained in more detail below.

[0197] In some implementations, the quorum and required (essential) node combination requirements of the verification process can be implemented at the algorithm level according to a multi-party computation scheme, such that any subset of shard chains associated with the group of computer nodes can cooperate to generate correct data fragments (e.g., simulate encrypted data using the private keys of the shard chains), provided that the subset includes the required computer nodes and at least a minimum threshold number (t) of computer nodes. In other words, the algorithm can be designed and implemented to require a set of computations to be performed among a subset of computer nodes, such that anyone (e.g., any device, and not limited to a centralized authority device) can determine the quorum and, based on the output of the computation set, satisfy the required node requirements (the number of nodes equal to or greater than the minimum threshold number (t) of nodes, including the required nodes already participating in the verification process). Thus, if multiple computer nodes satisfying the quorum requirements (including the required nodes) participate in the verification process by performing corresponding computations (e.g., corresponding verification routines), correct output can be generated. On the other hand, if the quorum requirements are not met or a number of nodes not including all required nodes participate in the authentication process by performing corresponding computations (e.g., corresponding authentication routines), incorrect output (or no output) may be generated. In some implementations, the correct output can correspond to a digital signature associated with the sharded chain (e.g., a data fragment encrypted using the sharded chain's private key). While the actual private key may not be used in the computation (e.g., the verification process), the output generated by a set of computations during the verification process can mimic a digital signature generated by encrypting a piece of data using the sharded chain's private key.

[0198] To implement this algorithm, multiple secrets can be generated based on the number of nodes required. For example, if the authentication process requires only one required computer node, two secrets can be generated to generate the digital signature. If the authentication process requires two required computer nodes, three secrets can be generated to generate the digital signature. One of the secrets (e.g., the shared secret) can be divided into multiple parts to generate shares associated with that secret. Shares can be distributed among the computer nodes used in the verification process, excluding the required node. The remaining secret (the unshared secret) can be distributed to the required nodes. Thus, each required node can have a corresponding unshared secret, while each remaining computer node can have a share associated with the shared secret. A share of the secret can include one or more values ​​that can be used with other shares to generate the shared secret.

[0199] In some implementations, secrets can be generated such that computations (e.g., a set of sequential computations) based on all generated secrets are required to produce the correct output (e.g., a sharded chain digital signature). For example, if two secrets are generated (due to the requirement of a node), sequential computations including a first computation based on the first of the two secrets and a second computation based on the second of the two secrets (where the second computation may further be based on the output of the first computation) might be necessary to generate a sharded chain digital signature. In this example, the first secret can be partitioned and shared among computer nodes other than the required node, and the second secret can be provided to the required node. Furthermore, generating shares (including portions of the secret) and distributing them among the remaining computer nodes such that regenerating the shared secret (e.g., the first secret) does not require all shares, but at least a minimum threshold number t of shares is needed.

[0200] Figure 15 This illustration demonstrates how secrets and shares associated with secrets can be generated and distributed among sharded networks of computer nodes associated with sharded chains, according to some embodiments of this disclosure. In this example, configuration module 1408 can determine a multi-party computation scheme for verifying transactions performed through sharded chain 1312, managed by sharded network 1322, which includes computer nodes 1512, 1514, 1516, 1518, and 1520. Configuration module 1408 can determine, based on various metrics associated with the computer nodes in sharded chain 1312 and sharded network 1322, that at least three of the five computer nodes in the sharded network of computer node 1322 need to perform the verification process to verify transactions to be recorded in sharded chain 1312. Furthermore, in this example, configuration module 1408 can designate computer node 1512 as a required node for the verification process of shard chain 1312, such that in addition to having a quorum (e.g., three participating nodes in the verification process), computer node 1512 must also be part of the verification process to verify transactions to be recorded in shard chain 1312. In some implementations, configuration module 1408 designates computer node 1512 as a required node based at least in part on the fact that computer node 1512 is part of shard network 1322 and one or more of other shard networks 1324 and 1326.

[0201] As shown in the figure, since a required node has been assigned to shard chain 1312 according to the multi-party computation scheme determined for shard chain 1312, MPC manager 1402 can generate two secrets 1504 and 1506 based on the private key 1422 associated with shard chain 1312 (or shard network 1322). Each of secrets 1504 and 1506 may include a string, which may be an encryption key or data that can be used by computer nodes of shard network 1322 to perform computations associated with the verification process, as will be explained in more detail below. In some implementations, the two secrets 1504 and 1506 generated based on private key 1422 are irreversible, meaning that private key 1422 cannot be regenerated from secrets 1504 and 1506. However, secrets 1504 and 1506 can be used in a set of computations (verification process) performed collaboratively by a group of computer nodes to mimic the function of signing (e.g., encrypting) a piece of data using private key 1422. This set of calculations may include a first calculation based on secret 1506 (e.g., performing a first operation on a data block using secret 1506 to generate a first output) and a second calculation based on secret 1504 (e.g., performing a second operation on the first output based on secret 1504 to generate a second output). The second output may correspond to a digital signature of the fragmented network (the second output is the same as encrypting the data segment using private key 1422). Once secrets 1504 and 1506 are generated, the MPC manager 1402 may discard private key 1422 (e.g., permanently remove private key 1422).

[0202] MPC Manager 1402 can then distribute Secret 1504 to the desired nodes (e.g., computer node 1512). In response to receiving Secret 1504 from MPC Manager 1402, computer node 1512 can securely store Secret 1504 on computer node 1512 (e.g., a persistent data storage device such as a hard drive, flash drive, etc.).

[0203] In some implementations, MPC manager 1402 can generate shares associated with secret 1506. Each share may include one or more portions of secret 1506, or may be used with other shares to regenerate information about secret 1506. These shares may be distributed among the remaining computer nodes 1514, 1516, 1518, and 1520. For example, MPC manager 1402 can generate shares 1522, 1524, 1526, and 1528 for computer nodes 1514, 1516, 1518, and 1520. MPC manager 1402 can distribute shares 1522, 1524, 1526, and 1528 to computer nodes 1514, 1516, 1518, and 1520, respectively. In some implementations, MPC manager 1402 generates shares by dividing secret 1506 into multiple portions, where each share includes one or more portions of secret 1506. For example, MPC manager 1402 can generate shares 1522, 1524, 1526, and 1528, where each share includes multiple parts (but not all parts) of secret 1506, such that no single computer node possesses the entirety of secret 1506. Furthermore, different shares can include different sets of multiple parts, such that a portion (but not all) of computer nodes 1514, 1516, 1518, and 1520 needs to have all parts of secret 1506. In some implementations, shares can be generated based on Shamir's secret-sharing technique, where secret 1506 can be transformed into a polynomial and each share includes different data points (with a set of coordinates) of the polynomial. In some implementations where secret 1506 is transformed into a polynomial, secret 1504 can be implemented as an offset of the polynomial.

[0204] Upon receiving the corresponding shares 1522, 1524, 1526, and 1528, computer nodes 1514, 1516, 1518, and 1520 may store the corresponding shares 1522, 1524, 1526, and 1528. After distributing shares 1522, 1524, 1526, and 1528 of secrets 1504 and 1506, the sharded network of computer node 1322 is ready to perform the verification process to verify the transaction according to the multi-party computation scheme. In some implementations, after distributing secrets 1504 and shares 1522, 1524, 1526, and 1528, MPC manager 1402 may also discard (delete or otherwise destroy) copies of secrets 1504 and shares 1522, 1524, 1526, and 1528 from its memory.

[0205] Figure 16An example verification process, performed by a sharded network of computer nodes 1322 to verify a transaction to be recorded on shard chain 1312, is illustrated according to some embodiments of this disclosure. In some embodiments, user 1240 may use user device 110 to initiate a transaction with service provider server 1230. The transaction may be a cryptocurrency transaction (e.g., transferring a certain amount of cryptocurrency from one wallet to another), a smart contract transaction, or any type of transaction. In some embodiments, user 1240 may send a transaction request to service provider server 1230. The transaction request may include credentials associated with a user account (e.g., username, password, etc.). After verifying the credentials, service provider server 1230 may determine a specific shard chain for recording the transaction. For example, service provider server 1230 may determine a specific shard chain based on the identity of the user account used to conduct the transaction, the location of the transaction, and / or other factors. In this example, service provider server 1230 may determine that shard chain 1312 is suitable for recording the transaction. Therefore, service provider server 1230 can transmit transaction data 1602 associated with a transaction to one or more computer nodes in the network of computer nodes 1322, including computer nodes 1512, 1514, 1516, 1518, and 1520. Transaction data 1602 can be sent directly by service provider server 1230 to each of computer nodes 1512, 1514, 1516, 1518, and 1520. Alternatively, once any computer node within the sharded network 1322 receives transaction data 1602, that computer node can be configured to automatically broadcast transaction data 1602 to other computer nodes in the sharded network 1322.

[0206] In some implementations, the verification process includes an ordered set of consecutive computations, which must be performed sequentially based on a secret and / or portions thereof. Therefore, the secret and / or portions thereof distributed to the computer nodes can be labeled (e.g., based on order). When computer nodes 1512, 1514, 1516, 1518, and 1520 receive a transaction (or transaction data associated with the transaction), each of these computer nodes can verify the transaction. For example, each computer node can traverse a copy of its shard chain 1312 to determine the legitimacy of the transaction based on other transactions recorded in shard chain 1312. When a transaction is determined to be verified, each computer node can determine whether it can perform an initial computation (e.g., an initial verification routine as part of the verification process) based on a first portion of secret 1506 stored on the computer node. If a computer node determines that it can perform an initial computation based on a first portion of its owned secret 1506 (the first portion being included in the corresponding share stored on the computer node), then the computer node can perform the initial computation based on the transaction data and the first portion of secret 1506 within its corresponding share (labeled as the first portion). The execution of the initial computation may manipulate transaction data 1602 based on the first portion of secret 1506 and generate a first output. The computer node may broadcast the first output to other computer nodes. Each computer node may determine whether it is capable of performing a second computation (e.g., a second verification routine as part of a verification process) based on a second portion of secret 1506. If a computer node determines that it can perform a second computation based on a second portion of its owned secret 1560 (including the second portion in the corresponding share stored on the computer node), then it may perform the second computation. The second computation may involve manipulating the first output using the second portion of secret 1506. Computer nodes 1514, 1516, 1518, and 1520 may continue to perform computations using portions of secret 1506 they own as part of a verification process until all computations involving secret 1506 are completed. The final calculation produces output 1604. Once all calculations involving secret 1506 are complete, the computer node that performed the final calculation can transmit output 1604 to the desired computer node 1512.

[0207] Upon receiving output 1604, computer node 1512 can perform computations corresponding to the verification process based on secret 1504 stored on computer node 1512. In some embodiments, the computation performed by computer node 1512 further manipulates output 1604 based on secret 1504 to generate output 1606, which is the final output of the verification process. In some embodiments, the final output 1606 may correspond to a digital signature associated with shard chain 1312. Computer node 1512 can broadcast output 1606 to other computer nodes in shard network 1312, such that each computer node in shard network 1312 can record the transaction along with output 1606 (e.g., the digital signature of shard chain 1312) to its copy of shard chain 1312. Since the digital signature is also included in shard chain 1312, any device (e.g., any computer node in shard network 1322 or other computer nodes) can verify digital signature 1312 by decrypting output 1606 using the public key associated with the shard chain and verifying that the decrypted signature corresponds to transaction data stored in shard chain 1312. If the minimum threshold number of computer nodes from shard network 1322 (e.g., three) is greater than the required number of computer nodes 1512 participating in the verification process, then output 1606 should correspond to the digital signature of shard chain 1312 (e.g., decrypting output 1606 using the public key of shard chain 1312 should produce a value that matches transaction data 1602). On the other hand, if the minimum threshold number of computer nodes participating in the verification process (e.g., two) or the required number of computer nodes 1512 fails to participate in the verification process, then output 1606 will not correspond to shard chain 1312 (e.g., decrypting output 1606 using the public key of shard chain 1312 will produce a value that does not match transaction data 1602).

[0208] Each computer node in sharded network 1322 can verify output 1606 accordingly, and can only add transaction data 1602 and output 1606 to its copy of shard chain 1312 if output 1606 is verified (adding transaction data 1602 and output 1606 to a block and appending the block to shard chain 1312). If output 1606 is not verified, the computer node should discard the transaction.

[0209] In some implementations, after a multi-party computation scheme is implemented within a sharded network (e.g., sharded networks 1322, 1324, 1326, etc.), the MPC manager 1402 can continue to monitor the different characteristics of the sharded networks (e.g., sharded networks 1322, 1324, 1326, etc.) and their corresponding shard chains (e.g., shard chains 1312, 1314, 1316, etc.). For example, the sharding analysis module 1406 can continue to monitor (e.g., periodically, etc.) the different attributes of transactions added to each shard chain, the volatility of new transactions added to each shard chain, the status of computer nodes in each sharded network (e.g., security status, etc.), the network status between computer nodes in each sharded network, and other attributes. Based on the characteristics of sharded network updates, the configuration module 1408 can determine whether to modify one or more multi-party computation schemes of one or more shard chains.

[0210] For example, if it is determined that the amount associated with new transactions added to the shard chain (e.g., transactions added after a threshold time) is significantly greater than (e.g., exceeds the threshold) the amount associated with older transactions in the shard chain (e.g., transactions added before the threshold time), or the number of transactions added to the shard chain in a recent period is significantly greater than the number of transactions added to the shard chain in the same past period, then configuration module 1408 may determine the minimum threshold number of computer nodes required to add to the shard chain to participate in transaction verification, the number of computer nodes required to add to the transaction verification, or both.

[0211] For example, if it is determined that the computer node designated as the required computer node in the existing sharding chain multi-party computation scheme has a security problem (e.g., the software is not up-to-date, or there has been a recent attack on the computer node), the configuration module 1408 can increase the number of nodes required to verify transactions for the sharding chain and / or designate another computer node as the required node.

[0212] In another example, if it is determined that the volatility of a new transaction in the shard chain is significantly greater than that of an old transaction, the configuration module 1408 may also increase the minimum threshold number of computer nodes required to participate in transaction verification, increase the number of computer nodes required to verify the transaction, or both, for the shard chain.

[0213] In some implementations, based on the updating characteristics of a shard chain (e.g., shard chain 1312), the configuration module 1408 can also modify one or more multi-party computation schemes of one or more other shard chains (e.g., shard chains 1314, 1316, etc.). This is because an increase in the security risk of one shard chain may also affect the security risks of other shard chains. For example, if an increased number of attacks are detected on a shard network (e.g., shard network 1322), the configuration module 1408 can foresee that similar attack trends may occur in other shard networks. Therefore, the configuration module 1408 can increase security by modifying the multi-party computation schemes of multiple shard chains (e.g., shard chains 1312, 1314, and 1316) based on events detected on one shard chain.

[0214] Once the multi-party computation scheme is modified, the MPC manager 1402 can implement the modified multi-party computation scheme within the sharded network. In some implementations, to implement the modified multi-party computation scheme, the MPC manager 1402 can generate new secrets and new secret shares, and can distribute the new secrets and new secret shares among computer nodes within the sharded network using the techniques described herein.

[0215] Figure 17 A process 1700 for determining and implementing a multi-party computation scheme according to various embodiments of the present disclosure is illustrated. In some embodiments, at least a portion of process 1700 may be performed by MPC module 1232. Note that while in some embodiments, MPC module 1232 may be implemented as a centralized module for implementing a multi-party computation scheme across multiple shards, in other embodiments, a separate MPC module 1232 may be implemented for implementing a multi-party computation scheme individually for each shard. Process 1700 may be initiated by accessing (in step 1705) multiple shard chains and shard networks corresponding to the blockchain. For example, shard analysis module 1406 may access computer nodes within shard networks 1322, 1324, and 1326 via a shard interface. Shard analysis module 1406 may obtain copies of the shard chains stored within the computer nodes. For example, shard analysis module 1406 may access a copy of shard chain 1312 from a computer node in shard network 1322. Similarly, the sharding analysis module 1406 can access a copy of shard chain 1314 from computer nodes in sharding network 1324, and access a copy of shard chain 1316 from computer nodes in sharding network 1326.

[0216] Process 1700 then analyzes (in step 1710) the transaction characteristics of the transactions recorded in each shard chain. For example, shard analysis module 1406 can analyze transactions recorded in shard chains 1312, 1314, and 1316. In some implementations, shard analysis module 1406 can determine the amounts associated with the transactions recorded in the shard chains, the average amount of the transactions, the volatility of the transactions, the total number of transactions, and other transaction attributes.

[0217] Process 1700 then analyzes (in step 1715) the node characteristics of each node in the shard chain. For example, shard analysis module 1406 can analyze the computer nodes within each of shard networks 1322, 1324, and 1326. Shard analysis module 1406 can determine the hardware and / or software configuration of each computer node (e.g., whether any security hardware or software is installed on the computer node), the network attributes of each computer node, and other computer attributes of each computer node in the shard network.

[0218] Process 1700 then analyzes (in step 1720) the chain characteristics associated with each shard chain. For example, shard analysis module 1406 can analyze copies of the shard chains stored in the computer nodes of the sharded network. Shard analysis module 1406 can determine the size of the shard chain, the age of blocks in the shard chain, the rate or frequency at which blocks are added to the shard chain, and the characteristics of the blockchain to which the shard chain belongs.

[0219] Process 1700 determines a multi-party computation scheme for each shard chain based on its characteristics (in step 1725). For example, configuration module 1408 can determine a multi-party computation scheme for each of shard chains 1312, 1314, and 1316. Each multi-party computation scheme can specify a minimum threshold number of participating computer nodes and one or more computer nodes required to verify transactions to be recorded in the corresponding shard chain.

[0220] Process 1700 then implements (in step 1730) the corresponding multi-party computation scheme within each shard network. For example, MPC manager 1402 can interact with computer nodes in each of shard networks 1322, 1324, and 1326 to configure the computer nodes according to the corresponding multi-party computation scheme. In some implementations, MPC manager 1402 can generate secrets and shares of secrets based on the private key of each shard chain and can distribute the secrets and shares of secrets among the computer nodes in the shard network. Once the multi-party computation scheme is implemented, shard networks 1322, 1324, and 1326 can begin verifying transactions under the corresponding multi-party computation scheme.

[0221] Figure 18A process 1800 for modifying a multi-party computation scheme according to various embodiments of the present disclosure is illustrated. In some embodiments, at least a portion of process 1800 may be executed by MPC module 1232. Process 1800 may begin by monitoring (in step 1805) the characteristics of each shard chain and shard network. For example, shard analysis module 1406 may monitor the transaction characteristics of transactions added to shard chains 1312, 1314, and 1316, the node characteristics of computer nodes in each of shard networks 1322, 1324, and 1326, and the chain characteristics of shard chains 1312, 1314, and 1316.

[0222] Process 1800 then determines (in step 1810) whether a condition exists. For example, MPC manager 1402 can determine whether there are changes in transaction characteristics, node characteristics, and chain characteristics. When the change is greater than a threshold, MPC manager 1402 can determine that the condition exists. If the condition does not exist, process 1800 returns to step 1805 and continues to monitor the characteristics of each in the shard chain and the shard network. However, if such a condition exists, process 1800 analyzes (in step 1815) the condition and modifies (in step 1820) the multi-party computation scheme of one or more shard chains based on the condition. For example, configuration module 1408 can analyze the characteristics of the shard chains (and changes in those characteristics) and determine the multi-party computation scheme for modifying the shard chains. Modifications may include adjusting (e.g., increasing or decreasing) the minimum threshold number of computer nodes required to participate in the verification process, changing the number of computer nodes required to participate in the verification process, and / or allocating different required computer nodes to participate in the verification process. In some implementations, based on conditions detected in a shard chain, the MPC module 1232 can modify the multi-party computation scheme for only that shard chain. In some implementations, the MPC module 1232 can also modify the multi-party computation scheme for one or more other shard chains based on the detected conditions of the shard chain.

[0223] Process 1800 then implements (in step 1825) the modified multi-party computation scheme in one or more shard chains. In some implementations, to implement the modified multi-party computation scheme, MPC manager 1402 may generate new secrets and new secret shares and distribute the new secrets and new secret shares to computer nodes in the sharded network.

[0224] Figure 19A process 1900 for performing a verification process according to various embodiments of the present disclosure is illustrated. In some embodiments, at least a portion of process 1900 may be performed by computer nodes associated with a sharded network. Process 1900 may begin by receiving (in step 1905) a transaction associated with the sharded chain. For example, when service provider server 1230 receives a transaction request, service provider server 1230 may generate transaction data associated with the transaction request and may send the transaction data to the computer nodes associated with the sharded chain. Upon receiving the transaction data, the computer nodes associated with the sharded chain may broadcast the transaction data to other computer nodes in the sharded network associated with the sharded chain, such that each computer node in the sharded network receives the transaction data.

[0225] Then, process 1900 performs the verification process of the transaction (in step 1910) by collaborating with one or more other computer nodes to generate a digital signature. For example, computer nodes in a sharded network can collaborate with each other, using their own secret shares to perform a series of computations. If the computer nodes participating in the verification process using their secret shares meet the criteria specified in the multi-party computation scheme (e.g., meeting a minimum threshold number requirement and including the required number of computer nodes), a correct digital signature based on the transaction data will be generated. On the other hand, if the computer nodes participating in the verification process do not meet the criteria specified in the multi-party computation scheme, an incorrect digital signature (or no digital signature) will be generated.

[0226] Next, process 1900 determines (in step 1915) whether the signature is valid, and if the signature is valid, records the transaction in the shard chain (in step 1920). Conversely, if the signature is invalid, process 1900 discards the transaction (in step 1925). For example, each computer node in the sharded network can determine whether the output signature from the verification process is a valid signature. A computer node can verify a signature by decrypting it using the public key associated with the shard chain and determining whether the decrypted signature corresponds to transaction data. If the signature is valid, the computer node can add the transaction to a block and append that block to the shard chain. Conversely, if the signature is invalid, the computer node can discard the transaction.

[0227] Figure 20This is a block diagram of a computer system 2000 suitable for implementing one or more embodiments of the present disclosure, including a service provider server 1230, a merchant server 1220, user equipment 1210, and computer nodes 1512, 1514, 1516, 1518, and 1520. In various implementations, user equipment 1210 and other user equipment may include mobile cellular phones suitable for wireless communication, personal computers (PCs), laptop computers, wearable computing devices, etc., and each of the service provider server 1230, merchant server 1220, and computer nodes 1512, 1514, 1516, 1518, and 1520 may include a network computing device, such as a server. Therefore, it should be understood that devices / servers 1210, 1220, 1230, 1512, 1514, 1516, 1518, and 1520 can be implemented as computer system 2000 in the following manner.

[0228] Computer system 2000 includes a bus 2012 or other communication mechanisms for transmitting information, data, signals, and information between various components of computer system 2000. These components include input / output (I / O) components 2004, which process user (i.e., sender, receiver, service provider) actions, such as selecting keys on a keypad / keyboard, selecting one or more buttons or links, and sending corresponding signals to bus 2012. I / O components 2004 may also include output components, such as a display 2002 and a cursor control 2008 (such as a keyboard, keypad, mouse, etc.). Display 2002 can be configured to display a login page for logging into a user account or a checkout page for purchasing items from a merchant. Optional audio input / output components 2006 may also be included to allow the user to input information using speech by converting audio signals. Audio I / O components 2006 allow the user to hear audio. A transceiver or network interface 2020 is connected via a network 2022, such as... Figure 12 Network 1260 transmits and receives signals between computer system 2000 and other devices such as another user device, merchant server, or service provider server. In one implementation, the transmission is wireless, but other transmission media and methods may also be suitable. Processor 2014 may be a microcontroller, digital signal processor (DSP), or other processing unit that processes these various signals, such as for display on computer system 2000 or for transmission to other devices via communication link 2024. Processor 2014 may also control the transmission of information such as cookies or IP addresses to other devices.

[0229] The computer system 2000 also includes a system memory component 2010 (e.g., RAM), a static storage device component 2016 (e.g., ROM), and / or a disk drive 2018 (e.g., a solid-state drive, hard disk drive). The computer system 2000 performs specific operations by executing one or more sequences of instructions contained in the system memory component 2010 via a processor 2014 and other components. For example, the processor 2014 may execute the transaction verification function described herein according to procedures 1700, 1800, and 1900.

[0230] The logic can be encoded in a computer-readable medium, which can refer to any medium that participates in providing instructions to the processor 2014 for execution. Such a medium can take many forms, including but not limited to non-volatile media, volatile media, and transmission media. In various implementations, non-volatile media include optical discs or magnetic disks, volatile media include dynamic memory such as system memory component 2010, and transmission media include coaxial cables, copper wires, and optical fibers, including the lines constituting bus 2012. In one embodiment, the logic is encoded in a non-transitory computer-readable medium. In one example, the transmission medium can take the form of acoustic waves or light waves, such as those generated during radio wave, optical, and infrared data communication.

[0231] Some common forms of computer-readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tapes, any other magnetic media, CD-ROMs, any other optical media, punched cards, paper tapes, any other physical media with a perforated pattern, RAM, PROMs, EPROMs, FLASH-EPROMs, any other memory chips or cartridges, or any other media that a computer is adapted to read.

[0232] In various embodiments of this disclosure, the execution of the instruction sequence for practicing this disclosure may be performed by computer system 2000. In various other embodiments of this disclosure, multiple computer systems 2000 coupled to a network (such as a LAN, WLAN, PTSN, and / or various other wired or wireless networks, including telecommunications, mobile, and cellular telephone networks) via communication link 2024 may execute instruction sequences to practice this disclosure in a coordinated manner with each other.

[0233] Where applicable, the various embodiments provided in this disclosure may be implemented using hardware, software, or a combination of hardware and software. Furthermore, where applicable, without departing from the spirit of this disclosure, the various hardware and / or software components described herein may be combined into composite components comprising software, hardware, and / or both. Where applicable, without departing from the spirit of this disclosure, the various hardware and / or software components described herein may be divided into sub-components comprising software, hardware, or both. Additionally, where applicable, it is contemplated that software components may be implemented as hardware components, and vice versa.

[0234] Software such as program code and / or data according to this disclosure can be stored on one or more computer-readable media. It is also contemplated that the software identified herein can be implemented using one or more networked general-purpose or special-purpose computers and / or computer systems and / or otherwise. Where applicable, the order of the various steps described herein can be changed, combined into compound steps, and / or divided into sub-steps to provide the features described herein.

[0235] The various features and steps described herein can be implemented as a system comprising one or more memories storing the various information described herein and one or more processors coupled to the one or more memories and a network, wherein one or more processors are operable to perform the steps described herein as a non-transient machine-readable medium comprising a plurality of machine-readable instructions, wherein the non-transient machine-readable medium, when executed by one or more processors, is adapted to cause one or more processors to perform a method comprising the steps described herein, and a method performed by one or more devices such as a hardware processor, user equipment, server, and other devices described herein.

Claims

1. A system comprising: Non-transitory memory; as well as One or more hardware processors, said hardware processors being coupled to the non-transitory memory and configured to read instructions from the non-transitory memory to cause the system to perform operations including: Obtain attributes associated with a first shard chain among a plurality of shard chains corresponding to a blockchain, wherein the attributes are obtained from a plurality of computer nodes configured to manage the first shard chain; Analyze the aforementioned attributes; Based on the analysis, a multi-party computation scheme is determined for verifying transactions made through the first shard chain, wherein the multi-party computation scheme specifies (i) a minimum threshold number of computer nodes in the first group of computer nodes that need to cooperate in verifying transactions to be recorded in the first shard chain, and (ii) a first computer node in the first group of computer nodes that is a required node and needs to cooperate in verifying transactions to be recorded in the first shard chain; and The first group of computer nodes is configured to perform a transaction verification process according to the multi-party computation scheme.

2. The system according to claim 1, wherein, The operation also includes: A first secret and a second secret are generated based on the encryption key associated with the first shard chain, wherein the electronic signature of the electronic data using the encryption key is imitated by a computational transformation of the electronic data using the first secret and the second secret; Multiple shares are generated based on the second secret, wherein the multiple shares include a first number of shares, wherein a second number of shares less than the first number are required to recover the second secret, and wherein the second number corresponds to the minimum threshold number of computer nodes specified in the multi-party computation scheme; and The first secret is distributed to the first computer node, and the plurality of shares are distributed to the first group of computer nodes other than the first computer node.

3. The system according to claim 1, wherein, The analysis includes analyzing the transactions recorded in the first shard chain.

4. The system according to claim 1, wherein, The analysis includes analyzing the volatility of transactions recorded in the first shard chain.

5. The system according to claim 1, wherein, The analysis includes analyzing the computer hardware and software configurations of the first group of nodes.

6. The system according to claim 1, wherein, The multi-party computation scheme is a first multi-party computation scheme, and the operation further includes: After configuring the first group of computer nodes according to the first multi-party computation scheme, detect the conditions associated with at least one of the first group of computer nodes or the first shard chain. In response to the detection of the condition, a second multi-party computation scheme is determined for the first shard chain; and The first group of computer nodes is reconfigured to perform the transaction verification process according to the second multi-party computation scheme.

7. The system according to claim 6, wherein, The second multi-party computation scheme specifies a second minimum threshold number of computer nodes that collaborate when verifying transactions to be recorded in the first shard chain.

8. The system according to claim 6, wherein, The second multi-party computation scheme designates a second computer node from the first group of computer nodes as a required node. The second computer node as a required node needs to cooperate in verifying the transactions to be recorded in the first shard.

9. A method comprising: Interacting with multiple computer nodes via one or more hardware processors, the multiple computer nodes are configured to manage the first shard chain of multiple shard chains corresponding to a blockchain; Based on the interaction and by determining the characteristics associated with the first shard chain through the one or more hardware processors; The one or more hardware processors determine a multi-party computation scheme for verifying transactions made through the first shard chain based on analysis of the characteristics, wherein the multi-party computation scheme specifies (i) a minimum threshold number of computer nodes in the first group of computer nodes that need to cooperate in verifying transactions to be recorded in the first shard chain, and (ii) a first computer node in the first group of computer nodes that is a required node that needs to cooperate in verifying transactions to be recorded in the first shard chain. as well as The first group of computer nodes is configured using one or more hardware processors to perform a transaction verification process according to the multi-party computation scheme.

10. The method according to claim 9, wherein, The multi-party computation scheme is a first multi-party computation scheme, and the method further includes: After configuring the first group of computer nodes according to the first multi-party computation scheme, detect the conditions associated with at least one of the first group of computer nodes or the first shard chain. In response to the detection of the condition, a second multi-party computation scheme is determined for the first shard chain; and The first group of computer nodes is reconfigured to perform the transaction verification process according to the second multi-party computation scheme.

11. The method according to claim 10, wherein, The condition is associated with changes in the volatility of transactions linked to the first shard chain.

12. The method according to claim 10, wherein, The condition is associated with changes in transaction amount, which is associated with transactions related to the first shard chain.

13. The method according to claim 10, wherein, The conditions are associated with changes in the security-related computer configurations in the first group of computer nodes.

14. The method according to claim 10, further comprising: A second set of computer nodes associated with the second shard chain among the plurality of shard chains are configured to perform the transaction verification process according to a third multi-party computation scheme; In response to detecting a condition associated with at least one of the first group of computer nodes or the first shard chain, a fourth multi-party computation scheme for the second shard chain is determined; as well as The second group of computer nodes is reconfigured to perform the transaction verification process according to the fourth multi-party computation scheme.

15. The method according to claim 9, wherein, The blockchain is associated with a ledger used to record cryptocurrency transactions of a specific cryptocurrency type.

16. The method according to claim 9, wherein, The blockchain is associated with a ledger used to record smart contract transactions.

17. A non-transitory machine-readable medium storing machine-readable instructions that are executable to cause a machine to perform operations including: Retrieve the attributes associated with the first shard chain among multiple shard chains corresponding to the blockchain, where, The attribute is obtained from multiple computer nodes configured to manage the first shard chain; Based on the analysis of the attributes, a multi-party computation scheme for verifying transactions made through the first shard chain is determined, wherein the multi-party computation scheme specifies (i) a minimum threshold number of computer nodes in the first group of computer nodes that need to cooperate in verifying transactions to be recorded in the first shard chain, and (ii) a first computer node in the first group of computer nodes that is a necessary node that needs to cooperate in verifying transactions to be recorded in the first shard chain. as well as The first group of computer nodes is configured to perform a transaction verification process according to the multi-party computation scheme.

18. The non-transitory machine-readable medium according to claim 17, wherein, The operation also includes: A first secret and a second secret are generated based on the encryption key associated with the first shard chain, wherein the electronic signature of the electronic data using the encryption key is imitated by a computational transformation of the electronic data using the first secret and the second secret; Multiple shares are generated based on the second secret, wherein the multiple shares include a first number of shares, wherein a second number of shares less than the first number are required to recover the second secret, and wherein the second number corresponds to the minimum threshold number of computer nodes specified in the multi-party computation scheme; and The first secret is distributed to the first computer node, and the plurality of shares are distributed to the first group of computer nodes other than the first computer node.

19. The non-transitory machine-readable medium according to claim 17, wherein, The multi-party computation scheme is a first multi-party computation scheme, and the operation further includes: After configuring the first group of computer nodes according to the first multi-party computation scheme, the conditions associated with the second shard chain among the multiple shard chains corresponding to the blockchain are detected. In response to the detection of the condition, a second multi-party computation scheme is determined for the first shard chain; and The first group of computer nodes is reconfigured to perform transaction verification according to the second multi-party computation scheme.

20. The non-transitory machine-readable medium according to claim 19, wherein, The condition is associated with a computer attack on at least one computer node configured to manage the second shard chain.

Images