Cross-network identity provisioning method and system

Abstract

An example operation includes one or more of the following: an identity-providing node connects blockchain one to blockchain two; the identity-providing node creates an interoperable identity network (IIN) for blockchain one and blockchain two as an instance of a self-governing identity (SSI) network; and a smart contract is executed to: invoke an IIN access control policy; map the attributes and permissions of blockchain one to the attributes and permissions of blockchain two based on the IIN access control policy; and generate a valid verifiable credential (VC) of the IIN in blockchain one and blockchain two based on the mapped attributes and permissions.

Description

Background Technology

[0001] A centralized database stores and maintains data in a single location (e.g., a database server). This location is typically a central computer, such as a desktop central processing unit (CPU), server CPU, or mainframe computer. Information stored in a centralized database is usually accessible from different points. Multiple users or client workstations can work simultaneously on the centralized database, for example, based on a client / server configuration. Centralized databases are easy to manage, maintain, and control, especially for security purposes, due to their single location. Within a centralized database, 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] From a first aspect, the present invention provides a system including a processor and a memory, wherein the processor is configured to perform one or more of the following: connecting blockchain one to blockchain two, creating an interoperable identity network (IIN) for blockchain one and blockchain two as an instance of a self-sufficient identity (SSI) network, and executing a smart contract to: invoke an IIN access control policy, map attributes and permissions of blockchain one to attributes and permissions of blockchain two based on the IIN access control policy, and generate a valid verifiable credential (VC) of the IIN in blockchain one and blockchain two based on the mapped attributes and permissions.

[0003] Preferably, the present invention provides a system in which the SSI network is configured to store cross-network distributed identifiers (DIDs).

[0004] Preferably, the present invention provides a system in which the SSI network includes an IIN-specific mode that defines the structure of related DID documents.

[0005] Preferably, the present invention provides a system wherein the instructions further cause the processor to execute the smart contract to apply the IIN access control policy to define entities in the blockchain that are allowed to connect to the second blockchain and invoke the functions of the second blockchain.

[0006] Preferably, the present invention provides a system in which the instructions further cause the processor to execute a smart contract to verify the VC of IIN in Blockchain 1 and Blockchain 2 based on the DID of the SSI network.

[0007] Preferably, the present invention provides a system in which the instructions further enable the processor to use IIN to provide cross-network identity for multiple blockchain networks.

[0008] Preferably, the present invention provides a system in which the instructions further cause the processor to execute the smart contract to verify the verifiable identity and permissions against the IIN access control policy.

[0009] From a second aspect, the present invention provides a method comprising one or more of the following: connecting blockchain one to blockchain two by an identity-providing node; creating an interoperable identity network (IIN) for blockchain one and blockchain two as an instance of a self-governing identity (SSI) network by the identity-providing node; executing a smart contract to: invoke an IIN access control policy, mapping attributes and permissions of blockchain one to attributes and permissions of blockchain two based on the IIN access control policy, and generating a valid verifiable credential (VC) of the IIN in blockchain one and blockchain two based on the mapped attributes and permissions.

[0010] Preferably, the present invention provides a method in which an SSI network is configured to store distributed identifiers (DIDs) across the network.

[0011] Preferably, the present invention provides a method in which the SSI network includes an IIN-specific pattern that defines the structure of related DID documents.

[0012] Preferably, the present invention provides a method that further includes executing a smart contract to apply an IIN access control policy to define entities of Blockchain 1 that are allowed to connect to Blockchain 2 and invoke functions of Blockchain 2.

[0013] Preferably, the present invention provides a method that further includes executing a smart contract to verify the VC of the IIN in Blockchain 1 and Blockchain 2 based on the DID of the SSI network.

[0014] Preferably, the present invention provides a method that further includes using IIN to provide cross-network identity for multiple blockchain networks.

[0015] Preferably, the present invention provides a method, the method further comprising: executing a smart contract to verify the verifiable identity and permissions against an IIN access control policy.

[0016] From a third perspective, the present invention provides a non-transitory computer-readable medium including instructions that, when read by a processor, cause the processor to execute: connecting blockchain one to blockchain two; creating an interoperable identity network (IIN) for blockchain one and blockchain two as an instance of a self-sufficient identity (SSI) network; executing a smart contract to: invoke an IIN access control policy; map attributes and permissions of blockchain one to attributes and permissions of blockchain two based on the IIN access control policy; and generate valid verifiable credentials (VCs) for the IIN in blockchain one and blockchain two based on the mapped attributes and permissions.

[0017] Preferably, the present invention provides a non-transitory computer-readable medium wherein the SSI network is configured to store cross-network distributed identifiers (DIDs).

[0018] Preferably, the present invention provides a non-transitory computer-readable medium, further comprising instructions that, when read by a processor, cause the processor to execute a smart contract to apply an IIN access control policy to define entities of blockchain one that are permitted to connect to blockchain two and invoke functions of blockchain two.

[0019] Preferably, the present invention provides a non-transitory computer-readable medium, further comprising instructions that, when read by a processor, cause the processor to execute a smart contract to verify the VC of the IIN in Blockchain 1 and Blockchain 2 based on the DID of the SSI network.

[0020] Preferably, the present invention provides a non-transitory computer-readable medium further comprising instructions that, when read by a processor, cause the processor to use IIN to provide cross-network identity for multiple blockchain networks.

[0021] Preferably, the present invention provides a non-transitory computer-readable medium, further comprising instructions that, when read by a processor, cause the processor to execute a smart contract to verify the verifiable identity and permissions against an IIN access control policy. Attached Figure Description

[0022] Figure 1 A network diagram of a system including a database according to an example embodiment is shown.

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

[0024] Figure 2B The blockchain transaction flow according to various example embodiments is illustrated.

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

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

[0027] Figure 3C An unlicensed network according to an example embodiment is shown.

[0028] Figure 4A A flowchart according to an example embodiment is shown.

[0029] Figure 4B Another flowchart according to an example embodiment is shown.

[0030] Figure 5A An example system configured to perform one or more operations described herein is shown according to an example embodiment.

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

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

[0033] Figure 5D Another example system configured to utilize blockchain, according to an example embodiment, is shown.

[0034] Figure 6A The illustration depicts a process for adding a new block to a distributed ledger according to an example embodiment.

[0035] Figure 6B The contents of a new data block according to an example embodiment are shown.

[0036] Figure 6C A blockchain of digital content is shown according to an example embodiment.

[0037] Figure 6D A block is shown that represents the structure of a block in a blockchain according to an exemplary embodiment.

[0038] Figure 7A An example blockchain for storing machine learning (artificial intelligence) data is shown according to an example embodiment.

[0039] Figure 7B An example quantum-safe blockchain is shown according to an example embodiment.

[0040] Figure 8 An example system supporting one or more example embodiments is shown. Detailed Implementation

[0041] 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.

[0042] 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,” “in some embodiments,” “in 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.

