Aggregate Machine Learning Validation for Databases

Abstract

Example operations may include one or more of the following: generating gradient computations for machine learning model training by a plurality of training participant clients, each training participant client including a training data set, converting the gradient computations into a plurality of transaction proposals by a training aggregator coupled to the plurality of training participant clients, receiving the plurality of transaction proposals by one or more endorser nodes or peers of a blockchain network, executing a verify gradient smart contract by each endorser node or peer, and providing endorsements corresponding to the plurality of transaction proposals to the training aggregator.

Description

Technical Field

[0001] The present application relates generally to consensus processes for machine learning applications, and more specifically to aggregate machine learning validation of databases. Background Art

[0002] A centralized database stores and maintains data in a single database (e.g., a database server) at one location. The location is typically a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe computer. Information stored in a centralized database can typically be accessed from multiple different points. Multiple users or client workstations can work simultaneously on a centralized database, for example based on a client / server configuration. Because it is located in a single location, a centralized database is easy to manage, maintain, and control, particularly for security purposes. In a centralized database, data redundancy is minimized because a single storage location for all data means that a given set of data has only one master record.

[0003] However, centralized databases suffer from significant drawbacks. For example, centralized databases have only one point of failure. In particular, if fault tolerance is not considered and a hardware failure (e.g., hardware, firmware, and / or software failure) occurs, all data in the database will be lost and the work of all users will be interrupted. In addition, centralized databases are highly dependent on network connections. As a result, the slower the connection, the longer it takes to access the database each time. Another disadvantage is that bottlenecks occur when centralized databases experience high traffic due to a single location. In addition, since the database maintains only one copy of the data, centralized databases provide limited access to the data. As a result, multiple devices cannot access the same piece of data at the same time without causing serious problems or risking overwriting the stored data. In addition, since the database storage system has little or no data redundancy, it is difficult to recover accidentally lost data except by restoring from backup storage through manual operations. Therefore, solutions that overcome these shortcomings and limitations are needed. Summary of the invention

[0004] An example embodiment provides a system including a training participant network including a plurality of training participant clients, each training participant client including a training data set and configured to perform one or more of: generating a plurality of gradient computations, each gradient computation corresponding to a training iteration of a machine learning model training using stochastic gradient descent, the machine learning model training including a plurality of training iterations, and a training aggregator coupled to each of the plurality of training participant clients and configured to convert the gradient computations into a plurality of transaction proposals, a blockchain network including one or more endorser nodes or peers, each node or peer including a verify gradient smart contract and configured to endorse the plurality of transaction proposals.

[0005] Another example embodiment provides a method, comprising one or more of: generating gradient calculations for machine learning model training by a plurality of training participant clients, each training participant client comprising a training data set, converting the gradient calculations into a plurality of transaction proposals by a training aggregator coupled to the plurality of training participant clients, receiving the plurality of transaction proposals by one or more endorser nodes or peers of a blockchain network, executing a verify gradient smart contract by each endorser node or peer, and providing endorsements corresponding to the plurality of transaction proposals to the training aggregator.

[0006] Another example embodiment provides a non-transitory computer-readable medium, comprising instructions that, when read by a processor, cause the processor to perform one or more of the following operations: generating gradient calculations for machine learning model training by a plurality of training participant clients, each training participant client comprising a training data set, converting the gradient calculations into a plurality of transaction proposals by a training aggregator coupled to the plurality of training participant clients, receiving the plurality of transaction proposals by one or more endorser nodes or peers of a blockchain network, executing a verification gradient smart contract by each endorser node or peer, and providing endorsements corresponding to the plurality of transaction proposals to the training aggregator. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1A A block diagram of verifying gradient transaction endorsements in a blockchain is shown according to an example embodiment.

[0008] Figure 1B A block diagram of a training participant network is shown according to an example embodiment.

[0009] Figure 1C A block diagram of a training participant network is shown according to an example embodiment.

[0010] Figure 2A An example blockchain architecture configuration is shown according to an example embodiment.

[0011] Figure 2BA blockchain transaction flow is shown according to an example embodiment.

[0012] Figure 3A A licensed network according to an example embodiment is shown.

[0013] Figure 3B Another licensed network according to an example embodiment is shown.

[0014] Figure 3C A permission-less network is shown according to an example embodiment.

[0015] Figure 4 A system message diagram for verifying gradient computation in a blockchain according to an example embodiment is shown.

[0016] Figure 5A A flow chart of an example method of verifying machine learning computations in a blockchain according to example embodiments is shown.

[0017] Figure 5B A flow chart of an example method of verifying training aggregator computations in a blockchain according to example embodiments is shown.

[0018] Figure 5C A flow diagram for verifying model updates in a blockchain is shown according to an example embodiment.

[0019] Fig. 6A An example system configured to perform one or more operations described herein is shown according to an example embodiment.

[0020] Figure 6B Another example system configured to perform one or more operations described herein is shown according to an example embodiment.

[0021] Figure 6C Another example system configured to utilize smart contracts according to an example embodiment is shown.

[0022] Fig.6D Yet another example system configured to utilize blockchain according to an example embodiment is shown.

[0023] Fig. 7A A process for adding a new block to a distributed ledger is shown according to an example embodiment.

[0024] Figure 7B The content of a new data block according to an example embodiment is shown.

[0025] Figure 7C A blockchain for digital content according to an example embodiment is shown.

[0026] Fig.7DBlocks are shown that may represent the structure of blocks in a blockchain according to example embodiments.

[0027] Fig. 8A An example blockchain storing machine learning (artificial intelligence) data is shown according to an example embodiment.

[0028] Figure 8B An example quantum-secure blockchain is shown according to an example embodiment.

[0029] Fig. 9 An example system is shown that supports one or more example embodiments. DETAILED DESCRIPTION

[0030] It will be readily appreciated that the instant components, as generally described and illustrated in the figures herein, may be arranged and designed in a variety of different configurations. Therefore, the following detailed description of embodiments of at least one of the methods, devices, non-transitory computer-readable media, and systems, as illustrated in the figures, is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments.

[0031] The instant features, structures or characteristics described throughout the specification may be combined or removed in any suitable manner in one or more embodiments. For example, the use of the phrases "exemplary embodiments", "some embodiments" or other similar language throughout the specification refers to the fact that a specific feature, structure or characteristic described in conjunction with the embodiment may be included in at least one embodiment. Therefore, the appearance of the phrases "exemplary embodiments", "in some embodiments", "in other embodiments" or other similar language throughout the specification does not necessarily all refer to the same set of embodiments, and in one or more embodiments, the described features, structures or characteristics may be combined or removed in any suitable manner. In addition, in the figures, even if the connection between the elements shown is a unidirectional or bidirectional arrow, unidirectional and / or bidirectional communication may be allowed. Moreover, any device depicted in the drawings may be a different device. For example, if a mobile device is shown sending information, a wired device may also be used to send information.

[0032] In addition, although the term "message" may have been used in the description of the embodiment, the application can be applied to various types of networks and data. In addition, although certain types of connections, messages and signaling can be depicted in exemplary embodiments, the application is not limited to certain types of connections, messages and signaling.

[0033] Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks that provide aggregated machine learning validation for a database.

[0034] In one embodiment, the application utilizes a decentralized database (e.g., blockchain) as a distributed storage system, which includes multiple nodes that communicate with each other. The decentralized database includes an immutable data structure that can only be appended, similar to a distributed ledger, and can maintain records between mutually untrusted parties. Untrusted parties are referred to as peers or peer nodes in this article. Each peer maintains a copy of the database record, and no peer can modify the database record without reaching a consensus between the distributed peers. For example, peers can execute a consensus protocol to verify blockchain storage transactions, group storage transactions into blocks, and build hash chains on these blocks. To maintain consistency, this process forms an account book by sorting storage transactions. In various embodiments, permissioned and / or permissionless blockchains can be used. In a public or permissionless blockchain, anyone can participate without a specific identity. Public blockchains can involve native cryptocurrencies and can use consensus based on various protocols (e.g., proof of work (PoW)). On the other hand, a permissioned blockchain database provides secure interactions between a group of entities that have a common goal but do not fully trust each other, such as businesses that exchange funds, goods, information, etc.

[0035] Applications can leverage blockchains to arbitrarily manipulate programmable logic tailored for decentralized storage solutions and called “smart contracts” or “chaincodes.” In some cases, there may be dedicated chaincodes for managing functionality and parameters, called system chaincodes. Applications can further leverage smart contracts for trusted distributed applications, leveraging the tamper-proof properties of blockchain databases and the underlying protocols between nodes, called endorsements or endorsement policies. Blockchain transactions associated with an application can be “endorsed” before being submitted to the blockchain, while unendorsed transactions are ignored. Endorsement policies allow chaincodes to specify endorsers of a transaction in the form of a set of peer nodes that are required for endorsement. When a client sends a transaction to the peers specified in the endorsement policy, the transaction is executed to validate the transaction. After validation, the transaction enters the ordering phase, where a consensus protocol is used to generate an ordered sequence of endorsed transactions grouped into blocks.

[0036] Applications can utilize nodes that are communication entities of a blockchain system. A "node" can perform a logical function in the sense that multiple nodes of different types can run on the same physical server. Nodes are grouped in trust domains and are associated with logical entities that control them in various ways. Nodes can include different types, such as client or submitting client nodes, which submit transaction calls to signatories (e.g., peers) and broadcast transaction proposals to ordering services (e.g., ordering nodes). Another type of node is a peer node, which can receive transactions submitted by clients, submit transactions and maintain a copy of the state and blockchain transaction ledger. Although not required, peers can also play the role of endorsers. Ordering service nodes or orderers are nodes that run communication services for all nodes and implement delivery guarantees, such as broadcasting to every peer node in the system when submitting transactions and modifying the world state of the blockchain, which is another name for the initial blockchain transaction that usually contains control and setup information.

