Integrating Device Identity into a Blockchain Permissions Framework

Abstract

A computer-implemented method for configuring a blockchain network, a computer program product for integrating device identity into a blockchain permissioned framework, and a blockchain network. One embodiment may include registering a device with a separator node of the blockchain network, creating a profile for the device by a processor of the separator node based on the registration, and performing a pass-through service for the device by the processor of the separator node. The registration may include receiving, via a network interface, an immutable device identity from the device.

Description

[Technical field]

[0001] The present disclosure relates to configuration and management of blockchain networks, and more particularly, to configuration and management of "Internet of Things" (IoT) devices in blockchain networks. [Background technology]

[0002] The development of the EDVAC system in 1948 is often cited as the beginning of the computer age. Since then, computer systems have evolved into highly complex devices. Modern computer systems typically contain a combination of sophisticated hardware and software components, application programs, operating systems, processors, buses, memory, and input / output devices. Advances in semiconductor processing technology and computer architectures have continuously increased performance, and more advanced computer software has evolved to take advantage of this increased performance, making today's computer systems much more powerful than they were just a few years ago.

[0003] One application of this new capability is the blockchain, which generally refers to a shared, immutable ledger that facilitates the process of recording transactions and tracking assets in a business network. Assets can be tangible (houses, cars, cash, land) or intangible (intellectual property, patents, copyrights, brands). Virtually anything of value can be tracked and traded on a blockchain network, reducing risk and costs for all involved. Summary of the Invention

[0004] According to an embodiment of the present disclosure, a computer-implemented method for configuring a blockchain network is provided. In one embodiment, the method may include registering a device with a separator node of a blockchain network, creating, by a processor of the separator node, a profile of the device based on the registration, and performing, by a processor of the separator node, a pass-through service for the device. The registration may include receiving, by a network interface, an immutable device identity from the device.

[0005] According to an embodiment of the present disclosure, a computer program product for integrating device identity into a permission framework of a blockchain network is provided. The computer program product may include a computer-readable storage medium having program instructions embodied therein. The program instructions may cause the processor to: provide, by a node, a pass-through security service; register, by the node, a device as a registered node on the blockchain network; create, by the node based on the registration, a virtual profile for the device in a secure enclave; maintain a transaction correlation table for the device; and facilitate, by the node, transaction commitment and client communication for the device. The device in some embodiments may have a physical unclonable function associated therewith. The registration may include the device sending a physical unclonable function challenge response to the node. The pass-through security service may include a trusted registration of peers in a blockchain network. The transaction correlation table may include a record of blockchain essentials associated with the device, the blockchain essentials including a channel, an endorsement policy, and a delegation authority proof.

[0006] Preferably, the present invention provides a method further comprising updating a transaction correlation table of the device, the transaction correlation table including a record of a blockchain function associated with the device.

[0007] Preferably, the present invention provides a method, wherein the blockchain function comprises maintaining an endorsement policy and delegation authority certificate for the blockchain network.

[0008] Preferably, the present invention provides a method further comprising receiving a membership service directive directed to the device from a node of a blockchain network, and updating the transaction correlation table of the device in response to the membership service directive.

[0009] Preferably, the present invention provides a method further comprising receiving a membership service directive from the device directed to the blockchain network, and updating the transaction correlation table of the device in response to the membership service directive.

[0010] Preferably, the present invention provides a method, comprising: a pass-through service creating a channel for communication between peers on the blockchain network.

[0011] Preferably, the present invention provides a method wherein the pass-through service includes facilitating transactions on behalf of the device.

[0012] Preferably, the present invention provides a method, wherein the pass-through service includes facilitating communications between the device and other nodes of the blockchain network.

[0013] Preferably, the present invention provides a method further comprising the pass-through service proxying all communications between the device and the other nodes of the blockchain network.

[0014] Preferably, the present invention provides a method, wherein the registration further comprises registering the device with a membership service of the blockchain network.

[0015] Preferably, the present invention provides a method, wherein said registration enables said device to be registered as a peer node on a private blockchain network.

[0016] Preferably, the present invention provides a method wherein the profile includes a virtual profile for the device, the virtual profile including an encryption key pair for the device, the encryption key pair being stored in a secure repository associated with the separator node.

[0017] Preferably, the present invention provides a method, wherein said secure repository comprises a hardware security architecture.

[0018] Preferably, the present invention provides a method further comprising receiving a registration request from the device, in response to the registration request, sending a challenge to the device, verifying a response from the device, and in response to successful verification, registering the device.

[0019] Preferably, the present invention provides a method, wherein said immutable device identity comprises a Physical Unclonable Function (PUF) associated with said device.

[0020] Preferably, the present invention provides a method, wherein the PUF automatically provides cryptographic proof for an immutable registration key, and the immutable registration key is used as an identity mechanism in the blockchain network.

[0021] Preferably, the invention provides a method, wherein the devices are Internet of Things (IoT) devices and the partition node maintains a distributed ledger on behalf of the IoT devices. Preferably, the invention provides a method, wherein said separator node comprises a dedicated hardware co-processor for executing said pass-through service.

[0022] According to an embodiment of the present disclosure, a blockchain network is provided. One embodiment includes a plurality of relatively lower capability peers and at least one relatively higher capability peer. Each of the relatively lower capability peers may have an immutable device identity associated therewith. The relatively higher capability peer may execute workloads requiring computing power above one or more predefined thresholds on behalf of the plurality of the relatively lower capability peers.

[0023] The above summary is not intended to describe each illustrated embodiment or every implementation of the present disclosure.

[0024] The drawings contained herein are incorporated in and constitute a part of this specification. They illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure. The drawings are merely illustrative of particular embodiments and are not intended to limit the disclosure. [Brief description of the drawings]

[0025] [Figure 1] FIG. 1 illustrates an embodiment of a data processing system (DPS), consistent with some embodiments. [Diagram 2] FIG. 1 illustrates a cloud computing environment, consistent with some embodiments. [Diagram 3] FIG. 1 illustrates an abstraction model layer, consistent with some embodiments. [Figure 4]FIG. 1 is a system diagram of an embodiment of a blockchain network, consistent with some embodiments. [Diagram 5] 1 is a flowchart illustrating an example of a pass-through service provided by a separator node during operation, consistent with some embodiments. [Figure 6A] 11 is a flowchart illustrating another example of a pass-through service provided by an operational separator node, consistent with some embodiments. [Figure 6B] 11 is a flowchart illustrating another example of a pass-through service provided by an operational separator node, consistent with some embodiments. [Figure 7A] FIG. 1 illustrates an example blockchain architecture configuration, consistent with some embodiments. [Figure 7B] FIG. 1 illustrates a blockchain transaction flow, consistent with some embodiments. [Figure 8A] FIG. 1 is a flow diagram consistent with certain embodiments. [Figure 8B] FIG. 11 is a further flow diagram consistent with certain embodiments. [Figure 8C] FIG. 1 illustrates an example system configured to perform one or more operations described herein, consistent with some embodiments. [Figure 8D] FIG. 1 illustrates another example system configured to perform one or more operations described herein, consistent with some embodiments. [Figure 8E] FIG. 1 illustrates a further exemplary system configured to utilize smart contracts, consistent with some embodiments. [Figure 8F] FIG. 1 illustrates a system including a blockchain, consistent with some embodiments. [Figure 9A] FIG. 1 illustrates a process by which a new block is added to a distributed ledger, according to an example embodiment. [Figure 9B]FIG. 13 illustrates the contents of a new data block according to an exemplary embodiment. [Figure 9C] FIG. 1 illustrates a block chain for digital content, according to an exemplary embodiment. [Figure 9D] FIG. 1 illustrates a block diagram that may represent the structure of a block in a blockchain, according to an exemplary embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0026] While the invention is susceptible to various modifications and alternative forms, specific details thereof have been shown by way of example in the drawings and may be described in detail. It should be understood, however, that the intention is not to limit the invention to the particular embodiments described. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the scope of the invention.

[0027] Aspects of the present disclosure relate to the configuration and management of blockchain networks, and more particularly to the configuration and management of IoT devices in blockchain networks. The present disclosure is not necessarily limited to such applications, but various aspects of the present disclosure may be understood through the discussion of various examples using this context.

[0028] The IoT generally refers to the networking and networking of special-purpose computing systems such as devices, vehicles, signs, buildings, and other objects that are embedded with electronics, software, sensors, or actuators, or a combination thereof, and that may enable these systems to collect and exchange data with other IoT devices and / or computer systems. The IoT enables these objects to be sensed or controlled remotely across existing network infrastructures, creating opportunities for more direct integration of the physical world into computer-based systems, leading to improved efficiency, accuracy, and economic benefits in addition to reduced human intervention. When physical-world objects are augmented with IoT sensors and actuators, the combination becomes an instance of a more general class of cyber-physical systems, which also includes technologies such as smart grids, virtual power plants, smart homes, intelligent transportation, and smart cities.

