Blockchain network identity management using SSI

Abstract

The system receives requests for storage on a blockchain network, attaches verifiable credentials created by a Sovereign Identity (SSI) network to the blockchain transaction associated with the request via blockchain nodes, wherein the verifiable credentials include a claim of the blockchain node and proof of the SSI network that created the verifiable credentials, sends the blockchain transaction and the attached verifiable credentials to one or more other blockchain nodes, and stores the blockchain transaction and the attached verifiable credentials via data blocks on the blockchain.

Description

Background Technology

[0001] A centralized platform stores and maintains data in a single location. This location is typically a central computer, such as a cloud computing environment, web server, or mainframe computer. Information stored on a centralized platform is usually 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. Centralized platforms are easy to manage, maintain, and control due to their single location, especially for security purposes. Within a centralized platform, data redundancy is minimized because the single storage location of all data also implies that a given dataset has only one master record. Summary of the Invention

[0002] An 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 verifiable credentials created by a Sovereign Identity (SSI) network to a blockchain transaction associated with the request via a blockchain node, wherein the verifiable credentials include a claim to the blockchain node and proof of the SSI network that created the verifiable credentials, and to store the blockchain transaction and the attached verifiable credentials via data blocks on the blockchain, wherein the processor is further configured to control the network interface to send the blockchain transaction and the attached verifiable credentials to one or more other blockchain nodes.

[0003] Another example embodiment provides a method comprising receiving a request for storage on a blockchain, attaching a verifiable credential created by a Sovereign Identity (SSI) network to a blockchain transaction associated with the request via a blockchain node, wherein the verifiable credential includes a claim to the blockchain node and proof of the SSI network that created the verifiable credential, sending 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 data blocks on the blockchain.

[0004] Another example embodiment provides a non-transitory computer-readable medium including instructions that, when executed by a processor, cause a computer to perform one or more of the following: receiving a request for storage on a blockchain; attaching a verifiable credential created by a Sovereign Identity (SSI) network to a blockchain transaction associated with the request via a blockchain node, wherein the verifiable credential includes a claim to the blockchain node and proof of the SSI network that created the verifiable credential; sending 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 data blocks on the blockchain. Attached Figure Description

[0005] Figure 1A This is a diagram illustrating a blockchain network using Sovereign Identity (SSI) according to an example embodiment.

[0006] Figure 1B This is a diagram illustrating a verifiable credential according to an example embodiment.

[0007] Figure 1C This is a diagram illustrating further details of a verifiable credential according to an example embodiment.

[0008] Figure 2A This is a diagram illustrating an example blockchain architecture configuration according to an example embodiment.

[0009] Figure 2B This is a diagram illustrating the blockchain transaction flow between nodes according to an example embodiment.

[0010] Figure 3A This is a diagram illustrating a licensed network according to an example embodiment.

[0011] Figure 3B This is a diagram illustrating another licensed network according to an example embodiment.

[0012] Figure 3C This is a diagram illustrating an unlicensed network according to an example embodiment.

[0013] Figure 4 This is a diagram illustrating the process of issuing verifiable credentials according to an example embodiment.

[0014] Figure 5 This is a diagram illustrating a method for performing blockchain transactions with verifiable credentials according to an exemplary embodiment.

[0015] Figure 6A This is a diagram illustrating an example system configured to perform one or more operations described herein, according to an example embodiment.

[0016] Figure 6B This is a diagram illustrating another example system configured to perform one or more operations described herein, according to an example embodiment.

[0017] Figure 6C This is a diagram illustrating another example system configured to utilize smart contracts according to an example embodiment.

[0018] Figure 6D This is a diagram illustrating yet another example system configured to utilize blockchain according to an example embodiment.

[0019] Figure 7AThis is a diagram illustrating the process of adding a new block to a distributed ledger according to an example embodiment.

[0020] Figure 7B This is a diagram illustrating the data content of a new data block according to an example embodiment.

[0021] Figure 7C This is a diagram illustrating a blockchain for digital content according to an example embodiment.

[0022] Figure 7D This is a diagram illustrating a block that can represent the structure of a block in a blockchain according to an exemplary embodiment.

[0023] Figure 8A This is a diagram illustrating an example blockchain for storing machine learning (artificial intelligence) data according to an example embodiment.

[0024] Figure 8B This is a diagram illustrating an example quantum-safe blockchain according to an example embodiment.

[0025] Figure 9 This is a diagram illustrating an example system that supports one or more example embodiments. Detailed Implementation

[0026] It will be readily understood that, as generally described and illustrated in the accompanying drawings, the components of the present invention can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of at least one embodiment of the methods, apparatus, non-transitory computer-readable media, and systems illustrated in the drawings is not intended to limit the scope of the claimed applications, but is merely representative of selected embodiments.

[0027] In one or more embodiments, the features, structures, or characteristics described herein may be combined or removed in any suitable manner. For example, throughout the specification, the use of the phrases “example embodiment,” “some embodiments,” or other similar language refers to the fact that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment. Therefore, the phrases “example embodiment,” “some embodiments,” “other embodiments,” or other similar language appearing throughout the specification do not necessarily all refer to the same set of embodiments, and the described features, structures, or characteristics may be combined or removed in any suitable manner in one or more embodiments. Furthermore, in the figures, any connection between elements may allow unidirectional and / or bidirectional communication, even if the depicted connection is a unidirectional or bidirectional arrow. Moreover, any device depicted in the figures may be a different device. For example, if a mobile device is shown as transmitting information, a wired device may also be used to transmit information.

[0028] Furthermore, although the term "message" may have been used in the description of the embodiments, this application can be applied to many types of networks and data. Additionally, while certain types of connections, messages, and signaling may be described in the exemplary embodiments, this application is not limited to certain types of connections, messages, and signaling.

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

[0030] According to various implementations, each blockchain entity (e.g., peer, orderer, endorser, client, auditor, admin, etc.) can be assigned a unique Distributed Identifier (DID) that identifies the blockchain entity within the blockchain network. One or more Verifiable Credentials (VCs) can be issued to blockchain entities possessing a DID, which can be used to sign blockchain transactions, messages, blocks, etc. In some embodiments, each blockchain entity may include a set of VCs, each VC giving the blockchain entity one or more claims. For example, a claim could be a statement that a blockchain peer is authorized to sign transactions of a specific smart contract (chaincode). As another example, a blockchain peer may be authorized to transact on a specific channel / blockchain among multiple channels on the blockchain ledger. As yet another example, a claim could identify a blockchain peer as an endorsing peer of the blockchain network, etc.

[0031] Each verifiable credential can be issued from an authorized authority within the SSI network of the blockchain network (e.g., Membership Service Provider (MSP), Credential Authority (CA), etc.). Verifiable credentials can include a "proof," such as the signature of the issuer of the verifiable credential. The SSI network can maintain all assigned DIDs, VCs, etc. Additionally, the SSI network can maintain schema information for each VC, the public key of the issuer who signed the public key, etc. Blockchain members can access the registry to obtain the issuer's schema information and public key to verify the schema and signature of the verifiable credential, respectively. In this way, any blockchain entity can verify verifiable credentials without relying on central authority.

[0032] In one embodiment, this application utilizes a decentralized database (e.g., a blockchain) as a distributed storage system, comprising multiple nodes that communicate with each other. The decentralized database comprises an immutable, append-only data structure, similar to a distributed ledger capable of maintaining records between mutually distrustful parties. The untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database records, and no single peer can modify a database record without consensus among the distributed peers. For example, peers can execute consensus protocols to verify blockchain storage transactions, group storage transactions into blocks, and build hash chains on the blocks. This process forms a ledger by ordering storage transactions as needed to maintain consistency. In various implementations, permissioned and / or permissionless blockchains can be used. In public or permissionless blockchains, anyone can participate without a specific identity. Public blockchains may involve native cryptocurrencies and use consensus based on various protocols such as Proof-of-Work (PoW). On the other hand, permissioned blockchain databases provide secure interaction between a group of entities sharing common goals but not fully trusting each other, such as the exchange of funds, goods, information, etc.

[0033] This application can utilize blockchains that operate on arbitrary, programmable logic, customized as a decentralized storage scheme and referred to as "smart contracts" or "chaincode." In some cases, dedicated chaincode, referred to as system chaincode, can exist for managing functions and parameters. Applications can also utilize smart contracts as trusted distributed applications, leveraging the tamper-proof nature of the blockchain database and the underlying agreements between nodes, known as endorsement or endorsement policies. Blockchain transactions associated with the application can be "endorsed" before being submitted to the blockchain, while unendorsed transactions are ignored. Endorsement policies allow chaincode to specify the endorser of a transaction in the form of the set of peer nodes necessary for endorsement. When a client sends a transaction to the peers specified in the endorsement policy, the transaction is executed to verify it. After verification, the transaction enters a sorting phase, where a consensus protocol is used to produce an ordered sequence of endorsed transactions that are divided into blocks.

