Anonymization of partners

Abstract

Example operations may include one or more of the following: generating, by a processor node, an identifier (ID) of an asset producer node; mapping, by the processor node, the ID to an identity of the asset producer node; receiving, by the processor node, a request from a supplier node among a plurality of supplier nodes to add the asset producer node to a supply blockchain; and providing rights to the plurality of supplier nodes based on the mapped ID.

Description

Technical Field

[0001] The present application relates generally to supply chain systems and more particularly to anonymization of partners. Background Art

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

[0003] However, the disadvantages of centralized databases are significant. For example, centralized databases have a single point of failure. Specifically, if a failure occurs due to lack of fault tolerance considerations (e.g., hardware, firmware and / or software failures), all data within the database will be lost and the work of all users will be interrupted. In addition, centralized databases are highly dependent on network connectivity. Therefore, the slower the connection speed, the amount of time required for each database access will increase. Another disadvantage is that bottlenecks occur when the centralized database experiences high traffic due to a single location. In addition, centralized databases provide limited access to data because the database only maintains one copy of the data. Therefore, it is impossible for multiple devices to access the same piece of data at the same time without generating major problems or risks of rewriting the stored data. In addition, because the database storage system has minimal or even no data redundancy, it is very difficult to retrieve accidentally lost data unless it is retrieved from backup storage through manual operation.

[0004] In a supply chain management system, Tier 3 members (i.e., growers) supply to multiple Tier 2 partners (i.e., suppliers), which in turn supply to Tier 1 partners (i.e., retailers). Retailers need to be able to view traceability events from the entire supply chain to identify products from the same grower (even across different suppliers). This is required for regulatory compliance and more effective recalls. Typically, suppliers are reluctant to share the identity (identification) or other information about their growers for fear of being eliminated. Suppliers want to see it as their asset (e.g., crops) from the outside, while growers may not even want to join any traceability solution. However, there is no single solution that can meet the needs of all supply chain partners around traceability needs and data privacy restrictions.

[0005] Therefore, a solution based on a blockchain network that provides anonymization of partners in a supply chain with traceability is desired. Summary of the invention

[0006] An exemplary embodiment provides a system comprising a processor and a memory, wherein the processor is configured to perform one or more of the following operations: generate an identifier (ID) of an asset producer node; map the ID to an identity of the asset producer node; receive a request from a supplier node among a plurality of supplier nodes to add the asset producer node to a supply blockchain; and provide rights to the plurality of supplier nodes based on the mapped ID.

[0007] Preferably, the present invention provides a system, wherein the instructions further cause the processor to store the mapped ID and the private encryption key of the asset producer node on a ledger of the supply blockchain in response to the request.

[0008] Preferably, the present invention provides a system, wherein the instructions further cause the processor to upload an asset traceability event based on the mapped ID.

[0009] Preferably, the present invention provides a system in which asset traceability events are referenced by supplier nodes.

[0010] Preferably, the present invention provides a system, wherein the instructions further cause the processor to provide data encrypted by the private encryption key of the asset producer node to the plurality of supplier nodes based on a matching request.

[0011] Preferably, the present invention provides a system, wherein the matching request comprises at least one element associated with the mapped ID.

[0012] Preferably, the present invention provides a system, wherein the instructions further cause the processor to process invitations from the plurality of supplier nodes to the asset producer node to join the supply blockchain.

[0013] Another exemplary embodiment provides a system including a processor and a memory, wherein the processor is configured to perform one or more of the following operations: obtain identity data from an asset producer node through a supply blockchain; generate a unique identifier (ID) for the asset producer node; execute a smart contract to map the ID to the identity data and provide rights of the asset producer node to multiple supplier nodes based on the mapped ID.

[0014] Another exemplary embodiment provides a method comprising one or more of the following operations: generating, by a processor node, an identifier (ID) of an asset producer node; mapping, by the processor node, the ID to an identity of the asset producer node; receiving, by the processor node, a request from a supplier node among a plurality of supplier nodes to add the asset producer node to a supply blockchain; and providing rights to the plurality of supplier nodes based on the mapped ID.

[0015] Preferably, the present invention provides a method, further comprising: uploading asset traceability events based on the mapped ID.

[0016] Preferably, the present invention provides a method wherein an asset traceability event is referenced by a supplier node.

[0017] Preferably, the present invention provides a method, further comprising providing data encrypted by a private encryption key of the asset producer node to the plurality of supplier nodes based on a matching request.

[0018] Preferably, the present invention provides a method, wherein the matching request comprises at least one element associated with the mapped ID.

[0019] Preferably, the present invention provides a method, further comprising processing invitations from said plurality of supplier nodes to asset producer nodes to join a supply blockchain.

[0020] Preferably, the present invention provides a method, further comprising uploading an asset traceability event based on the mapped ID.

[0021] Preferably, the present invention provides a method wherein an asset traceability event is referenced by a supplier node.

[0022] Preferably, the present invention provides a method, further comprising providing data encrypted by a private encryption key of the asset producer node to the plurality of supplier nodes based on a matching request.

[0023] Preferably, the present invention provides a method, wherein the matching request comprises at least one element associated with the mapped ID.

[0024] Preferably, the present invention provides a method further comprising processing invitations from a plurality of supplier nodes to an asset producer node to join a supply blockchain.

[0025] Another exemplary embodiment provides a method, comprising one or more of the following: obtaining, by a processor node, identity data from an asset producer node through a supply blockchain; generating, by the processor node, a unique identifier (ID) for the asset producer node; and executing a smart contract to map the ID to the identity data and provide rights of the asset producer node to multiple supplier nodes based on the mapped ID.

[0026] Yet another exemplary embodiment provides a non-transitory computer-readable medium comprising instructions which, when read by a processor, cause the processor to perform one or more of: generating an identifier (ID) for an asset producer node; mapping the ID to an identity of the asset producer node; receiving a request from a supplier node among a plurality of supplier nodes to add the asset producer node to a supply blockchain; and providing rights to the plurality of supplier nodes based on the mapped ID.

[0027] Yet another exemplary embodiment provides a non-transitory computer-readable medium comprising instructions which, when read by a processor, cause the processor to perform one or more of the following operations: obtain identity data from an asset producer node via a supply blockchain; generate a unique identifier (ID) for the asset producer node; execute a smart contract to map the ID to the identity data and provide rights of the asset producer node to a plurality of supplier nodes based on the mapped ID. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0029] Figure 1B A network diagram of a system including a database according to another exemplary embodiment is shown.

[0030] Figure 2A An example blockchain architecture configuration is shown in accordance with an exemplary embodiment.

[0031] Figure 2B A blockchain transaction flow according to an exemplary embodiment is shown.

[0032] Figure 3A A permission network according to an exemplary embodiment is shown.

[0033] Figure 3B Another permission network according to an exemplary embodiment is shown.

[0034] Figure 3C An unlicensed network according to an exemplary embodiment is shown.

[0035] Figure 4A A flow chart according to an exemplary embodiment is shown.

[0036] Figure 4B Another flow chart according to an exemplary embodiment is shown.

[0037] Figure 4C A flow chart according to an exemplary embodiment is shown.

[0038] Figure 4D Another flow chart according to an exemplary embodiment is shown.

[0039] Figure 5A An example system configured to perform one or more operations described herein is shown in accordance with example embodiments.

[0040] Figure 5B Another example system configured to perform one or more operations described herein is shown in accordance with an illustrative embodiment.

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

[0042] Figure 5D Yet another example system configured to utilize blockchain according to an exemplary embodiment is shown.

[0043] Fig. 6A A process of adding a new block to a distributed ledger is shown according to an exemplary embodiment.

[0044] Figure 6B The content of a new data block according to an exemplary embodiment is shown.

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

[0046] Fig.6D Blocks that may represent a block structure in a blockchain according to an exemplary embodiment are shown.

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

[0048] Figure 7B An example quantum-secure modular blockchain is shown in accordance with an exemplary embodiment.

[0049] Figure 8 An exemplary system is shown that supports one or more exemplary embodiments. DETAILED DESCRIPTION