[0029] The world is currently experiencing a dramatic increase in the number of IoT devices used in commercial, industrial, and private environments. Workplaces, industrial environments, home environments, public buildings, and city streets are increasingly equipped with network-enabled devices that can connect with other equipment, receive commands, transmit information, and perform specific functions. Some estimates predict that there will eventually be more than 50 billion IoT devices - intelligent devices that can communicate with each other.

[0030] However, IoT devices are often designed to be small, inexpensive, and lightweight. They may also be designed for passive operation (e.g., using only wireless energy transmitted by a reader). These constraints typically translate into IoT devices having relatively little local computing power (e.g., having processor speeds, memory sizes, or storage sizes, or combinations thereof, less than one or more predefined thresholds), especially compared to modern laptop computers, smartphones, and server computers (e.g., having processor speeds, memory sizes, or storage sizes, or combinations thereof, greater than one or more predefined thresholds).

[0031] This lack of local computing power can pose difficulties in processing machine-to-machine (M2M) transactions, such as blockchain network transactions involving IoT devices. For example, one significant problem in some types of blockchain networks is establishing the identity and trustworthiness of new peer devices (i.e., IoT devices in this illustrative example). A related problem in some types of blockchain networks can be a registry and central management of those peer devices. Various options have been explored to solve this problem, ranging from using identity management for IoT and other devices to verifying and attesting device signatures, but none of these options have proven adequate for low-capability computing systems such as many IoT devices.

[0032] Thus, some embodiments of the present disclosure may provide immutable device identities, such as physical unclonable functions, that may be integrated into the processing node services and / or infrastructure of a blockchain network. Some embodiments may employ immutable device identities as a registration mechanism and may provide pass-through trust services to allow lower computing power devices to participate in the blockchain network. These pass-through services may include registration, endorsement, ledger maintenance, channel definition and maintenance, database pointer tracking, and delegation authority proof.

[0033] Some embodiments may integrate immutable device identities into the permission framework of a blockchain network with low processing overhead to enable low-power devices, such as IoT devices, to meet the requirements of computational nodes in a blockchain network. One feature and advantage of these embodiments is that they may enable trust of low-power devices and sensors, such as IoT devices, to participate in a blockchain network.

[0034] One feature and advantage of these embodiments is that the immutable device identity may automatically provide a cryptographic proof to an immutable registration key, which may then be used as an identity mechanism in the blockchain network. A representative node may then be selected as a separator node, which may use this registration key to authenticate IoT devices and establish trust. Once trust is established, the separator node may provide pass-through services for and / or on behalf of IoT devices, such as registering with the network, maintaining a distributed ledger on behalf of the IoT devices, managing elements of the channel, providing endorsement functions, and other client / peer related activities. In this manner, some embodiments of the present disclosure may improve M2M and / or device-to-device communications, as separator nodes may provide a localized version of transaction processing that enables network processing efficiencies.

[0035] The present disclosure may also improve the efficiency of blockchain networks. Separator nodes may act as dedicated nodes to handle specific performance and computationally intensive workloads (e.g., workloads that require processor speed, memory size, or storage size, or a combination thereof, above one or more predefined thresholds). Some embodiments may further optimize these specialized nodes with hardware configurations and / or co-processors specifically designed for these workloads. For example, separator nodes may include specialized input / output processors (IOPs) to offload some of the communication overhead from the central processing unit (CPU), a larger amount of random access memory to store transactions for multiple IoT devices, or a co-processor to perform cryptography on behalf of IoT devices, or a combination thereof.

[0036] Although the embodiments of the present disclosure are generally described with reference to a practical model for M2M and device-to-device (D2D) participation in secure transaction processing between IoT devices, they may be applied to a variety of other applications. For example, some embodiments may be used as various proxy services and / or with corresponding extensions of key management to extend authorized networks to end users / consumers using Physical Unclonable Function (PUF) enabled mobile devices.

[0037] <Data Processing System> FIG. 1 illustrates an embodiment of a data processing system (DPS) 100a consistent with some embodiments. The DPS 100a in this embodiment may be implemented as a personal computer, a server computer, a portable computer such as a laptop or notebook computer, a personal digital assistant (PDA), a tablet computer or a smartphone, a processor embedded in a larger device such as an automobile, an airplane, a teleconferencing system, a home appliance, a smart device, or any other suitable type of electronic device. Furthermore, there may be components other than or in addition to those shown in FIG. 1, and the number, type, and configuration of such components may vary. Furthermore, FIG. 1 merely illustrates representative major components of the DPS 100a, and the individual components may be more complex than depicted in FIG. 1.

[0038] The data processing system 100a of FIG. 1 includes multiple central processing units 110a-110d (generally referred to herein as processors 110 or CPUs 110) connected to a memory 112, a mass storage interface 114, a terminal / display interface 116, a network interface 118, and an input / output ("I / O") interface 120 by a system bus 122. The mass storage interface 114 in this embodiment couples the system bus 122 to one or more mass storage devices, such as a direct access storage device 140, a universal serial bus ("USB") storage device 141, or a read / write optical disk drive 142. The network interface 118 allows the DPS 100a to communicate with another DPS 100b via a communication medium 106. The memory 112 also includes an operating system 124, multiple application programs 126, and program data 128.

[0039] The embodiment of data processing system 100a of FIG. 1 is a general-purpose computing device. Processor 110 may therefore be any device capable of executing program instructions stored in memory 112, and may itself be comprised of one or more microprocessors and / or integrated circuits. In this embodiment, DPS 100a includes multiple processors and / or processing cores, as typically found in larger, more powerful computer systems, although in other embodiments, DPS 100a may include a single processor system or a single processor designed to emulate a multiprocessor system or / and. Additionally, processor 110 may be implemented using multiple heterogeneous data processing systems 100a, where a main processor exists with secondary processors on a single chip. As another illustrative example, processor 110 may be a symmetric multiprocessor system including multiple processors of the same type.

[0040] When data processing system 100a boots, its associated processor 110 initially executes program instructions that make up an operating system 124, which manages the physical and logical resources of DPS 100a. These resources include memory 112, mass storage interface 114, terminal / display interface 116, network interface 118, and system bus 122. As with processor 110, some DPS 100a embodiments may utilize multiple system interfaces 114, 116, 118, 120, and bus 122, which in turn may each include their own separate, fully programmed microprocessor.

[0041] Instructions for the operating system, applications, or programs, or combinations thereof (commonly referred to as "program code," "computer usable program code," or "computer readable program code") may be initially located on mass storage devices 140, 141, 142, which are in communication with processor 110 via system bus 122. Program code in different embodiments may be implemented on different physical or tangible computer readable media, such as system memory 112 or mass storage devices 140, 141, 142. In the illustrative example of FIG. 1, the instructions are stored in a functional form of persistent storage on direct access storage device 140. These instructions are then loaded into memory 112 for execution by processor 110. However, program code may also be located in a functional form on computer readable medium 142, which is selectively removable and may be loaded or transferred to DPS 100a for execution by processor 110.

[0042] The system bus 122 may be any device that facilitates communication between the processor 110, the memory 112, and the interfaces 114, 116, 118, 120. Additionally, although the system bus 122 in this embodiment is a relatively simple single bus structure providing a direct communication path between the system buses 122, other bus structures may be used consistent with this disclosure including, but not limited to, point-to-point links, multiple hierarchical buses in a hierarchical, star or web configuration, parallel and redundant paths, and the like.

[0043] Memory 112 and mass storage devices 140, 141, 142 work in concert to store operating system 124, application programs 126, and program data 128. In this embodiment, memory 112 is a random-access semiconductor device capable of storing data and programs. While FIG. 1 conceptually depicts the device as a single monolithic entity, memory 112 in some embodiments may be a more complex arrangement, such as a hierarchy of caches and other memory devices. For example, memory 112 may exist in multiple levels of caches, and these caches may be further divided by function, such that one cache holds instructions while another holds non-instruction data used by one or more processors. Memory 112 may be further distributed and associated with different processors 110 or sets of processors 110, as is known in any of a variety of so-called non-uniform memory access (NUMA) computer architectures. Additionally, some embodiments may utilize a virtual addressing mechanism that enables DPS 100a to operate as if it had access to a large, single storage entity rather than access to multiple smaller storage entities, such as memory 112 and mass storage devices 140, 141, 142.

[0044] Although the operating system 124, application programs 126, and program data 128 are illustrated as being contained within memory 112, some or all of them may be located on different physical computer systems and, in some embodiments, may be accessed remotely, for example, via communications medium 106. Thus, although the operating system 124, application programs 126, and program data 128 are illustrated as being contained within memory 112, these elements are not necessarily all contained entirely on the same physical device at the same time and may even reside in the virtual memory of another DPS 100a.