[0037] Applications can utilize a shared ledger that is an ordered, tamper-proof record of all state transitions of a blockchain. State transitions can be caused by chaincode invocations (i.e., transactions) submitted by participants (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Each participant (e.g., peer node) can maintain a copy of the ledger. A transaction may result in a set of asset key-value pairs being submitted to the ledger as one or more operands (e.g., create, update, delete, etc.). The ledger includes a blockchain (also called a chain) that stores immutable, ordered records in blocks. The shared ledger also includes a state database that maintains the current state of the blockchain.

[0038] Applications can utilize chains as transaction logs, structured as hash-linked blocks, and each block contains a sequence of N transactions, where N is equal to or greater than 1. The block header includes the hash of the block transaction, as well as the hash of the previous block header. In this way, all transactions on the ledger can be ordered and cryptographically linked together. Therefore, it is impossible to tamper with the ledger data without breaking the hash link. The hash of the most recently added blockchain block represents every transaction that occurred previously on the chain, thereby ensuring that all peer nodes are in a consistent and trusted state. The chain can be stored on the peer node file system (i.e. local, attached storage, cloud, etc.), effectively supporting the append-only nature of blockchain workloads.

[0039] The current state of the immutable ledger represents the latest values ​​of all keys included in the chain's transaction log. Because the current state represents the latest key values ​​known to the channel, it is sometimes referred to as the world state. Chaincode invocations execute transactions against the current state data of the ledger. In order for these chaincode interactions to be efficient, the latest values ​​of the keys can be stored in a state database. The state database may be just an indexed view of the chain's transaction log, so it can be regenerated from the chain at any time. The state database can be automatically restored (or generated on demand) when a peer node starts and before accepting transactions.

[0040] Some benefits of the solution described herein include the following. The disclosed protocol provides an efficient and verifiable consensus mechanism for the most popular algorithms in machine learning and artificial intelligence (stochastic gradient descent computations and their variants). Verification of transaction proposals is orders of magnitude faster than conventional verification (hours versus seconds) based on approximate and provably correct verification rather than recomputation processes. The disclosed embodiments enable verification in different kinds of machine learning and artificial intelligence processes, including but not limited to popular machine learning training, optimization, deep neural networks, and support vector machines (SVMs). The disclosed embodiments also provide higher efficiency than conventional methods and enable real-time auditing by moving from "post-processing audits" through recomputation to real-time computational guarantees.

[0041] This application enables efficient (real-time) verification of blockchain native machine learning and artificial intelligence processes. For example, training a deep neural network involves multiple gradient descent updates. The problem solved by this application involves the current blockchain consensus process. The current blockchain consensus process verifies any calculation through a "recalculation and comparison" method by each endorsing peer. In the Hyperledger Fabric blockchain network, the consensus mechanism involves multiple "endorsing peers" who perform the same calculation as the participant / peer who submitted the transaction and then compare the results. Only when a specified number of endorser nodes or peers agree on the result do they reach a "consensus". If the traditional blockchain process is used, the gradient calculation will be performed as part of the smart contract on the blockchain. Multiple endorsers will repeat the gradient calculation for each iteration and then compare and verify the results. This is a wasteful and inefficient method. The current blockchain consensus process is only suitable for simple and lightweight calculations (such as simple financial operations). For complex calculations, such as gradient calculations in machine learning and artificial intelligence processes, a more efficient and computationally lighter method is needed.

[0042] This application adds capabilities to blockchain technology by enabling rapid verification of machine learning training processes. Although it can be used without a blockchain, the main benefit of the disclosed verification protocol is that it is intended to speed up machine learning training on the blockchain. Similar results might be achieved if there was a fully trusted party that all other participants fully trusted running the database and all verifiers were honest and could be trusted. But this is not the case in many (or even most) practical settings.

[0043] This application improves processing speed and resource consumption in blockchain networks while training machine learning models on blockchain. The novel protocol is designed to help blockchain applications effectively verify machine learning / artificial intelligence training updates. Without a public protocol, if machine learning training processes are published as smart contracts, they will trigger the duplication of these processes on endorsers, delaying the consensus step. The disclosed embodiments provide a novel and efficient verification mechanism that does not repeat the training process. The verification mechanism can be published as a smart contract on behalf of the machine learning training process.

[0044] This application proposes a new type of smart contract that accompanies the machine learning training process. To do this, the smart contract transaction will have relevant details about parts of the training data and model updates. The improvement is exactly when the endorser uses this metadata to verify the training calculation. It does not need to perform the model training step again (this step is computationally expensive). The disclosed embodiment describes a protocol for an efficient verification step for endorser nodes or peers in a blockchain network.

[0045] Figure 1A A block diagram of verifying gradient transaction endorsement in a blockchain according to an example embodiment is shown. Figure 1A , the network 100 includes a training participant client 104. The training participant client 104 is a blockchain client responsible for training the machine learning model. Due to the limited computing resources on common blockchain peers, gradient calculations performed by blockchain peers may be difficult to handle, so gradient calculations are only performed by the training participant client 104. Efficient gradient calculations may require advanced computing resources including graphics processing units (GPUs), which are more economically deployed in the blockchain client 104 that directly handles the advanced calculations.

[0046] The training participant client 104 may be part of a training participant network 112 that includes other training participant clients 104. The training participant client 104 includes a training data set 108. The blockchain network 100 may be a public or permissioned blockchain network 100. However, the disclosed processes are primarily intended for use with permissioned blockchain networks 100.

[0047] Stochastic gradient descent is a standard optimization technique for training machine learning models. The technique involves computing the so-called "gradient" of a specific loss function defined on the training data set 108 and the type of model involved. In technical terms, the gradient represents the best improvement that can be made to the model in the current iteration. In a typical machine learning training process, you start with an initial model (intended to make predictions) and update the model step by step (i.e., iteratively), guiding you in the direction of the best possible improvement at each step. At the end of the process, you expect to find a model that works well on the data set 108 used to train the model. This step-by-step updating process is called an iteration.

[0048] The disclosed procedures provide efficiently verifiable consensus mechanisms and protocols for the most popular stochastic gradient descent protocols and variants. These procedures provide orders of magnitude faster computation (seconds vs. hours) based on approximate and provably correct verification. They enable verifiability in different types of machine learning and artificial intelligence processes (e.g., popular machine learning training, optimization, etc., including deep neural networks and support vector machines (SVMs)). The disclosed procedures also provide real-time auditability, moving from "post-processing auditing" through recomputation to real-time computation assurance.

[0049] In machine learning, during training, the model update process may require a very expensive process to calculate the gradient. During testing, only predictions need to be made based on the current model. This prediction step is very fast. The disclosed novel method uses a few fast prediction steps to verify the gradient calculation in a single training step.

[0050] In some embodiments, the training participant network 112 may include a trusted blockchain node or peer (not shown) that interfaces directly with blockchain nodes or peers that provide endorsements, ordering services, and block committers. The blockchain network 100 includes various endorser nodes or peers 116, each of which includes a verification gradient smart contract 120. There may be any number of endorser nodes or peers 116 in the blockchain network 100. Figure 1A N endorser nodes or peers 116 are shown, from endorser node or peer 116A (including verification gradient smart contract 120A) to endorser node or peer 116N (including verification gradient smart contract 120N).

[0051] The training participant client 104 performs gradient computation on the training data set 108, and the training participant network 112 provides the result in a verification gradient transaction proposal 124 to the endorser node or peer 116. The endorser node or peer 116 executes the verification gradient smart contract 120 on the verification gradient transaction proposal 124. The approved verification gradient transaction proposal 124 is returned to the training participant network 112 as an endorsement 128. Otherwise, the failed verification gradient transaction proposal 124 is rejected. In the blockchain context, the endorser 116 typically verifies the computation in the smart contract. However, the precise training process located at the training participant client 104 cannot be included in the smart contract because it will trigger the repetition of the computationally expensive training process, thereby causing significant delays within the blockchain network 100.

[0052] As an example, consider a single training participant client 104 with data D training a model M using stochastic gradient descent or a related process. The goal is to ensure that the model is trained correctly by verifying the gradient at each step or iteration. In the first step, the training participant client 104 uses the previous model parameters W t and batch B access batch B from D and compute the latest gradient g on the loss function L t . Data D and model parameters W t Belongs to the training participant client 104 responsible for training the model. These are stored outside the blockchain, and only the attributes relevant to verification are stored on the blockchain. A typical step (iteration) in the training process takes the current model parameters W t , and update them using a small subset of samples from the training dataset 108. Subsequently, the new model parameters are further updated using some other subsets of samples. Any of these small subsets of samples used in the steps is called a batch B. The previous model parameters W t are the parameters of the output model from the previous training step or iteration.

[0053] The gradient calculation can be expressed as: Combined with reference Figure 1C Discussion Verify the parameters above of the Gradient smart contract description.

[0054] The weight calculation can be expressed as: W t+1 =W t -hg t h is a scalar value that determines the step size (also known as the learning rate in machine learning), which is the amount by which the current model should be updated in the direction of the gradient.

[0055] Blockchain verification (API call) is the verification gradient (W t , g t , B). In the second step, the previous model parameters W t , gradient gt The new verification gradient transaction proposal 124 for batch B is submitted to the blockchain network 100. In the third step, one or more endorser nodes or peers 116 execute the verification gradient smart contract 120 to verify the correctness of the gradient calculation performed by the training participant client 104 and return the endorsement 128.

[0056] Figure 1B FIG. 1 is a block diagram of a training participant network 112 according to an example embodiment. Figure 1B , the training participant network 112 may include a set of training participant clients 104, each training participant client including a training data set 108. The training participant network 112 may include any number of training participant clients 104, and Figure 1B There are shown M training participant clients 104 in training participant network 112. Training participant client 104A includes training data set 108A, training participant client 104B includes training data set 108B, and training participant client 104M includes training data set 108M.

[0057] In one embodiment, federated learning, such as Google's, may require a collaborative process in which training participants 104 train a common model. The training aggregator 132 collects gradient calculations 136 from the training participants 104 and combines them to create an aggregate model. The training aggregator 132 can be a special type of training participant 104 that is responsible for collecting inputs (e.g., gradients) from different training participants 104 and applying them to the model being collectively trained. It is desirable to enable updates to be verified in a distributed machine learning setting to ensure that no training participants 104 are cheating. Model parameters 136 specify / describe the model in mathematical terms. These parameters 136 are used during prediction. In collaborative machine learning applications, there may be multiple training participants 104 contributing their own personal data sets 108.

[0058] Each training participant client 104 provides a gradient calculation 136 to the training aggregator 132. The gradient calculation 136 is performed by each training participant client 104 on its own training data set 108. In one embodiment, the training aggregator 132 is a blockchain client, and in other embodiments, may include a trusted blockchain node or peer. The illustrated embodiment assumes that the training aggregator 132 is also a trusted blockchain node or peer. The training aggregator generates a verification gradient transaction proposal 124 in response to the received gradient calculation 136.

[0059] Figure 1C FIG. 1 is a block diagram of an alternative embodiment of a gradient calculation verification system 150 according to an example embodiment. Figure 1B, the training participant network 150 may include an endorser node or peer 116 that may not include the verification gradient smart contract 120. Instead, the endorser node or peer 116 can access a trusted independent auditor 154. The independent auditor 154 is an auditing entity (e.g., a government agency) responsible for verifying the progress of the machine learning training process. The endorser node or peer 116 can refer to the independent auditor 154 to perform the verification gradient smart contract 120 and the verification gradient calculation steps. In response to receiving the gradient calculation transaction proposal 124 from the training participant network 112, the endorser node or peer 116 forwards the gradient calculation transaction proposal 162 to the independent auditor 154.

[0060] The independent auditor 154 performs verification of the gradient smart contract 120 on the received forwarded gradient computation transaction proposal 162. The verification result 166 may include an endorsement or a rejected transaction proposal and is returned to the endorser node or peer 116, and the verification result 166 is ultimately included in the shared ledger 128 of the gradient computation verification system 150. Each endorser node or peer 116 includes a copy of the shared ledger 158, the endorser node or peer 116A includes the shared ledger 158A, and the endorser node or peer 116N includes the shared ledger 158N.

[0061] Verify that the gradient smart contract 120 performs the following steps:

[0062] First, the verification gradient smart contract 120 selects a random scalar β and a random unit vector μ. Next, the verification gradient smart contract 120 uses the following formula to verify the correctness of the gradient:

[0063] Verify the gradient function (W t ,g t ,β,B)=|S(x∈B)L(W t +βm;x)-L(W t ; x)-|B|β(g T μ)|<τW t Refers to model parameters (weight parameters)

[0064] g t Refers to the gradient g calculated to the tth iteration

[0065] S refers to the sum of the following

[0066] x refers to a sample in batch B used to start the smart contract

[0067] B stands for batch, which is the sample subset used to calculate the model update

[0068] L is the loss function, which represents the cost metric associated with the prediction accuracy that the machine learning algorithm is trying to optimize. The loss function L optimized during the training process has two input parameters - one is the current model parameters W t , the other is the sample x. ";" is a separator used to separate the two parameters of the loss function.

[0069] Since B is a set of points, |B| refers to the number of points in B (the cardinality of B).

[0070] g t Refers to the gradient g calculated to the tth iteration

[0071] g T Refers to the vector transpose operation, which is used to calculate the transaction-by-transaction product of two vectors

[0072] τ is a small suitable threshold parameter. τ can be set to β 2 * Smoothness parameter. The smoothness parameter is the smoothness parameter of the loss function L and depends on the application. The smoothness parameter is an upper bound on the absolute value of the Hessian eigenvalue of the loss function L.

[0073] To verify the correctness of the gradient calculation, the Verify Gradient Smart Contract 120 uses the current model parameters and applies a Taylor expansion to the loss function L under small perturbations of the model parameters along a selected random direction and a selected random step size. Small perturbations reflect small changes in the values ​​of the model parameters. The random direction refers to the random unit vector μ. This is selected by the Verify Gradient Smart Contract 120. The step size is a random scalar β, also selected by the Verify Gradient Smart Contract 120. Assuming that the step size β is small, the above formula holds. A small step size means that the size of the scalar β must be small enough compared to the other parameters.

[0074] Figure 2A A blockchain architecture configuration 200 is shown according to an example embodiment. Figure 2A, the blockchain architecture 200 may include certain blockchain units, such as a set of blockchain nodes 202. The blockchain nodes 202 may include one or more nodes 204-210 (these four nodes are shown by way of example only). These nodes participate in a variety of activities, such as blockchain transaction addition and verification processes (consensus). One or more of the blockchain nodes 204-210 may endorse transactions based on endorsement policies and may provide subscription services for all blockchain nodes in the architecture 200. The blockchain node may initiate a blockchain endorsement and attempt to write a copy of the blockchain immutable ledger stored in the blockchain layer 216 that may also be stored on the underlying physical infrastructure 214. The blockchain configuration may include one or more applications 224, linked to an application programming interface (API) 222 to access and execute stored program / application code 220 (e.g., chain code, smart contracts, etc.) that can be created according to the customized configuration sought by the participants and can maintain its own state, control its own assets, and receive external information. It can be deployed as a transaction and installed on all blockchain nodes 204-210 by attaching it to the distributed ledger.

[0075] The blockchain foundation or platform 212 may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and a foundation of physical infrastructure that may be used to receive and store new transactions and provide access to auditing parties seeking access to data entries. The blockchain layer 216 may expose interfaces that provide access to the virtual execution environment necessary to process program code and use the physical infrastructure 214. Cryptographic trust services 218 may be used to verify transactions such as asset exchange transactions and keep information private.

[0076] Figure 2A The blockchain architecture configuration can process and execute program / application code 220 via one or more interfaces exposed by the blockchain platform 212 and the services provided. Code 220 can control blockchain assets. For example, code 220 can store and transmit data and can be executed by nodes 204-210 in the form of smart contracts and related chain codes with their execution conditions or other code units. As a non-limiting example, smart contracts can be created to perform reminders, updates, and / or notifications of other changes, updates, etc. The smart contract itself can be used to identify rules related to authorization and access requirements and ledger usage. For example, information 226 may include gradient calculations from one or more training participant clients and may be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 216. Result 228 may include a transaction proposal endorsed by executing a verification gradient smart contract. Physical infrastructure 214 can be used to retrieve any data or information described herein.

[0077] Smart contracts can be created through high-level applications and programming languages ​​and then written to blocks in the blockchain. Smart contracts can include executable code that is registered, stored, and / or replicated by a blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of smart contract code that can be executed in response to the satisfaction of a condition associated with a smart contract. The execution of a smart contract can trigger trusted modifications to the state of a digital blockchain ledger. Modifications to the blockchain ledger caused by the execution of a smart contract can be automatically replicated throughout the distributed network of blockchain peers through one or more consensus protocols.

[0078] Smart contracts can write data to the blockchain in the format of key-value pairs. In addition, smart contract code can read values ​​stored in the blockchain and use them in application operations. Smart contract code can write the output of various logical operations to the blockchain. The code can be used to create temporary data structures in a virtual machine or other computing platform. The data written to the blockchain can be public and / or can be encrypted and kept private. Temporary data used / generated by smart contracts is kept in memory by the provided execution environment and deleted once the data is identified as needed for the blockchain.

[0079] Chaincode may include a code interpretation of a smart contract with additional features. As described herein, chaincode may be a program code deployed on a computing network that is executed on-chain and validated by a chain validator during a consensus process. The chaincode receives the hash and retrieves from the blockchain a hash associated with a data template created using a previously stored feature extractor. If the hash value of the hashed identifier matches the hash value created from the stored identifier template data, the chaincode sends the authorization key to the requesting service. The chaincode may write data associated with the cryptographic details to the blockchain.

[0080] Figure 2B An example of a blockchain transaction flow 250 between nodes of a blockchain according to an example embodiment is shown. Figure 2B, a transaction flow may include a transaction proposal 291 sent by an application client node 260 to an endorsing peer node 281. The endorsing peer node 281 may verify the client signature and execute the chaincode function to initiate the transaction. The output may include a chaincode result, a set of key / value versions read in the chaincode (read set), and a set of key / values ​​written in the chaincode (write set). If approved, a proposal response 292 is sent back to the client 260 along with the endorsement signature. The client 260 assembles the endorsement into a transaction payload 293 and broadcasts it to the ordering service node 284. The ordering service node 284 then delivers the ordered transaction as a block to all peers 281-283 on the channel. Each peer 281-283 may validate the transaction before committing to the blockchain. For example, a peer may check the endorsement policy to ensure that the correct assignment of the specified peer has signed the result and verified the signature against the transaction payload 293.

[0081] Reference again Figure 2B , the client node 260 initiates a transaction 291 by constructing a request and sending it to the peer node 281 acting as an endorser. The client 260 may include an application utilizing a supported software development kit (SDK) to generate a transaction proposal using the available APIs. The proposal is a request to invoke a chaincode function so that data can be read and / or written to the ledger (i.e., write a new key-value pair for an asset). The SDK may act as a shim, packaging the transaction proposal into an appropriate schema format (e.g., protocol buffers over remote procedure calls (RPCs)) and generating a unique signature for the transaction proposal using the client's cryptographic credentials.

[0082] In response, the endorsing peer 281 may verify that (a) the transaction proposal is formatted correctly, (b) the transaction has not been submitted in the past (replay attack protection), (c) the signature is valid, and (d) the submitter (in this example, client 260) is properly authorized to perform the proposed operation on the channel. The endorsing peer 281 may input the transaction proposal as a parameter to the invoked chaincode function. The chaincode is then executed against the current state database to produce a transaction result including a response value, a read set, and a write set. However, no updates have been made to the ledger at this point. In 292, the set of values ​​is passed back to the SDK of client 260 along with the signature of the endorsing peer 281 as a proposal response 292, and the SDK of client 260 parses the payload for consumption by the application.

[0083] In response, the client 260 application checks / verifies the endorsed peer signature and compares the proposal response to determine if the proposal responses are the same. If the chaincode only queries the ledger, the application will check the query response and generally not submit the transaction to the ordering node service 284. If the client application intends to submit the transaction to the ordering node service 284 to update the ledger, the application determines whether the specified endorsement policy has been implemented (i.e., whether all peer nodes required for the transaction endorse the transaction) before submission. Here, the client may include only one of the multiple parties to the transaction. In this case, each client may have its own endorsing node, and each endorsing node is required to endorse the transaction. The architecture is such that even if the application chooses not to check the response or otherwise forward unendorsed transactions, the endorsement policy will still be enforced by the peers and maintained during the submission verification phase.

[0084] After successful checks, in step 293, client 260 assembles the endorsements into a transaction and broadcasts the transaction proposal and response within a transaction message to ordering nodes 284. The transaction may contain read / write sets, endorsement peer signatures, and channel IDs. Ordering nodes 284 do not need to check the entire contents of a transaction in order to perform their operations, but rather ordering nodes 284 may simply receive transactions from all channels in the network, order them chronologically by channel, and create a transaction block for each channel.

[0085] The block of transactions is passed from the ordering node 284 to all peer nodes 281-283 on the channel. Transactions within the block 294 are validated to ensure that any endorsement policies are satisfied and that the ledger state of the read set variables has not changed since the transaction execution generated the read set. The transactions in the block are marked as valid or invalid. In addition, in step 295, each peer node 281-283 appends the block to the channel's chain and, for each valid transaction, commits the write set to the current state database. An event is emitted to notify the client application that the transaction (call) has been immutably attached to the chain and notifies whether the transaction was validated or invalid.

[0086] Figure 3A An example of a permissioned blockchain network 300 is shown, featuring a distributed, decentralized peer-to-peer architecture. In this example, a blockchain user 302 can initiate a transaction to a permissioned blockchain 304. In this example, a transaction can be a deployment, call, or query, and can be issued directly by a client application utilizing an SDK. The network can provide access to regulators such as auditors 306. The blockchain network operator 308 manages member permissions, such as registering regulators 306 as "auditors" and registering blockchain users 302 as "clients." Auditors may be limited to querying the ledger, while clients may be authorized to deploy, call, and query certain types of chaincodes.

[0087] Blockchain developers 310 can write chaincodes and client applications. Blockchain developers 310 can deploy chaincodes directly to the network through an interface. In order to include credentials from traditional data sources 312 in the chaincode, developers 310 can use out-of-band connections to access the data. In this example, blockchain user 302 connects to the permissioned blockchain 304 through peer node 314. Before conducting any transactions, peer node 314 retrieves the user's registration and transaction certificates from the certificate authority 316 that manages user roles and permissions. In some cases, blockchain users must have these digital certificates in order to conduct transactions on the permissioned blockchain 304. At the same time, users who attempt to use the chaincode may be required to verify their credentials on the traditional data source 312. In order to confirm the user's authorization, the chaincode can use an out-of-band connection to this data through the traditional processing platform 318.

[0088] Figure 3B Another example of a permissioned blockchain network 320 is shown, featuring a distributed, decentralized peer-to-peer architecture. In this example, a blockchain user 322 can submit a transaction to a permissioned blockchain 324. In this example, a transaction can be a deployment, call, or query, and can be issued directly through an API or the like by a client application utilizing an SDK. The network can provide access to regulators 326 such as auditors. The blockchain network operator 328 manages member permissions, such as registering regulators 326 as "auditors" and registering blockchain users 322 as "clients." Auditors may be limited to querying the ledger, while clients may be authorized to deploy, call, and query certain types of chaincodes.

[0089] Blockchain developers 330 write chaincodes and client applications. Blockchain developers 330 can deploy chaincodes directly to the network through an interface. To include credentials from a traditional data source 332 in the chaincode, developers 330 can use out-of-band connections to access the data. In this example, blockchain user 322 connects to the network through peer node 334. Before conducting any transactions, peer node 334 retrieves the user's registration and transaction certificates from certificate authority 336. In some cases, blockchain users must possess these digital certificates in order to conduct transactions on the permissioned blockchain 324. At the same time, users attempting to use the chaincode may be required to verify their credentials on the traditional data source 332. To confirm the user's authorization, the chaincode can use an out-of-band connection to this data through a traditional processing platform 338.

[0090] In some embodiments, the blockchain herein may be a permissionless blockchain. In contrast to requiring permission to join a permissioned blockchain, anyone can join a permissionless blockchain. For example, to join a permissionless blockchain, a user can create a personal address and begin interacting with the network by submitting transactions and thereby adding entries to the ledger. In addition, all parties may choose to run nodes on the system and employ a mining protocol to help validate transactions.

[0091] Figure 3C A process 350 of a transaction being processed by a permissionless blockchain 352 including a plurality of nodes 354 is shown. A sender 356 wishes to send a payment or some other form of value (e.g., a deed, medical record, contract, good, service, or any other asset that can be encapsulated in a digital record) to a receiver 358 via the permissionless blockchain 352. In one embodiment, each of the sender device 356 and the receiver device 358 may have a digital wallet (a blockchain associated with the blockchain 352) that provides user interface controls and a display of transaction parameters. In response, the transaction is broadcast to the nodes 354 throughout the blockchain 352. Based on the network parameters of the blockchain 352, the nodes validate 360 ​​the transaction based on rules established by the creator of the permissionless blockchain 352 (which may be predefined or dynamically assigned). For example, this may include verifying the identities of the parties involved, etc. The transaction may be validated immediately, or it may be placed in a queue with other transactions, and the nodes 354 determine whether the transaction is valid based on a set of network rules.

[0092] In structure 362, valid transactions form a block and are sealed with a lock (hash). This process can be performed by a mining node among nodes 354. The mining node can utilize additional software specifically for mining and creating blocks for the permissionless blockchain 352. Each block can be identified by a hash (e.g., a 256-bit number, etc.) created using an algorithm agreed upon by the network. Each block may include a header, a pointer or reference to the hash of the previous block header in the chain, and a set of valid transactions. The reference to the previous block hash is associated with the creation of a secure independent blockchain.

[0093] Before a block can be added to the blockchain, it must be verified. Verification of the permissionless blockchain 352 can include proof of work (PoW), which is the solution to a puzzle derived from the block header. Figure 3C It is not shown in the example of , but another process for verifying blocks is proof-of-stake. A similar proof is then performed by the selected nodes.

[0094] By mining 364, nodes attempt to solve the block by making incremental changes to one variable until the solution meets the network-wide target. This creates a PoW that guarantees the correct answer. In other words, a potential solution must prove that computational resources were expended on solving the problem.

[0095] Here, the PoW process, along with the chain of blocks, makes modification of the blockchain extremely difficult, as an attacker must modify all subsequent blocks in order for a modification to one block to be accepted. Furthermore, as new blocks are mined, the difficulty of modifying a block increases, and the number of subsequent blocks also increases. Successfully validated blocks are distributed through the permissionless blockchain 352 via distribution 366, and all nodes 354 add the block to the majority chain, which is the audit ledger of the permissionless blockchain 352. Additionally, the value in the transaction submitted by the sender 356 is deposited or otherwise transferred to the digital wallet of the recipient device 358.

[0096] Figure 4 A system message diagram for verifying gradient computation in a blockchain according to an example embodiment is shown. Figure 4 , system diagram 400 includes training client 410, training aggregator 420, and endorser node or peer 430. In the illustrated embodiment, it is assumed that training aggregator 420 is also a trusted node or peer of the same blockchain network. However, in other embodiments, training aggregator 420 can be a client and communicate with endorser node or peer 430 through a separate trusted node or peer.

[0097] The training client 410 first receives the current model parameters 411 from the training aggregator 420. Each training client 410 trains on a local dataset and performs gradient calculations 415 and transmits the gradient calculations and metadata 416 to the training aggregator 420. In turn, the training aggregator 420 generates a transaction proposal 425 for each received gradient calculation and metadata 416. The transaction proposal 426 is then sent to the endorser node or peer 430 of the blockchain network.

[0098] The endorser node or peer 430 receives the transaction proposal 426 and executes the verify gradient smart contract 435. The verify gradient smart contract 435 takes the parameters from the transaction proposal 426 and approves or rejects the transaction proposal 426 by attempting to approve the gradient calculation 416. If the verify gradient smart contract is able to approve the transaction proposal 426, it returns an endorsement 436 to the training aggregator 420, otherwise it returns a rejection. The training aggregator 420 collects the endorsements 436 from the endorser nodes or peers 430 and generates a blockchain transaction 440, which is then submitted 441 to the blockchain network.

[0099] The training aggregator 420 creates a new aggregated machine learning model by combining the endorsed gradients 445 and then generates a new transaction proposal 450.

[0100] Figure 5A A flowchart 500 of an example method for verifying machine learning computations in a blockchain according to an example embodiment is shown. Figure 5A , method 500 may include one or more of the following steps.

[0101] In box 502, the training participant client calculates the gradient of the machine learning or artificial intelligence model training step.

[0102] At block 504, the training participant client submits a gradient computation transaction proposal to the blockchain network. In one embodiment, the training participant client submits a request for a gradient computation to be verified to a trusted node or peer of the blockchain network. The trusted node or peer receives the request and submits a corresponding transaction proposal to the blockchain network.

[0103] At block 506, one or more endorser nodes or peers of the blockchain network receive the transaction proposal and execute the validation gradient smart contract. The validation gradient smart contract evaluates the content of the transaction proposal to determine whether the transaction proposal is valid. In one embodiment, the endorser node or peer does not include a validation gradient smart contract. In this case, the endorser node or peer forwards the transaction proposal to one or more independent auditors outside the blockchain network. The independent contractor includes a validation gradient smart contract and executes the contract to provide endorsement based on the transaction proposal. In this case, the endorser node or peer will provide the endorsed transaction proposal to the training participant client or a trusted blockchain node or peer that handles the endorsement.

[0104] At block 508, the endorser node or peer provides an endorsement for the approved transaction proposal.

[0105] At block 512, the endorser node or peer rejects the unapproved transaction proposal.

[0106] Figure 5B A flowchart 520 of an example method for verifying training aggregator computations in a blockchain according to an example embodiment is shown. Figure 5B , method 520 may include one or more of the following steps.

[0107] At block 522 , a set of training participant clients compute gradients for machine learning or artificial intelligence training computations.

[0108] At block 524, a group of training participant clients submit the original model parameters W received from the training aggregator. t , the new gradients computed on it, and the subset of local data used to train the aggregator.

[0109] At block 526 , the training aggregator converts the gradient computation into a transaction proposal and submits the transaction proposal to the blockchain network.

[0110] At block 528, one or more endorser nodes or peers receive the transaction proposal and execute the validation gradient smart contract to validate the transaction proposal. In one embodiment, the endorser nodes or peers do not include a validation gradient smart contract. In this case, the endorser nodes or peers forward the transaction proposal to one or more independent auditors outside the blockchain network. The independent contractor includes a validation gradient smart contract and executes the contract to provide endorsement based on the transaction proposal. In this case, the endorser nodes or peers provide the endorsed transaction proposal to the training aggregator.

[0111] At block 530, the endorser node or peer provides an endorsement for the approved transaction proposal.

[0112] Figure 5C A flowchart 540 for verifying model updates on a blockchain is shown according to an example embodiment. Figure 5C , method 540 may include one or more of the following steps.

[0113] At block 542, model update data is generated. In various embodiments, the blockchain nodes may each be loaded with one or more computational models configured to perform various machine learning and artificial intelligence operations. In various embodiments, the initial setup, installation, configuration, etc. of the computational models may vary and may be accomplished using any suitable technique. For example, participation in the system may be limited based on a defined list of certificates (where certificates are generated for new nodes joining the system), may be limited based on a private network configuration, may be limited based on a published blockchain address, or the like.

[0114] A node may detect a model update event. For example, a node may detect a model update event while operating a computational model, such as by transmitting (e.g., sending an update to a node). Model update events may include prediction errors, new model requirements, custom events, and the like. For example, a prediction error may be related to an incorrect identification using a computational model, or may be associated with any other suitable or desired error. A new model requirement may involve a new identification required by the computational model. For example, where the computational model is configured to identify inventory in a store, a new model requirement may be in response to a new item (e.g., soda, etc.) being offered as inventory in the store.

[0115] The node generates model update data based on the model update event. The model update data may include training data (e.g., data to be ingested by the node to "train" the computational model to correct prediction errors, detect new model requirements, etc.), model updates (e.g., for merging with the computational model to correct prediction errors, detect new model requirements, etc.), and / or new computational models. The node sends the model update data to the validation node.

[0116] At box 544, verify the model update data. In various embodiments, the verification node may send the model update data based on a distribution algorithm, etc. For example, and in accordance with various embodiments, the delegation to a limited number of verification nodes may be controlled or established via a delegated proof-of-stake system. As another example, the delegation may be controlled by a smart contract (e.g., a publish and subscribe model), wherein verification and model updates are performed by one or more verification nodes. As another example, the delegation may be controlled by a signature authorization for establishing a relationship between nodes. In various embodiments, the delegation to the verification node may also be static and defined, wherein each node may include instructions detailing one or more verification nodes to which the model update data is sent. In various embodiments, one or more verification nodes may also publish contracts and provide payments, etc. to verify and / or update the model update data. The node may select one or more verification nodes based on the published contract.

[0117] In various embodiments, in response to a verification node (and / or multiple verification nodes) receiving multiple model update data transmissions simultaneously, about to, or similarly, the order in which the model is calculated can be updated based on a timestamp (e.g., a timestamp present in the model update data or a timestamp of when the verification node received the model update data). In various embodiments, an average model or algorithm can also be used to aggregate and / or average the received multiple model update data together.

[0118] In response to receiving the model update data, the verification node verifies the model update data. The verification node may broadcast the model update data to one or more other verification nodes in the verification network. The verification node may use any suitable or desired consensus method or algorithm to establish consensus on the model update data, such as proof of work, proof of stake, practical Byzantine fault tolerance, delegated proof of stake, or any other suitable consensus algorithm. The verification node may also be configured to verify the model update data by testing the model update data locally to determine whether the model update data corrects the prediction error, detects new model requirements, etc. For example, the verification node may implement test data and / or model updates locally, and may use a computational model to process the data to determine whether the prediction error is still a problem, whether new model requirements can be detected, etc. As another example, the verification node may test the model update data to identify false positives, false negatives, etc. The test may also be performed by a human to identify new scenarios and / or verify the model update data. The verification node writes the model update data to the model blockchain.

[0119] The validator node may be configured to write the model update data to the model blockchain along with any other suitable data, such as a hash, date or timestamp of the model update data, identification information of the node sending the model update data (e.g., IP address, blockchain address, etc.), and / or any other suitable data or metadata. The validator node propagates the write to the validation network. For example, the validator node may broadcast the write data (e.g., data associated with the block written to the model blockchain, model update data, etc.) to one or more validators in the validation network. Each validator node may be configured to write the model update data to an associated local model blockchain.

[0120] At block 546, an updated computational model is generated. In various embodiments, the verification node generates an updated computational model based on the model update data. For example, the verification node may be configured to generate an updated computational model by merging a pre-existing computational model with the model update data. For example, a pre-existing computational model may be recalculated or retrained using new training data, or a parameter of a pre-existing computational model may be changed based on the model update data.

[0121] At block 548, the updated computational model is validated. The validation node validates the updated computational model. The validation node may broadcast the updated computational model to one or more other validation nodes in the validation network. The validation node may establish consensus on the updated computational model using any suitable or desired consensus method or algorithm, such as proof of work, proof of stake, practical Byzantine fault tolerance, delegated proof of stake, or any other suitable consensus algorithm. The validation node may also be configured to determine the updated computational model by testing the updated computational model locally to determine whether the updated computational model corrects prediction errors, detects new model requirements, and the like. For example, the validation node may implement the updated computational model locally and may process data using the computational model to determine whether prediction errors are still generated, detect whether new model requirements are detected, and the like. The validation node writes the updated computational model to the model blockchain. The validation node may be configured to write the updated computational model to the model blockchain along with any other suitable data, such as a hash of the updated computational model, a date or timestamp, identification information of the node that sent the model update data (e.g., an IP address, a blockchain address, etc.), and / or any other suitable data or metadata.

[0122] At block 550, the updated computational model is propagated. The verification node propagates the write to the verification network. For example, the verification node may broadcast the write data (e.g., data related to the block written to the model blockchain, the updated computational model, etc.) to one or more verification nodes in the verification network. Each verification node may be configured to write the updated computational model to the associated local model blockchain. The verification node broadcasts the updated computational model to the nodes. In various embodiments, the verification node may broadcast the verified model update data instead of the updated computational model to one or more nodes. In various embodiments, the verification node may broadcast the updated computational model based on a distribution algorithm, etc.

[0123] Fig. 6A An example system 600 is shown including a physical infrastructure 610 configured to perform various operations according to an example embodiment. Fig. 6A , the physical infrastructure 610 includes a module 612 and a module 614. The module 614 includes a blockchain 620 and a smart contract 630 (which may reside on the blockchain 620), and may perform any operation step 608 (in the module 612) included in any example embodiment. The step / operation 608 may include one or more embodiments described, and may represent output or written information written or read from one or more smart contracts 630 and / or blockchain 620. The physical infrastructure 610, the module 612, and the module 614 may include one or more computers, servers, processors, memories, and / or wireless communication devices. In addition, the module 612 and the module 614 may be the same module.

[0124] Figure 6B Another example system 640 configured to perform various operations according to an example embodiment is shown. Figure 6B , system 640 includes module 612 and module 614. Module 614 includes blockchain 620 and smart contract 630 (which may be located on blockchain 620), and may perform any operation step 608 (in module 612) included in the example embodiment. Step / operation 608 may include one or more embodiments described, and may represent output or written information written or read from one or more smart contracts 630 and / or blockchain 620. Physical infrastructure 610, module 612, and module 614 may include one or more computers, servers, processors, memories, and / or wireless communication devices. In addition, module 612 and module 614 may be the same module.

[0125] Figure 6C An example system configured to utilize a smart contract between contracting parties and an intermediary server configured to enforce the terms of the smart contract on a blockchain are shown according to an example embodiment. Figure 6C , configuration 650 may represent a communication session, asset transfer session, or process driven by a smart contract 630, which explicitly identifies one or more user devices 652 and / or 656. The results of the smart contract execution may be managed by a server 654. The contents of the smart contract 630 may need to be digitally signed by one or more of the entities 652 and 656 that are parties to the smart contract transaction. The results of the smart contract execution may be written to the blockchain 620 as a blockchain transaction. The smart contract 630 resides on the blockchain 620, which may reside on one or more computers, servers, processors, memories, and / or wireless communication devices.

[0126] Fig.6D A system 660 including a blockchain is shown according to an example embodiment. Fig.6D In the example of , an application programming interface (API) gateway 662 provides a public interface for accessing blockchain logic (e.g., smart contracts 630 or other chaincodes) and data (e.g., distributed ledgers, etc.). In this example, the API gateway 662 is a public interface for executing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 652 and 656 to blockchain peers (i.e., servers 654). Here, the server 654 is a blockchain network peer component that holds a copy of the world state and the distributed ledger, allowing clients 652 and 656 to query data about the world state and submit transactions to the blockchain network, where, depending on the smart contract 630 and the endorsement policy, the endorsement peer will run the smart contract 630.

[0127] The above embodiments may be implemented in hardware, a computer program executed by a processor, firmware, or a combination thereof. The computer program may be embodied on a computer-readable medium such as a storage medium, for example, the computer program may reside in a random access memory ("RAM"), flash memory, read-only memory ("ROM"), erasable programmable read-only memory ("EPROM"), electrically erasable programmable read-only memory ("EEPROM"), registers, a hard disk, a removable disk, a compact disk read-only memory ("CD-ROM"), or any other form of storage medium known in the art.

[0128] An exemplary storage medium may be coupled to a processor so that the processor can read information from the storage medium and write information to the storage medium. Alternatively, the storage medium may be integrated with the processor. The processor and the storage medium may reside in an application specific integrated circuit ("ASIC"). In an alternative, the processor and the storage medium may reside as discrete components.

[0129] Fig. 7A A process 700 for adding a new block to a distributed ledger 720 is shown according to an example embodiment, and Figure 7B The content of a new data block structure 730 for a blockchain according to an example embodiment is shown. Fig. 7A , a client (not shown) can submit a transaction to blockchain nodes 711, 712, and / or 713. A client can be an instruction received from any source for enacting an activity on blockchain 720. As an example, a client can be an application that proposes a transaction for a blockchain on behalf of a requester (e.g., a device, an individual, or an entity). Multiple blockchain peers (e.g., blockchain nodes 711, 712, and 713) can maintain the state of the blockchain network and a copy of the distributed ledger 720. Different types of blockchain nodes / peers can exist in the blockchain network, including endorsement peers that simulate and endorse transactions proposed by clients and submission peers that verify endorsements, verify transactions, and submit transactions to the distributed ledger 720. In this example, blockchain nodes 711, 712, and 713 can act as endorser nodes, submitter nodes, or both.

[0130] The distributed ledger 720 includes a blockchain that stores immutable, sequential records in blocks and a state database 724 (current world state) that maintains the current state of the blockchain 722. There can be one distributed ledger 720 per channel, and each peer maintains a copy of its own distributed ledger 720 for each channel it belongs to. The blockchain 722 is a transaction log structured as hash-linked blocks, where each block contains a sequence of N transactions. A block may include Figure 7B The various components shown. Links to blocks ( Fig. 7A) can be generated by adding the hash value of the previous block header in the block header of the current block. In this way, all transactions on the blockchain 722 are ordered and cryptographically linked together to prevent tampering with the blockchain data without breaking the hash link. In addition, due to the link, the latest block in the blockchain 722 represents every transaction that came before it. The blockchain 722 can be stored on a peer-to-peer file system (local or attached storage), which supports append-only blockchain workloads.

[0131] The current state of the blockchain 722 and the distributed ledger 722 may be stored in a state database 724. Here, the current state data represents the latest values ​​of all keys ever included in the chain transaction log of the blockchain 722. Chaincode invocations execute transactions against the current state in the state database 724. In order to make these chaincode interactions very efficient, the latest values ​​of all keys are stored in the state database 724. The state database 724 may include an indexed view into the transaction log of the blockchain 722, so it can be regenerated from the chain at any time. The state database 724 may be automatically restored (or generated when needed) at the initiation of a peer before accepting a transaction.

[0132] The endorsing node receives the transaction from the client and endorses the transaction based on the simulation results. The endorsing node holds the smart contract that simulates the transaction proposal. When the endorsing node endorses the transaction, the endorsing node creates a transaction endorsement that is a signed response from the endorsing node to the client application, indicating the endorsement of the simulated transaction. The method of endorsing the transaction depends on the endorsement policy that can be specified in the chaincode. An example of an endorsement policy is "a majority of endorsing peers must endorse the transaction". Different channels may have different endorsement policies. The client application forwards the endorsed transaction to the ordering service 710.

[0133] The ordering service 710 accepts endorsed transactions, orders them into a block, and delivers these blocks to commit peers. For example, when a transaction threshold has been reached, a timer has expired, or other conditions, the ordering service 710 can initiate a new block. Fig. 7A In the example of , blockchain node 712 is a submitting peer that has received new data new data block 730 for storage on blockchain 720. The first block in a blockchain can be called a genesis block, including information about the blockchain, its members, the data stored therein, etc.

[0134] The ordering service 710 may consist of a cluster of subscribers. The ordering service 710 does not process transactions, smart contracts, or maintain a shared ledger. Instead, the ordering service 710 may accept endorsed transactions and specify the order in which these transactions are submitted to the distributed ledger 720. The architecture of the blockchain network may be designed to make "ordering" (e.g., Solo, Kafka, BFT, etc.) a pluggable component.

[0135] Transactions are written to the distributed ledger 720 in a consistent order. The order of transactions is established to ensure that updates to the state database 724 are valid when submitted to the network. Unlike cryptocurrency blockchain systems where ordering is performed by solving cryptographic puzzles or mining, in this example, the parties to the distributed ledger 720 can choose the ordering mechanism that best suits the network.

[0136] When the ordering service 710 initializes a new data block 730, the new data block 730 may be broadcast to the submitting peers (e.g., blockchain nodes 711, 712, and 713). In response, each submitting peer verifies the transaction in the new data block 730 by checking to ensure that the read set and the write set still match the current world state in the state database 724. Specifically, the submitting peer may determine whether the read data that existed when the endorser simulated the transaction is the same as the current world state in the state database 724. When the submitting peer verifies the transaction, the transaction is written to the blockchain 722 on the distributed ledger 720, and the state database 724 is updated with the write data in the read-write set. If the transaction fails, that is, if the submitting peer finds that the read-write set does not match the current world state in the state database 724, the transaction ordered into the block will still be included in the block but it will be marked as invalid, and the state database 724 will not be updated.

[0137] Reference Figure 7B , a new data block 730 (also referred to as a data block) stored on the blockchain 722 of the distributed ledger 720 may include multiple data segments, such as a block header 740, block data 750, and block metadata 760. It should be understood that Figure 7B The various blocks and their contents shown in the figure, such as the new data block 730 and its contents, are merely examples and are not meant to limit the scope of the example embodiments. The new data block 730 may store transaction information for N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) within the block data 750. The new data block 730 may also include: a link to a previous block within the block header 740 (e.g., Fig. 7A In particular, the block header 740 may include a hash of a previous block header. The block header 740 may also include a unique block number, a hash of the block data 750 of the new data block 730, and the like. The block number of the new data block 730 may be unique and may be assigned in various sequences, such as increments / sequences starting from zero.

[0138] The block data 750 may store transaction information for each transaction recorded within the new data block 730. For example, the transaction data may include one or more of the following: transaction type, version, timestamp, channel ID of the distributed ledger 720, transaction ID, epoch, payload visibility, chaincode path (deploy TX), chaincode name, chaincode version, inputs (chaincode and function), client (creator) and other identification public keys and certificates, client signatures, endorser identities, endorser signatures, proposal hashes, chaincode events, response statuses, namespaces, read sets (keys and versions read by transactions, etc.), write sets (lists of keys and values, etc.), start keys, end keys, key lists, Merkle tree query digests, etc. Transaction data may be stored for each of the N transactions.

[0139] In some embodiments, block data 750 may also store new data 762 that adds additional information to the chain of hash-linked blocks in blockchain 722. The additional information includes one or more of the steps, features, processes, and / or actions described herein. Thus, new data 762 may be stored in an immutable log of blocks on distributed ledger 720. Some benefits of storing such new data 762 are reflected in the various embodiments disclosed and described herein. Although in Figure 7B , the new data 762 is described in the block data 750 , but may also be located in the block header 740 or the block metadata 760 .

[0140] The block metadata 760 may store multiple fields of metadata (e.g., as a byte array, etc.). The metadata fields may include a signature at the time of block creation, a reference to the last configuration block, a transaction filter that identifies valid and invalid transactions within the block, the last offset duration of the ordering service that orders the block, etc. The signature, the last configuration block, and the subscriber metadata may be added by the ordering service 710. At the same time, the submitter of the block (e.g., blockchain node 712) may add validity / invalidity information based on endorsement policies, verification of read / write sets, etc. The transaction filter may include a byte array of size equal to the number of transactions in the block data 750 and a verification code that identifies whether the transaction is valid / invalid.

[0141] Figure 7C An embodiment of a blockchain 770 for digital content according to embodiments described herein is shown. Digital content may include one or more files and related information. Files may include media, images, video, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable, append-only aspect of the blockchain may serve as a safeguard to protect the integrity, validity, and authenticity of the digital content, making it suitable for use in legal proceedings where admissibility rules apply, or in other contexts where it is desirable to present and use digital information in cases where evidence is considered or otherwise available. In such cases, the digital content may be referred to as digital evidence.

[0142] The blockchain can be formed in a variety of ways. In one embodiment, digital content can be included in the blockchain and can be accessed from it. For example, each block of the blockchain can store a hash value of reference information (e.g., header, value, etc.) along with the associated digital content. The hash value and the associated digital content can then be encrypted together. Therefore, the digital content of each block can be accessed by decrypting each block in the blockchain, and the hash value of each block can be used as a basis for referencing the previous block. It can be illustrated as follows:

[0143]

[0144] In one embodiment, the digital content may not be included in the blockchain. For example, the blockchain may store a cryptographic hash of the content of each block without any digital content. The digital content may be stored in another storage area or memory address in association with the hash value of the original file. The other storage area may be the same storage device used to store the blockchain, or it may be a different storage area, or even a separate relational database. The digital content of each block may be referenced or accessed by obtaining or querying the hash value of the block of interest, and then looking up a value with a value in the storage area stored corresponding to the actual digital content. For example, a database gatekeeper may be implemented. It may be illustrated as follows:

[0145]

[0146] exist Figure 7C In the example embodiment of the present invention, the blockchain 770 includes a plurality of blocks 7781, 7782, ..., 7783 that are cryptographically linked in an ordered sequence. N , where N ≥ 1. Used to link blocks 7781, 7782, ..., 778 N The encryption of can be any one of a number of keyed or non-keyed hash functions. In one embodiment, blocks 7781, 7782, ..., 778 N Processing is performed using a hash function that produces an n-bit alphanumeric output (where n is 256 or another number) from an input based on the information in the block. Examples of such hash functions include, but are not limited to, SHA-type (SHA stands for Secure Hash Algorithm) algorithms, Merkle-Damgard algorithms, HAIFA algorithms, Merkle-tree algorithms, random number-based algorithms, and non-collision-resistant PRF algorithms. In another embodiment, blocks 7781, 7782, ..., 778 can be cryptographically linked by a function different from a hash function. N For purposes of illustration, the following description is made with reference to a hash function such as SHA-2.

[0147] Each block in the blockchain is 7781, 7782, ..., 778 N Includes a header, a file version, and a value. Due to the hashing operation in the blockchain, the header and value are different for each block. In one embodiment, the value may be included in the header. As described in more detail below, the version of the file may be the original file or a different version of the original file.

[0148] The first block 7781 in the blockchain is called the genesis block and includes a header 7721, an original file 7741, and an initial value 7761. The hashing scheme used in the genesis block and in fact in all subsequent blocks can vary. For example, all the information in the first block 7781 can be hashed together at once, or each piece of information or a portion of the information in the first block 7781 can be hashed separately, and then the separately hashed portions can be hashed.

[0149] The header 7721 may include one or more initial parameters, such as a version number, timestamp, random number, root information, difficulty level, consensus protocol, duration, media format, source, descriptive keywords, and / or other information related to the original file 7741 and / or the blockchain. The header 7721 may be generated automatically (e.g., by blockchain network management software) or may be manually generated by a blockchain participant. N Unlike the header in , header 7721 in the genesis block does not reference a previous block, simply because there is no previous block.

[0150] The original file 7741 in the origin block can be, for example, data captured by a device, which may or may not be processed before the device is included in the blockchain. The original file 7741 is received from a device, a media source, or a node through an interface of the system. The original file 7741 is associated with metadata, which can be manually or automatically generated by a user, a device, and / or a system processor, for example. The metadata can be included in the first block 7781 in association with the original file 7741.

[0151] The value 7761 in the origin block is an initial value generated based on one or more unique attributes of the original file 7741. In one embodiment, the one or more unique attributes may include a hash value of the original file 7741, metadata of the original file 7741, and other information associated with the file. In one embodiment, the initial value 7761 may be based on the following unique attributes:

[0152] 1) SHA-2 calculates the hash value of the original file