[0043] Additionally, 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. Furthermore, 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.

[0044] Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks for providing cross-network identity provision in a blockchain network.

[0045] In one embodiment, the application utilizes a decentralized database (such as 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 among mutually untrusted parties. These untrusted parties are referred to here 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 a hash chain 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 businesses exchanging funds, goods, information, etc.).

[0046] 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 may exist for management functions and parameters, referred to as system chaincode. Applications can also utilize smart contracts as trusted distributed applications that leverage the tamper-proof nature of the blockchain database and the underlying protocols between nodes, known as endorsement or endorsement policies. Blockchain transactions associated with this application can be "endorsed" before being submitted to the blockchain, while unendorsed transactions are ignored. Endorsement policies allow chaincode to specify endorsers for transactions in the form of a set of peer nodes, which are required 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 transactions enter a sorting phase, where a consensus protocol is used to generate an ordered sequence of endorsed transactions that are divided into blocks.

[0047] 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 submitting client nodes that submit transaction calls to endorsers (e.g., peers) and broadcast transaction suggestions to an ordering service (e.g., ordering nodes). Another type of node is a peer node that receives transactions submitted by clients, submits transactions, and maintains the state and copies of the ledger of blockchain transactions. Peers can also have the role of endorsers, although this is not mandatory. Ordering service nodes or orderers are nodes that run communication services for all nodes and implement delivery guarantees, such as broadcasting to every peer in the system, when a transaction is submitted and the state of the blockchain world is modified. This is another name for the initial blockchain transaction, which typically includes control and setup information.

[0048] 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 submitted 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.

[0049] 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 one. The block header includes the hashes of the block's transactions and the hash of the previous block's header. In this way, all transactions on the ledger can be ordered and cryptographically linked together. Therefore, it is impossible to tamper with the ledger data without breaking the hash 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 a peer node file system (i.e., local, attached storage, cloud, etc.), thus efficiently supporting the attached-only nature of blockchain workloads.

[0050] 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 valid, 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 peer nodes start up and before accepting transactions.

[0051] Some benefits of the solution described and depicted herein include methods and systems for providing cross-network identity in a blockchain network. Exemplary embodiments address time and trust issues by extending database characteristics such as immutability, digital signatures, and single truth values. An exemplary embodiment provides a solution for providing cross-network identity in a blockchain network. The blockchain network can be a homogeneous network based on asset types and rules for managing assets based on smart contracts.

[0052] The difference between blockchain and traditional databases lies in the fact that blockchain is not a centralized store, but a decentralized, immutable, and secure store where nodes must share changes to records in the store. Some properties inherent in blockchain and that help realize it include, but are not limited to, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsement, and accessibility, which are further described in this paper. According to various aspects, the inherent and unique immutability, security, privacy, permissive decentralization, availability of smart contracts, endorsement, and accessibility of blockchain enable a system for providing cross-network identity in blockchain networks. Specifically, blockchain ledger data is immutable and provides an efficient method for providing cross-network identity in blockchain networks. Furthermore, the use of encryption in blockchain provides security and establishes trust. Smart contracts manage the state of assets to complete their lifecycle. Exemplary blockchains are permissioned and decentralized. Therefore, each end user can have their own copy of the ledger for access. Multiple organizations (and peers) can be mounted on the blockchain network. Key organizations can act as endorsing peers to verify the results of smart contract execution, read sets, and write sets. In other words, the inherent characteristics of blockchain provide an efficient implementation of methods for providing cross-network identity in blockchain networks.

[0053] One benefit of the example embodiments is that they improve the functionality of computing systems by implementing methods for providing cross-network identity within a blockchain network. Exemplary embodiments can bridge identity systems across multiple networks. This enhances trust and introduces transparency without sacrificing the privacy and confidentiality of a range of interconnected systems. Through the blockchain system described herein, computing systems can perform the functions of providing cross-network identity within a blockchain network by providing access to capabilities such as distributed ledgers, peer-to-peer mechanisms, cryptography, MSPs, and event processing. Furthermore, blockchain enables the creation of business networks and allows any user or organization to participate. Thus, blockchain is more than just a database. Blockchain has the ability to create business networks of users and board / non-board organizations to collaborate and execute service processes in the form of smart contracts.

[0054] The example implementations offer numerous advantages over traditional databases. For instance, through blockchain, the implementations provide inherent and unique immutable responsibility, security, privacy, permissible decentralization, availability, endorsement, and accessibility of smart contracts.

[0055] Furthermore, traditional databases cannot be used to implement the example embodiments because they do not bring all parties into the business network, do not create trusted collaboration, and do not provide efficient storage for digital assets. Traditional databases do not provide tamper-proof storage and do not provide preservation of the stored digital assets. Therefore, the proposed method for cross-network identity provision in blockchain networks cannot be implemented in traditional databases because cross-network identity provision is based on the creation and use of DIDs (Distributed IDs) for use in blockchain networks. While each blockchain technology framework utilizes databases to store record / transaction data and transaction logs, databases may only provide storage mechanisms. The exemplary embodiments utilize blockchain as a transaction system with the ability to immutably record and uphold elements of transaction / trust ownership of digital assets including fungible assets, as well as to use non-fungible assets to prove identity and define / ownership of assets. Databases are insufficient to implement all of these in the system.

[0056] Furthermore, if traditional databases are used to implement the example implementation, it will suffer from unnecessary drawbacks, such as poor search capabilities, lack of security, and slow transaction speeds. Additionally, automated methods for providing cross-network identity in a blockchain network will be completely impossible.

[0057] Centralized databases have a single point of failure. Specifically, without fault tolerance considerations, if a failure occurs (e.g., hardware, firmware, and / or software failure), all data within the database is lost and all users' work is interrupted. Furthermore, centralized databases are highly dependent on network connectivity. Consequently, the slower the connection, the longer the time required for each database access. Additionally, bottlenecks are possible when a centralized database experiences high traffic due to a single location. Moreover, centralized databases maintain only one copy of the data. As a result, multiple devices cannot access the same data segment simultaneously without creating significant problems or risks of overwriting the stored data. Furthermore, because database storage systems have minimal to no data redundancy, accidentally lost data can be extremely difficult to retrieve except through manual operation from backup storage.

[0058] Therefore, a blockchain-based solution is needed that can serve as an effective tool for providing identity across networks. In blockchains, participant identity is typically based on credentials. However, using credentials in cross-network environments can be difficult and inefficient. Distributing cryptographic materials across networks can be insecure and costly.

[0059] Therefore, the example embodiments provide one or more solutions for use in blockchain networks.

[0060] Example embodiments also change how data can be stored within the block structure of a blockchain. For example, digital asset data can be securely stored in specific portions of a data block (i.e., in the header, data segments, or metadata). By storing digital asset data within data blocks of a blockchain, the digital asset data can be appended to the immutable blockchain ledger via a hash-linked chain of blocks. In some embodiments, a data block can differ from a traditional data block by storing personal data associated with a digital asset outside the blockchain's traditional block structure. By removing personal data associated with digital assets, the blockchain can provide the benefits of anonymity based on immutable responsibility and security.

