Blockchain Network Identity Management using SSI

Abstract

Exemplary operations may include one or more of receiving a request for storage in a blockchain network; attaching a verifiable credential created by a Self-Sovereign Identity (SSI) network, the verifiable credential including a blockchain node's claim and proof of the SSI network that created the verifiable credential, to a blockchain transaction associated with the request via the blockchain node; transmitting the blockchain transaction and the attached verifiable credential to one or more other blockchain nodes; and storing the blockchain transaction and the attached verifiable credential via a data block on the blockchain.

Description

[Background technology]

[0001] A centralized platform stores and maintains data in a single location. This location is often a central computer, such as a cloud computing environment, a web server, or a mainframe computer. Information stored in a centralized platform is typically accessible from multiple different points. Multiple users or client workstations can work simultaneously on the centralized platform, for example, based on a client / server configuration. Due to its single location, a centralized platform is easier to manage, maintain, and control, especially for security purposes. Within a centralized platform, storing all data in a single location also means that there is only one primary record for a given set of data, thereby minimizing data redundancy. Summary of the Invention

[0002] One exemplary embodiment provides an apparatus comprising: a network interface configured to receive a request for storage on a blockchain; and a processor configured to attach a verifiable credential created by a Self-Sovereign Identity (SSI) network via the blockchain node to a blockchain transaction associated with the request, the verifiable credential including a claim of a blockchain node and proof of the SSI network that created the verifiable credential, and to store the blockchain transaction and the attached verifiable credential via a data block on the blockchain, wherein the processor is further configured to control the network interface to transmit the blockchain transaction and the attached verifiable credential to one or more other blockchain nodes.

[0003] Another exemplary embodiment provides a method that includes one or more of receiving a request for storage on a blockchain; attaching a verifiable credential created by a Self-Sovereign Identity (SSI) network via the blockchain node to a blockchain transaction associated with the request, the verifiable credential including a claim of a blockchain node and proof of the SSI network that created the verifiable credential; transmitting the blockchain transaction and the attached verifiable credential to one or more other blockchain nodes; and storing the blockchain transaction and the attached verifiable credential via a data block on the blockchain.

[0004] A further exemplary 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 steps: receive a request for storage on a blockchain; attach a verifiable credential created by a Self-Sovereign Identity (SSI) network via the blockchain node to a blockchain transaction associated with the request, the verifiable credential including a claim of a blockchain node and proof of the SSI network that created the verifiable credential; transmit the blockchain transaction and the attached verifiable credential to one or more other blockchain nodes; and store the blockchain transaction and the attached verifiable credential via a data block on the blockchain. [Brief explanation of the drawings]

[0005] [Figure 1A] FIG. 1 illustrates a blockchain network using self-sovereign identity (SSI), according to an example embodiment.

[0006] [Figure 1B] FIG. 1 illustrates a verifiable credential according to an example embodiment.

[0007] [Figure 1C] FIG. 10 illustrates further details of a verifiable credential according to an example embodiment.

[0008] [Figure 2A] FIG. 1 illustrates an exemplary blockchain architecture configuration according to an exemplary embodiment.

[0009] [Figure 2B] FIG. 1 illustrates a blockchain transaction flow between nodes, according to an example embodiment.

[0010] [Figure 3A] FIG. 1 illustrates a permissioned network in accordance with an example embodiment.

[0011] [Figure 3B] FIG. 1 illustrates another permissioned network in accordance with an example embodiment.

[0012] [Figure 3C] FIG. 1 illustrates a permissionless network in accordance with an exemplary embodiment.

[0013] [Figure 4] FIG. 1 illustrates a process for issuing verifiable credentials according to an example embodiment.

[0014] [Figure 5] FIG. 1 illustrates a method for performing a blockchain transaction using verifiable credentials, according to an example embodiment.

[0015] [Figure 6A]FIG. 1 illustrates an example system configured to perform one or more operations described herein, according to an example embodiment.

[0016] [Figure 6B] FIG. 1 illustrates another exemplary system configured to perform one or more operations described herein, in accordance with an exemplary embodiment.

[0017] [Figure 6C] FIG. 1 illustrates a further exemplary system configured to utilize smart contracts, according to an exemplary embodiment.

[0018] [Figure 6D] FIG. 1 illustrates yet another exemplary system configured to utilize blockchain, according to an exemplary embodiment.

[0019] [Figure 7A] FIG. 1 illustrates the processing of a new block being added to a distributed ledger, according to an example embodiment.

[0020] [Figure 7B] FIG. 10 illustrates the data content of a new data block according to an exemplary embodiment.

[0021] [Figure 7C] FIG. 1 illustrates a blockchain of digital content, according to an exemplary embodiment.

[0022] [Figure 7D] FIG. 1 illustrates a block diagram that may represent the structure of a block in a blockchain, according to an example embodiment.

[0023] [Figure 8A] FIG. 1 illustrates an exemplary blockchain for storing machine learning (artificial intelligence) data, according to an exemplary embodiment.

[0024] [Figure 8B] FIG. 1 illustrates an exemplary quantum secure blockchain, according to an exemplary embodiment.

[0025] [Figure 9] FIG. 1 illustrates an example system that supports one or more of the example embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0026] It will be readily understood that the components, as generally described and illustrated herein, could be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of at least one embodiment of a method, apparatus, non-transitory computer-readable medium, and system, as illustrated in the accompanying drawings, is not intended to limit the scope of the present application as claimed, but rather represents selected embodiments.

[0027] The features, structures, or characteristics described throughout this specification may be combined or eliminated in any suitable manner in one or more embodiments. For example, throughout this specification, the use of the phrase “exemplary embodiment,” “some embodiments,” or other similar language indicates that particular features, structures, or characteristics described in connection with an embodiment may be included in at least one embodiment. Thus, throughout this specification, the appearances of the phrase “exemplary embodiment,” “some embodiments,” “other embodiments,” or other similar language do not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics may be combined or eliminated in any suitable manner in one or more embodiments. Furthermore, in the figures, any connection between elements may enable one-way and / or two-way communication, even if the connection is shown with a one-way or two-way arrow. Any devices shown in the figures may be different devices. For example, where a mobile device is shown transmitting information, a wired device may also be used to transmit the information.

[0028] Additionally, while the term "message" may be used in describing the embodiments, the present application may apply to many types of networks and data. Furthermore, while particular types of connections, messages, and signaling may be shown in the exemplary embodiments, the present application is not limited to the particular types of connections, messages, and signaling.

[0029] Exemplary embodiments provide methods, systems, components, non-transitory computer-readable media, devices and / or networks related to managing blockchain network identities via a Self-Sovereign Identity (SSI) network.

[0030] According to various embodiments, each blockchain entity (e.g., peer, orderer, endorser, client, auditor, admin, etc.) may be assigned a unique decentralized identifier (DID) that identifies the blockchain entity within a blockchain network. A blockchain entity with a DID may be issued one or more verifiable credentials (VCs) that can be used by the blockchain entity to sign blockchain transactions, messages, blocks, etc. In some embodiments, each blockchain entity may include a set of VCs, each granting one or more claims to the blockchain entity. A claim may be, for example, a claim that a blockchain peer is authorized to sign transactions for a particular smart contract (chaincode). As another example, a claim may be that a blockchain peer is authorized to transact on a particular channel / blockchain among multiple channels of a blockchain ledger. As another example, a claim may be the identity of a blockchain peer as an endorsing peer of a blockchain network, etc.

[0031] Each verifiable credential may be issued by an authority within the blockchain network's SSI network, such as a membership service provider (MSP) or a certificate authority (CA). The verifiable credential may include a "proof," such as the signature of the issuer of the verifiable credential. The SSI network may maintain all assigned DIDs and VCs. In addition, the SSI network may maintain the schema information and public key of the issuer who signed the public key of each VC. Members of the blockchain can access the registry and obtain the schema information and the issuer's public key to verify the verifiable credential's schema and issuer's signature, respectively. In this way, any blockchain entity can confirm the validity of a verifiable credential without relying on a central authority.

[0032] In one embodiment, the present application utilizes a decentralized database (e.g., a blockchain), which is a distributed storage system that includes multiple nodes communicating with each other. A decentralized database includes an append-only immutable data structure, similar to a distributed ledger, that can maintain records among mutually untrusted parties. The untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database record, and no single peer can modify the database record unless consensus is reached among the distributed peers. For example, peers may execute a consensus protocol to validate blockchain storage transactions, group the storage transactions into blocks, and build a hash chain across the blocks. This process forms a ledger by ordering the storage transactions as necessary to ensure consistency. In various embodiments, permissioned and / or permissionless blockchains can be used. In public or permissionless blockchains, anyone can participate without specific identity. Public blockchains may involve native cryptocurrencies and may use consensus based on various protocols, such as Proof of Work (PoW). Permissioned blockchain databases, on the other hand, provide secure interactions between groups of entities that share a common purpose but do not fully trust each other, such as businesses exchanging funds, goods, and information.

[0033] This application can utilize a blockchain tailored to a decentralized storage scheme and running arbitrary programmable logic, referred to as a "smart contract" or "chaincode." In some cases, there can be specialized chaincode for managing functions and parameters, referred to as a system chaincode. This application can also utilize smart contracts, which are trusted distributed applications that leverage the tamper-resistant properties of the blockchain database and an underlying agreement between nodes, referred to as an endorsement or endorsement policy. Blockchain transactions associated with this application can be "endorsed" before being committed to the blockchain, while unendorsed transactions are ignored. An endorsement policy allows the chaincode to specify endorsers for a transaction in the form of a set of peer nodes required for endorsement. When a client sends a transaction to a peer specified in the endorsement policy, the transaction is executed and the transaction is validated. 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.