[0034] This application can utilize nodes as communication entities in a blockchain system. A "node" can perform logical functions, meaning that multiple nodes of different types can run on the same physical server. Nodes are grouped in trust domains and associated with logical entities that control them in various ways. Nodes can include different types, such as client or commit client nodes, which submit transaction calls to endorsers (e.g., peers) and broadcast transaction proposals to ordering services (e.g., ordering nodes). Another type of node is a peer node, which can receive transactions submitted by clients, submit transactions, and maintain the state and copies of the ledger of blockchain transactions. Peers can also have the role of endorsers, although this is not required. Ordering service nodes or orderers are nodes that run communication services for all nodes and implement delivery guarantees, such as broadcasting to every peer node in the system when a transaction is submitted and the world state of the blockchain is modified, which is another name for the initial blockchain transaction and typically includes control and setup information.

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

[0036] This application can utilize a chain as a transaction log, constructed as hashed linked blocks, with each block containing a sequence of N transactions, where N is equal to or greater than 1. The block header includes the hash of the block's transactions, as well as the hash of the headers of previous blocks. In this way, all transactions on the ledger can be ordered and cryptographically linked together. Therefore, it is impossible to tamper with the ledger data without breaking the hash linking. The hash of the most recently added blockchain block represents every transaction on the chain that arrived before it, ensuring that all peer nodes are in a consistent and trusted state. This chain can be stored on the peer node file system (i.e., local, attached storage, cloud, etc.), thus efficiently supporting the attached-only nature of blockchain workloads.

[0037] The current state of an immutable ledger represents the latest value of all keys included in the chain's transaction log. Because the current state represents the most recent key value known to the channel, it is sometimes referred to as the world state. Chaincode calls execute transactions against the ledger's current state data. To make these chaincode interactions effective, the latest value of the key can be stored in a state database. The state database can simply be an indexed view of the chain's transaction log, and therefore can be regenerated from the chain at any time. The state database can be automatically restored (or generated if needed) when a peer node starts up and before accepting a transaction.

[0038] Some benefits of using SSI membership and identification in blockchain networks include privacy, security, and portability (or interoperability). For example, with SSI, network participants can use a Distributed Identifier (DID) in a specific context at the desired level of exposure. For instance, when a blockchain peer signs a transaction included in a block, it only uses the credentials (or a portion thereof) issued to it for signing the transaction within that network. While the peer's DID may contain various other attributes and affiliations (e.g., the peer may belong to an organization participating in multiple business networks), this information is not exposed during the transaction cycle. Similar to auditors (at a later date), validating peers only examine the VP (Verifiable Representation) of verifiable credentials.

[0039] Furthermore, security can be enhanced, for example, in cross-network interactions where assets or data items are shared between permissioned ledgers. Participants (blockchain peers) possessing SSIs (such as DIDs and VCs) can use a direct process relying on VCs / VPs and SSI networks acting as DID identity and storage providers to authenticate themselves and prove their attributes to external parties (who freely choose their policies), such as centralized entities or participants in different business networks. Additionally, accessibility and interoperability can be improved. Currently, permissioned networks have their own proprietary identity management systems (for credential issuance and storage). This is invisible to parties outside the network. By using SSIs instead of these heterogeneous and opaque identity management systems, example embodiments ensure that network participants are known and can prove their authenticity outside their network, thereby allowing data and assets to flow across network boundaries (in a policy-controlled manner). Furthermore, SSI networks can be built around well-known identity providers or credential authorities that are not tied to a specific network. This makes identities and credentials portable in inter-network interactions.

[0040] In an example embodiment, verifiable credentials can be issued to DID holders (network participants relying on SSI). Verifiable credentials can be issued by issuers (members of the SSI network), which can be existing identity providers and credential authorities within the permissioned network, or well-known external authorities. Within the network, issuers can include network or organizational (sub-partition) CAs. In a superclassified network, these entities are called MSPs (Membership Service Providers), which maintain a chain of root CAs and intermediate CAs. In a Corda network, there is a hierarchy of network CAs, proof portal CAs, which in turn prove node CAs (each node has the ability to sign and approve transactions). These MSPs or CAs represent the network as a whole or sub-parts within the network, and they issue / revoke identities and credentials (such as DIDs) outside the network. Issuers can include external groups, such as rejected CAs and proof authorities like Verisign or DMV. Other issuers can include existing organizations that choose to participate in the permissioned network, special agencies representing alliances of organizations including business networks, such as supply chain, food trust networks, etc. It should also be understood that SSI networks are capable of managing the identities of multiple network participants and facilitating identity sharing across network boundaries.

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

[0042] Each DID file can express cryptographic material, verification methods, or services, providing a set of mechanisms that enable a DID controller to prove control of the DID. Services enable trusted interactions associated with the DID subject. If the DID subject is an informational resource such as a data model, the DID file can contain the DID subject itself. The document can specify a common data model, URL format, and set of operations used for the DID, DID document, and DID method. A DID is a simple text string consisting of three parts: a URI scheme identifier (DID), a DID method identifier, and a DID method-specific identifier. A DID can be resolved into a DID file. A DID URL extends the basic DID syntax to incorporate other standard URI components (path, query, fragment) to locate specific resources, such as public keys within a DID document or resources available outside the DID document.

[0043] DID files contain information related to the DID. They typically express verification methods (e.g., public keys) and services associated with interactions with the DID subject. DID documents can be serialized according to a specific syntax. The DID itself is the value of the id attribute. Attributes existing in the DID file can be updated. A DID method is a mechanism by which specific types of DIDs and their associated DID files are created, parsed, updated, and deactivated using a specific verifiable data registry. DID methods are defined using a separate DID method specification. In example embodiments, DIDs, VCs, VPs, etc., can be stored on a blockchain ledger that includes a verifiable data registry.