[0045] The system interfaces 114, 116, 118, 120 support communication with various storage and I / O devices. The mass storage interface 114 supports attachment of one or more mass storage devices 140, 141, 142 that are typically rotating magnetic disk drive storage devices, solid state storage devices (SSDs) that use integrated circuit assemblies as memory to persistently store data, typically using flash memory, or a combination of the two. However, the mass storage devices 140, 141, 142 may include other devices including an array of disk drives (commonly referred to as a RAID array) configured to appear to a host as a single large storage device, or archival storage media (hard disk drives, tape (e.g., mini-DV), writable compact disks (e.g., CD-R and CD-RW), digital versatile disks (e.g., DVD, DVD-R, DVD+R, DVD+RW, DVD-RAM), holographic storage systems, Blue Laser Disk, IBM Millipede devices, etc.), or both.

[0046] The terminal / display interface 116 is used to directly connect one or more display units, such as a monitor 180, to the data processing system 100a. These display units 180 may be non-intelligent (i.e., dumb) terminals, such as LED monitors, or may themselves be fully programmable workstations used to enable IT administrators and customers to communicate with the DPS 100a. However, it should be noted that while the display interface 116 is provided to support communication with one or more display units 180, the DPS 100a does not necessarily require a display unit 180, as all necessary interaction with customers and other processes can occur via the network interface 118.

[0047] The communication medium 106 may be any suitable network or combination of networks and may support any suitable protocol suitable for communication of data and / or code between the multiple DPSs 100a. Thus, the network interface 118 may be any device that facilitates such communication, regardless of whether the network connection is made using current analog or digital technologies or both, or through some future network mechanism. Suitable communication mediums 106 include, but are not limited to, networks implemented using one or more of the "InfiniBand" or IEEE (Institute of Electrical and Electronics Engineers) 802.3x "Ethernet" specifications, cellular transmission networks, wireless networks implementing any of the IEEE 802.11x, IEEE 802.16, General Packet Radio Service ("GPRS"), Family Radio Service (FRS) or Bluetooth specifications, ultra-wideband ("UWB") technologies such as those described in FCC 02-48, or the like. Those skilled in the art will appreciate that many different networks and transport protocols can be used to implement the communication medium 106. The Transmission Control Protocol / Internet Protocol ("TCP / IP") suite includes suitable network and transport protocols.

[0048] <Cloud Computing> 2 is a diagram illustrating a cloud environment including one or more DPSs 100a, consistent with some embodiments. Although this disclosure includes detailed descriptions of cloud computing, implementation of the teachings described herein is not limited to a cloud computing environment. Rather, embodiments of the invention may be practiced in conjunction with any other type of computing environment now known or developed in the future.

[0049] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal administrative effort or interaction with a service provider. The cloud model may include at least five characteristics, at least three service models, and at least four implementation models.

[0050] The characteristics are as follows: On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity, such as server time or network storage, automatically as needed, without the need for human interaction with the service provider. Broad network access: Computing power is available over the network and can be accessed through standard mechanisms, facilitating usage by heterogeneous thin- or thick-client platforms (e.g., cell phones, laptops, PDAs). Resource Pooling: Computing resources from a provider are pooled and offered to multiple consumers using a multi-tenant model. Different physical and virtual resources are dynamically allocated and reallocated depending on demand. Consumers generally have no control or knowledge of the exact location of the resources provided to them, so there is a sense of location independence, although consumers may be able to determine location at a higher level of abstraction (e.g. country, state, data center). Rapid elasticity: Computing capacity can be provisioned quickly and elastically, sometimes automatically, to scale out immediately and to be released quickly to scale in immediately. To the consumer, the computing capacity available for provisioning often appears unlimited and can be purchased at any time and in any quantity. · Metered Services: Cloud systems leverage metering capabilities at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, active customer accounts) to automatically control and optimize resource usage. Resource usage can be monitored, controlled, and reported to provide transparency to both providers and consumers of the services utilized.

[0051] The service model is as follows: Software as a Service (SaaS): The functionality offered to the consumer is the availability of the provider's applications running on a cloud infrastructure that can be accessed from a variety of client devices via a thin-client interface such as a web browser (e.g. webmail). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even the individual application functions, except for limited customer-specific application configuration settings. Platform as a Service (PaaS): The functionality offered to the consumer is the deployment onto a cloud infrastructure of applications that the consumer creates or acquires using programming languages ​​and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the configuration of the hosting environment. Infrastructure as a Service (IaaS): The functionality offered to the consumer is the provision of processors, storage, networking, and other basic computing resources on which the consumer can deploy and run any software, including operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating systems, storage, and deployed applications, and in some cases has partial control over some network components (e.g., host firewalls).

[0052] The deployment model is as follows: Private Cloud: The cloud infrastructure is dedicated to a specific organization. It can be managed by that organization or a third party and can exist on-premise or off-premise. Community Cloud: The cloud infrastructure is shared by multiple organizations to support a specific community with common concerns (e.g., mission, security requirements, policies, and compliance). The cloud infrastructure can be managed by those organizations or a third party and can exist on-premise or off-premise. Public Cloud: The cloud infrastructure is available to the general public or large industry organizations and is owned by an organization that sells cloud services. Hybrid Cloud: This cloud infrastructure combines two or more cloud models (private, community or public), each of which retains its inherent nature but is bound by standards or specific technologies that enable data and application portability (e.g. cloud bursting for load balancing between clouds).

[0053] A cloud computing environment is a service-oriented environment with an emphasis on statelessness, low coupling, modularity and semantic interoperability. At the core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0054] Referring now to FIG. 2, an exemplary cloud computing environment 50 is depicted. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10, to which local computing devices used by cloud consumers (e.g., PDA or cell phone 54A, desktop computer 54B, laptop computer 54C, or automobile computer system 54N, or combinations thereof, etc.) can communicate. The nodes 10 can communicate with each other. The nodes 10 can be physically or virtually grouped (not shown) in one or more networks, such as, for example, a private, community, public, or hybrid cloud, or combinations thereof, as described above. This allows the cloud computing environment 50 to provide infrastructure, platform, or software, or combinations thereof, as a service, for which the cloud consumer does not need to maintain resources on the local computing device. It should be understood that the types of computing devices 54A-N shown in FIG. 2 are merely exemplary, and that the computing nodes 10 and the cloud computing environment 50 can communicate with any type of electronic device over any type of network or network addressable connection (e.g., using a web browser), or both.

[0055]

[0033] Referring now to Figure 3, there is shown a set of functional abstraction layers provided by cloud computing environment 50 (Figure 2). It should be understood in advance that the components, layers and functions shown in Figure 2 are merely exemplary and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0056] Hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframe 61, reduced instruction set computer (RISC) architecture based servers 62, servers 63, blade servers 64, storage devices 65, and networks and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0057] The virtualization layer 70 provides an abstraction layer from which the following virtual entities can be provided, for example: virtual servers 71, virtual storage 72, virtual networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75.

[0058] By way of example, the management layer 80 may provide the following functions: Resource provisioning 81 allows dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 82 allows cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources. By way of example, these resources may include application software licenses. Security allows for identification and verification of cloud consumers and tasks as well as protection for data and other resources. User portal 83 provides consumers and system administrators with access to the cloud computing environment. Service level management 84 allows for allocation and management of cloud computing resources such that requested service levels are met. Service level agreement (SLA) planning and fulfillment 85 allows for pre-arranging and procurement of anticipated future needs for cloud computing resources according to SLAs.

[0059] The workload layer 90 provides examples of functionality available to a cloud computing environment. Examples of workloads and functionality that can be provided from this layer include mapping and navigation 91, software development and lifecycle management 92, virtual classroom instruction delivery 93, data analytics processing 94, transaction processing 95, and blockchain nodes 96.

[0060] <Blockchain system> 4 is a system diagram of an embodiment of a blockchain network 400 consistent with some embodiments. Advantageously, the blockchain network 400 of the present embodiment may provide a PUF that can automatically provide cryptographic proof for immutable registration keys used as an identity mechanism in the blockchain. The network 400 may include a number of relatively low computing power IoT devices 410 (individually and collectively, only some of which are labeled for clarity) that are enabled with PUFs, a blockchain network 420 that maintains a distributed ledger 425, and a separator node 430. The blockchain network 420 in some embodiments may be created using or compatible with an existing blockchain infrastructure, such as the Hyperledger® framework (Hyperledger is a trademark of The Linux Foundation), or both. The separator node 430, in turn, may provide pass-through services for the blockchain network 420, such as registering with the blockchain network 420, maintaining a distributed ledger 425 on behalf of registered IoT devices 410, maintaining a transaction correlation table 435 related to the registered IoT devices 410, providing channel elements, providing endorsement functionality, and other client-related blockchain activities.

[0061] The IoT devices 410 in this embodiment may participate in an M2M or device-driven transaction network, such as a blockchain network 420. The IoT devices 410, in turn, may each be enabled with a PUF, such as an SRAM PUF, a delay PUF, a butterfly PUF, a metal resistive PUF, a bistable ring PUF, a DRAM PUF, a digital PUF, an oxide break PUF, a coating PUF, a quantum electronic PUF, a magnetic PUF, an optical PUF, a quantum optical PUF, an RF PUF, etc. The PUFs in some embodiments may provide a physically defined "digital fingerprint" output in response to predetermined inputs and conditions (challenges) that may serve as a unique identifier for the IoT device 410.