[0034] This application may utilize nodes, which are communication entities in a blockchain system. A "node" may perform a logical function, in the sense that multiple nodes of different types may run on the same physical server. Nodes are grouped into trust domains and associated with logical entities that control them in various ways. Nodes may include different types, such as client or submitting client nodes that submit transaction calls to endorsers (e.g., peers) and broadcast transaction proposals to an ordering service (e.g., ordering node). Another type of node is a peer node that can receive client-submitted transactions, commit transactions, and maintain the ledger state and copy of blockchain transactions. Peers may also have the role of endorser, but this is not a requirement. An ordering service node, or orderer, is a node that performs communication services for all nodes and implements delivery guarantees, such as broadcasting to each of the peer nodes in the system, when committing transactions and modifying the blockchain world state, which is another name for the initial blockchain transaction, which typically contains control and setup information.

[0035] This application utilizes a ledger, which is a sequenced, tamper-resistant record of all state transitions of a blockchain. State transitions can result from chaincode invocations (i.e., transactions) submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Each participating party (e.g., peer node) can maintain a copy of the ledger. Transactions can result in a set of asset key-value pairs being committed to the ledger as one or more operands, e.g., create, update, and delete. The ledger includes a blockchain (also referred to as a chain) that is used to store immutable, sequenced records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0036] The present application utilizes a chain, which is a transaction log structured as hash-linked blocks, where each block contains a sequence of N transactions, where N is equal to or greater than 1. The block header contains a hash of the block's transactions and a hash of the previous block's header. In this way, all transactions on the ledger can be sequenced and cryptographically linked together. Therefore, it is impossible to tamper with the ledger data without breaking the hash links. The hash of the most recently added blockchain block represents all transactions on the chain that occurred before it, allowing all peer nodes to ensure a consistent and reliable state. The chain can be stored on the peer node file system (i.e., local, attached storage, cloud, etc.), efficiently supporting the append-only nature of blockchain workloads.

[0037] The current state of the immutable ledger represents the most recent values of all keys contained in the chain transaction log. Because the current state represents the most recent key values known to the channel, it is sometimes referred to as the world state. Chaincode invocations perform transactions against the ledger's current state data. To make these chaincode interactions efficient, the most recent values of keys may be stored in a state database. The state database may simply be an indexed view into the chain's transaction log and therefore can be regenerated from the chain at any time. The state database may be automatically recovered (or generated if necessary) at peer node startup, before any transactions are accepted.

[0038] Some of the benefits of a blockchain network using SSI membership and identity include privacy, security, and portability (or interoperability). For example, with SSI, network participants can use decentralized identifiers (DIDs) in specific contexts with a desired level of exposure. For example, when a blockchain peer signs a transaction for inclusion in a block, it uses only the credentials (or a portion of the credentials) issued to it for the purpose of signing transactions within that network. This peer's DID may include various other attributes and affiliations (e.g., the peer may belong to an organization that participates in multiple business networks), but none of that information is made public in the transaction cycle. A validating peer simply checks the verifiable presentation (VP) of the verifiable credentials, as does an auditor (after a few days).

[0039] Furthermore, security may be enhanced in cross-network interactions, for example, when assets or data items are shared between permissioned ledgers. Participants (blockchain peers) with SSIs (e.g., DIDs and VCs) can authenticate themselves and prove their identity to external parties (which can freely choose their policies), such as centralized entities or participants in different business networks, using a simple process by relying on the SSI network, which acts as a VC / VP and DID identity and storage provider. Furthermore, portability and interoperability may be improved. Permissioned networks today have their own proprietary identity management systems (for issuing and storing credentials), which are invisible to parties outside the network. By using SSIs instead of these disparate and opaque identity management systems, exemplary embodiments may enable data and assets to flow across network boundaries (in a policy-controlled manner) by ensuring that network participants are recognized and can prove their authenticity outside the network. Furthermore, SSI networks may be built around well-known identity providers or credential authorities that have no affiliation with any particular network. This allows for portability of identities and credentials across network interactions.

[0040] In an exemplary embodiment, verifiable credentials can be issued to DID holders (network participants relying on SSIs). Verifiable credentials can be issued by issuers (members of the SSI network), which can be existing identity providers and certificate authorities within the permissioned network or well-known external authorities. Within the network, issuers can include network or organizational (subdivision) CAs. In a Hyperledger Fabric network, these entities are called MSPs (Membership Service Providers) and maintain a chain of root and intermediate CAs. In the Corda network, there is a hierarchy of network CAs that certify doormen CAs, which are in turn credential node CAs (each node has the ability to sign and approve transactions). These MSPs or CAs represent either the entire network or subdivisions within the network and issue / revoke identities and credentials (e.g., DIDs). Outside the network, issuers can include external parties, such as well-known CAs and certificate authorities like Verisign or DMV. Other issuers may include existing organizations that have chosen to participate in the permissioned network, ad hoc authorities representing consortia of organizations including business networks, e.g., supply chains, food trust networks, etc. It should also be appreciated that the SSI network can manage identities for participants in multiple networks and facilitate the sharing of identities across network boundaries.

[0041] In an exemplary embodiment, participants in an SSI network, such as blockchain peers or clients, may be issued a DID. A DID may be a unique identifier, such as a URI, that identifies a blockchain entity. For example, a DID enables verifiable, decentralized digital identity. A DID identifies any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) that the controller of the DID decides to identify. In contrast to typical federated identifiers, DIDs are designed to be decoupled from centralized registries, identity providers, and certificate authorities. Specifically, while other parties may be used to help enable discovery of information related to a DID, this design allows the controller of a DID to prove its control without requiring permission from any other party. A DID is a URI that associates a DID subject with a DID document that enables trusted interactions associated with that subject.

[0042] Each DID document may represent cryptographic material, verification methods, or services that provide a set of mechanisms that allow a DID controller to prove control of a DID. Services enable trusted interactions associated with a DID subject. If a DID subject is an information resource such as a data model, a DID document may contain the DID subject itself. This document may specify a common data model, URL format, and a set of behaviors for DIDs, DID documents, and DID methods. A DID is a simple string consisting of three parts, including a URI scheme identifier (DID), a DID method identifier, and a DID method unique identifier. A DID can be decomposed into DID documents. DID URLs extend the basic DID syntax to incorporate other standard URI components (path, query, fragment) to locate specific resources, such as public keys inside a DID document or resources available outside a DID document.

[0043] A DID document contains information associated with a DID and typically represents verification methods (such as a public key) and services related to interactions with the DID subject. DID documents may be serialized according to a specific syntax. The DID itself is the value of an identity property. Properties present in a DID document may be updated. A DID method is the mechanism by which a specific type of DID and its associated DID documents are created, resolved, updated, and deactivated using a specific verifiable data registry. DID methods are defined using a separate DID method specification. In an exemplary embodiment, DIDs, VCs, VPs, etc. may be stored in a blockchain ledger that includes a verifiable data registry.