[0153] 2) Originating device ID

[0154] 3) The start timestamp of the original file

[0155] 4) The original storage location of the original file

[0156] 5) The blockchain network member ID for the software that currently controls the original file and associated metadata

[0157] Other blocks in the blockchain 7782 to 778 N It also has a header, a file, and a value. However, unlike the first block 7721, the headers 7722 to 772 N Each of the blocks includes the hash value of the immediately preceding block. The hash value of the preceding block may be just the hash of the header of the preceding block, or may be the hash value of the entire preceding block. By including the hash value of the preceding block in each of the remaining blocks, it is possible to go back from the Nth block to the origin block (and the associated original file) block by block, as shown by arrow 780, to establish an auditable and unchangeable chain of custody.

[0158] Headers 7722 to 772 in other blocks N Each of the may also include other information, such as a version number, a timestamp, a random number, root information, a difficulty level, a consensus protocol, and / or other parameters or information associated with the corresponding file and / or the general blockchain.

[0159] Files 7742 to 774 in other blocks N The original file may be equal to the original file, or may be a modified version of the original file in the originating block, for example, depending on the type of processing performed. The type of processing performed may vary from block to block. The processing may include, for example, any modification of the file in a previous block, such as editing information or otherwise changing the contents of the file, taking information away from the file, or adding or appending information to the file.