[0044] Credential providers (e.g., a DMV issuing a driver's license, a university issuing transcripts, etc.) can issue VCs to the owners of DIDs to establish certain attributes of the owner. In an exemplary embodiment, verifiable credentials can establish attributes of the blockchain entity holding the credential, such as the blockchain entity being an endorsing peer, the blockchain entity being authorized to conduct transactions on a specific ledger, the blockchain entity being authorized to execute / invoke specific chaincode, etc. In short, DIDs have a longer lifespan than VCs (which have an expiration time). Any network component, such as a blockchain peer, sequencer, endorser, client, etc., receives a DID at the start of operation. Subsequently, participants can request and obtain VCs from credential authorities, including the SSI network. Each VC can serve different (and limited) purposes, such as signing transactions included in blocks or signing asset states transacted with different networks. How a VC can be used (using VPs or verifiable representations) can depend on the policy; for example, a transaction commit policy requires endorsing peers to prove their membership in an organization that is part of the network.

[0045] Verifiable credentials and verifiable presentations can be serialized in one or more machine-readable data formats, such as Comma-Separated Values (CSV) files, eXtensible Markup Language (XML) files, JavaScript Object Notation (JSON) files, etc. The process of serialization and / or deserialization can be deterministic, bidirectional, and lossless. Any serialization of a verifiable credential or verifiable presentation can be transformed into a common data model in a deterministic process such that the resulting verifiable credential can be processed in an interoperable manner. The serialized form can also be generated from the data model without loss of data or content. Additionally, a verifiable presentation (VP) can disclose the attributes of a verifiable credential or satisfy an export predicate requested by a verifier. Derived predicates are boolean conditions such as greater than, less than, equal to, in a set, etc.

[0046] In an example embodiment, it can be ensured that a DID is unique only within the domain of the DID provider (or more typically, a registry), rather than globally. If a permissioned network or a permissioned network group decides to trust a single DID registry, peers within that setting will have unique DIDs. Otherwise, a peer's DID can be uniquely resolved globally by the tuple <DID registry, DID>.

[0047] An SSI network includes a DID registry that maintains records indexed by DID values. Additionally, it can maintain the schema (structure) of VCs and verification keys (Hyperledger Indy is an example of such a DID registry built on SSI concepts). A VC can be verified in part by matching its schema with what is stored in the SSI network registry and by using the public key stored in the registry to verify the digital signature of the issuer who issued the VC (the storage can be the distributed ledger itself, but it is not mandatory). However, once trust in the attributes of the DID owner within the VC in a claim is confirmed, it simply depends on whether the confirmer trusts the VC issuer.

[0048] In an exemplary embodiment, the VC itself is not stored in the DID registry of the SSI network. Instead, it is published from the publisher to the owner / holder via peer-to-peer communication and stored by the owner / holder. To verify and authenticate the VC, the 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 is an attribute of the VC and is not stored in the registry itself. However, the fact that a VC is published (or a VC publication event) is recorded in the ledger register. This event carries an automatic timestamp, which can be used for later verification and auditing. Various variations are possible in how the SSI network is configured. In one example, the internal configuration includes an SSI network that overlays existing identity publishers on different networks, such as blockchain networks with credential authorization, MSPs, etc. As another example, the SSI network could be an external network that is completely separate from the blockchain network but loosely coupled to existing identity publishers on different networks.

[0049] Figure 1A A blockchain network 100 using Self-Signing Identity (SSI) is illustrated according to an exemplary embodiment. (Refer to...) Figure 1A The blockchain network 100 includes multiple blockchain peers 110, 120, 130, and 140 that manage the blockchain ledger 150, sorting nodes 150, and clients 102. (See reference...) Figure 4 As further described in the example, when client 102, blockchain peers 110-140, and ordering node 150 register membership with blockchain network 100 (e.g., via authentication, authorization, membership service provider, etc.), client 102, blockchain peers 110-140, and ordering node 150 may receive one or more verifiable credentials. For example, client 102 may receive VC 104, blockchain peers 110, 120, 130, and 140 may receive VC 112, 22, 132, and 142 respectively, and ordering node 152 may receive VC 152.

[0050] Although only one VC is shown in this example, it should be understood that Figure 1A One or more blockchain entities shown can receive multiple VCs, and such VCs can have different lifespans, different uses, different creation times, etc. For example, blockchain peers 110-140 can receive different / separate VCs for each corresponding chaincode they have and can execute / call. As another example, each blockchain peer 110-140 can receive different / separate VCs for each corresponding ledger / channel on the ledger, which they can access / store.

[0051] VCs can be used as credentials for each blockchain entity, indicating that they are authorized to take the actions they are taking. For example, in... Figure 1A In this context, client 102 sends a transaction to blockchain peer 110. Here, client 102's VC 104 can identify client 102 as a member / client of blockchain 105. VC 104 can be signed by the issuer of VC 104, such as a CA, MSP, etc. As another example, blockchain peers 110, 120, 130, and 140's VCs 112, 122, 132, and 142 can identify blockchain peers 110-140 as members of blockchain 105 and have storage rights / chaincode execution capabilities of blockchain 105. Simultaneously, sorting node 150's VC 152 can identify sorting node 150 as the sorter of blocks stored on blockchain 150. Each blockchain entity (client 102, blockchain peers 110-140, and sorting node 150) can attach its respective VC to messages, transactions, suggestions, requests, etc., transmitted internally within network 100, as well as to external entities (not shown).

[0052] Figure 1B This is a diagram illustrating the basic components of a verifiable credential 112 of a blockchain peer 110 according to an exemplary embodiment. (See reference) Figure 1B Verifiable credentials 112 may include machine-readable files, code, documents, etc., in a digital format, including credential metadata 160, one or more claims 170, and one or more certificates 180 associated with the claims 170. Verifiable credentials may include identifiers of the subject / holder, such as the subject / holder's DID, information related to the issuing authority (e.g., CA, MSP, etc.), information about the credential type, information about specific attributes of the credential, information about how the credential was derived, and information about the constraints on the credential (terms of use, expiry terms, etc.). Verifiable credentials may represent the same information as physical credentials, except that it is in a machine-readable format (e.g., JSON, XML, CSV, etc.) rather than a human-readable form.

[0053] Examples of Claim 170 included in verifiable credentials are blockchain peers claiming to be members of a blockchain network and having the ability to store data on the blockchain of that network. Another type of Claim 170 is a blockchain peer claiming access to specific chaincode and the ability to execute transactions from clients based on such chaincode. Yet another type of Claim 170 is a blockchain peer claiming to be a member / participant in a specific channel of the blockchain ledger, etc. Many other claims can be made with verifiable credentials, and each blockchain entity can hold multiple VCs. Furthermore, VCs can be updated to add new claims, modify claims, delete claims, etc., and this can be performed by the issuing entity.

[0054] Metadata 160 may include data describing attributes of the verifiable credential 112, such as the publisher, the format of the verifiable credential (e.g., JSON, XML, CSV, etc.), expiration date / time, an image of the credential, an identifier of the public key to be used for verification, a revocation mechanism, etc. Proof 180 may include a digital signature from the publisher that makes the credential tamper-proof, along with the signature data / time, the purpose of the proof, an identifier of the public key used to verify the signature, etc.

[0055] Figure 1C Further details of the statement 170 and the proof 180 of the verifiable credential 112 according to the example embodiment are shown. Figure 1B The basic components of verifiable credential 112 are shown, while Figure 1C This illustrates a pattern in which verifiable credential 112 stores data. Specifically, claim 170 (with metadata 160) and proof 180 can be stored as separate information graphs. In this example, the first information graph includes a credential ID node 171 interconnected to DID node 172 (the holder's DID), a publisher ID node 173 (the MSP that issued VC 112), a credential type 174 (e.g., the identity of a credential such as a blockchain peer-to-peer VC, ordering node VC, client VC, ledger VC, chaincode VC, etc.), and a timestamp node 175 including the time / date of VC 112's creation. The second information graph includes: a signature ID node 181 containing the signature of the publisher of verifiable credential 112; a signature value node 182 containing the signature content; a 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] Figure 2A A blockchain structure configuration 200 according to an example embodiment is shown. (Reference) Figure 2AThe blockchain architecture 200 may include certain blockchain elements, such as a set of blockchain nodes 202. Blockchain nodes 202 may include one or more nodes 204-210 (these four nodes are described by way of example only). These nodes participate in multiple activities, such as blockchain transaction increment and verification processes (consistency). One or more of the blockchain nodes 204-210 may endorse transactions based on an endorsement policy and may provide ordering services for all blockchain nodes in the architecture 200. A blockchain node may initiate blockchain authentication and attempt to write to the immutable blockchain ledger stored in blockchain layer 216, a copy of which may also be stored on the underlying physical infrastructure 214. The blockchain configuration may include one or more applications 224 linked to an application programming interface (API) 222 to access and execute stored program / application code 220 (e.g., chaincode, smart contracts, etc.), which may be created according to the customized configuration sought by the participants and may maintain its own state, control its own assets, and receive external information. This can be deployed as transactions and installed on all blockchain nodes 204-210 via attachment to the distributed ledger.

[0057] The blockchain infrastructure or platform 212 may include layers of blockchain data and services (e.g., cryptographic trust services, virtual execution environments, etc.), and support physical computer infrastructure that can be used to receive and store new transactions and provide access to auditors attempting to access data entries. The blockchain layer 216 may expose interfaces that provide access to the processor code and the virtual execution environment necessary for participation in the physical infrastructure 214. The cryptographic trust service 218 can be used to verify transactions such as asset exchange transactions and maintain information privacy.

[0058] Figure 2A The blockchain architecture configuration can process and execute program / application code 220 via one or more interfaces exposed by the blockchain platform 212 and the services provided. Code 220 can control blockchain assets. For example, code 220 can store and transmit data and can be executed by node 204, conforming to its execution in the form of smart contracts and associated chaincode with conditional or other code elements. As a non-limiting example, smart contracts can be created to execute alerts, updates, and / or conform to other notifications of changes, updates, etc. Smart contracts themselves can be used to identify authorization and access requirements with the ledger and the rules associated with their use. For example, a smart contract (or chaincode executing the logic of a smart contract) can read blockchain data 226, which can be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 216 to generate results 228 including alerts, liability determination, etc., within complex service scenarios. Physical infrastructure 214 can be used to retrieve any data or information described herein.

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

[0060] Smart contracts can write data to the blockchain in key-value pair format. Furthermore, smart contract code can read values ​​stored in the blockchain and use them in application operations. Smart contract code can write the output of various logical operations to one or more blocks within the blockchain. This code can be used to create temporary data structures in virtual machines or other computing platforms. Data written to the blockchain can be public and / or can be encrypted and maintained as private. Temporary data used / generated by smart contracts is maintained in memory by the supplied execution environment and is then deleted once the data required by the blockchain is identified.

[0061] Chaincode can include a code interpretation (e.g., logic) of a smart contract. For example, chaincode can include a wrapper and deployable version of logic within a smart contract. As described herein, chaincode can be program code deployed on a computing network, where it is executed and verified together by a chain of validators during the consensus process. Chaincode can receive hashes and retrieve hashes from the blockchain associated with a data template created using a previously stored feature extractor. If the hash of the hash identifier matches a hash created from the stored identifier template data, the chaincode sends an authorization key to the requested service. The chaincode can write data associated with cryptographic details to the blockchain.

[0062] Figure 2B An example of a blockchain transaction flow 250 between nodes of a blockchain according to an example embodiment is shown. References Figure 2BThe transaction flow may include client node 260 sending a transaction proposal 291 to endorsing peer node 281. Endorsing peer 281 may verify the client signature and execute chaincode functions to initiate the transaction. Output may include the chaincode result, a set of key / value pairs read from the chaincode (read set), and a set of key / value pairs written to the chaincode (write set). Here, endorsing peer 281 may determine whether to endorse the transaction proposal. If approved, a proposal response 292 is sent back to client 260 along with the endorsement signature. Client 260 assembles the endorsement into a transaction payload 293 and broadcasts it to ordering service node 284. Ordering service node 284 then delivers the ordered transactions as blocks on the channel to all peers 281-283. Each peer 281-283 may verify the transaction before it is committed to the blockchain. For example, a peer may check the endorsement policy to ensure that the correct allocation for the designated peer has been signed and verify the signature against the transaction payload 293.

[0063] Refer again Figure 2B The client node initiates transaction 291 by constructing a request and sending it to peer node 281, which acts as the endorser. Client 260 may include an application utilizing a supporting software development kit (SDK) that leverages available APIs to generate transaction proposals. The proposal requests chaincode functions to read and / or write data to the ledger (i.e., write new key-value pairs for assets). The SDK can be used to encapsulate the transaction proposal into an appropriate architectural format (e.g., a protocol buffer over a remote procedure call (RPC)) and employ the client's cryptographic credentials to generate a unique signature for the transaction proposal.

[0064] In response, endorsing peer node 281 can verify that (a) the transaction proposal is well-formed, (b) the past transaction has not yet been committed (replay attack protection), (c) the signature is valid, and (d) the committer (client 260 in this example) is correctly authorized to perform the proposed operation on the channel. Endorsing peer node 281 can input the transaction proposal as arguments to the invoked chaincode function. The chaincode is then executed against the current state database to produce a transaction result including response values, a set of reads, and a set of writes. However, the ledger is not updated at this time. At 292, this set of values, along with the signature of endorsing peer node 281, is passed back to client 260's SDK as a proposal response 292, which parses the payload to be consumed by the application.

[0065] In response, the application of client 260 checks / verifies the signature of the endorsing peer and compares the proposed response to determine if they are identical. If the chaincode only queries the ledger, the application will check the query response and typically will not commit the transaction to the ordering node service 284. If the client application wants to commit the transaction to the ordering node service 284 to update the ledger, the application determines whether the specified endorsement policy has been satisfied before the commit (i.e., whether all peer nodes necessary for the transaction have signed the transaction). Here, the client may include only one of the many parties to the transaction. In this case, each client may have its own endorser node, and each endorser node will be required to endorse the transaction. This architecture ensures that even if the application chooses not to check the response or otherwise forwards an unprotected transaction, the endorsement policy will still be enforced by the peers and supported during the commit confirmation phase.

[0066] After a successful check, in step 293, client 260 integrates the endorsement into the transaction proposal and broadcasts the transaction proposal and response to sorting node 284 within the transaction message. A transaction may contain a read / write set, endorsement peer signatures, and a channel ID. Sorting node 284 does not need to examine the entire contents of a transaction to execute its operation; instead, it can simply receive transactions from all channels in the network, sort them by channel in chronological order, and create blocks for each channel.

[0067] These blocks are delivered on the channel from sorting node 284 to all peer nodes 281-283. The data portions within the blocks can be verified to ensure the endorsement policy is satisfied and to ensure that there have been no changes to the ledger state of the read set variables since the read set was generated by the transaction execution. Furthermore, in step 295, each peer node 281-283 appends the block to the channel's chain, and for each valid transaction, the write set is committed to the current state database. Events can be emitted to notify clients that the transaction (call) has been immutably appended to the chain, and to indicate whether the transaction is valid or invalid.

[0068] exist Figure 2B In the example, client node 260 and each blockchain peer 281-284 can use verifiable credentials as signatures. When a transaction moves through... Figure 2BAt different steps, each of client node 260 and blockchain peers 281-284 can attach their respective VCs to the steps they have performed. In this example, blockchain peers 281-284 may include a set of VCs that provide identity and membership information associated with blockchain peers 281-284. For example, client node 260 may include verifiable credentials with a claim issued by the MSP of the blockchain network that identifies the client as a member for transactions on the blockchain. As another example, blockchain peers 281-283 may include VCs that identify blockchain peers 281-283 as endorsing peers of the blockchain. Meanwhile, blockchain peer 284 may include VCs that identify blockchain peer 284 as a sorting node of the blockchain. Many other VCs are also possible. For example, a particular channel on the blockchain (e.g., different blockchains on the same ledger) may require different VCs to be used as clients, peers, endorsers, and sorters, etc. As another example, different types of transactions and / or chaincode may require separate VCs provided by clients, peers, etc. For example, if a client has a VC that identifies the client as having permission to use a specific chaincode, the client can simply commit a transaction to invoke that chaincode.

[0069] Figure 3A An example of a permissioned blockchain network 300 is shown, characterized by a distributed, decentralized peer-to-peer architecture. In this example, blockchain user 302 can initiate transactions to a permissioned blockchain 304. In this example, transactions can be deployments, invocations, or queries, and can be issued via client-side applications utilizing the SDK, directly through APIs, etc. The network can provide access to regulators 306, such as auditors. Blockchain network operator 308 manages member permissions, such as registering regulator 306 as an "auditor" and blockchain user 302 as a "client." Auditors can be restricted to querying only the ledger, while clients can be authorized to deploy, invoke, and query certain types of chaincode.

[0070] Blockchain developer 310 can write chaincode and client applications. Blockchain developer 310 can deploy chaincode directly to the network via an interface. To include credentials from traditional data source 312 in the chaincode, developer 310 can use out-of-band connections to access the data. In this example, blockchain user 302 connects to permissioned blockchain 304 via peer node 314. Before any transaction, peer node 314 retrieves the user's registration and transaction credentials from credential authority 316, which manages user roles and permissions. In some cases, blockchain users must possess these digital credentials to conduct transactions on permissioned blockchain 304. Simultaneously, users attempting to utilize the chaincode may need to verify their credentials on traditional data source 312. To confirm user authorization, the chaincode can use an out-of-band connection to that data via a traditional processing platform 318.

[0071] Figure 3B Another example of a permissioned blockchain network 320 is shown, characterized by a distributed, decentralized peer-to-peer architecture. In this example, blockchain user 322 can submit transactions to a permissioned blockchain 324. In this example, transactions can be deployments, invocations, or queries, and can be issued via client-side applications utilizing the SDK, directly through APIs, etc. The network can provide access to regulators 326, such as auditors. Blockchain network operator 328 manages member permissions, such as registering regulator 326 as an "auditor" and blockchain user 322 as a "client." Auditors can be restricted to querying only the ledger, while clients can be authorized to deploy, invoke, and query certain types of chaincode.

[0072] Blockchain developer 330 writes chaincode and client applications. Blockchain developer 330 can deploy the chaincode directly to the network via an interface. To include credentials from the traditional data source 332 in the chaincode, developer 330 can use an out-of-band connection to access the data. In this example, blockchain user 322 connects to the network through peer node 334. Before any transaction, peer node 334 retrieves the user's registration and transaction credentials from the credential authority 336. In some cases, blockchain users must possess these digital credentials to transact on the permissioned blockchain 324. Simultaneously, users attempting to use the chaincode may need to verify their credentials on the traditional data source 332. To confirm user authorization, the chaincode can use an out-of-band connection to that data via a traditional processing platform 338.

[0073] In some implementations, the blockchain described herein can be a permissionless blockchain. In contrast to permissioned blockchains that require permission to join, anyone can join a permissionless blockchain. For example, to join a permissionless blockchain, a user can create a personal address and begin interacting with the network by submitting a transaction and thus adding an entry to the ledger. Additionally, all parties can choose to run nodes on the system and employ mining protocols to help verify transactions.

[0074] Figure 3C A process 350 of a transaction processed by a permissionless blockchain 352 comprising multiple nodes 354 is illustrated. A sender 356 expects to send payment or some other form of value (e.g., contract, medical record, goods, services, or any other asset that can be encapsulated in a digital record) to a receiver 358 via the permissionless blockchain 352. In one embodiment, each of the sender device 356 and the receiver device 358 may have a digital wallet (associated with the blockchain 352) that provides user interface control and displays transaction parameters. In response, the transaction is broadcast to the nodes 354 throughout the blockchain 352. Depending on the network parameters of the blockchain 352, the nodes verify the transaction 360 based on rules established by the creator of the permissionless blockchain 352 (which may be predefined or dynamically allocated). For example, this may include verifying the identities of the parties involved. The transaction may be verified immediately, or it may be queued along with other transactions, and the nodes 354 determine 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 locks (hashes). This process can be performed by nodes among the mining nodes 354. Mining nodes can utilize additional software specifically designed for mining and creating blocks in the permissionless blockchain 352. Each block can 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 a previous block in the chain, and a set of valid transactions. The reference to the hash of the previous block is associated with the creation of a secure, independent blockchain.

[0076] Before blocks can be added to the blockchain, they must be verified. Verification of permissionless blockchains (352) may include proof-of-work (PoW) as a solution to a puzzle derived from the block header. Although in Figure 3C Not shown in the example, but another process used to verify blocks is proof-of-stake. Unlike proof-of-work, where the algorithm rewards miners who solve mathematical problems, proof-of-stake uses the wealth of miners to deterministically select the creator of a new block, also defined as a "stake." A similar proof is then performed by the selected / picked node.

[0077] By mining 364 blocks, nodes attempt to solve the block by incrementally changing a variable until the solution satisfies the network's objective. This creates Proof-of-Work (PoW), ensuring correct responses. In other words, a potential solution must prove that computational resources are exhausted while solving the problem. In some types of permissionless blockchains, miners can be rewarded with value (e.g., coins) for correctly mining blocks.

[0078] This article discusses how the Proof-of-Work (PoW) process makes modifying the blockchain extremely difficult, as an attacker must modify all subsequent blocks to accept a change to a single block. Furthermore, the difficulty of modifying a block increases as new blocks are mined, and the number of subsequent blocks also increases. Successfully verified blocks are distributed via distribution 366 through the permissionless blockchain 352, and all nodes 354 add the block to the majority chain, which is the auditable ledger of the permissionless blockchain 352. Additionally, the value in a transaction committed by sender 356 is stored or otherwise transferred to the digital wallet of recipient device 358.

[0079] Figure 4 A process 400 for issuing verifiable credentials according to an example embodiment is illustrated. (Reference) Figure 4 Multiple organizations share a blockchain ledger 430 (e.g., one or more blockchains, a state database, etc.). Each organization 420 may have one or more peers 422 that perform 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 of the blockchain ledger 430. The SSI network 410 may include multiple identity providers 412 (trusted sources), such as CAs, MSPs, administrators, and other trusted entities. Identity providers 412 may provide DIDs and VCs to peers 422 of peer organizations 420. VCs and DIDs may be stored on a registry 414 of the SSI network. In some embodiments, the registry 414 may be a separate blockchain ledger, but is not limited thereto.

[0080] Registry 414 can store data identified by DIDs. For example, Registry 414 can store records indexed by DID values. Furthermore, Registry 414 can maintain the schema (structure) and verification keys of VCs. A VC can be verified in part by matching its schema against what is stored in Registry 414 and by confirming a digital signature using the public key of the publisher who issued the VC, where the publisher is stored in Registry 414. However, once trust in the attributes of the DID owner within a VC is confirmed in a claim, it simply depends on whether the confirmer trusts the VC publisher. Each blockchain peer 420 may include an SSI agent 424 installed therein. The SSI agent 424 may be an "wallet" for maintaining credentials for its respective component, communicating with a designated SSI network, and additional software for communicating with components belonging to other networks. Some functionalities are blockchain-specific because they involve knowing where their components fit within a given network and understanding how to communicate with external blockchain networks, including SSI networks. Other parts of their functionality are specific to DID management, not blockchain-specific.

[0081] In the example embodiment, a scalable credential (VC) is provided, consisting of a DID, explicit tamper-proof, and verifiable set of claims made by a scalable publisher. A verifiable presentation (VP) can be derived from the VC to present specific credential attributes shared with a particular validator. In some embodiments, the VC may contain data synthesized from the original credential (e.g., zero-knowledge proofs, etc.). Validators can interact with a verifiable data registry to obtain information for verifying the VC. The registry serves as a medium for creating and verifying identities, credential schemas, etc. A DID can be used to identify blockchain network components. In a dedicated blockchain network (Fabric, Corda, etc.), clients and all active components have identities. In Fabric, peers and sorters have identities. In the example embodiment, all identities in the blockchain network are managed by an SSI identity network. The SSI network facilitates the issuance and verification of credentials for all identities participating in the blockchain network. Blockchain network components are mapped to identities managed by the SSI network.

[0082] Identity data (the actual identity network) can be hosted within the same network or an external network. The technology does not need to be blockchain (architecture and operational choices). However, using external options has several advantages. For example, an external network can act as an identity network for multiple networks, serving as a bridge (or intermediary) for inter-network exchange. External networks allow for unified and simplified identity management across organizations(s) or large ecosystems. This identification mechanism allows for a general configuration management mechanism based on the external network. In some embodiments, the organization is represented by an SSI publisher (similar to a CA).

[0083] In the example implementation, publishers provide identities to the network components they manage (peers, etc.), and the network trust model is formed by establishing trust between publishers (organizations). This represents the initial setup of an SSI network. An SSI network can be a dynamic model and allows for changes at any time. Through extension, the identity / VC published by the publisher is trusted by the validator. All network components can act as validators when performing verification functions.

[0084] To perform active component configurations such as configuring a new blockchain peer for a blockchain network, default settings can be used. Here, active components can have their own wallets or similar mechanisms. Each component can be assigned a DID managed by its affiliated organization / publisher. As another example, each component can be assigned initial cryptographic material. Each component can have a connection configuration to the SSI-identified network. During initial setup / launch, the component uses its DID / cryptographic material to obtain its initial VC. Depending on the organization's needs, multiple VCs or VPs can be issued to the component based on the requirements of various ledgers, smart contracts, transactions, etc. Publishers and networks have identity issuance policies—defining which type of credentials must be used to sign TXs / blocks, etc. The component can include an SSI agent that performs identity-related functions based on the policy (obtaining VCs / VPs when needed). This allows for dynamic configuration and updating of credentials used to process TXs, blocks, etc.

[0085] SSI determinism can be challenging. VC / VPs can change over time—expiring, being updated, etc. SSI networks can be updated—revoking lists, etc. For retrospective verification of the ledger, VC / VPs must be distinguishable and identical to those verifiable at the time of TX processing. The state of the VC / VP and the TX condition. Here, the VC / VP may have an expiration timestamp. The TX is the reconciliation timestamp on the network. The network can converge to a single representative timestamp. The TX timestamp must be within an increment that can be configured for a particular network peer. The TX processing mechanism ensures that the timestamp is valid for each VC / VP used in the TX (expiration must be later than the TX—among other validity checks). VC / VPs used during transaction creation are included in the transaction and stored / appended to the header (TX or block). The stored representation can be a verifiable subset (e.g., a specific VP of the VC). Including VC / VPs and timestamps in the ledger allows for retrospective verification regardless of subsequent state changes.

[0086] The state of an SSI network can change over time. To support ledger confirmation, SSI networks can be extended to support retrospective query and confirmation functionality. An SSI network can contain verifiable historical states, such as its own blockchain / ledger (or similar). The SSI network protocol / API can be extended to allow time-bounded verification. Example embodiments may include timestamps as arguments to API functions. Timestamp arguments can be used to retrieve the state of artifacts valid at the represented time. Incremental arguments used in queries can also exist to allow for synchronization gaps between networks.

[0087] Figure 5 A method 500 for performing blockchain transactions using verifiable credentials, according to an example embodiment, is shown. As a non-limiting example, method 500 can be performed by a blockchain peer managing a blockchain ledger, etc. References Figure 5 In 510, the method may include receiving a request for storage at the blockchain network. As an example, the request may include blockchain transactions to be performed, endorsed, committed, etc., to the blockchain. As another example, the request may include multiple transactions to be sorted and stored in blocks to be committed to the blockchain.

[0088] In 520, the method may include attaching a verifiable credential as a signature to a blockchain transaction created by a Sovereign Identity (SSI) network via a blockchain node, wherein the verifiable credential includes a claim to the blockchain node requesting the signature and proof of the SSI network that created the verifiable credential. Here, the blockchain node may execute the blockchain transaction, for example, by simulating one or more parameters of the transaction against the current state of the blockchain to generate a response. The blockchain node may attach a VC to the execution result of the transaction and transmit the execution result and the attached VC to another blockchain peer, client, sorter, etc. In 530, the method may include transmitting the blockchain transaction and the attached verifiable credential to one or more other blockchain nodes. Furthermore, in 540, the method may include storing the blockchain transaction and the attached verifiable credential via data blocks on the blockchain.

[0089] In some embodiments, the verifiable credential may include a decentralized identifier (DID) that uniquely identifies a blockchain node. In some embodiments, the request may include a request to execute chaincode of the blockchain, and the verifiable credential may include a claim that identifies the blockchain node as a blockchain peer authorized to execute 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 an SSI network, wherein the modified verifiable credential includes a 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 to sort multiple blockchain transactions, and the signing includes sorting the multiple blockchain transactions in a new block and signing the new block with a verifiable credential indicating that the blockchain node is the sorting node of the blockchain. In some embodiments, the request may include a request to add a block to a predetermined blockchain ledger, a channel of the ledger, etc., and the verifiable credential stores a statement therein identifying the blockchain node as a blockchain peer authorized to store blocks to a predetermined blockchain ledger, etc. In some embodiments, the request may include a blockchain entry received from a client, and the signature includes an endorsement of the blockchain entry, wherein the verifiable credential identifies the blockchain node as an endorsing peer of the blockchain.

[0091] Figure 6A An example system 600, according to an example embodiment, includes physical infrastructure 610 configured to perform various operations. References Figure 6A Physical infrastructure 610 includes modules 612 and 614. Module 614 includes a blockchain 620 and a smart contract 630 (which may reside on the blockchain 620), which can perform any operational step 608 (in module 612) included in any example embodiment. Step / operation 608 may include one or more embodiments described or depicted, and may represent output or write information written or read from one or more smart contracts 630 and / or blockchain 620. Physical infrastructure 610, module 612, and module 614 may include one or more computers, servers, processors, memory, and / or wireless communication devices. Furthermore, module 612 and module 614 may be the same module.

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

[0093] Figure 6CThe illustration depicts an example system, according to an exemplary embodiment, configured to utilize smart contract configuration between contracting parties and an intermediary server configured to enforce smart contract terms on a blockchain. References Figure 6C Configuration 650 can represent a communication session, asset transfer session, or 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 the smart contract execution can be managed by server 654. The content of smart contract 630 may require digital signature by one or more entities 652 and 656 who are parties to the smart contract transaction. The results of smart contract execution can be written to blockchain 620 as a blockchain transaction. Smart contract 630 resides on blockchain 620, which can reside on one or more computers, servers, processors, memory, and / or wireless communication devices.

[0094] Figure 6D A system 660 including a blockchain, according to an example embodiment, is shown. Reference Figure 6D For example, Application Programming Interface (API) Gateway 662 provides a public interface for accessing blockchain logic (e.g., smart contract 630 or other chaincode) and data (e.g., distributed ledger, etc.). In this example, API Gateway 662 is a public interface for performing 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 allows clients 652 and 656 to query data about the world state and submit transactions to the distributed ledger in the blockchain network, where, depending on smart contract 630 and the endorsement policy, the endorsing peer will run smart contract 630.

[0095] The above embodiments can be implemented in hardware, as a computer program executed by a processor, firmware, or a combination thereof. The computer program can be contained on a computer-readable medium, such as a storage medium. For example, the computer program can 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, hard disks, removable disks, optical disc 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 a processor, enabling the processor to read information from and write information to the storage medium. Alternatively, the storage medium may be integrated with the processor. The processor and storage medium may reside in an application-specific integrated circuit (“ASIC”). Alternatively, the processor and storage medium may reside as discrete components.

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

[0098] The distributed ledger 720 comprises a blockchain storing immutable, ordered records in blocks, and a state database 724 (current world state) maintaining the current state of the blockchain 722. Each channel can have its own distributed ledger 720, and each peer maintains its own copy of the distributed ledger 720 for each channel of its members. The blockchain 722 is a transaction log constructed as hash-linked blocks, where each block contains a sequence of N transactions. Blocks may include, for example... Figure 7B The various components are shown. Block chains can be generated by adding the hash of the previous block header to the current block header. Figure 7A (As indicated by the arrow in the diagram). In this way, all transactions on Blockchain 722 are ordered and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash links. Furthermore, due to the links, the last block in Blockchain 722 represents every transaction that arrived before it. Blockchain 722 can be stored on a peer-to-peer file system (local or attached storage), with the peer-to-peer file system supporting only attached blockchain workloads.

[0099] The current state of blockchain 722 and distributed ledger 722 can be stored in state database 724. Here, the current state data represents the latest values ​​of all keys ever included in the chain transaction log of blockchain 722. Chaincode calls execute transactions against the current state in state database 724. To make these chaincode interactions highly efficient, the latest values ​​of all keys are stored in state database 724. State database 724 can include an indexed view of the transaction log of blockchain 722, and therefore, the indexed view can be regenerated from the chain at any time. State database 724 can be automatically restored (or generated if needed) before accepting a transaction upon peer startup.

[0100] Endorsing nodes receive transactions from clients and endorse them based on the simulation results. The endorsing node holds the smart contract proposing the simulated transaction. When an endorsing node endorses a transaction, it creates a transaction endorsement, a signed response from the endorsing node to the client application instructing the endorsement of the simulated transaction. The method of endorsing a transaction depends on the endorsement policy, which can be specified within the chaincode. An example of an endorsement policy is "most endorsing peers must endorse the transaction." Different channels can have different endorsement policies. The endorsed transaction is forwarded by the client application to the ordering service 710.

[0101] The sorting service 710 accepts endorsed transactions, sorts them into blocks, and delivers these blocks to commit peers. For example, the sorting service 710 can initiate new blocks when a transaction threshold is reached, a timer times out, or another condition is met. Figure 7A In the example, blockchain node 712 is a committing peer that has received a new data block 730 for storage on blockchain 720. The first block in a blockchain can be called the origin block, which includes information about the blockchain, its members, the data stored in it, etc.

[0102] The sorting service 710 can consist of a set of sorters. The sorting service 710 does not handle transactions, smart contracts, or maintain a shared ledger. Instead, the sorting service 710 can accept endorsed transactions and specify the order in which these transactions are submitted to the distributed ledger 720. The architecture of the blockchain network can be designed to make specific implementations of "sorting" (e.g., Solo, Kafka, BFT, etc.) pluggable components.

[0103] Transactions are written to the distributed ledger 720 in a consistent order. This order is established to ensure that updates to the state database 724 are valid when submitted to the network. Unlike cryptocurrency blockchain systems (such as Bitcoin) that use cryptographic puzzles or mining for ordering, in this example, the parties to the distributed ledger 720 can choose the ordering mechanism best suited to the network.

[0104] When the sorting service 710 initializes a new data block 730, the new data block 730 can be broadcast to commit peers (e.g., blockchain nodes 711, 712, and 713). In response, each commit peer verifies the transactions within the new data block 730 by checking to ensure that the read and write sets still match the current world state in the state database 724. Specifically, the commit peers can determine whether the read data present when the endorser simulates the transaction is the same as the current world state in the state database 724. When a commit peer confirms a transaction, the transaction is written to blockchain 722 on the distributed ledger 720, and the state database 724 is updated with the write data from the read and write sets. If the transaction fails, i.e., if the commit peers find that the read and write sets do not match the current world state in the state database 724, the transaction sorted into a block will still be included in that block, but it will be marked as invalid, and the state database 724 will not be updated.

[0105] refer to Figure 7B A new data block 730 (also called a data block) stored on blockchain 722 of the distributed ledger 720 may include multiple data segments, such as a block header 740, block data 750 (the block data portion), and block metadata 760. It should be understood that... Figure 7B The various blocks and their contents shown, such as the new data block 730 and its contents, are merely examples and are not intended to limit the scope of the example embodiments. In a regular block, a data segment can store transaction information for N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) within block data 750.