[0044] The owner of a DID may be issued a VC by a credential provider (e.g., the DMV that issues driver's licenses, a university that issues transcripts, etc.) that establishes some characteristics of the owner. In an exemplary embodiment, the verifiable credential may establish characteristics of the blockchain entity that holds the credential, such as that the blockchain entity is an endorser, that the blockchain entity is authorized to transact on a particular ledger, that the blockchain entity is authorized to execute / invoke a particular chaincode, etc. This binding is made secure and tamper-proof using a digital signature that may be recorded within the VC. Overall, DIDs have a longer lifespan than VCs (which have expiration times). Any network component, such as a blockchain peer, orderer, endorser, or client, obtains a DID when it begins operation. Participants can then request and obtain VC from a certificate authority, including an SSI network. Each VC may serve a different (and limited) purpose, such as signing transactions for inclusion in blocks or signing asset states traded with different networks. How VC can be used (using VP or verifiable presentation) may depend on policy; for example, a transaction commitment policy may require signing peers to prove membership within an organization that is part of the network.

[0045] The verifiable credential and the verifiable presentation may be serializable in one or more machine-readable data formats, such as comma separated value (CSV) files, Extensible Markup Language (XML) files, and JavaScript Object Notation (JSON) files. The serialization and / or deserialization process may be deterministic, bidirectional, and lossless. Any serialization of the verifiable credential or the verifiable presentation may be convertible to a common data model in a deterministic manner so that the resulting verifiable credential can be processed in an interoperable manner. The serialized form may also be reproducible from the data model without loss of data or content. Furthermore, the verifiable presentation (VP) may disclose attributes of the verifiable credential or satisfy a derived predicate required by a verifier. The derived predicate may be a Boolean condition, such as greater than, less than, equal to, or in a set.

[0046] In an exemplary embodiment, DIDs can be guaranteed to be unique only within the domain (or more typically, registry) of the DID provider, not globally. If a permissioned network or group of permissioned networks decides to trust a single DID registry, then peers in that setup will have unique DIDs. Otherwise, a peer's DID will be unique within the tuple<DID Registry,DID> can be solved globally and uniquely by

[0047] An SSI network includes a DID registry that maintains records indexed by DID value. In addition, the SSI network can maintain the schema (structure) and validation keys for VC (Hyperledger Indy is an example of such a DID registry built on the SSI concept). VC can be partially validated by matching the schema to one stored in the SSI network registry and by validating the digital signature of the issuer issuing the VC using a public key stored in the registry (storage can be, but is not required to be, on the distributed ledger itself). However, trust in claims about the properties of the DID owner in the VC, once validated, depends only on whether the validator trusts the VC issuer.

[0048] In an exemplary embodiment, the VC itself is not stored in the SSI network's DID registry, but rather is issued through peer-to-peer communication from the issuer to the owner / holder and stored by the owner / holder. For VC validation and authentication, a verifier receiving the VC can use the DID as a unique identifier to identify the schema and public key stored in the VC's DID registry (blockchain). The timestamp, which is a property of the VC, is not itself stored in the registry. However, what is recorded in the ledger registry is the fact of VC issuance (or VC issuance event). Such an event carries an automatic timestamp that can be used for later validation and auditing. Several variations on how the SSI network can be configured are possible. In one example, the internal configuration includes an SSI network overlapping with existing identity issuers in different networks, such as a blockchain network with certificate authorities, MSPs, etc. As another example, the SSI network can be a network that is completely separate / external from the blockchain network but loosely coupled with existing identity issuers in different networks.

[0049] FIG. 1A illustrates a blockchain network 100 using self-sovereign identity (SSI) according to an example embodiment. Referring to FIG. 1A, the blockchain network 100 includes multiple blockchain peers 110, 120, 130, and 140 that manage a blockchain ledger 150, an ordering node 150, and a client 102. As further described with respect to the example of FIG. 4, when the client 102, the blockchain peers 110-140, and the ordering node 150 register for membership in the blockchain network 100 (e.g., via a certificate authority, a membership service provider, etc.), the client 102, the blockchain peers 110-140, and the ordering node 150 may receive one or more verifiable credentials. For example, the client 102 may receive VC 104, the blockchain peers 110, 120, 130, and 140 may receive VCs 112, 112, 132, and 142, respectively, and the ordering node 152 may receive VC 152.

[0050] While only one VC is shown in this example, it should be understood that one or more of the blockchain entities shown in FIG. 1A may receive multiple VCs, and that such VCs may have different lifespans, different usages, different creation times, etc. For example, a blockchain peer 110-140 may receive a different / separate VC for each chaincode it has and can execute / invoke. As another example, each of the blockchain peers 110-140 may receive a different / separate VC for each ledger / channel on a ledger to which it has access and which is stored therein.

[0051] A VC may serve as a credential for each blockchain entity, indicating that the blockchain entity is authorized to perform the action it is currently performing. For example, in FIG. 1A , client 102 sends a transaction to blockchain peer 110. Here, VC 104 of client 102 may identify client 102 as a member / client of blockchain 105. VC 104 may be signed by the issuer of VC 104, such as a CA or MSP. As another example, VCs 112, 122, 132, and 142 of blockchain peers 110, 120, 130, and 140 may identify blockchain peers 110-140 as members of blockchain 105 and as having storage rights / chaincode execution capabilities in blockchain 105. Meanwhile, VC 152 of ordering node 150 may identify ordering node 150 as the orderer of blocks stored in blockchain 150. Each of the blockchain entities (clients 102, blockchain peers 110-140, and ordering node 150) may attach a respective VC to messages, transactions, proposals, requests, etc. transmitted within network 100, and to external entities (not shown).

[0052] 1B illustrates basic components of a verifiable credential 112 of a blockchain peer 110 according to an example embodiment. Referring to FIG. 1B, the verifiable credential 112 may include a digitally formatted, machine-readable file, code, document, etc., including credential metadata 160, one or more claims 170, and one or more proofs 180 associated with the one or more claims 170. The verifiable credential may include identifiers for the subject / holder, such as the subject / holder's DID, information related to the issuing authority (e.g., CA, MSP, etc.), information about the type of credential, information about specific attributes of the credential, information related to how the credential was derived, and information related to constraints on the credential (e.g., terms of use, expiration, etc.). The verifiable credential may represent the same information as a physical credential, except in a machine-readable format (e.g., JSON, XML, CSV, etc.) rather than a human-readable format.

[0053] One example of a claim 170 included in a verifiable credential is a blockchain peer claiming to be a member of a blockchain network and to have the ability to store data on the blockchain of the blockchain network. Another type of claim 170 is a blockchain peer claiming to have access to a particular chaincode and to be able to execute transactions from a client based on such chaincode. Another type of claim 170 is a blockchain peer claiming to be a member / participant of a particular channel, such as a blockchain ledger. There are many other claims that can be made with a verifiable credential, and each blockchain entity may hold multiple VCs. Additionally, a VC may be updated to add new claims, modify claims, delete claims, etc., and may be executed by the issuing entity.

[0054] Metadata 160 may include data describing characteristics of verifiable credential 112, such as the issuer, the schema of the verifiable credential (e.g., JSON, XML, CSV, etc.), expiration date / time, an image of the credential, the identifier of the public key used for verification, a revocation mechanism, etc. Attestation 180 may include the issuer's digital signature, which allows tampering of the credential to be detected, along with the date / time of this signature, the purpose of the attestation, the identifier of the public key to verify this signature, etc.

[0055] FIG. 1C further details claims 170 and proof 180 of verifiable credential 112 according to an example embodiment. While FIG. 1B illustrates the basic components of verifiable credential 112, FIG. 1C illustrates a schema for how verifiable credential 112 stores data internally. In particular, claims 170 (and metadata 160) and proof 180 may be stored as separate information graphs. In this example, the first information graph includes a credential ID node 171 interconnected to a DID node 172 (the holder's DID), an issuer ID node 173 (of the MSP that issued VC 112), a credential type 174 (e.g., blockchain peer VC, ordering node VC, client VC, ledger VC, chaincode VC, etc., the identity of the credential), and a timestamp node 175 containing the time / date VC 112 was created. The second information graph includes a signature ID node 181 containing the signature of the issuer of the verifiable credential 112, a signature value node 182 containing the signature content, an creator node 183 identifying the public key, a timestamp node 184 indicating when the signature was added, and a signature type node 185 identifying the type of digital signature (e.g., RSA, AES, etc.).

[0056] FIG. 2A illustrates a blockchain architecture configuration 200 according to an example embodiment. Referring to FIG. 2A, the blockchain architecture 200 may include a particular blockchain element, e.g., a group 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 multiple activities, such as the blockchain transaction addition and validation process (consensus). One or more of the blockchain nodes 204-210 may endorse transactions based on an endorsement policy and may provide an ordering service to all blockchain nodes in the architecture 200. A blockchain node may initiate blockchain validation and attempt to write to a blockchain immutable ledger stored in the blockchain layer 216, a copy of which may be stored in the underlying physical infrastructure 214. A blockchain configuration may include one or more applications 224 linked to an application programming interface (API) 222 for accessing and executing stored program / application code 220 (e.g., chaincode, smart contracts, etc.), which can be created according to customized configurations desired by participants, maintain their own state, control their own assets, and receive external information, which can be deployed as transactions and installed on all blockchain nodes 204-210 via additions to the distributed ledger.

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

[0058] The blockchain architecture configuration of FIG. 2A may process and execute program / application code 220 through one or more interfaces and services exposed by the blockchain platform 212. The code 220 may control blockchain assets. For example, the code 220 may store and transfer data and may be executed by the nodes 204-210 in the form of smart contracts and associated chaincode with conditions or other code elements subject to execution. As a non-limiting example, smart contracts may be created to implement reminders, updates, and / or other notifications subject to changes, updates, etc. The smart contract itself may be used to identify permission and access requirements and rules associated with ledger usage. For example, smart contracts (or chaincodes executing the smart contract logic) may read blockchain data 226, which may be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 216, to generate results 228, including alerts, responsibility determinations, etc., within complex service scenarios. The physical infrastructure 214 may be utilized to obtain any of the data or information described herein.

[0059] Smart contracts may be created via high-level application and programming languages and then written into blocks within a blockchain. Smart contracts may include executable code that is registered, stored, and / or replicated on a blockchain (e.g., a decentralized network of blockchain peers). A transaction is an execution of smart contract logic that may be executed in response to a condition associated with a smart contract being satisfied. Execution of a smart contract may trigger trusted modifications to the state of a digital blockchain ledger. Modifications to the blockchain ledger caused by smart contract execution may be automatically replicated across the decentralized network of blockchain peers through one or more consensus protocols.

[0060] Smart contracts may write data to the blockchain in the format of key-value pairs. Additionally, smart contract code can read values stored on the blockchain and use them in application operations. Smart contract code can write the output of various logical operations into one or more blocks in the blockchain. The code can be used to create temporary data structures in a virtual machine or other computing platform. Data written to the blockchain can be public and / or kept private by encryption. The temporary data used / generated by the smart contract is kept in memory by the provided execution environment and then deleted once the data needed for the blockchain has been identified.

[0061] Chaincode may include a code interpretation (e.g., logic) of a smart contract. For example, chaincode may include a packaged, deployable version of the logic in a smart contract. As described herein, chaincode may be program code deployed on a computing network and executed and validated by a chain validator together during the consensus process. The chaincode may receive a hash and retrieve a hash from the blockchain associated with a data template created using a previously stored feature extractor. If the hash of the hash identifier and the hash created from the stored identifier template data match, the chaincode sends an authorization key to the requested service. The chaincode may be written to the blockchain data associated with cryptographic details.

[0062] FIG. 2B illustrates an example of a blockchain transaction flow 250 between nodes of a blockchain, according to an example embodiment. Referring to FIG. 2B, the transaction flow may include a client node 260 transmitting a transaction proposal 291 to an endorsing peer node 281. The endorsing peer 281 may verify the client signature and execute a chaincode function to initiate the transaction. The output may include the chaincode result, a set of key / value versions read in the chaincode (the read set), and a set of keys / values written to the chaincode (the write set). The endorsing peer 281 may then decide whether to endorse the transaction proposal. If approved, a proposal response 292 is sent back to the client 260 along with an 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 distributes the ordered transactions as a block to all peers 281-283 on the channel. Before committing it to the blockchain, each peer 281-283 may verify the validity of the transaction. For example, a peer may check an endorsement policy to ensure that the correct allocation of designated peers has signed the result and authenticated the signature on the transaction payload 293.

[0063] Referring again to FIG. 2B, a client node initiates a transaction 291 by constructing and sending a request to an endorser peer node 281. The client 260 may include an application that utilizes a supported software development kit (SDK) that utilizes available APIs to generate a transaction proposal. The proposal is a request to invoke chaincode functions so that data can be read from and / or written to the ledger (i.e., write a new key-value pair for an asset). The SDK may package the transaction proposal into an appropriately designed format (e.g., protocol buffers for remote procedure calls (RPCs)) and act as a shim to obtain the client's cryptographic credentials to generate a unique signature for the transaction proposal.

[0064] In response, the endorsing peer node 281 may verify that (a) the transaction proposal is well-formed, (b) the transaction has not already been submitted previously (replay attack protection), the signature is valid, and (d) the submitter (in this example, client 260) is properly authorized to perform the proposed operation on that channel. The endorsing peer node 281 may take the transaction proposal input as an argument to a chaincode function that is invoked. The chaincode is then executed against the current state database to generate a transaction result that includes a response value, a read set, and a write set. However, the ledger has not yet been updated. At 292, the set of values, along with the endorsing peer node 281's signature, is returned as a proposal response 292 to the client 260's SDK, which parses the payload for the application to consume.

[0065] In response, the application on the client 260 checks / verifies the signatures of the endorsing peers and compares their proposal responses to determine whether they are the same. If the chaincode only queried the ledger, the application checks the query response and typically does not submit the transaction to the ordering node service 284. If the client application intends to submit a transaction to the ordering node service 284 to update the ledger, the application determines whether the specified endorsement policy has been satisfied (i.e., whether all required peer nodes for the transaction have endorsed the transaction) before submitting. Here, the client may include only one of multiple parties to the transaction. In this case, each client may have its own endorsing node, and each endorsing node must endorse the transaction. This architecture ensures that even if the application chooses not to check the response or otherwise forwards an unendorsed transaction, the endorsement policy is still enforced by the peers and maintained in the commit validation phase.

[0066] After successful validation, in step 293, client 260 assembles the endorsements into a transaction proposal and broadcasts the transaction proposal and response in a transaction message to ordering node 284. The transaction may include a read / write set, an endorsed peer signature, and a channel ID. Ordering node 284 does not need to validate the entire contents of a transaction to perform its action; instead, ordering node 284 may simply receive transactions from all channels in the network, order them chronologically by channel, and create blocks of transactions per channel.

[0067] The block is distributed from the ordering node 284 to all peer nodes 281-283 on the channel. The validity of the data section in the block may be checked to ensure that endorsement policies are met and that the ledger state of the readset variable has not changed since the readset was generated by the transaction execution. Furthermore, in step 295, each peer node 281-283 adds the block to the channel's chain, and for each valid transaction, the writeset is committed to the current state database. Events may be emitted to notify client applications that a transaction (invocation) has been immutably added to the chain and whether the transaction has been validated or invalidated.

[0068] In the example of FIG. 2B, client node 260 and each of blockchain peers 281-284 may use verifiable credentials as signatures. As the transaction progresses through the different stages of FIG. 2B, client node 260 and each of blockchain peers 281-284 may attach respective VCs to the stages they have executed. In this example, each of blockchain peers 281-284 may include a set of VCs (e.g., one or more VCs) that provide identity and membership information associated with blockchain peers 281-284. For example, client node 260 may include a verifiable certificate with claims issued by an MSP of the blockchain network that identifies the client as a member for transacting on the blockchain. As another example, blockchain peers 281-283 may include a VC that identifies blockchain peers 281-283 as endorsing peers of the blockchain. Meanwhile, blockchain peer 284 may include a VC that identifies blockchain peer 284 as an ordering node of the blockchain. Many other VCs are possible. For example, particular channels on a blockchain (e.g., different blockchains on the same ledger) may require different VCs to act as clients, peers, endorsers, orderers, etc. As another example, different types of transactions and / or chaincodes may require separate VCs by clients, peers, etc. For example, if a client has a VC that identifies the client as authorized to use a particular chaincode, it may invoke such chaincode simply by submitting a transaction.

[0069] FIG. 3A illustrates an example of a permissioned blockchain network 300 featuring a distributed, decentralized, peer-to-peer architecture. In this example, blockchain users 302 may initiate transactions against a permissioned blockchain 304. In this example, transactions may be deployed, invoked, or queried, and may be issued directly, such as through an API, or through a client-side application leveraging an SDK. The network may provide access to regulators 306, such as auditors. A blockchain network operator 308 manages member permissions, such as registering regulators 306 as "auditors" and blockchain users 302 as "clients." Auditors may be limited to only querying the ledger, while clients may be allowed to deploy, invoke, and query certain types of chaincode.

[0070] A blockchain developer 310 can write chaincode and client-side applications. The blockchain developer 310 can deploy the chaincode directly to the network through an interface. To include credentials from traditional data sources 312 in the chaincode, the developer 310 can access the data using an out-of-band connection. In this example, a blockchain user 302 connects to the permissioned blockchain 304 through a peer node 314. Before proceeding with any transaction, the peer node 314 obtains the user's registration certificate and transaction certificate from a certificate authority 316, which manages user roles and permissions. In some cases, a blockchain user must possess these digital certificates to transact on the permissioned blockchain 304. Meanwhile, a user attempting to use the chaincode may need to verify their credentials on the traditional data source 312. To verify the user's authorization, the chaincode can use an out-of-band connection to this data through a traditional processing platform 318.

[0071] 3B illustrates another example of a permissioned blockchain network 320 featuring a distributed, decentralized, peer-to-peer architecture. In this example, blockchain users 322 may submit transactions to a permissioned blockchain 324. In this example, transactions may be deployed, invoked, or queried and may be issued through client-side applications leveraging SDKs, directly through APIs, etc. The network may provide access to regulators 326, such as auditors. A blockchain network operator 328 manages member permissions, such as registering regulators 326 as "auditors" and blockchain users 322 as "clients." Auditors may be limited to only querying the ledger, while clients may be allowed to deploy, invoke, and query certain types of chaincode.

[0072] A blockchain developer 330 may write chaincode and client-side applications. The blockchain developer 330 can deploy the chaincode directly to the network through an interface. To include credentials from a traditional data source 332 in the chaincode, the developer 330 may access the data using an out-of-band connection. In this example, a blockchain user 322 connects to the network through a peer node 334. Before proceeding with any transaction, the peer node 334 obtains the user's registration and transaction certificate from a certificate authority 336. In some cases, a blockchain user must possess these digital certificates to transact on the permissioned blockchain 324. Meanwhile, a user attempting to use the chaincode may need to verify their credentials on the traditional data source 332. To verify the user's authorization, the chaincode can use an out-of-band connection to this data through a traditional processing platform 338.

[0073] In some embodiments, the blockchain herein may be a permissionless blockchain. In contrast to a permissioned blockchain, which requires permission to participate, anyone can participate in a permissionless blockchain. For example, to participate in a permissionless blockchain, a user may create a personal address and begin interacting with the network by submitting transactions to add entries to the ledger. Additionally, all parties may choose to run a node on the system and use a mining protocol to help validate transactions.

[0074] 3C illustrates a transaction process 350 processed by a permissionless blockchain 352 including multiple nodes 354. A sender 356 desires to send a payment or some other form of value (e.g., a certificate, medical records, a contract, goods, services, or any other asset that can be encapsulated in a digital record) to a recipient 358 via the permissionless blockchain 352. In one embodiment, the sender device 356 and the recipient device 358 may each have a digital wallet (associated with the blockchain 352) that provides user interface controls and a display of transaction parameters. In response, the transaction is broadcast to nodes 354 throughout the blockchain 352. Depending on the network parameters of the blockchain 352, the nodes validate 360 the transaction based on rules (which may be predefined or dynamically assigned) established by the creator of the permissionless blockchain 352. For example, this may include verifying the identities of the parties involved, etc. The transaction may be validated immediately or may be queued with other transactions, and node 354 determines whether the transaction is valid based on a set of network rules.

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

[0076] Before a block can be added to the blockchain, the block's validity must be verified. Validation in a permissionless blockchain 352 can involve proof of work (PoW), which is the solution to a puzzle derived from the block's header. Another process for verifying block validity, not shown in the example of Figure 3C, is proof of stake. Unlike proof of work, where an algorithm rewards miners for solving a mathematical problem, in proof of stake, the creator of a new block is selected in a deterministic manner according to their wealth, also defined as "stake." Similar proofs are then performed by the selected / elected nodes.

[0077] In mining 364, nodes attempt to solve a block by making incremental changes to one variable until the solution meets a network-wide target. This creates a proof of work, which guarantees a correct answer. In other words, potential solutions must prove that they have exhausted the computing resources required to solve the problem. In some types of permissionless blockchains, miners may receive a reward of value (e.g., coins) for successfully mining a block.

[0078] Here, the PoW process chains blocks together, making it extremely difficult for an attacker to modify the blockchain by requiring an attacker to 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 the block increases, and the number of subsequent blocks increases. In distribution 366, successfully validated blocks are distributed throughout the permissionless blockchain 352, and all nodes 354 add the block to the majority chain, which is an auditable ledger of the permissionless blockchain 352. Furthermore, the value of the transaction submitted by the sender 356 is deposited or otherwise transferred to the digital wallet of the recipient device 358.

[0079] FIG. 4 illustrates a process 400 for issuing verifiable credentials according to an example embodiment. Referring to FIG. 4 , multiple organizations 420 share a blockchain ledger 430 (e.g., one or more blockchain state databases, etc.). Each organization 420 may have one or more peers 422 that execute transactions on the blockchain of the blockchain ledger 430 shared among the multiple organizations 420. According to various embodiments, the multiple organizations 420 may interact with an SSI network 410, which may be an internal or external network related to the blockchain ledger 430. The SSI network 410 may include multiple identity providers 412 (trusted sources), such as CAs, MSPs, admins, and other trusted entities. The identity providers 412 may provide DIDs and VCs to the peer organizations' 420 peers 422. The VCs and DIDs may be stored in the SSI network's registry 414. In some embodiments, the registry 414 may be, but is not limited to, a separate blockchain ledger.

[0080] The registry 414 may store data identified by DIDs. For example, the registry 414 may store records indexed by DID values. In addition, the registry 414 may maintain a VC schema (structure) and validation keys. A VC may be partially validated by matching its schema to that stored in the registry 414 and by validating a digital signature using the public key of the issuer that issued the VC stored in the registry 414. However, trust in claims about the characteristics of the DID owner in the VC, once validated, depends only on whether the validator trusts the VC issuer. Each of the blockchain peers 420 may include an SSI agent 424 installed internally. The SSI agent 424 may be additional software for maintaining a "wallet" of credentials for each component and communicating with a designated SSI network and with components belonging to other networks. Some of this functionality is unique to blockchains. This is because it involves knowing where that component fits into a given network and understanding how to communicate with external blockchain networks (including SSI networks). Some other parts of this functionality are specific to DID management, not blockchain.

[0081] In an exemplary embodiment, a verifiable credential (VC) that extends the verifiable set of DIDs, tamper detection, and claims is created by an issuer. A verifiable presentation (VP) can be derived from the VC to present attributes of a particular credential shared with a particular verifier. In some embodiments, the VC can include data synthesized from the original credential (e.g., zero-knowledge proof, etc.). A verifiable data registry can interact with the verifier to obtain information to confirm the validity of the VC. The registry mediates the creation and validation of identities, credential schemas, etc. DIDs can also be included in the VC. DIDs can be used to identify blockchain network components. In private blockchain networks (e.g., Fabric, Corda), clients and all active components have identities. Fabric peers and orderers have identities. In an exemplary embodiment, all identities in the blockchain network are managed by an SSI identity network. The SSI network facilitates the issuance and validation of credentials for all identities participating in the blockchain network. Blockchain network components are mapped to identities managed by the SSI network.

[0082] The identity data (actual identity network) can be hosted within the same or an external network. This technology does not require a blockchain (an architectural and operational choice). However, there are several advantages to using the external option. For example, the external network can act as an identity network for multiple networks, acting as a bridge (or mediator) for inter-network exchanges. The external network allows for the unification and simplification of identity management across an organization or large ecosystem. This identity mechanism allows for an overall external network-based configuration management mechanism. In some embodiments, an organization is represented by an SSI issuer (similar to a CA).

[0083] In an exemplary embodiment, issuers provide identities to network components (e.g., peers) they manage. A network trust model is formed by establishing trust between issuers (organizations). This represents the initial setup of the SSI network. The SSI network can be a dynamic model, allowing for changes at any time. By extension, identities / VCs issued by issuers are trusted by verifiers. Every network component can play the role of a verifier when performing functional validation.

[0084] A default setup may be performed to configure active components, such as newly configured blockchain peers for a blockchain network. Here, active components may have a wallet or similar mechanism. Each component may be assigned a DID managed by the organization / issuer to which it belongs. As another example, each component may be assigned initial cryptographic material. Each component may have configuration for connection to the SSI identity network. During initial setup / startup, a component obtains initial VC using its DID / cryptographic material. Depending on the needs of the organization, a component can issue multiple VCs or VPs required for various ledgers, smart contracts, transactions, etc. Issuers and networks have identity issuance policies that define, for example, what type of credentials must be used to sign TX / blocks. Components may include SSI agents that perform identity-related functions (obtaining VC / VP when necessary) based on these policies. This allows for dynamic configuration and updating of credentials used to process TX, blocks, etc.

[0085] SSI determinism can involve challenges. VCs / VPs can change over time, expire, be updated, etc. The SSI network can be updated (revocation lists, etc.). For retroactive validation of the ledger, VCs / VPs must be resolvable and verifiable as of the time of TX processing. The state of the VC / VP, and the condition of the TX. Here, VCs / VPs can have expiration timestamps. TX is a coordinated timestamp across the network. The network can converge to a single representative timestamp. TX peer timestamps must be within a piano-specific delta (configurable for a particular network). The TX processing mechanism ensures that timestamps are validated for all VCs / VPs used in the TX (expiration must be later than the TX, apart from other validity checks). The VCs / VPs used during transaction creation are included in that transaction and stored / attached to the header (TX or block). The stored representation can be a verifiable subset (e.g., a specific VP of a VC). Including the VC / VP and timestamp in the ledger allows for retroactive validation regardless of subsequent state changes.

[0086] The state of the SSI network may change over time. To support ledger validation, the SSI network may be extended to support retrospective query and validation capabilities. The SSI network may inherently include a verifiable past state, such as a blockchain / ledger (or similar). The SSI network protocol / API may be extended to allow for time-bound validation. An exemplary embodiment may include a timestamp as an argument to API functions. The timestamp argument may be used to obtain the state of the artifact in effect at the represented time. There may also be a delta argument used in queries to allow for lack of composition between networks.

[0087] FIG. 5 illustrates a method 500 for performing a blockchain transaction using verifiable credentials, according to an example embodiment. As a non-limiting example, method 500 may be performed by a blockchain peer that manages a blockchain ledger or the like. Referring to FIG. 5, at 510, the method may include receiving a request for storage in a blockchain network. As an example, the request may include executing, endorsing, committing, etc., a blockchain transaction to the blockchain. As another example, the request may include multiple transactions to be ordered and stored in a block to be committed to the blockchain.

[0088] At 520, the method may include attaching a verifiable credential created by a self-sovereign identity (SSI) network to a blockchain transaction as a signature via a blockchain node, where the verifiable credential includes a claim of the blockchain node that signed the request and proof of the SSI network that created the verifiable credential. Here, the blockchain node may execute the blockchain transaction, for example, simulating one or more parameters of the transaction against the current state of the blockchain to generate a response. The blockchain node may attach VC to an execution result of the transaction and transmit the executed result and the attached VC to another blockchain peer, client, orderer, etc. At 530, the method may include transmitting the blockchain transaction and the attached verifiable credential to one or more other blockchain nodes. Further, at 540, the method may include storing the blockchain transaction and the attached verifiable credential via a data block on the blockchain.

[0089] In some embodiments, the verifiable credential may include a decentralized identifier (DID) that uniquely identifies the blockchain node. In some embodiments, the request may include a request for execution of a blockchain chaincode, and the verifiable credential may include therein a claim that identifies the blockchain node as a blockchain peer that is authorized to execute the chaincode. In some embodiments, the verifiable credential may include a timestamp of when it was created and an expiration value. In some embodiments, the method may further include receiving a modified verifiable credential from the SSI network, the modified verifiable credential including the new claim added thereto, a timestamp of when the new claim was created, and an expiration value.

[0090] In some embodiments, the request may include a request for ordering multiple blockchain transactions, and signing includes ordering the multiple blockchain transactions in a new block and signing the new block with a verifiable credential indicating that the blockchain node is an ordering node for the blockchain. In some embodiments, the request may include a request for adding a block to a predefined blockchain ledger, channel of the ledger, etc., where the verifiable credential stores a claim identifying the blockchain node as a blockchain peer that is authorized to store the block in the predefined blockchain ledger, etc. In some embodiments, the request may include a blockchain entry received from the client, where the signature includes an endorsement of the blockchain entry, and the verifiable credential identifies the blockchain node as an endorsing peer for the blockchain.

[0091] FIG. 6A illustrates an exemplary system 600 including a physical infrastructure 610 configured to perform various operations according to an exemplary embodiment. Referring to 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 of the operational steps 608 (within the module 612) included in any of the exemplary embodiments. The steps / operations 608 may include one or more of the described or illustrated embodiments and may represent outputs written to or information written and read from one or more smart contracts 630 and / or the 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. Additionally, the module 612 and the module 614 may be the same module.

[0092] FIG. 6B illustrates another exemplary system 640 configured to perform various operations according to an exemplary embodiment. Referring to FIG. 6B, system 640 includes module 612 and module 614. Module 614 includes a blockchain 620 and a smart contract 630 (which may reside on the blockchain 620) and may perform any of the operational steps 608 (within module 612) included in any of the exemplary embodiments. The steps / operations 608 may include one or more of the described or illustrated embodiments and may represent outputs written to or information written and read from one or more smart contracts 630 and / or the blockchain 620. Physical infrastructure 610, module 612, and module 614 may include one or more computers, servers, processors, memories, and / or wireless communication devices. Furthermore, module 612 and module 614 may be the same module.

[0093] FIG. 6C illustrates an exemplary system configured to utilize a smart contract configuration between contract parties and an intermediary server configured to execute the smart contract terms on a blockchain, according to an exemplary embodiment. Referring to FIG. 6C, the configuration 650 may represent a communication session, an asset transfer session, or a process or procedure driven by a smart contract 630 that explicitly identifies one or more user devices 652 and / or 656. The execution, operation, and results of smart contract execution may be managed by a server 654. The contents of the smart contract 630 may require digital signatures by one or more of the entities 652 and 656 that are parties to the smart contract transaction. The results of 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.

[0094] Figure 6D illustrates a system 660 including a blockchain, according to an example embodiment. Referring to the example of Figure 6D, an application programming interface (API) gateway 662 provides a common interface for accessing blockchain logic (e.g., smart contracts 630 or other chaincode) and data (e.g., a distributed ledger, etc.). In this example, the API gateway 662 is a common interface for executing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 652 and 656 to a blockchain peer (i.e., server 654). Here, server 654 is a blockchain network peer component that holds a copy of the world state and distributed ledger, enabling clients 652 and 656 to query data about the world state and, according to smart contract 630 and endorsement policies, submit transactions into the blockchain network where endorsing peers execute smart contract 630.

[0095] The above embodiments may be implemented in hardware, in a computer program executed by a processor, in firmware, or in a combination of the above. The computer program may be embodied on a computer-readable medium, such as a storage medium. For example, the computer program may reside in 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.

[0096] An exemplary storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. Alternatively, the storage medium may be integral to the processor. The processor and the storage medium may reside in an application-specific integrated circuit ("ASIC"). Alternatively, the processor and the storage medium may reside as discrete components.

[0097] FIG. 7A illustrates a process 700 in which a new block is added to a distributed ledger 720 according to an example embodiment, and FIG. 7B illustrates the contents of a new data block structure 730 for the blockchain according to an example embodiment. Referring to FIG. 7A, a client (not shown) may submit transactions to blockchain nodes 711, 712, and / or 713. A client may be instructions received from any source to perform an activity on the blockchain 720. As an example, a client may be an application acting on behalf of a requester, such as a device, person, or entity, to propose a transaction to the blockchain. Multiple blockchain peers (e.g., blockchain nodes 711, 712, and 713) may maintain copies of the blockchain network state and the distributed ledger 720. Different types of blockchain nodes / peers may exist within a blockchain network, including endorsing peers that simulate and endorse transactions proposed by clients, and committing peers that verify the endorsements, confirm the validity of the transactions, and commit the transactions to the distributed ledger 720. In this example, blockchain nodes 711, 712, and 713 may act as endorser nodes, committer nodes, or both.

[0098] The distributed ledger 720 includes a blockchain, which stores immutable, sequenced records in blocks, and a state database 724 (current world state) that maintains the current state of the blockchain 722. There may be one distributed ledger 720 per channel, and each peer maintains its own copy of the distributed ledger 720 for which it is a member of each channel. The blockchain 722 is a transaction log structured as hash-linked blocks, with each block containing a sequence of N transactions. Blocks may include various components, such as those shown in FIG. 7B. Block links (shown by arrows in FIG. 7A) may be generated by appending the hash of the previous block's header to the current block's block header. In this way, all transactions on the blockchain 722 are sequenced and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash links. Furthermore, because of these links, the latest block in the blockchain 722 represents all transactions that came before it. The blockchain 722 may be stored on a peer file system (local or attached storage) to support append-only blockchain workloads.

[0099] The current state of the blockchain 722 and distributed ledger 722 may be stored in a state database 724, where the current state data represents the latest values of all keys ever included in the on-chain transaction log of the blockchain 722. Chaincode invocations execute transactions against the current state in the state database 724. To make these chaincode interactions highly efficient, the latest values of all keys may be stored in the state database 724. The state database 724 may contain an indexed view into the transaction log of the blockchain 722 and therefore can be regenerated off-chain at any time. The state database 724 may be automatically recovered (or generated, if necessary) at peer startup and before any transactions are accepted.

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

[0101] The ordering service 710 accepts endorsed transactions, orders them into blocks, and distributes the blocks to committing peers. For example, the ordering service 710 may start a new block when a transaction threshold is reached, a timer times out, or another condition occurs. In the example of FIG. 7A, blockchain node 712 is a committing peer that receives a new data block 730 of new data to be stored in the blockchain 720. The first block in a blockchain may be referred to as a genesis block, which contains information about the blockchain, its members, the data stored therein, etc.

[0102] The ordering service 710 may consist of a cluster of orderers. The ordering service 710 does not process transactions, smart contracts, or maintain a shared ledger. Rather, the ordering service 710 may accept endorsed transactions and specify the order in which these transactions are committed to the distributed ledger 720. The architecture of the blockchain network may be designed so that specific implementations of "ordering" (e.g., Solo, Kafka, BFT, etc.) are pluggable components.

[0103] 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 take effect when they are committed to the network. Unlike cryptocurrency blockchain systems (e.g., Bitcoin, etc.) where ordering is achieved through solving cryptographic puzzles or mining, in this example, the parties to the distributed ledger 720 may choose the ordering mechanism that best suits their network.

[0104] When the ordering service 710 initializes a new data block 730, the new data block 730 may be broadcast to the committing peers (e.g., blockchain nodes 711, 712, and 713). In response, each committing peer verifies the validity of the transactions in the new data block 730 by checking its read set and write set to ensure that they still match the current world state in the state database 724. Specifically, a committing peer can determine whether the read data that existed when the endorser simulated the transaction is identical to the current world state in the state database 724. If the committing peer verifies the validity of 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 from the read-write set. If the transaction fails, that is, if the committing peer finds that the read-write set does not match the current world state in the state database 724, the transactions that were ordered in the block are still included in the block but are marked as invalid, and the state database 724 is not updated.

[0105] 7B, a new data block 730 (also referred to as a data block) stored in the blockchain 722 of the distributed ledger 720 may include multiple data segments, such as a block header 740, block data 750 (block data section), and block metadata 760. It should be understood that the various blocks and their contents shown in the figure, such as the new data block 730 and its contents shown in Figure 7B, are examples only and are not meant to limit the scope of the illustrative embodiments. In a traditional block, the data section may store transaction information for N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) in the block data 750.

[0106] The new data block 730 may also include a link to its predecessor block (e.g., on the blockchain 722 of FIG. 7A) in its block header 740. In particular, the block header 740 may include a hash of the header of the predecessor block. The block header 740 may also include a unique block number, a hash of the block data 750 of the new data block 730, etc. The block numbers of the new data block 730 are unique and may be assigned in various orders, such as incremental / sequential order starting from zero.

[0107] According to various embodiments, the block data 750 may store the SSI identification 752, such as a verifiable credential, a DID, a verifiable presentation, or the like. According to various embodiments, the SSI identification 752 may be stored in an immutable log of blocks on the distributed ledger 720. Some of the benefits of storing the SSI identification 752 on a blockchain are reflected in various embodiments disclosed and illustrated herein. While FIG. 7B shows the SSI identification 752 in the block data 750, in other embodiments, the SSI identification 752 may be located in the block header 740 or the block metadata 760.

[0108] 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 constituent block, a transaction filter that identifies valid and invalid transactions in the block, the last persisted offset of the ordering service that ordered the block, etc. The signature, last constituent block, and orderer metadata may be added by the ordering service 710. Meanwhile, the block committer (e.g., blockchain node 712) may add validity / invalidity information based on an endorsement policy and validation of the read / write set, etc. The transaction filter may include a byte array of a size equal to the number of transactions included in block data 750 and a validation code that identifies whether the transaction was valid / invalid.

[0109] Figure 7C shows one embodiment of a blockchain 770 for digital content, according to embodiments described herein. The digital content may include one or more files and associated information. The files may include media, images, video, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable and append-only aspects of the blockchain serve as safeguards 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 settings where evidence is considered or the presentation and use of digital information is otherwise of interest. In this case, the digital content may be referred to as digital evidence.

[0110] A blockchain may be formed in various ways. In one embodiment, digital content may be contained in and accessed from the blockchain itself. For example, each block of the blockchain may store a hash value of reference information (e.g., headers, values, etc.) along with associated digital content. The hash value and associated digital content may then be encrypted together. Thus, the digital content of each block may be accessed by decrypting each block in the blockchain, and the hash value of each block may be used as a basis for referencing previous blocks. This may be shown as follows: [Table 1]

[0111] In one embodiment, the digital content may not be included in the blockchain. For example, the blockchain may store an encrypted hash of the contents of each block without any of the digital content. The digital content may be stored in a separate storage area or memory address associated 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 the hash value in the storage area where it is stored in correspondence with the actual digital content. This operation may be performed, for example, by a database gatekeeper. This may be illustrated as follows: [Table 2]

[0112] In the exemplary embodiment of FIG. 7C, the blockchain 770 comprises a plurality of cryptographically linked blocks 7781, 7782...7783 in an ordered sequence. N where N≧1. Blocks 7781, 7782...778 N The encryption used to link the blocks 7781, 7782, ... 778 can be any of multiple keyed or non-keyed hash functions. N is subjected to a hash function that generates 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-Dangard algorithms, HAIFA algorithms, Merkle tree algorithms, nonce-based algorithms, and collision-resistant PRF algorithms. In another embodiment, blocks 7781, 7782, ..., 778 N may be cryptographically linked by a function different from the hash function. For illustrative purposes, the following description is given with respect to a hash function, e.g., SHA-2.

[0113] Blocks 7781, 7782...778 in the blockchain N Each of the files includes a header, a file version, and a value. The header and value are different for each block as a result of hashing within the blockchain. In one embodiment, the value may be included in the header. As described in more detail below, the file version may be the original file or a different version of the original file.

[0114] The first block 7781 in a blockchain is called the genesis block and includes a header 7721, an original file 7741, and an initial value 7761. The hashing scheme used for the genesis block, and indeed all subsequent blocks, may be different. For example, all of the information in the first block 7781 may be hashed together at once, or each or portions of the information in the first block 7781 may be hashed separately, and then a hash of the separately hashed portions may be performed.

[0115] The header 7721 may include one or more initial parameters, such as a version number, a timestamp, a nonce, root information, difficulty, consensus protocol, duration, media format, source, descriptive keywords, and / or other information associated with the original file 7741 and / or the blockchain. The header 7721 may be generated automatically (e.g., by a blockchain network that manages the software) or manually by a blockchain participant. Other blocks 7782-7783 in the blockchain N Unlike the headers in the , the header 7721 in the genesis block does not reference a previous block, simply because there is no previous block.

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

[0117] The value 7761 in the genesis 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 implementation, the initial value 7761 is 1) The SHA-2 calculated hash value of the original file 2) Source device ID 3) The start timestamp of the original file 4) Initial storage location of the original file 5) The blockchain network member ID of the software that currently controls the original file and associated metadata. The attribute may be based on a unique attribute.