[0062] The blockchain network 420 in this embodiment may include a transaction processing infrastructure that provides trust and transaction processing facilities, including management of cryptographic artifacts. Nodes 410 on the blockchain network may cooperatively maintain a distributed ledger 425.

[0063] The separator node 430 in this embodiment may typically be a representative node running on a DPS 100a having relatively high computing power in the cloud computing environment 50, and may provide pass-through services such as registration into the blockchain network 420, maintain a distributed ledger 425 on behalf of the relatively lower powered IoT devices 410, and in some embodiments may include channel elements, endorsement functions, and other client-related or peer-related activities.

[0064] The separator node 430 in some embodiments may provide a unique interface for virtual and secure device-to-device communication with reduced communication workload between the IoT device 410 and the blockchain network 420. Thus, the separator node 430 may perform some or all of the following methods: a. Provider Pass-Through Security Services - This method may extend from the initial registration of the IoT device 410 to all communications with the IoT device PUF-enabled devices. b. Initial Registration - This method allows the IoT device 410 to send a PUF response to a pass-through service to perform trusted registration with the membership service. This method may allow the IoT device 410 to be registered as a node on the blockchain network 420. c. Virtual Secure Profile Creation—Upon registration, the method allows the node to create a virtual profile for the IoT device 410 within the secure enclave without the use of a Trusted Execution Environment (TEE), Trusted Computing Base (TCB), or similar architecture to facilitate security. Virtual profiles with all the cryptographic artifacts may be created on the node, and these virtual profiles may transact with each other on behalf of the IoT device 410, especially when the IoT device 410 is at low power. d. Secure Key Management - This method provides a secure profile for protecting the cryptographic artifact, the PUF, and while the design calls for a Hardware Security Module (HSM), it would not need to be a specialized hardware TEE / TCB and HSM enabled since the PUF-enabled IoT device 410 is already specialized hardware with unclonable addresses.

[0065] The delimiter node 430 may use these methods to maintain a transaction correlation table (not shown). This table may be in the form of a table that maintains records of the state and configuration of the blockchain network 420, such as channels, endorsement policies, database pointers, and delegation authority proofs. The delimiter node 430 in this embodiment may also participate in transaction finality. That is, in addition to acting as a maintainer of cryptographic artifacts and proxy services, this node 430 may participate in transaction finality, including transaction commitments and client communications.

[0066] The separator node 430 in some embodiments may act as a decentralized / focused certificate authority (CA) for a subset of the hardware-based identity devices, as well as a proxy for the blockchain network 420, based on public key infrastructure (PKI) membership. The separator node 430 in these embodiments may both register and proxy between the hardware-based identity devices and the network. As a result, an external certificate authority may not be aware of such registered devices, given the decentralized nature, temporary registration, and the significant number of devices to which transactions are submitted.

[0067] <Pass-through service> FIG. 5 is a flow chart illustrating an example method 500 of a pass-through service provided by a separator node 430 in operation, consistent with some embodiments. In the embodiment of FIG. 5, the pass-through service can act as one server with which all of the IoT and / or low-power PUF devices communicate, simplifying communication and security. The separator node 430 can register the devices, create virtual profiles, perform all transactions between virtual profiles, etc. More specifically, in operation 505, the separator node 430 can initialize and begin providing the pass-through service. The separator node 430 can then receive a registration request from one of the IoT devices 410 in operation 510. In response, the separator node can verify the PUF associated with that IoT device 410 in operation 512. In some embodiments, this can include sending a challenge to the IoT device 410 and receiving a response, etc. In some embodiments, the correct response may have been previously measured / calculated by the manufacturer of the IoT device 410 and communicated over an independent secure channel. In other embodiments, the response is defined as correct and used to prevent future attacks against the blockchain network 420.

[0068] In some embodiments, if the challenge / response handshake is successfully verified or otherwise completed, the separator node 430 may register the IoT device 410 with the virtual server profile in operation 515. Optionally, the separator node 430 may also create a public / private key pair for the IoT device 410 in operation 520 and store the key pair in a secure repository in operation 525.

[0069] Next, at operation 530, the separator node 430 may receive a membership service directive from either the IoT device 410 or another node in the blockchain network 420. In response, depending on the nature of the request (e.g., whether it is a request to create a new channel or a new communication directed to an existing channel), the separator node 430 may either create a new entry in a transaction correlation table or reference an existing entry in the transaction correlation table at operation 540. In either case, the separator node 430 responds to the membership service directive at operation 550.

[0070] 6A is a flow chart illustrating another exemplary method 600 of pass-through services provided by an operating separator node 430, consistent with some embodiments. The separator node 430 in this example acts as a proxy for the IoT devices 410 (i.e., an identity peer node). At operation 605, the separator node 430 may receive a proposed transaction to be added to the distributed ledger 425 from one of the IoT devices 410. At operation 610, the separator node 430 may sign the proposed transaction on its behalf, in some embodiments using its dedicated PKI hardware, using a key pair stored in its secure vault associated with one of the IoT devices 410 and signed by a certificate authority. At operation 612, the separator node 430 may store a pointer to the proposed transaction in its transaction correlation table.

[0071] In operation 615, the separator node 430 may submit the proposed transaction to one of the endorser nodes of the blockchain network 420, which will process the proposed transaction normally according to the protocols of the blockchain network 420. This may include using a certificate authority to verify the identity of the IoT device. Then, in operation 620, the separator node 430 may submit the endorsed transaction to one of the ordering nodes in the blockchain network 420, which will also process the proposed transaction normally according to the protocols of the blockchain network 420. This may again include using a certificate authority to verify the identity of the IoT device 410. In operation 625, the blockchain network 420 may finalize the proposed transaction on the distributed ledger 425 using the normal protocols of the network.

[0072] 6B is a flow chart illustrating another exemplary method 650 of pass-through services provided by an operating separator node 430, consistent with some embodiments. The separator node 430 in this example acts as a proxy for the IoT devices 410 (i.e., identity peer nodes). At operation 655, the separator node 430 may receive a create channel request from one of the IoT nodes 410 directed to another peer node on the blockchain network 420. At operation 660, the separator node 430 may use its dedicated PKI hardware, in some embodiments, to sign the channel request on behalf of the IoT device 410 using a key pair stored in its secure vault that is associated with one of the IoT devices 410 and signed by a certificate authority. At operation 665, the separator node 430 may create a record for the requested channel in its transaction correlation table.

[0073] The separator node 430 may then forward the channel request to the requested peer node at operation 670. The peer node may in turn respond by first verifying the identity of the requested IoT device 410 using a signature and certificate authority at operation 675. The peer node then processes the channel request transaction normally, at operation 680, according to the blockchain network 420 protocol.

[0074] One feature and advantage of these methods is that the separator node 430 may be transparent to the rest of the blockchain network 420 in some embodiments, including endorser nodes, orderer nodes, and other peer nodes. That is, other nodes may process proposed transactions and requests as if they came directly from one of the IoT devices 410. Advantageously, this may allow for the use of specialized nodes to improve performance of computationally intensive workloads and / or workflows. Additionally, the separator node 430 in these embodiments may provide an interface for virtual and secure device-to-device communication with reduced communication workload between the IoT device 410 and the blockchain network 420.

[0075] <Blockchain architecture> FIG. 7A illustrates a blockchain architecture configuration 700 consistent with some embodiments. The blockchain architecture 700 in these embodiments may include a particular blockchain element (e.g., a group of blockchain nodes 702). The virtual secure profile created on the separator node 430 may also behave like an individual blockchain node 720 in some embodiments. The group of blockchain nodes 702 may, in turn, include one or more member nodes 704-710 (these four nodes are depicted by way of example only). These member nodes 704-710 may participate in a number of activities, such as the blockchain transaction addition and validation process (consensus). One or more of the member nodes 704-710 may endorse transactions based on an endorsement policy and may provide ordering services for all blockchain nodes in the architecture 700. The member nodes 704-710 may initiate blockchain authentication and seek to write to a blockchain immutable ledger stored in the blockchain layer 716, a copy of which may be stored on the underlying physical infrastructure 714.

[0076] The blockchain architecture 700 in some embodiments may include one or more applications 724 linked to an application programming interface (API) 722 to access and execute stored program / application code 720 (e.g., chaincode, smart contracts, etc.). The stored program / application code 720 can, in turn, be created according to the customized configuration desired by the participants, can maintain their own state, can control their own assets, can receive external information. The stored program / application code 720 can be deployed as transactions and installed on all blockchain nodes 704-710 via appending to the distributed ledger.

[0077] The blockchain foundation or platform 712 may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and physical computer infrastructure infrastructure that may be used to receive and store new transactions and provide access to auditors seeking to access data entries. The blockchain layer 716 may provide access to the virtual execution environment necessary to process program code and expose interfaces involving the physical infrastructure 714. The cryptographic trust services 718 may be used to verify transactions such as asset exchange transactions and keep information private.