[0106] The new data block 730 may be included in the block header 740 (e.g., Figure 7A The block header 740 is a link to previous blocks on blockchain 722. Specifically, the block header 740 may include the hash of the previous block header. The block header 740 may also include a unique block number, the hash of the block data 750 of the new data block 730, etc. The block number of the new data block 730 can be unique and assigned in various orders, such as incremental / sequential starting from zero.

[0107] According to various embodiments, block data 750 may store SSI identification information 752, such as verifiable credentials, DIDs, verifiable representations, etc. According to various embodiments, SSI identification information 752 may be stored in the immutable log of blocks on the distributed ledger 720. Some benefits of storing SSI identification information 752 on the blockchain are reflected in the various embodiments disclosed and described herein. Although in Figure 7BThe SSI identification information 752 is depicted in the block data 750, but in other embodiments, the SSI identification information 752 may be located in the block header 740 or the block metadata 760.

[0108] Block metadata 760 can store multiple fields of metadata (e.g., as byte arrays). Metadata fields may include a signature on block creation, a reference to the last configured block, transaction filters identifying valid and invalid transactions within the block, persistent storage of the last offset of the sorting service for sorting blocks, and so on. The signature, last configured block, and sorter metadata can be added by the sorting service 710. Meanwhile, block submitters (such as blockchain node 712) can add validity / invalidity information based on endorsement policies, verification of read / write sets, etc. Transaction filters may include byte arrays of size equal to the number of transactions included in block data 750 and verification codes identifying whether a transaction is valid / invalid.

[0109] Figure 7C An embodiment of a blockchain 770 for digital content according to embodiments described herein is illustrated. Digital content may include one or more files and associated information. Files may include media, images, videos, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable, append-only aspects of the blockchain serve as a security measure to protect the integrity, validity, and authenticity of the digital content, making it suitable for use in legal proceedings where permissive rules are applied or other settings considering the presentation and use of evidence or digital information are of additional interest. In this context, the digital content may be referred to as digital evidence.

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

[0111]

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

[0113]

[0114] exist Figure 7C In an example embodiment, blockchain 770 includes multiple blocks 7781, 7782, ... 778 linked by an ordered sequence cryptography. N Where N≥1. Used to link blocks 7781, 7782, ... 778. N The encryption can be any of multiple keyed or non-keyed hash functions. In one embodiment, blocks 7781, 7782, ... 778... N The input follows a hash function that produces an n-bit alphanumeric output (where n is 256 or another number) from an input based on the information in the block. Examples of such hash functions include, but are not limited to, SHA-type (SHA stands for Secure Hash Algorithm) algorithms, Merkle-Damagard algorithms, HAIFA algorithms, Merkle-tree algorithms, random number-based algorithms, and non-collision-resistant PRF algorithms. In another embodiment, blocks 7781, 7782, ..., 778... N Links can be encrypted using functions other than hash functions. For illustrative purposes, the following description refers to hash functions such as SHA-2.

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

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

[0117] The header 7721 may include one or more initial parameters, which may include, for example, a version number, timestamp, nonce, root information, difficulty level, 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., via blockchain network management software) or manually by blockchain participants. (This is in contrast to other blockchains 7782 to 778...) N Unlike the header of the origin block, the header 7721 of the origin block does not reference the previous block, simply because the previous block does not exist.

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

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