[0050] It will be readily understood that the components of the present invention, as generally described and illustrated in the drawings herein, may be arranged and designed in a variety of different configurations. Therefore, the following detailed description of at least one embodiment of the method, apparatus, non-transitory computer-readable medium, and system as represented in the drawings is not intended to limit the scope of protection claimed in the present application, but is merely representative of selected embodiments.

[0051] In one or more embodiments, the characteristics, structures, or features of the present invention as described throughout this specification may be combined or removed in any suitable manner. For example, the phrases "exemplary embodiments", "some embodiments" or other similar language used throughout this specification actually refer to specific characteristics, structures, or features described in conjunction with the embodiments that may be included in at least one embodiment. Therefore, the phrases "exemplary embodiments", "in some embodiments", "in other embodiments", or other similar language that appear throughout this specification do not necessarily refer to the same group of embodiments, and in one or more embodiments, the described characteristics, structures, or features may be combined or removed in any suitable manner. Further, any connection between elements in the schematic diagram may allow unidirectional and / or bidirectional communication, even if the connection shown is a unidirectional or bidirectional arrow. Moreover, any device shown in the accompanying drawings may be a different device. For example, if a mobile device is shown sending information, the information may also be sent using a wired device.

[0052] In addition, although the term "message" may be used in the description of the embodiment, the application can be applied to many types of networks and data. In addition, although specific types of connections, messages and signaling may be described in exemplary embodiments, the application is not limited to specific types of connections, messages and signaling.

[0053] Exemplary embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks that provide anonymization of partners in a supply chain with traceability.

[0054] In one embodiment, the present application utilizes a decentralized database (such as a blockchain) as a distributed storage system, which includes multiple nodes that communicate with each other. The decentralized database includes an append-only immutable data structure similar to a distributed ledger that can maintain records between mutually untrusting parties. Mutually untrusting parties are referred to as peers or peer nodes in this article. Each peer maintains a copy of the database record, and no single peer can modify the database record without reaching a consensus between the distributed peers. For example, peers can execute a consensus protocol to verify blockchain storage transactions, group storage transactions into blocks, and establish a hash chain on the blocks. For consistency, the process forms a ledger by sorting storage transactions as needed. In various embodiments, permissioned blockchains and / or permissionless blockchains can be used. In a public or permissionless blockchain, anyone can participate without a specific identity. On the other hand, a permissioned blockchain database provides secure interactions between a group of entities that share a common goal but do not fully trust each other, such as businesses such as exchanging funds, goods, and information.

[0055] The present application can utilize blockchain operations to customize arbitrary, programmable logic called "smart contracts" or "chaincodes" for decentralized storage solutions. In some cases, there may be dedicated chaincodes called system chaincodes for managing functions and parameters. The present application can further utilize smart contracts, which are trusted distributed applications that utilize the tamper-proof nature of blockchain databases and a basic protocol between nodes called endorsements or endorsement policies. Blockchain transactions associated with the present application can be "endorsed" before being submitted to the blockchain, while unendorsed transactions are ignored. The endorsement policy allows the chaincode to specify endorsers for the transaction in the form of a set of peer nodes required for endorsement. When the client sends the transaction to the peers specified in the endorsement policy, the transaction will be executed to verify the transaction. After verification, the transaction enters the sorting phase, where a consensus protocol is used to generate an ordered sequence of endorsed transactions grouped into blocks.

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

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

[0058] The present application may utilize a chain that is a transaction log constructed as hash-linked blocks, each block containing a sequence of N transactions (where N is equal to or greater than 1). The block header includes the hash of the transactions of the block and the hash of the header of the previous block. In this way, all transactions on the ledger can be ordered and cryptographically linked together. Thus, it is impossible to tamper with the ledger data without breaking the hash link. The hash of the most recently added blockchain block represents every transaction that has appeared before it on the chain, so that all peer nodes can be ensured to be in a consistent and trusted state. The chain can be stored on a peer node file system (i.e., local, attached storage, cloud, etc.), effectively supporting the append-only nature of blockchain workloads.

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

[0060] Some benefits of the inventive solution described and illustrated herein include methods and systems for anonymizing partners in a supply chain with traceability based on a blockchain network. Exemplary embodiments address issues of time and trust by extending features of a database such as immutability, digital signatures, and being a single source of truth. Exemplary embodiments provide a solution for anonymizing partners in a supply chain with traceability based on a blockchain network. The blockchain network can be homogenous based on asset types and rules for managing assets based on smart contracts.

[0061] The difference between blockchain and traditional database is that blockchain is not central storage, but decentralized, immutable and secure storage, where nodes must share changes to records in storage. Some inherent and helpful properties of blockchain include but are not limited to immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsement, accessibility, etc., which are further described in this article. According to different aspects, due to the inherent and unique immutable accountability (accountability), security, privacy, allowed decentralization, availability of smart contracts, signatures and accessibility of blockchain, a system for anonymizing partners in a supply chain with traceability based on a blockchain network is implemented. In particular, blockchain ledger data is immutable, which provides an efficient method for anonymizing partners in a supply chain with traceability based on a blockchain network. In addition, the use of encryption in blockchain provides security and builds trust. Smart contracts manage the status of assets to complete the life cycle. The example blockchain is licensed decentralized. Therefore, each end user can have his own copy of the ledger accessible. Multiple organizations (and peers) can be bound on the blockchain network. Key organizations can act as endorsement peers to verify smart contract execution results, read sets, and write sets. In other words, the inherent characteristics of blockchain provide an effective implementation of a method for anonymizing partners in a supply chain with traceability based on a blockchain network.

[0062] One of the benefits of the exemplary embodiment is that it improves the functionality of the computing system by implementing a method for anonymizing partners in a supply chain with traceability in a blockchain-based system. Through the blockchain system described herein, the computing system can perform functions for anonymizing partners in a supply chain with traceability based on a blockchain network by providing access to capabilities such as distributed ledgers, peers, encryption technology, MSP, event processing, etc. In addition, the blockchain enables the creation of a business network and enables any user or organization to participate in on-board transactions. Therefore, the blockchain is more than just a database. The blockchain has the ability to create a business network of users and on-board / off-board organizations to collaborate and execute service processes in the form of smart contracts.

[0063] Additionally, exemplary embodiments improve the privacy of submitted and stored data by allowing a participant (e.g., a grower) to keep certain aspects of traceability information confidential (such as identity data of the precise location of a farm for a particular lot of harvest) unless required while still allowing full traceability to other qualified participants.

[0064] The exemplary embodiments provide many advantages over traditional databases. For example, through blockchain, the embodiments provide the inherent and unique immutable accountability, security, privacy, permission decentralization, availability, endorsement and accessibility of smart contracts.

[0065] At the same time, the exemplary embodiments cannot be implemented using a traditional database, because the traditional database does not bring all parties to the business network, does not create trusted collaboration, and does not provide efficient storage of digital assets. The traditional database does not provide tamper-proof storage and does not provide preservation of the stored digital assets. Therefore, the proposed method for anonymizing partners in a supply chain with traceability based on a blockchain network cannot be implemented in a traditional database.

[0066] Meanwhile, if a conventional database is used to implement the exemplary embodiment, the exemplary embodiment will have unnecessary disadvantages, such as:

[0067] -The data will be stored / controlled by a single entity, which could conceivably change or delete the data without the knowledge of other participants. Entities in the supply chain may be competitors, so any single entity with this ability may not be trusted.

[0068] - Storing data on a blockchain provides immutability that can be used to verify the mapping from a unique identifier to private identity data and the authenticity of event data referencing the unique identifier when needed (for example, in a recall scenario where private identity data is needed to verify supply chain traceability).

[0069] Thus, the exemplary embodiments provide a particular solution to a problem in the art / area of ​​traceability in a supply chain.

[0070] Exemplary embodiments also change how data can be stored within the block structure of the blockchain. For example, digital asset data can be securely stored within a portion of a data block (i.e., within a header, data segment, or metadata). By storing digital asset data within a data block of the blockchain, the digital asset data can be attached to the immutable blockchain ledger through a hash link chain of blocks. In some embodiments, data blocks can differ from traditional data blocks by not storing personal data associated with digital assets with assets within the traditional block structure of the blockchain. By removing personal data associated with digital assets, blockchain can provide the benefits of anonymity based on immutable accountability and security.