[0061] According to an exemplary embodiment, a method and system for providing cross-network identity in a blockchain network are provided.

[0062] In cross-network environments, blockchain networks require interoperability for asset and information exchange. This necessitates trusted cross-network operation, which in turn involves cross-network identity and credential sharing. Exemplary embodiments can provide scalable mechanisms for general interoperability, as manual self-organizing sharing is inefficient and difficult to maintain. As mentioned above, distributing cryptographic materials across networks can be difficult and insecure. For users on another network to be trusted, identities, trust trees, attributes, etc., must be available across networks. This may require periodically distributing updates (i.e., new trusted entities, changes, CRLs, etc.). Furthermore, periodic synchronization of files / records is required, which may be impractical in real-world scenarios. Network operators / stakeholders need fine-grained control over the sharing of this information.

[0063] Exemplary embodiments can provide connectivity, i.e., leverage credentials to protect privacy across networks. In one implementation, a Self-Initiated Identity (SSI) model is provided. According to one embodiment, a solution for cross-network identity management based on the (DID) / SSI W3C standard is provided. Key concepts of DID / SSI are as follows:

[0064] DID - Distributed Identifier, Globally Unique Identifier - that is, distinguishable and verifiable based on URN;

[0065] DID infrastructure model - that is, a global key-value pair database composed of all DID blockchains, networks, etc.;

[0066] The value of DID is the document;

[0067] Verifiable Credentials (VC) – Extend the DID by a set of clearly tamper-proof and verifiable claims made by the issuer;

[0068] - Verifiable Presentation (VP) - Exported from VC to present specific credential attributes shared with a specific validator. VP can contain data generated from the original credential (i.e., zero-knowledge proof);

[0069] Verifiable data registry - for the creation and verification of identity, credential patterns, etc.

[0070] Hyperledger Indy is a specific implementation of a proprietary blockchain with a set of wallets and agents that facilitate the exchange of information between VCs and VPs.

[0071] According to an exemplary embodiment, cross-network interoperability using the SSI model can be achieved. A mechanism is provided to integrate DID / SSI mechanisms to provide identity creation and verification within a blockchain network. In the context of a hyperledger structure as an example, it is a novel MSP that allows the use of identity and permissions across multiple networks. The network relationships are implemented as follows.

[0072] Each blockchain network decides who and how to interact with it through interoperability policies. Identity interoperability between network A and a remote network B can be achieved. Network A selects an external entity it trusts to issue credentials (e.g., the entire network B, org_1, or other entities). This includes decisions regarding authorization / access control. Remote clients accessing network A (e.g., clients of network B) act as earlier credential holders. Entities trusted by network A (e.g., org_1 of network B) act as credential issuers to the holders. Network A acts as the credential verifier and determines, through its local consensus protocol, whether to allow remote clients to invoke specific actions. According to an exemplary embodiment, a mechanism facilitating the above interactions is provided. Cross-network identity mechanisms can use an Interoperable Identity Network (IIN) architecture. IINs can use instances of SSI networks to store cross-network DIDs (e.g., Indy, SSI structures, Sovrin, etc.). In W3C standard terminology, an IIN provides a verifiable data area. An IIN can store DIDs used to exchange credentials in cross-network environments. SSI networks may have IIN-specific schemas that describe the structure of the associated DID documents. This pattern can include general definitions of attributes associated with VCs (which are crucial for attribute mapping between networks).

[0073] Multiple blockchains / ledgers / channels can connect to any IIN. IINs can operate as private or public services—for example, as service providers, consortia, or open communities. Ledgers / channels can define IIN access control policies. Policies can define which external entities are allowed to connect to and invoke functions. In other words, policies can define trusted entities as credential issuers. Policies can also define external-to-local attribute / permission mappings. Policies can be stored on the ledger and can be accessible to all peers. Ledgers can connect to any number of IINs. IIN proxy nodes can be used by network / ledger components / peers to interact with the IIN. IIN access control policies define which IINs a proxy can connect to. IIN proxies can have access permissions, can interact directly with the IIN, and can mediate access permissions for other components to the IIN. IIN proxies can retrieve DIDs from or store DIDs in the IIN. IIN proxies can exchange credential information with other proxies as needed (using the IIN). IIN proxies facilitate the flow of VP and VC information required for authentication and authorization.

[0074] An IIN identity provider can be used by peers and other components to provide authentication and authorization. In one embodiment, the IIN identity provider can be implemented as an IIN.MSP in a Hyperledger architecture. The IIN identity provider can use IIN proxies and access control policies to perform authentication and authorization functions. The IIN identity provider can verify identities and grant permissions for policy-verifiable representation. Note that relay components can facilitate message flow across network environments outside of the IIN mechanism.

[0075] For users participating in cross-network messaging, IIN-verifiable credentials (VCs) are issued to them for storage in their local wallets (e.g., in client software wallets). VC issuance can be managed on a per-stakeholder / organization basis (i.e., via CAs in the architecture). VC issuance is managed by IIN issuance policies (specific to each institution). Policies define which identities receive the IIN VC and which attributes are included. Policies define the mapping from local attributes to IIN schema attributes. This issuance can be implemented as an automated and transparent function of the IIN agent. For example, it can be automated by the IIN agent when a network identity is issued to a user (e.g., authenticated by the architecture CA). The institution can also issue a VC along with selected attributes. VCs can also be generated by operators / administrators, etc., at any other time. VCs can be received and used by users.

[0076] According to an exemplary embodiment, verifiable presentation publishing and use can be implemented as a function of an IIN proxy. Before sending a message to a remote network, a user can generate a verifiable presentation for that specific remote network. The user can construct a proof and send it along with the message to the remote network. A verification protocol can be implemented as a function of the IIN proxy. When the network receives a remote message, the proxy can verify the attached proof based on access control policies. The verification protocol can define whether an identity is allowed access to the network, i.e., whether it is published by a trusted publisher. The verification protocol can also define whether an identity has permission to invoke the requested functionality, i.e., mapping attributes to roles / permissions. For example, messages destined for both local and remote networks are signed with local credentials and an added VP-derived proof. Messages can be routed to the remote network by a relay. The remote network uses an IIN identity provider (e.g., IIN.MSP) and an IIN proxy to authenticate and verify authorization based on IIN access control policies.

[0077] According to another exemplary embodiment, a distributed identity management service for blockchain can be provided. A system can be implemented that allows DID / SSI to be integrated as a source of identity and permissions into a cross-network blockchain setup. The required set of components may include an IIN network, IIN agents, IIN policies, and IIN identity providers, which facilitate the creation, exchange, and verification of identities and permissions between blockchain networks. The process of creating a valid DID / SSI-IIN VC in a blockchain network can be implemented as follows: Creation is controlled by an IIN issuance policy. Creation may include a mapping mechanism that includes access control attributes. The process of verifying a DID / SSI-IIN VC in a blockchain network is as follows: Verification is managed by an IIN access control policy. This verification determines the ability to invoke specific smart contract functions. Verification may be based on permissions assigned to the issuer and attributes included in the VC.