[0120] 1) The hash value of the original file calculated using SHA-2

[0121] 2) Initiate Device ID

[0122] 3) Start timestamp of the original file

[0123] 4) Initial storage location of the original file

[0124] 5) Blockchain network member ID used by the software currently controlling the original file and associated metadata.

[0125] Other blocks 7782 to 778 in the blockchain NIt also has a header, filename, and value. However, unlike the first block 7721, each header in the other blocks is 7722 to 772. N This includes the hash value immediately following the previous block. The hash value of the previous block can be simply the hash of the header of the previous block, or it can be the hash value of the entire previous block. By including the hash value of the previous block in each remaining block, a traceback from the Nth block back to the origin block (and the associated original file) can be performed on a block-by-block basis, as shown by arrow 780, to establish an auditable and immutable chain of custody.

[0126] Each header in the other blocks is 7722 to 772. N It may also include other information such as version number, timestamp, random number, root information, difficulty level, consensus protocol and / or other parameters or information that are typically associated with the relevant file and / or blockchain.

[0127] Files 7742 to 774 in other blocks N It can be equal to the original file, or it can be a modified version of the original file in the origin block, depending on, for example, the type of processing performed. The type of processing performed can vary between blocks. Processing can involve, for example, any modification to the file in a previous block, such as editing information or otherwise changing the contents of the file, removing information from the file, or adding or appending information to the file.