[0071] According to an exemplary embodiment, a system and method for anonymizing partners in a supply chain with traceability based on a blockchain network are provided.

[0072] Traceability events that reference protected data (e.g., grower identity) can encrypt that data to protect the grower's identity. Additional event data can be used as an encryption salt to further obfuscate supply chain partner patterns. Exemplary embodiments provide the utility of increasing traceability when needed. According to an exemplary embodiment, a method enables suppliers to identify growers without enabling retailers to identify them or distributing encryption keys.

[0073] This application can be applied to the food supply chain, where the grower identity is a protected data element. However, the same approach can be applied to any protected data in any value chain. In the food supply chain example, the traceability event contains protected data (e.g., grower identity). It may be desirable to disclose aspects related to the protected data (e.g., the name of the location of the grower's farm). The protected data element (e.g., business location) can be constructed in a way that combines an encrypted copy of the protected data and a plaintext copy of the unprotected data, such as:

[0074] urn:ibm:location:farm: <encryptedinfo> . <publicinfo>

[0075] EncryptedInfo can be derived as a function of the protected data and additional information about the events described below. The additional information can vary in different use cases to provide the desired level of transparency. Note that the function of the protected data can be implemented as an encryption method. However, if the system does not require the inverse operation (for example, the supplier has its own IT system that tracks the protected data elements), a one-way hash function can be used. Using a one-way function reduces the need to distribute keys.

[0076] PublicInfo may also include desired data elements in an identifier that is also unencrypted. For example, a retailer may require a location or approximate geo-hash in the system and share it without protection. Thus, exemplary embodiments protect data while allowing a degree of traceability.

[0077] As described above, cryptographic salts may be used on the protected data for further obfuscation. This reduces the ability to extract supply chain patterns from the encrypted data. An example of additional information about events is based on the food supply chain. The batch ID of a product changes every time it is harvested. This is ideal for data privacy because there is very little opportunity for data redundancy or pattern matching on the protected data. This may be suboptimal for retailer traceability, but can be greatly improved using the additional utilities discussed in detail below. Retailers may only be able to identify common batches from common growers (not very useful in some cases). This may also be suboptimal for supporting documents attached to the grower location, but this can also be improved. Additional data related to the grower (e.g., certification records) may have to be replicated for each batch.

[0078] A supplier's organization ID may be appropriate for traceability: a retailer may be able to trace a product from a grower to the same supplier without knowing the grower's identity. This may be suboptimal for data privacy: a retailer may be able to infer a supplier's data patterns even without knowing the identity (e.g., a retailer may see that a supplier gets 90% of its products from a single grower). An organization ID may be appropriate for supporting documentation because minimal duplication is required. If supply chain patterns (including common partners between suppliers) do not need to be hidden, cryptographic salts can be removed for maximum retailer traceability.

[0079] For example, there are three traceability event assets representing a trace that are accessible to both the retailer and supplier-1. When the retailer performs a trace, they can see events with the farm location as an obfuscated identifier. There is a fourth asset that is not authorized to the retailer, which contains a grower ID that is mapped to a real-world identity. This is the key to understanding identity. When supplier-1 performs a trace, the grower ID asset can be used to decrypt the data in the original event asset to show the full identity. Supplier-2 may receive information from the same batch. If a specific item is recalled, the retailer can search for other suppliers that received the batch from that grower and see that the grower provided the item to supplier-2. Therefore, the retailer knows that the related items are also affected by the recall.

[0080] In some cases (e.g., recalls, etc.), the retailer may need more information. This may vary based on the requirements and based on the salt used in the encryption, as it affects the data that the retailer can see. For example, a retailer received a bad batch from a supplier. The retailer may need to know which other suppliers produced batches from the same grower within a certain time frame. The supply chain utility may need to return other affected batches within the same month to suppliers that dealt with that grower. However, the grower identity may not need to be exposed. Instead, a list of batch identifiers may be returned. This exemplary process can be described as:

[0081] GetCommonLocations(Encrypt(GrowerID+item_lot 1),daterange,

[0082] Geograpicalidentifier)=>Encrypt(GrowerID+item_lot 2)

[0083] According to an exemplary embodiment, the utility may provide additional context as needed. The utility may provide to return additional data that is not directly visible in the viewable event. The data returned is minimized to just what is needed. A cap may be used to prevent retailers from getting more access than needed. Usage notifications may be provided so that partners can see the elevated access request, further preventing unnecessary usage.

[0084] As mentioned above, the providers want to protect the identities of their farmers. To a large extent, knowing the farmer identity eliminates the need to protect that information. Therefore, pure knowledge of the grower's identity (e.g., email, phone, address, farm name, etc.) can allow people to know the grower's identity within the system. Such an assumption can allow the system to operate even if the grower is not a member. The grower identity can then be represented as a digital identifier. The digital identifier mapped to the grower's physical identity and a private encryption key can be used to encrypt data related to that grower. This data can be stored and shared on the same asset that was generated when the first provider invited the grower to the exemplary system (and licensed to that provider).

[0085] For example, Supplier-A invites Acme Grower to the system, providing an identifier (i.e., farm name, farm address, contact email, and phone number). The system generates a grower ID and encryption key, and displays the grower ID to Supplier-A given their grower network. Supplier-A now references the grower ID in uploaded traceability events. This asset can be licensed to other suppliers who attempt to invite the same ID. Supplier-B can then invite the same grower, and can automatically gain authorization to that data by virtue of being able to match. If the grower contact information is already known, then there is actually little need to protect the identity. An invitation cap can be set to prevent retailers from trying to exploit this to slam the door. Matching criteria can vary by solution, such as:

[0086] - If the party provides an exact phone number, email, or address, the system can match existing records;

[0087] - If the parties provide the same organization name (with fuzzy matching), the system can find a match.

[0088] The asset may have access to additional suppliers that directly share grower connections with each other. From a grower network perspective, Supplier-A can refer a grower to Supplier-B and may have access to the grower ID.

[0089] Once a grower accepts the invitation to join the supply chain solution, the grower can more proactively manage access to his identity / credentials (accept, deny, revoke, explicitly share with other suppliers).

[0090] While the above example depicts the identity of the farmer as data that can be hidden, there are many more candidates that can take advantage of this technique. The following could be examples of data:

[0091] Quantity: Harvested batches may include content that goes to multiple partners. Showing those partners harvest quantities indicates they are dealing with someone else, which may not be ideal;

[0092] Quantities and event timing: For some supply chains, multiple ingredients are combined to produce a final product. Exposing quantities and event timing for some events may reveal confidential details about the processing steps;

[0093] GTIN (Product ID): GTIN includes the registered company in its GS1 prefix, for example. Often GTINs are renamed before being provided to partners, so there is no need to share the original GTIN;

[0094] GLN: Very similar to the grower ID. The GLN is the registered location where the event occurred, so exposing the GLN actually exposes the farmer's ID;

[0095] Batch number: Information (such as farmer ID and harvester) is encoded into the batch number in many organizations and can be used to identify the grower;

[0096] Certification data: Retailers may need to provide certification, but the exact details about it may be private. If the party is compliant, details such as the party’s certificate expiration date or exact audit score may not need to be shared;

[0097] Event Description: Text describing the event might only be desirable for certain applications.

[0098] According to an exemplary embodiment, there are multiple places in the process where encryption may occur. In one embodiment, the data can be encrypted before uploading. This is simpler in some ways, but puts more pressure on the uploading application and may not be the most useful. In another embodiment, the data can be encrypted in the server-side process when uploading. The server-side process can apply logic to encrypt the data when the data is uploaded, thereby reducing the burden on the uploading application or entity. This can be achieved by ensuring that all data is encrypted using public logic. Further, if the authorized party has access to the private key, the server-side logic can decrypt the authorized party's data. Data can be encrypted in the server-side process during download. If the data source itself is encrypted and is not directly visible to the Tier 1 1 participant, the data can be stored in plain text (i.e., unencrypted) and encrypted when the appropriate identity is downloaded by a trusted server-side application that accesses the private key.

[0099] Figure 1A A logical network diagram is shown for anonymizing partners in a supply chain with traceability based on a blockchain network according to an exemplary embodiment.

[0100] refer to Figure 1A , the example network 100 includes a processor node 102 connected to an asset producer node 103 and a supplier node 105. The processor node 102 may be connected to a blockchain 106 having a ledger 108 for storing the mapped ID and private encryption key of the asset producer node 103. Although this example describes only one processor node 102 in detail, multiple such nodes may be connected to the blockchain 106. It should be understood that the processor node 102 may include additional components, and some of the components described herein may be removed and / or modified without departing from the scope of the processor node 102 disclosed herein. The processor node 102 may be a computing device or a server computer, etc., and may include a processor 104, which may be a semiconductor-based microprocessor, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), and / or another hardware device. Although a single processor 104 is shown, it should be understood that the processor node 102 may include multiple processors, multiple cores, etc. without departing from the scope of the processor node 102 system.