[0078] The blockchain architecture configuration of FIG. 7A can process and execute program / application code 720 through one or more interfaces and services provided by the blockchain platform 712. The program / application code 720 can control blockchain assets. For example, the code 720 can store and transfer data and can be executed by the member nodes 704-710 in the form of smart contracts and associated chaincodes having conditions or other code elements subject to their execution. As a non-limiting example, smart contracts can be created to perform reminders, updates, or other notifications subject to changes, updates, etc., or a combination thereof. The smart contracts themselves can be used to identify authorization and access requirements as well as rules associated with the use of the ledger. For example, the document attribute information 726 can be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 716. The results 728 can include multiple linked shared documents. The physical infrastructure 714 can be utilized to obtain any of the data or information described herein.

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

[0080] A smart contract can write data to the blockchain in the format of key-value pairs. In some embodiments, the smart contract code can read values ​​stored in the blockchain and also use them in application operations. The smart contract code in these embodiments can then write the output of various logical operations to the blockchain. The smart contract code in some embodiments can be used to create temporary data structures in a virtual machine or other computing platform. The data written to the blockchain in these embodiments can be public or encrypted and kept private. The temporary data used / generated by the smart contract may be kept in memory by the provided execution environment and then deleted once the data required for the blockchain is identified.

[0081] The chaincode in some embodiments may include a code interpretation of the smart contract with additional functionality. In some embodiments, the chaincode may be implemented as program code deployed on a computing network, where it is executed and verified together by the chain validator during the consensus process. The chaincode may receive a hash, and may retrieve a hash from the blockchain that is associated with a data template created by use of a previously stored feature extractor. If the hash of the hashed identifier and the hash created from the stored identifier template data match, the chaincode may send an authentication key to the requested service. The chaincode may write cryptographic details to the associated blockchain data.

[0082] FIG. 7B illustrates an example of a blockchain transaction flow 750 between nodes of a blockchain, according to some embodiments. The transaction flow in these embodiments may include a transaction proposal 791 sent by an application client node 760 to an endorsing peer node 781. The endorsing peer 781 may verify the client signature and may execute a chaincode function to initiate the transaction. The output may include the chaincode result, a set of versions of the keys / values ​​read by the chaincode (the read set), and a set of keys / values ​​written by the chaincode (the write set). A proposal response 792 may then be sent back to the client 760, along with an endorsement signature, if approved.

[0083] In response, the client 760 may assemble the endorsements into a transaction payload 793 and broadcast it to the ordering service node 784. The ordering service node 784 may then distribute the ordered transactions as a block to all peers 781-783 on the channel. Before committing it to the blockchain, each peer 781-783 may validate the transaction. For example, peers in some embodiments may check the endorsement policy to ensure that the correct allocation of designated peers has signed the result and authenticated the signature against the transaction payload 793.

[0084] With continued reference to FIG. 7B , a client node 760 in some embodiments may initiate a transaction 791 by constructing and sending a request to a peer node 781 that may act as an endorser. The client 760 may include an application that leverages a supported software development kit (SDK), which may utilize an available API to generate a transaction proposal. The transaction proposal may in turn be a request to invoke a chaincode function such that data is read and / or written to the distributed ledger (i.e., write a new key-value pair for an asset). The SDK may package the transaction proposal in a suitably designed format (e.g., protocol buffers over remote procedure calls (RPC)) and act as a shim to obtain the client's cryptographic credentials to generate a unique signature for the transaction proposal.

[0085] In response, the endorsing peer node 781 may verify that (a) the transaction proposal is well-formed, (b) the transaction has not already been submitted in the past (replay attack protection), (c) the signature is valid, and (d) the submitter (client 760 in this example embodiment) is properly authorized to perform the proposed operation on the channel. The endorsing peer node 781 may receive the transaction proposal input as an argument to the called chaincode function. The chaincode may then be executed against the current state database to generate a transaction result including a response value, a read set, and a write set. In some embodiments, no ledger updates are made at this point. Instead, the set of values, along with the endorsing peer node 781's signature, may be returned as a proposal response 792 to the client's 760's SDK, which parses the payload for the application to consume.

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

[0087] After successful validation, in operation 793, the client 760 may assemble the endorsements into a transaction and broadcast the transaction proposal and response in a transaction message to the ordering service 784. The transaction may include a read / write set, the signature of the endorsing peers, and a channel ID. The ordering service 784 does not need to validate the entire contents of the transaction to perform the action. Instead, the ordering service 784 may simply receive transactions from all channels in the network, order them chronologically by channel, and create blocks of transactions per channel.

[0088] + Generated by the execution of a transaction. The transactions in the block may be tagged as valid or invalid. Further, in operation 795, each peer node 781-783 may add a block to the chain of channels, and for each valid transaction, a write set is committed to the current state database. An event may be emitted to notify the client application that a transaction (invocation) has been immutably added to the chain, and also to notify whether the transaction was valid or invalid.

[0089] Permissioned Blockchain FIG. 8A illustrates an example of a permissioned blockchain network featuring a decentralized, decentralized peer-to-peer architecture, consistent with some embodiments. In this example, a blockchain user 802 may initiate a transaction against a permissioned blockchain 804. In this example, the transaction may be deployed, invoked, or queried, and may be issued via a client-side application leveraging an SDK, directly via an API, etc. The network may provide access to regulators 806, such as auditors. A blockchain network operator 808 manages member permissions, such as registering regulators 806 as "auditors" and blockchain users 802 as "clients." Auditors may be limited to only querying the ledger, while clients may be allowed to deploy, invoke, and query certain chaincodes.

[0090] A blockchain developer 810 may write chaincode and client-side applications in some embodiments. The blockchain developer 810 in these embodiments may deploy the chaincode directly to the network via an interface. To include credentials from traditional data sources 812 in the chaincode, the developer 810 may use an out-of-band connection to access the data. In this example, a blockchain user 802 may connect to a permissioned blockchain 804 via a peer node 814. Before proceeding with any transaction, the peer node 814 may obtain the user's registration and transaction certificates from a certificate authority 816 that manages the roles and permissions of users. In some embodiments, a blockchain user must possess these digital certificates in order to transact on the permissioned blockchain 804. In other embodiments, a blockchain user may be authenticated using other techniques, such as via a decentralized chain of trust. On the other hand, a user seeking to utilize the chaincode may be required to verify its credentials on a traditional data source 812. The chaincode may use an out-of-band connection to this data via a traditional processing platform 818 to verify the user's authentication.

[0091] FIG. 8B illustrates another example of a permissioned blockchain network featuring a decentralized, decentralized peer-to-peer architecture, consistent with some embodiments. In this example, blockchain users 822 can submit transactions to a permissioned blockchain 824. In this example, transactions may be deployed, invoked, or queried, and may be issued via a client-side application leveraging an SDK, directly via an API, etc. The network may provide access to regulators 826, such as auditors. A blockchain network operator 828 manages member permissions, such as registering regulators 826 as "auditors" and blockchain users 822 as "clients." Auditors may be limited to only querying the ledger, while clients may be allowed to deploy, invoke, and query certain chaincodes.

[0092] A blockchain developer 831 can write the chaincode and client-side applications in these embodiments. The blockchain developer 831 can deploy the chaincode directly to the network via an interface. To include credentials from traditional data sources 832 in the chaincode, the developer 831 can use an out-of-band connection to access the data. In this example, a blockchain user 822 connects to the network via a peer node 834. Before proceeding with any transaction, the peer node 834 obtains the user's registration and transaction certificates from a certificate authority 836. In some embodiments, a blockchain user must possess these digital certificates in order to transact on the permissioned blockchain 824. In other embodiments, a blockchain user may be authenticated using other techniques, such as via a decentralized chain of trust. On the other hand, a user seeking to utilize the chaincode may be required to verify its credentials on a traditional data source 832. The chaincode may use an out-of-band connection to this data via a traditional processing platform 838 to verify the user's authentication.

[0093] FIG. 8C illustrates an exemplary system including a physical infrastructure 811 configured to perform various operations consistent with some embodiments. With reference to FIG. 8C, the physical infrastructure 811 includes a module 888 and a module 889. The module 889 includes a blockchain 820 and a smart contract 830 (which may reside in the blockchain 820) that may perform (in module 812) any of the operational steps 878 included in any of the exemplary embodiments. The steps / operations 878 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 830 or the blockchain 820 or both. The physical infrastructure 811, the module 888, and the module 889 may include one or more computers, servers, processors, memories, or wireless communication devices, or combinations thereof. Additionally, the module 888 and the module 889 may be the same module.