[0078] Figure 1 A logical network diagram for providing cross-network identity in a blockchain network is shown according to an example embodiment.

[0079] refer to Figure 1 Example network 100 includes identity-providing node 102. Identity-providing node 102 can connect to blockchain 106 with ledger 108 and to blockchain 107 with ledger 109. The identity-providing node can connect to blockchains 106 and 107 via IIN 105. Although this example describes only one identity-providing node 102 in detail, multiple such nodes can connect to blockchains 106 and 107. It should be understood that identity-providing node 102 may include additional components, and some components described herein may be removed and / or modified without departing from the scope of identity-providing node 102 disclosed herein. Identity-providing node 102 may be a computing device or server computer, etc., and may include processor 104, which may be a semiconductor-based microprocessor, central processing unit (CPU), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), and / or other hardware device. Although a single processor 104 is depicted, it should be understood that identity-providing node 102 may include multiple processors, multiple cores, etc., without departing from the scope of the identity-providing node 102 system. Note that multiple blockchains can be connected via IIN 105.

[0080] Identity providing node 102 may also include a non-transitory computer-readable medium 112 on which machine-readable instructions executable by processor 104 may be stored. Examples of machine-readable instructions are shown on pages 114-118 and discussed further below. Examples of non-transitory computer-readable medium 112 may include electronic, magnetic, optical, or other physical storage devices that contain or store executable instructions. For example, non-transitory computer-readable medium 112 may be random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), hard disk, optical disk, or other types of storage devices.

[0081] Processor 104 can execute machine-readable instructions 114 to connect blockchain one 106 to blockchain two 107. The blockchains can be configured to use one or more smart contracts that manage transactions from multiple participating nodes.

[0082] Processor 104 can execute machine-readable instructions 116 to create an interoperable identity network (IIN) 105 for blockchain 106 and blockchain 207, as an instance of a self-governing identity (SSI) network. Processor 104 can execute machine-readable instructions 118 to execute a smart contract to: invoke the IIN 105 access control policy; map the attributes and permissions of blockchain 106 to the attributes and permissions of blockchain 207 based on the IIN 105 access control policy; and generate valid verifiable credentials (VCs) for IIN 105 in blockchain 106 and blockchain 207 based on the mapped attributes and permissions.

[0083] Figure 2A A blockchain architecture configuration 200 according to an example embodiment is shown. (Reference) Figure 2A The 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 (consensus). One or more of blockchain nodes 204 and 210 may endorse transactions based on an endorsement policy and may provide subscription services to 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 and 210 via attachment to the distributed ledger.

[0084] The blockchain foundation or platform 212 may include layers of blockchain data and services (e.g., cryptographic trust services, virtual execution environments, etc.), and strengthens the 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.

[0085] Figure 2A The blockchain architecture configuration can process and execute program / application code 220 through 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 transfer data and can be executed by nodes 204-210 in the form of smart contracts and conditionally associated chaincode or other code elements subordinate to its execution. As a non-limiting example, smart contracts can be created to execute alerts, updates, and / or other notifications subordinate to changes, updates, etc. The smart contracts themselves can be used to identify authorization and access requirements related to the ledger and the use of associated rules. For example, the attributes and permissions of blockchain one and the attributes and permissions of information 226 in blockchain two can be processed (i.e., mapped) by one or more processing entities (e.g., virtual machines) included in blockchain layer 216. The result 228 can include valid verifiable credentials (VCs) of IINs in blockchain one and blockchain two based on the mapped attributes and permissions.

[0086] Physical infrastructure 214 can be used to retrieve any data or information described herein.

[0087] 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 with the blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of smart contract code, which can be executed in response to the fulfillment of conditions associated with the smart contract. 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.

[0088] 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 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.

[0089] Chaincode can include a code interpretation of a smart contract with additional features. 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. The chaincode receives hashes and retrieves from the blockchain a hash 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 also write data associated with cryptographic details to the blockchain.

[0090] Figure 2B An example of a blockchain transaction flow 250 between nodes of a blockchain according to an example embodiment is shown. (Reference) Figure 2B The transaction flow may include a transaction proposal 291 sent by application client node 260 to endorsing peer node 281. Endorsing peer 281 can verify the client signature and execute the chaincode function to initiate the transaction. The output may include the chaincode result, a set of key / value versions read in the chaincode (read set), and a set of key / value versions written in the chaincode (write set). 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 transaction as a block on the channel to all peers 281-283. Each peer 281-283 can verify the transaction before it is committed to the blockchain. For example, a peer can 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.

[0091] Refer again Figure 2BClient node 260 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 is a request to invoke 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.

[0092] In response, endorsing peer 281 can verify that (a) the transaction proposal is well-formed, (b) the transaction has not been committed in the past (replay attack protection), (c) the signature is valid, and (d) the submitter (client 260 in this example) is correctly authorized to perform the proposed operation on the channel. Endorsing peer 281 can take the transaction proposal as input as arguments to the invoked chaincode function. The chaincode is then executed against the current state database to produce a transaction result including the response value, 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 281, is passed back to client 260's SDK as a proposal response 292, which parses the payload to be consumed by the application.

[0093] In response, client 260's application checks / verifies the endorsed peer's signature and compares the proposed response to determine if they are identical. If the chaincode only queries the ledger, the application checks the query response and typically does not submit the transaction to the ordering node service 284. If the client application wants to submit the transaction to the ordering node service 284 to update the ledger, the application determines whether the specified endorsement policy has been satisfied before submission (i.e., whether all the peers required for the transaction have endorsed it). Here, the client may include only one of the multiple 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 unendorsed transactions, the endorsement policy will still be enforced by the peers and supported during the submission confirmation phase.

[0094] After a successful check, in step 293, client 260 aggregates the endorsements into the transaction and broadcasts the transaction proposal and response to sorting node 284 within the transaction message. The transaction may contain a read / write set, endorser peer signatures, and channel ID. Sorting node 284 does not need to examine the entire contents of the 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 a transaction block for each channel.

[0095] The transaction block is delivered on the channel from sorting node 284 to all peer nodes 281-283. Transactions 294 within the block are verified to ensure that any endorsement policies are met and that the ledger state for the read set variables has not changed since the read set was generated by the transaction execution. Transactions in the block are marked as valid or invalid. 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. An event is emitted to notify the client that the transaction (call) has been immutably appended to the chain, and to indicate whether the transaction is valid or invalid.

[0096] Figure 3A An example of a permissioned blockchain network 300 is illustrated, 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.