[0101] The processor node 102 may also include a non-transitory computer-readable medium 112, which may have machine-readable instructions stored thereon that may be executed by the processor 104. Examples of machine-readable instructions are shown as 114-120 and are discussed further below. Examples of non-transitory computer-readable media 112 may include electronic, magnetic, optical, or other physical storage devices that contain or store executable instructions. For example, the non-transitory computer-readable medium 112 may be a random access memory (RAM), an electrically erasable programmable read-only memory (EEPROM), a hard disk, an optical disk, or other type of storage device.

[0102] The processor 104 may execute machine-readable instructions 114 to generate an identifier (ID) of the asset producer node. As discussed above, the blockchain ledger 108 may store the mapped ID and private encryption key 110 of the asset producer node 103. The supply blockchain 106 network may be configured to use one or more smart contracts that manage transactions for multiple participating nodes.

[0103] Processor 104 may execute machine-readable instructions 116 to map the ID to the identity of asset producer node 103. Processor 104 may execute machine-readable instructions 118 to receive a request from a supplier node in the plurality of supplier nodes 105 to add asset producer node 103 to supply blockchain 106. Processor 104 may execute machine-readable instructions 120 to provide rights to the plurality of supplier nodes 105 based on the mapped ID.

[0104] Figure 1B A logical network diagram for anonymizing partners in a supply chain with traceability based on a blockchain network according to an exemplary embodiment is shown.

[0105] refer to Figure 1B , the example network 130 includes a processor node 102 connected to an asset producer node 103 and a supplier node 105. The processor node 102 may be connected to a blockchain 106 having a ledger 108 for storing the mapped ID and private encryption key of the asset producer node 103. Although this example describes only one processor node 102 in detail, multiple such nodes may be connected to the blockchain 106. It should be understood that the processor node 102 may include additional components, and some of the components described herein may be removed and / or modified without departing from the scope of the processor node 102 disclosed herein. The processor node 102 may be a computing device or a server computer, etc., and may include a processor 104, which may be a semiconductor-based microprocessor, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), and / or another hardware device. Although a single processor 104 is shown, it should be understood that the processor node 102 may include multiple processors, multiple cores, etc. without departing from the scope of the processor node 102 system.

[0106] The processor node 102 may also include a non-transitory computer-readable medium 112', which may have machine-readable instructions stored thereon that may be executed by the processor 104. Examples of machine-readable instructions are shown as 113-117 and are discussed further below. Examples of non-transitory computer-readable media 112' may include electronic, magnetic, optical, or other physical storage devices that contain or store executable instructions. For example, the non-transitory computer-readable medium 112 may be a random access memory (RAM), an electrically erasable programmable read-only memory (EEPROM), a hard disk, an optical disk, or other type of storage device.

[0107] The processor 104 may execute machine-readable instructions 113 to obtain identity data from the asset producer node 103 via the supply blockchain 106. As described above, the blockchain ledger 108 may store the mapped ID and private encryption key 110 of the asset producer node 103. The supply blockchain 106 network may be configured to use one or more smart contracts that manage transactions for multiple participating nodes.

[0108] The processor 104 may execute machine-readable instructions 115 to generate a unique identifier (ID) for the asset producer node. The processor 104 may execute machine-readable instructions 117 to execute a smart contract to map the ID to identity data and provide rights to the asset producer node to multiple supplier nodes based on the mapped ID.

[0109] Figure 2A A blockchain architecture configuration 200 is shown according to an exemplary embodiment. Figure 2A , the blockchain architecture 200 may include certain blockchain elements, for example, a set of blockchain nodes 202. The blockchain nodes 202 may include one or more nodes 204-210 (these four nodes are shown by way of example only). These nodes participate in many activities, such as blockchain transaction addition and confirmation processes (consensus). One or more of the blockchain nodes 204-210 may endorse transactions based on endorsement policies and may provide sorting services for all blockchain nodes in the architecture 200. The blockchain node may initiate a blockchain authentication and attempt to write to a blockchain immutable ledger stored in the 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., chain code, 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 a transaction and installed on all blockchain nodes 204-210 by attaching to the distributed ledger.

[0110] The blockchain foundation or platform 212 may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and supporting physical computer infrastructure for receiving and storing new transactions and providing access to auditors seeking to access data entries. The blockchain layer 216 may expose interfaces that provide access to the virtual execution environment necessary to process program code and participate in the physical infrastructure 214. Cryptographic trust services 218 may be used to verify transactions (such as asset exchange transactions) and keep information private.

[0111] Figure 2A The blockchain architecture configuration of the blockchain platform 212 can process and execute program / application code 220 through one or more interfaces exposed and services provided by the blockchain platform 212. The code 220 can control blockchain assets. For example, the code 220 can store and transfer data, which can be executed by the nodes 204-210 in the form of smart contracts and associated chain codes, which have conditions or other code elements affected by their execution. As a non-limiting example, smart contracts can be created to perform reminders, updates, and / or other notifications of changes, updates, etc. The smart contract itself can be used to identify rules associated with authorization and access requirements and use of the ledger. For example, the asset producer identity information 226 can be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 216. The results 228 may include rights to supplier nodes based on the asset producer identity information. The physical infrastructure 214 can be used to retrieve any data or information described herein.

[0112] Smart contracts can be created through high-level applications and programming languages ​​and then written to blocks in the blockchain. Smart contracts can include executable code that is registered, stored, and / or replicated using a 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 satisfaction of a condition associated with the smart contract. The execution of a smart contract can trigger trusted modifications to the state of a digital blockchain ledger. Modifications to the blockchain ledger caused by the execution of a smart contract can be automatically replicated throughout the distributed network of blockchain peers through one or more consensus protocols.

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

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

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

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

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

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

[0119] After successful checks, at step 293, client 260 assembles the endorsements into a transaction and broadcasts the transaction proposal and response to ordering node 284 within a transaction message. The transaction may contain read sets / write sets, endorsement peer signatures, and channel IDs. Ordering node 284 does not need to check the entire contents of the transaction in order to perform its operations, instead, ordering node 284 can simply receive transactions from all channels in the network, sort them chronologically by channel, and create a per-channel transaction block.

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

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

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

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

[0124] Blockchain developers 330 write chaincodes and client-side applications. Blockchain developers 330 can deploy chaincodes directly to the network through an interface. In order to include credentials from traditional data sources 332 in the chaincode, developers 330 can use out-of-band connections to access the data. In this example, blockchain users 322 connect to the network through peer nodes 334. Before conducting any transactions, peer nodes 334 retrieve the user's registration and transaction certificates from certificate authorities 336. In some cases, blockchain users must have these digital certificates to conduct transactions on the permissioned blockchain 324. At the same time, users trying to utilize chaincodes may need to verify their credentials on traditional data sources 332. To confirm the user's authorization, the chaincode can use an out-of-band connection to the data through a traditional processing platform 338.

[0125] In some embodiments, the blockchain herein may be a permissionless blockchain. In contrast to permissioned blockchains, which require permission to join, anyone can join a permissionless blockchain. For example, to join a permissionless blockchain, a user can create a personal address and begin interacting with the network by submitting a transaction, thereby adding an entry to the ledger. In addition, all parties can choose to run a node on the system and employ a mining protocol to help verify transactions.