[0118] Other blocks in the blockchain: 7782-778 N However, unlike the first block 7721, the headers 7722-7723 of the other blocks also have headers, files, and values. N Each of the remaining blocks contains the hash value of the immediately preceding block. The hash value of the immediately preceding block may simply be the hash of the header of the preceding block, or it 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, tracing from the Nth block back to the genesis block (and associated original file) can be performed block by block, as indicated by arrow 780, to establish an auditable and immutable chain of custody.

[0119] Also, headers 7722-772 in other blocks N Each of the may include other information, such as a version number, a timestamp, a nonce, root information, difficulty level, a consensus protocol, and / or other parameters or information associated with the corresponding file and / or blockchains in general.

[0120] Files 7742-774 in other blocksN may be equal to the original file or may be a modified version of the original file in the genesis block, depending on, for example, the type of processing performed. The type of processing performed may vary from block to block. Processing may involve any modification of the file in the preceding block, such as, for example, editing or otherwise changing the content, removing information, or adding or appending information to the file.

[0121] Additionally or alternatively, processing may involve simply copying a file from a previous block, changing the 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 an action on a file on the blockchain and / or its associated metadata. Processing involving analysis of a file may include, for example, adding, including, or otherwise associating various analytical, statistical, or other information associated with the file.

[0122] Other blocks in other blocks 7762-776 N The value in each of the blocks is unique and is different as a result of the operations that were 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. Thus, the value of a block provides an indication of what operations were performed in the block and also allows tracing back through the blockchain to the original file. This tracing confirms the chain of custody of the file throughout the blockchain.