[0128] Additionally or alternatively, processing may involve only 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 actions relative to the file and / or its associated metadata on the blockchain. Processes involving analyzing files may include, for example, appending, including, or associating various analyses, statistics, or other information associated with the file.

[0129] 7762 to 776 in each of the other blocks N The values ​​in a block are unique and all differ due to the processing performed. For example, a value in any given block corresponds to an updated version of a value in a previous block. The update is reflected in the hash of the block to which the value was assigned. Therefore, the value of a block provides an indication of what processing was performed within that 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.

[0130] For example, consider a scenario where a portion of a file in a previous block is edited, fragmented, or pixelated to protect the identity of the person depicted in the file. In this case, the block containing the edited file would include metadata associated with the edited file, such as how the edit was performed, who performed the edit, the timestamp of the edit, etc. The metadata can be hashed to form this value. Because the metadata of this block differs from the information hashed to form the value in the previous block, these values ​​are distinct from each other and can be recovered during decryption.

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

[0132] a) If the file has been processed in any way (e.g., if the file has been edited, copied, modified, accessed, or subjected to some other action), then the new SHA-2 calculated hash value)

[0133] b) New storage location of the file

[0134] c) New metadata associated with the file is identified.

[0135] d) Transferring access to or control of files from one blockchain participant to another.