[0126] Figure 3C A process 350 of a transaction processed by a permissionless blockchain 352 including a plurality of nodes 354 is shown. A sender 356 wishes to send a payment or some other form of value (e.g., a deed, medical record, contract, good, service, or any other asset that may 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 controls and a display of transaction parameters. In response, the transaction is broadcast to the nodes 354 throughout the blockchain 352. Depending on the network parameters of the blockchain 352, the nodes validate 360 ​​the transaction based on rules established by the creator of the permissionless blockchain 352 (which may be predefined or dynamically assigned). For example, this may include verifying the identities of the parties involved, etc. The transaction may be validated immediately, or it may be placed in a queue with other transactions, and the nodes 354 determine whether the transaction is valid based on the network rule set.

[0127] In structure 362, valid transactions are formed into blocks and sealed with locks (hashes). This process can be performed by a mining node in node 354. The mining node can utilize additional software dedicated to mining and creating blocks of the permissionless blockchain 352. Each block can be identified by a hash (e.g., a 256-bit number, etc.) created using an algorithm agreed upon by the network. Each block may include a header, a pointer or reference to the hash of the header 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.

[0128] Before a block can be added to the blockchain, the block must be verified.

[0129] Through mining 364, nodes attempt to solve a block by making incremental changes to one variable until the solution satisfies the network-wide goal.

[0130] Here, it is extremely difficult to modify the blockchain because an attacker would have to modify all subsequent blocks for a modification to one block to be accepted. In addition, as new blocks are mined, the difficulty of modifying a block increases, and the number of subsequent blocks also increases. Successfully validated blocks are distributed through the permissionless blockchain 352 via distribution 366, and all nodes 354 add the block to the majority chain, which is an auditable ledger of the permissionless blockchain 352. In addition, the value in the transaction submitted by the sender 356 is deposited or otherwise transferred to the digital wallet of the recipient device 358.

[0131] Figure 4A A flowchart 400 of an example method for anonymizing partners in a supply chain with traceability based on a blockchain network according to an exemplary embodiment is shown. Figure 4A , method 400 may include one or more steps described below.

[0132] Figure 4A The processor 102 (see Figure 1A ) is a flowchart of an exemplary method performed. It should be understood that Figure 4A The method 400 shown in FIG. 4 may include additional operations, and some operations described therein may be removed and / or modified without departing from the scope of the method 400. For illustrative purposes, the description of the method 400 also refers to Figure 1A Specifically, the processor 104 of the processor node 102 may perform some or all of the operations included in the method 400.

[0133] refer to Figure 4A At block 412, the processor 104 may generate an identifier (ID) of the asset producer node. At block 414, the processor 104 may map the ID to the identity of the asset producer node. At block 416, the processor 104 may receive a request from a supplier node in a plurality of supplier nodes to add the asset producer node to a supply blockchain. At block 418, the processor 104 may provide rights to the plurality of supplier nodes based on the mapped IDs.

[0134] Figure 4B A flowchart 450 of an example method according to an exemplary embodiment is shown. Figure 4B , method 450 may also include one or more of the following steps. In box 452, the processor 104 may store the mapped ID and private encryption key of the asset producer node on the ledger of the supply blockchain in response to the request. In box 454, the processor 104 may upload an asset traceability event based on the mapped ID. Note that the asset traceability event can be referenced by the supplier node. In box 456, the processor 104 may provide data encrypted by the private encryption key of the asset producer node to the multiple supplier nodes based on the matching request. Note that the matching request may include at least one element associated with the mapped ID. In box 458, the processor 104 may process invitations from multiple supplier nodes to the asset producer node to join the supply blockchain.

[0135] Figure 4C A flowchart 460 is shown of an example method for anonymizing partners in a supply chain with traceability based on a blockchain network according to an exemplary embodiment. Figure 4C , method 460 may include one or more steps described below.

[0136] Figure 4C The processor node 102 (see Figure 1B ) is a flowchart of an example method performed. It should be understood that Figure 4C The method 460 shown in FIG. 4 may include additional operations, and some of the operations described therein may be removed and / or modified without departing from the scope of the method 460. For illustrative purposes, reference is also made to Figure 1B The features shown in 460 are described for the method 460. Specifically, the processor 104 of the processor node 102 may perform some or all of the operations included in the method 460.

[0137] refer to Figure 4C At block 462, the processor 104 may obtain identity data from the asset producer node through the supply blockchain. At block 464, the processor 104 may generate a unique identifier (ID) for the asset producer node. At block 466, the processor 104 may execute a smart contract to map the ID to the identity data and provide rights of the asset producer node to multiple supplier nodes based on the mapped ID.

[0138] Figure 4D A flowchart 470 of an example method according to an exemplary embodiment is shown. Figure 4D , method 470 may also include one or more of the following steps. In box 472, the processor 104 may store the mapped ID and private encryption key of the asset producer node on the ledger of the supply blockchain. In box 474, the processor 104 may execute a smart contract to process invitations from the multiple supplier nodes to the asset producer node to join the supply blockchain. In box 476, the processor 104 may provide data encrypted by the private key to the multiple suppliers based on the matching request. Note that the matching request may contain at least one element of the identity data of the asset producer. In box 478, the processor 104 may execute a smart contract to authorize the asset producer node to multiple supplier nodes based on the matching request. In box 480, the processor 104 may execute a smart contract to match the request based on an exact match criterion or a fuzzy match criterion.

[0139] Figure 5A An exemplary system 500 is shown including a physical infrastructure 510 configured to perform various operations in accordance with an exemplary embodiment. Figure 5A , the physical infrastructure 510 includes a module 512 and a module 514. The module 514 includes a blockchain 520 and a smart contract 530 (which may reside on the blockchain 520), which may perform any operation steps 508 (in the module 512) included in any exemplary embodiment. The steps / operations 508 may include one or more of the described or illustrated embodiments, and may represent output or written information written or read from one or more smart contracts 530 and / or blockchains 520. The physical infrastructure 510, the modules 512, and the modules 514 may include one or more computers, servers, processors, memories, and / or wireless communication devices. In addition, the modules 512 and 514 may be the same module.

[0140] Figure 5B Another example system 540 is shown that is configured to perform various operations in accordance with an exemplary embodiment. Figure 5B , system 540 includes module 512 and module 514. Module 514 includes blockchain 520 and smart contract 530 (which may reside on blockchain 520), and smart contract 530 may perform any operation step 508 (in module 512) included in any exemplary embodiment. Step / operation 508 may include one or more of the described or illustrated embodiments, and may represent output or written 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 computers, servers, processors, memories, and / or wireless communication devices. In addition, module 512 and module 514 may be the same module.

[0141] Figure 5C An example system configured to utilize a smart contract configuration between contracting parties and an intermediary server configured to enforce the terms of the smart contract on a blockchain according to an exemplary embodiment are shown. Figure 5C , configuration 550 may 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 execution results of the smart contract may be managed by a server 554. The content of the smart contract 530 may require digital signatures of one or more of the entities 552 and 556 that are parties to the smart contract transaction. The smart contract execution results may be written to the blockchain 520 as a blockchain transaction. The smart contract 530 resides on the blockchain 520, which in turn resides on one or more computers, servers, processors, memories, and / or wireless communication devices.

[0142] Figure 5D A system 560 including a blockchain according to an exemplary embodiment is shown. Figure 5D In the example of , an application programming interface (API) gateway 562 provides a public interface for accessing blockchain logic (e.g., smart contracts 530 or other chaincodes) and data (e.g., distributed ledgers, etc.). In this example, the 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 blockchain peers (i.e., servers 554). Here, the server 554 is a blockchain network peer component that holds a copy of the world state and the distributed ledger, allowing clients 552 and 556 to query data about the world state and submit transactions to the blockchain network, where, according to the smart contract 530 and the endorsement policy, the endorsing peer will run the smart contract 530.

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

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

[0145] Fig. 6A 600 showing a process 600 of adding a new block to a distributed ledger 620 according to an exemplary embodiment, Figure 6B The content of a new data block structure 630 of a blockchain according to an exemplary embodiment is shown. The new data block may contain rights to multiple supplier nodes based on the mapped IDs as described above.

[0146] refer to Fig. 6A , a client (not shown) may submit a transaction to blockchain nodes 611, 612, and / or 613. A client may be a server that receives instructions from any source to enact activities on blockchain 620. As an example, a client may be an application that proposes transactions for a blockchain on behalf of a requester (such as a device, person, or entity). 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 endorsement peers that simulate and endorse transactions proposed by clients and submission peers that verify endorsements, verify transactions, and submit transactions to the distributed ledger 620. In this example, blockchain nodes 611, 612, and 613 may play the role of endorser nodes, submitter nodes, or both.

[0147] The distributed ledger 620 includes a blockchain that stores immutable, ordered records in blocks and a state database 624 (current world state) that maintains the current state of the blockchain 622. There can be one distributed ledger 620 per channel, and each peer maintains its own copy of the distributed ledger 620 for each channel of which they are a member. The blockchain 622 is a transaction log structured as hash-linked blocks, where each block contains a sequence of N transactions. A block may include, for example, Figure 6B The various components shown in the figure. The links of the blocks (by Fig. 6A ) can be generated by adding the hash of the header of the previous block within the block header of the current block. In this way, all transactions on the blockchain 622 are ordered and cryptographically linked together, thereby preventing tampering with the blockchain data without breaking the hash link. In addition, due to the linking, the latest block in the blockchain 622 represents every transaction that occurred before it. The blockchain 622 can be stored on a peer-to-peer file system (local or attached storage) that supports append-only blockchain workloads.

[0148] The current state of the blockchain 622, and the distributed ledger 622, may be stored in a state database 624. Here, the current state data represents the latest values ​​of all keys ever included in the chain transaction log of the blockchain 622. Chaincode calls execute transactions against the current state in the state database 624. In order to make these chaincode interactions extremely efficient, the latest values ​​of all keys are stored in the state database 624. The state database 624 may include an indexed view of the transaction log of the blockchain 622, and may therefore be regenerated from the chain at any time. The state database 624 may be automatically restored at peer startup (or generated when needed) before a transaction is accepted.

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

[0150] The ordering service 610 accepts endorsed transactions, orders them into blocks, and delivers the blocks to committing peers. For example, the ordering service 610 may initiate a new block when a transaction threshold has been reached, a timer has expired, or another condition. Fig. 6A In the example of , blockchain node 612 is a commit peer that has received a new data block 630 to be stored on blockchain 620. The first block in a blockchain may be referred to as a genesis block, which includes information about the blockchain, its members, the data stored therein, and the like.

[0151] The ordering service 610 may be comprised of a cluster of orderers. The ordering service 610 does not process transactions, smart contracts, or maintain a shared ledger. Instead, the ordering service 610 may accept endorsed transactions and specify the order in which these are submitted to the distributed ledger 620. The architecture of the blockchain network may be designed such that the specific implementation of 'ordering' (e.g., Solo, Kafka, BFT, etc.) becomes a pluggable component.

[0152] Transactions are written to the distributed ledger 620 in a consistent order. The establishment of an order for transactions ensures that updates to the state database 624 are valid when the transactions are submitted to the network. In this example, the parties to the distributed ledger 620 can choose the ordering mechanism that best suits the network.

[0153] When the ordering service 610 initializes a new data block 630, the new data block 630 may be broadcast to the committing peers (e.g., blockchain nodes 611, 612, and 613). In response, each committing peer verifies the transaction within the new data block 630 by checking to ensure that the read set and the write set still match the current world state in the state database 624. Specifically, the committing peer may determine whether the read data that existed when the endorser simulated the transaction is the same as the current world state in the state database 624. When the committing peer verifies the transaction, the transaction is written to the blockchain 622 on the distributed ledger 620, and the state database 624 is updated with the write data from the read-write set. If the transaction fails, that is, if the committing peer finds that the read-write set does not match the current world state in the state database 624, the transaction ordered into the block will still be included in the block, but it will be marked as invalid, and the state database 624 will not be updated.

[0154] refer to Figure 6B , a new data block 630 (also referred to as a data block) stored on the 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 the various blocks shown and their contents, such as Figure 6B The new data block 630 and its contents shown in the figure are merely examples and are not meant to limit the scope of the exemplary embodiments. The new data block 630 may store transaction information of N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) in the block data 650. The new data block 630 may also include a pointer to the previous block in the block header 640 (e.g., Fig. 6A Specifically, the block header 640 may include a hash of the header of the previous block. 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 starting from zero and in an increasing / continuous order.

[0155] The block data 650 may store transaction information for each transaction recorded in the new data block 630. For example, the transaction data may include one or more of the following: transaction type, version, timestamp, channel ID of the distributed ledger 620, transaction ID, epoch, payload visibility, chaincode path (deployment transaction), chaincode name, chaincode version, inputs (chaincode and function), client (creator) identity (such as public key and certificate), client's signature, endorser's identity, endorser signature, proposal hash, chaincode event, response status, namespace, read set (list of keys and versions read by the transaction, etc.), write set (list of keys and values, etc.), start key, end key, list of keys, Merkel tree query summary, etc. Transaction data may be stored for each of the N transactions.

[0156] In some embodiments, block data 650 may also store new data 662 that adds additional information to the hash-linked chain of blocks in blockchain 622. The additional information includes one or more of the steps, features, processes, and / or actions described or illustrated herein. Accordingly, new data 662 may be stored in an immutable block log on distributed ledger 620. Some benefits of storing such new data 662 are reflected in the various embodiments disclosed and illustrated herein. Although new data 662 is stored in Figure 6B 650, but may also be located in the block header 640 or block metadata 660. New data 662 may include the rights of multiple supplier nodes based on the mapped ID. The new data of the block may consist of a cryptographic mapping from identity data to a unique identifier assigned by the present invention for privacy protection. This new information improves the data privacy capabilities of the blockchain.

[0157] The block metadata 660 may store multiple fields of metadata (e.g., as a byte array, etc.). The metadata fields may include a signature on the creation of the block, a reference to the last configuration block, a transaction filter identifying valid and invalid transactions within the block, the last offset of the sorting service that sorted the block, etc. The signature, the last configuration block, and the sorter metadata may be added by the sorting service 610. Meanwhile, the submitter of the block (such as the blockchain node 612) may add valid / invalid information based on an endorsement policy, verification of a read set / write set, etc. The transaction filter may include a byte array of size equal to the number of transactions in the block data 650 and a verification code identifying whether the transaction is valid / invalid.

[0158] Figure 6C An embodiment of a blockchain 670 of digital content according to embodiments described herein is shown. The digital content may include one or more files and associated information. A file may contain media, images, video, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable, append-only nature of the blockchain is a safeguard to protect the integrity, validity, and authenticity of the digital content, making it suitable for use in legal proceedings where admissibility rules apply, or other environments where evidence is considered, or where the presentation and use of digital information is of interest. In this context, the digital content may be referred to as digital evidence.

[0159] The blockchain can be formed in a variety of ways. In one embodiment, the digital content can be included in and accessed from the blockchain itself. For example, each block of the blockchain can store a hash value of reference information (e.g., header, value, etc.) along with the associated digital content. The hash value and the associated digital content can then be encrypted together. 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. This can be illustrated as follows:

[0160]

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

[0162]

[0163] exist Figure 6C In an exemplary embodiment of the present invention, the blockchain 670 includes a plurality of blocks 6781, 6782, ..., 6783 connected cryptographically in a sorted order. N , where N ≥ 1. Used to link blocks 6781, 6782, ..., 678 N The encryption of can be any of a number of keyed or non-keyed hash functions. In one embodiment, blocks 6781, 6782, ..., 678 N A hash function is subject to producing an n-bit alphanumeric output (where n is 256 or another number) from an input based on the information in the block. Examples of such hash functions include, but are not limited to, SHA-type (SHA stands for Secure Hash Algorithm) algorithms, Merkle-Damgard algorithms, HAIFA algorithms, Merkle-tree algorithms, random number-based algorithms, and collision-resistant PRF algorithms. In another embodiment, blocks 6781, 6782, ..., 678 N The cryptographic linking may be performed by a function other than a hash function. For purposes of illustration, the following description is made with reference to a hash function (eg, SHA-2).

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

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

[0166] The header 6721 may include one or more initial parameters, which may include, for example, a version number, a timestamp, a random number, root information, a difficulty level, a consensus protocol, a duration, a media format, a 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., by blockchain network management software) or manually by a blockchain participant. N Unlike the header in the block, header 6721 in the genesis block does not reference the previous block because there is no previous block at all.

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