[0097] Blockchain developer 310 can write chaincode and client applications. Blockchain developer 310 can deploy chaincode directly to the network via the N 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 the permissioned blockchain 304 via peer node 314. Before any transaction is made, peer node 314 retrieves the user's registration and transaction credentials from the credential authority 316, which manages user roles and permissions. In some cases, blockchain users must possess these digital credentials to transact on the permissioned blockchain 304. Simultaneously, users attempting to utilize the chaincode may need to verify their credentials on the traditional data source 312. To confirm user authorization, the chaincode can use an out-of-band connection to this data via a traditional processing platform 318.

[0098] 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.

[0099] 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 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 via peer node 334. Before any transaction is made, peer node 334 retrieves the user's registration and transaction credentials from credential management 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 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.

[0100] 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 transactions and thus adding entries to the ledger. Additionally, all parties can choose to run nodes on the system and employ mining protocols to help verify transactions.

[0101] Figure 3CThe process 350 of a transaction processed by a permissionless blockchain 352 comprising multiple nodes 354 is illustrated. A sender 356 intends to send payment or some other form of value (e.g., contract, medical record, agreement, 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 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 assigned). For example, this may include verifying the identities of the parties involved. A transaction may be verified immediately, or it may be queued along with other transactions, and nodes 354 may determine whether the transaction is valid based on a set of network rules.

[0102] In structure 362, valid transactions are formed into blocks and sealed with a lock (hash). This process can be performed by nodes in 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 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.

[0103] 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 header of a block. Although in Figure 3C Not shown in the example, but another process used to verify blocks is stub proof. Unlike proof-of-work, where the algorithm rewards miners who solve mathematical problems, stub proof, also defined as "stubs" based on their wealth, is used to deterministically select the creator of a new block. A similar proof is then performed by the selected / picked node.

[0104] By mining 364 blocks, nodes attempt to solve the block by incrementally changing a variable until the solution satisfies the network-wide 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 values ​​(e.g., coins) for correctly mining blocks.

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

[0106] Figure 4A A flowchart 400 illustrates an example method for providing cross-network identity in a blockchain network according to an example embodiment. (Reference) Figure 4A Method 400 may include one or more steps described below.

[0107] Figure 4A The identity-providing node 102 is shown (see Figure 1 The flowchart shows the example method being executed. It should be understood that... Figure 4A The method 400 described herein may include additional operations, and some of the operations described herein may be removed and / or modified without departing from the scope of method 400. For illustrative purposes, reference is also made to... Figure 1 The features described herein are used to describe method 400. Specifically, the processor 104 of the identity providing node 102 can perform some or all of the operations included in method 400.

[0108] refer to Figure 4A In block 412, processor 104 can connect blockchain one to blockchain two. In block 414, processor 104 can create an interoperable identity network (IIN) for blockchain one and blockchain two as an instance of a self-sufficient identity (SSI) network. In block 416, processor 104 can execute a smart contract to: invoke an IIN access control policy; map the attributes and permissions of blockchain one to the attributes and permissions of blockchain two based on the IIN access control policy; and generate valid verifiable credentials (VCs) for the IIN in blockchain one and blockchain two based on the mapped attributes and permissions.

[0109] Figure 4B A flowchart 450 is shown according to an example method based on an example embodiment. (Reference) Figure 4BMethod 450 may further include one or more of the following steps. At box 452, processor 104 executes a smart contract to apply an IIN access control policy to define entities of blockchain 1 that are permitted to connect to blockchain 2 and invoke functions of blockchain 2. At box 454, processor 104 executes a smart contract to verify the VC of the IIN in blockchain 1 and blockchain 2 based on the DID of the SSI network. At box 456, processor 104 may use the IIN to provide cross-network identity for multiple blockchain networks. At box 458, processor 104 executes a smart contract to verify the verifiable identity and permissions against the IIN access control policy. Note that the SSI network may be configured to store cross-network distributed identifiers (DIDs). The SSI network may have an IIN-specific schema that defines the structure of the associated DID documents.

[0110] Figure 5A An example system 500, according to an example embodiment, includes a physical infrastructure 510 configured to perform various operations. References Figure 5A Physical infrastructure 510 includes modules 512 and 514. Module 514 includes a blockchain 520 and a smart contract 530 (which may reside on the blockchain 520), which can perform any operational step 508 (in module 512) included in any example embodiment. Step / operation 508 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 530 and / or blockchain 520. Physical infrastructure 510, module 512, and module 514 may include one or more computing devices, servers, processors, memory, and / or wireless communication devices. Furthermore, module 512 and module 514 may be the same module.

[0111] Figure 5B Other example systems 540 are shown, configured to perform various operations according to example embodiments. References Figure 5B System 540 includes modules 512 and 514. Module 514 includes a blockchain 520 and a smart contract 530 (which may reside on the blockchain 520), which can perform any operational step 508 (in module 512) included in any example embodiment. Step / operation 508 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 530 and / or blockchain 520. Modules 512 and 514 may include one or more computers, servers, processors, memory, and / or wireless communication devices. Furthermore, modules 512 and 514 may be the same module.

[0112] Figure 5CThe 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 5C Configuration 550 can represent a communication session, asset transfer session, or process or procedure driven by a smart contract 530 that explicitly identifies one or more user devices 552 and / or 556. The execution, operation, and results of the smart contract execution can be managed by server 554. The content of smart contract 530 may require digital signature by one or more entities 552 and 556 who are parties to the smart contract transaction. The result of smart contract execution can be written to blockchain 520 as a blockchain transaction. Smart contract 530 resides on blockchain 520, and it can reside on one or more computers, servers, processors, memory, and / or wireless communication devices.

[0113] Figure 5D A system 560 including a blockchain is shown according to an example embodiment. (Refer to...) Figure 5D For example, Application Programming Interface (API) Gateway 562 provides a public interface for accessing blockchain logic (e.g., smart contract 530 or other chaincode) and data (e.g., distributed ledger, etc.). In this example, API Gateway 562 is a public interface for executing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 552 and 556 to a blockchain peer (i.e., server 554). Here, server 554 is a peer component of the blockchain network that holds a copy of the world state and a distributed ledger that allows clients 552 and 556 to query data about the world state and submit transactions to the blockchain network, where, depending on smart contract 530 and the endorsement policy, the endorsing peer will run smart contract 530.

[0114] 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.

[0115] 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.

[0116] Figure 6A The illustration shows a process 600 in which a new block is added to a distributed ledger 620 according to an example embodiment, and Figure 6B The illustration shows the contents of a new data block structure 630 for a blockchain according to an example embodiment. The new data block structure 630 may include a mapping of attributes and permissions for blockchains one and two. (Refer to...) Figure 6A A client (not shown) may submit transactions to blockchain nodes 611, 612, and / or 613. The client can be an instruction received from any source to formulate an activity on blockchain 620. As an example, the client may be acting on behalf of a requester (e.g., a device, person, or entity) to propose an application of a transaction to the blockchain. Multiple blockchain peers (e.g., blockchain nodes 611, 612, and 613) may maintain the state of the blockchain network and a copy of the distributed ledger 620. Different types of blockchain nodes / peers may exist in the blockchain network, including peers that endorse and endorse transactions proposed by clients, and peers that verify endorsements, confirm transactions, and submit transactions to the distributed ledger 620. In this example, blockchain nodes 611, 612, and 613 may act as endorser nodes, submitter nodes, or both.

[0117] The distributed ledger 620 comprises a blockchain storing immutable, ordered records in blocks, and a state database 624 (current world state) maintaining the current state of the blockchain 622. Each channel can have its own distributed ledger 620, and each peer maintains its own copy of the distributed ledger 620 for each channel to which it is a member. The blockchain 622 is a transaction log constructed as hashed, linked blocks, where each block contains a sequence of N transactions. Blocks can contain various components, such as... Figure 6B As shown, the links between each block (such as...) Figure 6A (As indicated by the arrow in the diagram) can be generated by adding the hash of the previous block header to the current block header. In this way, all transactions on blockchain 622 are ordered and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash link. Furthermore, due to the linking, the latest block in blockchain 622 represents every transaction that arrived before it. Blockchain 622 can be stored on a peer-to-peer file system (local or attached storage) that supports only attaching blockchain workloads.

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

[0119] The endorsing node receives transactions from clients and endorses them based on the simulation results. The endorsing node holds a smart contract representing the simulated transaction proposal. 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 610.

[0120] The ordering service 610 accepts endorsed transactions, orders them into blocks, and delivers the blocks to the submitting peers. For example, the ordering service 610 can initiate a new block when a transaction threshold is reached, a timer times out, or other conditions are met. Figure 6A In the example, blockchain node 612 is a submitting peer that has received a new data block 630 for storage on blockchain 620. 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.

[0121] Ordering service 610 can be part of a cluster of orderers. Ordering service 610 does not process transactions, smart contracts, or maintain a shared ledger. Instead, ordering service 610 can accept endorsed transactions and specify the order in which these transactions are submitted to the distributed ledger 620. The architecture of the blockchain network can be designed to allow specific implementations of the "ordering" mechanism (e.g., Solo, Kafka, BFT, etc.) to become pluggable components.

[0122] Transactions are written to the distributed ledger 620 in a consistent order. This order ensures that transactions are valid when updates to the state database 624 are submitted to the network. Unlike cryptocurrency blockchain systems that sort transactions through solving cryptographic puzzles or mining (such as Bitcoin), in this example, the parties to the distributed ledger 620 can choose the sorting mechanism best suited to the network.

[0123] When the sorting service 610 initializes a new data block 630, the new data block 630 can be broadcast to submitting peers (e.g., blockchain nodes 611, 612, and 613). In response, each submitting peer confirms the transactions within the new data block 630 by checking to ensure that the read and write sets still match the current world state in the state database 624. Specifically, the submitting 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 624. When a submitting peer confirms a transaction, the transaction is written to blockchain 622 on the distributed ledger 620, and the state database 624 is updated with the write data from the read and write sets. If a transaction fails, i.e., if the submitting peers find that the read and write sets do not match the current world state in the state database 624, the transaction sorted into a block will still be included in that block, but it will be marked as invalid, and the state database 624 will not be updated.

[0124] refer to Figure 6B A new data block 630 (also referred to as a data block) stored on blockchain 622 of the distributed ledger 620 may include multiple data segments, such as a block header 640, block data 650, and block metadata 660. It should be understood that various blocks and their contents are shown, such as the new data block 630 and its contents. Figure 6B The examples shown are merely illustrative and are not intended to limit the scope of the exemplary embodiments. New data block 630 may store transaction information for N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) within block data 650. New data block 630 may also include information from the block header 640 (e.g., ...). Figure 6A The block header 640 is a link to previous blocks on blockchain 622. Specifically, the block header 640 may include a hash of the previous block header. The block header 640 may also include a unique block number, a hash of the block data 650 of the new data block 630, etc. The block number of the new data block 630 may be unique and assigned in various orders, such as incremental / sequential order starting from zero.