[0160] Additionally or alternatively, processing may include merely copying a file from a previous block, changing a storage location of a file, analyzing a file from one or more previous blocks, moving a file from one storage or memory location to another, or performing operations relative to the blockchain file and / or its associated metadata. Processing involving analyzing a file may include, for example, appending, including, or otherwise associating various analytical, statistical, or other information associated with the file.

[0161] Each of the other blocks 7762 to 776 N The values ​​in a block are unique values ​​and are all different due to the processing performed. For example, the value in any one block corresponds to an updated version of the value in the previous block. The update is reflected in the hash of the block to which the value is assigned. The value of the block thus provides an indication of what processing was performed in the block and also allows tracing back to the original file through the blockchain. This tracking confirms the chain of custody of the file throughout the blockchain.

[0162] For example, consider a situation where portions of a file in a previous block are redacted, masked, or pixelated to protect the identity of the person appearing in the file. In this case, the block that includes the redacted file will include metadata associated with the redacted file, such as how the redaction was performed, who performed the redaction, a timestamp of when the redaction was performed, etc. The metadata may be hashed to form a value. Because the metadata for this block is different than the information that was hashed to form the value in the previous block, the values ​​are distinct from one another and can be recovered upon decryption.

[0163] In one embodiment, when any one or more of the following occurs, the value of the previous block can be updated (e.g., a new hash value is calculated) to form the value of the current block. In this example embodiment, a new hash value can be calculated by hashing all or part of the information described below.