[0168] The value 6761 in the generation 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 a hash value of the original file 6741, metadata of the original file 6741, and other information associated with the file. In one embodiment, the initial value 6761 may be based on the following unique attributes:

[0169] 1) The SHA-2 hash value of the original file

[0170] 2) Originating device ID

[0171] 3) The starting timestamp of the original file

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

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

[0174] Other blocks in the blockchain 6782 to 678 N It also has a header, file, and value. However, unlike the first block 6721, the headers 6722 to 672 N Each of the blocks includes the hash value of the immediately preceding block. The hash value of the preceding block may be just the hash of the header of the preceding block, or may be the hash value of the entire preceding block. By including the hash value of the preceding block in each of the remaining blocks, tracking from the Nth block back to the generating block (and the associated original file) may be performed block by block as shown by arrow 680 to establish an auditable and immutable chain of custody.

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

[0176] Files 6742 to 674 in other blocks N The generated block may be equal to the original file, or may be a modified version of the original file in the generated block, depending on, for example, the type of processing performed. The type of processing performed may vary from block to block. For example, the processing may involve any modification of 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.

[0177] Additionally or alternatively, the processing may involve merely copying the file from a previous block, changing the storage location of the file, analyzing the file from one or more previous blocks, moving the file from one storage or memory location to another, or performing an action relative to the file and / or its associated metadata on the blockchain. Processing involving analyzing the file may include, for example, appending, including, or otherwise associating different analytics, statistics, or other information associated with the file.