[0136] Figure 7D An embodiment of a block that can represent the structure of a block in a blockchain 790 according to one embodiment is shown. i (block) i ) Including head 772 i Document 774 i Sum of 776 i .

[0137] Head 772 i Including previous blocks i-1 (block) i-1 The hash value of the block and additional referencing information, which can be any type of information discussed herein (e.g., header information including references, attributes, parameters, etc.). All blocks reference the hash of previous blocks, except for the originating block. The hash value of a previous block can be simply the hash of the header in the previous block, or the hash of all or part of the information in the previous block, including files and metadata.

[0138] Document 774 iThis includes multiple data sets, such as sequential data 1, data 2, ..., data N. Each data set is tagged with metadata 1, metadata 2, ..., metadata N, describing the content and / or characteristics associated with it. For example, the metadata for each data set may include a timestamp indicating the data, information about the data processing, keywords indicating the people or other content depicted in the data, and / or other characteristics that may help establish the validity and content of the document as a whole, and particularly information about its use of digital evidence, such as those described in conjunction with the embodiments discussed below. In addition to the metadata, each data set may be accompanied by references to previous data, REF1, REF2, ..., REF... N-1 To mark it, so as to prevent tampering, gaps, and sequential references through the file.

[0139] Once metadata is assigned to data (e.g., via a smart contract), it cannot be altered unless the hash changes, which could easily be flagged as invalid. Therefore, metadata creates a data log of information that can be accessed and used by participants in the blockchain.

[0140] Value 776 i This refers to a hash value or other value calculated based on any type of information previously discussed. For example, for any given block... i (block) i The value of a block can be updated to reflect the processing performed on that block, such as a new hash value, a new storage location, new metadata for associated files, a transfer of control or access, an identifier, or other actions or information to be added. Although the value in each block is shown as separate from the metadata of the file and header data, in another embodiment, the value may be based partly or entirely on that metadata.

[0141] Once the blockchain 770 is established, at any point in time, the 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 tracing process can begin by decrypting the value of the most currently included block (e.g., the last (Nth) block), and then continue decrypting the values ​​of other blocks until the origin block is reached and the original file is recovered. Decryption can also involve decrypting the header and file structure within each block, as well as the associated metadata.

[0142] Decryption is performed based on the type of encryption that occurs within each block. This can involve the use of private keys, public keys, or public-private key pairs. For example, when using asymmetric encryption, blockchain participants or processors in the network can generate public and private key pairs using a pre-defined algorithm. The public and private keys are associated with each other through some mathematical relationship. The public key can be publicly distributed to be used as an address to receive messages from other users, such as an IP address or home address. The private key is kept secret and 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 confident that only the sender could have sent the message.

[0143] Generating key pairs is similar to creating an account on the blockchain, but it doesn't require actual registration anywhere. Furthermore, every transaction executed on the blockchain is digitally signed by the sender using their private key. This signature ensures that only the account owner can track and process documents on the blockchain (if within the permissions defined by smart contracts).

[0144] Figure 8A and 8B Further examples of blockchain use cases that can be incorporated into and used in this paper are shown. Specifically, Figure 8A Example 800 of a blockchain 810 storing machine learning (artificial intelligence) data is shown. Machine learning relies on large amounts of historical data (or training data) to build predictive models for making accurate predictions on new data. Machine learning software (e.g., neural networks, etc.) can typically sift through millions of records to find non-intuitive patterns.

[0145] exist Figure 8A In the example, host platform 820 builds and deploys machine learning models for predictive monitoring of asset 830. In this paper, host platform 820 can be a cloud platform, industrial server, web server, personal computer, user equipment, etc. Asset 830 can be any type of asset (e.g., machinery or equipment), such as aircraft, locomotives, turbines, medical equipment and devices, oil and gas equipment, ships, vessels, vehicles, etc. As another example, asset 830 can be intangible assets, such as stocks, currency, digital coins, insurance, etc.

[0146] Blockchain 810 can be used to significantly improve both the training process 802 of machine learning models and the prediction process 804 based on the trained machine learning models. For example, in 802, historical data can be stored on blockchain 810 by the asset 830 itself (or via a medium, not shown), instead of requiring data scientists / engineers or other users to collect the data. This significantly reduces the collection time required by the host platform 820 when performing predictive model training. For example, using smart contracts, data can be transferred directly and reliably from its place of origin to blockchain 810. By using blockchain 810 to ensure the security and ownership of the collected data, smart contracts can directly send data from the asset to the individual using the data to build the machine learning model. This allows data to be shared between assets 830.

[0147] The collected data can be stored on Blockchain 810 based on a consensus mechanism. The consensus mechanism pulls in (permissioned nodes) to ensure that 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. In some cases (i.e., supply chains, healthcare, logistics, etc.), adding IoT devices that write directly to the blockchain can increase the frequency and accuracy of the recorded data.

[0148] Furthermore, the machine learning model trained on the collected data can be refined and tested in several rounds by the host platform 820. Each round can be based on additional data or data that was not previously considered to help expand the knowledge of the machine learning model. In 802, the different training and testing steps (and the data associated with them) can be stored on the blockchain 810 by the host platform 820. Each refinement of the machine learning model (e.g., changes to variables, weights, etc.) can be stored on the blockchain 810. This provides verifiable proof of how the model was trained and what data was used to train the model. Additionally, when the host platform 820 has achieved the final trained model, the resulting model can be stored on the blockchain 810.

[0149] After the model has been trained, it can be deployed to a field environment where predictions / decision-making can be made based on the execution of the finally trained machine learning model. For example, in 804, the machine learning model can be used for condition-based maintenance (CBM) of assets such as aircraft, wind turbines, and healthcare machines. In this example, data feedback from asset 830 can be fed into the machine learning model and used to make event predictions, such as failure events, error codes, etc. The determinations made by the machine learning model by executing it at host platform 820 can be stored on blockchain 810 to provide auditable / verifiable proof. As a non-limiting example, the machine learning model can predict the future failure / failure of a portion of asset 830 and create an alert or notification to replace that portion. The data behind this decision can be stored on blockchain 810 by host platform 820. In one embodiment, the features and / or actions described and / or depicted herein can occur on or relative to blockchain 810.

[0150] New transactions on the blockchain can be aggregated into a new block and added to an existing hash. This hash is then encrypted to create a new hash for the new block. As transactions are encrypted, they are added to the next list of transactions, and so on. The result is a series of blocks, each containing the hashes of all previous blocks. The computers storing these blocks periodically compare their hashes to ensure they are consistent. Any computer that disagrees discards the record that caused the problem. This method is beneficial for ensuring the blockchain's tamper-resistance, but it is not perfect.

[0151] One way to manipulate the system is for a dishonest user to change their list of favorite transactions while keeping the hash unchanged. This can be done by brute force, in other words, by altering the record, encrypting the result, and checking if the hashes match. If not, it is repeated until a matching hash is found. The security of blockchain is based on the belief that ordinary computers can only perform such brute-force attacks on completely impractical timescales, such as the age of the universe. In contrast, quantum computers are much faster (1000 times faster), and therefore pose a much greater threat.

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

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

[0154] Blockchain 852 operates based on two processes: (i) the creation of transactions and (ii) the construction of blocks that aggregate new transactions. Creating new transactions can be similar to traditional blockchain networks. Each transaction can contain information about the sender, receiver, creation time, amount (or value) to be transferred, a list of referenced transactions proving the sender has the funds for the operation, etc. This transaction record is then sent to all other nodes, where it is entered into a pool of unconfirmed transactions. Here, the two parties (i.e., the user pair in 854-860) authenticate the transaction by providing their shared key 862 (QKD). This quantum signature can be appended to each transaction, making it extremely difficult to tamper with. Each node checks its local copy of the entries for blockchain 852 to verify that each transaction has sufficient funds. However, the transaction is not yet confirmed.

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

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