[0123] For example, consider the case where a portion of a file in a previous block has been redacted, blocked out, or pixelated to protect the identity of a person depicted in the file. In this case, the block containing the edited file includes metadata associated with the edited file, such as how the edits were made, who made the edits, the timestamp at which the edits occurred, etc. The metadata may be hashed to form a value. Because the metadata for the block is different from the information hashed to form the value in the previous block, these values may be different from each other and may be recovered when decrypted.

[0124] In one embodiment, the value of a previous block may be updated (e.g., a new hash value may be calculated) to form the value of a current block if any one or more of the following occurs: The new hash value, in this example embodiment, may be calculated by hashing all or part of the information shown below: a) if the file has been processed in any way (e.g., if the file has been edited, copied, modified, accessed, or any other action taken), a new SHA-2 calculated hash value; b) a new storage location for the file; c) identified new metadata associated with the file; d) Transfer of access or control of a file from one blockchain participant to another.

[0125] Figure 7D illustrates an embodiment of a block that may represent the structure of a block in a blockchain 790, according to one embodiment. i Header 772 i , File 774 i and value 776 i Includes:

[0126] Header 772 i is the preceding block Block i-1and additional reference information, which may be, for example, any type of information described herein (e.g., header information containing references, properties, parameters, etc.). Every block references the hash of its predecessor block, except of course for the genesis block. The hash value of the predecessor block may simply be a hash of the header in the predecessor block, or a hash of all or part of the information in the predecessor block, including files and metadata.