[0178] Other blocks 6762 to 676 in other blocks N The value in each of the blocks is a unique value and is different due to the processing performed. For example, the value in any one block corresponds to an updated version of the value in the previous block. The update is reflected in the hash of the block being assigned. The value of the block thus provides an indication of what processing was performed in the block and also allows tracking back to the original file through the blockchain. This tracking confirms the chain of custody of the file throughout the blockchain.

[0179] For example, consider a situation where a portion of a file in a previous block is edited, masked, or pixelated to protect the identity of the person shown in the file. In this case, the block that includes the edited file will include metadata associated with the edited file, such as how the edit was performed, who performed the edit, a timestamp when the edit occurred, etc. The metadata can be hashed to form a value. Because the metadata of the block is different from the information that was hashed to form the value in the previous block, the values ​​are different from each other and can be recovered upon decryption.

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

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

[0182] b) New storage location for the file

[0183] c) New metadata associated with the file identified

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

[0185] Fig.6D An embodiment of a block is shown that can represent the structure of a block in blockchain 690 according to one embodiment. i Including header 672 i 、File 674 i Total value 676 i .

[0186] Head 672 i Including the previous block Block i-1 The hash value of the previous block and additional reference information, such as any type of information discussed in this article (e.g., header information including references, features, parameters, etc.). All blocks (except the generation block, of course) reference the hash of the previous block. The hash value of the previous block can be just the hash of the header in the previous block, or it can be the hash of all or part of the information in the previous block (including files and metadata).

[0187] File 674 i The system includes a plurality of data, such as data 1, data 2, ..., data N in sequence. The data are tagged with metadata describing the content and / or characteristics associated with the data - metadata 1, metadata 2, ..., metadata N. For example, the metadata of each data may include information indicating a timestamp of the data, processing data, keywords indicating a person or other content depicted in the data, and / or other characteristics that may be helpful in determining the validity and content of the overall file, in particular, information for its use as digital evidence, such as described in conjunction with the embodiments discussed below. In addition to the metadata, each data may be labeled with a reference to a previous data REF1, REF2, ..., REF N Marking is done to prevent tampering, gaps in the file, and sequential reference through the file.

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

[0189] Value 676 i is a hash value or other value calculated based on any of the types of information discussed previously. For example, for any given block i , the value of the block can be updated to reflect the processing performed for the 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 being separate from the metadata and header of the file's data, in another embodiment, the value can be based in part or in whole on the metadata.

[0190] Once the blockchain 670 is formed, at any point in time, an immutable chain of custody for a file can be obtained by querying the blockchain to obtain the transaction history of values ​​across blocks. This query or tracking process can start by decrypting the value of the currently included block (e.g., the last (Nth) block), and then continue to decrypt the values ​​of other blocks until the generation block is reached and the original file is restored. This decryption may also involve decrypting the header and file of each block and associated metadata.

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

[0192] Generating a key is similar to creating an account on the blockchain, but without having to actually register it anywhere. In addition, each transaction performed on the blockchain is digitally signed by the sender using his private key. This signature ensures that only the owner of the account can track and process (if within the scope of permissions determined by the smart contract) the files on the blockchain.

[0193] Fig. 7A and Figure 7B Additional examples of use cases for blockchains that may be incorporated and used herein are shown. Specifically, Fig. 7A An example 700 of a blockchain 710 storing machine learning (artificial intelligence) data is shown. Machine learning relies on large amounts of historical data (or training data) to build predictive models to make accurate predictions about new data. Machine learning software (e.g., neural networks, etc.) can often sift through millions of records to discover non-intuitive patterns.

[0194] exist Fig. 7A In the example of , host platform 720 builds and deploys a machine learning model for predictive monitoring of asset 730. Here, host platform 720 may be a cloud platform, an industrial server, a web server, a personal computer, a user device, etc. Asset 730 may be any type of asset (e.g., a machine or equipment, etc.), such as an aircraft, a locomotive, a turbine, a medical machine and equipment, oil and gas equipment, a vessel, a ship, a vehicle, etc. As another example, asset 730 may be an intangible asset.

[0195] Blockchain 710 can be used to significantly improve the training process 702 of the machine learning model and the prediction process 704 based on the trained machine learning model. For example, in 702, instead of requiring data scientists / engineers or other users to collect data, historical data can be stored on blockchain 710 by the asset 730 itself (or through an intermediary, not shown). This can significantly reduce the collection time required by the host platform 720 when performing predictive model training. For example, using smart contracts, data can be directly and reliably transmitted directly from its origin location to blockchain 710. By using blockchain 710 to ensure the security and ownership of the collected data, smart contracts can send data directly from assets to individuals who use the data to build machine learning models. This allows data to be shared between assets 730.

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

[0197] In addition, the training of the machine learning model on the collected data may be subject to multiple rounds of fine-tuning and testing by the host platform 720. Each round can help expand the knowledge of the machine learning model based on additional data or previously unconsidered data. In 702, the different training and testing steps (and the data associated therewith) can be stored on the blockchain 710 by the host platform 720. Each fine-tuning of the machine learning model (e.g., changes in variables, weights, etc.) can be stored on the blockchain 710. This provides a verifiable proof of how the training model was trained and what data was used to train the model. In addition, when the host platform 720 has implemented the final trained model, the resulting model can be stored on the blockchain 710.

[0198] After the model is trained, it can be deployed to a field environment where predictions / decisions can be made based on the execution of the final 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, healthcare machines, etc. In this example, data fed back from asset 730 can be input into the machine learning model and used to make event predictions such as failure events, error codes, etc. Decisions made by executing the machine learning model at the host platform 720 can be stored on the blockchain 710 to provide auditable / verifiable proof. As a non-limiting example, the machine learning model can predict future damage / failure of a part of asset 730 and create an alert or notification to replace the part. The data behind this decision can be stored on the blockchain 710 by the host platform 720. In one embodiment, the features and / or actions described and / or shown herein can occur on or with respect to the blockchain 710.

[0199] New transactions to a blockchain can be gathered into a new block and added to an existing hash. This is then encrypted to create a new hash for the new block. As the transaction is encrypted, it is added to the next list of transactions, and so on. The result is a blockchain that contains the hashes of all previous blocks. The computers storing these blocks periodically compare their hashes to ensure they are all consistent. Any computer that disagrees discards the record that caused the problem. This helps ensure that the blockchain is tamper-resistant, but it is not perfect.

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