[0164] a) The new SHA-2 calculated hash value if the file has been manipulated in any way (for example, if the file has been edited, copied, changed, accessed, or other actions have been taken)

[0165] b) New storage location for the file

[0166] c) Determine new metadata associated with the file

[0167] d) Transferring access to or control of a file from one blockchain participant to another

[0168] Fig.7D An embodiment of a block that can represent the structure of a block in blockchain 790 is shown according to one embodiment. i Including head 772 i 、File 774 i The sum is 776 i .

[0169] Head 772 i Including the previous block Blocki i-1 The hash value and additional reference information of the previous block, which can be any type of information discussed in this article (e.g., header information including references, features, parameters, etc.). Of course, all blocks except the origin block reference the hash of the previous block. The hash value of the previous block can be just the hash of the previous block header, or it can be the hash of all or part of the information in the previous block, including files and metadata.

[0170] File 774 iThe system includes a plurality of data, such as data 1, data 2, ..., data N. The data are marked with metadata metadata 1, metadata 2, ..., metadata N, which describe the content and / or characteristics associated with the data. For example, the metadata of each data may include a timestamp indicating the data, processing data, keywords indicating a person or persons described in the data or other content, and / or other characteristics that may be helpful in determining the validity and content of the entire file, especially using digital evidence, for example, as described in the embodiments discussed below. In addition to the metadata, each data may be marked with reference REF1, REF2, ..., REF N Marking to previous data to prevent tampering, gaps in the file, and sequential reference through the file.