[0127] File 774 i includes multiple pieces of data, such as Data1, Data2, ..., DataN, in order. The data are tagged with Metadata1, Metadata2, ..., MetadataN that describe the content and / or characteristics associated with the data. For example, the metadata for each piece of data may include a timestamp for the data, keywords that indicate the process of the data, people or other content depicted in the data, and / or other characteristics that may be useful in establishing the validity and content of the file as a whole, and in particular information indicative of its use, e.g., digital evidence, as described in connection with one embodiment described below. In addition to the metadata, each piece of data may also include references REF1, REF2, ..., REF to the previous piece of data to prevent tampering, gaps within the file, and sequential referencing through the file. N May be tagged with.

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

[0129] Value 776 i is a hash value or other value calculated based on any of the types of information mentioned above. For example, for any given block, Block i, the value of that block may be updated to reflect the processing performed on that block, such as a new hash value, a new storage location, new metadata for the associated file, a transfer of control or access, an identifier, or other action or information being added. Although the values in each block are shown to be separate from the metadata and headers for the file's data, in other embodiments the values may be based in part or entirely on this metadata.

[0130] Once the blockchain 770 is formed, at any point in time, an immutable chain of custody for a file can be obtained by querying the blockchain for the transaction history of values across blocks. This query, or tracking procedure, may begin by decrypting the value of the most recently included block (e.g., the last (Nth) block), and then continuing to decrypt the values of other blocks until the genesis block is reached and the original file is recovered. Decryption may also involve decrypting the header and file and associated metadata in each block.