[0201] Figure 7B An example 750 of a quantum-secure blockchain 752 that implements quantum key distribution (QKD) to prevent quantum computing attacks is shown. In this example, blockchain users can use QKD to verify each other's identities. This uses quantum particles such as photons to send information, which an eavesdropper cannot copy without destroying them. In this way, the sender and receiver can determine each other's identity through the blockchain.

[0202] exist Figure 7B In the example of , there are four users 754, 756, 758, and 760. Each pair of users can share a key 762 (i.e., QKD) between them. Since there are four nodes in the example, there are six node pairs, so six different keys 762 are used, including QKDAB, QKDAC, QKDAD, QKDBC, QKDBD, and QKDCD. Each pair can create QKD by sending information using quantum particles (such as photons) that an eavesdropper cannot copy without destroying them. In this way, a pair of users can determine each other's identity.

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

[0204] Blocks can be created in a decentralized manner using a broadcast protocol, rather than performing a traditional mining process on the blocks. In 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) on the correct version of the transaction. For example, each node can have a private value (the transaction data of that particular node). In the first round, the nodes transmit their private values ​​to each other. In subsequent rounds, the 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 the blockchain 752. In one embodiment, the features and / or actions described and / or shown herein may occur on or relative to the blockchain 752.

[0205] Figure 8 An exemplary system 800 is shown that supports one or more exemplary embodiments described and / or illustrated herein. The system 800 includes a computer system / server 802 that can operate with many other general or special computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations suitable for use with the computer system / server 802 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems or devices, etc.

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

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

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

[0209] Computer system / server 802 generally includes various computer system readable media. Such media can be any available media that can be accessed 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 flow charts 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 and writing from non-removable non-volatile magnetic media (not shown, commonly referred to as "hard drive"). Although not shown, a disk drive for reading from or writing to a removable non-volatile disk (e.g., "floppy disk"), and an optical drive for reading from or writing to a removable non-volatile optical disk (e.g., CD-ROM, DVD-ROM or other optical media) may be provided. In such a case, each may be connected to the bus via one or more data medium interfaces. As will be further shown and described below, memory 806 may include at least one program product having a set (eg, at least one) of program modules configured to perform the functions of different embodiments of the application.

[0210] A program / utility 816 having a set (at least one) of program modules 818, as well as an operating system, one or more application programs, other program modules, and program data, may be stored in memory 806 by way of example and not limitation. Each or some combination of the operating system, one or more application programs, other program modules, and program data may include an implementation of a network environment. Program modules 818 generally perform the functions and / or methods of different embodiments of the application as described herein.

[0211] As will be appreciated by those skilled in the art, aspects of the present application may be embodied as systems, methods, or computer program products. Therefore, aspects of the present application may take the form of a complete hardware embodiment, a complete software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, which may be collectively referred to herein as a "circuit", "module", or "system". In addition, aspects of the present application may take the form of a computer program product embodied in one or more computer-readable media having a computer-readable program code embodied thereon.

[0212] The computer system / server 802 may also communicate with one or more external devices 820 (e.g., keyboards, pointing devices, displays 822, etc.); and / or any device that enables the computer system / server 802 to communicate with one or more other computing devices (e.g., network cards, modems, etc.). Such communication may occur through an I / O interface 824. In addition, the computer system / server 802 may communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet) through a network adapter 826. As shown, the network adapter 826 communicates with other components of the computer system / server 802 through 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 archiving storage systems, etc.

[0213] Although exemplary embodiments of at least one of the systems, methods and non-transient computer-readable media have been shown in the accompanying drawings and described in the foregoing detailed description, it will be understood that the present application is not limited to the disclosed embodiments, but is capable of many rearrangements, modifications and substitutions as set forth and defined by the following claims. For example, the capabilities of the systems of the various drawings may be performed by one or more modules or components described herein or in a distributed architecture, and may include a transmitter, a receiver or a pair of transmitters, receivers. For example, all or part of the functions performed by a separate module may be performed by one or more of these modules. Further, the functions described herein may be performed at different times and with respect to different events inside or outside the module or component. In addition, the information sent between the modules may be sent between the modules via a data network, the Internet, a voice network, an Internet protocol network, a wireless device, a wired device and / or via at least one of a plurality of protocols. Moreover, messages sent or received by any module may be sent or received directly and / or via one or more other modules.

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

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

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

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

[0218] It will be readily understood that the components of the present application, as generally described and illustrated in the drawings herein, may be arranged and designed in a wide 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 present application.

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

[0220] Although preferred embodiments of the present application have been described, it should be understood that the described embodiments are merely illustrative and that the scope of the present application will be limited solely by the appended claims when considering the full range of equivalents and modifications thereto (e.g., protocols, hardware devices, software platforms, etc.).< / publicinfo> < / encryptedinfo>

Claims

1. A processor node of a blockchain network, the processor node comprising: processor; a memory having machine-readable instructions stored thereon, the machine-readable instructions, when executed by the processor, causing the processor to: Generate an identifier (ID) of an asset producer node of the blockchain network; Mapping the ID to the identity of the asset producer node; adding the asset producer node to a supply blockchain in the blockchain network in response to a request from a supplier node of the blockchain network; authorizing the ID to the supplier node; identifying that information in a request from another provider node of the blockchain network matches information in a request from the provider node; as well as Based on the matching, data encrypted by the private encryption key of the asset producer node is provided to the other supplier node.

2. The processor node according to claim 1, wherein: The instructions further cause the processor to store the ID and a private encryption key of the asset producer node on a ledger of the supply blockchain in response to the request.

3. The processor node according to claim 1, wherein: The instructions further cause the processor to upload an asset traceability event based on the ID.

4. The processor node according to claim 3, wherein: The asset traceability event is referenced by the supplier node.

5. The processor node according to claim 1, wherein: The match contains at least one element associated with the mapped ID.

6. The processor node according to claim 1, wherein: The instructions further cause the processor to process invitations from a plurality of supplier nodes to the asset producer node to join the supply blockchain.

7. A method for a processor node of a blockchain network, comprising: Generating, by a processor node of the blockchain network, an identifier (ID) of an asset producer node of the blockchain network; The processor node maps the ID to the identity of the asset producer node; adding, by the processor node, the asset producer node to a supply blockchain in the blockchain network in response to a request from a supplier node of the blockchain network; The processor node authorizes the ID to the supplier node; identifying, by the processor node, that information in a request from another provider node of the blockchain network matches information in a request from the provider node; as well as The processor node provides data encrypted by the private encryption key of the asset producer node to the other supplier node based on the matching.

8. The method according to claim 7, further comprising: In response to the request, storing the ID and the private encryption key of the asset producer node on a ledger of the supply blockchain.

9. The method according to claim 7, further comprising: Upload asset traceability events based on the ID.

10. The method according to claim 9, wherein: The asset traceability event is referenced by the supplier node.

11. The method according to claim 7, wherein: The match contains at least one element associated with the ID.

12. The method of claim 7, further comprising processing invitations from a plurality of supplier nodes to the asset producer node to join the supply blockchain.

13. A non-transitory computer-readable medium comprising instructions that, when executed by a processor in a processing node of a blockchain network, cause the processor to perform: Generate an identifier ID of the asset producer node of the blockchain network; Mapping the ID to the identity of the asset producer node; adding the asset producer node to a supply blockchain in the blockchain network in response to a request from a supplier node of the blockchain network; authorizing the ID to the supplier node; identifying that information in a request from another provider node of the blockchain network matches information in a request from the provider node; as well as Based on the matching, data encrypted by the private encryption key of the asset producer node is provided to the other supplier node.

14. The non-transitory computer-readable medium of claim 13, further comprising instructions that, when read by the processor, cause the processor to store the ID and the private encryption key of the asset producer node on a ledger of the supply blockchain in response to the request.

15. The non-transitory computer readable medium of claim 13, further comprising instructions that, when read by the processor, cause the processor to upload an asset traceability event based on the ID, wherein: The asset traceability event is referenced by the supplier node.

16. The non-transitory computer readable medium of claim 13, wherein: The match contains at least one element associated with the ID.

17. The non-transitory computer-readable medium of claim 13, further comprising causing the processor, when read by the processor, to process invitations from a plurality of the supplier nodes to the asset producer node to join the supply blockchain.

Images