[0125] Block data 650 can store transaction information for each transaction recorded in the new data block 630. For example, transaction data may include transaction type, version, timestamp, channel ID of the distributed ledger 620, transaction ID, period, payload visibility, chaincode path (deployment tx), chaincode name, chaincode version, inputs (chaincode and functions), client (creator) identifiers such as public keys and credentials, client signature, endorser identifier, endorser signature, suggestion hash, chaincode event, response status, namespace, read set (a list of keys and versions read by the transaction, etc.), write set (a list of keys and values, etc.), start key, end key, list of keys, Markov tree query digest, etc. Transaction data can be stored for each of N transactions.

[0126] In some embodiments, block data 650 may also store new data 662, which adds additional information to the chain of hash links of blocks in blockchain 622. The additional information includes one or more of the steps, features, processes, and / or actions described or depicted herein. Therefore, new data 662 may be stored in the immutable log of blocks on the distributed ledger 620. Some of the benefits of storing this new data 662 are reflected in the various embodiments disclosed and depicted herein. Although in Figure 6B In this context, new data 662 is depicted in block data 650, but it can also be located in the block header 640 or block metadata 660. New data 662 may include a mapping of attributes and permissions for blockchains one and two.

[0127] Block metadata 660 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 a sorting service for sorting blocks, and so on. The signature, last configured block, and orderer metadata can be added by the ordering service 610. Simultaneously, the block submitter (such as blockchain node 612) 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 in block data 650 and verification codes identifying whether a transaction is valid or invalid.

[0128] Figure 6CAn embodiment of a blockchain 670 for digital content is illustrated according to embodiments described herein. 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 or other settings for considering evidence are applied, or where the presentation and use of the digital information are of additional interest. In this context, the digital content may be referred to as digital evidence.

[0129] 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 referencing information along with its 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 the previous block.

[0130] This can be explained as follows:

[0131] Block 1 Block 2 ... Block N

[0132] Hash value 1, hash value 2, ..., hash value N

[0133] Digital content 1, digital content 2, ..., digital content N

[0134] In one embodiment, digital content may not be included in the blockchain. For example, the blockchain could store a 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:

[0135] Blockchain storage area

[0136] Block 1 hash value Block 1 hash value... content

[0137] Block N hash value Block N hash value... content

[0138] exist Figure 6CIn an example embodiment, blockchain 670 includes multiple blocks 6781, 6782, ... 678 linked by an ordered sequence cryptography. N Where N≥1. Used to link blocks 6781, 6782, ... 678 N The encryption can be any of multiple keyed or non-keyed hash functions. In one embodiment, blocks 6781, 6782, ... 678... N The input is subjected to a hash function that produces an n-bit alphanumeric output (where n is 256 or another number) based on 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 6781, 6782, ..., 678... N Links can be encrypted using functions other than hash functions. For illustrative purposes, the following description is based on hash functions such as SHA-2.