[0131] Decryption is performed based on the type of encryption performed on each block. This may involve the use of a private key, a public key, or a public-private key pair. For example, if asymmetric encryption is used, blockchain participants or processors in the network may use a predetermined algorithm to generate a public-private key pair. The public and private keys are related to each other through some mathematical relationship. The public key may be publicly distributed to serve as an address for receiving messages from other users, e.g., an IP address or 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 could have sent the message.

[0132] Generating a key pair may be similar to creating an account on the blockchain, but without actually registering it anywhere. Also, all transactions performed on the blockchain are digitally signed by the sender using their private key. This signature ensures that only the account owner can track and transact files on the blockchain (if within their permissions as determined by the smart contract).

[0133] 8A and 8B illustrate additional example blockchain use cases that may be incorporated and used herein. In particular, FIG. 8A illustrates an example 800 of a blockchain 810 storing machine learning (artificial intelligence) data. Machine learning relies on vast amounts of historical data (or training data) to build predictive models for accurately predicting new data. Machine learning software (e.g., neural networks, etc.) can often sift through millions of records to discover non-intuitive patterns.

[0134] 8A , host platform 820 builds and deploys machine learning models for predictive monitoring of assets 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., machinery or equipment, etc.), such as, for example, aircraft, locomotives, turbines, medical machinery and equipment, oil and gas equipment, boats, ships, and vehicles. As another example, asset 830 may be an intangible asset, such as, for example, stocks, currency, digital coins, or insurance.

[0135] The blockchain 810 can be used to significantly improve both the machine learning model training process 802 and the prediction process 804 based on the trained machine learning model. For example, in 802, historical data can be stored on the blockchain 810 by the asset 830 itself (or through an intermediary, not shown) rather than requiring a data scientist / engineer or other user to collect the data. This can significantly reduce the collection time required by the host platform 820 when performing training of a predictive model. For example, a smart contract can be used to directly and reliably transfer data from its original 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 the data directly from the asset to the individual who uses the data to build the machine learning model. This enables data to be shared among the assets 830.

[0136] The collected data can be stored on the blockchain 810 based on a consensus mechanism that incorporates (permissioned nodes) to ensure the data being recorded is verified and accurate. The recorded data is time-stamped, cryptographically signed, and immutable; therefore, it is auditable, transparent, and secure. Adding IoT devices that write directly to the blockchain can increase both the frequency and accuracy of the data being recorded in certain cases (i.e., supply chain, healthcare, logistics, etc.).

[0137] Furthermore, training the machine learning model on the collected data may require rounds of refinement and testing by the host platform 820. Each round may be based on additional data or data not previously considered useful for expanding the machine learning model's knowledge. At 802, the different training and testing stages (and their associated data) may be stored by the host platform 820 on the blockchain 810. Each refinement of the machine learning model (e.g., change of variables, weights, etc.) may be stored on the blockchain 810, providing verifiable proof of how the model was trained and the data used to train the model. Furthermore, when the host platform 820 realizes the final trained model, the resulting model may be stored on the blockchain 810.

[0138] After the model is trained, it can ultimately be deployed to a live environment where predictions / decisions can be made based on the execution of the trained machine learning model. For example, at 804, the machine learning model can be used for condition-based maintenance (CBM) of assets such as aircraft, wind turbines, and medical machinery. In this example, feedback data from the asset 830 can be input into the machine learning model and used to make event predictions, such as failure events and error codes. Decisions made by the execution of the machine learning model on the host platform 820 can be stored on the blockchain 810 to provide auditable / verifiable proof. As one non-limiting example, the machine learning model can predict a future failure / failure for a portion of the asset 830 and generate an alert or notification to replace the part. The data on which this decision is based can be stored by the host platform 820 on the blockchain 810. In one embodiment, the features and / or actions described and / or illustrated herein can be performed on or with respect to the blockchain 810.

[0139] New transactions on the blockchain can be packaged into a new block and added to the existing hash value. This is then encrypted to create a new hash for the new block. This is added to the next list of transactions as they are encrypted, and so on. The result is a chain of blocks, each containing the hash values of all preceding blocks. Computers storing these blocks periodically compare the hash values to ensure they all match. Any computers that do not match will discard the offending record. This approach is good at ensuring the blockchain is tamper-proof, but it is not perfect.

[0140] One way to exploit this loophole in the system is for a fraudulent user to change the list of transactions to their advantage, thereby avoiding changing the hash. This can be done by brute force, in other words by changing the record, encrypting the result, and checking if the hash value is the same. If it doesn't match, they try again and again until they find a matching hash. Blockchain security is based on the idea that ordinary computers can only perform this kind of brute force attack on completely unrealistic timescales, such as the age of the universe. Quantum computers, in contrast, are much faster (thousands of times faster) and therefore pose a much greater threat.

[0141] Figure 8B shows an example 850 of a quantum-secure blockchain 852 that implements quantum key distribution (QKD) to protect against quantum computing attacks. In this example, blockchain users can verify each other's identities using QKD, which transmits information using quantum particles, such as photons, that cannot be copied by an eavesdropper without being corrupted. In this way, senders and receivers across the blockchain can confirm each other's identities.

[0142] In the example of Figure 8B, there are four users: 854, 856, 858, and 860. Each pair of users may share a secret key 862 (i.e., QKD) between themselves. Since there are four nodes in this example, there are six pairs of nodes, and therefore, QKD AB , QKD AC , QKD AD , QKD BC , QKD BD , and QKD CD Six different secret keys 862 are used, including 862 for each pair. Each pair can create QKD by transmitting information using quantum particles, such as photons, which cannot be copied by an eavesdropper without being corrupted. In this way, pairs of users can verify each other's identities.

[0143] The operation of blockchain 852 is based on two steps: (i) transaction creation and (ii) the construction of blocks that aggregate new transactions. New transactions can be created in the same way as in traditional blockchain networks. Each transaction can contain information about the sender, recipient, creation time, the amount (or value) being transferred, and a list of reference transactions that justify the sender having the funds for the operation. This transaction record is then sent to all other nodes and placed in a pool of unconfirmed transactions. Here, two parties (i.e., a pair of users from among 854-860) authenticate the transaction by providing a shared secret key 862 (QKD). This quantum signature can be attached to every transaction, making it extremely difficult to tamper with. Each node checks the entry against its local copy of blockchain 852 and verifies that each transaction has sufficient funds. However, the transaction is not yet confirmed.