[0171] Once metadata is assigned to data (e.g., by a smart contract), it cannot be changed without changing the hash, which can be easily identified as invalid. Metadata thus creates a data log of information that can be accessed by participants in the blockchain for use.

[0172] Value 776 i is a hash value or other value calculated based on any of the types of information discussed previously. For example, for any given block i , the value of the block can be updated to reflect the processing performed on the block, such as a new hash value, a new storage location, new metadata for the associated file, a transfer of control or access rights, an identifier, or other operations or information to be added. Although the value in each block is shown separate from the metadata for the file and header data, in another embodiment, the value can be based in part or in whole on the metadata.

[0173] Once the blockchain 770 is formed, at any point in time, the immutable chain of custody of the file can be obtained by querying the blockchain for the transaction history of the values ​​across the blocks. The query or tracking process can start by decrypting the value of the currently included block (e.g., the last (Nth) block), and then continue to decrypt the values ​​of other blocks until the origin block is reached and the original file is restored. Decryption can also include decrypting the header and file and associated metadata at each block.

[0174] Decryption is performed based on the type of encryption that occurs in each block. This may involve the use of private keys, public keys, or public-private key pairs. For example, when asymmetric encryption is used, a blockchain participant or processor in the network can use a predetermined algorithm to generate a public and private key pair. The public and private keys are related to each other through some mathematical relationship. The public key can be publicly distributed to be used as an address to receive messages from other users, for example, an IP address or a home address. The private key is kept secret and is used to digitally sign messages sent to other blockchain participants. The signature is included in the message so that the recipient can verify it using the sender's public key. In this way, the recipient can be sure that only the sender can send this message.