[0094] FIG. 8D illustrates another exemplary system configured to perform various operations consistent with some embodiments. With reference to FIG. 8D, the system includes a module 812 and a module 814. The module 814 includes a blockchain 820 and a smart contract 830 (which may reside in the blockchain 820) that may perform (in module 812) any of the operational steps 878 included in any of the exemplary embodiments. The steps / operations 878 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 830 or the blockchain 820 or both. The physical module 812 and the module 814 may include one or more computers, servers, processors, memories, or wireless communication devices, or combinations thereof. Additionally, the module 812 and the module 814 may be the same module.

[0095] FIG. 8E illustrates an exemplary system configured to utilize a smart contract configuration between contracting parties and an intermediary server configured to enforce the smart contract terms on the blockchain 820, consistent with some embodiments. With reference to FIG. 8E, the configuration may represent a communication session, an asset transfer session, or a process or procedure driven by a smart contract 830 that explicitly identifies one or more user devices 852 or 856, or both. The execution, operation, and results of the smart contract may be managed by a server 854. The contents of the smart contract 830 may require digital signatures by one or more entities 852 and 856 that are parties to the smart contract transaction. The results of the execution of the smart contract may be written to the blockchain 820 as a blockchain transaction. The smart contract 830 resides on the blockchain 820, which may reside on one or more computers, servers, processors, memories, or wireless communication devices, or a combination thereof.

[0096] FIG. 8F illustrates a system 860 including a blockchain, consistent with some embodiments. Referring to the example of FIG. 8D, an application programming interface (API) gateway 862 provides a common interface for accessing blockchain logic (e.g., smart contracts 830 or other chaincode) and data (e.g., distributed ledger, etc.). In this example, the API gateway 862 is a common interface for performing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 852 and 856 to a blockchain peer (i.e., server 854). Here, server 854 is a blockchain network peer component that holds a copy of the world state and the distributed ledger, allowing clients 852 and 856 to not only query the world-state data, but also to submit transactions to the blockchain network where the endorsing peers execute smart contracts 830, depending on the smart contracts 830 and the endorsing policies.

[0097] <Block processing> 9A illustrates a process 900 in which a new data block 930 is added to a distributed ledger 920, consistent with some embodiments, and FIG. 9B illustrates the contents of the new data block 930 for a blockchain, consistent with some embodiments. The new data block 930 may include document link data.

[0098] With reference to FIG. 9A, a client (not shown) may submit a transaction to blockchain nodes 911, 912, or 913, or a combination thereof. A client may be instructions received from any source to perform an activity on the blockchain 922. As an example, a client may be an application acting on behalf of a requester, such as a device, person, or entity, proposing a transaction for the blockchain. Multiple blockchain peers (e.g., blockchain nodes 911, 912, and 913) may maintain a copy of the blockchain network state and the distributed ledger 920. Different types of blockchain nodes / peers may exist in the blockchain network, including endorsing peers that simulate and endorse transactions proposed by clients, and committing peers that verify the endorsements, validate the transactions, and commit the transactions to the distributed ledger 920. In some embodiments, blockchain nodes 911, 912, and 913 may act as endorser nodes, committer nodes, or both.

[0099] The distributed ledger 920 may include a blockchain that stores immutable, sequenced records in blocks, and a state database 924 (current world state) that maintains the current state of the blockchain 922. There may be one distributed ledger 920 per channel, and each peer maintains its own copy of the distributed ledger 920 for each channel in which it is a member. The blockchain 922 may be a transaction log, structured as hash-linked blocks, where each block contains a sequence of N transactions. A block may include various components as shown in FIG. 9B. Block links (shown by arrows in FIG. 9A) may be generated by appending a hash of the previous block's header within the block header of the current block. In this way, all transactions on the blockchain 922 may be sequenced and cryptographically linked, preventing tampering with the blockchain data without breaking the hash links. Furthermore, for linking purposes, the latest block of the blockchain 922 represents all transactions that came before it. The blockchain 922 may be stored on a peer file system (local storage or connected storage) that supports append-only blockchain workloads.

[0100] The current state of the blockchain 922 and distributed ledger 920 may be stored in a state database 924, where the current state data represents the latest values ​​of all keys that have ever been included in the chain transaction log of the blockchain 922. Chaincode invocations execute transactions against the current state of the state database 924. To make the interaction of these chaincodes more efficient, the latest values ​​of all keys may be stored in the state database 924. The state database 924 may contain an indexed view into the transaction log of the blockchain 922, so that it can be regenerated off-chain at any time. The state database 924 may be automatically restored (or generated on demand) at peer startup before transactions are accepted.

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

[0102] The ordering service 910 accepts approved transactions, orders them into blocks, and distributes the blocks to committing peers. For example, the ordering service 910 can initiate a new block when a transaction threshold is reached, a timer times out, or upon another condition. In the example of FIG. 9A, blockchain node 912 is a committing peer that receives a new block of data 930 for storage in the blockchain 922. The first block of a blockchain is sometimes called a genesis block, which contains information about the blockchain, its members, the data stored in it, etc.

[0103] The ordering service 910 may be comprised of a cluster of ordering nodes. The ordering service 910 in some embodiments may not process transactions, smart contracts, or maintain a shared ledger. Rather, the ordering service 910 in these embodiments may accept approved transactions and specify the order in which those transactions are committed to the distributed ledger 920. The architecture of the blockchain network may be designed such that a particular implementation of "ordering" (e.g., Solo, Kafka, BFT, etc.) is a pluggable component.

[0104] Transactions in some embodiments may be written to the distributed ledger 920 in a consistent order. The order of transactions in these embodiments may be established to ensure that updates to the state database 924 are valid when committed to the network. Unlike cryptocurrency blockchain systems (e.g., Bitcoin, etc.) where ordering is achieved by solving cryptographic puzzles, i.e., mining, in this example, the parties to the distributed ledger 920 can choose the ordering mechanism that best suits their network.

[0105] In some embodiments, when the ordering service 910 initializes a new data block 930, the new data block 930 may be broadcast to the committing peers (e.g., blockchain nodes 911, 912, and 913). In response, each committing peer may validate the transactions in the new data block 930 by verifying that the read set and write set still match the current world state in the state database 924. Specifically, the committing peer may determine whether the read data that existed when the endorser simulated the transaction is identical to the current world state in the state database 924. Once the committing peer validates the transaction, it may write the transaction to the blockchain 922 on the distributed ledger 920, and the state database 924 may be updated with the write data from the read-write set. In some embodiments, if the transaction fails (e.g., if the committing peer finds that the read-write set does not match the current world state in the state database 924), the transactions that were ordered into the block are still included in the block, but are marked as invalid, and the state database 924 is not updated.

[0106] With reference to FIG. 9B, a new data block 930 (also referred to as a data block) stored in the blockchain 922 of the distributed ledger 920 may, in some embodiments, include multiple data segments, such as a block header 940, block data 950, and block metadata 960. It should be understood that the various depicted blocks and their contents, such as the new data block 930 and its contents shown in FIG. 9B, are merely examples and are not intended to limit the scope of the exemplary embodiments. The new data block 930 may store transaction information for N transactions (e.g., 1, 10, 100, 200, 1000, 2000, 3000, etc.) in the block data 950. The new data block 930 may also include a link to a previous block (e.g., on the blockchain 922 of FIG. 9A) in the block header 940. In particular, the block header 940 may include a hash of the header of the previous block. The block header 940 may also include a unique block number, a hash of the block data 950 of the new data block 930, etc. The block numbers of the new data blocks 930 may be unique and may be assigned in various orders, such as an incremental / consecutive order starting from zero.

[0107] The block data 950 may store transaction information for each transaction recorded in the new data block 930. For example, the transaction data may include one or more of the following: transaction type, version, timestamp, distributed ledger 920 channel ID, transaction ID, epoch, payload visibility, chaincode path (deploy tx), chaincode name, chaincode version, inputs (chaincode and function), client (creator) identification such as public key and certificate, client signature, endorser identification, endorser signature, proposal hash, chaincode event, response status, namespace, read set (e.g., list of keys and versions read by the transaction), write set (e.g., list of keys and values), start key, end key, list of keys, Merkle tree query summary, etc. Note that the transaction data may be stored for every N transactions.

[0108] In some embodiments, the block data 950 may also store new data 962 that adds additional information to the hash-linked chain of blocks in the blockchain 922. The additional information may include one or more of the steps, features, processes, or actions described or illustrated herein, or a combination thereof. Thus, the new data 962 may be stored in an immutable log of blocks on the distributed ledger 920. Some of the advantages of storing such new data 962 are reflected in various embodiments disclosed and illustrated herein. In FIG. 9B, the new data 962 is depicted in the block data 950, but in some embodiments, it may also be located in the block header 940 or the block metadata 960. The new data 962 may also include a document decryption key used to link documents within an organization.

[0109] The block metadata 960 may store multiple fields of metadata (e.g., as a byte array, etc.). The metadata fields may include a signature at the time of block creation, a reference to the last constituent block, a transaction filter that identifies valid and invalid transactions in the block, the last persisted offset of the ordering service that ordered the block, etc. The signature, last constituent block, and orderer metadata may be added by the ordering service 910. Alternatively, the committer of the block (e.g., blockchain node 912) may add validity / invalidity information based on an endorsement policy, validation of the read / write set, etc. The transaction filter may include a byte array of size equal to the number of transactions in the block data 950 and a validation code that identifies whether the transaction was valid / invalid.