[0139] Blocks 6781, 6782, ..., 678 in the blockchain N Each of these includes a header, a file version, and a value. As a result of 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 may be the original file or a different version of the original file.

[0140] The first block of the blockchain, 6781, is called the origin block and includes a header 6721, the original file 6741, and an initial value 6761. The hashing scheme used for the origin block, and indeed in all subsequent blocks, can vary. For example, all the information in the first block 6781 can be hashed together and at once, or each or part of the information in the first block 6781 can be hashed separately, and then the hash of the separately hashed parts can be performed.

[0141] The header 6721 may include one or more initial parameters, which may include, for example, a version number, timestamp, current value, root information, difficulty level, consensus protocol, duration, media format, source, descriptive keywords, and / or other information associated with the original file 6741 and / or the blockchain. The header 6721 may be generated automatically (e.g., via blockchain network management software) or manually by blockchain participants. This is related to other blocks 6782 to 678 in the blockchain. N Unlike the header of the source block, the header 6721 of the source block does not reference the previous block, simply because there is no previous block.

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

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

[0144] 1) The hash value of the original file calculated by SHA-2

[0145] 2) Initiate Device ID

[0146] 3) Start timestamp of the original file

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

[0148] 5) Blockchain network member IDs used for the software to simultaneously control the original files and associated metadata.

[0149] Other blocks 6782 to 678 of the blockchain N It also has a header, filename, and value. However, unlike the first block 6721, the headers 6722 to 672... N Each other block in the sequence includes the hash of the preceding block. The hash of the preceding block can be simply the hash of the header of the preceding block, or it can be the hash of the entire preceding block. By including the hash of the preceding block in each remaining block, a block-by-block tracing back from the Nth block to the originating block (and the associated original file) can be performed, as shown by arrow 680, to establish an auditable and immutable chain of custody.

[0150] Each title is 6722 to 672. N Other blocks may also include other information such as version number, timestamp, random number, root information, difficulty level, consensus protocol and / or other parameters or information typically associated with the corresponding file and / or blockchain.

[0151] Files 6742 to 674 in other blocks NIt 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 the 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.

[0152] Additionally or alternatively, processing may involve only copying files from previous blocks, changing the storage location of files, analyzing files from one or more previous blocks, moving files from one storage or memory location to another, or performing actions relative to files and / or their associated metadata on the blockchain. Processes involving file analysis may include, for example, appending, including, or associating various analyses, statistics, or other information associated with the file.

[0153] In other blocks 6762 to 676 N The value in each block is unique and distinct due to the processing performed. For example, the value in any given block corresponds to an updated version of the value in a previous block. This 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 for tracing back through the blockchain to the original file. This tracing confirms the chain of custody for the file throughout the blockchain.

[0154] 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 editing was performed, who performed the editing, the timestamp of the editing, 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, the values ​​are distinct and can be recovered during decryption.

[0155] 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.

[0156] 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), the new SHA-2 hash value is calculated.

[0157] b) New storage location of the file

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

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

[0160] Figure 6D An embodiment of a block, representing the structure of a block in blockchain 690, is shown according to one embodiment. Block i Block i Including the first 672 i Document 674 i Sum of 676 i .

[0161] First volume 672 i Including previous blocks i-1 The hash value 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 the previous block, except for the originating block. The hash value of the 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.

[0162] Document 674 i This 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 To mark it, so as to prevent tampering, gaps, and sequential references through the file.

[0163] Once metadata is assigned to data (e.g., via a smart contract), it cannot be altered without changing the hash, 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.

[0164] Value 676 i It is a hash value or other value calculated based on any type of information discussed earlier. For example, for any given block... iThe value of the 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 the associated file, 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.

[0165] Once the blockchain (670) is established, at any point in time, the immutable custodian chain of the document can be obtained by querying the blockchain to trace the transaction history across blocks. This query or tracing process can begin by decrypting the most currently included block (e.g., the last (N) block). th The decryption process begins by decrypting the value of the first block, then continues decrypting the values ​​of other blocks until the origin block is reached and the original file is recovered. Decryption may also involve decrypting the header and filename of each block, as well as the associated metadata.

[0166] 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.

[0167] 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 the blockchain's documents (if within the permissions defined by smart contracts).

[0168] Figure 7A and 7B Further examples of blockchain use cases that can be combined and utilized in this paper are shown. Specifically, Figure 7A Example 700 of a blockchain 710 for 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.

[0169] exist Figure 7AIn the example, host platform 720 builds and deploys machine learning models for predictive monitoring of asset 730. Here, host platform 720 can be a cloud platform, industrial server, web server, personal computer, user equipment, etc. Asset 730 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 730 can be intangible assets, such as stocks, currency, digital coins, insurance, etc.