[0175] Generating a key pair can be similar to creating an account on the blockchain, but without having to actually register anywhere. In addition, the sender uses the private key to digitally sign each transaction performed on the blockchain. The signature ensures that only the account owner can track and process (if within the scope of permission determined by the smart contract) the blockchain file.

[0176] Fig. 8A and 8B Other examples of blockchain use cases that can be incorporated and used here are shown. In particular, Fig. 8A An example 800 of a blockchain 810 storing machine learning (artificial intelligence) data is shown. Machine learning relies on large amounts of historical data (or training data) to build predictive models to make accurate predictions about new data. Machine learning software (such as neural networks, etc.) can often sift through millions of records to mine non-intuitive patterns.

[0177] exist Fig. 8A In the example of , host platform 820 builds and deploys a machine learning model for predictive monitoring of asset 830. Here, host platform 820 may be a cloud platform, an industrial server, a web server, a personal computer, a user device, etc. Asset 830 may be any type of asset (e.g., a machine or equipment, etc.), such as an airplane, a locomotive, a turbine, medical machinery and equipment, oil and gas equipment, a ship, a vessel, a vehicle, etc. As another example, asset 830 may be a non-tangible asset, such as a stock, currency, a digital coin, insurance, etc.

[0178] The blockchain 810 can be used to significantly improve the training process 802 of the machine learning model and the prediction process 804 based on the trained machine learning model. For example, in 802, instead of data being collected by data scientists / engineers or other users, historical data can be stored on the blockchain 810 by the asset 830 itself (or through an intermediary, not shown). This can significantly reduce the collection time required by the host platform 820 when performing predictive model training. For example, using smart contracts, data can be directly and reliably transmitted directly from its source location to the blockchain 810. By using the blockchain 810 to ensure the security and ownership of the collected data, the smart contract can send data directly from the smart contract. Individual assets that use this data to build machine learning models. This allows data to be shared between assets 830.

[0179] The collected data can be stored in the blockchain 810 based on a consensus mechanism. The consensus mechanism introduces (permitted nodes) to ensure that the recorded data is verified and accurate. The recorded data is time-stamped, cryptographically signed, and immutable. Therefore, it is auditable, transparent, and secure. In some cases (such as supply chain, healthcare, logistics, etc.), adding IoT devices that write directly to the blockchain can increase the frequency and accuracy of recorded data.

[0180] In addition, training the machine learning model on the collected data by the host platform 820 can be carried out for several rounds of improvement and testing. Each round can be based on additional data or data that was not previously considered to help expand the knowledge of the machine learning model. In 802, the host platform 820 can store the different training and testing steps (and the data associated therewith) on the blockchain 810. Each refinement of the machine learning model (e.g., changes in variables, weights, etc.) can be stored on the blockchain 810. This provides verifiable evidence about how the model was trained and what data was used to train the model. In addition, when the host platform 820 has obtained the final trained model, the resulting model can be stored on the blockchain 810.

[0181] After the model is trained, it can be deployed in a real environment, and predictions / decisions can be made based on the execution of the final trained machine learning model. For example, in 804, the machine learning model can be used for condition-based maintenance (CBM) of assets such as aircraft, wind turbines, healthcare machines, etc. In this example, data fed back from the asset 830 can be input into the machine learning model and used to make event predictions, such as failure events, error codes, etc. The determination made by executing the machine learning model on the host platform 820 can be stored on the blockchain 810 to provide auditable / verifiable evidence. As a non-limiting example, the machine learning model can predict a future failure / error of a part of the asset 830 and create an alert or notification to replace the part. The data behind the decision can be stored on the blockchain 810 by the host platform 820. In one embodiment, the features and / or actions described and / or depicted herein can occur on or with respect to the blockchain 810.

[0182] New transactions for a blockchain can be collected together into a new block and added to an existing hash. This is then encrypted to create a new hash for the new block. This is added to the next list of transactions after encryption, and so on. The result is a chain of blocks, with each block containing the hashes of all the previous blocks. The computers storing these blocks periodically compare their hashes to make sure they all agree. Any computer that disagrees will discard the record that caused the problem. This method is useful for ensuring that the blockchain is tamper-proof, but it is not perfect.

[0183] One way to game the system is for a dishonest user to change the transaction list to their liking, but keep the hash the same. This can be done by brute force, in other words, by changing the record, encrypting the result, and seeing if the hash is the same. If not, it is tried again and again until a matching hash is found. The security of the blockchain is based on the belief that ordinary computers can only perform such brute force attacks in completely unrealistic timescales (such as the age of the universe). In contrast, quantum computers are much faster (thousands of times faster) and therefore pose a much greater threat.

[0184] Figure 8B An example 850 of a quantum-safe blockchain 852 is shown, implementing quantum key distribution (QKD) to protect against quantum computing attacks. In this example, blockchain users can use QKD to verify each other's identities. It uses quantum particles such as photons to send information, which cannot be copied by an eavesdropper without destroying them. In this way, senders and receivers through the blockchain can be sure of each other's identities.

[0185] exist Figure 8BIn the example of , there are four users 854, 856, 858, and 860. Each of the pairs of users can share a secret key 862 (i.e., QKD) between them. Since there are four nodes in this example, there are six pairs of nodes, and therefore six different private keys 862 are used, including QKD AB , QKD AC , QKD AD , QKD BC , QKD BD and QKD CD Each pair can create QKD by sending information using quantum particles, such as photons, which cannot be copied by an eavesdropper without destroying them. In this way, a pair of users can determine each other's identity.

[0186] The operation of blockchain 852 is based on two processes (i) creating transactions, and (ii) building blocks that aggregate new transactions. New transactions can be created similar to traditional blockchain networks. Each transaction can contain information about the sender, the receiver, the creation time, the amount (or value) to be transferred, a list of reference transactions that prove that the sender has sufficient funds for the operation, etc. This transaction record is then sent to all other nodes and entered into a pool of unconfirmed transactions. Here, two parties (i.e., a pair of users in 854-860) authenticate the transaction by providing their shared secret key 862 (QKD). This quantum signature can be attached to each transaction, making it difficult to tamper with. Each node checks its entries against its local copy of blockchain 852 to verify that each transaction has sufficient funds. However, the transaction has not yet been confirmed.

[0187] Instead of performing a traditional mining process on a block, a broadcast protocol can be used to create blocks in a decentralized manner. At a predetermined time period (e.g., seconds, minutes, hours, etc.), the network can apply the broadcast protocol to any unconfirmed transactions, thereby achieving Byzantine agreement (consensus) on the correct version of the transaction. For example, each node may have a private value (transaction data for that particular node). In the first round, private values ​​are passed between nodes. In subsequent rounds, nodes communicate the information they received from other nodes in the previous round. Here, honest nodes are able to create a complete set of transactions within a new block. New blocks can be added to blockchain 852. In one embodiment, the features and / or actions described and / or depicted herein can occur on or relative to blockchain 852.

[0188] Fig. 9An example system 900 is shown that supports one or more example embodiments described and / or depicted herein. System 900 includes a computer system / server 902 that can operate with many other general or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that may be suitable for computer system / server 902 include, but are not limited to, personal computer systems, server computer systems, thin clients, fat clients, handheld or portable devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices, and the like.

[0189] Computer system / server 902 may be described in the general context of computer system executable instructions (e.g., program modules) executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform specific tasks or implement specific abstract data types. Computer system / server 902 may be practiced in a distributed cloud computing environment where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in local and remote computer system storage media including memory storage devices.

[0190] like Fig. 9 As shown, a computer system / server 902 in a cloud computing node 900 is shown in the form of a general-purpose computing device. Components of the computer system / server 902 may include, but are not limited to, one or more processors or processing units 904, a system memory 906, and a bus that couples various system components including the system memory 906 to the processor 904.