[0110] FIG. 9C illustrates an embodiment of a blockchain 970 for digital content, consistent with some embodiments. Digital content may include one or more files and associated information. Files may include transaction data, media, images, video, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable, append-only aspects of some blockchain embodiments may be desirable to act as safeguards to protect the integrity, validity, and authenticity of the digital content, making it suitable for use in legal proceedings where admissibility rules apply, or other settings where evidence is considered, or where the presentation and use of digital information is otherwise of interest. In this case, the digital content may be referred to as digital evidence.

[0111] The blockchain in these embodiments may be formed in a variety of ways. In one embodiment, the digital content may be included in and accessed from the blockchain itself. For example, each block of the blockchain may store a hash value of the reference information (e.g., headers, values, etc.) along with the associated digital content. The hash value and the associated digital content may then be encrypted together. Thus, the digital content of each block may be accessed by decrypting each block in the blockchain, and the hash value of each block may be used as a reference to reference previous blocks. This may be illustrated as follows: Block 1 Block 2 ....... Block N Hash value 1 Hash value 2 Hash value N Digital Content 1 Digital Content 2 Digital Content N

[0112] 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 including any digital content. The digital content may be stored in a separate storage area or memory address in association with the hash value of the original file. The separate storage area may be the same storage device used to store the blockchain, or a separate 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 searching for that hash value in the storage area where it is stored in association with the actual digital content. This operation may be performed, for example, by a database gatekeeper. This may be illustrated as follows: Blockchain Storage Space Block 1 hash value Block 1 hash value... contents .. .. .. Block N hash value Block N hash value... contents

[0113] In the exemplary embodiment of FIG. 9C , the blockchain 970 comprises a number of blocks 9781, 9782, . . . 978 that are cryptographically linked in an ordered sequence. N 9781, 9782, . . . 978, where N is greater than or equal to 1. N The encryption used to concatenate may be any of a number of keyed or non-keyed hash functions. In one embodiment, blocks 9781, 9782, . . . 978 N The blocks 9781, 9782, . . . 978 are subjected to a hash function that generates an n-bit alphanumeric output (where n is 256 or any other 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 Secured Hash Algorithm) algorithms, Merkle-Damgard algorithms, HAIFA algorithms, Merkle tree algorithms, nonce-based algorithms, and non-collision resistant PRF algorithms. In another embodiment, blocks 9781, 9782, . . . 978 are subjected to a hash function that generates an n-bit alphanumeric output (where n is 256 or any other 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 Secured Hash Algorithm) algorithms, Merkle-Damgard algorithms, HAIFA algorithms, Merkle tree algorithms, nonce-based algorithms, and non-collision resistant PRF algorithms. N may be cryptographically concatenated by a function different from the hash function. For purposes of illustration, the following description is made with reference to a hash function (e.g., SHA-2).

[0114] Blocks 9781, 9782, ... 978 in the blockchain N Each of the may include a header, a version of the file, and a value. As a result of hashing in the blockchain, the header and value may vary from block to 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 may be a different version of the original file.

[0115] The first block 9781 of a blockchain may be called a genesis block and may include a header 9721, an original file 9741, and an initial value 9761. The hashing scheme used for the genesis block, and indeed for all subsequent blocks, may be different. For example, all of the information in the first block 9781 may be hashed together at once, or each or a portion of the information in the first block 9781 may be hashed individually, followed by subsequent hashing of the individually hashed portions.

[0116] The header 9721 may include one or more initial parameters, such as a version number, a timestamp, a nonce, route information, difficulty, consensus protocol, duration, media format, source, descriptive keywords, or other information related to the original file 9741, or the blockchain, or both, or a combination thereof. The header 9721 may be generated automatically (e.g., by blockchain network management software) or manually by a blockchain participant. Other blocks 9782 to 978 of the blockchain may include N Unlike the headers of the original block, the genesis block header 9721 may not reference any previous blocks, simply because there are no previous blocks.

[0117] The original file 9741 of the genesis block may be, for example, data as captured by a device, with or without processing prior to inclusion in the blockchain. The original file 9741 may be received from a device, media source, or node through an interface of the system. The original file 9741 may be associated with metadata, which may be generated manually or automatically by, for example, a user, a device, or a system processor, or a combination thereof. The metadata may be included in the first block 9781 in association with the original file 9741.

[0118] The value 9761 in the genesis block may be an initial value generated based on one or more unique attributes of the original file 9741. In one embodiment, the one or more unique attributes may include a hash value of the original file 9741, metadata of the original file 9741, and other information associated with the file. In one embodiment, the initial value 9761 may be based on the following unique attributes: 1) SHA-2 calculated hash value of the original file 2) Source device ID 3) The start timestamp of the original file 4) Initial location of original files 5) A member ID in the blockchain network for the software that currently controls the original file and associated metadata.

[0119] Other blocks in the blockchain: 9782 to 978 N However, unlike the header 9721 of the first block, the headers 9722 to 9723 of the other blocks have the same header, file, and value. N Each of the Nth blocks contains a hash value of the immediately preceding block, which may be just the hash value of the immediately preceding block's header, or may be the hash value of the entire immediately preceding block. By including the hash value of the immediately preceding block in each remaining block, it is possible to trace back block by block from the Nth block, as shown by arrow 980, to the genesis block (and associated original file), establishing an auditable and immutable chain of custody.

[0120] Headers 9722 to 972 in other blocks N Each of the may also include other information (e.g., version numbers, timestamps, nonce, root information, difficulty, consensus protocol or other parameters or combinations thereof), or information related to the corresponding file or the blockchain in general, or both.

[0121] Files 9742-974 in other blocks N may be, for example, the same as the original file or may be a modified version of the original file in the genesis block, depending on the type of processing performed. The type of processing performed may vary from block to block. Processing may include any change that changes information in a file in a previous block, such as correcting information, removing information from a file, or adding or appending information to a file.

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

[0123] Other blocks in other blocks 9762 to 976 N Each value in is unique and is a different value as a result of the operations performed. For example, the value of a block represents an updated version of the value of the previous block. The update is reflected in the hash of the block to which the value was assigned. Thus, the value of a block indicates what operations were performed in the block, and allows tracing back through the blockchain to the original file. This tracing allows the chain of custody of the file to be confirmed across the blockchain.

[0124] For example, consider the case where a portion of a file in a previous block has been corrected, blocked out, or pixelated to protect the identity of a person appearing in the file. In this case, the block containing the corrected file will contain metadata related to the corrected file (e.g., how the correction was made, who made the correction, a timestamp of where the correction was made, etc.). The metadata may be hashed to form a value. Because the metadata of a block is different from the information hashed to form the value of the previous block, the values ​​will be different from each other and may be restored when decrypted.

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

[0126] 9D is a diagram illustrating an embodiment of a block, which may represent the structure of a block of a blockchain 990, consistent with some embodiments. i , Header 972 i , File 974 i , and the value 976 i may include:

[0127] Header 972 i is the previous block, block i-1, and additional reference information, which may be, for example, any of the types of information discussed herein (e.g., header information including references, properties, parameters, etc.). All blocks in some embodiments may reference a hash of a previous block, except for the genesis block in some embodiments. The hash value of the previous block may be just a hash of the header of the previous block, or may be a hash of all or a portion of the information in the previous block, including files and metadata.

[0128] File 974 i may include multiple data, such as Data1, Data2, ..., DataN, in sequence. The data are tagged with Metadata1, Metadata2, ..., MetadataN that describe the content and / or characteristics associated with the data. For example, the metadata for each data may include information indicating the timestamp of the data, information processing the data, keywords indicating people or other content depicted in the data, or other features that may be useful for establishing the validity and content of the file as a whole, and its use as digital evidence, particularly as described in connection with the embodiments below, or combinations thereof. In addition to the metadata, each data may be tagged with a reference REF1, REF2, ..., REFN to the previous data to prevent tampering, gaps in the file, and sequential referencing through the file. Once metadata is assigned to the data (e.g., through a smart contract), the metadata cannot be changed unless the hash changes in some embodiments, and can be easily identified for invalidation. Thus, the metadata in these embodiments creates a data log of information that can be accessed for use by participants in the blockchain.