[0170] Blockchain 710 can be used to significantly improve the training process 702 of machine learning models and the prediction process 704 based on the trained machine learning models. For example, in 702, historical data TA can be stored on blockchain 710 by asset 730 itself (or through 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 host platform 720 when performing predictive model training. For example, using smart contracts, data can be directly and reliably transferred from its place of origin to blockchain 710. By using blockchain 710 to ensure the security and ownership of the collected data, smart contracts can directly send data from assets to individuals who use the data to build machine learning models. This allows data to be shared between assets 730.

[0171] The collected data can be stored on Blockchain 710 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 timestamped, 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.

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

[0173] 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 704, 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 730 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 720 can be stored on blockchain 710 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 730 and create an alert or notification to replace that portion. The data behind this decision can be stored on blockchain 710 by host platform 720. In one embodiment, the features and / or actions described and / or depicted herein can occur on or relative to blockchain 710.

[0174] New transactions for the blockchain can be aggregated into a new block and added to an existing hash value. This is then encrypted to create a new hash for the new block. As a transaction is encrypted, it is added to the next list of transactions, and so on. The result is a series of blocks, each containing the hash values ​​of all previous blocks. The computers storing these blocks periodically compare their hash values ​​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.

[0175] One way to play this system is for dishonest users to change their list of favorite transactions while keeping the hash unchanged. This can be done with brute force—in other words, by altering the record, encrypting the result, and checking if the hash values ​​are the same. If not, it's 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.

[0176] Figure 7B An example 750 of a quantum-secure blockchain 752 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 photons, such as photons, to send information; an eavesdropper cannot copy the quantum particle without destroying it. In this way, senders and receivers can be certain of each other's identities through the blockchain.

[0177] exist Figure 7BIn the example, there are four users: 754, 756, 758, and 760. Each pair of users can share a secret key 762 (i.e., QKD) among themselves. Since there are four nodes in this instance, there are six pairs of nodes, and therefore six different keys 762 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.

[0178] Blockchain 752 operates based on two processes: (i) the creation of transactions and (ii) the construction of blocks that aggregate new transactions. New transactions can be created similarly to those in 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. The 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., a pair of users from 754-760) authenticate the transaction by providing their shared secret key 762 (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 752 to verify that each transaction has sufficient funds. However, the transaction is not yet confirmed.

[0179] 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 transactions. For example, each node can possess a private value (the transaction data of 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 the previous round. Here, honest nodes are able to create a complete set of transactions within the new block. This new block can be added to blockchain 752. In one embodiment, the features and / or actions described and / or depicted herein can occur on or relative to blockchain 752.

[0180] Figure 8Example system 800 supporting one or more of the exemplary embodiments described and / or depicted herein is illustrated. System 800 includes computer system / server 802, which can operate with a number of 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 802 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.

[0181] Computer system / server 802 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 802 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 in local and remote computer system storage media, including memory storage devices.

[0182] like Figure 8 As shown, the computer system / server 802 in the cloud computing node 800 is illustrated in the form of a general-purpose computing device. Components of the computer system / server 802 may include, but are not limited to, one or more processors or processing units 804, system memory 806, and buses that couple various system components, including system memory 806, to the processor 804.

[0183] A bus represents 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.

[0184] Computer system / server 802 typically includes a variety of computer system readable media. Such media can be any available media accessible by computer system / server 802, and it includes volatile and non-volatile media, removable and non-removable media. In one embodiment, system memory 806 implements the flowcharts of other figures. System memory 806 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 810 and / or cache memory 812. Computer system / server 802 may also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 814 may be provided for reading from and writing to a non-removable, non-volatile magnetic medium (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 configuration, each can be connected to the bus via one or more data media interfaces. As will be further described and illustrated below, memory 806 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.

[0185] By way of example and not limitation, a program / utility 816 having a set (at least one) of program modules 818, along with an operating system, one or more applications, other program modules, and program data, may be stored in memory 806. 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 818 typically perform the functions and / or methods of various embodiments of the applications described herein.

[0186] 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.

[0187] The computer system / server 802 may also communicate with one or more external devices 820, such as a keyboard, pointing device, display 822, etc.; one or more devices that enable a user to interact with the computer system / server 802; and / or any device that enables the computer system / server 802 to communicate with one or more other computing devices (e.g., network interface card, modem, etc.). This communication may occur via I / O interface 824. Furthermore, the computer system / server 802 may communicate with one or more networks via network adapter 826, such as a local area network (LAN), a general area network (WAN), and / or a public network (e.g., the Internet). As described, network adapter 826 communicates with other components of the computer system / server 802 via a bus. It should be understood that, although not shown, other hardware and / or software components may be used in conjunction with the computer system / server 802. 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.

[0188] 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.

[0189] 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.

[0190] 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.

[0191] 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.

[0192] 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 it 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.

[0193] 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.

[0194] 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.

[0195] 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. A system for providing identity across networks, comprising: processor; Memory, on which machine-readable instructions are stored, which, when executed by the processor, cause the processor to: Connect blockchain 1 to blockchain 2; Create an interoperable identity network (IIN) for blockchain one and blockchain two as an instance of a self-sufficient identity (SSI) network; Executing smart contracts to: Invoke the IIN access control policy; Based on the IIN access control policy, the attributes and permissions of Blockchain 1 are mapped to the attributes and permissions of Blockchain 2. Based on the mapped attributes and permissions, generate valid and verifiable credentials for the IIN in Blockchain 1 and Blockchain 2. as well as The valid and verifiable credentials of the IIN in Blockchain 1 and Blockchain 2 are verified based on the cross-network distributed identifier (DID) of the SSI network.

2. The system of claim 1, wherein the SSI network is configured to store cross-network distributed identifiers (DIDs).

3. The system of claim 1, wherein the SSI network includes an IIN-specific pattern that defines the structure of the associated DID documents.

4. The system of claim 1, wherein, The instructions also cause the processor to execute the smart contract to apply the IIN access control policy to define entities of Blockchain 1 that are allowed to connect to Blockchain 2 and invoke the functions of Blockchain 2.

5. The system of claim 1, wherein, The instructions also enable the processor to use the IIN to provide cross-network identity for multiple blockchain networks.

6. The system according to claim 1, wherein, The instructions also cause the processor to execute the smart contract to verify the verifiable identity and permissions against the IIN access control policy.

7. A method for providing identity across networks, comprising: The identity-providing node connects blockchain one to blockchain two; An interoperable identity network (IIN) for blockchain one and blockchain two is created by the identity-providing node as an instance of a self-sufficient identity (SSI) network; The identity-providing node executes the smart contract to: Invoke the IIN access control policy; Based on the IIN access control policy, the attributes and permissions of Blockchain 1 are mapped to the attributes and permissions of Blockchain 2. Based on the mapped attributes and permissions, generate valid and verifiable credentials for the IIN in Blockchain 1 and Blockchain 2. as well as The valid and verifiable credentials of the IIN in Blockchain 1 and Blockchain 2 are verified based on the cross-network distributed identifier (DID) of the SSI network.

8. The method of claim 7, wherein the SSI network is configured to store cross-network distributed identifiers (DIDs).

9. The method of claim 7, wherein the SSI network includes an IIN-specific pattern that defines the structure of the associated DID documents.

10. The method of claim 7, further comprising having the identity-providing node execute the smart contract to apply the IIN access control policy to define entities of blockchain 1 that are permitted to connect to blockchain 2 and invoke functions of blockchain 2.

11. The method of claim 7, further comprising having the identity providing node use the IIN to provide cross-network identity for multiple blockchain networks.

12. The method of claim 7, further comprising having the identity-providing node execute the smart contract to verify the verifiable identity and permissions against the IIN access control policy.

13. A computer program product comprising instructions that, when read by a processor, cause the processor to execute: Connect blockchain 1 to blockchain 2; Create an interoperable identity network (IIN) for blockchain one and blockchain two as an instance of a self-sufficient identity (SSI) network; Executing smart contracts to: Invoke the IIN access control policy; Based on the IIN access control policy, the attributes and permissions of Blockchain 1 are mapped to the attributes and permissions of Blockchain 2. Based on the mapped attributes and permissions, generate valid and verifiable credentials for the IIN in Blockchain 1 and Blockchain 2. as well as The valid and verifiable credentials of the IIN in Blockchain 1 and Blockchain 2 are verified based on the cross-network distributed identifier (DID) of the SSI network.

14. The computer program product of claim 13, wherein the SSI network is configured to store cross-network distributed identifiers (DIDs).

15. The computer program product of claim 13, further comprising instructions that, when read by the processor, cause the processor to execute the smart contract to apply the IIN access control policy to define entities of blockchain one that are permitted to connect to blockchain two and invoke the functions of blockchain two.

16. The computer program product of claim 13, further comprising instructions that, when read by the processor, cause the processor to use the IIN to provide cross-network identity for multiple blockchain networks.

17. The computer program product of claim 13, further comprising instructions that, when read by the processor, cause the processor to execute the smart contract to verify the verifiable identity and authorization against the IIN access control policy.

Images