[0191] Bus refers to any one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example and not limitation, such architectures include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0192] Computer system / server 902 generally includes various computer system readable media. Such media can be any available media accessible to computer system / server 902, and include volatile and non-volatile media, removable and non-removable media. In one embodiment, system memory 906 implements the flow charts of other figures. System memory 906 can include computer system readable media in the form of volatile memory, such as random access memory (RAM) 910 and / or cache memory 912. Computer system / server 902 can further include other removable / non-removable, volatile / non-volatile computer system storage media. As an example only, a storage system 914 can be provided for reading and writing non-removable non-volatile magnetic media (not shown and generally referred to as "hard drive"). Although not shown, a disk drive for reading and writing a removable non-volatile disk (such as a "floppy disk") and an optical disk drive for reading or writing a removable non-volatile optical disk can provide a disk such as a CD-ROM, DVD-ROM or other optical media. In this case, each can be connected to the bus through one or more data media interfaces. As will be further depicted and described below, memory 906 may include at least one program product having a set (eg, at least one) of program modules configured to perform the functions of various embodiments of the present application.

[0193] A program / utility 916 having a set (at least one) of program modules 918 and an operating system, one or more application programs, other program modules, and program data may be stored in the memory 906 by way of example and not limitation. Each of the operating system, one or more application programs, other program modules, and program data, or some combination thereof, may include an implementation of a networking environment. The program modules 918 generally perform the functions and / or methods of various embodiments of the present application as described herein.

[0194] As will be appreciated by those skilled in the art, various aspects of the present application may be embodied as a system, method or computer program product. Therefore, various aspects of the present application may take the following forms: a complete hardware embodiment, a complete software embodiment (including firmware, resident software, microcode, etc.) or an embodiment combining all software and hardware aspects that can be generally mentioned. Referred to herein as "circuit", "module" or "system". In addition, various aspects of the present application may take the form of a computer program product embodied in one or more computer-readable media on which a computer-readable program code is embodied.

[0195] The computer system / server 902 may also communicate with one or more external devices 920, such as a keyboard, a pointing device, a display 922, etc., one or more devices that enable a user to interact with the computer system / server 902, and / or any device that enables the computer system / server 902 to communicate with one or more other computing devices (e.g., a network card, a modem, etc.). Such communication may occur via an I / O interface 924. However, the computer system / server 902 may still communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet) through a network adapter 926. As shown, the network adapter 926 communicates with other components of the computer system / server 902 via a bus. It should be understood that, although not shown, other hardware and / or software components may be used in conjunction with the computer system / server 902. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drives, arrays, RAID systems, tape drives, and data archive storage systems.

[0196] Although exemplary embodiments of at least one of the systems, methods, and non-transitory computer-readable media are shown in the accompanying drawings and described in the foregoing detailed description, it should be understood that the present application is not limited to the disclosed embodiments, but can be rearranged, modified, and replaced as described and defined in the appended claims. For example, the capabilities of the systems of the various drawings can be performed by one or more of the modules or components described herein or in a distributed architecture, and can include a transmitter, a receiver, or both. For example, all or part of the functions performed by each module can be performed by one or more of these modules. In addition, the functions described herein can be performed at various times inside or outside a module or a module or component and in relation to various events. Moreover, the information sent between various modules can be sent between various modules and / or by multiple protocols via at least one of the following: data network, Internet, voice network, Internet protocol network, wireless device, wired device. Moreover, messages sent or received by any module can be sent or received directly and / or via one or more other modules.

[0197] Those skilled in the art will appreciate that a "system" may be embodied as a personal computer, server, console, personal digital assistant (PDA), cell phone, tablet computing device, smart phone, or any other suitable computing device or combination of devices. Presenting the above functions as being performed by a "system" is not intended to limit the scope of the present application in any way, but is intended to provide an example of many embodiments. In fact, the methods, systems, and apparatus disclosed herein may be implemented in local and distributed forms consistent with computing technology.

[0198] It should be noted that some of the system features described in this specification have been presented as modules in order to more specifically emphasize their implementation independence. For example, a module may be implemented as a hardware circuit, including a custom very large scale integrated circuit (VLSI) circuit or gate array, an off-the-shelf semiconductor such as a logic chip, a transistor, or other discrete components. A module may also be implemented in a programmable hardware device such as a field programmable gate array, a programmable array logic, a programmable logic device, a graphics processing unit, etc.

[0199] Modules may also be implemented at least in part in software to be executed by various types of processors. The identified executable code unit may, for example, include one or more physical or logical blocks of computer instructions, which may, for example, be organized as objects, processes, or functions. However, the executable files of the identified modules do not need to be physically located together, but may include different instructions stored in different locations, which, when logically combined together, include the modules and achieve the described purpose of the modules. In addition, modules may be stored on a computer-readable medium, which may be, for example, a hard drive, a flash memory device, a random access memory (RAM), a magnetic tape, or any other such medium for storing data.

[0200] In practice, a module of executable code may be a single or multiple instructions, and may even be distributed across multiple different code segments, between different programs, and across multiple storage devices. Similarly, operational data may be identified and shown herein within a module, and may be embodied in any suitable form and may be organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed across different locations including different storage devices, and may exist, at least in part, only as electronic signals on a system or network.

[0201] It will be easily understood that the components of the present application can be arranged and designed in a variety of different configurations as generally described and shown in the drawings herein. Therefore, the detailed description of the embodiments is not intended to limit the scope of the claimed application, but only represents the selected embodiments of the present application.

[0202] Those skilled in the art will readily appreciate that the above content may be practiced with steps in a different order and / or with hardware elements in a configuration different from that disclosed. Therefore, although the present application has been described based on these preferred embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative constructions will be apparent.

[0203] Although preferred embodiments of the present application have been described, it should be understood that the described embodiments are merely exemplary and that the scope of the present application is limited solely by the appended claims when considering the scope of all equivalents and modifications (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. A system for verifying gradient calculation, comprising: Train a network of participants, including: a plurality of training participant clients, each training participant client comprising a training data set and configured to generate a plurality of gradient computations, each gradient computation corresponding to a training iteration of a machine learning model training using stochastic gradient descent, the machine learning model training comprising a plurality of training iterations; and a training aggregator, coupled to each of the plurality of training participant clients and configured to convert the gradient computation into a plurality of transaction proposals; A blockchain network, including one or more endorser nodes or peers to endorse multiple transaction proposals, Wherein, in a case where the one or more endorser nodes or peers include a verification gradient smart contract, endorsing the plurality of transaction proposals includes: receiving multiple transaction proposals; Execute the validation gradient smart contract for each transaction proposal; and Provide endorsements corresponding to multiple transaction proposals, Wherein, in a case where the one or more endorser nodes or peers do not include a verification gradient smart contract, endorsing the plurality of transaction proposals comprises: The one or more endorser nodes or peers forward the multiple transaction proposals to an independent auditor external to the blockchain network, wherein the independent auditor includes a verification gradient smart contract and is configured to: Receive multiple transaction proposals; Executing a verification gradient smart contract for each of the plurality of transaction proposals; and Providing verification results corresponding to the multiple transaction proposals to endorser nodes or peers.

2. The system according to claim 1, wherein: The VerifyGradient smart contract does not perform gradient calculations, where the VerifyGradient smart contract verifies the results of the gradient calculations from the transaction proposal.

3. The system according to claim 2, wherein: The training aggregator converts the gradient calculation into multiple transaction proposals, including the training aggregator is configured as: receiving gradient computations and metadata from each of a plurality of training participant clients; and Create a separate transaction proposal for each training participant client based on the received metadata.

4. The system according to claim 2, wherein: A transaction proposal specifies a batch from a training dataset, a loss function, current parameter weights, and gradient computations, where a batch includes a subset of samples from the training dataset for a training iteration.

5. The system according to claim 2, wherein: The data and model parameters corresponding to the training dataset are stored outside the blockchain network, whereas the data related to the verification is stored in the blockchain of the blockchain network.

6. The system according to claim 2, wherein: The training aggregator is also configured with: Receiving endorsement; Add endorsements to transactions; Submit the transaction to the blockchain network; Apply the aggregated endorsed gradients to the original machine learning model; and Submit a new transaction proposal with an updated machine learning model.

7. A method for verifying gradient calculation, comprising: Generating gradient calculations for machine learning model training by a plurality of training participant clients, each training participant client including a training data set; The gradient computation is converted into multiple transaction proposals by a training aggregator coupled to multiple training participant clients; One or more endorser nodes or peers of the blockchain network receive the multiple transaction proposals and provide endorsements corresponding to the multiple transaction proposals to the training aggregator, Wherein, in a case where the one or more endorser nodes or peers include a verification gradient smart contract, the one or more endorser nodes or peers providing endorsements corresponding to the plurality of transaction proposals to the training aggregator include: Receive multiple transaction proposals; Execute the validation gradient smart contract for each transaction proposal; and Providing verification results corresponding to multiple transaction proposals, Wherein, in a case where the one or more endorser nodes or peers do not include a verification gradient smart contract, the one or more endorser nodes or peers providing endorsements corresponding to the plurality of transaction proposals to the training aggregator include: The transaction proposal is forwarded by one or more endorser nodes or peers to an independent auditor external to the blockchain network, wherein the independent auditor includes a verification gradient smart contract, wherein the method further comprises: Receive multiple transaction proposals from independent auditors; Execute and verify the gradient smart contract; Providing verification results corresponding to the plurality of transaction proposals by an independent auditor to one or more endorser nodes or peers; and Verification results corresponding to multiple transaction proposals are provided to the training aggregator by one or more endorser nodes or peers.

8. The method according to claim 7, wherein: The VerifyGradient smart contract does not perform gradient calculations, where the VerifyGradient smart contract verifies the results of the gradient calculations from the transaction proposal.

9. The method according to claim 8, wherein: Converting gradient computations into multiple transaction proposals involves: receiving gradient computations and metadata from each of a plurality of training participant clients; and A separate transaction proposal is created for each training participant client based on the received metadata, wherein each of the multiple transaction proposals corresponds to a training iteration for machine learning model training using stochastic gradient descent, and the machine learning model training includes multiple training iterations.

10. The method according to claim 9, wherein: A transaction proposal specifies a batch from a training dataset, a loss function, current parameter weights, and gradient computations, where a batch includes a subset of samples from the training dataset for a training iteration.

11. The method according to claim 9, wherein: The data and model parameters corresponding to the training dataset are stored outside the blockchain network, whereas the data related to the verification is stored in the blockchain of the blockchain network.

12. The method according to claim 9, further comprising: Receiving endorsement; Applying backed gradient calculations to machine learning models; The training aggregator adds endorsement to the transaction; and Submit the transaction to the blockchain network.

13. A computer program product comprising a computer readable medium storing instructions which, when read by a processor, cause the processor to perform the steps of the method according to any one of claims 7 to 12.

14. A device for validating gradient calculations, comprising means for performing the steps of the method according to any one of claims 7 to 12.

Images