[0129] In some embodiments, the value 976 i may be a hash value or other value calculated based on any of the types of information previously discussed. For example,i For each block, the value of that block may be updated to reflect operations performed on that block (e.g., a new hash value, a new storage location, new metadata for the associated file, a transfer of control or access, an identifier, or other action or information added. Although the value of each block is shown to be separate from the metadata for the file and header data, in alternative embodiments, it may be based on some or all of this metadata.

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

[0131] Decryption may occur based on the type of encryption performed on each block. This may include the use of a private key, a public key, or a public-private key pair. For example, if asymmetric encryption is used, a blockchain participant or a processor in the network may generate a public and private key pair using a predefined algorithm. The public and private keys may be related to each other through some mathematical relationship. The public key may be publicly distributed to serve as an address (e.g., an IP address or a home address) for receiving messages from other users. The private key may be kept secret and may be used to digitally sign messages sent to other blockchain participants. The signature may, in turn, be included in the message so that the recipient can verify it using the sender's public key. In this way, the recipient can be confident that only the sender could have sent this message.

[0132] In some embodiments, generating a key pair may be similar to creating an account on the blockchain, without the need to actually register anywhere. In these embodiments, every transaction performed on the blockchain may be digitally signed by the sender using their private key. This signature may help ensure that only the owner of the account can track and process files on the blockchain (within the scope of permissions determined by the smart contract).

[0133] <Computer program product> The present invention may be a system, method or computer program product, or combination thereof, integrated at any possible level of technical detail. The computer program product may include a computer readable storage medium having stored thereon computer readable program instructions for causing a processor to carry out aspects of the present invention.

[0134] A computer-readable storage medium may be a tangible device that can hold and store instructions used by an instruction execution device. The computer-readable storage medium may be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or a suitable combination thereof. More specific examples of computer-readable storage media include portable computer diskettes, hard disks, RAM, ROM, EPROM (or flash memory), SRAM, CD-ROM, DVD, memory sticks, floppy disks, punch cards or ridges in grooves or other mechanically encoded devices that record instructions, and suitable combinations thereof. As used herein, a computer-readable storage device should not be construed as a transitory signal per se, such as an electric signal transmitted over a wire, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a wave guide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or a radio wave.

[0135] The computer-readable program instructions described herein can be downloaded from the computer-readable storage medium to each computing / processing device or to an external computer or storage device via a network (e.g., the Internet, a local area network, a wide area network, or a wireless network network, or a combination thereof). The network may be comprised of copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface of each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in the computer-readable storage medium within the respective computing / processing device.

[0136] The computer readable program instructions for carrying out the operations of the present invention may be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object oriented programming languages ​​such as Smalltalk, C++, etc., and procedural programming languages ​​such as the "C" programming language and similar programming languages. The computer readable program instructions may be executed entirely on the user's computer, as a stand-alone software package, or partially on the user's computer. Alternatively, they may be executed partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the computer readable program instructions to perform aspects of the invention.

[0137] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

[0138] These computer readable program instructions can be provided to a processor of a computer or other programmable data processing apparatus to generate a machine, such that the instructions, executed via a processor of the computer or other programmable data processing apparatus, generate means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer readable program instructions can also be stored in a computer readable storage medium connectable to a computer, programmable data processing apparatus, or other device or combination that functions in a particular way, such that the computer readable program instructions stored therein configure one of the products including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0139] Computer readable program instructions, such as instructions to perform the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams on a computer, other programmable apparatus, or other device, may also be loaded into a computer, other programmable data processing apparatus, or other device to perform a series of operational steps on the computer, other programmable apparatus, or other device to generate a computer-implemented process.

[0140] The flowcharts and block diagrams in the figures illustrate the configuration, functionality, and operation of executable implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or part of an instruction, which constitutes one or more executable instructions for implementing a specified logical function. In some alternative embodiments, the functions shown in the blocks may differ from the order shown in the figures. For example, two blocks shown in succession may in fact be accomplished as one step and executed simultaneously, substantially simultaneously, partially or fully in a time-overlapping manner, or the blocks may be executed in reverse order depending on the functions involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a special purpose hardware-based system that executes the specified functions or operations or executes a combination of special purpose hardware and computer instructions.

[0141] <General> Any particular program nomenclature used herein is merely for convenience, and thus the present invention should not be limited to use only in any particular application identified and / or implied by such nomenclature. Thus, for example, routines executed to implement embodiments of the present invention could have been referred to as "programs," "applications," "servers," or other meaningful nomenclature, regardless of whether they are implemented as part of an operating system or a particular application, component, program, module, object, or sequence of instructions. Indeed, other alternative hardware and / or software environments can be used without departing from the scope of the present invention.

[0142] The presently described embodiments are therefore to be considered in all respects as illustrative and not restrictive and reference should be made to the appended claims for determining the scope of the invention.

Claims

1. 1. A computer-implemented method for configuring a blockchain network, comprising: The processor of the partition node of the blockchain network responsive to a registration request from a device, validating the device based on an immutable device identity received from the device; responsive to said validation, creating, by a processor of said separator node, a profile for said device and registering said device in said profile; updating, by a processor of the separator node, a transaction correlation table maintained at the separator node, the transaction correlation table recording state and configuration information of the blockchain network; executing, by a processor of the separator node, a pass-through service for the devices registered in the profile; 4. A computer-implemented method comprising:

2. The method described in claim 1, wherein the information of the blockchain network recorded in the transaction correlation table includes an endorsement policy and a proxy authority proof of the blockchain network. receiving, by a processor of the separator node, a request from a node of the blockchain network directed to the device; updating, by a processor of the separator node, the transaction correlation table of the device in response to the request; The method of claim 1 further comprising: receiving, by a processor of the separator node, a request from the device directed to the blockchain network; updating, by a processor of the separator node, the transaction correlation table of the device in response to the request; The method of claim 1 further comprising:

5. 1. A computer-implemented method for configuring a blockchain network, comprising: The processor of the partition node of the blockchain network responsive to a registration request from a device, validating the device based on an immutable device identity received from the device; responsive to said validation, creating, by a processor of said separator node, a profile for said device and registering said device in said profile; the profile includes a virtual profile for the device, the virtual profile including an encryption key pair for the device, the encryption key pair being stored by a processor of the separator node in a secure repository associated with the separator node; executing, by a processor of the separator node, a pass-through service for the devices registered in the profile; 4. A computer-implemented method comprising:

6. The method of claim 5 , wherein the secure repository comprises a hardware security architecture.

7. The method of claim 1 or claim 5, wherein the pass-through service includes creating a channel for communication between peers on the blockchain network.

8. The method of claim 1 or claim 5, wherein the pass-through service includes facilitating a transaction on behalf of the device.

9. The method of claim 1 or claim 5, wherein the pass-through service includes facilitating communications between the device and other nodes of the blockchain network.

10. 10. The method of claim 9, wherein the pass-through service further comprises proxying all communications between the device and the other nodes of the blockchain network.

11. The method of claim 1 or claim 5, wherein the registration by the processor of the separator node further includes registering the device with a membership service of the blockchain network.

12. 12. The method of claim 11, wherein the registration enables the device to be registered as a peer node on a private blockchain network.

13. The processor of the partition node: receiving a registration request from the device; In response to the registration request, sending a challenge to the device; verifying a response from the device; and in response to successful verification, registering the device; The method of claim 1 or claim 5, further comprising:

14. The method of claim 1 or claim 5, wherein the immutable device identity includes a Physical Unclonable Function (PUF) associated with the device.

15. 15. The method of claim 14, wherein the PUF automatically provides cryptographic proof for an immutable registration key, the immutable registration key being used as an identity mechanism in the blockchain network.

16. 6. The method of claim 1 or claim 5, wherein the devices are Internet of Things (IoT) devices and the partition node maintains a distributed ledger on behalf of the IoT devices.

17. The method of claim 1 or claim 5, wherein the separator node comprises a dedicated hardware co-processor for executing the pass-through service.

18. A computer-implemented method for configuring a blockchain network, comprising: initializing a pass-through service by a processor of a separator node of the blockchain network; receiving, at the separator node, a registration request from a device; validating, by the delimiter node in response to a registration request, the device using a Physical Unclonable Function (PUF) response received from the device, the PUF automatically providing cryptographic proof of an immutable registration key previously measured or calculated by a manufacturer of the device and previously communicated over a secure channel to the delimiter node; The verification step is: the delimiter node sending a challenge to the device; the delimiter node receiving a PUF response from the device; In response to the verification, a processor of the separator node registers the device in a virtual profile; a processor of the separator node executing a pass-through service for the registered device; 4. A computer-implemented method comprising:

19. 1. A computer program product for integrating device identity into a permissioned framework of a blockchain network, the computer program product comprising: a computer readable storage medium having program instructions embodied therein, the program instructions being executable by a processor, the computer program product comprising: providing, by a node, a pass-through security service, the pass-through security service including a trusted registration of peers in a blockchain network; registering, by the node, a device as a registered node on the blockchain network, the device having a physical unclonable function associated therewith, the registration including the device sending a physical unclonable function challenge response to the node; creating, by the node based on the registration, a virtual profile of the registered node on the device within a secure enclave; maintaining a transaction correlation table for the device, the transaction correlation table including records of blockchain essentials associated with the device, the blockchain essentials including channels, endorsement policies, and delegation authority proofs; facilitating transaction commitment and client communications for the device by the node; and executing the pass-through security service by a computer program product.

Images