[0157] Computer system / server 902 can be described in the general context of executable instructions of a computer system, such as program modules executed by the computer system. Typically, program modules can include routines, programs, objects, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. Computer system / server 902 can be implemented in a distributed cloud computing environment, where tasks are performed by remote processing devices linked via a communication network. In a distributed cloud computing environment, program modules can reside on local and remote computer system storage media, including memory storage devices.

[0158] like Figure 9 As shown, the computer system / server 902 in the cloud computing node 900 is illustrated 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, system memory 906, and buses that couple various system components, including system memory 906, to the processor 904.

[0159] A bus refers to one or more of several types of bus architectures, including memory buses or memory controllers, peripheral buses, accelerated graphics ports, and processor or local buses that use any of the various bus architectures. By way of example and not limitation, these architectures include the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MCA) bus, the Enhanced ISA (EISA) bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0160] Computer system / server 902 typically includes a variety of computer system readable media. Such media can be any available media accessible by computer system / server 902, and it includes volatile and non-volatile media, removable and non-removable media. In one embodiment, system memory 906 implements the flowcharts 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 912. Computer system / server 902 may also 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 and generally referred to as a "hard disk drive"). Although not shown, a disk drive may be provided for reading from and writing to a removable, non-volatile disk (e.g., a "floppy disk"), and an optical disk drive may be provided for reading from or writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM, or other optical media. In this case, each may be connected to a bus via one or more data media interfaces. As will be further described and illustrated below, memory 906 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of various embodiments of this application.

[0161] As an example and not a limitation, a program / utility 916 having a set (at least one) of program modules 918, along with an operating system, one or more applications, other program modules, and program data, may be stored in memory 906. Each of the operating system, one or more applications, other program modules, and program data, or some combination thereof, may include an implementation of a networking environment. Program modules 918 typically perform functions and / or methods of various embodiments of the applications described herein.

[0162] As those skilled in the art will understand, aspects of this application can be implemented as a system, method, or computer program product. Therefore, aspects of this application can take the form of a completely hardware embodiment, a completely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, which can be collectively referred to herein as a “circuit,” “module,” or “system.” Furthermore, aspects of this application can take the form of a computer program product contained in one or more computer-readable media that include computer-readable program code thereon.

[0163] The computer system / server 902 can also communicate with one or more external devices 920, such as a keyboard, pointing device, display 922, etc.; one or more devices that enable a user to interact with the computer system / server 902; and / or any device that enables the computer system / server 902 to communicate with one or more other computing devices (e.g., a network interface card, modem, etc.). This communication can occur via I / O interface 924. Furthermore, the computer system / server 902 can communicate with one or more networks, such as a local area network (LAN), a general area network (WAN), and / or a public network (e.g., the Internet), via network adapter 926. As depicted, 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 can 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, and data archive storage systems.

[0164] Although exemplary embodiments of at least one of the systems, methods, and non-transient computer-readable media are shown in the accompanying drawings and described in the foregoing detailed description, it will be understood that this application is not limited to the disclosed embodiments, but is capable of numerous rearrangements, modifications, and substitutions as set forth and defined in the appended claims. For example, the capabilities of the systems in the various figures may be implemented by one or more of the modules or components described herein or in a distributed architecture, and may include a transmitter, a receiver, or a pair of both. For example, all or part of the functions performed by the various modules may be performed by one or more of these modules. Furthermore, the functions described herein may be performed at various times and may be related to various events, either internal or external to the modules or components. Moreover, information transmitted between the various modules may be transmitted between the modules via at least one of the following: a data network, the Internet, a voice network, an Internet Protocol network, a wireless device, a wired device, and / or via multiple protocols. Moreover, messages sent or received by any module may be sent or received directly and / or via one or more other modules.

[0165] Those skilled in the art will understand that the "system" can be implemented as a personal computer, server, console, personal digital assistant (PDA), cellular phone, tablet computing device, smartphone, or any other suitable computing device, or a combination of devices. Presenting the foregoing functionality as being performed by the "system" is not intended to limit the scope of this application in any way, but rather to provide one example of many embodiments. In fact, the methods, systems, and apparatuses disclosed herein can be implemented in a localized and distributed manner consistent with computing technologies.

[0166] It should be noted that some system features described in this specification have been presented as modules to more specifically emphasize their implementation independence. For example, modules can be implemented as hardware circuits comprising custom VLSI circuitry or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. Modules can also be implemented in programmable hardware devices such as field-programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, etc.

[0167] Modules can also be implemented, at least in part, as software executed by various types of processors. Identifying units of executable code can, for example, include one or more physical or logical blocks of computer instructions, which can be organized, for example, into objects, procedures, or functions. However, the executable code identifying a module does not need to be physically located together, but can include different instructions stored in different locations that, when logically combined, comprise the module and achieve its intended purpose. Furthermore, modules can be stored on a computer-readable medium, which can be, for example, a hard disk drive, a flash memory device, random access memory (RAM), magnetic tape, or any other such medium for storing data.

[0168] In practice, a module of executable code can be a single instruction or multiple instructions, and can even be distributed across several different code segments, between different programs, and across several memory devices. Similarly, operational data can be identified and represented within a module, and can be embodied in any suitable form and organized within any suitable type of data structure. Operational data can be collected as a single dataset, or can be distributed across different locations including different storage devices, and can exist at least in part as electronic signals on a system or network.

[0169] It is readily understood that, as generally described and illustrated in the accompanying drawings, the components of this application can be arranged and designed in a variety of different configurations. Therefore, the detailed description of the embodiments is not intended to limit the scope of the claimed application, but merely represents selected embodiments of the application.

[0170] Those skilled in the art will readily understand that the above content can be practiced with steps in a different order and / or with hardware components configured differently from the disclosed configuration. Therefore, although this application has been described based on these preferred embodiments, certain modifications, variations, and alternative constructions will be apparent to those skilled in the art.

[0171] Although preferred embodiments of this application have been described, it should be understood that the described embodiments are merely illustrative, and the scope of this application is limited only by the appended claims when considering its full range of equivalents and modifications (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. An apparatus comprising: The network interface is configured to receive requests for storage on the blockchain; as well as A processor configured to attach verifiable credentials created by a Sovereign Identity (SSI) network to a blockchain transaction associated with the request via a blockchain node, wherein the verifiable credentials include a claim of the blockchain node and proof of the SSI network that created the verifiable credentials, and to store the blockchain transaction and the attached verifiable credentials via data blocks on the blockchain. The processor is also configured to control the network interface to transmit the blockchain transaction and the attached verifiable credentials to one or more other blockchain nodes.

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

3. The apparatus of claim 1, wherein the request includes a request to execute the blockchain transaction via a smart contract of the blockchain, and the verifiable credential includes a statement therein identifying the blockchain node as a blockchain peer authorized to execute the smart contract.

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

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

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

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 a statement therein identifying the blockchain node as a blockchain peer authorized to store the block to the predefined blockchain ledger.

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. A method comprising: Receive requests for storage on the blockchain; A verifiable credential created by a Sovereign Identity (SSI) network is attached to a blockchain transaction associated with the request via a blockchain node, wherein the verifiable credential includes a claim of the blockchain node and proof of the SSI network that created the verifiable credential. Transmit the blockchain transaction and the attached verifiable credentials to one or more other blockchain nodes; as well as The blockchain transaction and the attached verifiable credentials are stored via data blocks on the blockchain.

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

11. The method of claim 9, wherein the request includes a request to execute the blockchain transaction via a smart contract of the blockchain, and the verifiable credential includes a statement therein identifying the blockchain node as a blockchain peer authorized to execute the smart contract.

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

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 added thereto, a timestamp of when the new claim was created, and an expiration value.

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

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 a statement therein identifying the blockchain node as a blockchain peer authorized to store the block to the predefined blockchain ledger.

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

17. A non-transitory computer-readable medium comprising instructions that, when executed by a processor, cause a computer to perform a method, the method comprising: Receive requests for storage on the blockchain; A verifiable credential created by a Sovereign Identity (SSI) network is attached to a blockchain transaction associated with the request via a blockchain node, wherein the verifiable credential includes a claim of the blockchain node and proof of the SSI network that created the verifiable credential. Transmit the blockchain transaction and the attached verifiable credentials to one or more other blockchain nodes; as well as The blockchain transaction and the attached verifiable credentials are stored via data blocks on the blockchain.

18. The non-transitory computer-readable medium of claim 17, wherein the verifiable credential further comprises a decentralized identifier (DID) that uniquely identifies the blockchain node.

19. The non-transitory computer-readable medium of claim 17, wherein the request includes a request to execute the blockchain transaction via a smart contract of the blockchain, and the verifiable credential includes a statement therein identifying the blockchain node as a blockchain peer authorized to execute the smart contract.

20. The non-transitory computer-readable medium of claim 17, wherein the verifiable credential includes a timestamp of when it was created and an expiration value.

Images