[0144] Rather than performing a traditional mining process on blocks, blocks may be created in a decentralized manner using a broadcast protocol. At a predetermined period (e.g., seconds, minutes, hours, etc.), the network applies the broadcast protocol to any unconfirmed transactions, thereby achieving Byzantine consensus on the correct version of the transaction. For example, each node may possess a private value (that particular node's transaction data). In a first round, nodes transmit their private values to each other. In subsequent rounds, nodes communicate information received from other nodes in previous rounds. Honest nodes can now create the complete set of transactions in a new block. This new block can be added to the blockchain 852. In one embodiment, the features and / or actions described and / or illustrated herein may occur on or with respect to the blockchain 852.

[0145] 9 illustrates an exemplary system 900 that supports one or more of the exemplary embodiments described and / or illustrated herein. System 900 comprises a computer system / server 902, which is operable with numerous other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that may be suitable for use with computer system / server 902 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices, etc.

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

[0147] 9, a computer system / server 902 within 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 coupling various system components including the system memory 906 to the processor(s) 904.

[0148] A bus represents one or more of any 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 MicroChannel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0149] Computer system / server 902 typically includes a variety of computer system-readable media. Such media may be any available media accessible by computer system / server 902, including both volatile and nonvolatile media, and removable and non-removable media. System memory 906, in one embodiment, implements the flow diagrams of other figures. System memory 906 may 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 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 914 may be provided for reading from and writing to non-removable, non-volatile magnetic media (not shown, but typically referred to as a “hard drive”). Although not shown, a magnetic disk drive for reading from and writing to a removable nonvolatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive for reading from or writing to a removable nonvolatile optical disk, such as a CD-ROM, DVD-ROM, or other optical media, may be provided. In such cases, each may be connected to the bus by one or more data media interfaces. As further illustrated and described below, memory 906 may include at least one program product having a set (e.g., at least one) program module configured to perform the functions of various embodiments of the application.

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

[0151] As will be appreciated by one skilled in the art, aspects of the present application may be embodied as a system, method, or computer program product. Accordingly, aspects of the present application may take the form of an entirely hardware embodiment, an entirely software (including firmware, resident software, microcode, etc.) embodiment, or an embodiment combining software and hardware aspects, all of which may be generally referred to herein as a "circuit," "module," or "system." Furthermore, aspects of the present application may take the form of a computer program product embodied in one or more computer-readable medium(s) having computer-readable program code embodied therein.

[0152] The computer system / server 902 may also communicate with one or more external devices 920, such as, for example, a keyboard, a pointing device, a display 922, one or more devices that allow a user to interact with the computer system / server 902; and / or any device (e.g., a network card, a modem, etc.) that allows the computer system / server 902 to communicate with one or more other computing devices. Such communication may occur via an I / O interface 924. Furthermore, the computer system / server 902 may 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), via 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 drive arrays, RAID systems, tape drives, data archive storage systems, etc.

[0153] While at least one exemplary embodiment of the system, method, and non-transitory computer-readable medium is illustrated 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 is capable of numerous rearrangements, modifications, and substitutions as described and defined in the following claims. For example, the functions of the various illustrated systems may be performed by one or more of the modules or components described herein, or in a distributed architecture, and may include pairs of transmitters, receivers, or both. For example, all or part of the functions performed by individual modules may be performed by one or more of those modules. Furthermore, the functions described herein may be performed at various times in connection with various events internal or external to the modules or components. Furthermore, information transmitted between the various modules may be transmitted between the modules via at least one of a data network, the Internet, a voice network, an Internet Protocol network, a wireless device, a wired device, and / or via multiple protocols. Furthermore, messages transmitted or received by any of the modules may be transmitted or received directly and / or via one or more of the other modules.

[0154] Those skilled in the art will appreciate that the "system" may be embodied as a personal computer, a server, a console, a personal digital assistant (PDA), a mobile phone, a tablet computing device, a smartphone, or any other suitable computing device or combination of devices. Presenting the above-described functions as being performed by a "system" is not intended to limit the scope of the present application in any way, but rather to provide one example of many embodiments. Indeed, the methods, systems, and apparatuses disclosed herein may be implemented in both local and distributed fashions consistent with computing technology.

[0155] Note that some of the system features described herein are presented as modules to more specifically emphasize implementation independence. For example, a module may be implemented as a hardware circuit comprising custom very large scale integrated (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or graphics processing units.

[0156] Modules may also be implemented at least partially in software for execution by various types of processors. For example, an identified unit of executable code may comprise one or more physical or logical blocks of computer instructions, which may be organized, for example, as an object, procedure, or function. Nevertheless, the executable files of an identified module need not be physically located together, but may comprise heterogeneous instructions stored in different locations that, when logically combined, comprise a module and achieve the module's stated purpose. Furthermore, a module may be stored on a computer-readable medium, which may be, for example, a hard disk drive, a flash device, a random access memory (RAM), a tape, or any other such medium used to store data.

[0157] Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed across several different code segments, among different programs, and even across several memory devices. Similarly, operational data may be identified and depicted herein in modules and may be embodied in any suitable form and organized within any suitable type of data structure. Operational data may be collected as a single data set or distributed across different locations, including different storage devices, and may exist, at least in part, solely as electronic signals on a system or network.

[0158] It will be readily understood that the components of the present application, as generally described and illustrated in the Figures herein, could be arranged and designed in a wide variety of different configurations. Thus, the detailed description of the embodiments is not intended to limit the scope of the present application as claimed, but rather is merely representative of selected embodiments of the present application.

[0159] Those skilled in the art will readily appreciate that the above may be implemented in steps in a different order and / or with hardware elements in different configurations than those disclosed. Thus, while the present application has been described in terms of these preferred embodiments, it will be apparent to those skilled in the art that certain modifications, variations and alternative configurations will be apparent.

[0160] While preferred embodiments of the present application have been described, it should be understood that the described embodiments are by way of example only, and that the scope of the present application should be defined solely by the appended claims, taking into account the full range of equivalents and modifications thereto (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. a network interface configured to receive a request for storage in the blockchain; and a processor configured to attach, via the blockchain node, a verifiable credential created by a Self-Sovereign Identity (SSI) network, the verifiable credential including a claim of a blockchain node and proof of the SSI network that created the verifiable credential, to a blockchain transaction associated with the request, and to store the blockchain transaction and the attached verifiable credential via a data block on the blockchain, wherein the processor is further configured to control the network interface to transmit the blockchain transaction and the attached verifiable credential to one or more other blockchain nodes. An apparatus comprising:

2. 10. The apparatus of claim 1, wherein the verifiable credential further comprises a decentralized identifier (DID) that uniquely identifies the blockchain node.

3. 3. The apparatus of claim 1 or 2, wherein the request includes a request for execution of the blockchain transaction via a smart contract of the blockchain, and the verifiable credentials include therein a claim identifying the blockchain node as a blockchain peer that is authorized to execute the smart contract.

4. The apparatus of claim 1 , wherein the verifiable credential includes a timestamp of when the verifiable credential was created and an expiration value.

5. 5. The apparatus of claim 1, wherein the processor is further configured to receive a modified verifiable credential from the SSI network, the modified verifiable credential including a new claim to be added to the modified verifiable credential, a timestamp of when the new claim was created, and an expiration value.

6. 6. The apparatus of claim 1, wherein the request includes a request to order a plurality of blockchain transactions, and wherein the processor is configured to order the plurality of blockchain transactions in a new block and to attach a verifiable credential to the new block indicating that the blockchain node is an ordering node for the blockchain.

7. 7. The apparatus of claim 1, wherein the request includes a request to add a block to a predefined blockchain ledger, and the verifiable credential stores therein a claim identifying the blockchain node as a blockchain peer that is authorized to store the block in the predefined blockchain ledger.

8. 8. The apparatus of claim 1, wherein the processor is further configured to endorse the blockchain transaction, wherein the verifiable credential identifies the blockchain node as an endorsing peer of the blockchain.

9. receiving a request for storage on the blockchain; attaching a verifiable credential created by a Self-Sovereign Identity (SSI) network via the blockchain node to the blockchain transaction associated with the request, the verifiable credential including a claim of the blockchain node and proof of the SSI network that created the verifiable credential; transmitting the blockchain transaction and the attached verifiable credential to one or more other blockchain nodes; and storing the blockchain transaction and the attached verifiable credential via a data block on the blockchain; A method for providing

10. 10. The method of claim 9, wherein the verifiable credential further comprises a decentralized identifier (DID) that uniquely identifies the blockchain node.

11. 11. The method of claim 9 or 10, wherein the request includes a request for execution of the blockchain transaction via a smart contract of the blockchain, and the verifiable credentials include therein a claim identifying the blockchain node as a blockchain peer that is authorized to execute the smart contract.

12. 12. The method of claim 9, wherein the verifiable credential includes a timestamp of when the verifiable credential was created and an expiration value.

13. 13. The method of claim 9, further comprising receiving a modified verifiable credential from the SSI network, wherein the modified verifiable credential includes a new claim to be added to the modified verifiable credential, a timestamp of when the new claim was created, and an expiration value.

14. 14. The method of claim 9, wherein the request includes a request for ordering a plurality of blockchain transactions, the method further comprising ordering the plurality of blockchain transactions in a new block and attaching a verifiable credential to the new block indicating that the blockchain node is an ordering node for the blockchain.

15. 15. The method of claim 9, wherein the request includes a request to add a block to a predefined blockchain ledger, and the verifiable credential stores therein a claim identifying the blockchain node as a blockchain peer that is authorized to store the block on the predefined blockchain ledger.

16. 16. The method of claim 9, further comprising endorsing the blockchain transaction, wherein the verifiable credential identifies the blockchain node as an endorsing peer of the blockchain.

17. The processor receiving a request for storage on the blockchain; attaching a verifiable credential created by a Self-Sovereign Identity (SSI) network via the blockchain node to the blockchain transaction associated with the request, the verifiable credential including a claim of the blockchain node and proof of the SSI network that created the verifiable credential; transmitting the blockchain transaction and the attached verifiable credential to one or more other blockchain nodes; and storing the blockchain transaction and the attached verifiable credential via a data block on the blockchain. A computer program for executing

18. 20. The computer program product of claim 17, wherein the verifiable credential further comprises a decentralized identifier (DID) that uniquely identifies the blockchain node.

19. 19. The computer program of claim 17 or 18, wherein the request includes a request for execution of the blockchain transaction via a smart contract of the blockchain, and the verifiable credentials include therein a claim identifying the blockchain node as a blockchain peer that is authorized to execute the smart contract.

20. 20. The computer program product of claim 17, wherein the verifiable credential includes a timestamp of when the verifiable credential was created and an expiration value.

Images